Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.

Platform, DevOps and site reliability · Mid level

How to assess a Cloud Infrastructure Engineer

Cloud certification recall is the most tempting and least predictive signal in this hub. It tests knowledge of a vendor's product catalogue — which service does what, which storage class costs less — and that catalogue changes twice a year and is precisely the material an assistant retrieves perfectly. The two failure modes that actually cost cloud organisations money are not knowledge failures at all. The first is permission sprawl: a role granted broadly because narrowing it would have taken an hour, repeated a hundred times, producing an estate where the blast radius of any compromised credential is the whole account. The second is cost that compounds invisibly, because nothing breaks when you over-provision — the cluster keeps running, the snapshots keep accumulating, the cross-region transfer keeps being charged, and the feedback arrives ninety days later on a bill nobody reads line by line. Neither failure is a wrong answer to a question. Both are the accumulated result of taking the fast option under time pressure, which is a disposition, and dispositions are observable only when someone is actually under time pressure doing the work.

Cloud infrastructure engineering separates from DevOps at the point where the question stops being "how does change reach production" and becomes "what is production made of, who can reach it, and what does it cost". The two roles overlap in tooling and diverge in what they are accountable for, which is why they warrant different assessments rather than one shared one.

Identity is the centre of this job and is systematically under-hired for. Every cloud estate accretes roles, and the difference between an estate that survives a leaked credential and one that does not is a series of small decisions made months earlier by an engineer under mild time pressure. Scoping a policy to the three actions and the one resource it needs takes real work; granting the managed administrator policy takes eight seconds and the ticket closes either way. What a hiring manager is really buying is the person who does the hour of work, and who complains about the tooling that makes it an hour. That is observable: put a candidate in a sandbox where the fast path is a wildcard, and watch which path they take when the clock is visible.

Network boundaries are the second axis and carry the same shape. The debugging session that requires opening a path, the temporary rule with no expiry, the resource placed in a public subnet because private networking needed an endpoint. The strong candidate narrates the temporary change and closes it. The weak one solves the immediate problem and moves on, leaving an artefact nobody will ever notice until an audit.

Cost deserves to be treated as an engineering competence rather than a finance concern, because in cloud it is a direct consequence of technical decisions and has no error signal attached. Nothing pages you for over-provisioning. A strong cloud engineer can look at a proposed architecture and say roughly where the money goes — this is egress, this is the always-on cluster, this is the per-request charge that is trivial until the retry loop — and will trade a small amount of elegance for a large amount of predictability.

The fourth axis is dependence on infrastructure the organisation does not control, which is where this role touches the incident world. Uptime Institute's 2026 outage analysis noted external dependency and connectivity failures as a rising category more likely to produce extended disruption, alongside 57 percent of surveyed operators reporting their most recent major outage cost more than $100,000. A cloud engineer who designs as though a managed service cannot fail is designing against evidence. The useful question is not whether they know the availability zone model but whether they have an opinion about what their system does when the region's control plane is degraded but the data plane is fine — a real and common failure shape that certification material barely mentions.

The assessment reflects all four. The sandbox contains an existing multi-account estate with a fast, wrong path deliberately available: a task that can be completed correctly in twenty minutes with a scoped role and network change, or in four minutes with a wildcard and an open rule. The monitored session records which was taken and whether anything temporary was cleaned up. A short written artefact asks for the change note another engineer would read. Then the follow-up conversation does the deciding: you granted this permission — list what it actually allows, and what you would have granted with another hour. This rule you added for testing, is it still there? Where does the money go in what you just built, and what is the first thing you would cut? The control plane in this region is degraded but instances are healthy — what still works? Those questions are answerable only by the person who made the choices, and the choices are the job.

What the job actually needs

identity and permission design
network boundary reasoning
cost as an engineering constraint
multi-account and environment separation
designing for a failure domain you do not control

How people fail in this seat

grants a wildcard permission because scoping it was slow
opens a network path for a debugging session and leaves it open
provisions capacity sized for a launch and never revisits it
puts production and staging in one account
assumes a managed service does not fail

What most employers do instead

CV screen for a named cloud and a certification, an interview on service names and their differences, and a scenario question about designing a highly available architecture.

The assessment

About 64 minutes end to end.

The systems it runs in

