정답 · 해설

해설

【핵심 용어】 ▸ CloudWatch 알람: 메트릭 임계값 초과 시 자동으로 트리거되는 모니터링 기능 ▸ SNS(Simple Notification Service): 이메일 및 푸시 알림을 전송하는 메시징 서비스 ▸ Trusted Advisor 메트릭: CloudWatch에서 사용 가능한 할당량 메트릭 【정답 포인트】 ▸ Trusted Advisor 서비스 할당량 메트릭은 CloudWatch에서 직접 수집되므로 CloudWatch 알람이 적절합니다. ▸ SNS는 이메일 알림 전송을 위한 표준 AWS 서비스입니다(SQS는 메시지 큐로 이메일 연동이 복잡함). ▸ 5개 메트릭 각각에 대해 별도의 알람을 생성하여 개별 모니터링이 가능합니다. 【오답 체크】 (B) SQS는 메시지 큐이며 기본 이메일 알림 기능이 없어 추가 처리 로직 필요합니다. (C) Service Health Dashboard는 AWS 서비스 상태 모니터링용이며 할당량 메트릭 추적에 부적합합니다. (D) Service Health Dashboard 선택이 부정확하여 정답이 아닙니다. 【시험 포인트】 ▸ CloudWatch 알람 + SNS는 이메일 알림의 표준 조합입니다. ▸ 할당량 모니터링은 Trusted Advisor 또는 CloudWatch를 통해, SNS로 알림을 전달하는 패턴입니다.

해설

【핵심 용어】 ▸ FSx File Gateway: Windows 파일 공유(SMB)를 AWS와 온프레미스 간에 동기화하는 AWS Storage Gateway ▸ Storage Gateway: 온프레미스와 AWS 간의 데이터 연결 계층 ▸ SMB(Server Message Block): Windows 파일 공유 프로토콜 【정답 포인트】 ▸ FSx File Gateway는 Amazon FSx for Windows File Server와 온프레미스 Windows 파일 공유를 동기화합니다. ▸ 온프레미스와 AWS 양쪽에서 동일한 파일 공유에 액세스할 수 있는 하이브리드 파일 시스템을 제공합니다. ▸ 최소 지연 시간으로 로컬 캐싱을 지원하고 자동 동기화를 제공합니다. 【오답 체크】 (A) S3 File Gateway는 객체 스토리지용이며 Windows 파일 공유(SMB)와 호환되지 않습니다. (B) Direct Connect는 네트워크 연결만 제공하며 파일 시스템 동기화 기능이 없습니다. (C) DataSync는 일회성 또는 정기적 데이터 전송용이며 실시간 동기화를 지원하지 않습니다. 【시험 포인트】 ▸ Windows 파일 공유 + 하이브리드 액세스 = FSx File Gateway ▸ Storage Gateway 선택은 프로토콜(NFS vs SMB)과 스토리지 타입(S3 vs FSx)을 고려합니다.

해설

【핵심 용어】 ▸ RDS 파라미터 그룹(Parameter Group): RDS 데이터베이스의 설정을 제어하는 구성 모음 ▸ rds.force_ssl 파라미터: SSL 연결을 필수로 하는 PostgreSQL 파라미터 ▸ SSL 연결 강제: 모든 접근 시도에 암호화된 연결을 필수화 【정답 포인트】 ▸ RDS 파라미터 그룹에서 'rds.force_ssl' 파라미터를 '1'로 설정하면 모든 연결이 SSL을 강제합니다. ▸ 이는 데이터베이스 엔진 수준에서 동작하므로 모든 클라이언트 연결에 적용됩니다. ▸ RDS 매니지드 서비스 특성상 PostgreSQL 확장이나 저수준 패치 없이 파라미터로 제어합니다. 【오답 체크】 (A) 보안 그룹은 SSL 연결을 '허용'하지만 '강제'하지 않으므로 암호화되지 않은 연결도 가능합니다. (B) KMS 암호화는 저장 데이터(data at rest) 암호화이며 전송 중 암호화(in-transit)가 아닙니다. (D) RDS는 관리형 서비스로 PostgreSQL 확장을 직접 제어할 수 없습니다. 【시험 포인트】 ▸ RDS 연결 암호화: 파라미터 그룹의 'rds.force_ssl' 설정이 정답입니다. ▸ 저장 vs 전송 암호화 구분이 중요합니다.

