The org is moving to many cloud accounts across many teams. How do you design the multi-account landing zone and guardrails so teams move fast safely, instead of locking everything down or letting it become the wild west?
What they are really testing: Whether you can balance autonomy with control using preventive and detective guardrails as code, and whether you design governance that scales without a central team approving every change.
A real interview question
The org is moving to many cloud accounts across many teams. How do you design the multi-account landing zone and guardrails so teams move fast safely, instead of locking everything down or letting it become the wild west?
What most people say
drag me
“I would set up an organization with separate accounts, apply service control policies to restrict what teams can do, and have the central cloud team review and approve new accounts and any policy exceptions.”
The structure is fine but it centralizes approval, which becomes a bottleneck at scale. It also leans entirely on prevention and a gate, missing self-service, detection, and the autonomy that makes teams move fast.
The follow-ups they ask next
A team needs an exception to a guardrail to ship an important feature. How does that work without you becoming the bottleneck?
Listen for a documented, time-boxed exception path with an owner, not ad hoc approvals funneling through one person.
How do you roll out a new guardrail across hundreds of existing accounts without breaking running workloads?
Listen for detect-first, warn, then enforce, with staged rollout and communication, rather than a flip-the-switch deny.
What the interviewer is listening for
- Uses account boundaries to contain blast radius
- Expresses controls as policy-as-code guardrails rather than manual gates
- Combines preventive and detective controls deliberately
- Makes the secure baseline the default via account vending and self-service
What sinks the answer
- Routes every account or exception through a central approval team
- Relies only on prevention, with no drift detection
- Treats security as a follow-up ticket rather than a baked-in baseline
- Locks teams down so hard they route around the controls
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I would structure accounts by [team and environment] to limit [blast radius], then govern at the boundary with [policy-as-code guardrails] instead of [manual gates]. I combine [preventive] and [detective] controls, vend new accounts with a [secure baseline] built in, and make provisioning [self-service within guardrails] so governance scales without [a central bottleneck].”
Keep going with architecture & design
Junior
How does putting a load balancer in front of your app improve availability, and what does it NOT solve?
Junior
What is autoscaling, and how does it decide when to add or remove instances?
Senior
Design a highly available web application on AWS. Walk me through the architecture and your trade-offs.
Senior
Design a disaster recovery strategy for a revenue-critical workload on AWS. How do you pick between backup-and-restore, pilot light, warm standby, and active-active?
Senior
Design a scalable async processing pipeline for spiky, long-running work (think video transcoding or report generation). Walk me through the queue-based architecture and its failure modes.
Senior
You own a system of many services and an incident took too long to diagnose. Design an observability strategy across the whole estate.
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free