정답 · 해설

해설

【핵심 용어】 ▸ API Gateway — 서버리스 API 엔드포인트, 관리형 스케일링 ▸ Kinesis Data Stream — 실시간 데이터 수집, 지속적 처리 가능 ▸ Kinesis Firehose — 자동 배치, S3 로드, 변환 통합 ▸ Lambda — 스트림 기반 비동기 처리 【정답 포인트】 ▸ 최소 운영 오버헤드 → 서버리스 선택 (API Gateway + Firehose) ▸ EC2 관리 불필요 → 자동 스케일링, 인스턴스 유지보수 제거 ▸ API + 변환 + 저장 통합 → Firehose의 데이터 변환(Lambda 트리거) + S3 자동 로드 【오답 체크】 (A) EC2 인스턴스 기반 API 호스팅은 수동 관리 오버헤드를 야기합니다. 서버리스 아키텍처가 아니며, Firehose의 자동 배치 로드 및 변환 기능이 중복되고 인스턴스 유지보수 비용이 지속적으로 발생합니다. (B) EC2 기반 API 호스팅은 확장성에 대한 수동 관리가 필요합니다. AWS Glue는 배치 처리에 최적화된 도구로서 실시간 데이터 변환을 지원하지 않으므로 요구사항에 부적합합니다. (D) API Gateway와 AWS Glue는 직접 통합 불가능하며 중간 처리 계층이 필요합니다. Lambda 함수만으로 대규모 실시간 스트림 처리 시 복잡성과 비용이 급증합니다. 【시험 포인트】 ▸ 패턴: "최소 운영 오버헤드" + "실시간 + 변환 + 저장" → Firehose 기반 아키텍처 ▸ API Gateway 선택 이유: 관리형, 스케일링 자동, EC2 제거 ▸ Firehose의 강점: 버퍼링, 변환, 배치 로드 원스톱 제공

해설

【핵심 용어】 ▸ AWS Backup — 중앙식 관리, 일정 자동화, 보존 정책 통합 ▸ Point-in-Time Recovery — 복구 시점 보존 기간 제한(35일) ▸ 운영 효율성 — 자동화, 관리 오버헤드 최소화 【정답 포인트】 ▸ 7년 보관 → 장기 보존 정책 필요 → AWS Backup 일정 + 보존 자동 관리 ▸ "운영 효율성" 키워드 → 수동 작업 제거, 중앙 집중식 관리 ▸ Backup은 DynamoDB 네이티브 지원, 정책 기반 자동화 제공 【오답 체크】 (A) DynamoDB Point-in-Time Recovery는 최대 35일의 보존 기간 제한이 있어서 7년 장기 보존 요구사항을 충족할 수 없습니다. 기간 연장이 불가능합니다. (C) 수동으로 백업을 생성해야 하므로 일정 관리가 매우 복잡해지고, S3 수명 주기 정책 운영 오버헤드가 높아집니다. 자동화 부족으로 인한 관리 비용이 지속적으로 증가합니다. (D) EventBridge + Lambda 커스텀 로직 조합은 일정 관리와 모니터링 복잡성을 크게 증가시킵니다. AWS Backup의 중앙 집중식 관리 및 자동화 기능이 없습니다. 【시험 포인트】 ▸ 패턴: "장기 보존" + "운영 효율" → AWS Backup 중앙 관리 ▸ Point-in-Time Recovery 한계 인식: 35일 제한 ▸ Backup의 가치: 보존 정책 자동화, 멀티 리전 지원 가능

해설

【핵심 용어】 ▸ 온디맨드 모드 — 사용한 만큼만 결제, 즉시 스케일링 ▸ 예측 불가능한 트래픽 — 급증 대응, 사이클 변동성 ▸ 비용 최적화 — 유휴 시간 요금 제거 【정답 포인트】 ▸ "아침 미사용 + 저녁 예측 불가능" → 프로비저닝된 용량 비효율 ▸ "급속 급증" → Auto Scaling 지연 대응 불가 → 온디맨드 필수 ▸ 온디맨드: 0 사용 시 비용 0, 트래픽 즉시 대응 【오답 체크】 (D) 전역 테이블은 여러 리전 간 고가용성 달성을 위한 구성이므로, 단일 리전에서의 비용 절감 요구사항과 무관합니다. 【시험 포인트】 ▸ 패턴: "예측 불가능 + 급증" → 온디맨드 모드 자동 매핑 ▸ 비용 최적화 조건: 사용률 변동성이 크면 온디맨드가 저렴 ▸ 프로비저닝 모드: 스케일링 지연, 기본 비용 고정 → 부적합

