The requirement is to restrict actions by Region to prevent accidental cross-Region operations that could violate data residency rules. The most direct and flexible way to enforce Region-based restrictions in AWS is to use IAM condition keys, specifically aws:RequestedRegion, in identity-based policies (and commonly in permission boundaries or SCPs when managing an organization).
Option B is correct because it applies Region constraints at authorization time. By adding conditions that allow actions only when aws:RequestedRegion matches an approved list (or denies when it matches disallowed Regions), the company can prevent users and roles from creating, modifying, or accessing resources in the wrong Region. This approach is broad and can be applied across many services, not just EC2, making it suitable for enforcing data residency boundaries across a multi-Region footprint.
Option A is too narrow because it restricts only ec2:RunInstances. Data residency concerns typically apply to many services (S3, RDS, DynamoDB, KMS, etc.), and limiting only EC2 does not prevent accidental data operations elsewhere. Option C controls where requests come from (source IP), not which Region is targeted. Option D (AWS Config) is detective, not preventative; it can alert after noncompliant actions occur, which does not meet the requirement to prevent accidental operations.
Therefore, B best meets the requirement by enforcing Region-level guardrails through IAM authorization conditions, helping ensure workloads remain within approved geographic boundaries.
