How to Block EC2 Launches in Unauthorized Regions Across an Organization?
Short answer
D Create an AWS Organizations service control policy that denies ec2:RunInstances in unauthorized Regions and attach it at the organization root.
Question
What is the MOST operationally efficient solution that meets these requirements?
Key Takeaways
Tests whether you reach for a centralized preventive guardrail (SCP at the org root) rather than per-account IAM controls or after-the-fact detection and termination.
An AWS Organizations service control policy attached at the root is the most operationally efficient way to deny ec2:RunInstances in unauthorized Regions across every current and future account. This page explains why the root-level SCP answer (D) beats per-account IAM policies, permissions boundaries, and EventBridge/Lambda remediation.
Common mistake: Choosing B, a Region-conditioned IAM managed policy attached to all groups in each account, which looks like a deny but must be maintained account by account, misses roles/root users, and does not scale to new accounts.
Expert Analysis
Why the Answer Is Correct
A service control policy in AWS Organizations is the only option that applies a preventive guardrail from one central place. A deny statement for ec2:RunInstances with an aws:RequestedRegion condition blocks the API call before any instance exists, so there is nothing to detect or clean up. Attaching the SCP at the organization root means every OU and member account inherits it, including accounts created later, so no per-account IAM work is needed. It also constrains every IAM principal in member accounts, including role sessions and the account root user, which is what "anyone in the company" implies. The only principal outside SCP enforcement is the organization's management account, which should not host workloads and is a caveat no other option solves better.
Why the Other Options Are Wrong
Option A is detective and reactive: CloudTrail plus EventBridge plus Lambda terminates instances only after RunInstances has already succeeded, leaving a window where unauthorized capacity runs and billing accrues. It also requires maintaining rules and functions in every unauthorized Region, which is heavy operational overhead. Option B attaches a Region-conditioned managed IAM policy to all groups in each account; that is per-account, per-principal work, must be repeated for every new account or group, and does not restrict the account root user. Option C uses a permissions boundary on all IAM users, but boundaries are attached per principal, do not automatically cover roles or the root user, and again require updates in every account. Only D prevents the action centrally and scales without manual upkeep.
Community Comment Notes
Bad_Mat's comment captures the deciding logic: SCPs "apply guardrails across multiple accounts in an organization" from a single central place, so a root-level attachment covers current and future accounts without manual updates. The comment also emphasizes that the block is preventative because unauthorized actions are denied outright rather than terminated after launch, which is exactly the gap in option A. No other commenter disputes this conclusion, and the reasoning aligns with AWS Organizations documentation.
Official Reference
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html
These links open the official vendor documentation in a new tab.
Exam Strategy
When a stem mentions AWS Organizations, "anyone in the company," and "most operationally efficient," look for the root-level SCP that denies the action up front. Eliminate options built on after-the-fact detection and termination or per-account IAM attachments, since those are the classic high-maintenance distractors on SOA-C03.
Frequently Asked Questions
Why is a Region-condition IAM policy in every account less efficient than an SCP?
Does an SCP attached at the organization root cover future AWS accounts?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
Bad_Mat 👍 1 Answered DWhy Option D is BestCentralized Control: Service control policies (SCPs) apply guardrails across multiple accounts in an organization from a single central place.Operational Efficiency: Applying an SCP at the root level instantly covers all current and future accounts without needing manual updates in each individual account.Preventative Security: It blocks unauthorized actions outright rather than reacting after resources are deployed (unlike reactive Lambda remediation).
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →