While preparing for the AWS SAA-C03, many candidates get confused by IAM policy evaluation (especially when multiple policies are attached). In the real world, this is fundamentally a decision about least privilege vs. operational convenience, with an exam-style focus on how Allow and Explicit Deny combine.
The Scenario #
A mid-sized SaaS company, Northbridge Metrics, is tightening access controls after an internal audit.
A solutions architect creates two IAM policies—Policy1 and Policy2—and attaches both to an IAM group called Ops-Trainees. A cloud engineer is added as an IAM user to that group.
Security leadership asks: “Given these two policies, what can this engineer actually do?”
This drill focuses on IAM evaluation logic: all applicable policies are evaluated together, and Explicit Deny always wins.
Key Requirements #
- Determine the effective permissions of an IAM user who inherits permissions from a group.
- Apply the IAM evaluation rules:
- Default is Deny
- An Allow can grant access
- Any Explicit Deny overrides any Allow
The Options #
- A) Delete an IAM user
- B) Delete a directory (folder-like resource in storage)
- C) Terminate (delete) an Amazon EC2 instance
- D) Delete log data from Amazon CloudWatch Logs
Correct Answer #
C) Terminate (delete) an Amazon EC2 instance
The Winning Logic #
When two policies are attached to the same identity (via a group), the user’s permissions are the union of Allows, minus anything that is explicitly denied.
In typical exam constructions like this:
- One policy allows a specific operational action (often an EC2 action like
ec2:TerminateInstances) - The other policy places guardrails via Explicit Deny on more sensitive areas (like IAM user deletion and log deletion)
So the only safe conclusion for the “what can they do?” question is the action that remains explicitly allowed and not denied: EC2 instance deletion/termination.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
-
Why not A (Delete IAM user)?
Deleting IAM users (iam:DeleteUser) is commonly explicitly denied in guardrail policies because it can break access governance and auditability. -
Why not B (Delete directory)?
“Delete a directory” is intentionally vague in AWS exams; in practice it maps to S3 deletes (s3:DeleteObject) or filesystem actions on EFS/FSx. If the policies don’t clearly grant it, the default is Deny. -
Why not D (Delete CloudWatch Logs)?
Log deletion (logs:DeleteLogGroup,logs:DeleteLogStream) is frequently denied to preserve audit trails. Even if one policy allows it, an explicit deny would override it.
FinOps Note (Associate-Level Practical Insight) #
IAM permissions aren’t a “line item cost,” but they drive cost outcomes:
- Allowing broad delete rights on logs can reduce spend short-term but harms compliance and incident response (hidden cost).
- Allowing instance termination can reduce compute spend, but should be constrained with tags/conditions to avoid accidental outages.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
U[IAM User] --> G[IAM Group: Ops-Trainees]
G --> P1[Policy1]
G --> P2[Policy2]
P1 --> E[Effective Permissions Calculation]
P2 --> E
E --> R{Any Explicit Deny?}
R -- Yes --> D[Deny that action]
R -- No + Allowed --> A[Allow that action]
R -- No + Not Allowed --> ID[Implicit Deny]
- Diagram Note: The user’s access is evaluated across both policies at once; explicit denies override any allows, and everything else is implicitly denied.
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
If multiple IAM policies apply, remember: Explicit Deny beats Allow, and anything not explicitly allowed is implicitly denied.
Real World #
In production, you’d avoid “mystery effective permissions” by:
- Using IAM Access Analyzer policy checks
- Adding Conditions (e.g., allow termination only for instances with tag
Environment=Dev) - Using permission boundaries for trainees/contractors to cap maximum privileges