SAA-C03 Design Secure Architectures Practice Question
In an AWS Organizations environment, developers create IAM roles using an automation tool. The security team wants to guarantee that even if a developer attaches an overly permissive inline policy, the role cannot exceed a fixed set of allowed actions. The team already uses permission boundaries on each role. The tool’s role-creation API call succeeds, but one developer’s new role can still delete production S3 buckets. What is the most likely reason, and what should be corrected?
⚠ Common exam trap
Many candidates assume permission boundaries are automatically inherited from the AWS Organizations policy or that they only affect managed policies, when in fact they must be explicitly attached and apply to all policy types.
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
✓
The boundary policy was not actually attached during role creation, or the automation tool attached the wrong boundary ARN; correct the role-creation request to set the intended PermissionBoundary.
Permission boundaries must be explicitly attached to an IAM role during creation via the `PermissionBoundary` parameter. If the automation tool fails to attach the intended boundary policy or attaches the wrong ARN, the role will have no effective boundary, allowing any inline policy to grant full access. The developer's role could then delete production S3 buckets because the boundary was not enforced.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Permission boundaries do not affect permissions for resources created with role chaining; enable role chaining instead to apply the boundary.
Why it's wrong here
Permission boundaries are evaluated to limit the maximum effective permissions for the IAM principal regardless of role chaining. The symptom (being able to perform an action beyond the intended maximum) most commonly indicates that the intended boundary was not applied or was applied incorrectly.
- ✓
The boundary policy was not actually attached during role creation, or the automation tool attached the wrong boundary ARN; correct the role-creation request to set the intended PermissionBoundary.
Why this is correct
Permission boundaries work by intersecting allowed actions from the role’s attached policies with the actions permitted by the boundary policy. If the automation tool fails to set the PermissionBoundary ARN (or sets an incorrect one), then the role can use the developer’s attached policies without the intended restriction. Fixing the PermissionBoundary parameter in the role creation call is the direct remedy.
- ✗
KMS key policies override permission boundaries for S3, so deletion permission comes from the KMS policy; restrict the KMS key policy instead.
Why it's wrong here
S3 bucket deletion authorization is governed by IAM permissions (and, where applicable, S3 bucket policies/ACLs). KMS key policies control access to cryptographic operations for KMS-encrypted data, not whether the caller can delete an S3 bucket.
- ✗
Permission boundaries apply only to managed policies, not to inline policies; move the overly permissive permissions to a managed policy type to keep it bounded.
Why it's wrong here
Permission boundaries apply to the effective permissions of the principal, regardless of whether the allowed actions come from inline policies or managed policies. If the boundary is correctly attached, both inline and managed policies are constrained by the boundary; moving to a managed policy does not address an incorrect/missing boundary attachment.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.