Free SAA-C03 practice questions: Secure Architectures

Design Secure Architectures is 30% of the SAA-C03 — the largest of the four domains, and the one where preparation pays off most predictably. Not because the services are exotic, but because the questions follow patterns. Learn the patterns and the domain becomes the most scriptable part of the exam; skip them and every scenario feels like a coin flip between four plausible options.

Least privilege is the grading rubric

If the SAA-C03 has one reflex it rewards above all others, it is this: when two options both work, the one that grants less wins. An option that hands out AdministratorAccess, shares a credential between parties, or opens a resource wider than the scenario demands is wrong even when it would function perfectly. The exam is not asking “would this work?” — it is asking “is this the tightest design that meets the requirement?”

That reframing changes how you read. The scenario paragraph is scenery; the requirement sentence is the question. “Access must be auditable” is not colour — it is the sieve that eliminates three options. “No long-term credentials may be stored” kills every answer containing an access key, however cleverly that key is hidden. Underline the constraint clause before you look at the options, and most secure-architecture questions shrink from four candidates to two.

Roles, not keys — the most reliable answer pattern in the domain

Whenever compute needs to call an AWS service — EC2 to DynamoDB, Lambda to S3, one account into another — the answer is an IAM role delivering temporary credentials, essentially without exception. Access keys in a config file, in user data, in environment variables, in an “encrypted file we download at boot”: all of these are the same wrong answer wearing different costumes. They store a long-term secret, they need manual rotation, and they blur the audit trail.

Roles invert every one of those weaknesses. Credentials are short-lived and rotated automatically, nothing sits on disk, and every assumption is a CloudTrail event with a name attached. The pattern extends across accounts: when account B needs access to a resource in account A, the answer is a role in A with a trust policy naming B, assumed through STS — revocable with one edit, auditable per assumption. If an option says “share the access keys with the other team,” you may reject it before finishing the sentence.

One evaluation rule belongs in the same reflex set: an explicit deny beats every allow, from any policy, at any attachment point. IAM pools all applicable policies into a single evaluation; there is no precedence between user, group and role policies, and no recency rule. Deny wins. Always.

Stateful or stateless: one distinction, many questions

Security groups and network ACLs guard different perimeters with different memory. A security group is stateful: allow the inbound request and the response flows back automatically, no return rule needed. It attaches to the resource itself, and it can only allow — there is no such thing as a security group deny rule. A network ACL is stateless: it evaluates every packet in both directions independently, so an inbound allow does nothing for the response unless an outbound rule covers the ephemeral ports. It sits at the subnet edge, and it is the only one of the pair that can express an explicit deny.

That gives you a clean decision rule. Blocking a hostile IP range? Only a NACL can say deny. “Responses must return without additional rules”? That is the definition of stateful — security group. Most questions in this area are one of these two sentences dressed up in a scenario.

Encryption questions are requirement-matching, not cryptography

The exam never asks you how AES works. It asks which key arrangement matches a compliance sentence. All the S3 encryption modes produce ciphertext at rest; they differ in who holds the key and what gets logged. SSE-S3 is fully managed and invisible — fine when the requirement is just “encrypted at rest,” and immediately wrong the moment the scenario mentions auditing key usage, controlling rotation, or writing a key policy. Those three phrases all point to SSE-KMS with a customer managed key, because a customer managed key is the only option that logs every use to CloudTrail and puts policy and rotation in your hands. SSE-C and client-side schemes appear as distractors whose tell is operational burden: supplying a key on every request, or worse, a key living in application code — which is just a stored credential by another name.

Defense in depth: the architecture behind the answers

The diagram above shows the layering that most secure-architecture scenarios silently assume. A request from the internet meets the edge first — Route 53 resolves it, CloudFront serves it, and AWS WAF filters it before it ever reaches your infrastructure. What survives crosses the VPC boundary, passes the subnet’s network ACL, then the security group ring directly around the instance. And running alongside every one of those layers are the two controls that touch everything: IAM deciding who may do what at each layer, and KMS governing the keys that protect data wherever it rests.

The exam builds questions at the seams between these layers — which layer can deny, which layer is stateful, which control produces an audit trail. Answer the seven questions below one at a time, and read each explanation past the correct letter: the “why not the others” is where the domain is actually learned, because on exam day the three wrong options will not introduce themselves.