Pair your devices with a code and playback position follows you: pause on this device, hit resume on the other. Position is saved to the site every minute and on pause.
Open this panel on your other device and enter the same code.
The quiz tests recall. This rehearses speech. Read the answers out loud. Nothing here should take more than 90 seconds to say.
Fundamentals questions are where interviewers calibrate. They're not hard — which is the point. What they're listening for is precision: "one or more data centers", not "a data center"; "guest OS", not "the OS"; "control plane in one Region", not "global so it can't fail". Loose answers here make every later answer sound loose too.
"What is cloud computing?"
AWS's definition is the on-demand delivery of IT resources — compute, storage, databases, applications — over the internet with pay-as-you-go pricing. The provider owns and maintains the hardware; you provision and use what you need.
If they want the formal version, NIST's definition has five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. Every phrase in AWS's definition maps onto one of those.
The follow-up they ask next: "And the benefits?" I'd give AWS's six advantages — variable instead of fixed expense, economies of scale, stop guessing capacity, speed and agility, stop running data centers, go global in minutes — and I'd be careful to say those are advantages, not the NIST characteristics. People merge the two lists.
"What's the difference between a Region and an Availability Zone?"
A Region is a separate geographic area, designed to be isolated from every other Region. An Availability Zone is one of several isolated locations inside a Region — and it's one or more discrete data centers with independent power, networking and connectivity, connected to the other AZs by low-latency dedicated fiber.
The practical difference: AZs are close enough to replicate synchronously, which is what Multi-AZ RDS does. Regions are far enough apart that AWS doesn't offer synchronous cross-Region replication at all.
"IaaS, PaaS, SaaS — where's the line?"
The operating system. In NIST's definition, the IaaS consumer controls the OS; the PaaS consumer doesn't. EC2 is IaaS — the guest OS is mine. RDS is further up — AWS runs the OS and I manage the database through its interface.
And that same line is the Shared Responsibility Model. Whoever manages the OS patches it.
"Explain the Shared Responsibility Model."
AWS is responsible for security of the cloud — hardware, facilities, network, and everything from the host operating system and virtualization layer down. The customer is responsible for security in the cloud, and how much that is depends on the service.
On EC2 I own the guest OS, patches, installed software and security groups. On S3 AWS runs the OS and platform, and I own my data, its encryption options, its classification and the IAM permissions. What never moves across any service is data, permissions and encryption choices — those are always mine.
"Is IAM a single point of failure? It's global."
It depends which half you mean. AWS's Fault Isolation Boundaries whitepaper describes IAM as partitional:
there's an isolated data plane in every Region, so authenticating and authorising requests keeps working
Region by Region. But the control plane — creating and changing roles and policies — is in us-east-1.
So IAM isn't a single point of failure for using roles. It is one for changing them. Which is why the whitepaper calls out creating or updating IAM resources during a failover as an anti-pattern. The DR roles should already exist.
The follow-up they ask next: "Any others like that?" Route 53 and CloudFront — both have control
planes in us-east-1 and data planes spread across points of presence. And a subtle one: S3 is a Regional
service, but CreateBucket depends on us-east-1 because bucket names are globally unique. So a runbook
that creates a bucket during recovery has a hidden us-east-1 dependency.
"How do you decide what a service survives?"
I put it in one of three buckets. If I choose the AZ — EC2, EBS, a subnet — it's zonal, and it survives nothing beyond that AZ; I need a second copy elsewhere. If I only talk to a Regional endpoint — S3, DynamoDB, SQS — AWS has already spread it across AZs, so it survives an AZ; I need a second Region to survive more. And global services have a one-Region control plane I keep out of my recovery path.
I'd be honest that there isn't an AWS table classifying every service. The whitepaper defines the categories with examples, and for anything else I read the service's own docs. And there are exceptions inside services — S3 One Zone-IA and EFS One Zone are zonal storage inside services people think of as Regional.
The follow-up they ask next: "What does 'statically stable' mean?" Having enough capacity already running that losing an AZ doesn't require launching anything. AWS's worked example is six instances needed across three AZs: run three per AZ — nine total — so losing one AZ still leaves six. Fifty percent extra, and you don't depend on the EC2 control plane during the event.
"Two teams in different accounts need workloads in the same AZ. How?"
Use AZ IDs, not AZ names. For older accounts in the oldest Regions, AWS maps AZ names to physical zones
independently per account — us-east-1a in mine might not be us-east-1a in theirs. The AZ ID, like
use1-az1, is the same physical location in every account. AWS changed this for accounts created from
November 2025, but I wouldn't assume which kind of account I'm dealing with.
"On RDS, who patches the operating system?"
AWS performs the maintenance — hardware, OS and engine version. But it's not fire-and-forget. OS updates are either mandatory, with an apply date after which RDS applies them in a maintenance window, or optional — and RDS doesn't apply optional ones automatically. I choose the window, and I'm responsible for applying optional updates if my compliance posture needs them.
The follow-up they ask next: "And Lambda?" With managed runtimes in Auto mode, Lambda applies runtime patches itself. But if you deploy functions as container images, Lambda only publishes updated base images — you have to rebuild and redeploy to pick up patches. Serverless doesn't automatically mean AWS patches everything.
"What makes a subnet public?"
Its route table. A public subnet has a direct route to an internet gateway; a private one doesn't and needs NAT for outbound internet. There's no "public" flag — change the route and the same subnet changes type. Whether instances get a public IP is a separate subnet attribute.
And every subnet lives in exactly one AZ, which is why a highly available layout has a public and a private subnet per AZ.
"What does DNSSEC give you?"
Assurance that a DNS response came from the authoritative source and wasn't tampered with — origin and integrity. I wouldn't describe it as encryption; Route 53's docs describe signing and validation, not confidentiality.
In Route 53 there are two keys. I manage the key-signing key, which sits on an asymmetric KMS key — ECC_NIST_P256, and it has to be in US East (N. Virginia). Route 53 manages the zone-signing key. And enabling signing isn't the end: the DS record has to go into the parent zone to complete the chain of trust.
The follow-up they ask next: "Any operational risk?" Yes — a broken signature can make the zone unresolvable. AWS recommends CloudWatch alarms on the DNSSEC failure metrics, and lowering the zone's max TTL to an hour before enabling, so rollback is quick.
"A healthcare startup in Germany wants to launch on AWS. Walk me through the foundational choices."
Region first, and it's a filter, not a trade-off. If the data must stay in Germany, that picks the Frankfurt Region before latency or price get a vote. I'd also check the Region has every service we plan to use — AWS lists that as the first selection criterion.
Then the account: confirm the Region is enabled — it's one of the older default-enabled ones, but I'd verify rather than assume — and check how many AZs the account can actually use there.
Network: a VPC from RFC 1918 space, sized generously and chosen to avoid overlap with anything we might peer with or connect over Direct Connect later — you can add CIDR blocks but you can't resize one. Public subnets only for load balancers and NAT, private subnets for application and database, one of each in at least two AZs.
Data: S3 and DynamoDB are encrypted at rest by default; RDS and EBS are choices, so I'd turn on EBS encryption by default for the account and create RDS instances encrypted. TLS everywhere in transit.
Responsibility: I'd write down, per service, which side of the line patching falls on — EC2 guest OS is ours; RDS maintenance windows and optional updates are ours to schedule; Lambda container images are ours to rebuild.
And resilience: Multi-AZ from day one for the database, because a single-AZ instance lives and dies with its AZ. Multi-Region only if the business states an RTO that needs it — which in this case also has to respect residency, so any second Region is a legal question before it's a technical one.
"An engineer says, 'I moved the instance to another AZ but its data disk won't attach.'"
EBS volumes are zonal — the volume and the instance must be in the same AZ. The fix is a snapshot of the volume and a new volume from it in the target AZ. Longer term, if data genuinely needs to be reachable from several AZs, that's EFS Regional or S3, not EBS.
"Our DR failover to a new Region failed at the first step."
First thing I'd check: is the Region enabled? Regions introduced after March 20, 2019 have to be enabled
per account. If nobody enabled it, every API call there fails. Then, in order: service quotas in that
Region, whether the runbook creates IAM roles or buckets — both with us-east-1 control-plane dependencies
— and whether it's editing Route 53 records instead of relying on health checks.
"Instances in a 'private' subnet are reachable from the internet."
Then it's not private. I'd look at the route table associated with the subnet — if there's a route to an internet gateway, it's public by definition. Common causes: it was created in the default VPC, whose default subnets are public; or it's implicitly associated with a main route table someone edited. Then security groups and NACLs, which are the second layer, not the first.
"An Availability Zone is a data center." It's one or more data centers. Small error, but it signals you haven't read the definition.
"AWS patches our EC2 instances." AWS patches the host. The guest OS is the customer's, by the model's first paragraph.
"IAM is global, so it can't go down."
Its data plane is Regional; its control plane is in us-east-1. You can lose the ability to change IAM
while still being able to use it.
"S3 is multi-AZ." Most classes are — across at least three. One Zone-IA isn't.
"We'll just resize the VPC later." You can't resize a CIDR block. You can add secondary blocks — if they don't overlap anything.
"DNSSEC encrypts our DNS." It authenticates responses. Route 53's docs describe origin and integrity, not secrecy.
"The five advantages of cloud computing…" NIST has five characteristics. AWS has six advantages. Mixing them tells the interviewer you learned from a summary.
"Should we use Local Zones?"
It depends on three things.
What latency do you actually need, and to whom? Local Zones put compute close to a specific metro area. If users are spread out, CloudFront or a well-chosen Region may be enough. If they're on a 5G carrier network, Wavelength is the more specific answer.
Does the Local Zone support what you need? They support select services, not everything. The docs list constraints — no VPC endpoints in Local Zone subnets, no Site-to-Site VPN — and if the architecture needs those, it has to route through the parent Region.
Is the driver residency? AWS names state and local data residency as a reason to use Local Zones. If that's the real requirement, the Local Zone is a compliance answer before it's a latency answer, and I'd want the compliance team's sign-off on it.
And I'd say one more thing: Local Zones aren't named on the SAA-C03 in-scope list, which is non-exhaustive — so for the exam I'd weight Wavelength and Outposts higher. In a real design, it's a legitimate tool; it's just a narrow one.