정답 · 해설

해설

【핵심 용어】 ▸ DiskReadBytes/DiskWriteBytes: 게스트 OS 내부 디스크 I/O (EC2 인스턴스 메타데이터 아님) ▸ VolumeReadBytes/VolumeWriteBytes: CloudWatch에서 제공하는 EBS 볼륨 메트릭 ▸ CloudWatch Agent: 게스트 메트릭 수집용, 기본 EBS 메트릭은 자동 【정답 포인트】 ▸ C가 정답입니다. DiskReadBytes/DiskWriteBytes는 EC2 인스턴스 내부의 디스크 활동을 나타내며, CloudWatch가 기본으로 수집하지 않는 게스트 OS 메트릭입니다. EBS 볼륨 수준의 메트릭은 VolumeReadBytes/VolumeWriteBytes이며, 이는 CloudWatch가 자동으로 제공합니다. 경보를 올바른 메트릭으로 재구성하면 정상 작동합니다. 【오답 체크】 (A) CloudWatch 에이전트는 DiskReadBytes 등 게스트 메트릭 수집용이지, 이미 설치된 맞춤형 도구가 있으므로 불필요. 메트릭 네임스페이스 문제가 아닙니다. 75~90자 (B) Systems Manager Agent는 메트릭 수집과 무관합니다. 패치 관리, 명령 실행 등의 용도입니다. 해결책이 아닙니다. 65~80자 (D) EC2 인스턴스에 VolumeReadBytes 메트릭은 존재하지 않습니다. 이 메트릭은 EBS 볼륨 네임스페이스에만 있습니다. 잘못된 메트릭 경로입니다. 70~85자 【시험 포인트】 ▸ CloudWatch 메트릭 네임스페이스: AWS/EBS vs AWS/EC2 구분 필수 ▸ DiskRead*/DiskWrite* = 게스트 OS 메트릭(에이전트 필수), Volume* = EBS 볼륨 메트릭(자동) ▸ 경보 트리거 실패 시 메트릭 네임스페이스와 가능성 먼저 확인

해설

【핵심 용어】 ▸ CloudWatch Agent: 게스트 메트릭(메모리, 디스크) 수집 필수 ▸ IAM Role: EC2 인스턴스가 CloudWatch에 데이터 푸시 권한 ▸ Guest Metrics: 기본으로는 수집되지 않음(에이전트 필수) 【정답 포인트】 ▸ B가 정답입니다. CloudWatch는 EC2 CPU, 네트워크만 기본 수집하며, 메모리/디스크 같은 게스트 OS 메트릭은 CloudWatch 에이전트 필수. 모든 인스턴스에 에이전트 설치 후, EC2가 CloudWatch로 데이터를 전송할 권한이 필요하므로 IAM 역할 연결 필수. 로그가 아닌 메트릭(metrics)이므로 정확한 구분 필요합니다. 【오답 체크】 (A) AWS Management Console 구성만으로는 에이전트 자동 설치 불가능합니다. 각 인스턴스에 직접 설치 필수. AWS는 자동 설치를 제공하지 않습니다. 80~95자 (C) IAM 사용자는 EC2 인스턴스 권한으로 사용하지 않습니다. EC2에는 역할(role)만 첨부 가능. 사용자는 사람 계정용입니다. 75~90자 (D) 보안 그룹은 포트 접근 제어이며, IAM 권한과는 무관합니다. CloudWatch 메트릭 전송은 보안 그룹이 아닌 IAM 정책 제어입니다. 70~85자 【시험 포인트】 ▸ CloudWatch 기본 메트릭(CPU, Network, EBS) vs 게스트 메트릭(Memory, Disk) 구분 ▸ EC2→CloudWatch 데이터 전송 = IAM Role (AWS Identity, 아님 IAM User) ▸ 에이전트 설치 = 각 인스턴스마다 직접 필수

해설

