AWS Certified DevOps Engineer - Professional (DOP-C02)

재시도 횟수를 늘려도 재시도되는 오류 없는 레코드 수는 줄지 않으며, 보통 증가합니다. Kinesis 배치 재시도에서는 어떤 레코드든 실패를 유발하면 전체 배치가 재시도되므로, 재시도가 많을수록 ERP endpoint로의 중복 전송이 늘고 반복 실패 후 정상 레코드가 DLQ로 떨어질 가능성도 커집니다. 또한 downstream 부하를 증가시키고 idempotency를 더 복잡하게 만들 수 있습니다.

parallelization factor를 늘리면 shard당 동시에 처리되는 배치 수가 증가하여 처리량이 개선되고 지연이 줄어듭니다. 그러나 단 하나의 실패 레코드가 전체 배치를 재시도하게 만드는 근본 동작은 바뀌지 않습니다. 따라서 재시도되거나 DLQ로 전송되는 정상 레코드 수를 줄이지 못하며, 실패 조건에서는 ERP endpoint로의 중복 전달을 오히려 늘릴 수 있습니다.

최대 레코드 수명을 줄이면 Lambda가 오래된 레코드에 대한 재시도를 더 빨리 중단하고 더 이르게 실패 시 destination으로 보냅니다. 이는 배치 내 실패 레코드를 격리하지 못하며, 대신 배치가 계속 실패하고 시간이 경과함에 따라(ages out) 유효한 레코드까지 DLQ로 폐기되는 수가 늘어 손실/노이즈가 증가할 수 있습니다. 복구 시간은 줄지만 더 큰 데이터 손실/노이즈를 대가로 합니다.

Route 53 health checks는 Regional API endpoints 간 failover를 제공할 수 있지만, 이 설계는 복제 메커니즘이 없는 별도의 Region 로컬 DynamoDB tables를 사용합니다. 이는 두 Region 모두에서 쓰기가 가능하고 Region 간 데이터 일관성을 유지하는 active-active 운영 요구 사항을 충족하지 못합니다. 또한 reconciliation을 위한 운영 복잡성을 만들고 부분 장애 동안 상태가 분기될 수 있습니다.

이는 커스텀 장애 조치 메커니즘을 가진 사실상 active-passive입니다. 5분마다 Lambda를 실행하여 health를 probe하고 Route 53을 업데이트하는 방식은 네이티브 Route 53 health checks보다 느리고 추가적인 실패 모드 및 전파 지연을 유발합니다. 또한 built-in health checks와 active-active 트래픽 처리를 원하는 99.99% 고가용성 및 자동 장애 조치 요구 사항과 충돌합니다.

us-east-1의 단일 API Gateway는 multi-Region이 아니며 단일 장애 지점 및 EU 가맹점에 대한 지연 시간 병목이 됩니다. API Gateway는 네이티브로 “가장 가까운 Region” 기능처럼 다른 Region의 Lambda로 요청을 투명하게 전달할 수 없으며, cross-Region invocation은 지연과 복잡성을 추가합니다. 단일 Region DynamoDB table 또한 multi-Region active-active writes 요구 사항을 충족하지 못합니다.

DeletionPolicy: Delete는 stack이 삭제될 때 해당 리소스를 어떻게 처리할지 CloudFormation에 지시할 뿐이며, bucket이 삭제되기 전에 비어 있어야 한다는 S3의 요구 사항을 무시하지는 못합니다. versioning이 활성화된 경우 delete marker와 이전 version도 여전히 내용물로 간주됩니다. 객체/버전이 남아 있으면 stack은 여전히 DELETE_FAILED로 실패하므로 근본 원인을 해결하지 못합니다.

bucket(버전 포함)을 수동으로 비우면 동작은 하지만, 효율적이지 않고 자동 제거 요구 사항을 충족하지 못합니다. 특히 매일 밤 proof-of-concept stack에 대해 운영 부담과 정리 불일치 위험을 초래합니다. 인증 시험 문제에서는 자동화된 IaC 기반 접근이 가능한 경우 수동 단계를 보통 감점 요소로 봅니다.

CodePipeline로 대체하는 것은 불필요하며 핵심 문제를 해결하지 못합니다. S3 bucket 삭제는 versioned content를 비우는 것이 필요합니다. 종료를 위해 pipeline stage를 두는 것은 단순한 stack lifecycle 관리에 대한 anti-pattern이며 복잡성, 비용, 유지보수를 증가시킵니다. CloudFormation은 이미 리소스 생성/삭제를 오케스트레이션하므로, 부족한 부분은 자동 bucket cleanup이며 이는 custom resource로 처리하는 것이 최선입니다.

