Practice Test #10

오답입니다. Application Load Balancer에는 Elastic IP 주소를 할당할 수 없습니다. ALB는 DNS 이름을 통해 접근되며 기본 IP는 확장 및 유지 관리로 인해 시간이 지남에 따라 변경될 수 있습니다. IP allowlisting 요구 사항의 경우, 다른 서비스(예: Global Accelerator)와 결합하지 않는 한 ALB 단독으로는 적합하지 않으며, 이는 옵션에 제공되지 않았습니다.

오답입니다. Route 53 A record는 Elastic IP를 가리킬 수 있지만, 이는 트래픽을 단일 public 엔드포인트로 라우팅하며 load balancing이나 내재적인 다중 AZ 복원력을 제공하지 않습니다. load balancer를 단일 IP target으로 대체하게 되어 단일 장애점(single point of failure)을 생성하고 관리형 load balancing 동작을 잃게 됩니다.

오답입니다. load balancer 앞에 public EC2 proxy를 배치하면 고정 IP를 제공할 수 있지만, 이는 복원력 및 운영 측면에서 안티 패턴입니다. 단일 장애점을 도입하고(여러 proxy를 구축하고 관리하지 않는 한), 패치/유지 관리 부담을 가중시키며, 병목 현상이 될 수 있습니다. 가용성과 보안을 위해 AWS 관리형 솔루션(EIP가 있는 NLB)이 선호됩니다.

최소 오버헤드를 위한 최선의 선택이 아닙니다. aws:PrincipalOrgPaths는 OU 멤버십을 기반으로 액세스를 제한할 수 있지만, 계정이 OU 간에 이동하거나 OU 구조가 변경될 경우 추가적인 복잡성과 잠재적인 유지 관리가 발생합니다. 요구 사항은 단순히 'Organization 내'이므로 Organization ID를 사용하는 것이 OU 경로 기반 제어보다 더 간단하고 안정적입니다.

운영 오버헤드가 높습니다. 조직 멤버십 변경을 감지한 다음 버킷 정책을 다시 작성하는 CloudTrail 기반 자동화는 복잡하고 불안정하며 불필요합니다. 이는 움직이는 요소(규칙, 함수, 권한, 오류 처리)를 추가하고 정책 편차 또는 지연된 적용의 위험을 초래합니다. 네이티브 IAM 조건 키는 사용자 지정 자동화 없이도 이미 실시간 평가를 제공합니다.

요구 사항과 일치하지 않으며 관리 작업이 증가합니다. 각 사용자(또는 역할)에 태그를 지정하고 aws:PrincipalTag를 강제하려면 25개 계정 전체에서 일관된 태그 거버넌스와 자격 증명 변경에 따른 지속적인 수명 주기 관리가 필요합니다. 또한 보안 주체가 Organization에 속해 있다는 것을 본질적으로 보장하지 않고 태그가 있다는 것만 보장하므로, Organization 멤버십에 대해 가장 신뢰할 수 있거나 유지 관리가 최소화된 제어 방법이 아닙니다.

CloudFormation 템플릿과 Systems Manager Automation은 프로비저닝을 표준화하는 데 도움이 되지만, 추가적인 제한적 IAM/SCP 제어가 마련되어 있지 않는 한 사용자가 콘솔/CLI/SDK를 통해 리소스를 시작하는 것을 방지하지는 못합니다. 여러 계정에 걸쳐 "템플릿을 사용해야 함"을 강제하려면 일반적으로 지속적인 IAM 정책 엔지니어링, 권한 경계 및 예외 처리가 필요하여 운영 오버헤드가 증가합니다. 이는 중앙 집중식 예방 가드레일이라기보다는 표준화 접근 방식에 가깝습니다.

Lambda 종료가 포함된 EventBridge 규칙은 탐지적/사후 대응적 제어입니다. 값비싼 instance가 상당한 비용을 발생시킬 만큼 충분히 오래 실행될 수 있으며, 자동화된 종료는 합법적인 테스트 워크플로를 방해할 수 있습니다. 또한 운영 복잡성(규칙 범위, 엣지 케이스, 재시도, 권한, 다중 리전 고려 사항)을 추가하며, 이벤트에 캡처되지 않는 방식으로 리소스가 생성되거나 종료가 실패할 경우 우회될 수 있습니다. 여기서는 예방적 제어가 선호됩니다.