【핵심 용어】 ▸ gp3: 기본 3,000 IOPS, 최대 16,000 IOPS, IOPS/처리량 독립적 조정 ▸ io2: 높은 IOPS, 더 높은 비용(10,000 IOPS 필요 시 io2보다 gp3 저렴) ▸ HDD(st1/sc1): 처리량 기반, IOPS 보장 안 함 【정답 포인트】 ▸ C가 정답입니다. 10,000 IOPS, 1.75 TB 크기, 고정 용량 요구사항에서 gp3이 최적. gp3는 기본 3,000 IOPS를 초과하는 추가 IOPS를 비교적 저렴하게 제공. 처리량도 독립적으로 조정 가능. 성능/비용 비율에서 io2보다 우수합니다. 【오답 체크】 (A) Cold HDD는 저빈도(cold) 데이터용으로, IOPS 보장 없음. 10,000 IOPS 요구사항 충족 불가. 데이터베이스에 부적절합니다. 65~80자 (B) Throughput Optimized HDD는 처리량 기반이며, IOPS 요구사항 충족 불가. 대량 순차 I/O용이지만, 랜덤 10,000 IOPS는 보장하지 않습니다. 75~90자 (D) io2는 매우 높은 IOPS(최대 64,000)를 지원하지만, 비용이 gp3보다 훨씬 높습니다. 10,000 IOPS는 gp3으로 충분하여 과도한 비용 낭비입니다. 80~95자 【시험 포인트】 ▸ EBS 볼륨 선택: 성능(IOPS/처리량) + 비용 고려 ▸ gp3 = SSD 범용, io2 = SSD 고성능(매우 높은 IOPS), st1/sc1 = HDD ▸ 10,000 IOPS 범위는 gp3(최대 16,000)로 충분, io2 과도

해설

【핵심 용어】 ▸ Target Tracking Policy: CPU 목표값 유지로 자동 확장 ▸ Scheduled Scaling: 시간 기반 사전 할당 ▸ 50% Available Capacity: CPU 사용률 50%를 목표(100%-50%=50% 여유) 【정답 포인트】 ▸ B가 정답입니다. "50% CPU 여유" = CPU 사용률이 50%를 넘지 않도록 관리. 대상 추적 정책에서 CPU 목표를 50%로 설정하면, CPU 사용률 50% 유지(즉, 50% 여유). 추가로 예약된 정책으로 09:00 증설, 17:00 감축하여 피크 시간 대비, 경계 시간 효율화. 세 가지 정책 조합으로 최적화합니다. 【오답 체크】 (A) 90% 목표는 10% 여유만 제공하여 요구사항(50%)의 1/5입니다. 버스트 수용 부족. 대상 추적 정책만으로는 시간 기반 대비 불가능합니다. 80~95자 (C) 고정 2개 인스턴스로는 동적 확장 불가. 피크 시간(09:00-17:00)에 추가 용량 필요하지만, 최소/최대/원하는값이 모두 2로 고정되면 확장 불가. 부분 요구사항만 충족합니다. 85~100자 (D) 예약된 정책만으로는 실시간 부하에 대응 불가. 09:00 이후 버스트 트래픽이 발생하면 확장이 지연. 동적 대상 추적 정책이 필수입니다. 75~90자 【시험 포인트】 ▸ "CPU 여유도" = 100% - 목표 CPU 사용률 ▸ 대상 추적 정책 = 메트릭 기반 동적 확장 ▸ 시간 기반 예측 → 예약된 정책 조합 필수 ▸ 최적화 = 동적(반응형) + 예약(예측형) 이중 정책

해설

