정답 · 해설

해설

【핵심 용어】 ▸ RPO(Recovery Point Objective) — 0은 데이터 손실이 없음을 의미, 즉 실시간 동기화 필수. ▸ RTO(Recovery Time Objective) — 10분은 빠른 복구 시간 요구. ▸ Active-Active — 양쪽 리전에서 동시에 트래픽을 처리하고 실시간 복제를 수행하는 구조. 【정답 포인트】 ▸ "실시간 데이터 복제" — RPO 0을 달성하려면 양쪽 리전이 항상 동기화되어야 함. ▸ "액티브-액티브" — 두 리전이 동시에 활성화되어 장애 시 즉시 절환 가능하므로 RTO 10분 이내 달성. 【오답 체크】 (A) 파일럿 라이트는 대기 리소스가 최소화되어 있어 RTO 10분 달성 어려움. (B) 웜 스탠바이는 정기적 복제만 하므로 RPO 0 달성 불가(데이터 손실 가능). (D) 백업 복구는 수동 프로세스로 RTO 10분 달성 불가, RPO도 보장되지 않음. 【시험 포인트】 ▸ Active-Active — 가장 높은 가용성, RPO 0, RTO 최소화. ▸ 라우팅 정책 — 가중치 기반으로 양쪽 리전 간 트래픽 분산.

해설

【핵심 용어】 ▸ CloudWatch Application Signals — 메트릭, 로그, 추적을 자동으로 수집하여 상호 연관시키는 AWS 관찰성 서비스, SLO/SLI 정의 및 모니터링을 간편하게 지원. ▸ DORA 메트릭 — 지연 시간, 트래픽, 오류, 포화(4개 황금 신호)를 추적. 【정답 포인트】 ▸ "자동 수집 및 모니터링" — Application Signals가 EKS 워크로드에서 자동으로 메트릭 수집. ▸ "메트릭, 로그, 추적 상호 연관" — Application Signals는 3가지를 하나의 플랫폼에서 통합. ▸ "SLO/SLI 정의" — Application Signals에서 직접 지원. 【오답 체크】 (B) OpenTelemetry + Prometheus + Grafana는 수동 구성이 많고, 상호 연관 기능이 제한적이며 운영 오버헤드 높음. (C) RUM과 Synthetics는 클라이언트 측과 외부 모니터링 중심이며, 완전한 SLO/SLI 지원 없음. (D) Application Insights는 이상 감지에 중점이며, SLO/SLI 정의 및 추적 상호 연관 기능이 없음. 【시험 포인트】 ▸ Application Signals — EKS에 최적화된 신규 서비스로, 최소 운영 노력 솔루션. ▸ DORA 메트릭 또는 황금 신호 — 4가지 핵심 메트릭을 자동 추적.

해설

【핵심 용어】 ▸ Multi-AZ Deployment — RDS 인스턴스가 여러 가용 영역에 걸쳐 배포되어 자동 장애 조치를 지원하는 구성. ▸ Backup Retention Period — 자동 백업을 유지하는 일 수, Multi-AZ에서는 최소 1일 이상 필수. 【정답 포인트】 ▸ "보존 기간 1~35" — Multi-AZ RDS는 자동 백업 비활성화(0일 설정)를 허용하지 않음, 최소 1일 유지 필수. ▸ "오류 메시지의 의미" — 자동 백업을 0일로 설정할 수 없다는 제약 표시. 【오답 체크】 (A) IAM 권한 부족은 다른 오류 메시지(Access Denied) 발생. (B) Read replicas가 있어도 백업 비활성화는 가능하지만, 복제 중단 시 추가 백업 필요. (C) 기본 백업 윈도우는 보존 기간과 무관, 오류 원인이 아님. 【시험 포인트】 ▸ Multi-AZ RDS — 백업 비활성화 불가, 최소 1일 유지 강제. ▸ Single-AZ는 0일(비활성화) 가능.

해설

