Study guide
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies
AWS Certified DevOps Engineer – Professional Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CI/CD Pipeline Architecture & Source Integration
1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models
2 Chapter 2: Automated Testing, Test Gates & Quality Verification
2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates
3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies
3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda
4 Chapter 4: CloudFormation, CDK & Reusable IaC Components
4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance
5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower
5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation
6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration
6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig
7 Chapter 7: High Availability & Multi-Region Resiliency
7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR
8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation
8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery
9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation
9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions
10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray
10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps
11 Chapter 11: Automated Observability & Event-Driven Monitoring
11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries
12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines
12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling
13 Chapter 13: Automated Remediation & Deployment Troubleshooting
13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures
14 Chapter 14: Identity, Access Management & Secrets at Scale
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager
15 Chapter 15: Security Automation, Data Protection & Compliance Auditing
15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config
14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies
Key Takeaways Explain This Topic AI
Default Deny is the baseline for all AWS API calls; an authorization decision requires at least one explicit Allow and zero explicit Denies across all applicable policy categories.
An Explicit Deny in any applicable policy (SCP, identity-based policy, resource-based policy, permissions boundary, or session policy) immediately halts evaluation and overrides all explicit Allows.
When an identity-based policy, a permissions boundary, and an STS session policy are all present, the effective permission is strictly the intersection (logical AND) of all three policy scopes.
Same-account authorization requires an explicit Allow from either an identity-based policy OR a resource-based policy, whereas cross-account access requires explicit Allows in BOTH the identity policy AND the target resource policy (or role trust policy).
The NotAction element paired with Effect: Deny creates a comprehensive deny across all AWS actions except those explicitly listed, whereas NotAction paired with Effect: Allow grants access to all actions except those listed.
Last updated: September 2026
AWS IAM Policy Evaluation Logic & Decision Flow
Every incoming AWS API call—whether originated by a developer via the AWS CLI, an automated CI/CD pipeline role, an Amazon EC2 instance profile, or a serverless AWS Lambda function—is evaluated by the AWS Identity and Access Management (IAM) authorization engine. Understanding the precise mathematical and logical precedence of this evaluation engine is crucial for passing the AWS Certified DevOps Engineer - Professional (DOP-C02) exam.
The Fundamental Axioms of IAM Evaluation
The IAM evaluation engine operates on three deterministic axioms:
Default Deny (Implicit Deny) : By default, all requests are denied. If no policy explicitly grants permission for an action on a resource, the final authorization decision is Deny .
Explicit Deny Precedence : An explicit Deny in any policy that applies to the request immediately supersedes any and all explicit Allow statements. If a single applicable policy evaluates to Deny , the final authorization decision is unconditionally Deny .
Explicit Allow Requirement : In the absence of an explicit Deny , there must be at least one explicit Allow in an applicable policy for the request to succeed. Request Received
- │
- ▼
- [ Is there an Explicit Deny in ANY applicable policy? ] ──YES──> DENY
- │
- NO
- ▼
- [ Do Organizations SCPs Allow the Action? ] ─────────────NO───> DENY
- │
- YES
- ▼
- [ Is there a Permissions Boundary? ] ────────────────────YES──> [ Does Boundary Allow Action? ] ──NO──> DENY
- │ │ YES
- NO ▼
- │ ◄─────────────────────────────────────────────────────────────────────┘
- ▼
[ Is there an STS Session Policy? ] ─────────────────────YES──> [ Does Session Policy Allow Action? ] ──NO──> DENY
- │ │ YES
- NO ▼
- │ ◄─────────────────────────────────────────────────────────────────────┘
- ▼
- [ Is this a Cross-Account Request? ]
- │
- ├─── YES ──> [ Do BOTH Identity Policy AND Resource Policy Allow Action? ] ──NO──> DENY
- │ │ YES
- │ ▼
- │ ALLOW
- │
- └─── NO ───> [ Does EITHER Identity Policy OR Resource Policy Allow Action? ] ──YES──> ALLOW
- │ NO
- ▼
- DENY (Default Implicit Deny)
- Multi-Policy Types and Authorization Intersections
In an enterprise environment governed by AWS Organizations and landing zones (such as AWS Control Tower), multiple policy types simultaneously govern a single request. The effective permissions represent the logical intersection or union depending on the policy types involved.
Applicable Policy Types
Policy Type Attachment Point Scope & Function Evaluation Behavior
Service Control Policy (SCP) AWS Organizations Root, OU, or Account Maximum entitlement guardrail across an entire account Must allow the action; does not grant permissions to identities directly
Resource-Based Policy AWS Resources (S3 buckets, KMS keys, SQS queues, Secrets) Specifies which principals can access the specific resource Can grant access directly across accounts without role assumption
IAM Permissions Boundary IAM Users or IAM Roles Maximum entitlement ceiling for an identity Restricts identity-based policies; effective permission is Identity ∩ Boundary
STS Session Policy Temporary STS credentials ( AssumeRole , GetFederationToken ) Ephemeral permission filter passed dynamically during role assumption Restricts assumed session; effective permission is Role ∩ SessionPolicy
Identity-Based Policy IAM Users, IAM Groups, or IAM Roles Grants permissions directly to the authenticated identity Evaluated against resource policies, boundaries, and session policies
The Intersection Rule for Constrained Identities
When an IAM entity operates with both a Permissions Boundary and an STS Session Policy, the effective permissions are determined by the strict intersection (logical AND) of all three policy scopes: Effective Permissions = Identity Policy ∩ Permissions Boundary ∩ Session Policy ∩ SCP \text{Effective Permissions} = \text{Identity Policy} \cap \text{Permissions Boundary} \cap \text{Session Policy} \cap \text{SCP} Effective Permissions = Identity Policy ∩ Permissions Boundary ∩ Session Policy ∩ SCP
If an identity policy grants s3:* and ec2:* , but the permissions boundary only allows s3:* and dynamodb:* , the intermediate allowable scope is s3:* . If the role is assumed via STS with a session policy allowing s3:GetObject and sqs:* , the final authorized permission is strictly s3:GetObject .
Same-Account vs. Cross-Account Evaluation Mechanics
The rules governing resource-based policies differ fundamentally based on whether the principal and the resource reside in the same AWS account or different AWS accounts .
1. Same-Account Access
Within the same AWS account, an explicit Allow in either the identity-based policy or the resource-based policy is sufficient to grant access, assuming no explicit Deny exists.
If an IAM role has no identity-based policies attached, but an Amazon S3 bucket policy in the same account explicitly allows that IAM role ARN to perform s3:GetObject , the role is authorized.
Critical Exception (AWS KMS) : AWS Key Management Service (KMS) key policies behave differently. If a KMS key policy does not delegate administration to the account root principal ( "Principal": {"AWS": "arn:aws:iam::111122223333:root"} ), identity-based policies cannot grant access to that key even within the same account. The key policy itself must contain the explicit allow.
2. Cross-Account Access
When a principal in Account A requests access to a resource in Account B:
An explicit Allow is mandatory in both the calling principal's identity-based policy (Account A) and the target resource-based policy (Account B).
If the target resource does not support resource-based policies (for example, an Amazon EC2 instance, an Amazon RDS DB instance, or an Amazon EBS volume), the principal in Account A cannot access the resource directly; it must assume an IAM role in Account B via sts:AssumeRole . The set of services that support resource-based policies grows over time — Amazon S3, AWS KMS, Amazon SQS, Amazon SNS, AWS Secrets Manager, AWS Lambda, Amazon EventBridge, Amazon ECR, and Amazon DynamoDB all support them today.
The NotAction Element: The Critical Exam Trap
One of the most dangerous and heavily tested concepts on the DOP-C02 exam is the interaction between NotAction and the Effect element ( Allow vs. Deny ). {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "DangerousPolicyExamTrap",
- "Effect": "Deny",
- "NotAction": "s3:*",
- "Resource": "*"
- }
- ]
- }
What Does Effect: Deny with NotAction Actually Do?
Many engineers mistakenly believe the policy above means "Deny access to all S3 actions that are not specified." That is completely incorrect.
NotAction: s3:* matches every single AWS action in existence except S3 actions ( ec2:* , rds:* , iam:* , lambda:* , dynamodb:* , etc.).
Effect: Deny applies an explicit Deny to all of those matched actions.
Consequently, this statement explicitly denies access to every AWS service across the entire platform except Amazon S3 !
For Amazon S3 actions, this statement does not apply. S3 actions remain unmentioned, which results in a Default (Implicit) Deny unless another statement explicitly allows them.
Comparison: NotAction with Allow vs. Deny
Statement Elements Practical Meaning & Impact Common Valid Use Case
Effect: Allow ; NotAction: iam:* ; Resource: * Grants permissions to all AWS services except IAM . Any action with prefix iam: is not allowed by this statement. Granting broad administrative capabilities to developers while preventing them from modifying IAM credentials or escalating privileges.
Effect: Deny ; NotAction: s3:* ; Resource: * Enforces an explicit Deny on all AWS services except S3 . No other policy can ever grant access to EC2, RDS, DynamoDB, etc. Lockdown or quarantine scenarios where an identity must be forcefully blocked from every AWS service except an isolated bucket.
Effect: Deny ; Action: s3:* ; NotResource: arn:aws:s3:::audit-bucket/* Denies all S3 actions except when targeting the specified audit bucket . Restricting an identity so it cannot interact with any S3 bucket other than the designated corporate audit repository.
Global Condition Keys for Zero-Trust DevOps Governance
Condition keys provide attribute-based access control (ABAC) and environmental constraints that must evaluate to true for a statement to take effect. {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "EnforceSecureTransportAndSourceVPC",
- "Effect": "Deny",
- "Action": "s3:*",
- "Resource": [
- "arn:aws:s3:::corp-compliance-vault",
- "arn:aws:s3:::corp-compliance-vault/*"
- ],
- "Condition": {
- "Bool": {
- "aws:SecureTransport": "false"
- }
- }
- },
- {
- "Sid": "RestrictToCorporateVPC",
- "Effect": "Deny",
- "Action": "s3:*",
- "Resource": [
- "arn:aws:s3:::corp-compliance-vault",
- "arn:aws:s3:::corp-compliance-vault/*"
- ],
- "Condition": {
- "StringNotEquals": {
- "aws:sourceVpc": "vpc-0123456789abcdef0"
- }
- }
- }
- ]
- }
- Critical Condition Keys for Enterprise Pipelines
aws:PrincipalArn / aws:PrincipalTag/${TagKey} : Validates the ARN or ABAC session tags of the caller. Used to enforce project-based access where a developer role with tag Project=Billing can only manipulate resources tagged Project=Billing .
aws:PrincipalOrgID : Validates that the calling principal belongs to a specific AWS Organization ID (e.g., o-a1b2c3d4e5 ). Extremely valuable in S3 bucket policies, KMS key policies, and EventBridge bus policies to allow all current and future accounts in an organization without manual account ID enumeration.
aws:SourceIp : Restricts requests to specific public IP CIDR ranges. Exam Trap : aws:SourceIp will evaluate to null and fail if the call originates from an AWS service acting on behalf of the user (e.g., AWS CloudFormation deploying resources), unless combined with aws:ViaAWSService .
aws:SourceVpc / aws:SourceVpce : Enforces that requests originate from a specific VPC ID or VPC Endpoint ID (via AWS PrivateLink), preventing data exfiltration over the public internet.
aws:SecureTransport : A boolean condition key. When checked with "Bool": {"aws:SecureTransport": "false"} under an explicit Deny , it mandates that all incoming API requests utilize TLS (HTTPS) and rejects plain HTTP requests.
aws:MultiFactorAuthPresent / aws:MultiFactorAuthAge : Enforces that the temporary session was authenticated using multi-factor authentication (MFA) and restricts the age of the MFA authentication event (e.g., under 3600 seconds) for sensitive operational actions such as deleting databases or terminating production instances.