【핵심 용어】 ▸ AWS Config: 리소스 구성 감시 및 자동 수정 ▸ Managed Rules: s3-bucket-logging-enabled 규칙 자동화 ▸ Remediation Actions: 비준수 리소스 자동 수정 【정답 포인트】 ▸ B가 정답입니다. AWS Config의 s3-bucket-logging-enabled는 S3 로깅 설정을 지속적으로 모니터링하고, 자동 수정(auto remediation)으로 로깅 미활성화 버킷을 자동 활성화. 새 버킷 생성 시에도 자동 감지 및 수정. 가장 "조작적으로 효율적"(operationally efficient) 솔루션입니다. 【오답 체크】 (A) CloudTrail은 API 호출 감사 추적용이지, S3 로깅 설정 모니터링이 주 목적이 아닙니다. Lambda 함수로 수동 수정 필요하여 번거롭습니다. 75~90자 (C) Trusted Advisor는 정기 권장사항만 제공하며, 자동 수정 기능이 없습니다. 수정을 위해 수동 개입 필요하여 효율적이지 않습니다. 70~85자 (D) CloudWatch는 메트릭 모니터링용이며, 구성(configuration) 감시가 주 목적이 아닙니다. Lambda로 수동 구성 필요하여 자동화 수준 낮습니다. 75~90자 【시험 포인트】 ▸ AWS Config = 구성 관리 및 자동 수정의 핵심 서비스 ▸ Managed Rules = 즉시 사용 가능한 감사 규칙(s3-bucket-logging-enabled 등) ▸ 운영 효율성 = 자동 감지 + 자동 수정 결합

해설

【핵심 용어】 ▸ Instance Scale-in Protection: 특정 인스턴스 축소 차단 ▸ SQS 메시지 처리: 12시간 걸릴 수 있는 긴 작업 ▸ 동적 제어: API 호출로 처리 중 보호 활성화 【정답 포인트】 ▸ A가 정답입니다. Instance Scale-in Protection은 특정 인스턴스가 Auto Scaling 축소 대상에서 제외되도록 합니다. 메시지 처리 시작 시 활성화, 완료 후 비활성화하면, 12시간의 긴 처리 중에도 인스턴스 종료 방지. SQS 메시지 기반 동적 확장과 인스턴스 보호를 조합하는 표준 패턴입니다. 【오답 체크】 (B) OldestInstance 종료 정책은 가장 오래된 인스턴스부터 축소할 뿐, 처리 중인 인스턴스 보호 메커니즘이 없습니다. 여전히 처리 중 중단 위험입니다. 80~95자 (C) OldestLaunchConfiguration도 종료 선택 기준만 결정하며, 처리 중 인스턴스 보호 불가. 메시지 처리 상태와 무관하게 종료될 수 있습니다. 85~100자 (D) Launch/Terminate 프로세스 일시 중단은 그룹 전체 축소 중지로, 다른 작업이 있을 때 비효율적. 특정 인스턴스 보호가 아닌 그룹 전체 제어이므로, 세밀한 제어 불가능합니다. 85~95자 【시험 포인트】 ▸ Instance Scale-in Protection = 개별 인스턴스 수준 축소 차단 ▸ Suspend Processes = Auto Scaling 그룹 전체 프로세스 중지(더 광범위) ▸ SQS 메시지 기반 동적 작업 보호 패턴

해설

【핵심 용어】 ▸ Security Hub: CIS Benchmark 스캔 및 규정 준수 감시 ▸ AWS Organizations Integration: 자동 멤버 계정 등록 ▸ Operational Efficiency: 수동 초대 스크립트 불필요 【정답 포인트】 ▸ D가 정답입니다. AWS Organizations와 Security Hub 통합으로 새 계정이 자동으로 멤버 계정 등록. 수동 초대/수락 스크립트 필요 없음. CIS Benchmark 스캔도 Security Hub에서 기본 지원. 가장 "효율적인 운영 방법"(most operationally efficient)입니다. Organizations 정책으로 전사 규정 준수 자동화. 【오답 체크】 (A) 수동 스크립트로 초대/수락 처리, 새 계정마다 실행 필요. 운영 오버헤드 큼. Organizations 자동화 미활용입니다. 85~100자 (B) Amazon Inspector는 EC2, ECR 취약점 스캔용이며, CIS Benchmark 규정 준수 검사(compliance)와는 다릅니다. 부적절한 도구입니다. 70~85자 (C) Amazon GuardDuty는 위협 탐지(threat detection) 서비스이며, CIS Benchmark 준수 검사를 지원하지 않습니다. Security Hub와 혼동. 올바른 도구가 아닙니다. 80~95자 【시험 포인트】 ▸ Security Hub = CIS/PCI-DSS 등 규정 준수 감시 및 자동화 ▸ AWS Organizations 통합 = 신규 계정 자동 등록, 수동 작업 제거 ▸ Inspector = 취약점, GuardDuty = 위협, Security Hub = 규정 준수