해설

【핵심 용어】 ▸ launchPermission — AMI 공유 권한 제어 메커니즘 ▸ KMS 키 정책 — 크로스 계정 암호화 키 액세스 승인 ▸ 안전한 공유 — 특정 계정 제한, 공개 노출 방지 【정답 포인트】 ▸ "가장 안전한" → 공개 공유 제외, 특정 계정만 → launchPermission 제한 ▸ KMS 암호화 유지 → MSP 계정이 키 접근 필요 → 원본 키 정책 수정 ▸ 원본 키 신뢰: 원본 계정이 소유, MSP 계정에 decrypt 권한 부여 【오답 체크】 (D) Amazon S3 버킷으로의 내보내기는 불필요한 추가 절차를 야기하며, 원본 KMS 키로 직접 공유하는 것이 가능합니다. 데이터 복사 오버헤드가 발생합니다. 【시험 포인트】 ▸ 패턴: "크로스 계정 + 암호화" → launchPermission + 원본 키 정책 조합 ▸ KMS 권한: 키 정책(account:decrypt), 원본 키 소유권 유지 안전 ▸ 추가 키 생성 회피: 관리 오버헤드, 암호화 체인 복잡화

해설

【핵심 용어】 ▸ AWS Config 규칙 — 리소스 준수 지속 모니터링, 자동 평가 ▸ EventBridge — 규칙 기반 이벤트 라우팅, SNS 통합 ▸ 인증서 만료 감지 — CloudWatch 커스텀 메트릭 대안, Config native 지원 【정답 포인트】 ▸ Config 규칙 생성 → acm-certificate-expiration-check 내장 규칙 활용 ▸ 비준수 감지 → EventBridge Config 규칙 변경 이벤트 트리거 ▸ SNS 통지 → Lambda/SNS 체인으로 경고 자동화 ▸ 지속적 모니터링 → Config는 자동 스캔, ACM 별도 규칙 불필요 【오답 체크】 (C) AWS Trusted Advisor는 주간 단위 스캔만 제공하므로 30일 임박 시점의 실시간 감지가 불가능합니다. 비용 효율성도 낮습니다. 【시험 포인트】 ▸ 패턴: "지속 모니터링 + 준수" → AWS Config 규칙 ▸ Config 활용: acm-certificate-expiration-check 규칙 → 비준수 이벤트 → EventBridge ▸ 실시간 감지: Trusted Advisor(주간) vs Config(지속)

해설

【핵심 용어】 ▸ 예약 인스턴스 — 1~3년 약정, 24/7 운영, 비용 70% 절감 ▸ 온디맨드 — 시간 단위, 유연성, 스팟보다 비쌈 ▸ 스팟 — 중단 위험, 프로덕션 부적합, 배치 처리 용 【정답 포인트】 ▸ "프로덕션 24시간" → 예약 인스턴스 (약정, 저가) ▸ "개발/테스트 8시간 + 자동 중지" → 온디맨드 (자동화 시 과금 중단) ▸ 스팟 회피: 프로덕션 신뢰성 위험 (2분 경고 후 중단) ▸ 자동화 중지: 온디맨드는 사용 시간만 청구 【오답 체크】 (A) 프로덕션 환경에 스팟 인스턴스는 2분 경고 후 중단 위험이 있어 SLA 위반이 발생합니다. 신뢰성을 보장하지 못합니다. (C) 스팟 블록도 중단 가능성이 존재하여 프로덕션 환경의 가용성 요구사항에 부적합합니다. 신뢰성이 부족합니다. (D) 온디맨드 방식으로 전체 인스턴스를 구성하면 매우 비용 비효율적이며, 프로덕션 예약 인스턴스 대비 약 70% 더 비싼 비용이 발생합니다. 【시험 포인트】 ▸ 패턴: "24/7 + 고정 부하" → 예약, "가변 + 중단 가능" → 온디맨드 ▸ 자동화 중지 인식: 온디맨드는 중지 시 요금 즉시 중단 ▸ 스팟 한계: 신뢰도 < 99%, 프로덕션 제외

