August 20, 2026·6 min read
Ask a cloud engineering candidate to explain the difference between an IAM role and a policy. They will get it right. Everyone gets it right. It is on the first page of every study guide.
Now think about the last expensive mistake your team made with infrastructure. It was probably not caused by someone not knowing what a role is. It was a plan nobody read properly, a state file that stopped matching reality, a module with a default that was fine in staging, or a bill that grew for four months before anyone looked.
Those are the things to interview for, and none of them fit in a quiz.
Because it is easy to grade and it feels technical. You ask twelve questions, you count correct answers, everybody feels the process was rigorous.
The problem is that infrastructure knowledge is the cheapest thing on the list. Someone can learn what a security group is in an afternoon. What takes years is the judgment about what to do when the plan output does not look like what you expected, and that judgment is exactly what a quiz cannot reach.
So put them in front of a terminal.
The setup. A small stack, already applied. Someone has changed a resource by hand in the console since. terraform plan now shows something confusing.
Ask: what happened here, and what do you want to do about it?
Strong looks like: they read the plan carefully before touching anything. They can tell the difference between "Terraform wants to fix drift" and "Terraform has lost track of a resource." They talk about import or state rm as deliberate options with different consequences, and they say out loud what would happen to the real resource in each case.
Weak looks like: running apply to make the noise go away. Or reaching for state rm without knowing it leaves the real resource alive and unmanaged, which is how you end up paying for things nobody owns.
Why it works: drift is the most common real Terraform situation and it never appears in tutorials.
The setup. A change that looks small in the diff, but the plan says one resource will be destroyed and recreated. Something like a change to an attribute that forces replacement, on a resource holding data.
Ask: review this change and tell me whether you would apply it.
Strong looks like: they read the plan output rather than the diff. They spot forces replacement and they know which resources cannot survive that. They ask about backups and about whether this is a production workspace. They propose a way to make the change without the replacement, or they say plainly that it needs a maintenance window and a restore plan.
Weak looks like: approving it because the code change looks harmless. This is a genuine, common, expensive incident, and it is almost entirely a reading skill.
Why it works: it is the closest thing infrastructure has to a code review test, and it is the single best predictor we know of for whether someone will break production.
The setup. An internal module that other teams use. It has a default that is reasonable in a test account and wrong in production: a public ingress rule, an unencrypted volume, a retention period of one day, deletion protection off.
Ask: we are about to make this the standard module for every team. Anything you would change?
Strong looks like: they read the variable defaults, not just the resources. They think about the person who will use this module without reading it, and they argue for safe defaults with an explicit opt-out. They may also flag missing tags, no version pinning, or no way to tell which team owns what.
Weak looks like: reviewing only what the module creates and not how it will be used.
Why it works: it is a judgment task disguised as a review. It tells you whether someone thinks about the people downstream of their work, which is most of what platform engineering is.
The setup. A real cost report, anonymized. A few months of data with something obviously growing.
Ask: where is the money going, and what would you do first?
Strong looks like: they find the largest line and the fastest-growing line, and they know those are different questions. They connect spend to architecture: this is data transfer between zones, that is a storage class never transitioned, this is an environment somebody forgot to shut down. They are careful about what is safe to change, and they suggest a guardrail so it does not come back.
Weak looks like: generic advice. Buy reserved instances. Rightsize the instances. No reference to what the report actually shows.
Why it works: it is the strongest seniority signal on this list. Cost is where architecture, operations and business awareness meet, and there is no way to fake having looked at a bill before. It also has no single right answer, which makes it a good conversation and a hard thing to memorize.
If you want the fuller version of the cost side, we wrote cloud cost optimization and stop paying for idle servers.
Four rows, same for every candidate:
Notice that none of those rows is "knows Terraform syntax." Syntax shows up for free while they work, and it is the part that is cheapest to learn.
These tasks need real state, real plan output and a real place to run commands. A plan you paste into a document is a reading comprehension exercise, which is worth something but is not the same thing.
EasyEnv gives the candidate a real Linux machine with Terraform installed, the stack already applied, the drift already introduced, and the module already in the repo. Every candidate gets the same starting point because it is provisioned from the same recipe, so the drift is identical each time and you can compare people fairly. Boxes are disposable, so a candidate with full access is not a risk. The session is recorded, terminal and screen, so you can see whether they read the plan output or scrolled past it.
The limits, plainly. You need a place for a real cloud account or a convincing local stand-in, and setting that up is real work. Reviewing these sessions needs someone who knows infrastructure. And if you are hiring for a role where the person will never touch production, this is more interview than you need.
Stop asking what an IAM role is. Put a confusing plan, a drifted state file, a permissive module default and a real bill in front of the candidate, and watch what they read first.
If you only run one, run the destructive plan. Whether someone notices "forces replacement" on a database before approving is the cheapest, sharpest signal in cloud hiring.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Frontend hiring rewards polish, which is visible, and misses the things that hurt later. Here are tasks inside an existing React and TypeScript codebase that surface what a portfolio never shows.
Most ML interviews test modeling, which is the part that goes well anyway. Here are the skills that decide whether a model reaches production, and a real-environment task for each, including the LLM engineer variant.
Read more
Timers, proctoring, no-docs rules and think-aloud requirements filter for things you never meant to test. Here is what each one actually measures, the replacement that keeps the difficulty, and how to offer accommodations without a negotiation.
Read more
