Practice Test #1

health check가 포함된 Route 53 latency-based routing은 DNS를 전환할 수 있지만 cross-Region read replica를 writer로 승격하지는 않습니다. Aurora cluster endpoint에 대한 health check는 오해를 유발할 수 있으며(endpoint가 해석되더라도 writer가 손상될 수 있음), DNS 캐싱/TTL은 엄격한 2분 감지 및 빠른 전환 요구사항을 위반할 수 있습니다. CloudTrail은 RDS 장애 알림의 올바른 소스가 아니며, 서비스 failover 이벤트가 아니라 API 활동을 로깅합니다.

Aurora custom endpoint는 단일 Aurora cluster 내에서 라우팅(예: 일부 instance 집합)을 위한 것이며 Region을 넘나들지 않고 cross-Region replica promotion을 관리하지도 않습니다. 또한 eu-central-1의 custom endpoint를 “업데이트”하여 eu-west-1의 cluster/instance를 가리키게 할 수 없습니다. 데이터베이스 unavailability의 트리거로 CloudTrail을 사용하는 것도 잘못인데, CloudTrail은 서비스 health/failover 이벤트를 내보내지 않기 때문입니다.

장애 중 CloudFormation stack을 수정하고 재적용하는 것은 느리고 운영상 위험하며, writer endpoint unreachability에 기반해 cross-Region replica를 승격해야 한다는 요구사항을 직접적으로 해결하지 못합니다. CloudFormation은 RDS failover를 위한 이벤트 시스템이 아니며, stack 업데이트는 요구되는 RTO를 초과할 수 있습니다. 또한 인프라 배포와 사고 대응 자동화를 불필요하게 결합합니다.

매주 스케줄된 EventBridge rule은 5분 요구사항을 충족할 만큼 반응성이 없습니다. retirement event를 며칠 늦게 감지할 수 있으며, “이벤트를 확인”하는 방식도 일반적인 패턴이 아닙니다—AWS가 이미 이벤트를 발생시킵니다. 또한 hibernation은 요청된 작업(stop 후 start)이 아니고, hibernation 전제 조건이 필요하며, 모든 인스턴스 구성에서 지원되거나 적절하지 않을 수 있습니다.

EC2 Auto Recovery는 scheduled instance retirement events가 아니라 기본 하드웨어/호스트 impairment(CloudWatch alarm의 StatusCheckFailed_System로 트리거됨)에서 복구하도록 설계되었습니다. 또한 stop/start 사이클을 수행하지 않고, 인스턴스 ID를 유지한 채 새 하드웨어에서 인스턴스를 복구합니다. AWS Config를 추가해 recovery를 특정 시간대로 제한하는 것은 이 시나리오에서 표준적이거나 신뢰할 수 있는 제어가 아닙니다.

모든 인스턴스를 매주 reboot하는 것은 요구사항인 “영향받는 인스턴스만 재시작”을 위반하는 무차별적이고 비표적 접근 방식입니다. 또한 scheduled retirement event의 remediation을 보장하지 않는데, 이는 일반적으로 reboot가 아니라 stop/start(또는 교체)가 필요합니다. 알림을 위한 CloudWatch alarms는 모니터링을 추가하지만, 5분 이내에 필요한 자동화된 이벤트 기반 remediation을 제공하지 않습니다.

오답입니다. 99/1 weighted 분할은 primary가 healthy일 때도 client 요청의 일부를 standby로 라우팅합니다. 시나리오에서 broker는 여러 active node에 걸쳐 동작할 수 없다고 명시되어 있으므로, 정상 상태에서 standby로 트래픽이 지속적으로 유입되면 동시 active 처리, session/state 충돌, offset 불일치 위험이 있습니다. weighted routing은 standby가 사실상 0 트래픽을 받지 않는 한 active/passive와 동일하지 않습니다.

오답입니다. ALB는 health check를 수행할 수 있지만, listener target group weight를 100과 0으로 사용하는 것은 엄격한 failover를 구현하는 신뢰할 수 있는 방법이 아니며, “primary가 unhealthy가 되기 전에는 standby로 트래픽을 절대 보내지 않음”과 정렬되지 않는 라우팅 동작을 시도할 수 있는 항상-on load balancer 계층을 추가합니다. single-active 워크로드에는 Route 53 health check 기반 DNS failover가 더 단순하고 적절한 메커니즘입니다.

