SAA-C03 Design Secure Architectures Practice Question
Exhibit
Shared role policy in Account A:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject", "kms:Decrypt"],
"Resource": [
"arn:aws:s3:::artifact-bucket/*",
"arn:aws:kms:us-east-1:111122223333:key/KEY-AAAA"
]
}
]
}
AssumeRole call from the pipeline:
- Role ARN: arn:aws:iam::111122223333:role/SharedDeployRole
- Session name: build-7412
- No session policy currently suppliedBased 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?
⚠ Common exam trap
A common mix-up: candidates confuse permission boundaries (which set a maximum limit) with session policies (which further restrict a specific session), or mistakenly think trust policies can scope resource-level permissions like S3 prefixes or KMS keys.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Pass an inline session policy in the AssumeRole request that further restricts the temporary credentials to teamA/prod/ and the approved KMS key.
An inline session policy passed in the AssumeRole request allows you to further restrict the temporary credentials' permissions without modifying the shared role itself. This ensures the pipeline can only upload to teamA/prod/ and decrypt using the specified KMS key, while other pipelines using the same role remain unaffected.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Attach a permission boundary to the pipeline's assumed session so the temporary credentials cannot exceed the shared role permissions.
Why it's wrong here
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.
- ✓
Pass an inline session policy in the AssumeRole request that further restricts the temporary credentials to teamA/prod/ and the approved KMS key.
Why this is correct
STS session policies are designed to further restrict the permissions of temporary credentials issued by AssumeRole. In this case, the shared role can remain reusable for other pipelines, while this one execution is narrowed to the exact S3 prefix and KMS key required. The effective permissions become the intersection of the role permissions and the session policy, which preserves least privilege without changing the shared role itself.
- ✗
Add an SCP to Account A that forces all roles to use the same S3 prefix and key whenever they are assumed.
Why it's wrong here
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.
Why it's wrong here
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.
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 302-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.