mediummultiple choiceObjective-mapped

A platform team wants application developers to create IAM roles for their ECS tasks, but security must guarantee that no role created by those developers can ever exceed a predefined permission set. The developers also should not be able to attach broader permissions to themselves later. What should the team implement?

Question 1mediummultiple choice
Full question →

A platform team wants application developers to create IAM roles for their ECS tasks, but security must guarantee that no role created by those developers can ever exceed a predefined permission set. The developers also should not be able to attach broader permissions to themselves later. What should the team implement?

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

Create a service-linked role for ECS and let developers reuse it for all workloads.

Service-linked roles are managed by AWS for specific service integrations, not for custom developer delegation models.

B

Distractor review

Add an S3 bucket policy that only allows tagged roles to be created.

Bucket policies apply to S3 access, not to IAM role creation or the permission limits of newly created roles.

C

Distractor review

Attach a customer-managed IAM policy to the developers and let them create roles freely.

This grants permissions directly to the developers, but it does not cap the maximum permissions of roles they create.

D

Best answer

Use an IAM permission boundary on the developer principals and require created roles to include the boundary.

A permission boundary sets the upper limit for permissions that an IAM principal or created role can receive. By combining developer role creation permissions with a required boundary, security can allow self-service role creation while preventing privilege escalation. Even if developers attach broader identity policies later, the effective permissions cannot exceed the boundary. This is the right control when you need delegated administration with a hard ceiling on privileges.

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: Use an IAM permission boundary on the developer principals and require created roles to include the boundary. — Permission boundaries are the best fit when a team needs delegated IAM administration without allowing privilege escalation. They define the maximum effective permissions an IAM principal can obtain, even if someone later attaches broader policies. In this scenario, developers can still create ECS task roles, but those roles remain constrained by the approved boundary. That makes the design both flexible for teams and safe for security governance. Why others are wrong: An attached customer-managed policy gives permissions, but it does not enforce a maximum ceiling on future roles. Service-linked roles are AWS-managed and are not a general-purpose control for developer-created IAM roles. An S3 bucket policy has no effect on IAM role creation or privilege boundaries, so it cannot solve this IAM delegation requirement.

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.