【핵심 용어】 ▸ Amazon CloudWatch agent — EC2 게스트 OS 내부의 상세 메트릭(메모리, 네트워크, ENA 드라이버 메트릭 등) 수집·게시하는 관리형 에이전트 ▸ ENA driver 메트릭 — conntrack_allowance_available/exceeded 등 Nitro 기반 인스턴스의 연결 추적 한도 메트릭, OS 내부에서만 노출 ▸ VPC Flow Logs — IP 트래픽 흐름 로그(수락/거부)만 기록, 드라이버 레벨 메트릭 미제공 ▸ Performance Insights — RDS/Aurora DB 부하 분석용, EC2 네트워크 메트릭과 무관 【정답 포인트】 ▸ conntrack_allowance_* 는 ENA 드라이버가 게스트 OS 내부에서만 노출 → CloudWatch agent로 수집해야 CloudWatch에서 조회 가능 ▸ "가장 운영 효율적" → agent 단독 설치만으로 충족(추가 데몬 불필요) 【오답 체크】 (B) collectd 데몬은 불필요한 추가 구성요소, agent만으로 ENA 메트릭 수집 가능해 운영 복잡도만 증가. (C) VPC Flow Logs는 트래픽 흐름 로그일 뿐 conntrack 드라이버 메트릭을 제공하지 않음. (D) Performance Insights는 RDS/Aurora DB 성능 분석 도구로 EC2 ENA 메트릭과 무관. 【시험 포인트】 "게스트 OS 내부 메트릭(메모리·ENA·디스크)" → CloudWatch agent. Flow Logs/기본 모니터링으로는 안 나옴.

해설

【핵심 용어】 ▸ S3 Event Notification — S3 이벤트를 Lambda/SNS/SQS로 전달, 대상 검증 시 기존 알림 설정도 함께 검사 ▸ Lambda 리소스 기반 정책 — S3가 함수를 호출하려면 필요, 문제에서 IAM은 정상 확인됨 ▸ 대상 검증(destination validation) — 새 알림 저장 시 버킷의 전체 알림 구성을 재검증 【정답 포인트】 ▸ 새 함수·IAM은 정상인데 "Unable to validate the following destination configurations" 발생 → 버킷에 이미 존재하는 오래된(stale) 알림이 삭제되었거나 권한 없는 리소스를 가리켜 전체 검증 실패 ▸ S3는 알림 구성 저장 시 모든 대상을 검증하므로 기존 stale 항목이 신규 설정까지 막음 【오답 체크】 (A) 알림 대상 최대 개수 초과가 원인이면 다른 오류 메시지, 검증 실패 메시지와 무관. (B) 크로스 계정 리소스 정책 문제는 지문의 동일 계정·정상 IAM 전제와 불일치. (C) 함수 리소스 정책 누락이면 IAM 정상 확인 전제와 모순, 콘솔이 자동 추가함. 【시험 포인트】 "IAM 정상인데 destination 검증 실패" → 버킷의 기존 stale 이벤트 알림이 원인.

해설

【핵심 용어】 ▸ S3 Storage Lens — 조직/버킷 단위 스토리지 분석 대시보드, Incomplete Multipart Upload Bytes 메트릭 제공 ▸ Incomplete Multipart Upload — 실패·미완료 멀티파트 업로드 조각, 삭제 전까지 스토리지 비용 발생 ▸ S3 Lifecycle policy — AbortIncompleteMultipartUpload 규칙으로 N일 후 미완료 업로드 자동 삭제 【정답 포인트】 ▸ "미완료 업로드 메트릭 표시" → S3 Storage Lens의 Incomplete Multipart Upload Bytes 메트릭 ▸ "7일 후 자동 삭제" → S3 Lifecycle 정책의 미완료 멀티파트 업로드 중단 규칙이 표준·관리형 해법 【오답 체크】 (B) Intelligent-Tiering은 스토리지 클래스 이동용, Storage Lens는 삭제 정책 기능 없음(둘 다 오용). (C) 콘솔 Metrics 탭+Lambda 커스텀 삭제는 불필요한 개발·운영 오버헤드. (D) storage class analysis는 미완료 업로드 측정 도구 아님, 버킷 정책으로 자동 삭제 불가. 【시험 포인트】 "미완료 멀티파트 업로드 가시성=Storage Lens, 자동 삭제=Lifecycle 규칙" 조합.

해설

