IAM roles and STS: SAA-C03 temporary-credential scenarios

How the exam tests roles over long-lived keys — instance profiles, service roles, STS tokens, federation and session policies. Seven scenarios, SAA-C03, 2026 edition.

Try 7 free IAM-roles and STS scenarios in the exam's own style — every answer explained, no sign-up.

Straight to the 7 free questions ↓

IAM roles and AWS STS are the beating heart of the Design Secure Architectures domain, and the SAA-C03 tests them the same way every time: it describes a workload holding a long-lived access key and asks for the pattern that removes it. The correct answer is almost always a role issuing temporary credentials, and the distractors are real mechanisms that solve a slightly different problem.

Roles issue temporary credentials; users hold long-lived keys

An IAM user carries a permanent access key and secret. A role carries nothing permanent: an entity assumes it, and AWS STS mints temporary credentials that expire and rotate automatically. That single difference decides most questions. When the requirement mentions “no stored secret”, “automatically rotated”, or “only valid briefly if leaked”, the answer is a role — a leaked temporary credential simply stops working, while a leaked long-lived key is valid until someone notices and deletes it. The diagram contrasts the two: a compute identity assuming a role via STS on one side, a crossed-out static key on the other.

Instance profiles and service roles

For compute, the role is delivered for you. An instance profile attaches a role to an EC2 instance; the SDK pulls temporary credentials from the instance metadata service and refreshes them, so the application never handles a secret. A service role lets an AWS service act on your behalf — the classic case is a Lambda execution role, which Lambda assumes at runtime to hand your function temporary credentials for DynamoDB, S3 or wherever it writes. Watch for distractors that reach for the network or the resource policy: a security group grants no IAM permissions, and a resource-based policy on a function controls who may invoke it, not what it may do.

What STS actually hands back

When code calls AssumeRole, STS returns three things — an access key ID, a secret access key, and a session token — all stamped with an expiry. All three travel on every signed request; the session token alone is not a credential. Knowing the shape of that response lets you dismiss options offering “a permanent key” or “just a token you reuse forever”. A role’s trust policy, by contrast, decides who may assume it and is never returned to the caller.

Federation and scoping down

Human access follows the same mechanism. With SAML or web identity federation, an external identity provider authenticates the user, who then assumes a role and receives temporary credentials — no per-person IAM user, and access that expires with the session. And when a single call needs to be tighter than the role allows, a session policy passed inline to AssumeRole intersects with the role’s permissions: the session can only be equal to or narrower than the role, never broader. That is the tool for scoping one task down to a single S3 prefix without editing the role or disturbing anyone else who uses it.

The method for these scenarios

Read for the requirement word. “No stored keys” and “automatically rotated” point at a role and STS; “act on your behalf” points at a service role; “temporary credentials” and “session duration” point at AssumeRole; “authenticate through our identity provider” points at federation; “narrow just this session” points at a session policy. The seven scenarios below each turn on one of those constraints, and every explanation names it before taking the distractors apart. For the wider domain, see Design Secure Architectures.

A contrast between temporary and long-lived credentials. On the left, a compute identity — an EC2 instance with an attached instance profile and a Lambda function — calls AWS STS to assume an IAM role. STS returns short-lived, automatically rotated temporary credentials that the workload uses to reach an AWS service such as Amazon S3. On the right, a long-lived IAM access key and secret stored in application configuration is crossed out, marking it as the pattern the exam wants replaced.

7 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 7

A security review of an EC2-hosted application finds hard-coded IAM access keys in a config file on every instance, used so the app can read an Amazon S3 bucket. What should the team use instead?

Answer: A — Attach an IAM role to the instance through an instance profile and let the SDK obtain temporary credentials automatically.

An instance profile delivers an IAM role to the EC2 instance; the SDK retrieves short-lived credentials from the instance metadata service and refreshes them automatically, so no long-lived secret is ever stored on the host. Why not the others: moving the key to environment variables or into the binary still leaves a permanent secret on the instance that can be exfiltrated and never rotates itself. A user-per-instance with a rotation script is exactly the undifferentiated key management the role removes — you are rebuilding by hand what the instance profile does natively.

SAA-C03 Question 2 of 7

A workload runs continuously on AWS and must call several AWS APIs. Security requires that no credential the workload uses stays valid indefinitely if leaked. Why does an IAM role satisfy this better than an IAM user with an access key?

Answer: A — A role issues temporary credentials that expire and are rotated automatically, so a leaked credential is only valid briefly.

A role does not carry a permanent secret. When the workload assumes it, STS mints temporary credentials with a defined lifetime that the SDK renews before expiry, so an exposed credential stops working on its own. Why not the others: roles and users are both bounded by attached policies, so permission ceilings are not the difference. There is no 'encrypted access key' on a role — the whole point is that there is no long-lived key at all. And IAM identities are not billed per call, so cost is irrelevant to the security requirement.