오답입니다. 옵션 B와 마찬가지로 99/1 weight를 사용하면 정상 동작 중에도 standby로 일부 트래픽이 전송되어 single-active 제약을 위반합니다. 또한 ALB target group weighting은 엄격한 warm-standby failover가 아니라 트래픽 분산(카나리/blue-green)을 위해 설계되었습니다. 두 인스턴스가 동일한 EFS를 마운트하더라도 동시 처리 및 state/offset 문제가 발생할 수 있습니다.

Amazon GuardDuty는 suspicious activity를 위해 logs와 telemetry를 분석하는 threat-detection service이지, 모든 RDS public accessibility change를 결정적으로 탐지하기 위한 configuration-governance service가 아닙니다. RDS DB instance에서 PubliclyAccessible가 true가 될 때마다 반드시 SNS notification을 보내야 한다는 직접적인 control을 제공하지 않습니다. GuardDuty findings는 자체 detection logic과 finding generation에도 의존하므로, 이 compliance 스타일 요구 사항에 가장 정확하게 부합하지 않습니다. 따라서 이 옵션은 특정 RDS configuration state change에 대해 중앙에서 governance되는 notification 요구 사항을 깔끔하게 충족하지 못합니다.

CloudTrail과 EventBridge는 ModifyDBInstance API call을 빠르게 탐지할 수 있지만, 이 설계는 EventBridge rule과 SNS topic을 각 member account에 배포하므로, notification path가 우회 방지 대상인 accounts 내부에 존재하게 됩니다. 정답 해설은 SCPs 추가에 의존하지만, 제안된 solution에는 SCPs가 포함되어 있지 않으며 anti-bypass 주장을 신뢰할 수 있게 만들려면 SCPs가 필요합니다. 또한 이 접근 방식은 결과 resource state에 대한 중앙 governance compliance evaluation이 아니라 특정 API call에 대한 event-based 방식입니다. 문제에서 delegated administrator와 member-account의 비활성화 또는 우회 방지를 강조하므로, 이 분산형 StackSets 설계는 최선의 답이 아닙니다.

Amazon Inspector는 특정 RDS configuration attribute change에 대해 보장된 near-real-time notification을 제공하는 것이 아니라 vulnerability management와 exposure assessment에 초점을 둡니다. Inspector findings는 RDS DB instance에서 PubliclyAccessible가 true로 설정되었는지 탐지하는 정식 메커니즘이 아닙니다. 이 서비스는 AWS Config managed rules만큼 이 governance requirement에 직접적으로 부합하지 않습니다. 결과적으로 이 옵션은 명시된 compliance 및 notification 목표에 대해 덜 정확하고 덜 신뢰할 수 있습니다.

불필요한 복잡성과 오버헤드를 추가합니다. instance에 tag를 붙이고 IMDS와 EC2 API를 호출하려면 추가 IAM permission, network/API 가용성, tag를 environment로 매핑하는 추가 로직이 필요합니다. 또한 throttling, tag 누락 등 배포와 무관한 실패 요인을 도입합니다. CodeDeploy는 이미 deployment group context를 script에 직접 제공하므로, 이는 최소 관리 접근이 아닙니다.

CodeDeploy는 여기서 암시하는 방식으로 hook script에 대해 deployment group별 임의의 “custom environment variable”을 지원하지 않습니다. 일반적으로 built-in variable을 사용하거나 필요 시 Parameter Store/Secrets Manager 같은 외부 configuration source를 사용합니다. 또한 ValidateService는 보통 배포 후 검증을 위한 단계이므로, 그 시점에 Nginx configuration을 변경하면 reload/restart도 함께 해야 하는 등 흐름이 복잡해지고 불일치가 발생할 수 있습니다.

DEPLOYMENT_GROUP_ID는 사람이 이해하기 쉬운 environment 매핑을 위한 적절한 selector가 아니며, 이 목적에는 일반적으로 DEPLOYMENT_GROUP_NAME을 사용합니다. ID가 사용 가능하더라도 ID-to-environment 매핑을 유지해야 하므로 운영 오버헤드가 증가합니다. 또한 Install hook은 configuration 변경에 BeforeInstall/AfterInstall만큼 일반적으로 사용되지 않습니다.