【핵심 용어】 ▸ EBS 기반 AMI 공유 — AMI가 KMS 암호화 시 스냅샷 복호화 권한(KMS 키 접근)까지 대상 계정/사용자에 부여해야 부팅 가능 ▸ AWS KMS 키 접근 — 암호화 볼륨을 마운트하려면 인스턴스 시작 주체가 해당 KMS 키 사용 권한 필요 ▸ 즉시 종료(terminated) — 암호화 볼륨 복호화 실패 시 부팅 못 하고 인스턴스가 곧바로 종료됨 【정답 포인트】 ▸ "인스턴스는 시작됐지만 즉시 종료" → RunInstances 권한·SCP 문제였다면 시작 자체가 거부됨 ▸ 암호화 AMI의 KMS 키에 대한 접근 권한이 없어 루트 볼륨 복호화 실패 → 부팅 불가로 즉시 종료 【오답 체크】 (A) ec2:RunInstances 권한 없으면 API 호출 단계에서 거부, 인스턴스가 아예 시작되지 않음. (C) SCP 거부도 시작 요청 자체가 차단됨, "시작 후 종료" 증상과 불일치. (D) 인터넷 없는 서브넷은 부팅과 무관, 인스턴스는 정상 실행 상태 유지. 【시험 포인트】 "공유 암호화 AMI로 시작 후 즉시 종료" → KMS 키 grant/접근 권한 누락.

해설

【핵심 용어】 ▸ AWS Site-to-Site VPN — 온프레미스 네트워크와 VPC 간 암호화 터널, 사설 서브넷 인스턴스에 프라이빗 IP로 접근 가능 ▸ Private subnet — 인터넷 게이트웨이 라우트 없는 서브넷, 외부 직접 접근 불가 ▸ NAT gateway/Internet gateway — 아웃바운드/퍼블릭 접근용이며 사설 서브넷으로의 인바운드 SSH 제공 안 함 【정답 포인트】 ▸ "사설 서브넷 인스턴스에 사무실 데스크톱에서 SSH" + "보안 유지" → 회사망과 VPC를 Site-to-Site VPN으로 연결해 프라이빗 경로로 접근 ▸ 인스턴스를 인터넷에 노출하지 않고 온프레미스↔VPC 사설 연결 확보 【오답 체크】 (A) NAT gateway는 사설 서브넷의 아웃바운드 전용, 인바운드 SSH 접근 불가. (C) Internet gateway 부착은 인스턴스를 퍼블릭 노출시켜 보안 요구와 배치되고 사설 서브넷엔 무의미. (D) 퍼블릭 서브넷용 SG 규칙은 사설 서브넷 인스턴스 접근과 무관. 【시험 포인트】 "사설 서브넷 자원에 온프레미스에서 사설 접근" → Site-to-Site VPN(또는 DX).

해설

【핵심 용어】 ▸ CloudFront 캐시 적중률(cache hit ratio) — 엣지에서 처리되는 요청 비율, 캐시 키 구성이 좌우 ▸ 캐시 키(cache key) — 요청 헤더/쿼리 스트링/쿠키 조합, 항목이 많을수록 캐시 세분화되어 적중률 하락 ▸ TTL — 객체 캐시 유지 시간, 짧을수록 origin 재요청 증가 【정답 포인트】 ▸ "적중률 낮음" 원인은 캐시 키가 과도하게 세분화된 것 → 헤더·쿼리 스트링·쿠키를 줄여 캐시 키 단순화하면 동일 캐시 항목 재사용↑ ▸ 불필요한 요소 제거로 적중률 상승 【오답 체크】 (A) max-age=0은 캐싱 사실상 비활성화, 적중률을 더 떨어뜨림. (B) TTL 축소는 재검증 빈도를 높여 origin 요청 증가, 적중률 하락. (D) 서명 URL/쿠키는 접근 제어 기능으로 캐시 적중률과 무관. 【시험 포인트】 "캐시 적중률 향상" → 캐시 키(헤더·쿼리·쿠키) 최소화 + TTL 증가.

해설