오답입니다. 여러 Region에 Single-AZ Aurora 클러스터를 두는 것만으로는 Region 간 지속적 복제가 제공되지 않으므로 RPO가 보장되지 않습니다. Single-AZ는 각 Region 내 가용성도 낮추고 AZ 수준 장애에 대한 복구 시간도 증가시킵니다. “Aurora 자동 복구”는 주로 Region 내 인스턴스/스토리지 장애를 다루며, 보장된 RPO/RTO 목표를 가진 cross-Region DR을 의미하지 않습니다.

오답입니다. 독립적인 Aurora 클러스터를 NLB 뒤에 두고 서로 대체 가능한 엔드포인트처럼 Region 전반에 걸쳐 SQL 트래픽을 분산할 수는 없습니다. 이는 일관된 읽기/쓰기를 제공하지 못하고, 지원되는 multi-writer 아키텍처 없이 데이터 불일치를 초래합니다. Aurora는 이런 방식의 multi-Region active/active writer를 지원하지 않으며, NLB는 데이터베이스 복제나 일관성 메커니즘이 아닙니다.

이 옵션은 예상되는 시험 정답은 아니지만, 설명은 더 정확해야 합니다. AWS Global Accelerator는 사용자를 다른 Region의 정상 ALB endpoint로 라우팅하여 application tier에 대해 빠른 cross-Region failover를 제공할 수 있으므로, 순수한 application availability 관점에서는 필요한 RTO를 지원할 수 있습니다. 그러나 이 문제는 일반적으로 disaster recovery와 연관되는 deployment strategy 조합을 묻고 있으며, Route 53 failover routing이 regional failover에 대해 시험에서 더 전형적으로 다루는 AWS DR 패턴입니다. 또한 두 ALB를 단일 endpoint group에 배치한다는 표현은 일반적인 multi-Region design pattern이 아니므로, application component에 대해서는 D가 더 명확하고 표준적인 선택입니다.

오답입니다. AmazonRDSFullAccess는 IAM 정책입니다. IAM 권한은 SCP의 명시적 Deny를 재정의할 수 없습니다. 오류에 작업이 Organizations SCP에 의해 차단되었다고 명시되어 있으므로, SCP가 rds:CreateDBInstance를 더 이상 거부하지 않기 전까지 IAM 권한을 추가(관리자 포함)해도 도움이 되지 않습니다.

오답입니다. ext-ml 계정에 RDS를 허용하는 새 SCP를 연결해도 analytics OU SCP의 명시적 Deny를 재정의하지 못합니다. SCP는 가드레일로 결합되며, 적용되는 SCP 중 어느 하나에라도 명시적 Deny가 있으면 작업이 차단됩니다. OU SCP의 거부 조건을 제거/수정(또는 계정 이동)해야 합니다.

오답입니다. 루트 OU SCP가 모든 작업을 허용하더라도 하위 OU SCP의 명시적 Deny를 취소하지 못합니다. SCP 평가는 적용되는 모든 SCP 제약에서 작업이 허용되어야 하며, 어떤 명시적 Deny라도 우선합니다. 따라서 루트에 allow-RDS SCP를 추가해도 명시적으로 거부하는 OU에서 RDS를 활성화할 수 없습니다.

오답입니다. AWS Health를 event source로 사용하는 것은 올바른 출발점이지만, EventBridge에서 AWS-RestartEC2Instance를 직접 대상으로 지정하면 이벤트를 수신하는 즉시 automation이 실행됩니다. 즉, reboot가 승인된 Sunday 01:00–03:00 UTC maintenance window를 기다리지 않고 즉시 발생하게 됩니다. 따라서 source service는 적절하지만 이 선택지는 핵심 scheduling 요구 사항을 충족하지 못합니다.

오답입니다. Systems Manager maintenance window event는 scheduled instance retirement 또는 underlying host maintenance 알림을 감지하기 위한 올바른 트리거가 아닙니다. 영향을 받는 resource와 maintenance 요구 사항은 maintenance window 자체가 아니라 AWS Health에서 발생합니다. 또한 이 선택지는 영향을 받는 특정 EC2 instance를 어떻게 식별하고 restart automation에 전달할 것인지 설명하지 않습니다.

오답입니다. EC2 instance state-change notification은 예정된 retirement 또는 host maintenance action에 대한 authoritative signal이 아닙니다. 이러한 알림은 AWS Health에서 오며 disruptive event 전에 게시되므로 remediation을 계획할 수 있습니다. Lambda가 maintenance window task를 등록할 수는 있지만, 이 선택지는 잘못된 event source에서 시작하므로 필요한 사전 대응을 놓칠 수 있습니다.

