5.2 Service Control Policies (SCPs) & Multi-Account Guardrails

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

5.2 Service Control Policies (SCPs) & Multi-Account Guardrails

Key Takeaways Explain This Topic AI

Service Control Policies (SCPs) define the maximum available permissions for IAM principals in member accounts; they act as preventative guardrails and never grant permissions.

SCPs affect all IAM users, IAM roles, and the root user of member accounts, but have zero effect on the Management account, service-linked roles, or resource-based policies accessed by external accounts.

Under the default Deny List strategy, the AWS-managed FullAWSAccess policy remains attached throughout the tree, and specific prohibited actions are restricted using explicit Deny statements.

In multi-OU hierarchies, SCP permissions are evaluated as an intersection down the tree; if FullAWSAccess is detached at any intermediate OU without an explicit Allow, all permissions below that point are implicitly denied.

Critical enterprise SCP patterns enforce region restrictions via aws:RequestedRegion, prevent disabling logging services (CloudTrail, Config), and use Condition blocks with ArnNotEquals to preserve break-glass emergency access.

Last updated: September 2026

Service Control Policies (SCPs) Mechanics & Evaluation Engine

Service Control Policies (SCPs) are the primary preventative governance mechanism in AWS Organizations. Understanding how SCPs interact with other AWS identity and access management layers is essential for the DOP-C02 exam.

The Guardrail Principle: Boundaries vs. Grants

Important

Core Rule: An SCP never grants permissions . It specifies the maximum available permissions (a permission boundary) for the accounts or Organizational Units (OUs) to which it is attached.

Even if an IAM user or role inside a member account is assigned the AWS-managed policy AdministratorAccess ( "Action": "*", "Resource": "*" ), if an attached SCP does not allow an action—or explicitly denies it—the caller cannot perform that action under any circumstances. [ Service Control Policy (SCP) ] ── (Maximum Allowed Permissions Boundary)

• ∩
• [ IAM Permissions Boundary ] ── (Identity-Level Upper Bound)
• ∩
• [ IAM Policy (User / Role) ] ── (Actual Identity Grants)
• ∩
• [ Resource-Based Policy / Session Boundary ]
• │
• ▼
• [ Effective Runtime Authorization ]
• Entities Subject to SCPs

Impacted Entities: All IAM users, federated IAM roles, applications, and the account root user within target member accounts.

Exempt Entities:

The Management Account: SCPs do not restrict any actions taken within the Organization's Management account, regardless of where policies are attached.

Service-Linked Roles: Predefined roles utilized by AWS services to execute cross-service operations (e.g., AWSServiceRoleForAutoScaling ) cannot be blocked by SCPs.

Resource-Based Policies: If an IAM principal in an external AWS account accesses a resource in your member account (e.g., an S3 bucket with a permissive bucket policy), the member account's SCP does not filter that external principal's permissions.

Policy Inheritance & Evaluation Logic

AWS Organizations evaluates SCPs hierarchically from the Root , down through parent OUs, child OUs, and finally to the individual Account .

Full-List Authorization & The Default FullAWSAccess Policy

By default, AWS Organizations attaches an AWS-managed SCP named FullAWSAccess to the Root, every OU, and every newly created account: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Effect": "Allow",
• "Action": "*",
• "Resource": "*"
• }
• ]
• }

For an API call to be authorized at the member account level, there must be an explicit Allow present at every single level of the hierarchy between Root and the target account: Permitted Actions = Root Allow ∩ Parent OU Allow ∩ Child OU Allow ∩ Account Allow − Any Explicit Deny \text{Permitted Actions} = \text{Root Allow} \cap \text{Parent OU Allow} \cap \text{Child OU Allow} \cap \text{Account Allow} - \text{Any Explicit Deny} Permitted Actions = Root Allow ∩ Parent OU Allow ∩ Child OU Allow ∩ Account Allow − Any Explicit Deny

Deny List Strategy vs. Allow List Strategy

Architectural Strategy Implementation Method Pros & Cons Recommendation

Deny List Strategy Leave FullAWSAccess attached at Root and all OUs. Attach custom SCPs containing Effect: Deny for specific prohibited actions or unauthorized regions. Pros: Low operational overhead; new AWS services work immediately; resilient against accidental lockouts.; Cons: Proactive guardrails must explicitly enumerate every forbidden action. Strongly Recommended & Standard Best Practice.

Allow List Strategy Detach FullAWSAccess . At each OU, attach custom policies containing Effect: Allow only for explicitly approved AWS services. Pros: Maximum least-privilege security posture; unapproved services are blocked by default.; Cons: Extreme administrative burden; whenever AWS releases a new service feature or API, administrators must update SCPs at multiple OU levels or pipelines break. Rarely used; reserved for ultra-high-security isolated enclaves.

Caution

The Accidental Black Hole: If an engineer detaches FullAWSAccess from an OU before attaching an alternative Allow policy, the effective permission boundary becomes an empty set. Every IAM user, role, and workload in every account beneath that OU immediately loses access to all AWS services.

Critical Enterprise SCP Guardrail Patterns

Production landing zones enforce non-negotiable security controls using standardized SCP patterns.

1. Restricting Allowed AWS Regions ( aws:RequestedRegion )

To prevent data exfiltration, shadow IT, and unexpected infrastructure spend in unmonitored geographic regions, organizations restrict API activity to designated operating regions (e.g., us-east-1 and us-west-2 ).

