They decide how to isolate, connect, secure and size the cloud resources products will rely on for the long term, and how to evolve them.
The role is neither about creating resources at a cloud provider nor about turning an architecture diagram into scripts. It holds the foundation layer: how accounts and environments are organised, network, compute, storage, identities, security policies, infrastructure as code, backup, capacity and lifecycle. An infrastructure can be perfectly functional on delivery day and impossible to operate six months later.
The boundary with neighbouring roles is deliberately strict. The DevOps Engineer smooths the delivery chain. The Platform Engineer turns technical capabilities into an internal product for developers. The SRE protects the reliability of a service in production. The Cloud Infrastructure Engineer builds the foundations and makes those choices executable, reproducible, secure and maintainable.
Someone executing can provision. Someone holding the role knows why a resource must be isolated, which flow must be allowed, which dependency makes a change risky, and how to roll back. The central tension of the job pits speed of provisioning against control of the estate: moving fast without creating a manual, opaque or over-privileged foundation.
Market benchmarks
The market frequently maps this title onto DevOps, CloudOps or Platform roles, which makes applications hard to compare. People who combine real network depth, rigorous infrastructure-as-code practice, command of identity, and experience of hybrid environments remain sought after.
Certifications are common and useful for placing someone in an ecosystem, but they predict poorly whether someone can lead a risky change, reason about blast radius, or take over an inherited foundation. The scarcity lies less in knowing the services than in infrastructure judgement.
Context
In an IT services firm, the assessment leans on working inside an inherited estate, dealing with the client's standards, contractual limits and shared rights, and the need to hand over infrastructure other people can run. The candidate has to improve a foundation they do not fully control.
Level 1
Junior
Works within a bounded scope from established standards. They can deploy and modify common components, check prerequisites, document what they change, and seek sign-off when the impact goes beyond their area. What separates them from a pure operator is that they do not paper over an unknown with a default value.
Click to read
Level 2
Mid-level
Owns an environment or an infrastructure domain end to end. They connect network, identity, compute, storage and infrastructure as code, handle the dependencies between those layers, and can lead a reversible change. They make sure the resource can be reproduced, maintained and handed on.
Click to read
Level 3
Senior
Arbitrates implementation choices by risk, blast radius, security, cost and migration path. They spot the exceptions that will become structural debt, sequence transformations without demanding a clean slate, and can contradict a request that weakens the foundation. They think in terms of a cloud estate, not a provisioning ticket.
Click to read
Level 4
Expert
Is not distinguished by a longer catalogue of cloud services. They settle the most expensive trade-offs and own the price explicitly: temporarily maintaining two infrastructure models, slowing a migration to preserve reversibility, or accepting extra cost to get verifiable isolation. They turn those decisions into standards other people can use.
Click to read
This is the heart of the role: poor isolation, inconsistent addressing or a misunderstood network dependency contaminates every layer built on top.
A cloud foundation is only under control if it is reproducible, traceable, changeable without drift and cleanly removable; infrastructure as code is assessed as a control mechanism, not as tool proficiency.
Rights, exposure and segmentation are design properties of the foundation. Dealing with them after deployment turns a local mistake into a cross-cutting risk.
The Cloud Infrastructure Engineer has to understand failure domains, restoration, quotas and sizing, without taking the SRE's place in the day-to-day management of application reliability.
The weight is lower but not incidental: infrastructure with no cost attribution, no change documentation and no handover to the teams who run it quickly becomes an orphaned estate.
The method in action
The scorecard at a glance — hover an axis
Cloud, platform & reliability