Infrastructure map — where every service actually sits
Four diagrams to fix the spatial mental model the mocks turn on: what scope a service lives at, how a landing-zone Organization is arranged, what goes where inside a VPC, and how a request threads through the whole thing from an internet client all the way to a data store — with the on-prem side wired in.
Container / boundary
Logical scope (Global, AZ, OU)
Highlighted / shared
Main data path
One-way exposure (PrivateLink)
Control / trust / audit
01 Scope containment — global → region → AZ → subnet
The single biggest source of confusion in the mocks. Everything AWS runs sits inside exactly one of these bands, and the band decides what a resource can and cannot reach. Read outside-in.
A resource can only reach things at its own scope or wider. An EC2 instance in a private-app subnet in AZ-a can hit S3 (regional, via a gateway endpoint), the RDS primary in AZ-a's data subnet (VPC), and the internet through NAT-a (AZ) — but its EBS volume cannot move to AZ-b, and its subnet does not exist in the other two AZs.
02 Multi-account landing zone — how accounts talk
A typical AWS Organization. The Management account never runs workloads — it authors the guardrails and pays the bills. Everything else lives in Organizational Units below it, and the interesting arrows are the cross-account patterns: RAM (share subnets), PrivateLink (expose one service one-way), and the Organization CloudTrail that collects every account's audit log.
Nesting shows scope: everything inside the SCP-guardrail box is subject to policies the Management account writes. Cross-account trust is always explicit — an IAM role in the target account with a trust policy naming the source. PrivateLink exposes one service one-way (never opens a route); RAM shares subnets so workload compute sits inside a network the Shared Services account owns. The Log Archive bucket uses S3 Object Lock in Compliance mode — root itself cannot shorten retention.
03 VPC anatomy — the standard 3-AZ layout
One VPC, three AZs, three subnet tiers per AZ. This is the shape almost every exam scenario assumes without saying so. The interesting placements: ALB spans public subnets across all AZs, RDS Multi-AZ pins a primary in one AZ and a hidden sync standby in another, EFS puts a mount target in every AZ, and the S3 gateway endpoint is the way to avoid NAT data charges for S3 traffic.
ALB is one object with targets in every AZ, so a single URL survives the loss of one AZ. RDS Multi-AZ hides its standby — you never point traffic at it; failover reuses the primary's endpoint. Instances in a private-app subnet reach S3 through the S3 gateway endpoint — traffic never leaves the AWS network and skips NAT data charges. EBS volumes live in exactly one AZ; instance store dies with the instance.
04 Request path — internet to database, with on-prem wired in
Follow one HTTPS request from a mobile client all the way to a table row, and follow one on-prem query in through Direct Connect at the same time. Every decision the mocks care about — where WAF attaches, why Global Accelerator beats DNS for blue/green, why the private-DNS lookup needs a Route 53 Resolver inbound endpoint — is a hop on this line.
Two paths, same destination. The mobile client goes through Route 53 and one of the two edge accelerators — CloudFront (cacheable HTTP, WAF/Shield attach here) or Global Accelerator (UDP, non-cacheable, when DNS caching would defeat a Route 53 traffic shift). The on-prem client goes over Direct Connect through a DX Gateway into a Transit Gateway, then out to the same VPC. WAF sits wherever the traffic first enters AWS — on CloudFront for the internet path, on the ALB when there is no CloudFront in front. Between compute and slow work, always SQS. Between compute and S3/DynamoDB, always the gateway endpoint.