해설

【핵심 용어】 ▸ Virtual Private Gateway: 온프레미스 연결 엔드포인트 ▸ Route Table: 각 서브넷별 라우팅 규칙(독립적) ▸ VPN Propagation: VGW 경로 자동 배포(수동 설정도 가능) 【정답 포인트】 ▸ A가 정답입니다. Site-to-Site VPN 자체는 양쪽 AZ 모두 지원합니다. 문제는 신규 서브넷의 라우팅 테이블이 온프레미스 트래픽을 VGW로 라우팅하는 규칙이 없기 때문입니다. VPN 연결이 암묵적으로 새 서브넷 경로를 학습하지 않으므로, 라우팅 테이블에 명시적으로 온프레미스 목적지(예: 10.0.0.0/8)→VGW 규칙 추가 필요. 【오답 체크】 (B) Site-to-Site VPN은 이미 모든 AZ 지원. AWS Support 요청이 필요 없습니다. VPN 라우팅 구성은 고객 측(라우팅 테이블)에서 제어합니다. 80~95자 (C) 새 VPN 연결 설정은 불필요합니다. 단일 VGW는 모든 AZ의 트래픽을 처리할 수 있습니다. 문제는 라우팅 테이블 설정입니다. 75~90자 (D) Direct Connect 교체는 과도한 조치이며, 현재 문제(라우팅 테이블)와 무관합니다. 비용/시간 낭비입니다. 65~80자 【시험 포인트】 ▸ VPC 라우팅은 서브넷별 라우팅 테이블로 제어 ▸ VPN 연결은 AZ 제약 없음, 라우팅 테이블 설정 필수 ▸ VPN Propagation 자동화 또는 수동 라우팅 경로 추가 방법

해설

【핵심 용어】 ▸ Parameter Store: 중앙집중식 에이전트 구성 저장소 ▸ Systems Manager: 대규모 에이전트 배포 및 구성 관리 ▸ Configuration as Code: 단일 구성으로 수백 인스턴스 통일 관리 【정답 포인트】 ▸ D가 정답입니다. 수백 개의 인스턴스에 동일한 에이전트 구성을 배포해야 하는 경우, Parameter Store에 구성을 중앙 저장하고, Systems Manager로 대규모 배포하면 "가장 적은 운영 오버헤드". 각 인스턴스가 Parameter Store에서 구성을 자동 로드하므로, 구성 변경 시 모든 인스턴스에 즉시 반영. 스케일 확장성과 일관성 최적입니다. 【오답 체크】 (A) syslogd는 시스템 로그만 처리. 애플리케이션 맞춤 로그 파일 수집 기능이 제한적. CloudWatch와의 통합도 약합니다. 75~90자 (B) Amazon Linux 패키지 관리자로 각 인스턴스에 개별 설치 후 수동 구성. 수백 인스턴스 관리 시 오버헤드 매우 큼. 중앙 관리 불가능합니다. 85~100자 (C) Systems Manager로 설치는 좋으나, CloudWatch 마법사로 각 인스턴스마다 구성 생성 필수. 수백 인스턴스는 수동 반복 작업. 중앙집중식 구성 미지원입니다. 85~100자 【시험 포인트】 ▸ 대규모 에이전트 배포 = Parameter Store + Systems Manager 조합 필수 ▸ Configuration as Code 패턴으로 운영 효율성 극대화 ▸ 인스턴스 개수 증가 시 수동 작업 제거 필수

해설