오답. AWS Config rule은 리소스 컴플라이언스를 평가하고 알림/수정 조치를 트리거할 수 있지만, 버전 관리된 파일을 EC2 인스턴스에 배포하도록 설계되지 않았다. 파일 내용을 InputParameters에 넣는 것은 인스턴스 부트스트래핑을 위한 실용적이거나 의도된 메커니즘이 아니다. Systems Manager Resource Data Sync는 구성을 적용하기 위해 “구성 업데이트를 폴링”하는 것이 아니라, 보고를 위해 인벤토리/컴플라이언스 데이터를 S3로 동기화한다.

cfn-init + cfn-hup이라는 아이디어는 부분적으로 맞지만, 배치가 잘못되었다. cfn-hup이 모니터링하는 것은 launch template이 아니라 CloudFormation 리소스 metadata 변경이다. 구성이 launch template 데이터에만 있으면, CloudFormation::Init metadata로 관리하고 cfn-init을 다시 실행하도록 하지 않는 한, 기존 인스턴스는 stack 변경으로 자동 업데이트되지 않는다.

오답. Launch Template에 구성을 포함하는 것은 새로 시작되는 인스턴스에만 영향을 주며, 인스턴스를 교체하지 않고 3분 이내에 이미 실행 중인 인스턴스를 업데이트하지 못한다. 또한 Systems Manager Resource Data Sync는 구성 배포 메커니즘이 아니며 인스턴스에 파일 변경을 적용하지 않는다. 이 옵션은 인플레이스 업데이트 요구 사항과 SSM 기능의 올바른 사용 모두를 충족하지 못한다.

오답입니다. rolling update 전에 ALB listener를 tg-green으로 전환하면, 트래픽이 launching 중이거나 health check에 실패하거나 이전/부분 버전을 실행 중인 인스턴스로 전달될 수 있습니다. ALB는 healthy target으로만 라우팅하므로 배포 중 용량 감소 또는 5xx/connection 문제가 발생할 수 있어, cutover 동안 영향 최소화 요구 사항을 위반합니다.

오답입니다. blue launch template을 업데이트하고 api-blue-asg를 rolling 방식으로 교체하는 것은 blue/green cutover가 아니라 rolling deployment입니다. 100% 트래픽을 즉시 전환하지 못하고 동일 target group 뒤에서 인스턴스를 점진적으로 교체합니다. 이는 위험(혼재된 버전이 트래픽 처리) 증가로 이어지며, 인스턴스 교체로 용량 저하나 오류가 발생하면 30초 미만 영향 요구 사항을 초과할 수 있습니다.

오답입니다. Route 53을 변경하여 “green endpoint”를 가리키게 하는 것은 AWS가 통제할 수 없는 DNS 캐싱 및 propagation 동작에 의존합니다. TTL이 300초여도 클라이언트와 resolver가 더 오래 캐시할 수 있으며, ALB로의 기존 TCP/TLS session은 즉시 이동하지 않습니다. 요구 사항에서 cutover에 DNS propagation 의존을 명시적으로 금지합니다.

CloudFormation service role은 권한을 표준화할 수 있지만, 팀이 임의/raw CloudFormation template을 사용하는 것을 방지하지는 못합니다. 여전히 원하는 어떤 template이든 제출할 수 있습니다. 또한 CloudFormation drift detection은 항상 동작하는 중앙집중식 multi-account/multi-Region compliance 메커니즘이 아니며, stack 범위로 제한되고 일반적으로 필요 시(on demand) 실행됩니다. 또한 stack으로 관리되지 않는 리소스는 커버하지 못합니다.

AWS Config managed rule은(aggregator와 함께라면) account/Region 전반에서 비준수 구성을 탐지할 수 있지만, 이 옵션은 거버넌스 요구 사항을 충족하지 못합니다. 여전히 팀이 raw template에서 CloudFormation stack을 직접 배포하도록 허용합니다. Service role은 CloudFormation이 무엇을 할 수 있는지를 제어할 뿐, 사용자가 어떤 template을 제출할 수 있는지를 제한하지는 못합니다. 문제는 사전 승인된 blueprint를 통해서만 프로비저닝하고 raw template 사용을 방지할 것을 명시적으로 요구합니다.

Service Catalog는 승인된 product에 도움이 되고 template constraint는 parameter 값을 제한할 수 있지만, 14개 account와 6개 Region 전반에서의 중앙집중식, 지속적인 drift/compliance 탐지를 다루지 못합니다. CloudFormation drift detection event는 stack drift에만 제한되며(더 광범위한 configuration compliance가 아님), EventBridge notification에 의존하는 것은 drift detection이 실행되고 있다는 전제를 필요로 하며 AWS Config만큼 포괄적이고 집계된 compliance 뷰를 제공하지 못합니다.