【핵심 용어】 ▸ Aurora Backtrack — 백업 복원 없이 클러스터를 특정 과거 시점으로 되감는 기능(MySQL 호환), 빠르고 in-place ▸ Backtrack window — 되감기 가능한 시간 범위(예: 48시간) ▸ EventBridge + Lambda — 매일 스케줄로 backtrack 작업 자동 호출 【정답 포인트】 ▸ "매일 데이터 리셋" + "가장 운영 효율적" → Backtrack 활성화 후 매일 EventBridge로 Lambda 호출해 데이터 채운 시점으로 되감기 ▸ 스냅샷 복원/클러스터 재생성 없이 in-place 되감기라 최소 오버헤드 【오답 체크】 (A) 스냅샷 복원 후 기존 클러스터 삭제는 신규 클러스터 생성·엔드포인트 변경 등 오버헤드 큼. (C) S3로 스냅샷 export 후 복원은 시간·복잡도 과다. (D) 특정 시점 복원(PITR)도 새 클러스터를 만들고 이전 것 삭제하는 반복 작업으로 비효율. 【시험 포인트】 "Aurora MySQL 데모 데이터 일일 리셋" → Backtrack. 복원/재생성 없는 in-place 되감기.

해설

【핵심 용어】 ▸ Systems Manager Maintenance Window — 정해진 시간대(업무 외)에 정기 작업 실행하는 관리형 스케줄러 ▸ AWS-RestartEC2Instance runbook — EC2 재시작 자동화 문서 ▸ Maintenance Window 타겟 등록 — 대상 인스턴스에 지정 시간에 runbook 실행 【정답 포인트】 ▸ "매일 자동 재부팅" + "업무 시간 중 방해 최소화" → SSM 유지 관리 기간을 업무 외 시간으로 설정하고 인스턴스를 타겟 등록, AWS-RestartEC2Instance runbook 할당 ▸ 정해진 오프피크 시간에 안전하게 정기 재부팅 【오답 체크】 (A) StartInstances는 이미 실행 중 인스턴스에 무효(중지 상태 대상), 재부팅 요구 미충족. (C) StatusCheckFailed_System 알람 기반 재부팅은 장애 발생 시에만 동작, 매일 예방적 재부팅 아님. (D) "애플리케이션 재시작" EC2 알람 액션은 존재하지 않음(EC2 액션은 정지/종료/재부팅/복구뿐). 【시험 포인트】 "정해진 시간 정기 유지보수 작업" → SSM Maintenance Window + runbook.

해설

【핵심 용어】 ▸ S3 Bucket Keys — 버킷 단위로 KMS 데이터 키를 재사용해 KMS API 호출을 대폭 줄이는 기능, SSE-KMS 비용 절감 ▸ SSE-KMS — 객체마다 KMS 호출 발생 → 읽기 많으면 KMS 트랜잭션 비용 급증 ▸ 기존 KMS 키 유지 — 암호화 방식·기존 객체 접근 그대로 유지 【정답 포인트】 ▸ "KMS 비용 절감" + "암호화 유지" + "기존 객체 접근 유지" + "최소 오버헤드" → S3 Bucket Keys 활성화(기존 KMS 키 지정)로 KMS 호출 횟수 감소 ▸ 설정 토글만으로 즉시 적용, 재암호화 불필요 【오답 체크】 (B) SSE-C 전환은 키 관리를 클라이언트로 넘겨 운영 부담↑, 기존 객체 접근 방식 변경 필요. (C) CloudFront 캐싱은 KMS 호출 근본 감소책 아님, 아키텍처 추가. (D) S3 Access Point는 접근 관리용, KMS 트랜잭션 비용과 무관. 【시험 포인트】 "SSE-KMS 읽기 트랜잭션 비용 절감" → S3 Bucket Keys 활성화.

해설

【핵심 용어】 ▸ ALB round robin — 대상에 요청을 균등 분배하는 기본 알고리즘 ▸ Sticky sessions(stickiness) — 동일 클라이언트를 같은 대상으로 고정, 장바구니 세션 유지 ▸ Cross-zone load balancing — AZ 경계 넘어 모든 healthy 대상에 균등 분산 【정답 포인트】 ▸ "모든 healthy 인스턴스에 고른 분배" → round robin + cross-zone load balancing ▸ "장바구니 세션 지속성" → stickiness 활성화 ▸ 관리 노력 최소 → ALB 기본 기능만 켜면 됨 【오답 체크】 (B) NLB 전환·cross-zone 비활성화는 균등 분산 요구와 배치, 불필요한 재구성. (C) Lambda+DynamoDB로 세션 저장은 과도한 개발·운영 오버헤드. (D) 경로 기반 라우팅 분리는 장바구니만 목적일 때 불필요하게 복잡. 【시험 포인트】 "균등 분산 + 세션 지속성 최소 노력" → ALB round robin + stickiness + cross-zone.