해설

【핵심 용어】 ▸ Secrets Manager — 자격증명 관리, 자동 로테이션, 감사 기능 ▸ 자격증명 로테이션 — 정기적 갱신, 자동화 지원 ▸ IAM 정책 — 접근 제어, 최소 권한 원칙 【정답 포인트】 ▸ "자격증명 자주 교체" → Secrets Manager 자동 로테이션 (RDS 네이티브 지원) ▸ "안전한 방법" → 암호화 저장, IAM 기반 접근 제어 ▸ Secrets Manager는 RDS 통합 → Lambda 함수로 자동 로테이션 가능 ▸ 감사 추적: CloudTrail 기록, 접근 이력 추적 【오답 체크】 (C) AWS CloudTrail은 API 호출 로깅만 지원하고, DNS 쿼리 동적 설정이 불가능합니다. 라우팅 정책 자동화를 미지원합니다. (D) CloudFront 지역 제한은 특정 국가 차단만 가능하고, 다중 지역 자동 장애조치를 미지원합니다. 고가용성이 부족합니다. 【시험 포인트】 ▸ 패턴: "자격증명 + 자동 로테이션" → Secrets Manager 자동 선택 ▸ RDS 통합: Secrets Manager는 RDS 사용자 생성/변경 자동화 ▸ 자동화 조건: Lambda 실행 역할 + RDS 권한

해설

【핵심 용어】 ▸ SQS FIFO — 순서 보장, 메시지 영구 저장, 중복 제거 ▸ 데이터 손실 방지 — 데이터베이스 다운 시에도 큐에 보관 ▸ 비동기 처리 — Lambda는 데이터 저장만, 별도 함수가 DB 쓰기 【정답 포인트】 ▸ "업그레이드 중 데이터 손실" → 직접 쓰기 회피 → SQS 큐 중개 ▸ "고객 데이터 저장" → SQS FIFO(순서 보장, 중복 제거) ▸ "데이터베이스 업그레이드 후" → 별도 Lambda가 큐 폴링 → 재시도 가능 ▸ 메시지 보존: SQS 보관 기간 (기본 4일), DB 재연결 시간 충분 【오답 체크】 (B) AWS X-Ray는 분산 추적 기능만 제공하고, DynamoDB 스로틀 현상 예방이 미지원입니다. 용량 계획 기능이 부족합니다. 【시험 포인트】 ▸ 패턴: "다운타임 데이터 손실" → 비동기 큐 분리 (SQS) ▸ FIFO 선택: 순서 보장 + 중복 방지 (금융/주문 데이터) ▸ 아키텍처: API → Lambda (SQS 발행) → 별도 Lambda (폴링 → DB) ▸ 내구성: SQS 메시지는 3개 AZ 복제

해설

【핵심 용어】 ▸ 요청자 지불 — 다운로드 요청 대상이 데이터 전송 비용 부담 ▸ 데이터 전송 비용 — 리전 간 전송 > 같은 리전 내 전송 ▸ 크로스 리전 복제 — 자동 복제 비용, 이중 데이터 저장 【정답 포인트】 ▸ "데이터 전송 비용 최소" → 요청자 지불 (출처 계정이 비용 회피) ▸ 요청자 지불: 마케팅 회사(다운로더)가 OUT 전송 비용 부담 ▸ 기본 설정: 소유 계정 부담 → 요청자 지불로 전환 ▸ 비용 구조: US→EU 전송료 vs 사본 생성+저장(더 비쌈) 【오답 체크】 (C) VPC 피어링은 양쪽 모두 설정이 필요하고, 자동 장애조치를 미지원합니다. 양방향 네트워크 관리 오버헤드가 높습니다. (D) AWS Direct Connect는 전용 네트워크 회선으로 프로비저닝에 4주 이상 소요되어 빠른 배포에 부적합합니다. 【시험 포인트】 ▸ 패턴: "데이터 전송 비용 최소" → 요청자 지불 자동 선택 ▸ 요청자 지불 조건: 요청자는 AWS 계정 필수, 익명 불가 ▸ 비용 계산: OUT 전송료 (리전별 요율) ▸ 리플리케이션 회피: 복제=비용 최소화 반대 전략