오답입니다. 교차 계정 복사를 위해 DR 계정이 소스 계정의 백업 볼트에서 읽을 필요는 없습니다. 복사는 백업 플랜에 따라 AWS Backup이 시작하여 대상 볼트에 씁니다. 볼트에 대한 핵심 권한 지점은 소스 볼트 정책에서 읽기를 부여하는 것이 아니라, 대상 볼트 정책에서 쓰기를 허용하는 것입니다.

오답입니다. 백업 볼트 정책은 다른 계정의 KMS 키에 대한 액세스를 부여하지 않습니다. KMS 권한 부여는 백업 볼트 액세스 정책이 아니라 KMS 키 정책(및 경우에 따라 grants)에 의해 제어됩니다. DR 계정에서 대상 CMK 정책을 업데이트하여 AWS Backup(및 소스 계정 컨텍스트)이 이를 사용할 수 있도록 해야 합니다.

오답입니다. DR 소유 CMK로 암호화된 DR 볼트로 교차 계정 복사를 수행하는 데 소스 계정 CMK(alias/ops-backup)를 DR 계정과 공유하는 것은 주요 요구 사항이 아닙니다. AWS Backup은 복구 지점을 복사하고 대상 볼트의 암호화 키를 사용하여 다시 암호화합니다. 누락되는 권한은 일반적으로 대상 볼트 정책과 대상 CMK 정책에 있습니다.

오답입니다. CodeBuild는 S3 authorization를 강제하는 custom “AllowedBuckets” 설정이라는 security control을 제공하지 않습니다. AWS CLI로 전환하더라도 여전히 public access를 제거하고 bucket policy/IAM permissions가 올바르게 구성되었는지 확인해야 합니다. 이 옵션은 모호하며, public access를 차단하고 IAM 기반 authentication을 강제해야 한다는 요구 사항을 명시적으로 충족하지 않습니다.

오답입니다. S3는 native bucket 기능으로 “HTTPS basic authentication”을 지원하지 않습니다. 또한 cURL과 static token을 사용하는 것은 build environment에 장기 credentials를 저장해서는 안 된다는 요구 사항을 위반합니다. 이 접근 방식은 secret management 위험을 초래하며, service-to-service authentication에 대한 AWS 모범 사례와도 일치하지 않습니다.

오답입니다. IAM access key와 secret access key를 environment variables에 포함하는 것은 명시적으로 금지됩니다(“장기 credentials 금지”). 또한 logs, misconfiguration 또는 손상된 build container를 통해 유출될 경우 blast radius를 증가시킵니다. 안전한 패턴은 static IAM user key가 아니라 temporary credentials와 함께 CodeBuild service role을 사용하는 것입니다.

이는 즉흥적인 파이프라인(FSx NFS -> S3 -> CRR)으로 복잡성을 추가하며, NFS로 마운트된 애플리케이션에 대한 “file storage” DR 의도에 부합하지 않을 가능성이 큽니다. storage interface를 변경(NFS에서 object로)하고, 변경 사항 감지/복사, 삭제 처리, 권한, 일관성을 처리하기 위한 custom logic이 필요합니다. 10분 RPO를 안정적으로 충족하지 못할 수 있으며 FSx for ONTAP DR 패턴도 아닙니다.

AWS Backup은 FSx for ONTAP backups 및 cross-Region copy를 지원하지만, 10분 backup frequency는 일반적으로 비현실적이며 이 워크로드에 대해 표준 plan frequency로 지원되지 않을 수 있고, backup/restore는 near-real-time replication과 동일하지 않습니다. 설령 자주 스케줄링하더라도 backup jobs와 copy jobs가 지연과 운영 불확실성을 유발하여 10분 RPO 위반 위험이 있습니다.

이는 잘못된 데이터를 대상으로 합니다. 문제에서 애플리케이션 데이터가 EKS nodes에 저장되지 않는다고 했고, instance store volumes는 ephemeral이며 EBS snapshots로 스냅샷을 생성할 수 없습니다. 설령 nodes가 EBS를 사용하더라도 worker nodes를 snapshotting해도 FSx for ONTAP의 공유 NFS 상태는 캡처되지 않습니다. 이 옵션은 기술적으로도 결함이 있고 명시된 아키텍처와도 맞지 않습니다.