해설

【핵심 용어】 ▸ CloudWatch 알람 → Lambda 액션 — 메트릭 임계값 초과 시 알람이 직접 Lambda 실행(알람 액션 지원) ▸ HTTPCode_Target_5XX_Count — ALB 대상 그룹의 5xx 응답 수 메트릭 ▸ 신뢰성 있는 탐지 — 관리형 메트릭 기반 알람으로 500 오류 감지 【정답 포인트】 ▸ "HTTP 500 감지 시 Lambda 실행" → HTTPCode_Target_5XX_Count 메트릭에 CloudWatch 알람 설정, 알람 액션으로 Lambda 호출 ▸ 관리형 메트릭 기반이라 신뢰성 높고 구성 간단 【오답 체크】 (B) 액세스 로그 상시 스캔 Lambda는 지연·비용·복잡도 큼, 실시간성 떨어짐. (C) CloudTrail은 API 활동 로그로 HTTP 상태 코드 탐지에 부적합. (D) 모든 ALB 요청 이벤트를 EventBridge로 받는 방식은 존재하지 않으며 대량 비효율. 【시험 포인트】 "ALB 5xx 감지 → 액션 실행" → HTTPCode_Target_5XX_Count 메트릭 CloudWatch 알람.

해설

【핵심 용어】 ▸ CloudFront invalidation — 엣지 캐시의 특정 객체를 무효화해 origin에서 최신본 재요청하게 함 ▸ 캐시 stale 콘텐츠 — TTL 만료 전까지 엣지가 이전 버전 제공 ▸ S3 origin — 정적 웹사이트 원본, 콘텐츠 갱신 시 캐시 무효화 필요 【정답 포인트】 ▸ "업데이트 후 이전 버전 표시" → CloudFront 엣지 캐시가 stale → 새 콘텐츠 업로드 시 invalidation 실행으로 최신본 강제 배포 【오답 체크】 (A) S3 ACL 공개는 접근 권한 문제지 캐시 갱신과 무관. (B) 버전 관리는 객체 이력 보존 기능, 엣지 캐시 무효화와 별개. (C) CloudFront는 글로벌 엣지 서비스로 "AZ 위치"에 콘텐츠 업로드 개념 자체가 잘못됨. 【시험 포인트】 "CloudFront 업데이트 후 옛 콘텐츠" → invalidation(또는 버전 파일명).

해설

【핵심 용어】 ▸ Lambda VPC 구성 — RDS 등 VPC 사설 리소스 접근하려면 함수를 해당 VPC(서브넷)에 연결해야 함 ▸ 기본(default) 설정 Lambda — VPC 미연결 상태라 VPC 내부 사설 리소스에 도달 불가 ▸ ENI — VPC 연결 시 Lambda가 서브넷에 ENI 생성해 사설 통신 【정답 포인트】 ▸ IAM·라우팅 정상인데 연결 실패 → 기본 설정 Lambda가 RDS와 같은 VPC에 배포되지 않아 사설 서브넷 리소스에 접근 불가 ▸ Lambda를 대상 VPC/서브넷에 연결해야 함 【오답 체크】 (A) Lambda 구성에 "RDS를 대상으로 지정"하는 설정은 존재하지 않음. (C) VPC 피어링은 동일 VPC 시나리오에서 불필요, 지문은 단일 VPC 사설 서브넷. (D) SG 아웃바운드는 기본 전체 허용, 지문에서 SG는 원인으로 지목되지 않음(근본은 VPC 미연결). 【시험 포인트】 "Lambda가 VPC 사설 리소스 접근 불가" → 함수를 그 VPC에 연결했는지 먼저 확인.

해설