An AWS multi-account estate under AWS Organizations: an IAM role and policy the candidate writes as JSON, one S3 bucket prefix in the production account, one RDS instance in a private subnet, and VPC security groups standing between the two. The private path has to be established rather than assumed, which is what makes the temporary wide-open inbound rule tempting. t2 reads a Cost and Usage Report export against a one-page architecture description; t3's degradation is reported the way a provider reports one, on a health dashboard, with the data plane healthy and serving throughout.

AWS
AWS Organizations
AWS IAM
Amazon S3
Amazon RDS
VPC security groups
AWS Cost and Usage Report
AWS Health Dashboard
Terraform

Azure, with RBAC role assignments, network security groups, Cost Management and Service Health; or Google Cloud, with IAM policy bindings, VPC firewall rules and a Cloud Billing export. AWS is the default because the Stack Overflow Developer Survey 2025 reports it as the most used cloud platform, not because the competency is AWS-specific: over-scoping a role because a broad one already exists, opening an inbound rule to prove connectivity and leaving it open, and confusing the control plane with the data plane are the same three failures on all three providers.

Working speed is not scored. t1 puts a visible countdown in front of the candidate for exactly one reason, which is to make the wildcard role tempting. It closes the ticket in about four minutes against most of the window for the scoped one, and both close the ticket. Scoring speed would rank the grant that is unsafe in a year above the one that is not — the specific observation this fixture exists to make. The clock is a fixture element, not a criterion.

What the candidate actually does

Task	What happens
The access request with a clock on it coding_sandbox · 22 min	A monitored sandbox holding a small multi-account estate. The ticket is routine — a new reporting service in the analytics account needs an IAM role that reads one prefix of one S3 bucket in the production account and connects to one RDS instance. Two fast paths are deliberately available and neither is hidden. An existing broadly-scoped role already has the access and can simply be reused. The managed administrator policy is two clicks away. The database sits in a private subnet, so proving connectivity is easier if a security group rule is opened wide for a moment. A visible countdown is shown to the candidate throughout, and the brief says the reporting team is waiting. The fork. The wildcard role plus a temporary open rule closes the ticket in about four minutes and works. A role scoped to the actions, the bucket prefix and the one database, reached through a private path, takes most of the window. Both close the ticket. Only one of them is still safe in a year, and the sandbox records which was chosen and whether anything opened for testing was closed again before the session ended.
Where the money goes data_task · 12 min	A Cost and Usage Report export for the same estate covering the last three months, alongside a one-page architecture description. The candidate names the largest lines, identifies which of them is growing without anyone having decided anything, and says what they would cut first and what that would cost operationally. One large line is a load-bearing always-on cluster. Another, smaller but compounding, is cross-region replication egress plus a snapshot schedule with no expiry that nobody has looked at since it was created. The fork. Attacking the biggest number is arithmetically obvious and takes out capacity the business depends on. Finding the line that is large, growing and useless requires reading the export against the architecture rather than sorting it descending.
The control plane is degraded judgment_scenario · 10 min	The provider's health dashboard reports the region's control plane as degraded. Instances are healthy and serving. Autoscaling is not responding, deployments do not complete, and new resources cannot be created. Traffic is normal now and a marketing push lands in four hours. The candidate says what still works, what the organisation should stop doing immediately, whether to fail over, and what they tell the business. The fork. Declaring a full outage and initiating a regional failover feels decisive and requires exactly the control plane that is unavailable, which converts a degradation into an outage. Freezing all change, pre-warming capacity while it can still be created if any headroom remains, and communicating a specific inability rather than a general one is the answer that survives contact with the failure.
The change note written_artifact · 8 min	The candidate writes what the next engineer reads — what access was granted, what that access actually permits, what was opened temporarily and whether it was closed, and what they would tighten given another hour. The fork. Recording the ticket number and the resource name is what most change notes contain and tells a future reader nothing about blast radius. Writing what the grant permits, including the things it permits that nobody intended, is the note that prevents the next incident.
Enumerate your own blast radius live_call · 12 min	A conversation about the candidate's own estate changes. You granted this policy — list what it actually allows, not what you meant it to. This rule you added to test connectivity, is it still there? If this role's credentials leaked tonight, what is reachable? In your cost analysis you would cut the snapshots — how much, and what breaks if someone needs a restore from four months ago?