해설

【핵심 용어】 ▸ MFA 삭제 — 루트 계정 + MFA 코드 필요, DeleteObject 방지 ▸ 버전 관리 — MFA 삭제 선행 조건, 삭제 마크만 생성 ▸ 실수 삭제 방지 — 기술적 차단, 정책 기반 아님 【정답 포인트】 ▸ "실수로 삭제" → 기술적 보호 필요 (정책만으로 부족) ▸ MFA 삭제: 루트 자격증명 + MFA 장치 필수 → 감압팀 사용자 삭제 불가능 ▸ 버전 관리 활성화 → DeleteObject는 삭제 마크만 추가, 이전 버전 복구 가능 ▸ IAM 사용자는 MFA 삭제 권한 없음(루트만 가능) 【오답 체크】 (C) AWS Lambda 함수만으로 대규모 병렬 처리 스케일링이 어렵습니다. 동시성 제한이 있습니다. (D) SQS 메시지만으로는 광범위한 메타데이터 저장이 부족하고, 데이터베이스 쿼리 성능 문제가 발생합니다. 【시험 포인트】 ▸ 패턴: "실수 삭제 방지" → 버전 관리 + MFA 삭제 조합 ▸ MFA 삭제 특수성: 루트 계정만 설정/해제 가능, IAM 불가 ▸ 버전 관리: DELETE는 마크만, 원본 유지 → 복구 가능 ▸ 감압팀 사용자로는 실제 삭제 불가 (MFA 없음)

해설

【핵심 용어】 ▸ 읽기 전용 복제본 — 쓰기 분리, 읽기 부하 감소, 독립적 쿼리 ▸ 성능 격리 — 스크립트 쿼리와 개발 작업 분리 ▸ 최소 운영 오버헤드 — 관리형 복제, 자동 동기화 【정답 포인트】 ▸ "스크립트 실행 중 성능 저하" → 읽기 부하 분산 필요 ▸ 읽기 전용 복제본: 스크립트는 READ만, 프로덕션은 쓰기 전용 ▸ 자동 동기화: Binlog 기반 비동기 복제, 지연 < 1초 ▸ 독립적 스케일: 복제본 인스턴스 크기 조정 가능, 원본 미영향 【오답 체크】 (A) NAT 게이트웨이는 아웃바운드 통신만 지원하고, 인바운드 접근이 불가능합니다. 원격 관리가 불가능합니다. (C) VPN 연결은 자동 장애조치를 미지원하고, 네트워크 지연시간이 높습니다. 고가용성 요구사항이 충족되지 않습니다. (D) AWS Systems Manager는 관리 기능만 제공하고, 원격 접근 데이터 전송 자체는 미지원합니다. 암호화가 추가로 필요합니다. 【시험 포인트】 ▸ 패턴: "특정 쿼리 + 읽기 부하" → 읽기 전용 복제본 ▸ 복제본 활용: 분석, 보고(스크립트), 개발 환경에 적합 ▸ 성능 격리: 복제본과 원본 독립적 리소스 사용 ▸ 최소 오버헤드: AWS 관리형 복제, 운영 작업 최소

해설