【핵심 용어】 ▸ 보조 IPv4 CIDR(secondary CIDR) — VPC에 추가 IP 주소 범위를 확장, 기본 CIDR 소진 시 사용 ▸ Subnet — 인스턴스는 서브넷의 프라이빗 IP를 할당받음, 새 CIDR엔 새 서브넷 필요 ▸ VPC/서브넷 CIDR 변경 불가 — 기존 CIDR 블록은 수정할 수 없음 【정답 포인트】 ▸ "사설 IPv4 고갈로 인스턴스 시작 불가" → (A) VPC에 보조 IPv4 CIDR 연결로 주소 공간 확장 ▸ (C) 확장된 CIDR 범위에 새 서브넷 생성 후 그 서브넷에서 인스턴스 시작 【오답 체크】 (B) IPv6 CIDR 추가는 IPv4 주소 부족 해결과 무관. (D) 기존 VPC의 CIDR 블록은 수정 불가. (E) 서브넷 CIDR도 수정 불가. 【시험 포인트】 "VPC IPv4 고갈" → 보조 IPv4 CIDR 추가 + 새 서브넷 생성.

해설

【핵심 용어】 ▸ EC2 Auto Scaling + ALB — 웹 계층 수평 확장·부하 분산·고가용성 제공 ▸ RDS for PostgreSQL Multi-AZ — 관리형 DB 이중화, 자동 장애 조치로 DB 계층 고가용성 ▸ Stateless 애플리케이션 — 웹 서버 수평 확장 적합, 상태를 인스턴스에 두지 않음 【정답 포인트】 ▸ "트래픽 증가 수용 + 고가용성" → (B) Auto Scaling 그룹 + ALB로 웹 계층 확장·이중화 ▸ (D) DB를 RDS PostgreSQL Multi-AZ로 이전해 DB 계층 관리형 고가용성 확보 ▸ 웹·DB를 단일 인스턴스에서 분리해 각각 확장·이중화 【오답 체크】 (A) CloudFront는 정적 캐싱 가속용, 동적 확장·고가용성 근본 해결책 아님. (C) 단일 인스턴스 업스케일(수직 확장)은 확장 한계·단일 장애점 유지. (E) PostgreSQL 버전 업그레이드는 성능·가용성 문제와 무관. 【시험 포인트】 "확장성+HA" → 웹은 ASG+ALB, DB는 RDS Multi-AZ로 분리.

해설

【핵심 용어】 ▸ ElastiCache (Redis OSS) Global Datastore — 리전 간 복제로 여러 리전에 동일 캐시 데이터 제공, 1차=읽기/쓰기, 2차=읽기 전용 ▸ 크로스 리전 일관성 — Global Datastore가 리전 간 데이터 복제로 일관된 캐시 제공 ▸ Memcached — 리전 간 복제/글로벌 데이터스토어 미지원 【정답 포인트】 ▸ "각 리전 캐시가 동일 데이터" + "3개 리전(1차 R/W, 2차 read-only)" → Redis OSS Global Datastore 구조와 정확히 일치 ▸ 1차 리전 R/W 클러스터 + 2차 리전 read-only 클러스터로 일관성 확보 【오답 체크】 (B) Memcached는 "global database"·리전 복제 기능이 없음(용어 자체가 허구). (C) PostgreSQL 쿼리 캐시 리전 복제는 존재하지 않는 기능. (D) Memcached는 cluster mode·크로스 리전 복제 미지원. 【시험 포인트】 "멀티 리전 일관 캐시" → ElastiCache for Redis Global Datastore. Memcached는 리전 복제 불가.

해설

【핵심 용어】 ▸ SSM Agent Auto update — Fleet Manager에서 토글 한 번으로 전체 관리 인스턴스의 SSM Agent 자동 최신화 ▸ Systems Manager Fleet Manager — 관리형 인스턴스 통합 관리 콘솔 ▸ 운영 효율 — 커스텀 Lambda/SNS 파이프라인 없이 내장 기능 사용 【정답 포인트】 ▸ "SSM Agent 항상 최신 유지" + "가장 운영 효율적" → Fleet Manager의 Auto update SSM Agent 설정 활성화 ▸ 추가 코드/구독 없이 관리형 자동 업데이트 【오답 체크】 (B),(D) GitHub 알림 구독 + SNS + Lambda 커스텀 파이프라인은 불필요한 개발·운영 오버헤드. (C) Auto update SSM Agent 설정은 Patch Manager가 아니라 Fleet Manager에 위치. 【시험 포인트】 "SSM Agent 자동 최신화" → Fleet Manager의 Auto update 설정.