해설

【핵심 용어】 ▸ AWS Budgets: 비용 및 사용량 기반 예산과 알림 설정 서비스 ▸ Savings Plans: AWS 약정 할인 상품 ▸ 사용률 모니터링: Savings Plans 활용도를 추적하는 기능 【정답 포인트】 ▸ AWS Budgets는 비용뿐만 아니라 Savings Plans 사용률도 모니터링할 수 있습니다. ▸ 일일 사용률 기준으로 임계값(90%)을 설정하고 SNS를 통해 이메일 알림을 보낼 수 있습니다. ▸ Savings Plans 최적화를 위한 전문 기능으로 설계되었으므로 가장 적절한 도구입니다. 【오답 체크】 (A) Trusted Advisor의 Savings Plan 확인은 권장사항 제공 목적이며 실시간 사용률 모니터링에는 부적합합니다. (B) CloudWatch의 SavingsPlansUtilization 메트릭을 사용할 수 있지만, AWS Budgets이 더 직관적이고 통합된 솔루션입니다. (C) Savings Plans 네이티브 알림은 별도 구성이 필요하며 SNS 통합이 직접 지원되지 않습니다. 【시험 포인트】 ▸ 비용/사용량 기반 모니터링 = AWS Budgets ▸ Savings Plans 운영 최적화 = AWS Budgets와 SNS 조합입니다.

해설

【핵심 용어】 ▸ SQS FIFO: 메시지 순서 보장 및 중복 제거 기능을 제공하는 SQS 큐 타입 ▸ 메시지 그룹 ID: FIFO 큐에서 메시지 순서를 정의하는 필수 필드 ▸ 콘텐츠 기반 중복 제거: 동일한 메시지 본문을 자동으로 중복 제거 【정답 포인트】 ▸ SQS 표준 큐는 기존 큐 타입을 변경할 수 없으므로 새로운 FIFO 큐를 생성해야 합니다. ▸ 콘텐츠 기반 중복 제거를 활성화하면 메시지 본문이 동일한 경우 자동으로 중복을 제거합니다. ▸ 메시지 그룹 ID는 FIFO 큐에서 메시지 순서를 보장하기 위해 필수입니다(예: 고객 ID별로 순서 보장). 【오답 체크】 (B) DelaySeconds는 메시지 지연 전송이며 FIFO 마이그레이션과 무관합니다. (C) 기존 표준 큐의 타입을 FIFO로 변경할 수 없습니다. (D) FIFO 구현에서는 메시지 본문이 항상 다를 필요는 없으며, DelaySeconds는 필요하지 않습니다. 【시험 포인트】 ▸ SQS 큐 타입 변경 불가 = 새로운 큐 생성 필수 ▸ FIFO 마이그레이션 = 메시지 그룹 ID + 선택적 콘텐츠 기반 중복 제거

해설

【핵심 용어】 ▸ Systems Manager Distributor: .msi 패키지 등 소프트웨어 배포 및 업데이트 자동화 서비스 ▸ State Manager: 인스턴스에서 실행할 구성을 정의하고 스케줄링하는 서비스 ▸ AWS-ConfigureAWSPackage 문서: Distributor 패키지 설치 및 업데이트 전담 State Manager 문서 【정답 포인트】 ▸ (A) Distributor 패키지: 타사 .msi 에이전트를 패키징하고 배포하는 데 필수입니다. ▸ (D) State Manager + AWS-ConfigureAWSPackage: 1일 일정으로 자동 업데이트를 실행합니다. 이 조합이 최소 운영 노력으로 자동화를 달성합니다. ▸ Distributor는 배포 수단, State Manager는 자동화 스케줄링 역할입니다. 【오답 체크】 (B) Inventory는 에이전트 설치 추적용이며 배포 자동화에는 필수 아닙니다. (C) AWS-RunRemoteScript는 일반적인 스크립트 실행용이며, AWS-ConfigureAWSPackage처럼 패키지 관리에 특화되지 않습니다. (E) OpsItem과 유지 보수 윈도우는 불필요한 복잡성을 추가합니다. 【시험 포인트】 ▸ Systems Manager 에이전트 배포 = Distributor(패키징) + State Manager(자동화) ▸ AWS-ConfigureAWSPackage는 Distributor 패키지 설치 전용 문서입니다.

