01Owns
Landing zone and accounts
Structures accounts, projects or subscriptions by environment and team, with guardrail policies, central logging and a clean path for adding new workloads.
Hire · Cloud infrastructure
Hire Cloud Engineers
Senior cloud engineers who join your team to own the foundations your applications run on: accounts and landing zones, private networking, identity and access, and infrastructure defined in code. Before shortlisting, each one has refactored a risky Terraform module and untangled an over-permissive IAM setup in a paid exercise.
Exercise on real Terraform and IAM
Senior, lead and architect levels
Comfortable on AWS, Google Cloud or Azure
On your team
What a cloud engineer owns on your team.
02Owns
Networking
Designs VPCs or VNets, subnets, routing, private endpoints, DNS and connectivity to on-premises or partner networks without exposing services publicly.
03Owns
Identity and access
Replaces long-lived keys with workload identity and federation, scopes roles to least privilege and keeps break-glass access audited.
04Owns
Infrastructure as code
Keeps every resource in Terraform or OpenTofu with remote state, reviewed plans and modules that teams can reuse safely.
05Owns
Cost and capacity
Tags spend by owner, rightsizes instances and storage tiers, uses commitments where usage is steady and alerts before a bill surprises anyone.
Infrastructure mistakes compound quietly
A poorly chosen CIDR range, a shared account for every environment or a pipeline holding administrator keys rarely causes trouble in the first month. It causes trouble when you add a second region, connect a partner network or face a security review. The cloud engineer you hire should be thinking about those moments now.
Ask candidates to describe a network or account structure they inherited and what they changed first. The answer reveals whether they prioritise by risk or by personal preference.
Vetting
Skills we test before a cloud engineer joins.
01Tested
Terraform craft
Module boundaries, state locking, import and moved blocks, drift detection and plans small enough for a human to review.
02Tested
Network design
CIDR planning that leaves room to grow, hub-and-spoke or transit topologies, NAT costs, and debugging routes and security groups methodically.
03Tested
IAM reasoning
Reads policies precisely, understands permission boundaries and service control policies, and can explain why a request was denied.
04Tested
Multi-provider fluency
Deep in one major provider and able to map concepts accurately to the others, without assuming services behave identically.
05Tested
Resilience planning
Multi-zone deployment, backup and restore testing, recovery objectives and the cost of each extra nine.
06Tested
FinOps habits
Reads billing exports, attributes cost to teams and challenges architecture choices that look cheap but generate heavy data transfer charges.
Work sample
How the cloud engineer work sample runs.
- 01Step 1
Refactor a risky module
The candidate receives a Terraform module that recreates a database on a minor change. They identify the forcing attribute and restructure it safely.
- 02Step 2
Tighten access
Given a role with wildcard permissions used by a deployment pipeline, they write a least-privilege replacement and explain how they verified it.
- 03Step 3
Design a network
They sketch subnets, routing and private connectivity for a three-tier app across two environments, noting the trade-offs. We compensate the time.
- 04Step 4
Talk through a bill
A short conversation where they read a sample cost breakdown, name the three biggest savings and the risk each one carries.
Levels
Cloud Engineers: what changes at each level.
01Level 1
Senior
Owns infrastructure for several workloads within an established account and module structure, and reviews peers’ plans.
02Level 2
Lead
Defines module standards, network and identity patterns, and the change process for production infrastructure.
03Level 3
Cloud architect
Plans landing zones, multi-region strategy, migrations from on-premises or between providers, and long-term cost commitments.
Choosing between senior, lead and architect
If you already have a landing zone and module library, a senior engineer extends it. If infrastructure grew by hand in the console and nobody trusts the state files, hire a lead to establish standards and import what exists. Bring in an architect when the decisions are strategic: a second provider, a data residency requirement or a migration out of a data centre.
Other options
When to hire someone other than a cloud engineer.
01Consider
You are all-in on Azure
If your applications use App Service, Functions and Entra ID heavily, an Azure developer works closer to the code.
Open register02Consider
The pain is releases, not infrastructure
Slow pipelines, flaky deploys and missing alerts point to a DevOps engineer rather than a cloud engineer.
Open register03Consider
A small app on a managed platform
If a single service runs on a platform-as-a-service, a full-stack developer can usually manage the hosting too.
Open registerReading a Terraform plan is a core skill
Writing HCL is easy to learn. Knowing which attribute change will destroy and recreate a resource, how to move state without downtime and how to keep plans reviewable is what protects production. Our exercise uses a module with exactly those hazards because they are the ones that cause outages.
A sensible first assignment
Ask for an inventory: what exists, who owns it, which resources are outside code and which identities hold broad permissions. It takes a couple of weeks and gives you a prioritised list of risks instead of a vague sense of unease.
Then pick the highest-risk item, often a long-lived access key or a publicly reachable database, and let the engineer fix it end to end through code review.
FAQ
Questions to resolve before the build.
01AWS, Google Cloud or Azure: which do your cloud engineers know?
Each candidate is deep in at least one provider and has working knowledge of another. We shortlist against the provider you run, and the Terraform exercise uses that provider’s resources.
02Can a cloud engineer reduce our cloud bill?
Cost control is part of the role. Expect tagging, rightsizing and commitment recommendations, each with the risk explained. We do not promise a percentage because savings depend entirely on your current setup.
03What is the difference between a cloud engineer and a DevOps engineer?
A cloud engineer owns the foundations: accounts, networks, identity and infrastructure code. A DevOps engineer owns how software gets built, released and operated on those foundations. Larger teams usually need both.
Works alongside
Roles a cloud engineer works best alongside.
01Pair with
DevOps engineers
Cloud engineers provide the accounts, networks and clusters; DevOps engineers own the pipelines and operations running on top.
Open register02Pair with
Java developers
When large services need connection pooling, private database access and sizing agreed with the people who wrote them.
Open register03Pair with
Data scientists
For GPU capacity, data storage tiers and isolated environments that keep training data access controlled.
Open registerProduct delivery
Need the whole product built instead?
Primary sources
References behind this page
Dated official documentation, standards, and research that support the factual claims on this page.
- 01Terraform documentation: Refactoring with moved blocks
How to restructure modules without destroying existing resources.
- 02AWS documentation: Security best practices in IAM
Official guidance on least privilege and temporary credentials.
How to read this page
Scope, cost and timeline figures are planning guidance until confirmed in a written proposal. Diagrams and screens are illustrations, not client deliverables, and source-code rights and handover follow the signed agreement. See the delivery process and the full disclaimer.
Next decision
Turn the brief into an accepted product scope.
Define outcomes, constraints, evidence, rights and handover before delivery begins.
Commercial rights, repositories, environments, documentation, acceptance and handover remain contract-defined.