SAA-C03 Question 3 of 7

A Lambda function must write records to an Amazon DynamoDB table. Which mechanism grants the function the permissions it needs to act on your behalf?

Answer: A — A Lambda execution role that the service assumes to obtain temporary credentials for the function.

A Lambda execution role is a service role: Lambda assumes it when the function runs and passes the resulting temporary credentials into the execution environment, so the code calls DynamoDB with no stored secret. Why not the others: putting a user's keys in environment variables reintroduces a long-lived credential the execution role exists to eliminate. A resource-based policy on the function controls who may invoke it, not what the function may do. A security group filters network traffic and grants no IAM permissions at all.

SAA-C03 Question 4 of 7

An application calls the AWS STS AssumeRole API and receives a response. Which set of items does STS return so the caller can make authenticated AWS requests as the role?

Answer: A — An access key ID, a secret access key, and a session token, all with an expiration time.

AssumeRole returns a temporary credential set — an access key ID, a secret access key, and a session token — that expires after the requested duration; all three must be sent on each signed request. Why not the others: the credentials are deliberately temporary, never permanent, which is the mechanism's whole purpose. The session token alone is not usable; it accompanies the temporary key pair. And a trust policy governs who may assume the role — it is not a credential and is never returned to sign requests.

SAA-C03 Question 5 of 7

A company authenticates its employees through a corporate SAML identity provider and wants them to access the AWS Management Console without creating an IAM user for each person. Which approach fits?

Answer: A — Configure identity federation so users assume an IAM role and receive temporary AWS credentials after authenticating with the identity provider.

With SAML (or web identity) federation, the identity provider authenticates the user and the user assumes an IAM role, receiving temporary credentials scoped to that role — no per-person IAM user, and access that expires with the session. Why not the others: creating and syncing an IAM user per employee is exactly the account sprawl federation removes. Sharing one user's keys destroys individual accountability and never rotates. Passwords do not travel inside SAML assertions, and doing so would leak long-lived secrets.

SAA-C03 Question 6 of 7

An application assumes a role that grants broad access to a project's resources, but for one specific task it should be limited to a single S3 prefix — without changing the role's own policies. What lets the caller narrow the permissions for just that session?

Answer: A — Pass a session policy in the AssumeRole call to further scope down the session's effective permissions.

A session policy is passed inline to AssumeRole and intersects with the role's permissions, so the resulting session can only be equal to or narrower than the role — ideal for scoping one call down to a single prefix without touching the role. Why not the others: editing and reverting the role's policy per call is fragile, racy, and affects everyone using the role. A permissions boundary is set on an identity, not supplied per AssumeRole request. And a trust policy decides who may assume the role, not what the session may do to S3.

SAA-C03 Question 7 of 7

A team is deciding how a long-running automated batch job should authenticate to AWS. One engineer proposes creating an IAM user with access keys for the job; another proposes an IAM role. For this machine identity, which is the better default and why?

Answer: A — The role, because it provides temporary auto-rotated credentials with nothing long-lived to store or leak.

A role is the recommended machine identity: the workload assumes it and runs on temporary credentials that rotate automatically, leaving no static secret in code, config, or a secrets store to leak or rotate manually. Why not the others: machine identities do not require a permanent key — that is the outdated pattern being replaced. Roles are explicitly designed for non-human workloads such as EC2, Lambda and batch compute. And the two are not equivalent: a user relies on a long-lived key while a role does not, which is the entire distinction the exam draws.

That is exactly how every question in the course works — answer, explanation, why-not. The real set continues in the practice player: 10 free questions, no sign-up.

Continue with the 10 free questions →

Those 7 questions were the start.

The exam does not test whether you recognise a term — it tests whether you can rule out three plausible answers under time pressure. That is what the explanations above are for, and there are 780 more questions built exactly like them.

Collecting questions yourself

Scattered across forums, of unknown age
Answer keys without reasoning
No idea which domain you are weak in

Practising with a system

780 questions in 12 full tests, SAA-C03 (2026)
Every option explained — including the wrong ones
Readiness per exam domain, and drills for your weakest

Start free — 10 questions

Straight into the player. No account, no email.

Frequently asked questions

Role or IAM user for an EC2 workload — what does the exam expect?

A role, delivered through an instance profile. The application receives temporary, automatically rotated credentials from the instance metadata service, so there is no long-lived access key to store on the host or leak. An IAM user with static keys on the instance is the anti-pattern the exam wants you to replace.

What exactly does AWS STS provide?

AWS Security Token Service issues temporary security credentials — an access key ID, a secret access key, and a session token — with a limited lifetime. AssumeRole, and federation flows for SAML or web identity, all return this expiring credential set, which is why nothing long-lived has to be stored.

Are these real exam questions?

No. They are original scenarios written for this page in the exam's style and difficulty. Reproducing real exam items violates the AWS certification agreement and can cost a candidate their certification — ours come with the reasoning attached instead.

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.