Design an enterprise cloud landing zone

WHAT THIS TESTS This checks whether you can build a secure, governed foundation that scales to many teams while preventing them from making unsafe choices, the core idea of a landing zone.

A GOOD ANSWER COVERS Account structure: use a multi-account or multi-subscription model under an organization, separating workloads and environments to limit blast radius, isolate billing, and apply policy at scale. Identity: centralize on a single identity provider with SSO, federate access into accounts through roles, enforce least privilege and MFA, and forbid sharing root or long-lived keys. Networking: a hub-and-spoke topology with a shared connectivity hub for VPN, DNS, and inspection, and segmented spokes per workload. Security guardrails: preventive controls with service control policies or Azure Policy, plus baseline IaC and continuous compliance scanning so teams cannot disable encryption or open the world. Logging and monitoring: aggregate all audit logs, flow logs, and metrics into a dedicated, tamper-resistant logging account with alerting. The goal is safe self-service: teams build freely inside guardrails.

COMMON WRONG ANSWERS One shared mega-account with everyone in it. Granting teams admin or root. No preventive policy, relying on after-the-fact cleanup. Scattered, deletable logs. Hand-built networking with no segmentation.

LIKELY FOLLOW-UPS Preventive versus detective controls? How do you onboard a new team quickly? How do you stop log tampering? How do SCPs differ from IAM policies?

ONE CONCRETE EXAMPLE Using AWS Control Tower, you stand up an organization with separate accounts for security, logging, shared networking, and each workload. SCPs forbid disabling CloudTrail or creating public S3 buckets. IAM Identity Center federates SSO logins to scoped roles. A transit gateway connects spoke VPCs to a shared hub, and all CloudTrail and config logs flow to a locked-down logging account, so a new team gets a pre-baked, compliant account on request.