【핵심 용어】 ▸ S3 게이트웨이 엔드포인트 — VPC 내부 S3 접근, 퍼블릭 IP 불필요 ▸ PrivateLink 아님 — 게이트웨이만 인터넷 게이트웨이 우회 ▸ 인터넷 경유 방지 — 라우팅 테이블 설정 【정답 포인트】 ▸ "인터넷 경유 불가" → VPC 엔드포인트 필수 ▸ S3 게이트웨이 엔드포인트: 라우트 테이블 경로, 직접 연결 ▸ NAT/인터넷 게이트웨이 제거: 퍼블릭 IP/라우팅 불필요 ▸ 무료 제공: 데이터 전송 비용만 【오답 체크】 (C) Amazon Kinesis Data Firehose는 배치 처리만 지원하므로, 실시간 알림이 지연됩니다. 즉시 응답 요구사항에 부적합합니다. (D) 트리거 기반 Lambda만으로 복잡한 메시지 필터링 로직 관리가 어렵습니다. 비용과 운영 복잡도가 증가합니다. 【시험 포인트】 ▸ 패턴: "VPC + S3 + 인터넷 제한" → S3 게이트웨이 엔드포인트 ▸ VPC 엔드포인트 종류: 게이트웨이(S3,DynamoDB) vs PrivateLink(기타) ▸ 라우팅: 라우트 테이블에 엔드포인트 경로 추가 (0.0.0.0/0 우선도) ▸ 라우팅 우선도: 더 구체적 경로(S3 엔드포인트) > 기본 경로

해설

【핵심 용어】 ▸ S3 게이트웨이 엔드포인트 — VPC 내부 S3 경로, 인터넷 우회 ▸ 버킷 정책 — 엔드포인트 소스 제한, VPC/엔드포인트 ID 기반 ▸ 보안 액세스 — 네트워크 + 자격증명 이중 제어 【정답 포인트】 ▸ "VPC 애플리케이션만 액세스" → A(네트워크 경로) + C(소스 제한) ▸ 게이트웨이 엔드포인트: VPC 라우팅만, 인터넷 IP 불필요 ▸ 버킷 정책: aws:sourceVpce 조건 추가 → 엔드포인트 경유만 허용 ▸ 결과: VPC 외부 + 엔드포인트 미사용 = 403 금지 【오답 체크】 (A) AWS KMS 자동 키 교체는 기존 데이터의 암호화를 변경하지 않고, 새 키는 신규 데이터에만 적용됩니다. (B) AWS CloudHSM은 관리 오버헤드가 높고, 단일 HSM 하드웨어 장애 위험이 있습니다. 다중화에 추가 비용이 필요합니다. (D) 온프레미스 온사이트 암호화는 클라우드 보안 이점을 상실하고, 정기적인 감사와 규정 준수가 어렵습니다. 【시험 포인트】 ▸ 패턴: "VPC만 + 민감 정보" → 엔드포인트(경로) + 정책(소스) ▸ 버킷 정책 조건: aws:sourceVpce="vpce-xxx" 또는 aws:SourceVpc="vpc-xxx" ▸ 엔드포인트 정책: VPC 엔드포인트 자체에도 정책 설정 가능(추가 제어) ▸ 자격증명 관리: EC2 IAM 역할 권장 (임시 자격증명, 회전 자동)

해설

【핵심 용어】 ▸ Aurora 데이터베이스 복제 — Zero downtime clone, 스냅샷 기반 ▸ 스테이징 분리 — 스냅샷 복제로 독립적 환경, 프로덕션 영향 없음 ▸ mysqldump 회피 — 4시간 배치 로드 시간 제거 【정답 포인트】 ▸ "4시간마다 지연" → 배치 내보내기 회피 필수 ▸ Aurora 복제: 기존 스냅샷에서 클론 생성 가능, 쓰기 잠금 없음 ▸ "요청 시" → 스테이징이 필요할 때만 클론 → 개발팀 즉시 이용 가능 ▸ 프로덕션 격리: 클론은 독립적, 스테이징 수정도 프로덕션 미영향 【오답 체크】 (A) Amazon CloudWatch 수동 대시보드는 시각화만 제공하고, 자동 알림 기능이 없습니다. 대응 속도가 느립니다. (D) AWS CloudTrail은 API 호출만 감사하고, 애플리케이션 성능 메트릭을 미포함합니다. 모니터링 범위가 불완전합니다. 【시험 포인트】 ▸ 패턴: "배치 부하 + 스테이징" → Aurora 클론(스냅샷) ▸ Aurora 강점: 클론 생성 초 단위, COW(Copy-on-Write) 기술 ▸ RDS 한계: 스냅샷 복원 시간(GB당 분단위), 배치 회피 불가 ▸ 운영 개선: 개발팀이 자동/자체 스테이징 생성 가능