【핵심 용어】 ▸ RTO/RPO 15분: 매우 짧은 시간, 사전 준비 필수 ▸ Aurora Global Database: 거의 0 RPO, 자동 복제 ▸ Warm Standby: DR 리전에 최소 리소스 사전 배치(비용 최적화) 【정답 포인트】 ▸ B, D가 정답입니다. (B) Aurora Global Database로 데이터 실시간 복제(RPO 거의 0, RTO 낮음). (D) DR 리전에 최소 용량(1) ALB + Auto Scaling 사전 배치로 빠른 스케일 아웃 가능. "가장 비용 효율적"은 사전 준비(warm standby, 최소 용량) + 자동 복제 조합. A,C,E는 비용 낭비 또는 RTO 초과. 【오답 체크】 (A) Aurora 백업 내보내기는 느림(RTO/RPO 15분 미만 충족 불가). 수동 복원 필요합니다. 75~90자 (C) DR 리전에 기본 리전과 동일 구성(최대/원하는 용량 동등)은 비용 2배 낭비. Warm Standby 미적용으로 비용 비효율입니다. 80~95자 (E) CloudFormation 수동 시작은 느려서 RTO 15분 달성 불가. 자동화 부재로 장애 조치 지연 발생합니다. 70~85자 【시험 포인트】 ▸ RTO/RPO 15분 = Warm Standby + 거의 실시간 복제(Aurora Global) 필수 ▸ Aurora Global Database = RPO 거의 0, 자동 복제 ▸ 비용 최적화 = DR 최소 용량, 확장 자동화

해설

【핵심 용어】 ▸ Ephemeral Ports: 반환 트래픽용 임시 포트(1024-65535) ▸ Outbound Rule (ACL): 상태 비저장, 양방향 명시 필요 ▸ Stateless vs Stateful: ACL은 상태 비저장 【정답 포인트】 ▸ A가 정답입니다. 클라이언트가 HTTP 포트 80으로 요청을 보내면, 서버가 임시 포트(ephemeral port, 1024-65535)로 응답을 반환합니다. Network ACL은 상태 비저장이므로, 인바운드 규칙(HTTP 포트 80)만 허용해서는 아웃바운드 임시 포트 반환 트래픽이 차단됩니다. 아웃바운드 규칙에서 임시 포트 범위 명시 필요. 【오답 체크】 (B) 보안 그룹은 상태 저장(stateful)이므로, 인바운드 허용 → 자동으로 반환 트래픽 허용. 아웃바운드 규칙 별도 불필요. 이것이 문제 원인이 아닙니다. 75~90자 (C) Elastic IP는 인스턴스에 계속 연결되면 변경되지 않습니다. 문제 원인이 아닙니다. 55~70자 (D) 문제에서 "새 네트워크 ACL"만 생성했으므로, 기존 ACL은 기본 allow all입니다. 추가 ACL 없음. 가정 위반입니다. 70~85자 【시험 포인트】 ▸ Network ACL = 상태 비저장, 인바운드/아웃바운드 모두 명시 필수 ▸ Security Group = 상태 저장, 인바운드만 설정하면 반환 자동 ▸ 웹 서버 인바운드 트래픽 → 임시 포트 아웃바운드 반환

해설