The mark scheme

Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.

Scopes access to the work rather than to the ticket closingweight 0.3Scopes actions, resource and condition, states aloud which dimension was hardest and why, and can enumerate on request what the grant still permits be…

1 Reuses the broad role or attaches the managed administrator policy, and in the session review describes the access in terms of what the service needs rather than what the policy permits.

3 Writes a narrower policy but leaves a wildcard in one dimension — all actions on one resource, or one action on all resources — and does not flag which dimension is loose.

5 Scopes actions, resource and condition, states aloud which dimension was hardest and why, and can enumerate on request what the grant still permits beyond the intended use.

Leaves nothing temporary behindweight 0.2Announces the temporary change as temporary at the moment of making it, closes it as soon as the test passes, and records both in the change note with…

1 Opens a network path or a permission to test, never closes it, and does not mention it in the change note or the review.

3 Closes what was opened but only at the end, with no record that it existed.

5 Announces the temporary change as temporary at the moment of making it, closes it as soon as the test passes, and records both in the change note without being asked.

Treats cost as a consequence of technical decisionsweight 0.2Separates load-bearing spend from accumulated spend, names the line that grew because nobody decided anything, quantifies roughly, and states the oper…

1 Sorts the export descending and recommends cutting the largest line, without reference to what it serves.

3 Identifies the compounding line correctly but cannot say roughly what removing it saves or what it would cost to be wrong about it.

5 Separates load-bearing spend from accumulated spend, names the line that grew because nobody decided anything, quantifies roughly, and states the operational risk of the cut alongside the saving.

Reasons about a failure domain it does not controlweight 0.15Names what continues to serve, names the specific capabilities lost, freezes change, addresses the four-hour traffic event with the capacity that can …

1 Treats the degradation as a binary outage, or proposes an action that requires the unavailable control plane to execute.

3 Correctly distinguishes control plane from data plane but gives a generic response rather than saying what specifically stops working in this estate.

5 Names what continues to serve, names the specific capabilities lost, freezes change, addresses the four-hour traffic event with the capacity that can still be secured, and communicates a precise inability rather than a vague one.

Writes down what it did, including the parts that reflect badlyweight 0.15States what the grant permits, records the temporary change and its closure, and names the specific thing they would tighten and why they did not.

1 Change note records what was done in resource names only, and omits the temporary rule or the breadth of the grant.

3 Accurate and complete on actions taken, silent on what would be improved with more time.

5 States what the grant permits, records the temporary change and its closure, and names the specific thing they would tighten and why they did not.

How it is scored

Weighted mean of the five criteria, each scored 1 to 5 against the anchors, reported with the artefact excerpt that earned it. Two raw observations are reported alongside the scores rather than folded into them — the final permission document produced by the candidate, verbatim, and the list of every network rule and permission that existed at session end but not at session start. Those two together let a hiring manager form their own judgement about blast radius without trusting the rubric.

Integrity

monitored sandbox in which AI assistance is available and its use is recorded as part of the session rather than treated as misconduct
the estate is instance-specific, so a correct general policy retrieved from anywhere still has to be scoped to accounts and resources that exist only in this session
scoring rests on the difference between the estate's state at the start and at the end, which is a property of what was done rather than of what was written
session-review questions are generated from this candidate's own grants and rules
no claim is made that undisclosed assistance is detected; reviewers score the estate diff and the conversation, and are instructed not to infer authorship from writing style or from speed

The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.

What you receive

full console and shell transcript with timestamps
diff of every identity policy and network rule between session start and end
the candidate's cost analysis and recommendation
written change note
recording and transcript of the session review
per-criterion score with the excerpt that earned it

Who decides

Recommended. A reviewer with cloud operations experience is given the permission diff before the scores and asked one question in writing — if these credentials leaked tonight, what is reachable? — then confirms or overrides the first two criteria against their own answer. The override that matters most here is the inverse case the rubric handles badly: a candidate who took the broad role deliberately, said so at the time, and wrote a change note explaining that the ticket needed closing today and the policy needed narrowing this week. That is a defensible engineer, and a mechanical score will rank them with the person who did not think about it.

What this does not measure

