hardmultiple choiceObjective-mapped

Exhibit

{
  "role_policy": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:PutObject",
        "Resource": "arn:aws:s3:::artifact-bucket/*"
      }
    ]
  },
  "assume_role_command": "aws sts assume-role --role-arn arn:aws:iam::111122223333:role/CentralDeployRole --role-session-name teamA-ci",
  "requirement": "TeamA pipeline must upload only to arn:aws:s3:::artifact-bucket/teamA/prod/*"
}

Based on the exhibit, a central deployment role in Account A is assumed by several CI/CD pipelines from Account B. The role must remain reusable, but the team wants the TeamA pipeline to upload artifacts only to s3://artifact-bucket/teamA/prod/ without creating a separate IAM role. What is the best approach?

Question 1hardmultiple choice
Full question →

Based on the exhibit, a central deployment role in Account A is assumed by several CI/CD pipelines from Account B. The role must remain reusable, but the team wants the TeamA pipeline to upload artifacts only to s3://artifact-bucket/teamA/prod/ without creating a separate IAM role. What is the best approach?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Distractor review

Use an IAM user in Account B and hard-code the narrower S3 path in its access key policy.

This reintroduces long-term credentials and defeats the purpose of using STS assumed-role access. It also creates a separate identity instead of reusing the central deployment role.

B

Distractor review

Add a bucket ACL that grants write access only to the TeamA pipeline session name.

S3 ACLs cannot evaluate STS session names or enforce per-session restrictions. They are also a poor fit for least-privilege automation because they are coarse and difficult to manage safely at scale.

C

Distractor review

Attach a permissions boundary to the central role so every pipeline session inherits the narrower prefix automatically.

A permissions boundary limits the maximum permissions of an IAM principal, but it does not let different callers apply different temporary restrictions when they assume the same role. The boundary would apply to the role itself, not dynamically to one TeamA session versus other pipeline sessions.

D

Best answer

Pass an STS session policy when TeamA assumes the role to further restrict the temporary credentials to the teamA/prod prefix.

An STS session policy is specifically designed to reduce the permissions of temporary credentials for a single assume-role session. The reusable base role can remain broad enough for multiple pipelines, while TeamA can pass a session policy that limits effective permissions to the teamA/prod prefix. This preserves the shared role model and achieves least privilege without creating a separate IAM role.

Common exam trap

Common exam trap: authentication is not authorization

Logging in proves the user can authenticate. It does not automatically mean the user is allowed to enter privileged or configuration mode. Watch for AAA authorization, privilege level and command authorization details.

Technical deep dive

How to think about this question

This kind of question is testing the difference between identity and permission. A user may successfully log in to a router because authentication is working, but still fail to enter configuration mode because authorization is missing, misconfigured or mapped to a lower privilege level.

KKey Concepts to Remember

  • Authentication checks who the user is.
  • Authorization controls what the user is allowed to do after login.
  • Privilege levels affect access to EXEC and configuration commands.
  • AAA, TACACS+ and RADIUS can separate login success from command access.

TExam Day Tips

  • Do not assume successful login means full administrative access.
  • Look for words such as cannot enter configuration mode, privilege level, authorization or command access.
  • Separate login problems from permission problems before choosing the answer.

Related practice questions

Related SAA-C03 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

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 STS session policy when TeamA assumes the role to further restrict the temporary credentials to the teamA/prod prefix. — STS session policies are the best fit when you need one reusable assumed role but want to narrow permissions for a specific caller or pipeline session. In this case, the central role in Account A can stay shared by multiple CI/CD systems from Account B, and TeamA can pass a session policy at assume-role time that restricts s3:PutObject to arn:aws:s3:::artifact-bucket/teamA/prod/*. The temporary credentials will then be unable to write outside that prefix, even though the base role itself is more broadly scoped. An IAM user would create a long-lived credential and reduce security. A bucket ACL cannot enforce STS session-name-based access control and is not an appropriate least-privilege mechanism. A permissions boundary constrains the role's maximum permissions, but it does not provide per-assumption, per-pipeline narrowing of a shared role's effective permissions.

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.

Discussion

Loading comments…

Sign in to join the discussion.