mediummultiple choiceObjective-mapped

Exhibit

Developer workflow output:

$ aws iam create-role --role-name dev-lambda-role \
  --assume-role-policy-document file://trust-lambda.json

$ aws iam attach-role-policy --role-name dev-lambda-role \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Security requirement:
- Developers may create roles for Lambda functions.
- New roles must be limited to approved read/write access to a small set of AWS services.
- Security wants a guardrail that cannot be bypassed by attaching a broader policy later.

Based on the exhibit, what should the security team implement so developers can create AWS Lambda execution roles, but no developer-created role can ever exceed the approved permission set?

Question 1mediummultiple choice
Full question →

Based on the exhibit, what should the security team implement so developers can create AWS Lambda execution roles, but no developer-created role can ever exceed the approved permission set?

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

Place the developers in an IAM group with a deny-only managed policy attached.

A group policy can help with access management, but it does not cap the maximum permissions a created role can receive.

B

Best answer

Require a permissions boundary on every developer-created role and set the boundary to the approved maximum permissions.

A permissions boundary limits the highest permissions a role can ever have, even if someone attaches broader policies later. This is the right guardrail when developers are allowed to create roles but must stay within a security-approved ceiling. It still lets them work independently while preventing privilege escalation through policy attachment.

C

Distractor review

Use an AWS Organizations SCP to grant only the approved Lambda permissions directly to the developer roles.

An SCP can restrict permissions, but it does not grant permissions to a role. The role still needs identity-based permissions.

D

Distractor review

Create the roles with inline policies only, because inline policies are always safer than managed policies.

Inline policies are not automatically safer. They can still contain excessive permissions and do not enforce a maximum boundary.

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: Require a permissions boundary on every developer-created role and set the boundary to the approved maximum permissions. — Permissions boundaries are designed for this exact control pattern. They let developers create and manage roles, while ensuring the effective permissions never exceed the approved ceiling defined by security. Even if a developer later attaches AdministratorAccess or another broad policy, the boundary still caps what the role can actually do. That makes it a strong least-privilege control for delegated role creation. Why others are wrong: Group policies only affect users or groups, not the final permissions ceiling of a role. SCPs restrict accounts and OUs, but they do not grant permissions to individual roles, so they cannot be the sole control here. Inline policies do not inherently prevent over-permissioning and are not a substitute for a permissions boundary.

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.