해설

【핵심 용어】 ▸ EBS gp2(General Purpose SSD): IOPS 성능이 볼륨 크기에 비례하는 SSD 볼륨 ▸ IOPS: 초당 입출력 작업 수(처리량 및 성능 지표) ▸ 볼륨 크기와 성능의 상관 관계: gp2는 GB당 3 IOPS 제공 【정답 포인트】 ▸ gp2 볼륨의 IOPS는 볼륨 크기에 정확히 비례합니다(크기 3배 = IOPS 3배). ▸ 볼륨 크기를 증가시키면 즉시 IOPS가 증가하며, 인스턴스 타입 변경 테스트가 필요하지 않습니다. ▸ 기존 볼륨을 수정할 수 있으므로 가장 빠른 구현 방법입니다(가동 중 크기 조정 가능). 【오답 체크】 (B) 네트워크 인터페이스는 I/O 성능과 무관하며, 네트워크 대역폭만 증가시킵니다. (C) 전송 가속화는 CloudFront 기능이며 EBS 볼륨과 무관합니다. (D) 클러스터 배치 그룹은 네트워크 지연 시간 감소용이며 로컬 IOPS 성능과 무관합니다. 【시험 포인트】 ▸ gp2 성능 향상 = 볼륨 크기 증가(3 IOPS/GB) ▸ 타입 변경 없이 성능 개선 = 크기 기반 조정입니다.

해설

【핵심 용어】 ▸ RDS 암호화: 저장 데이터(data at rest) 암호화 기능 ▸ AWS KMS 고객 관리형 키: 회사가 회전 정책을 제어하는 암호화 키 ▸ 자동 키 회전: KMS에서 매년 자동으로 수행되는 키 로테이션 【정답 포인트】 ▸ KMS 고객 관리형 키의 자동 회전을 활성화하면 매년 자동으로 키가 회전됩니다. ▸ RDS 암호화 시 생성 시점에 KMS 키를 지정해야 하므로, 마이그레이션 후 변경 불가합니다. ▸ AWS 관리형 키는 자동 회전 정책을 사용자가 제어할 수 없으므로 부적합합니다. 【오답 체크】 (A) TDE는 MySQL 엔진 수준 암호화이며 수동 회전이 필요합니다(자동 불가). (B) AWS 관리형 키의 회전 정책은 AWS가 결정하며 사용자가 제어할 수 없습니다. (D) EBS 볼륨 암호화는 RDS 암호화와 별개이며, RDS의 내부 저장 데이터는 EBS 계층과 무관합니다. 【시험 포인트】 ▸ RDS 암호화 요구사항 = KMS 고객 관리형 키 + 자동 회전 ▸ 생성 시 암호화 설정이 필수이며 사후 변경 불가입니다.

해설