【핵심 용어】 ▸ AWS Backup: EFS 완전 관리형 백업 ▸ Partial Restore: 개별 파일 선택 복원(빠름) ▸ S3 Glacier: 검색 지연(시간~일), 비용 저렴하지만 속도 느림 【정답 포인트】 ▸ D가 정답입니다. AWS Backup은 EFS 백업 전문 서비스이며, Partial Restore Job으로 개별 파일 "빠른 복구" 지원(S3 Glacier 검색 지연 없음). 백업 자격증명 모음에 저장되어 비용 효율적. "개별 파일을 빠르게 복구" 요구사항 완벽 충족. Glacier 검색(수시간~24시간) 대비 몇 분 내 복원. 【오답 체크】 (A) Amazon DLM + S3 Glacier는 아카이빙 목적이며, 개별 파일 검색이 느림(Glacier 검색 대기 시간). 빠른 복구 요구사항 미충족. 80~95자 (B) 다른 리전 EFS는 비용 2배(원본+백업), 복제 지연 발생. DataSync 수동 복사도 번거로움. 비용 효율성 낮습니다. 85~100자 (C) S3 Glacier 검색은 짧게는 수시간, 길게는 24시간. "빠르게 복구" 요구사항 미충족. 임시 액세스에 부적절합니다. 75~90자 【시험 포인트】 ▸ AWS Backup EFS = Partial Restore로 개별 파일 빠른 복구 ▸ S3 Glacier = 비용 저렴하지만 검색 지연(속도 느림) ▸ RTO 중시 → Backup 자격증명, 비용 최적화 → S3 Glacier(속도 희생)

해설

【핵심 용어】 ▸ S3 Object Lock: 객체의 삭제/수정을 방지하는 WORM 스토리지 모델 ▸ 거버넌스 모드(Governance mode): 특정 권한으로 보존 설정을 우회 가능 ▸ 법적 보유(Legal Hold): 거버넌스 모드에서는 우회 불가능 ▸ s3:BypassGovernanceRetention: 거버넌스 모드 우회 권한 【정답 포인트】 ▸ 거버넌스 모드에서는 s3:BypassGovernanceRetention 권한을 가진 역할로 우회 가능 ▸ x-amz-bypass-governance-retention:true 헤더를 요청에 포함하여 거버넌스 우회 ▸ 두 조건 모두 필요: 역할 권한 + 헤더 포함 ▸ Legal Hold는 거버넌스 모드에서 우회 불가(법적 요구) 【오답 체크】 (A) Retain Until Date 증가는 보존 기간을 연장할 뿐 삭제를 허용하지 않음 (B) BypassLegalRetention은 법적 보유 우회용이며, 거버넌스 모드에는 필요 없음 (E) x-amz-bypass-legal-retention 헤더는 법적 보유 우회용이며, 거버넌스 모드에는 불필요 【시험 포인트】 ▸ S3 Object Lock의 거버넌스 모드와 법적 보유 모드 차이 이해 ▸ 거버넌스 우회에 필요한 IAM 권한과 헤더의 동시 필요성 ▸ CLI 삭제 명령 시 bypass 헤더 사용법

해설

【핵심 용어】 ▸ 네트워크 ACL(NACl): 서브넷 수준의 상태 비저장 방화벽 ▸ 에페메랄 포트(Ephemeral Port): 응답 트래픽용 임시 포트 범위(1024~65535) ▸ 상태 비저장(Stateless): ACL의 인바운드/아웃바운드 규칙을 모두 구성해야 함 ▸ MySQL/Aurora 포트: TCP 3306 【정답 포인트】 ▸ 웹 서브넷 → DB 서브넷: 포트 3306(MySQL) 인바운드 필요 ▸ DB 서브넷 → 웹 서브넷: 에페메랄 포트 범위 아웃바운드 필요(응답) ▸ 3번째 서브넷도 웹 계층이므로 동일한 규칙 필요 ▸ 네트워크 ACL은 상태 비저장이므로 요청과 응답 경로 모두 명시적 허용 필요 【오답 체크】 (A) 기본 ACL의 인바운드는 이미 모든 트래픽 허용(기본 규칙) (B) 웹 서브넷의 네트워크 ACL 수정이 필요함(데이터베이스 서브넷 아님) (E) 포트 3306은 단방향(웹→DB)으로만 필요하고 응답은 에페메랄 포트 사용 【시험 포인트】 ▸ 네트워크 ACL의 상태 비저장 특성과 양방향 규칙 이해 ▸ 클라이언트 요청 포트와 서버 응답 포트 범위 구분 ▸ 새로운 서브넷 추가 시 네트워크 ACL 규칙 검토 필요성

해설

