SAA-C03 Design Secure Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

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

  Why it's wrong here

  A deny-only managed policy attached to an IAM group can block specific named actions, but it cannot impose an upper bound on the permissions that a developer-created role will have. IAM group policies apply only to the users in the group, not to roles created by those users, so the newly created roles are outside the group's deny scope. Deny statements also only reject the exact actions listed, leaving all other permissions available, so this measure fails to enforce an 'approved maximum permissions' ceiling.

  When this WOULD be correct

  This option would be correct if the question asked for a method to explicitly deny specific actions (e.g., deny access to certain AWS services) for all developers, without needing to manage individual policies.

• ✓

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

  Why this is correct

  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.

• ✗

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

  Why it's wrong here

  An AWS Organizations SCP acts as a permission filter at the account or OU level, not as a grant mechanism. It cannot 'grant' the approved Lambda permissions to a specific developer role because SCPs only constrain the maximum allowed permissions for principals in the account; the actual permissions must still come from identity-based policies attached to the role. Additionally, SCPs apply to all principals in scope, not directly to individual roles, so this approach does not cap what a developer-created role can receive and does not address the role-creation escalation path.

  When this WOULD be correct

  In a scenario where the organization needs to centrally restrict all IAM actions across multiple accounts, such as preventing any role from accessing certain high-risk services, an SCP would be the correct tool to apply a broad deny policy at the organizational unit level.

• ✗

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

  Why it's wrong here

  The choice between inline and managed policies affects lifecycle management and reuse, not the maximum permission scope. Inline policies can still contain broad permissions—including full Lambda access—and they are embedded directly in the role, making them harder to audit than managed policies. A developer could attach an inline policy granting excessive permissions just as easily as a managed policy, so this practice alone does not prevent privilege escalation or enforce a security-approved boundary.

  When this WOULD be correct

  When the question asks for the most secure way to attach permissions to a role that should never be shared or reused across multiple roles, and the concern is about limiting the scope of permissions to a single role without risk of unintended attachment to other roles.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question