【핵심 용어】 ▸ Route 53 별칭 레코드: AWS 리소스(ALB, CloudFront 등)를 직접 가리키는 레코드 ▸ 장애 조치 라우팅 정책: 주 리소스 실패 시 보조 리소스로 트래픽을 자동 전환 ▸ 대상 상태 평가(Evaluate Target Health): 원본 리소스의 상태 확인 기반 자동 장애 조치 【정답 포인트】 ▸ Route 53 별칭 레코드는 ALB의 상태 확인과 통합되어 자동 장애 조치를 지원합니다. ▸ '대상 상태 평가 = Yes'로 설정하면 주 ALB가 건강하지 않을 때 자동으로 보조 ALB로 전환됩니다. ▸ 장애 조치 라우팅 정책은 액티브-패시브 구성의 표준 패턴입니다. 【오답 체크】 (B) CNAME 레코드는 AWS 리소스의 상태 평가를 지원하지 않으므로 자동 장애 조치가 불가능합니다. (C) ELB 상태 확인은 Auto Scaling 정책용이며, Route 53 장애 조치와는 별개입니다. (D) EC2 상태 확인만으로는 리전 간 장애 조치 구현이 어려우며, ALB 상태 확인이 필요합니다. 【시험 포인트】 ▸ 다중 리전 액티브-패시브 패턴 = Route 53 장애 조치 라우팅 + 별칭 레코드 + 대상 상태 평가 ▸ 별칭 레코드는 Route 53 고유 기능이며 자동 상태 확인을 제공합니다.

해설

【핵심 용어】 ▸ Dead-Letter Queue(DLQ): 전달 실패한 메시지를 수집하는 큐 ▸ EventBridge 대상: 이벤트를 전송받는 서비스(여기서는 API 대상) ▸ 클라이언트 오류: 대상으로의 이벤트 전달 실패 【정답 포인트】 ▸ EventBridge 규칙의 대상에 SQS DLQ를 설정하면 API 호출 실패 메시지가 자동으로 SQS에 저장됩니다. ▸ SQS DLQ에서 실패한 메시지와 오류 세부 정보(HTTP 상태 코드, 응답 본문 등)를 검색할 수 있습니다. ▸ 최소한의 설정 변경으로 오류 진단이 가능합니다(규칙에 DLQ 추가만 하면 됨). 【오답 체크】 (A) EventBridge 아카이브는 재생 기능 제공이지 오류 진단 도구가 아닙니다. (C) Lambda 함수 추가는 불필요한 복잡성을 증가시키며, DLQ로 충분합니다. (D) SNS 주제는 오류 알림용이며 오류 세부 정보 저장/검색 기능이 없습니다. 【시험 포인트】 ▸ EventBridge 대상 실패 디버깅 = DLQ 추가 ▸ DLQ는 이벤트 기반 아키텍처의 표준 오류 처리 패턴입니다.

해설

【핵심 용어】 ▸ S3 Object Lock: 객체 삭제 및 덮어쓰기로부터 보호하는 WORM(Write Once Read Many) 메커니즘 ▸ 규정 준수 모드: 보존 기간 동안 어떤 사용자도 객체를 삭제할 수 없는 강화된 모드 ▸ 거버넌스 모드: 높은 권한을 가진 사용자는 보존 기간을 단축할 수 있는 모드 【정답 포인트】 ▸ S3 Object Lock의 규정 준수 모드는 보존 기간(3개월) 동안 누구도 객체를 삭제할 수 없게 보장합니다. ▸ 규정 요구사항에 부합하는 강화된 보호 메커니즘입니다. ▸ 자동 적용되므로 IAM 정책처럼 수동으로 제거할 필요가 없습니다. 【오답 체크】 (A) IAM 정책은 실수로 제거될 수 있으며, 자동화된 강제성이 부족합니다. (C) S3 버전 관리와 수명 주기 규칙은 삭제 방지 기능이 아닙니다. (D) 거버넌스 모드는 높은 권한 사용자가 보존 기간을 단축할 수 있어 규정 준수에 부적합합니다. 【시험 포인트】 ▸ WORM 요구사항 = S3 Object Lock + 규정 준수 모드 ▸ 규정 준수 vs 거버넌스: 보존 기간 강제 필요 = 규정 준수 모드입니다.

해설