【핵심 용어】 ▸ ELB(Elastic Load Balancer): Classic Load Balancer용 AWS CLI 명령 ▸ set-load-balancer-listener-ssl-certificate: ELB SSL 인증서 설정 명령 ▸ IAM 인증서 ARN: arn:aws:iam::123456789012:server-certificate/... ▸ 리스너 포트: HTTPS 통신용 포트 443 【정답 포인트】 ▸ ELB는 'aws elb' 명령을 사용합니다 ▸ set-load-balancer-listener-ssl-certificate는 ELB 리스너의 SSL 인증서를 설정하는 정확한 명령 ▸ --load-balancer-port 443으로 HTTPS 리스너 지정 ▸ --ssl-certificate-id로 IAM 인증서 ARN 지정 【오답 체크】 (A) 'aws kms modify-listener'는 존재하지 않는 명령(KMS는 암호화 키 관리용) (C) 'aws ec2 put-ssl-certificate'는 EC2 관련 명령이 아닌 Classic Load Balancer용 명령 불가 (D) 'aws acm put-ssl-certificate'는 존재하지 않으며, ACM은 인증서 저장소일 뿐 로드 밸런서 설정 명령이 아님 【시험 포인트】 ▸ ELB, ALB, NLB 등 로드 밸런서 유형별 AWS CLI 명령 차이 ▸ SSL 인증서를 로드 밸런서에 배포하는 정확한 CLI 명령어 ▸ IAM에 저장된 인증서의 ARN 형식 이해

해설

【핵심 용어】 ▸ EC2 Image Builder: AMI 생성 자동화 및 테스트 서비스 ▸ 취약점 스캔: 이미지 빌드 후 자동 보안 검사 ▸ 파이프라인(Pipeline): 정기적인 이미지 빌드 자동화 ▸ 사용자 정의 레시피: 설치 단계와 구성을 정의하는 템플릿 【정답 포인트】 ▸ EC2 Image Builder는 AMI 생성 전체 프로세스를 자동화합니다 ▸ 내장된 취약점 스캔 기능으로 보안 검증 자동 수행 ▸ 파이프라인을 통해 매주 자동으로 최신 이미지 생성 가능 ▸ 운영 효율성: 관리 작업 최소화, 일관된 이미지 생성 【오답 체크】 (A) Packer + 크론 작업은 취약점 스캔 자동화 기능 부족 (B) 수동 프로세스로 정기적 업데이트 적용 불가, 일관성 부족 (D) EventBridge로 API 호출은 이미지 생성만 수행하고 취약점 검사 미흡 【시험 포인트】 ▸ EC2 Image Builder의 자동화 및 보안 검증 기능 ▸ 정기적인 이미지 업데이트와 취약점 스캔의 통합 솔루션 ▸ Packer와 EC2 Image Builder의 차이점

해설

【핵심 용어】 ▸ Snapshot Deletion Policy: CloudFormation 스택 삭제 시 스냅샷 생성 정책 ▸ DeletionPolicy: 리소스 삭제 시 동작을 제어하는 CloudFormation 속성 ▸ Snapshot: RDS 데이터의 완전한 백업 지점 ▸ 스택 삭제 보호: 자동으로 데이터 보존 메커니즘 적용 【정답 포인트】 ▸ CloudFormation에서 RDS 리소스에 DeletionPolicy: Snapshot을 설정 ▸ 스택 삭제 시 자동으로 최종 스냅샷 생성 ▸ 스냅샷은 계정에 유지되어 나중에 복구 가능 ▸ 안정적이고 자동화된 방식으로 데이터 보존 【오답 체크】 (A) 5분마다 백업은 비효율적이고 불필요한 비용 증가 (B) 수동 Lambda 호출은 자동화 불가, 운영 효율성 낮음 (D) 별도의 CloudFormation 템플릿 실행은 복잡하고 자동화 미흡 【시험 포인트】 ▸ CloudFormation의 DeletionPolicy와 Snapshot 옵션 이해 ▸ 스택 삭제 시 자동으로 데이터 보존하는 메커니즘 ▸ 개발 환경 임시 구성에서 데이터 보호 전략

