Study guide
14.2 IAM Permissions Boundaries & Delegated Administration
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.2 IAM Permissions Boundaries & Delegated Administration
Key Takeaways Explain This Topic AI
An IAM Permissions Boundary sets the maximum allowable permissions (guardrail ceiling) that an identity-based policy can grant to an IAM user or role, but it never grants permissions on its own.
In the delegated administration pattern, central security teams allow DevOps engineers to create IAM roles and policies dynamically while enforcing that any created role must have a specific Permissions Boundary attached.
Enforcing permissions boundary attachment requires conditional checks (StringEquals on iam:PermissionsBoundary) across iam:CreateRole, iam:CreateUser, and iam:PutRolePermissionsBoundary.
Preventing privilege escalation requires strictly denying permissions to delete the boundary (iam:DeleteRolePermissionsBoundary), modify the boundary policy document, or pass unbounded roles (iam:PassRole).
The effective permissions of any IAM principal are the strict logical intersection of its Identity-Based Policies, its Permissions Boundary, and applicable AWS Organizations Service Control Policies (SCPs).
Last updated: September 2026
The Enterprise IAM Challenge: Bottlenecks vs. Privilege Escalation
In high-velocity cloud engineering environments, developers and automated CI/CD pipelines continuously provision compute infrastructure—such as AWS Lambda functions, Amazon ECS tasks, and AWS CodeBuild project environments. Each of these compute resources requires an execution role with tailored IAM permissions.
Traditionally, organizations face a painful architectural dilemma:
Centralized Security Bottleneck : The central security team manually reviews and provisions every IAM role and policy. This introduces severe development friction, stalls deployment velocity, and incentivizes engineers to seek insecure workarounds.
Unrestricted Developer Access : Developers are granted iam:CreateRole and iam:AttachRolePolicy to self-serve. Without guardrails, a developer can create a role with AdministratorAccess , attach it to an EC2 instance or Lambda function, and immediately escalate their privileges to full account takeover.
IAM Permissions Boundaries solve this dilemma by enabling Delegated IAM Administration . A permissions boundary establishes an immutable maximum entitlement ceiling (an authorization guardrail) that limits the effective permissions of an IAM user or role, regardless of what identity policies are attached.
Mechanics of IAM Permissions Boundaries
An IAM permissions boundary is an advanced feature that uses an existing customer-managed IAM policy to set the maximum permissions that an identity-based policy can grant to an IAM entity.
Critical Rules of Permissions Boundaries
Ceiling, Not a Grant : A permissions boundary does not grant any permissions . It merely defines the boundary. An entity with a permissions boundary allowing AdministratorAccess ( *:* ) can perform zero actions until an identity-based policy is attached that explicitly grants permissions.
Intersection Evaluation : The effective permissions of the entity are strictly the intersection of the identity-based policy and the permissions boundary ( IdentityPolicy ∩ PermissionsBoundary ).
Target Entities : Permissions boundaries can be attached to IAM Users and IAM Roles . They cannot be attached to IAM Groups, and they do not apply to resource-based policies or the account root user. ┌────────────────────────────────────────────────────────┐
- │ Customer-Managed Policy Definition │
- │ "arn:aws:iam::123456789012:policy/DevCeiling" │
- │ Allows: S3 (*), DynamoDB (*), CloudWatch Logs (*) │
- └───────────────────────────┬────────────────────────────┘
- │ (Attached as Boundary)
- ▼
- ┌─────────────────────────┐
- │ IAM Execution Role │
- │ "PaymentProcessorRole" │
- └────────────┬────────────┘
- │ (Attached as Identity Policy)
- ▼
- ┌────────────────────────────────────────────────────────┐
- │ Attached Identity Policy │
- │ Allows: S3 (*), DynamoDB (*), Amazon SQS (*), IAM (*) │
- └───────────────────────────┬────────────────────────────┘
- │
- ▼
- ┌────────────────────────────────────────────────────────┐
- │ EFFECTIVE PERMISSIONS │
- │ Allows: S3 (*) and DynamoDB (*) ONLY │
- │ (SQS and IAM are denied because they exceed boundary) │
- └────────────────────────────────────────────────────────┘
- Implementing Delegated Administration: The 3-Step Pattern
To securely delegate IAM role creation to developers, the central security team deploys a framework comprising three discrete elements:
Step 1: Define the Permissions Boundary Policy
The security team authors and locks down the boundary policy ( arn:aws:iam::123456789012:policy/DevRoleBoundary ). This policy defines the outer limit of what any developer-created role can do (e.g., allow S3, DynamoDB, SQS, SNS, and CloudWatch, but explicitly deny access to billing, production database secrets, or IAM manipulation).
Step 2: Grant Delegated Role Creation Conditioned on Boundary Attachment
The developers are granted iam:CreateRole , iam:AttachRolePolicy , and iam:PutRolePolicy . However, role creation is strictly conditioned on attaching the specified boundary policy using the iam:PermissionsBoundary condition key.
Step 3: Block All Privilege Escalation Pathways
The developers are explicitly denied from modifying or deleting the boundary, altering the boundary policy document, or passing arbitrary roles to compute services.
Production Delegated Administration Policy JSON
The following IAM policy demonstrates a production-grade delegated administration policy attached to a developer group or CI/CD automation role: {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "AllowRoleCreationWithMandatoryBoundary",
- "Effect": "Allow",
- "Action": [
- "iam:CreateRole",
- "iam:PutRolePermissionsBoundary"
- ],
- "Resource": "arn:aws:iam::123456789012:role/app-team/*",
- "Condition": {
- "StringEquals": {
- "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevRoleBoundary"
- }
- }
- },
- {
- "Sid": "AllowPolicyManagementOnAppRoles",
- "Effect": "Allow",
- "Action": [
- "iam:AttachRolePolicy",
- "iam:DetachRolePolicy",
- "iam:PutRolePolicy",
- "iam:DeleteRolePolicy"
- ],
- "Resource": "arn:aws:iam::123456789012:role/app-team/*"
- },
- {
- "Sid": "PreventBoundaryRemovalOrTampering",
- "Effect": "Deny",
- "Action": [
- "iam:DeleteRolePermissionsBoundary",
- "iam:DeleteUserPermissionsBoundary"
- ],
- "Resource": "*"
- },
- {
- "Sid": "PreventBoundaryPolicyModification",
- "Effect": "Deny",
- "Action": [
- "iam:CreatePolicyVersion",
- "iam:DeletePolicyVersion",
- "iam:DeletePolicy",
- "iam:SetDefaultPolicyVersion"
- ],
- "Resource": "arn:aws:iam::123456789012:policy/DevRoleBoundary"
- },
- {
- "Sid": "RestrictedPassRoleToComputeServices",
- "Effect": "Allow",
- "Action": "iam:PassRole",
- "Resource": "arn:aws:iam::123456789012:role/app-team/*",
- "Condition": {
- "StringEquals": {
- "iam:PassedToService": [
- "lambda.amazonaws.com",
- "ecs-tasks.amazonaws.com"
- ]
- }
- }
- }
- ]
- }
- Privilege Escalation Attack Vectors & Hardened Countermeasures
When designing delegated administration policies, DevOps engineers must defend against five distinct privilege escalation vectors:
1. Removing the Permissions Boundary
The Exploit : A developer creates a role with the boundary attached, and subsequently calls iam:DeleteRolePermissionsBoundary to remove the ceiling, leaving the role unbounded.
Countermeasure : Explicitly deny iam:DeleteRolePermissionsBoundary on all resources.
2. Overwriting the Boundary with a Permissive Policy
The Exploit : A developer invokes iam:PutRolePermissionsBoundary targeting the role, but points to a completely unrestricted policy (such as AdministratorAccess ).
Countermeasure : Enforce Condition: {"StringEquals": {"iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevRoleBoundary"}} on iam:PutRolePermissionsBoundary .
3. Modifying the Boundary Policy Document Itself
The Exploit : A developer has permissions to manage IAM policies and calls iam:CreatePolicyVersion or iam:SetDefaultPolicyVersion against the boundary policy ARN, adding "Action": "*", "Effect": "Allow" .
Countermeasure : Explicitly deny iam:CreatePolicyVersion , iam:SetDefaultPolicyVersion , and iam:DeletePolicy targeting the boundary policy ARN.
4. Unrestricted iam:PassRole Exploitation
The Exploit : An engineer cannot create administrative roles, but they discover an existing administrative role (e.g., EmergencyBreakGlassRole or CloudFormationDeploymentRole ) in the account. If the engineer has iam:PassRole on Resource: * , they can configure an EC2 instance or Lambda function to execute under the administrative role and take over the account.
Countermeasure : Restrict iam:PassRole strictly to role ARNs matching the delegated path ( arn:aws:iam::123456789012:role/app-team/* ) and enforce the iam:PassedToService condition key to restrict which AWS services can accept the role.
5. Creating Users Without Boundaries
The Exploit : If developers have iam:CreateUser without a boundary condition, they can create an IAM user with access keys and assign it full administrative privileges.
Countermeasure : If user creation is permitted, enforce StringEquals: {"iam:PermissionsBoundary": "..."} on iam:CreateUser , or completely deny iam:CreateUser and mandate IAM role usage exclusively.
Permissions Boundaries vs. Service Control Policies (SCPs)
Both Permissions Boundaries and SCPs act as guardrail mechanisms, but their administrative scope, operational ownership, and evaluation mechanisms are fundamentally distinct.
- Architectural Attribute IAM Permissions Boundary Service Control Policy (SCP)
- Management Level Local AWS Account level AWS Organizations Management / Delegated Admin level
Target Entities Individual IAM Users and IAM Roles AWS Accounts, Organizational Units (OUs), or the Organization Root
Account Root Impact Does NOT affect the account root user Directly constrains the account root user and all IAM entities
Administrative Delegation Allows local account administrators to safely delegate role creation Enforced globally by enterprise security teams; local admins cannot modify
Resource-Based Policies Does NOT constrain resource-based policies directly Does NOT constrain resource-based policies directly, but blocks calls made by principals in governed accounts
Primary Enterprise Use Case Empowering application developers and CI/CD pipelines to create least-privilege IAM roles Enforcing baseline security invariants (e.g., blocking disabling CloudTrail, restricting allowed regions)