【핵심 용어】 ▸ AWS Budgets: 비용 예산 설정 및 알림 기능을 제공하는 서비스 ▸ 비용 예산: 특정 서비스 또는 비용 카테고리(예: 데이터 전송)에 대한 지출 한도 ▸ 경고: 예산의 특정 퍼센티지에 도달할 때 트리거되는 알림 【정답 포인트】 ▸ AWS Budgets는 데이터 전송 비용과 같은 특정 비용 카테고리에 대한 예산 설정이 가능합니다. ▸ 75% 경고를 설정하면 자동으로 이메일 배포 목록에 알림을 보냅니다. ▸ 직관적이고 최소한의 설정으로 요구사항을 충족합니다. 【오답 체크】 (A) Cost and Usage Report와 Athena는 분석 도구이며 자동 경고 기능이 없습니다. (B) CloudWatch 청구 알람은 전체 청구만 추적하며 데이터 전송과 같은 특정 카테고리 추적이 불가능합니다. (D) VPC 흐름 로그와 Lambda는 매우 복잡하며 비용-트리거 기반 알림이 아닙니다. 【시험 포인트】 ▸ 특정 비용 카테고리 모니터링 = AWS Budgets ▸ AWS Budgets은 퍼센티지 기반 경고 설정을 직접 지원합니다.

해설

【핵심 용어】 ▸ Glacier Vault Lock: S3 Glacier에서 WORM 정책을 강제하는 메커니즘 ▸ WORM(Write Once Read Many): 쓰기는 한 번, 읽기는 여러 번 가능한 불변 스토리지 ▸ 감사 로그 보존: 법적/규정 준수 요구사항 【정답 포인트】 ▸ S3 Glacier Vault Lock은 WORM 정책을 통해 로그가 편집되지 않음을 보장합니다. ▸ 보존 기간 동안 로그를 삭제하거나 수정할 수 없습니다. ▸ 10년 같은 장기 보관과 불변성 보장이 필요한 감사 로그에 적합합니다. ▸ Glacier는 저장 비용이 매우 낮아 장기 보관 용도로 최적화되어 있습니다. 【오답 체크】 (A) EBS는 장기 보관 비용이 높으며 WORM 보호 기능이 없습니다. (C) S3 Standard-IA는 WORM 보호 없이 사용자가 삭제 가능합니다. (D) MFA는 계정 탈취 방지이며 편집 방지가 아닙니다. 【시험 포인트】 ▸ 감사 로그 10년 보관 + 편집 방지 = Glacier Vault Lock + WORM ▸ 규정 준수 감사 로그는 항상 불변 스토리지가 필요합니다.

해설

【핵심 용어】 ▸ Lambda 메모리: Lambda 함수에 할당된 메모리(128MB~10,240MB) ▸ CPU와 메모리의 관계: Lambda에서 할당 메모리에 비례하여 CPU 성능이 증가 ▸ CPU 집약적 워크로드: 높은 계산 능력이 필요한 작업 【정답 포인트】 ▸ Lambda는 할당된 메모리에 따라 CPU 가용량이 결정됩니다(메모리가 많을수록 CPU 많음). ▸ 메모리를 증가시키면 자동으로 할당되는 CPU도 증가하여 CPU 집약적 작업의 성능이 향상됩니다. ▸ Lambda는 CPU나 하이퍼스레딩을 직접 제어할 수 없으므로 메모리 튜닝이 유일한 방법입니다. 【오답 체크】 (A) Lambda는 하이퍼스레딩 옵션을 노출하지 않으므로 제어 불가능합니다. (B) 암호화를 끄면 보안이 약화되며 성능 영향은 미미합니다. (D) 커스텀 계층은 코드 저장 구조일 뿐 CPU 성능 개선과 무관합니다. 【시험 포인트】 ▸ Lambda CPU 성능 최적화 = 메모리 증가 ▸ Lambda는 메모리만 설정 가능하며, CPU는 메모리에 자동으로 할당됩니다.

해설

