AWS SAP-C02 Drill: SCP Strategy for M&A Onboarding - The Governance-Agility Trade-off

While preparing for the AWS SAP-C02, many candidates get confused by SCP inheritance hierarchies and temporary policy exceptions. In the real world, this is fundamentally a decision about Governance Rigidity vs. Onboarding Velocity during M&A integration. Let’s drill into a simulated scenario.

The Architecture Drill

#

Scenario

#

GlobalRetail Corp operates a multi-account AWS environment managed through AWS Organizations. Their architecture consists of:

• A central Organization Root with deny-list SCPs restricting access to non-approved services
• A single “CoreProduction” OU containing all existing member accounts
• Standardized AWS Config rules enforcing compliance baselines

Following the acquisition of RegionalMart, a regional competitor, the Cloud Governance team invited RegionalMart’s existing AWS account into the organization. Upon joining, RegionalMart’s infrastructure team immediately encountered permission errors when attempting to modify their existing AWS Config rules to align with GlobalRetail’s compliance requirements.

The Cloud Governance team needs to enable RegionalMart’s team to complete their configuration updates while:

• Maintaining existing security guardrails
• Avoiding permanent security exceptions
• Minimizing ongoing administrative overhead

The Requirement

#

Enable the acquired account’s administrators to update AWS Config rules during onboarding while preserving organizational security controls and minimizing long-term maintenance burden.

The Options

#

A) Remove the AWS Config restriction from the Organization Root SCP; create an AWS Service Catalog product containing standardized AWS Config rules and deploy it across all accounts including the new acquisition.

B) Create a temporary “MergersOnboarding” OU for the acquired account; apply an SCP to this OU that allows AWS Config operations; after configuration is complete, move the account to the CoreProduction OU.

C) Convert the Organization Root’s deny-list SCP to an allow-list model permitting only essential services; temporarily apply an SCP at the Organization Root that allows AWS Config actions exclusively for principals in the acquired account.

D) Create a temporary “MergersOnboarding” OU for the acquired account; apply an SCP allowing AWS Config operations to this OU; migrate the existing Organization Root SCP to the CoreProduction OU; after configuration completion, move the acquired account to the CoreProduction OU.

Correct Answer

#

Option D.

The Architect’s Analysis

#

Correct Answer

#

Option D.

The Winning Logic

#

Option D solves the governance-agility paradox through temporal isolation and policy migration:

1. Temporal Isolation: Creating a dedicated “MergersOnboarding” OU with permissive SCPs provides controlled flexibility without weakening organization-wide security posture.

2. Policy Migration: Moving the restrictive SCP from Organization Root to CoreProduction OU ensures existing accounts remain protected while creating a structured exception pathway.

3. Zero Permanent Exceptions: Unlike Options A or C, this approach maintains the original security baseline—the acquired account eventually inherits the same restrictions as all production accounts.

4. Reusable Pattern: This architecture establishes a repeatable integration framework for future acquisitions without requiring SCP re-engineering each time.

5. Minimal Long-term Overhead: After the one-time migration, the OU structure requires no additional maintenance beyond the standard account move operation.

The Trap (Distractor Analysis)

#

Why not Option A?

• Permanent Security Degradation: Removing AWS Config restrictions from the Organization Root creates a permanent security gap across all accounts.
• Operational Debt: AWS Service Catalog deployment introduces ongoing product version management, distribution complexity, and requires IAM permissions management across accounts.
• Cost Inefficiency: Service Catalog portfolios incur administrative overhead ($1,200-$3,600 annually for maintenance) versus zero-cost SCP operations.

Why not Option B?

• Incomplete Protection: The Organization Root SCP still applies even when accounts are in child OUs—SCP policies are cumulative and restrictive. The temporary OU’s permissive SCP cannot override a deny statement from the parent root.
• Architectural Misunderstanding: This reflects a fundamental misunderstanding of SCP inheritance—deny statements always win regardless of OU hierarchy depth.

Why not Option C?

• Extreme Complexity: Converting deny-list to allow-list SCPs requires auditing all existing service usage across dozens of accounts—a multi-week effort prone to breaking existing workloads.
• Principal-Based Exceptions Don’t Scale: Conditioning SCP statements on specific principals creates brittle, account-specific logic that violates the principle of policy reusability.
• Temporary Root-Level Changes Are High-Risk: Any misconfiguration at the Organization Root impacts all accounts simultaneously, creating blast radius concerns during change windows.

The Architect Blueprint

#

Diagram Note: The architecture creates a parallel governance track—the Onboarding OU provides temporary flexibility while Production OU maintains inherited restrictions, with a clear migration path after configuration completion.

The Decision Matrix

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For SAP-C02, when you see temporary access requirements during onboarding combined with existing restrictive SCPs, look for solutions using dedicated OUs with time-limited permissive policies rather than weakening organization-wide controls.

Real World

#

In enterprise M&A scenarios, we typically enhance Option D with:

• Infrastructure-as-Code (IaC): Define the Onboarding OU and permissive SCP in AWS Control Tower Account Factory or Terraform modules for one-click provisioning.

• Automated Compliance Gates: Implement AWS Config conformance packs as prerequisites before allowing account migration from Onboarding to Production OU—preventing “configuration drift escapes.”

• Time-Based Guardrails: Set EventBridge rules that alert after 30 days if accounts remain in the Onboarding OU, preventing “temporary” exceptions from becoming permanent.

• Hybrid Service Catalog Approach: After migration, we do deploy Service Catalog products (like Option A suggested) but as a maintenance tool, not an access control mechanism—separating concerns between governance (SCP) and standardization (Service Catalog).

• Cost Allocation Tags: Apply acquisition-specific cost allocation tags during the Onboarding phase to track integration costs separately from BAU operations.

The key difference: Production architects separate access control (SCP) from standardization (Service Catalog/Config)—the exam often conflates these concerns to create plausible distractors.

Disclaimer

This is a study note based on simulated scenarios for the AWS SAP-C02 exam. It is not an official question from the certification body.