오답. 계정 B에 새 ECR 리포지토리를 생성하는 것은 이미지가 계속 계정 A의 단일 ECR 리포지토리에서 pull되어야 한다는 요구사항(중복 리포지토리 금지)을 직접 위반한다. endpoint는 프라이빗 연결에 도움이 되지만, 이 옵션은 소스 오브 트루스를 계정 B의 로컬 리포지토리로 바꾸며 이는 컴플라이언스 요구사항에서 명시적으로 금지된다.

오답. 교차 계정 리포지토리 정책과 IAM 권한은 필요하지만 충분하지 않다. 계정 B의 프로덕션 VPC에는 IGW 또는 NAT가 없으므로 VPC endpoint가 없으면 EKS 노드가 ECR API/registry endpoint 또는 이미지 레이어를 다운로드하기 위한 S3에 도달할 수 없다. 네트워크 경로가 없어 이미지 pull이 실패하며, 트래픽을 AWS 프라이빗 네트워크로 제한할 수도 없다.

오답. ECR private image replication은 계정 B에 리포지토리/이미지의 복사본(대상 리포지토리)을 생성하게 되며, 이는 리플리케이션 또는 중복 리포지토리가 허용되지 않고 이미지가 계속 계정 A의 단일 리포지토리에서 pull되어야 한다는 요구사항을 위반한다. 리플리케이션은 멀티 계정 복원력을 위한 일반적인 모범 사례이지만, 여기서는 명시적으로 금지되어 있다.

오답입니다. AWS X-Ray는 microservices 전반의 요청 흐름과 지연 시간을 분석하는 APM 및 distributed tracing 서비스입니다. S3의 CSV 데이터를 쿼리하거나 table metadata를 관리하거나 BI dashboard를 제공하지 않습니다. ingestion pipeline 애플리케이션을 추적하는 데는 사용할 수 있지만, 여기서 설명된 SQL analytics 및 시각화 요구 사항을 충족하지 않습니다.

“least effort” 관점에서 오답입니다. Amazon Redshift는 대규모 dataset을 쿼리할 수 있고 BI dashboard를 지원하지만, 일반적으로 더 많은 설정이 필요합니다. cluster를 프로비저닝/운영하거나(Redshift Serverless 구성 포함), schema를 설계하고, 최적의 성능을 위해 데이터를 로드/변환(COPY/ETL)해야 하는 경우가 많습니다. 이미 S3에 시간별 CSV 파일이 있고 ad hoc 쿼리가 필요하다면 Athena가 더 단순하고 더 serverless합니다.

오답입니다. Amazon DynamoDB는 NoSQL key-value/document 데이터베이스이며 Athena/Presto 스타일의 SQL 쿼리를 위한 네이티브 metastore가 아닙니다. DynamoDB를 사용해 schema/partition metadata를 저장하려면 동기화를 유지하기 위한 custom 로직을 구축하고 유지해야 하며, Glue Data Catalog처럼 Athena 및 QuickSight와 매끄럽게 통합되지 않습니다.

CloudTrail + Athena는 주로 로그 분석 접근 방식이며 강력한 준실시간 컴플라이언스 통제가 아니다. Athena 쿼리는 보통 scheduled/batch로 실행되며 추가 오케스트레이션을 구축하지 않는 한 5분 이내 통지를 보장하지 않는다. 또한 개발자가 snapshot을 public으로 만드는 것을 방지하지 못하고 사후에 시도/이벤트를 탐지할 뿐이다. Lambda로 remediation은 가능하지만, 이 옵션은 Config + explicit deny 가드레일보다 약하고 더 복잡하다.

단순히 “권한을 부여하지 않기”로 제거하는 것은 지속적인 가드레일이 아니다. 향후 정책 변경으로 실수로 다시 추가될 수 있고, 다른 principal이 여전히 해당 권한을 가질 수도 있다. 5분마다 실행되는 Lambda는 polling 기반으로 운영 오버헤드가 있으며 실행 사이의 변경을 놓치거나 조용히 실패할 수 있다. AWS Config는 지속적 컴플라이언스를 위해 설계되었고 알림과 깔끔하게 통합되므로 이 옵션은 열등하다.

RDS DB snapshot에는 IAM role이 연결되지 않으므로 전제가 틀렸다. IAM permission은 snapshot에 role을 붙이는 것이 아니라 principal(user/role)에 연결된다. AWS Config가 public snapshot을 확인할 수는 있지만, 설명된 메커니즘(deny statement가 있는 role이 snapshot에 연결되어 있는지 검증)은 구현 불가능하다. 이 옵션은 IAM permission 모델과 RDS snapshot 제어 방식에 대한 오해를 반영한다.