해설

【핵심 용어】 ▸ S3 이벤트 + SQS — 파일 업로드 감지, 큐 기반 처리 ▸ Lambda — 서버리스, 자동 스케일(동시성), 기본 시작 < 1초 ▸ DynamoDB — 즉시 쓰기, 구조화 데이터 저장, NoSQL 【정답 포인트】 ▸ "최소 운영 오버헤드" → 서버리스 선택 (Lambda) ▸ "최대한 빨리" → 이벤트 기반(SQS 알림) + Lambda 즉시 처리 ▸ "다양한 수요" → Lambda 자동 스케일(동시성), 용량 수동 조정 없음 ▸ SQS 선택: S3 이벤트 알림 네이티브 지원, 메시지 내구성 【오답 체크】 (A) Amazon S3 동기식 복제는 실시간이나 자동 장애조치를 미지원하므로 수동 전환이 필요합니다. RPO/RTO 요구사항을 충족하지 못합니다. (D) Route 53 장애조치는 DNS 레벨만 지원하고, 데이터 동기화를 미지원합니다. 데이터 손실 위험이 있습니다. 【시험 포인트】 ▸ 패턴: "이벤트 + 즉시 + 가변 부하" → S3 이벤트 + SQS + Lambda ▸ Lambda 동시성: 기본 1000, 자동 스케일링, 비용 = 실행 시간만 ▸ DynamoDB 선택: JSON 저장, 즉시 쓰기, 확장 자동 ▸ 아키텍처: S3 PUT → SQS 메시지 → Lambda 트리거 → DynamoDB 저장

해설

【핵심 용어】 ▸ 읽기 전용 복제본 — 쓰기/읽기 분리, 독립적 스케일 ▸ 성능 격리 — 원본(쓰기) vs 복제본(읽기) 리소스 분리 ▸ 동일 스펙 — 읽기 부하 완전 흡수, 성능 균형 【정답 포인트】 ▸ "성능 저하 + 쓰기/읽기 분리" → 읽기 전용 복제본 필수 ▸ 다중 AZ는 가용성(장애조치), 읽기 분산 아님 → 제외 ▸ "동일 스펙 복제본" → 읽기 부하 전체 이관, 성능 격리 완전 ▸ "절반 스펙": 읽기 부하 일부만 흡수, 원본 부하 여전함 【오답 체크】 (A) API Gateway 캐싱은 HTTP 캐시헤더에 의존하여, 세밀한 캐시 제어가 어렵습니다. 캐시 일관성 관리가 복잡합니다. (B) Amazon CloudFront 캐싱은 정적 콘텐츠 중심이고, 동적 콘텐츠는 TTL이 짧습니다. 캐시 효율성이 낮습니다. 【시험 포인트】 ▸ 패턴: "성능 격리 + 즉시" → 읽기 복제본(동일 스펙) ▸ 복제본 크기: 부하 흡수 > 작은 스펙 권장 (부하 예측 기반) ▸ 다중 AZ vs 복제본: 가용성 ≠ 성능 분산 ▸ 쓰기/읽기 분리: 라우팅 로직(애플리케이션/미들웨어) 필요

해설

【핵심 용어】 ▸ IAM 정책 조건(Condition) — 조건문이 모두 참일 때만 작업 허용 ▸ StringEquals — 정확한 문자열 일치 검증 ▸ SourceIp — 요청자의 IP 주소를 조건으로 검증 【정답 포인트】 ▸ 정책 구조 → Allow, Action(ec2:TerminateInstances), Resource(*), Condition 포함 ▸ Condition 분석 → aws:StringEquals(aws:SourceIp: 10.100.100.254) AND aws:StringEquals(aws:RequestedRegion: us-east-1) ▸ 로직 → 조건 모두 충족 시에만 종료 가능 【오답 체크】 (A) Amazon EC2 AMI 복사는 단발성 작업이고, 자동 이미지 업데이트를 미지원합니다. 이미지 관리가 수동화됩니다. (D) AWS CodeDeploy 배포만으로 기본 이미지 최신화가 불가능합니다. 운영 패치 자동화가 미흡합니다. 【시험 포인트】 조건부 정책 → AND 연산자로 모든 조건 동시 충족 / IP + Region 이중 제약 → 실무 보안 모범사례

