A healthcare company stores PHI in S3 and shares APIs via VPC endpoints, but leaders fear data exfiltration to external accounts and overly permissive endpoint access. They need to validate that no bucket or endpoint allows unintended external principals. Which data perimeter validation design detects unintended external access?

The correct design is right because IAM Access Analyzer external access analysis continuously evaluates S3 bucket policies and access points to surface findings when unintended external principals are allowed, while reviewing VPC endpoint policies for broad principals (for example, requiring the organization ID) covers the endpoint side, because Access Analyzer does not analyze endpoint policies as a resource type. Applying Organizations SCPs to deny access outside trusted accounts is a sound preventive guardrail commonly used for data perimeters, but it fails by concept as prevention without validation because it does not detect or prove whether existing bucket or endpoint policies already allow unintended access. Enabling S3 access logging with Athena analysis is a legitimate auditing pattern for cross-account request history, but it fails by concept as reactive telemetry rather than policy validation because logs show past traffic and require manual inference instead of evaluating effective permissions for all external principals. Attaching restrictive bucket policies and monitoring Block Public Access compliance is standard hardening for PHI storage, but it fails by concept as incomplete scope because Block Public Access only stops public internet exposure and bucket policies alone do not validate VPC endpoint allowances that can still enable cross-account exfiltration. For exams, distinguish validate and detect from enforce and prevent, since this scenario asks for findings rather than blocking controls. Practically, filter Access Analyzer external findings for S3, review each endpoint policy, and verify only intended principals remain.