How to find a cloud engineer.

Cloud hiring has a signal problem. Certifications are the obvious filter, they are heavily marketed, and most of them are written exams that a determined person passes through study alone. Meanwhile the thing that actually predicts performance — whether someone manages infrastructure as versioned code or clicks through a console — appears nowhere on the CV.

A second assumption costs more than it should: that cloud experience transfers freely between providers. The concepts do transfer, but IAM models, networking primitives, and managed service behaviour differ enough that an AWS expert is an intermediate Azure engineer for months. Whether that matters depends entirely on whether the role has ramp capacity.

Job titles worth searching

Grouped by what the person actually does, because searching all42 at once produces a result set you cannot triage. Decide which group you need first — that decision does more for the search than any string below.

Certifications, and which ones mean something

The distinction worth making is written versus practical. Performance-based exams conducted in a live environment cannot be memorised; multiple-choice associate-level certifications can, and are held by a very large population.

Where cloud engineers actually are

Published infrastructure code is the fastest maturity signal in this field. Terraform and Pulumi modules on GitHub show someone who versions, reviews, and tests their infrastructure, which separates modern practice from console-driven administration invisibly on a CV. This single check resolves a large share of mismatches before an interview.

Open source contribution identifies the deepest practitioners. The tools that run modern platforms — Kubernetes, Prometheus, Grafana, the HashiCorp stack — are open, and contributors to the projects your platform depends on are both highly capable and rarely contacted. They expect outreach demonstrating familiarity with their actual work.

The conference circuit splits usefully between vendor events and practitioner ones. KubeCon and SREcon attract people who operate systems and publish speaker lists worth mining; the large provider conferences skew more commercial. For the emerging cost discipline, FinOps practitioners are a small enough population that searching quantified savings claims produces a workable shortlist.

Boolean search strings

Written to be pasted as-is. Each one is built around an intent rather than a platform, since the useful question is what you are trying to find, not which site you happen to be on.

site:linkedin.com/in/ ("cloud engineer" OR "cloud architect" OR "platform engineer") (Terraform OR Kubernetes OR AWS OR Azure) "{city}"

site:github.com ("terraform" OR "pulumi" OR "cloudformation") ("module" OR "provider" OR "stack") -awesome -tutorial

("CKA" OR "CKS" OR "kubernetes operator" OR "custom resource" OR "etcd") ("production" OR "cluster") -jobs -course

("FinOps" OR "cloud cost optimization" OR "reserved instances" OR "savings plans") ("reduced" OR "saved" OR "%") -jobs -vendor

("cloud security" OR "CSPM" OR "IAM policy" OR "least privilege") (AWS OR Azure OR GCP) -jobs -vendor -webinar

("speaker" OR "talk" OR "session") ("KubeCon" OR "re:Invent" OR "HashiConf" OR "SREcon") 2024..2026 -jobs

("cloud migration" OR "lift and shift" OR "data centre exit" OR "modernization") ("led" OR "delivered" OR "completed") -jobs -consulting

site:github.com ("contributor" OR "maintainer") ("kubernetes/" OR "hashicorp/" OR "prometheus/" OR "grafana/")

Mistakes that cost the most time

1. Assuming cloud skills transfer freely between providers

   The concepts transfer; the depth does not. IAM models, networking primitives, and managed service behaviour differ substantially between AWS, Azure, and GCP, and an expert in one is realistically an intermediate practitioner in another for some months. For roles requiring immediate depth, provider match matters. For roles with ramp capacity, general infrastructure ability matters more.

2. Reading certifications as operational experience

   Most cloud certifications are written exams that can be passed through study alone, and certification counts correlate weakly with ability to run production systems. The exceptions are the practical ones — CKA, CKAD, and CKS are performance-based exams in a live cluster under time pressure, which cannot be memorised. Weight those far more heavily than the written associate-level credentials.

3. Not distinguishing builders from operators

   Designing cloud architecture and keeping it running at 3am are different jobs that attract different people. Architects who have never carried a pager tend to design systems that are unpleasant to operate, and operators may lack the design breadth for greenfield work. Establish which the role actually needs, since job adverts routinely ask for both.

4. Overlooking console-versus-code maturity

   An engineer who provisions infrastructure through a web console and one who manages everything through Terraform in version control are at different maturity levels, and the difference is invisible on a CV that lists the same services. Published infrastructure code is the fastest way to tell, and it predicts working style better than any interview question.

5. Ignoring the cost dimension

   Cloud spend has become a board-level concern, and FinOps has emerged as a genuine discipline combining engineering with commercial analysis. Engineers who understand reserved capacity, rightsizing, and architectural cost trade-offs are scarce and increasingly sought. Roles that need this rarely say so, and candidates who have it rarely lead with it.

6. Requiring every cloud in the job advert

   Adverts asking for deep AWS, Azure, and GCP experience simultaneously attract people with shallow experience of all three. Genuine multi-cloud depth is rare and usually means one primary provider with working knowledge of another. Naming the primary provider honestly produces far better applicants than listing all three.

Common questions

What job titles should I search for when hiring a cloud engineer?

Provider-specific titles are more informative than generic ones, so search AWS Engineer, Azure Engineer, GCP Engineer, and their architect variants alongside Cloud Engineer and Cloud Architect. Modern practice is better identified by tooling than by title: Terraform Engineer, Platform Engineer, GitOps Engineer, and Infrastructure as Code Engineer. Kubernetes has become its own specialisation with titles such as Kubernetes Engineer, Cloud Native Engineer, and SRE. For cost work, FinOps Engineer and Cloud Cost Analyst identify a small but growing population.

Do cloud skills transfer between AWS, Azure, and GCP?

The concepts do, the depth does not. An engineer who understands networking, identity, storage, and compute abstractions will grasp the equivalent services on another provider quickly, but the specifics differ substantially — IAM models, networking primitives, and the behaviour of managed services are genuinely different, and expertise takes months to rebuild. For a role needing immediate production depth, match the provider. For one with ramp capacity, general infrastructure engineering ability is the better predictor, and requiring deep experience across all three providers usually attracts people with shallow experience of each.

Which cloud certifications actually indicate capability?

The practical ones. CKA, CKAD, and CKS are performance-based exams conducted in a live Kubernetes cluster under time pressure, which makes them genuinely hard to pass without hands-on ability. Professional-level cloud certifications such as AWS Solutions Architect Professional and Azure AZ-305 are meaningfully harder than associate-level ones and much less commonly held. Associate-level certifications like AWS Solutions Architect Associate are widely held and obtainable through study alone, so they indicate familiarity rather than operational experience. Certification count is a poor proxy for ability generally.

What is the difference between a cloud engineer, a DevOps engineer, and an SRE?

The boundaries are genuinely blurred and vary by organisation. Broadly, a cloud engineer builds and manages cloud infrastructure; a DevOps engineer focuses on the delivery pipeline and the automation connecting development to production; and a site reliability engineer applies software engineering to operations, owning reliability targets, error budgets, and production incident response. In smaller organisations one person does all three. What matters more than the label is whether the role is primarily building new systems or operating existing ones, since those attract different people.

Where can I find cloud engineers outside LinkedIn?

GitHub is the strongest signal, particularly published Terraform or Pulumi modules, which demonstrate that someone manages infrastructure as versioned code rather than through a console — a maturity distinction invisible on a CV. Contributors to Kubernetes, Prometheus, Grafana, and HashiCorp projects are exceptional candidates and rarely approached. The conference circuit is productive too: KubeCon and SREcon attract practitioners rather than vendors, and their speaker lists identify people with genuine operational depth.