IAM is the foundation of the SAA-C03’s largest domain, and its scenarios reward a small number of reflexes rather than memorised JSON. The exam is not asking you to write policies — it is asking you to recognise which mechanism a requirement calls for, and to apply the evaluation rules the same way AWS does.
Roles, not keys — the reflex the exam rewards most
When the caller is an AWS resource — an EC2 instance, a Lambda function, an ECS task — the answer is almost always an IAM role, never a stored access key. A role delivers temporary credentials that rotate automatically and never sit in a file waiting to leak. Any option that stores a long-lived key, however cleverly hidden in user data or an environment variable, is solving the wrong problem. Read the caller first: if it is a service, reach for a role before you read the rest of the options.
How IAM decides: the evaluation rule
The diagram above is the whole game. IAM gathers every applicable policy — identity-based, resource-based, permissions boundaries, service control policies — and applies two rules in order:
- An explicit Deny anywhere overrides everything. If any policy denies the action, it is denied.
- Otherwise the request is allowed only if at least one policy explicitly allows it; with no allow, the default is deny.
That is why a user with a group allow and a personal explicit deny is denied — the deny wins. Policies do not have precedence by attachment point, and evaluation is not order-dependent: everything is combined, then the deny rule decides.
Least privilege is a scoring pattern, not a slogan
On a security-domain question, the most-scoped option that still satisfies the requirement is almost always correct. Grant the one action on the one resource the workload actually uses — s3:PutObject on a specific prefix, not s3:*, not "*", not a broad managed policy “so it can grow later”. The distractors deliberately offer convenience in exchange for blast radius, and the exam consistently marks that trade wrong.
Capping delegated power: permissions boundaries
When the requirement is that someone can create identities but those identities must never exceed a fixed ceiling, the answer is a permissions boundary. Effective permissions are the intersection of the boundary and the identity’s own policies, so nothing a delegated developer writes can break through it. Distinguish it from a group (which grants, not caps) and from detective tools like Access Analyzer (which report after the fact rather than prevent).
Conditions and temporary credentials
Two more patterns close out the common set. A Condition — like requiring aws:MultiFactorAuthPresent — is part of whether a statement applies at all; if it is not met, the allow simply does not fire and the request falls to the default deny. And for time-limited access, assuming a role for short-lived AWS STS credentials beats any permanent key. Both reduce to the same instinct: prefer the mechanism that expires or scopes access automatically over the one you have to babysit.
How to use the six scenarios below
Answer each one before opening the explanation, and when you miss, find the requirement word that decided it — “automatic”, “temporary”, “never exceed”, “only that prefix”. Every explanation names the deciding constraint and then takes the distractors apart one by one. The services here are familiar; the skill the exam tests is choosing the right one under the exact requirement, which is what the reasoning below drills. For the domain overview, see Design Secure Architectures.
Updated for SAA-C03 (July 2026). The sample questions above are our own work
in the style of the exam — not real exam items. The exam itself is set and marked
by the certification body.