The permission and cleanup criteria measure a disposition observed once, under a visible countdown, in a session the candidate knows is being watched. That is a meaningfully weaker claim than the design might appear to make. Permission sprawl in a real estate is the accumulated result of a hundred decisions taken over a year while nobody is watching and three other things are on fire, and no single session establishes what someone does on the ninetieth repetition. Treat a strong score as evidence that the candidate knows what good looks like and chose it under mild pressure; do not treat it as evidence about sustained habit, and do not treat it as evidence about on-call temperament or about behaviour in a genuine multi-hour outage with real money moving, neither of which this design observes at all. Cloud-specific cautions matter here more than elsewhere. The estate must be run in the provider the candidate declared, because scoring identity design while someone navigates an unfamiliar console measures console familiarity and systematically disadvantages competent engineers whose experience is in another cloud — which in practice correlates with region and employer history rather than with ability. The cost task must not require currency or locale conventions the candidate has no reason to know. The countdown itself is a stressor and should be removable on request as an adjustment, applied before the session and not surfaced to the reviewer, with the scored variable remaining which path was taken rather than how fast. Monitor score distributions by declared cloud, by region and by requested adjustment, and read any consistent gap as a defect in the scenario.

This role sits next to DevOps in tooling and diverges completely in what a bad day looks like. A DevOps failure is an event — a change goes out, something breaks, someone notices within the hour. A cloud infrastructure failure is a state. The wildcard policy granted in March does nothing at all until a credential leaks in November, and the snapshot schedule with no expiry does nothing except cost money quietly for two years. Neither has an error signal attached. That absence is the single most important fact about hiring for this seat, and it dictates the entire design: the assessment scores what the candidate left behind, not what they produced.

Hence the estate diff. At session start the sandbox records every identity policy and every network rule; at session end it records them again, and the difference is the primary artefact. It is a more honest instrument than any submitted document, because it is indifferent to how well the candidate writes and completely sensitive to what they actually did when a countdown was running and a colleague was notionally waiting. The countdown is not decoration. Scoping a policy properly is not intellectually hard; it is tedious, and the entire question is whether someone does the tedious thing when nobody would know. A sandbox with no time pressure removes the only variable worth measuring.

The cost task is the piece that separates this design most sharply from the other three in the family, and it is deliberately a data task rather than a discussion. Anyone can say the right things about cost awareness. Reading an actual export against an actual architecture and identifying which line is load-bearing and which line is sediment is a different act, and it has a clean wrong answer available: sort descending, recommend cutting the top row. The top row is the cluster the business runs on. The correct finding is smaller, compounding, and requires holding the architecture in mind while reading the numbers — which is exactly the skill that keeps a cloud bill from doubling without a decision ever having been made.

The control-plane scenario earns its place because it is the failure shape that certification material barely mentions and that real estates encounter regularly. Most candidates have a rehearsed answer about multi-region architecture. Very few have thought about the case where their instances are perfectly healthy, their customers are being served, and they simply cannot create anything or complete a deployment. The trap is that decisive-sounding action — declare an outage, fail over — depends on the capability that is missing, and executing it converts a degradation the customers have not noticed into an outage they will. What the design is looking for is someone who enumerates before acting, freezes change, and tells the business a specific thing rather than a frightening one.

The change note and the session review close the loop on the same theme. The question "list what this policy actually allows, not what you meant it to allow" has no general answer; it can only be answered by the person who wrote it, and it cannot be answered at all by someone who pasted a policy that worked. A candidate who can enumerate their own blast radius out loud is demonstrating the habit that the whole role rests on.

What this design does not measure is architecture at the scale where the decisions get genuinely hard — multi-year platform strategy, vendor commitment, organisational design of account boundaries across many teams. Those are judged over quarters and in rooms, not in an hour, and this assessment should be sold as what it is: a reliable read on whether someone does the careful thing when the fast thing is available and the clock is visible.

Sources

Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.

Stack Overflow, 2025 Developer Survey, Developers section, roughly 49,000 respondents worldwide, developer-type question answered by 43,560, https://survey.stackoverflow.co/2025/developers
Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development, 24 September 2025, vendor-run survey of nearly 5,000 technology professionals worldwide, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
Uptime Institute, Annual Outage Analysis 2026, press release, survey of data centre and IT operators, https://uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2026

See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.

Read a sample report Or talk to us about this role