【핵심 용어】 ▸ CloudWatch Logs 메트릭 필터: 로그 패턴을 감지하여 자동으로 CloudWatch 메트릭을 생성 ▸ 구독 필터: 로그를 실시간으로 Lambda 또는 Kinesis로 스트리밍 ▸ CloudWatch Logs Insights: 쿼리 기반 임시 분석(실시간 모니터링 아님) 【정답 포인트】 ▸ 메트릭 필터는 HTTP 404 응답을 감지하고 CloudWatch 메트릭을 자동으로 생성합니다. ▸ 생성된 메트릭은 CloudWatch 대시보드, 알람, 그래프에서 실시간으로 모니터링할 수 있습니다. ▸ 설정 후 자동 운영되므로 가장 운영 효율적입니다(지속적인 스크립트 실행 불필요). 【오답 체크】 (B) 구독 필터는 이벤트를 다른 대상으로 라우팅하는 것일 뿐, 자동 집계가 아닙니다. (C) Lambda 함수는 정기적으로 실행되어야 하며 관리 오버헤드가 증가합니다. (D) 수동 스크립트 실행은 지속적 모니터링이 불가능하고 운영 효율성이 낮습니다. 【시험 포인트】 ▸ 로그 기반 실시간 메트릭 수집 = CloudWatch 메트릭 필터 ▸ 메트릭 필터 > 구독 필터 > 임시 분석(운영 효율성 순) ▸ 메트릭 필터 결과는 CloudWatch 알람으로도 연결 가능합니다.

해설

【핵심 용어】 ▸ Cost Allocation Tags: AWS 리소스에 할당되어 청구 및 비용 관리에 사용되는 태그 ▸ User-defined Tags: 사용자가 직접 생성하고 관리하는 비용 할당 태그 ▸ AWS-generated Tags: AWS에서 자동으로 생성하는 태그 (예: 환경, 리전) 【정답 포인트】 ▸ 비용 할당 태그는 AWS Billing Console에서 활성화되어야 청구 보고서에 표시됨 ▸ 사용자 정의 태그(User-defined)는 회사에서 직접 생성한 태그로, 이를 활성화하면 비용 보고서에 포함됨 ▸ AWS 생성 태그(AWS-generated)는 사전 정의된 태그로 자동 활성화되지만, 회사 정의 태그는 수동으로 활성화 필요 【오답 체크】 (A) AWS 생성 태그는 회사가 정의한 커스텀 태그가 아님 - 60자 (C) 비용 범주(Cost Category)는 태그와 다른 기능이며, 이 요구사항에는 부적절함 - 70자 (D) Cost and Usage Report는 기존 태그를 활성화하는 방법이 아니며, 리소스 ID만으로 불충분 - 80자 【시험 포인트】 ▸ AWS Billing & Cost Management에서 Tag Management 섹션 이해 필요 ▸ Cost Allocation Tags와 일반 Tags의 차이점 구분 필수 ▸ 비용 할당 태그 활성화 후 24시간 후부터 청구 보고서에 반영됨

해설

【핵심 용어】 ▸ Amazon DLM: 자동화된 스냅샷 생성 및 관리 서비스 ▸ Cross-Region Copy: 스냅샷을 다른 AWS 리전으로 복제 ▸ EBS Encryption: AWS KMS를 사용한 EBS 데이터 암호화 【정답 포인트】 ▸ DLM은 정책 기반 자동 스냅샷 생성/관리로 수동 개입 최소화 ▸ DLM의 교차 리전 백업 활성화로 복사 시 자동 암호화 적용 가능 ▸ KMS를 사용한 암호화로 암호화된/암호화되지 않은 모든 볼륨 통일 관리 【오답 체크】 (B) Encrypted 파라미터를 False로 설정하면 백업이 암호화되지 않아 요구사항 미충족 - 90자 (C) S3 저장소는 스냅샷 저장 용도로 부적절하며 교차 리전 복제 시 비효율적 - 85자 (D) Lambda 함수 사용은 수동 개입이 필요하여 관리 오버헤드가 높고 자동화 부족 - 100자 【시험 포인트】 ▸ DLM의 자동화 기능과 KMS 통합 이해 필수 ▸ 스냅샷 복사 시 암호화 설정 메커니즘 학습 ▸ 운영 효율성(Least Management Overhead) 기준 판단

해설