However, naive region-blocking SCPs break global AWS services (IAM, Route 53, CloudFront, AWS Organizations, AWS Support, AWS WAF global) that operate out of us-east-1 or without regional endpoints. The SCP must explicitly exclude global service actions using NotAction : {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "RestrictAllowedRegionsWithGlobalExclusions",
• "Effect": "Deny",
• "NotAction": [
• "a4b:*",
• "acm:*",
• "aws-marketplace-management:*",
• "aws-marketplace:*",
• "aws-portal:*",
• "budgets:*",
• "ce:*",
• "chime:*",
• "cloudfront:*",
• "config:*",
• "cur:*",
• "directconnect:*",
• "ec2:DescribeRegions",
• "ec2:DescribeAvailabilityZones",
• "fms:*",
• "globalaccelerator:*",
• "health:*",
• "iam:*",
• "importexport:*",
• "kms:*",
• "mobileanalytics:*",
• "networkmanager:*",
• "organizations:*",
• "pricing:*",
• "route53:*",
• "route53domains:*",
• "s3:GetAccountPublicAccessBlock",
• "s3:ListAllMyBuckets",
• "s3:PutAccountPublicAccessBlock",
• "shield:*",
• "sts:*",
• "support:*",
• "trustedadvisor:*",
• "waf:*",
• "wafv2:*",
• "wellarchitected:*"
• ],
• "Resource": "*",
• "Condition": {
• "StringNotEquals": {
• "aws:RequestedRegion": [
• "us-east-1",
• "us-west-2"
• ]
• }
• }
• }
• ]
• }
• 2. Protecting Security & Compliance Tooling

To guarantee auditability, member account administrators must be blocked from stopping logging, disabling monitoring, or tampering with centralized security infrastructure: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "PreventDisablingCloudTrailAndConfig",
• "Effect": "Deny",
• "Action": [
• "cloudtrail:DeleteTrail",
• "cloudtrail:StopLogging",
• "cloudtrail:UpdateTrail",
• "config:DeleteConfigRule",
• "config:DeleteConfigurationRecorder",
• "config:DeleteDeliveryChannel",
• "config:StopConfigurationRecorder",
• "guardduty:DeleteDetector",
• "guardduty:DisassociateFromMasterAccount",
• "guardduty:UpdateDetector"
• ],
• "Resource": "*"
• }
• ]
• }
• 3. Preventing Accounts from Leaving the Organization

To prevent rogue administrators or compromised accounts from detaching from corporate oversight and removing all inherited SCPs: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "DenyLeavingOrganization",
• "Effect": "Deny",
• "Action": [
• "organizations:LeaveOrganization"
• ],
• "Resource": "*"
• }
• ]
• }
• 4. Restricting the Member Account Root User

Best practices demand that all operational tasks be performed via federated IAM Identity Center roles with Multi-Factor Authentication (MFA). The member account root user should have no day-to-day operational capability: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "RestrictMemberAccountRootUser",
• "Effect": "Deny",
• "Action": "*",
• "Resource": "*",
• "Condition": {
• "StringLike": {
• "aws:PrincipalArn": [
• "arn:aws:iam::*:root"
• ]
• }
• }
• }
• ]
• }
• 5. Enforcing In-Transit Encryption (SSL/TLS)

To satisfy regulatory standards (such as PCI-DSS and FedRAMP), an SCP can enforce that Amazon S3 API requests use HTTPS: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "EnforceSecureTransport",
• "Effect": "Deny",
• "Action": "s3:*",
• "Resource": "*",
• "Condition": {
• "Bool": {
• "aws:SecureTransport": "false"
• }
• }
• }
• ]
• }
• Break-Glass Roles and Condition Exceptions

During high-severity operational incidents or infrastructure outages, emergency incident responders (the "break-glass" team) may require temporary, unrestricted access to recover systems or modify baseline infrastructure.

Implementing Safe SCP Exemptions

An SCP containing an unconditional Deny will block even emergency responders. To create an exception, include a Condition block utilizing ArnNotEquals or StringNotLike targeting the designated break-glass role: {

• "Version": "2012-10-17",
• "Statement": [
• {
• "Sid": "DenyS3BucketDeletionExceptBreakGlass",
• "Effect": "Deny",
• "Action": [
• "s3:DeleteBucket",
• "s3:DeleteBucketPolicy"
• ],
• "Resource": "*",
• "Condition": {
• "ArnNotEquals": {
• "aws:PrincipalArn": [
• "arn:aws:iam::*:role/EmergencyBreakGlassRole",
• "arn:aws:iam::*:role/aws-service-role/*"
• ]
• }
• }
• }
• ]
• }

Tip

DOP-C02 Exam Trap — Assumed-Role vs. Role ARN Evaluation: When an engineer assumes an IAM role, AWS STS issues temporary credentials where aws:PrincipalArn evaluates to the IAM role ARN ( arn:aws:iam::<AccountID>:role/EmergencyBreakGlassRole ). However, the session ARN is arn:aws:sts::<AccountID>:assumed-role/EmergencyBreakGlassRole/<SessionName> . The aws:PrincipalArn condition key evaluates the underlying IAM role ARN, making ArnNotEquals on arn:aws:iam::*:role/EmergencyBreakGlassRole work reliably for assumed roles.

Loading diagram... SCP Evaluation and Hierarchical Inheritance Logic