Based on the exhibit, a CI pipeline assumes a shared deployment role in Account A. The role can access several artifact prefixes, but this pipeline must only upload to teamA/prod/ and decrypt using a single KMS key for this execution. Changing the shared role would affect other pipelines. Which approach should the pipeline use?

Attach a permission boundary to the pipeline's assumed session so the temporary credentials cannot exceed the shared role permissions.

Permission boundaries are attached to IAM users or roles, not to an STS session after the role has already been assumed. They set the maximum permissions for that principal, but they do not provide a per-execution narrowing mechanism for one AssumeRole call while leaving the shared role unchanged for other pipelines.

Add an SCP to Account A that forces all roles to use the same S3 prefix and key whenever they are assumed.

Service control policies act as account-level guardrails, not per-session controls. They cannot tailor permissions for one pipeline execution and would be too broad for a shared-role scenario where different pipelines need different prefixes and keys. SCPs also do not replace identity or session policies for fine-grained runtime restriction.

Change the role trust policy to allow only the teamA/prod/ prefix and the key ARN because trust policies can scope S3 object paths directly.

Trust policies control which principals are allowed to assume the role; they do not scope the S3 object paths or KMS key resources that the resulting temporary credentials may access. Resource-level restrictions belong in identity policies, resource policies, or session policies. The scenario specifically asks for a per-execution restriction without modifying the shared role, which makes a session policy the correct control.

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Pass an inline session policy in the AssumeRole request that further restricts the temporary credentials to teamA/prod/ and the approved KMS key. — An STS session policy is the best way to further restrict the permissions of one temporary session without altering the shared role used by other pipelines. The role can keep broad, reusable access, while the pipeline attaches a session policy that narrows the effective permissions to the approved prefix and KMS key. This is a clean least-privilege pattern for shared deployment roles. Permission boundaries are not applied to an STS session as a separate runtime constraint. SCPs are organization or account guardrails and are too coarse for one execution path. Trust policies only determine who can assume the role, not what the resulting credentials can do. The scenario asks for a one-run restriction without changing the shared role, which points directly to an STS session policy.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.