해설

【핵심 용어】 ▸ Amazon FSx for Windows — AWS 관리형 Windows 파일 서버, SMB 프로토콜, AD 통합 ▸ Active Directory — Windows 도메인 인증 및 액세스 제어 ▸ SharePoint — Windows 기반 엔터프라이즈 콘텐츠 관리 【정답 포인트】 ▸ Windows 필수 요구사항 → SMB 프로토콜 지원 필수 ▸ AD 통합 → FSx for Windows 표준 기능, EFS는 NFS 기반으로 Windows AD 미지원 ▸ 고가용성 → FSx는 다중 AZ 자동 복제, 관리형 서비스 【오답 체크】 (A) Amazon CloudWatch 메트릭만으로 로그 분석이 불가능합니다. 상세한 진단과 문제 해결이 어렵습니다. (C) AWS CloudTrail은 API 호출 감사만 하고, 애플리케이션 로그를 미포함합니다. 종합적 가시성이 부족합니다. 【시험 포인트】 Windows 워크로드 + AD 필수 → FSx for Windows 자동 선택 / EFS vs FSx — Linux(EFS) vs Windows(FSx)

해설

【핵심 용어】 ▸ 가시성 제한 시간(Visibility Timeout) — 메시지 처리 중 다른 소비자 접근 차단 ▸ SQS 표준 대기열 — at-least-once 배치, 중복 가능 ▸ Lambda 배치 윈도우 — 메시지 수집 대기 시간 【정답 포인트】 ▸ 문제 원인 → Visibility Timeout 만료 전 Lambda 처리 미완료 → 메시지 재표시 → 중복 실행 ▸ 해결책 → Visibility Timeout = Lambda 함수 제한시간 + 배치 윈도우 시간 ▸ 최소 오버헤드 → 설정만 조정, 코드/아키텍처 변경 불필요 【오답 체크】 (A) Amazon S3 버전 관리는 의도치 않은 변경 복구만 하고, 규제 영구 저장 요구사항을 미충족합니다. 접근 제어만으로는 부족합니다. (B) S3 객체 잠금 GOVERNANCE 모드는 root 사용자 우회가 가능하여, 완전 보호가 아닙니다. 규제 준수 수준이 미달합니다. (D) DynamoDB TTL은 자동 삭제이므로, 규제에서 금지한 삭제 요구사항에 위반됩니다. 데이터 보존이 보장되지 않습니다. 【시험 포인트】 SQS 중복 메시지 → Visibility Timeout 우선 검토 / Lambda + SQS 통합 → 타임아웃 값 동기화 필수

해설

【핵심 용어】 ▸ Amazon FSx for Lustre — AWS 관리형 Lustre, HPC/게임 최적화 ▸ Lustre 프로토콜 — 고성능 병렬 파일 시스템 ▸ 완전 관리형 — 패치, 스케일링, 백업 자동 처리 【정답 포인트】 ▸ Lustre 필수 → FSx for Lustre 유일한 매니지드 선택지 ▸ 온프레미스 연결 → AWS Direct Connect 또는 VPN으로 FSx 접근 ▸ 관리형 요구 → EC2 자체 구축 배제, Storage Gateway는 Lustre 미지원 【오답 체크】 (A) Elastic IP는 네트워크 연결만 유지하고, 자동 장애조치를 미지원합니다. 가용성 향상이 부족합니다. (C) Route 53 가중치 기반 라우팅은 수동 가중치 조정이므로, 진정한 자동 장애조치가 아닙니다. 관리 오버헤드가 있습니다. 【시험 포인트】 Lustre 프로토콜 지정 → FSx for Lustre 즉시 선택 / 고성능 파일시스템 → FSx 계열 검토