【핵심 용어】 ▸ kubeconfig: Kubernetes 클러스터 접근 정보를 포함한 설정 파일 ▸ kubectl: Kubernetes 클러스터 관리 명령줄 도구 ▸ AWS EKS: 완전 관리형 Kubernetes 서비스 【정답 포인트】 ▸ kubeconfig 파일은 클러스터 엔드포인트, 인증 정보, 인증서 정보 포함 ▸ kubectl이 API 서버와 통신하려면 kubeconfig가 필수 전제 조건 ▸ AWS EKS는 IAM 기반 인증을 사용하며, kubeconfig 생성 시 aws-iam-authenticator 포함 【오답 체크】 (B) kube-proxy는 네트워크 트래픽 관리용 add-on이며, kubectl 통신과 무관함 - 85자 (C) Fargate 프로필은 Pod 실행 환경 설정이며, 로컬 머신의 kubectl 구성과 무관 - 90자 (D) eks-connector.yaml은 외부 클러스터 연결용이며, EKS 클러스터의 kubectl 접근 설정이 아님 - 95자 【시험 포인트】 ▸ AWS EKS 클러스터 접근 메커니즘 이해 필수 ▸ kubeconfig 생성 방법: aws eks update-kubeconfig 명령어 ▸ IAM 역할 기반 인증의 역할 학습

해설

【핵심 용어】 ▸ S3 Standard-IA: 저빈도 액세스용 비용 효율적 클래스, 높은 가용성 보장 ▸ S3 Glacier Flexible Retrieval: 장기 보관용, 5시간 검색 시간 충족 (Flexible는 3~5시간) ▸ S3 Lifecycle Policy: 시간 기반 자동 저장소 클래스 이동 규칙 【정답 포인트】 ▸ S3 Standard-IA는 90일 초기 기간 동안 저빈도 액세스에 최적화되고 비용 효율적 ▸ Glacier Flexible Retrieval은 5시간 미만 검색 시간 요구사항 충족 (Deep Archive는 12시간) ▸ 30일 최소 요금 기간 때문에 90일은 Standard-IA 사용에 충분한 기간 【오답 체크】 (B) One Zone-IA는 단일 리전 가용성으로 높은 가용성 요구 미충족; Glacier Deep Archive는 12시간 검색 시간으로 5시간 제한 위반 - 100자 (C) S3 Standard는 초기 90일에 불필요하게 높은 비용; Standard-IA 대비 2~3배 비용 - 75자 (D) Glacier Deep Archive는 5시간 검색 요구사항을 초과하며(12시간), 비용 절감에 부적절 - 80자 【시험 포인트】 ▸ S3 저장소 클래스별 검색 시간(Retrieval Time) 차이 숙지 필수 ▸ Glacier Flexible (3~5시간), Instant (1초), Standard (5시간) ▸ 가용성 요구사항과 비용, 검색 시간의 균형 판단 능력

해설

【핵심 용어】 ▸ IAM Access Analyzer: 실제 API 호출 패턴 분석하여 최소 권한 정책 생성 ▸ CloudTrail: AWS API 호출 로그 기록 서비스 ▸ Policy Generation: 사용된 권한만 포함하는 정책 자동 생성 【정답 포인트】 ▸ Access Analyzer의 Policy Generation 기능은 CloudTrail 로그 분석하여 실제 사용 권한 파악 ▸ CloudTrail이 API 호출을 기록해야 Access Analyzer가 분석 데이터 확보 ▸ 두 서비스 통합으로 최소 권한 정책(Least Privilege) 자동 생성 가능 【오답 체크】 (A) Security Hub는 보안 점수 및 컴플라이언스 검사용이며, 정책 생성 기능 없음 - 80자 (B) EventBridge는 이벤트 라우팅 서비스이며, Access Analyzer와 정책 생성 관계 없음 - 85자 (C) get-generated-policy 명령만으로는 부족; CloudTrail이 먼저 활성화되어야 분석 데이터 존재 - 95자 【시험 포인트】 ▸ IAM Access Analyzer의 Policy Generation 기능 이해 ▸ CloudTrail 로그를 기반한 권한 분석 메커니즘 ▸ 최소 권한 원칙(Principle of Least Privilege) 구현 방법