Hiring Guide

Azure, AWS, or GCP? What to Look for in a Contract Cloud Engineer

Cloud Sensitial · Hiring & staffing

Most job specs for a "cloud engineer" list a platform — Azure, AWS, or GCP — as if that's the qualifying detail. It isn't, really. The platform tells you which console someone's used, not whether they can actually keep your infrastructure reliable, secure, and cost-sensible. Here's what's worth checking instead.

Platform fluency isn't the same as platform depth

Someone can hold an Azure certification and still have only touched a handful of services in a training sandbox. What matters more is whether they've operated a production environment — dealt with a scaling incident at 2am, cleaned up a runaway cost bill, migrated a legacy workload without downtime. Ask for a specific example, not a list of services they "know."

Infrastructure-as-code, not just clicking through a console

A cloud engineer who can only configure resources by hand in the portal is going to be a bottleneck the moment your infrastructure grows past a handful of services. Terraform, Bicep, or CloudFormation experience is a reasonable proxy for whether someone thinks in repeatable, version-controlled infrastructure rather than one-off changes.

Security is not a separate person's job

It's common to see cloud engineering and security treated as entirely separate hiring tracks. In practice, the engineers who cause the fewest incidents are the ones who default to least-privilege access, encrypted storage, and proper network segmentation without being told to. Ask how a candidate would lock down a new environment by default — the answer tells you a lot.

A quick filter question: ask a candidate to describe a migration or incident that didn't go to plan, and what they changed afterward. Anyone who's actually run production infrastructure will have a real answer. Anyone who doesn't will speak in generalities.

Multi-cloud isn't always the goal

Plenty of teams assume they need someone fluent across all three major platforms. Usually they don't — they need genuine depth in whichever platform they've already committed to, plus enough general cloud-architecture literacy to sanity-check decisions. Breadth without depth tends to produce infrastructure that technically works but is expensive and fragile.

Contract vs. permanent changes what "good" looks like

A permanent hire has time to grow into a stack. A contractor generally doesn't — they need to be productive within days, not months. That's the filter we vet candidates against before anyone gets to interview stage.

If you're trying to fill an Azure, AWS, or GCP role and want it vetted against your actual stack rather than a keyword match, get in touch.