해설

【핵심 용어】 ▸ EventBridge API Destinations: HTTP/S 엔드포인트로 직접 메시지 전송 ▸ Input Transformer: 이벤트 데이터 형식 변환 및 매핑 ▸ CloudWatch Events: CloudFormation 스택 변경 사항 캡처 ▸ 최소 개발 시간: 코드 작성 없이 구성만으로 구현 【정답 포인트】 ▸ EventBridge API Destinations는 HTTPS 엔드포인트로 직접 전송 가능 ▸ Input Transformer로 CloudWatch 이벤트를 JSON 형식으로 변환 ▸ Lambda, Kinesis, Glue 없이 순수 EventBridge만으로 구현 ▸ 최소한의 설정으로 빠른 구현 가능 【오답 체크】 (B) Kinesis + Lambda + Glue는 복잡한 파이프라인으로 개발 시간 증가 (C) SNS는 HTTP 엔드포인트에 직접 메시지 변환 기능 미흡 (D) Step Functions + Lambda + Glue는 가장 복잡하고 개발 시간 증가 【시험 포인트】 ▸ EventBridge API Destinations의 사용 사례 ▸ Input Transformer로 이벤트 데이터 형식 변환 ▸ 최소 개발 시간으로 외부 시스템 통합하는 방법

해설

【핵심 용어】 ▸ Capacity Optimized Strategy: 할당 실패율이 가장 낮은 풀 선택 ▸ Diversified Strategy: 여러 Spot 풀에 분산하여 중단 위험 감소 ▸ Spot 인스턴스 풀: 동일한 인스턴스 유형, AZ, OS 조합 ▸ Spot 가용성: 인스턴스 유형에 따른 중단 가능성 차이 【정답 포인트】 ▸ 용량 최적화 전략은 요청된 용량에 대해 가장 낮은 중단 가능성을 가진 풀 선택 ▸ 가용성이 높은 풀로부터 인스턴스를 우선적으로 시작 ▸ 광범위한 인스턴스 유형에서 최적의 조합 자동 선택 ▸ 정적 Advisor 조언보다 동적 최적화 【오답 체크】 (A) 최대 용량까지 시작은 가용성 고려 없음 (B) 다양화 전략은 고르게 분산하되 가용성 최적화 아님 (D) Spot Advisor는 정적 권고사항일 뿐 Auto Scaling 전략 아님 【시험 포인트】 ▸ Spot 인스턴스 할당 전략의 종류와 특징 ▸ 용량 최적화 전략의 장점과 사용 사례 ▸ Auto Scaling 그룹에서 가용성과 비용의 균형

해설

【핵심 용어】 ▸ AMI 복사: 한 리전의 AMI를 다른 리전으로 복제하는 프로세스 ▸ 리전별 리소스: AMI는 리전별로 관리되며 교차 리전 사용 불가 ▸ Copy Image 명령: aws ec2 copy-image를 사용한 복사 ▸ 스냅샷 복제: AMI 복사 시 자동으로 EBS 스냅샷도 복제 【정답 포인트】 ▸ AMI는 특정 리전에만 존재하므로 다른 리전에서 사용 불가 ▸ 추가 리전에서 사용하려면 copy-image 명령으로 복사 필요 ▸ 복사된 AMI는 대상 리전에서 독립적으로 관리됨 ▸ 복사 중에 암호화 변경도 가능 【오답 체크】 (B) 공개 공유는 Community AMI로 전환되어 수정 불가능 (C) AMI 공유는 같은 리전 내 계정 간 공유 기능이지 교차 리전 사용 불가 (D) S3로 복사는 과정이 복잡하고 AMI 복사 기능이 아님 【시험 포인트】 ▸ AWS 리소스의 리전 종속성 이해 ▸ AMI copy-image 명령과 사용 사례 ▸ 리전별 리소스 관리 및 마이그레이션 전략