We are moving from one shared cloud account to a proper multi-account setup. Design the landing zone.
What they are really testing: They are testing whether you understand account or subscription boundaries as blast radius and billing boundaries, not just as folders. They also want to know if you can onboard teams at speed without hand crafting each one.
A real interview question
We are moving from one shared cloud account to a proper multi-account setup. Design the landing zone.
What most people say
drag me
“I would create separate accounts for dev, test, and prod, use organisations, and apply service control policies. Then I would peer the VPCs together so everything can talk.”
Three accounts is a starting point, not a landing zone, and full mesh peering quietly recreates the single blast radius they were trying to escape. It also ignores account provisioning, IP planning, identity, and who pays for what.
The follow-ups they ask next
How do you keep a baseline consistent across 200 accounts that already exist?
Talk about drift detection, organisation level policies that cannot be turned off locally, and a per account baseline stack that is redeployed by pipeline, not by hand.
A team wants direct internet egress from their account. What do you say?
Do not just say no. Explain the centralised egress model, the audit reason, and offer the exception path with a documented owner.
How do you handle shared data between accounts?
Resource policies and private endpoints over peering everything, plus a named data owner per dataset.
What the interviewer is listening for
- States the account boundary rule out loud and justifies it
- Plans IP addressing before drawing any network
- Automates account creation and gives a provisioning time target
- Admits the operational cost of account sprawl and gives a revisit trigger
What sinks the answer
- Full mesh peering or a flat network that rebuilds the shared blast radius
- No account factory, so every account is hand built
- Long lived access keys instead of federated identity
- Cannot say who pays for an account or who owns it
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 have not designed a landing zone from scratch, but here is how I would reason about it: I would first decide what earns its own account, then automate account creation with a baseline, and I would plan IP ranges early because that is the part you cannot easily undo.”
Keep going with system design
Mid
Design a log and metrics ingestion pipeline for a platform with about 200 services. Engineers need to search logs and alert on metrics.
Mid
Design an image upload and processing service for a marketplace app. Users upload photos from their phone, and we need thumbnails and a moderation check before the listing goes live. Walk me through it.
Senior
Design an event-driven order processing system for an e-commerce site. Payment, inventory, and shipping are separate services.
Senior
Design an analytics pipeline that produces a daily report for the leadership team by 8am. The data comes from a production database and a stream of app events.
Senior
Design a system that must never lose a message. It ingests payment notifications from a partner and each one must be processed exactly once.
Senior
We have about 50 product teams and every one of them has rolled their own pipeline. Design a CI/CD platform that all 50 can use. Take me through it.
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