Service Catalog는 사전 승인된 제품을 제공하고 거버넌스를 개선할 수 있지만, IAM 권한을 엄격하게 제한하지 않는 한(어쨌든 종종 SCP를 사용함) 사용자 카탈로그 외부에서 리소스를 프로비저닝할 수 없음을 보장하지는 않습니다. 포트폴리오 출시, 제품 버전 관리, 제약 조건 및 교차 계정 공유는 관리 오버헤드를 추가합니다. 표준화 및 셀프 서비스에는 탁월하지만, SCP는 비용이 많이 드는 리소스 생성을 완전히 방지하는 가장 간단한 방법입니다.

DynamoDB global tables는 single master database architecture가 아니라 multi-active 설계입니다. cross-Region replication은 eventually consistent이며, conflicts는 last-writer-wins semantics로 해결되는데, 이는 financial balances와 trade execution records에 위험합니다. 요구 사항은 global consistency를 유지하는 단일 master database를 명시적으로 요구하며, global tables는 이를 제공하지 않습니다. DynamoDB가 낮은 로컬 지연 시간을 제공할 수는 있지만, 이 문제의 consistency 및 single-writer 의도를 충족하지는 못합니다.

cross-Region read replicas를 사용하는 Amazon RDS for MySQL도 단일 writer와 regional readers를 제공하지만, 일반적으로 이런 유형의 globally distributed, latency-sensitive workload에서는 Aurora보다 기능이 떨어집니다. Aurora는 표준 RDS MySQL보다 더 나은 replication performance, scalability, 그리고 managed features를 제공합니다. B와 C는 architecture 측면에서 유사하므로, 시험에서는 더 최적화된 AWS-native relational 선택지를 기대합니다. 따라서 C는 DynamoDB 옵션보다는 더 가깝지만 최선의 답은 아닙니다.

Aurora Serverless는 제안된 설계가 native single-master replication model을 사용하는 대신 Regions 간 custom Lambda-based synchronization에 의존하기 때문에 올바른 답이 아닙니다. 이는 financial transactions에 대해 불필요한 복잡성, operational risk, 그리고 잠재적인 consistency 문제를 초래합니다. 또한 이 옵션은 모든 trade records와 balances에 대해 하나의 authoritative writer를 명확하게 보장하지도 않습니다. 시험 관점에서 custom cross-Region synchronization은 built-in managed database replication feature보다 거의 항상 선호되지 않습니다.

ro 마운트 옵션을 사용하면 OS 관점에서 쓰기를 방지할 수 있지만 IAM 기반이 아니며 강력한 보안 제어가 아닙니다. 인스턴스에 충분한 권한이 있는 사용자(또는 손상된 루트 프로세스)는 파일 시스템을 읽기-쓰기로 다시 마운트할 수 있습니다. 또한 인스턴스별 구성 및 드리프트 관리가 필요하므로 운영 효율성이 떨어지고 명시된 IAM 기반 요구 사항을 충족하지 못합니다.

elasticfilesystem:ClientWrite에 대한 명시적 거부가 있는 identity-based policy도 해당 roles에 대한 쓰기를 차단하지만 단일 EFS 리소스 정책보다 대규모로 운영 효율성이 떨어지고 오류가 발생하기 쉽습니다. 모든 관련 역할에 거부가 있고 대체 역할이 사용되지 않는지 확인해야 합니다. 질문은 운영 효율성과 중앙 집중식 무결성 제어를 강조하므로 resource-based policy가 더 유리합니다.

EFS access points 및 POSIX 권한은 디렉터리 수준 액세스 및 일관된 UID/GID 매핑을 강제하는 데 유용하지만 주로 IAM 기반 제어는 아닙니다. POSIX 권한이 잘못 구성될 수 있으며, 허용되는 경우 애플리케이션이 다른 경로(다른 access points 또는 직접 마운트)를 통해 파일 시스템에 계속 액세스할 수 있습니다. 이 옵션은 모든 쓰기를 방지하기 위한 기본 IAM 기반 보장이 아니라 심층 방어로 더 좋습니다.