정답 · 해설

해설

【핵심 용어】 ▸ 기본 모니터링: 5분 단위 메트릭 수집(해상도 낮음). ▸ 상세 모니터링: 1분 단위 메트릭 수집(고해상도). ▸ CloudWatch 알람: 메트릭 임계값 초과 시 작업 자동 실행. 【정답 포인트】 ▸ 정답: B - 상세 모니터링 + CloudWatch 알람. ▸ 요구사항: "2분 이상" 초과 탐지. ▸ 기본 모니터링(5분 단위)은 2분 조건 감지 불가능(너무 느림). ▸ 상세 모니터링(1분 단위)으로 2분 연속 초과 감지 가능. ▸ CloudWatch 알람의 "EvaluationPeriods" 설정: 2(2분 = 2×1분). ▸ 알람 작업: "ec2:Reboot" 또는 "autorecover" 인스턴스. 【오답 체크】 (A) 70~85자: 기본 모니터링은 5분 해상도로는 "2분" 조건 정확 감지 불가능. 지연 시간 문제 발생. (C) 75~90자: Lambda 예약 호출(2분마다)은 작동하나 비효율적. CloudWatch 이벤트 기반이 권장. (D) 80~95자: EC2 상태 확인은 인스턴스 물리적 상태만 감시. CPU 사용률 메트릭 모니터링과 무관. 【시험 포인트】 ▸ 기본 vs 상세 모니터링의 시간 해상도 차이 암기(5분 vs 1분). ▸ CloudWatch 알람 설정 시 메트릭 해상도와 평가 주기의 관계. ▸ 자동 복구 시나리오: CloudWatch 알람 + 작업 설정이 표준. ▸ Lambda 예약은 부분적 해결책이나 실시간성 떨어짐.

해설

【핵심 용어】 ▸ S3 Inventory: 정기적 객체 메타데이터 보고서(암호화 상태, 스토리지 클래스 등). ▸ 운영 효율성: 자동화, 확장성, 유지보수 용이. ▸ 수백만 객체 규모 대응. 【정답 포인트】 ▸ 정답: B - S3 Inventory 구성. ▸ S3 Inventory는 매일/매주 자동으로 객체 메타데이터 수집. ▸ 암호화 상태 필드("IsEncrypted", "SSEAlgorithm") 포함. ▸ CSV/Parquet 형식으로 S3에 저장 후 조회. ▸ 대규모 버킷(수백만 개 객체) 효율적 처리. ▸ "운영 효율적" = 반복 가능, 자동화, 확장 가능. ▸ 한 번 설정 후 계속 유지. 【오답 체크】 (A) 75~90자: 스크립트 방식은 매번 모든 객체 스캔(API 호출 과다). 대규모 버킷 시 시간/비용 증가. 재현성 낮음. (C) 70~85자: IAM 권한만으로는 자동 검증 불가능. 보안 팀이 직접 조회해야 함(비효율). (D) 75~90자: AWS CLI는 1회성 조회. 지속적인 모니터링 불가능. 매번 수동 실행 필요. 【시험 포인트】 ▸ S3 Inventory의 자동화 보고서 특성 숙지. ▸ 암호화 상태 필드 포함 설정. ▸ 운영 효율성 = 자동화, 확장성, 반복 가능성. ▸ 대규모 데이터셋 모니터링의 표준 솔루션.

해설

【핵심 용어】 ▸ gp2: 버스트 성능 기반, 크레딧 시스템(3IOPS/GB). ▸ gp3: 기본 성능 보장(3000 IOPS/125MB/s 기본), 버스트 불필요. ▸ 성능 변동성: gp2의 크레딧 고갈 시 성능 저하. 【정답 포인트】 ▸ 정답: A - gp3로 변환. ▸ 증상 분석: "느린 응답" 간헐적 발생, VolumeReadOps 급감. ▸ 원인: gp2의 버스트 크레딧 고갈. ▸ gp2 특성: 초기 빠름(크레딧 소비) → 크레딧 고갈 → 성능 저하 반복. ▸ gp3는 기본 IOPS 보장으로 일관성 유지. ▸ 350GB 정도면 gp3의 기본 3000 IOPS로도 충분할 가능성 높음. ▸ 버스트 불필요 = 일관된 성능. 【오답 체크】 (B) 70~85자: sc1은 콜드 HDD로 성능 극도로 낮음. 데이터베이스 워크로드에 부적합. 더 느려짐. (C) 75~90자: 인스턴스 타입 변경은 EBS 성능 문제와 무관. 메모리 증설이 읽기 성능 개선하려면 애플리케이션 캐싱 필요. (D) 70~85자: 무제한 모드는 CPU 크레딧 관련. 스토리지 I/O 성능과 무관. 【시험 포인트】 ▸ gp2의 버스트 크레딧 메커니즘과 한계 이해 필수. ▸ gp3의 보장된 기본 성능 개념. ▸ EBS 성능 문제 진단: VolumeReadOps/WriteOps 메트릭 해석. ▸ 버스트 기반 vs 기본 성능 보장의 차이점.

해설

【핵심 용어】 ▸ Compute Savings Plans: 계산 유형별 유연한 적용(EC2, Lambda, Fargate). ▸ EC2 Instance Savings Plans: 특정 인스턴스 유형/리전 고정. ▸ Reserved Instances: 가장 제한적(인스턴스 타입/리전/AZ). ▸ 유연성 vs 할인율 트레이드오프. 【정답 포인트】 ▸ 정답: A - Compute Savings Plans. ▸ 특성 분석: Lambda + EC2 혼합 사용, 리전별 불균등 분포. ▸ 요구사항: "리전/위치별 다른 양" = 리전 선택 유연성 필요. ▸ Compute Savings Plans: 계산량만 고정, 리전/인스턴스 타입 자유. ▸ Lambda와 EC2 모두 커버 가능(다른 상품은 EC2만). ▸ 예측 가능한 "전체" 사용량 기반으로 구매 가능. ▸ 30일 데이터는 기준선 수립용. 【오답 체크】 (B) 70~85자: Convertible RI는 인스턴스 타입 변경만 가능(리전 변경 안 됨). Lambda 미지원. (C) 75~90자: EC2 Instance Savings Plans는 특정 인스턴스 타입/리전 고정. Lambda 미지원, 리전 유연성 없음. (D) 80~95자: Standard RI는 가장 제한적(타입/리전/AZ 모두 고정). Convertible보다 유연성 떨어짐. 【시험 포인트】 ▸ 세 가지 계획 유형의 커버 범위와 유연성 비교. ▸ Compute Savings Plans의 최대 유연성(여러 제품/리전). ▸ 리전별 분산 워크로드 = Compute Savings Plans 선택 이유. ▸ 예측 가능한 사용량은 Savings Plans 기준(RI보다 우선).

해설

【핵심 용어】 ▸ ALB 상태 확인: HTTP/HTTPS 경로 기반, 포트 지정 가능. ▸ 사용자 지정: 특정 엔드포인트(/health, /status 등) 설정. ▸ 운영 효율성: 기본 제공 기능 활용. 【정답 포인트】 ▸ 정답: B - ALB 상태 확인 설정. ▸ ALB는 내장 상태 확인 기능 제공(HTTP 헬스 체크). ▸ Health Check Path: 애플리케이션의 사용자 지정 엔드포인트 지정. ▸ 예: /health 경로가 "200 OK" 반환 시 정상 판정. ▸ "사용자 지정" = 애플리케이션별 헬스 엔드포인트 정의. ▸ "운영 효율적" = ALB 기본 기능 사용(S3, ElastiCache 추가 인프라 불필요). ▸ 간단하고 비용 효율적. 【오답 체크】 (A) 75~90자: S3 상태 저장은 지연 발생(S3 쓰기 → ALB 읽기 대기). 실시간 헬스 체크 부적합. 복잡도 높음. (C) 80~95자: ElastiCache는 캐싱 서비스. 상태 관리와 무관. 오버엔지니어링. (D) 85~100자: API Gateway는 상태 확인 기능 아님. 추가 비용, 복잡도. ALB 기능으로 충분. 【시험 포인트】 ▸ ALB 기본 상태 확인 기능과 설정 방법 숙지. ▸ Health Check Path/Port 개념의 명확한 이해. ▸ 기본 제공 기능 vs 사용자 지정 구현 선택 기준. ▸ 운영 효율성 = 불필요한 추가 서비스 제외.

해설

【핵심 용어】 ▸ CloudWatch 에이전트: EC2 내부 게스트 메트릭 수집(디스크, 메모리, 프로세스). ▸ 기본 CloudWatch: EC2 호스트 메트릭만(CPU, 네트워크). ▸ 게스트 메트릭: OS 수준 정보 필수(에이전트 필요). 【정답 포인트】 ▸ 정답: C - CloudWatch 에이전트 + SNS 알람. ▸ 문제 분석: Windows EC2 디스크 여유 공간 모니터링. ▸ 기본 CloudWatch는 호스트 메트릭만 제공(디스크 사용량 없음). ▸ 디스크 사용량은 OS 수준 정보 = CloudWatch 에이전트 필수. ▸ 에이전트 설치 → "DiskUsagePercent" 메트릭 수집 → CloudWatch 알람 설정. ▸ SNS를 통해 이메일 알림 구성. ▸ 자동화된 선제적 모니터링. 【오답 체크】 (A) 75~90자: 기본 CloudWatch는 디스크 용량 메트릭 제공 안 함. EC2 호스트 수준만 모니터링 가능. (B) 80~95자: CloudTrail은 API 호출 로그. 디스크 사용량 정보 없음. 규정 감사용이지 성능 모니터링 아님. (D) 85~100자: Trusted Advisor는 비용, 보안, 성능 최적화 권장사항만 제공. 실시간 모니터링/알람 기능 없음. 【시험 포인트】 ▸ CloudWatch 에이전트의 필수성과 게스트 메트릭 개념. ▸ OS 수준 메트릭(디스크, 메모리) = 에이전트 필수. ▸ 에이전트 설정, 로그 그룹, 메트릭 확인 프로세스. ▸ SNS를 통한 알림 자동화. ▸ Windows EC2 모니터링의 표준 방식.

해설

【핵심 용어】 ▸ 비용 할당 태그: Cost Explorer에서 필터/그룹화용 태그 활성화. ▸ 태그 생성 vs 활성화: 생성만으로는 Cost Explorer에 표시 안 됨. ▸ 24시간 지연: 활성화 후 최대 24시간 내 반영. 【정답 포인트】 ▸ 정답: B - 비용 할당 태그 활성화 필요. ▸ 핵심: 태그 생성(적용) ≠ 비용 할당 태그 활성화. ▸ 프로세스: Resource Tagging API로 태그 적용 → Billing 콘솔에서 "User-Defined" 태그 활성화 → 최대 24시간 후 Cost Explorer에 표시. ▸ 20일은 충분하지만 활성화 단계 누락이 원인. ▸ "비용 할당"이라는 별도의 활성화 단계 필수. 【오답 체크】 (A) 70~85자: 30일은 아님. 활성화 후 최대 24시간 내 반영 가능. 20일은 충분히 지남. (C) 80~90자: Cost and Usage Report는 Cost Explorer와 별개 서비스. Cost Explorer 필터 기능과 무관. (D) 85~95자: AWS Budgets는 예산 알램 기능. 태그 필터링 기능과 무관. 【시험 포인트】 ▸ 태그 생성 vs 비용 할당 태그 활성화의 구분. ▸ Billing 콘솔에서의 태그 활성화 절차. ▸ Cost Explorer에서 태그를 필터로 사용하기 위한 필수 조건. ▸ 시간 기반이 아닌 "활성화" 단계가 핵심.

해설

【핵심 용어】 ▸ CloudWatch Logs Insights: 로그 실시간 쿼리 분석 언어(통계, 필터링, 집계). ▸ stats 명령: 메트릭 통계(count, sum, avg 등). ▸ 여러 로그 그룹: Insights는 다중 그룹 동시 조회 지원. 【정답 포인트】 ▸ 정답: A - CloudWatch Logs Insights의 stats 명령. ▸ 요구사항: "오류 수 유형별 그룹화". ▸ CloudWatch Logs Insights 쿼리 예시: "filter ispresent(error) | stats count() by error_type". ▸ Insights는 CloudWatch Logs에서 직접 실시간 분석. ▸ 여러 로그 그룹을 동시 조회 가능(Insights는 다중 그룹 지원). ▸ "stats count() by" = GROUP BY와 동일한 집계 기능. ▸ 매일 1GB 정도는 Insights로도 빠르게 처리 가능. 【오답 체크】 (B) 75~90자: CloudWatch Logs 검색은 "groupby" 키워드 미지원. Logs Insights와 혼동. 기본 검색은 필터링만 가능. (C) 85~100자: Athena는 S3에 저장된 로그 분석. CloudWatch Logs에는 직접 쿼리 불가능. 추가 설정 필요. (D) 80~95자: RDS는 데이터베이스. CloudWatch Logs 데이터 저장 안 함. 완전히 부적합. 【시험 포인트】 ▸ CloudWatch Logs Insights의 stats 명령과 집계 함수 숙지. ▸ Logs Insights는 CloudWatch 로그에서 실시간 분석. ▸ 다중 로그 그룹 쿼리 기능. ▸ "stats count() by" = SQL의 "GROUP BY COUNT()"와 동일. ▸ 성능과 용도에 따른 도구 선택(Athena vs Insights).

해설

【핵심 용어】 ▸ AWS Compute Optimizer: EC2, Lambda, EBS 등 리소스 최적화 권장(기계 학습 기반). ▸ 권장사항: 비용 절감, 성능 개선 기반. ▸ 다중 계정: Organizations와 통합 가능. 【정답 포인트】 ▸ 정답: B - AWS Compute Optimizer. ▸ Compute Optimizer: Lambda 함수 분석 → vCPU/메모리 최적 구성 제안. ▸ 권장사항 내용: 현재 구성 vs 권장 구성, 비용 절감율, 성능 개선 예측. ▸ 다중 계정 지원: Organizations에 등록되면 모든 멤버 계정 분석 가능. ▸ 자동 권장사항 생성, 내보내기(JSON/CSV) 가능. ▸ Lambda 최적화의 표준 도구. 【오답 체크】 (A) 80~95자: Serverless Application Repository는 샘플 앱 공유 플랫폼. 리소스 최적화 권장사항 기능 없음. (C) 85~100자: CloudTrail Insights는 API 이상 탐지. Lambda 리소스 최적화 권장사항 기능 없음. Organizations 기능은 관리와 무관. (D) 80~90자: Trusted Advisor는 보안, 비용 최적화 일반 체크. Lambda 리소스 구성 최적화 전문 권장 안 함. 【시험 포인트】 ▸ AWS Compute Optimizer의 기능과 지원 리소스 이해. ▸ Lambda 권장사항(vCPU/메모리 최적화) 생성 메커니즘. ▸ Organizations 통합으로 다중 계정 관리. ▸ 기타 도구(Trusted Advisor, CloudTrail Insights)와의 구분. ▸ 최적화 기반(비용, 성능)의 명확성.

해설

【핵심 용어】 ▸ 중첩 스택(Nested Stack): 상위 템플릿에서 하위 템플릿 호출(재사용 및 모듈화). ▸ 스택 세트(Stack Set): 여러 계정/리전에 동일 스택 배포. ▸ 매크로(Macro): 템플릿 처리 중 동적 변환(Python/Lambda). ▸ 변경 집합(Change Set): 스택 업데이트 미리보기. 【정답 포인트】 ▸ 정답: C - CloudFormation 중첩 스택. ▸ 문제 분석: "여러 템플릿에서 동일 구성 요소 반복". ▸ 솔루션: 공통 구성 요소 → 별도 템플릿으로 분리 → 중첩 스택으로 호출. ▸ 중첩 스택의 역할: ① 재사용성, ② 모듈화, ③ 자신의 매개변수/조건 정의 가능. ▸ 상위 템플릿 → AWS::CloudFormation::Stack 리소스로 하위 템플릿 참조. ▸ 복잡한 인프라를 계층적으로 관리. 【오답 체크】 (A) 70~85자: 변경 집합은 스택 수정 시 미리보기 도구. 코드 재사용과 무관. (B) 75~90자: 매크로는 템플릿 처리 중 동적 변환. 재사용보다는 사용자 지정 함수 추가용. 복잡도 높음. (D) 80~95자: 스택 세트는 여러 계정/리전 동시 배포. 단일 계정 내 코드 재사용과 무관. 【시험 포인트】 ▸ 중첩 스택의 목적: 재사용성, 모듈화, 복잡 인프라 관리. ▸ 상위/하위 템플릿의 구조와 매개변수 전달. ▸ 스택 세트와의 구분(계정/리전 다중 배포 아님). ▸ CloudFormation 설계 패턴: 공통 구성 요소 = 중첩 스택.

해설

【핵심 용어】 ▸ KMS 키 정책: 암호화 키에 대한 계정/사용자 권한 제어. ▸ 크로스 계정 공유: KMS 키 정책 수정으로 다른 계정 액세스 허용. ▸ RDS 스냅샷 공유: 키 정책 설정 후 스냅샷 공유. 【정답 포인트】 ▸ 정답: B - KMS 키 정책 업데이트 + 스냅샷 공유. ▸ KMS 기반 암호화 스냅샷 공유 단계: ① 스냅샷 암호화 KMS 키의 정책 수정. ② 다른 계정의 principal(ARN) 추가. ③ 스냅샷을 해당 계정과 공유. ④ 수신 계정은 KMS 권한 있으므로 스냅샷 사용 가능. ▸ 가장 간단하고 안전한 방식. ▸ 복호화 불필요, 권한만 관리. 【오답 체크】 (A) 75~90자: 스냅샷 다운로드 후 복호화는 매우 비효율적. 데이터 노출 위험 증가. 보안 모범 사례 위반. (C) 85~100자: 암호화 해제하여 공유는 요구사항(암호화 유지) 위반. 추가 EC2 인스턴스 생성 비용. (D) 90~110자: 암호화되지 않은 인스턴스 생성은 데이터 노출 위험. "저장 중 암호화" 요구사항 미충족. 극도로 비안전. 【시험 포인트】 ▸ KMS 키 정책을 통한 크로스 계정 권한 관리. ▸ 암호화된 RDS 스냅샷 공유의 표준 방식. ▸ 암호화 키 보유 계정에서 키 정책 수정이 필수 단계. ▸ 스냅샷 자체는 정책에서 관리할 필요 없음(키 정책이 핵심). ▸ 보안과 운영 효율성 동시 달성.

해설

【핵심 용어】 ▸ S3 게이트웨이 엔드포인트: VPC 내에서 인터넷 통과 없이 S3 액세스. ▸ 엔드포인트 라우트: 라우트 테이블에 S3 프리픽스 목록 추가 필수. ▸ 프리픽스 목록: AWS가 유지하는 S3 IP 주소 범위. 【정답 포인트】 ▸ 정답: C - 라우트 테이블에 S3 프리픽스 목록 경로 추가. ▸ 문제 분석: 게이트웨이 엔드포인트 설정됨, 하지만 업로드 실패. ▸ 원인: 라우트 테이블에 엔드포인트 경로 없음. ▸ 해결: EC2 서브넷의 라우트 테이블 수정 → "Destination: pl-xxxxxxxx (S3)", "Target: vpce-xxxxxxxx (엔드포인트)" 추가. ▸ 이러로 인해 S3 트래픽이 엔드포인트를 통해 라우팅됨. ▸ IAM/보안 그룹은 정상이라고 가정(일반적 케이스). 【오답 체크】 (A) 70~85자: IAM 정책이 문제면 "Access Denied" 에러. 현 시나리오는 "연결 불가능" 유형으로 추론. 라우트 문제가 먼저. (B) 75~90자: 포트 80 아웃바운드는 인터넷 게이트웨이 경로 추가하는 것. 게이트웨이 엔드포인트와 모순. "아웃바운드 인터넷 액세스 없음"이 요구사항. (D) 80~95자: 버킷 정책은 이미 S3 버킷 액세스 권한 있다고 가정. 라우팅이 더 기본적인 문제. 【시험 포인트】 ▸ S3 게이트웨이 엔드포인트 설정의 필수 요소: ① 엔드포인트 생성, ② 라우트 테이블 경로 추가. ▸ 프리픽스 목록(pl-xxxxx)의 개념과 S3 매핑. ▸ 엔드포인트 정책 vs 라우트 테이블: 라우트 테이블이 실제 트래픽 경로 결정. ▸ 네트워크 계층(라우팅)이 애플리케이션 계층보다 선행.

해설

【핵심 용어】 ▸ S3 Transfer Acceleration: CloudFront 엣지 로케이션 활용, 높은 대역폭 최적화. ▸ 멀티파트 업로드: 대형 파일을 병렬 청크로 업로드, 재시도 효율성 증대. ▸ 비용 효율성: Direct Connect/VPN은 월정액, Transfer Acceleration은 가변 비용. 【정답 포인트】 ▸ 정답: C, E. ▸ C - S3 Transfer Acceleration: CloudFront 글로벌 네트워크 활용, 지연 단축. ▸ 가장 저비용(추가 인프라 불필요). ▸ E - 멀티파트 업로드: 대형 파일(비디오)을 병렬로 업로드. ▸ 각 파트는 독립적 재시도, 대역폭 효율적. ▸ 두 기법 결합 시 최대 성능 개선. ▸ "가장 비용 효율적" = 인프라 추가 비용 최소화. 【오답 체크】 (A) 85~105자: Direct Connect는 월정액 수만 달러. 초기 설치 비용 매우 높음. 소규모 영상 팀에는 오버엔지니어링. (B) 80~100자: Site-to-Site VPN도 지속 비용 발생. 또한 인터넷 기반이므로 Direct Connect보다 성능 낮음. (D) 80~95자: AWS Global Accelerator는 엔터프라이즈급 서비스로 월정액 매우 높음. Transfer Acceleration이 더 경제적. 【시험 포인트】 ▸ S3 Transfer Acceleration의 GlobalAccelerator(CloudFront) 활용. ▸ 멀티파트 업로드의 병렬성과 재시도 효율성. ▸ 비용 기반 선택: Direct Connect/VPN(월정액, 고비용) vs Transfer Acceleration(가변, 저비용). ▸ 대역폭 최적화: 두 기법의 상보적 역할. ▸ \"비용 효율적" 선택 문제의 핵심은 인프라 추가 비용 회피.

해설

【핵심 용어】 ▸ Secrets Manager: 자동 암호 생성 및 회전 지원 ▸ GenerateSecretString: 강력한 암호 자동 생성 ▸ RotationSchedule: 정기적 회전 자동화 【정답 포인트】 ▸ A가 정답입니다. Secrets Manager는 GenerateSecretString으로 자동 암호 생성, RotationSchedule로 정기적 회전 스케줄 정의, 애플리케이션의 동적 검색을 모두 지원하는 완벽한 솔루션입니다. 90일 회전 요구사항을 자동으로 충족합니다. 【오답 체크】 (B) SecretString은 수동 암호 입력이 필요하며 자동 생성 기능이 없습니다. CloudFormation 파라미터는 일반 텍스트로 노출될 수 있는 보안 위험이 있습니다. 60~100자 (C) Parameter Store의 보안 문자열은 회전 기능이 없어 90일마다 수동으로 변경해야 합니다. 자동 회전 요구사항을 충족하지 않습니다. 70~90자 (D) Parameter Store 일반 문자열은 암호화되지 않아 가장 위험합니다. 회전 기능도 없으므로 요구사항을 전혀 충족하지 않습니다. 60~80자 【시험 포인트】 ▸ 암호 관리 요구사항 분석 시 자동 생성, 자동 회전, 애플리케이션 통합을 모두 검토 ▸ Secrets Manager는 회전 스케줄 자동화 기능, Parameter Store는 그렇지 않음 ▸ CloudFormation 파라미터에 암호 저장은 감사 추적(audit trail) 및 보안상 권장되지 않음

해설

【핵심 용어】 ▸ Flow Logs: 네트워크 트래픽 거부 원인 추적 ▸ Ephemeral Ports: 반환 트래픽용 임시 포트(1024-65535) ▸ Network ACL: 상태 비저장(stateless) 필터링 【정답 포인트】 ▸ D가 정답입니다. 온프레미스에서 EC2로 인바운드 트래픽이 허용되어도, EC2의 반환 트래픽(REPLY)이 임시 포트로 나가갈 때 Network ACL의 아웃바운드 규칙이 이를 차단합니다. Network ACL은 상태 비저장이므로 양방향 규칙 설정 필요합니다. 【오답 체크】 (A) EC2 보안 그룹은 상태 저장(stateful)이므로 인바운드를 허용하면 자동으로 반환 트래픽을 허용합니다. 이것이 원인이 아닙니다. 65~80자 (B) NLB는 동일 서브넷이며, 문제는 온프레미스↔EC2 직접 통신입니다. NLB 보안 그룹은 영향을 주지 않습니다. 70~85자 (C) 온프레미스 ACL은 AWS 관리 대상이 아니며, 문제의 범위를 벗어납니다. AWS 측 네트워크 ACL만 통제 가능합니다. 75~90자 【시험 포인트】 ▸ Network ACL vs Security Group 차이: ACL은 상태 비저장, SG는 상태 저장 ▸ 플로우 로그의 REJECT 이유 분석 필수 ▸ 반환 트래픽(ephemeral port) 아웃바운드 규칙은 모든 프로토콜에 필수

해설

【핵심 용어】 ▸ RDS Proxy: 데이터베이스 연결 풀 관리로 장애 조치 시간 단축 ▸ Multi-AZ Failover: 수동(manual) vs 자동(automatic) 장애 조치 ▸ Connection Pool: 기존 연결 재사용으로 RTO 개선 【정답 포인트】 ▸ D가 정답입니다. RDS Proxy는 애플리케이션 연결을 풀링하므로, Multi-AZ 장애 조치 시 애플리케이션이 새 데이터베이스 엔드포인트를 재발견하는 시간이 없어집니다. 프록시가 자동으로 새 인스턴스로 연결을 리라우팅하여 RTO를 10% 이상 단축합니다. 【오답 체크】 (A) 인스턴스 크기 증가는 장애 조치 시간과 무관합니다. Multi-AZ 장애 조치 메커니즘에 영향을 주지 않습니다. 60~75자 (B) 단일 AZ는 고가용성을 제거하여 요구사항에 위배됩니다. 장애 조치가 아예 불가능해집니다. 55~70자 (C) 다른 리전의 읽기 전용 복제본은 RPO/RTO가 훨씬 길어집니다. 빠른 장애 조치에는 부적절합니다. 70~85자 【시험 포인트】 ▸ RDS Proxy는 연결 풀링으로 장애 조치 RTO 개선 ▸ Multi-AZ는 동일 리전 자동 장애 조치, 읽기 복제본(read replica)은 수동 프로모션 ▸ 애플리케이션 재부팅 없이 장애 조치 시간 단축 방법은 프록시/미들웨어 활용

해설

【핵심 용어】 ▸ Route 53 Resolver Outbound Endpoint: VPC→온프레미스 DNS 쿼리 전달 ▸ Forwarding Rule: 특정 도메인의 쿼리를 지정된 DNS로 라우팅 ▸ VPC Association: 전달 규칙이 적용될 VPC 범위 지정 【정답 포인트】 ▸ D가 정답입니다. EC2 인스턴스(VPC 내부)에서 온프레미스 DNS 서버로 쿼리를 보내야 하므로, 아웃바운드 엔드포인트가 필요합니다. 아웃바운드 엔드포인트에서 example.com에 대한 전달 규칙을 정의하고, VPC와 연결하여 모든 EC2의 쿼리를 온프레미스로 전달합니다. 【오답 체크】 (A) 인바운드 엔드포인트는 온프레미스→VPC 방향입니다. EC2에서 온프레미스로 보내야 하므로 역방향이며 틀렸습니다. 75~90자 (B) 인바운드 엔드포인트를 사용했으므로 방향이 반대입니다. EC2가 인바운드 엔드포인트의 주소를 알 수 없습니다. 70~85자 (C) 아웃바운드 엔드포인트는 맞으나, 온프레미스에서 조건부 전달 규칙을 만드는 것은 틀렸습니다. Route 53 Resolver의 전달 규칙을 VPC에 설정해야 합니다. 80~95자 【시험 포인트】 ▸ Route 53 Resolver Inbound(온프레미스→VPC) vs Outbound(VPC→온프레미스) 방향 구분 필수 ▸ 전달 규칙은 Route 53 Resolver에서 정의하되, VPC와 연결하여 범위 설정 ▸ Site-to-Site VPN 연결된 환경에서 하이브리드 DNS 구성 패턴

해설

【핵심 용어】 ▸ Read Replica: 읽기 전용 복제본으로 읽기 부하 분산 ▸ ElastiCache: 인메모리 캐시로 데이터베이스 읽기 요청 감소 ▸ Write Scaling: RDS는 쓰기 확장 불가, 읽기만 복제 가능 【정답 포인트】 ▸ A, B가 정답입니다. 읽기 트래픽 과부하 문제이므로: (A) 읽기 전용 복제본은 읽기 작업을 분산하여 기본 인스턴스 부하 감소. (B) ElastiCache는 자주 읽는 데이터를 캐싱하여 데이터베이스 읽기 요청 자체를 줄입니다. 둘 다 읽기 성능 개선의 표준 패턴입니다. 【오답 체크】 (C) DynamoDB 마이그레이션은 스키마 변경이 필요하며, 읽기만 많은 경우 과도한 조치입니다. 기존 SQL 쿼리와 호환되지 않습니다. 75~90자 (D) EC2 자체 관리는 RDS의 관리형 이점을 포기합니다. 읽기 부하 문제 해결 메커니즘이 아닙니다. 70~85자 (E) Multi-AZ는 고가용성(HA) 목적이며, 읽기 성능 개선과 무관합니다. 읽기 전용 복제본과 혼동하면 안 됩니다. 60~75자 【시험 포인트】 ▸ RDS 읽기 부하 대응: Read Replica + 캐싱 조합이 표준 ▸ Multi-AZ는 HA, Read Replica는 성능, Aurora Global은 재해복구 목적 ▸ ElastiCache 추가로 데이터베이스 읽기 요청 수 자체 감축

해설

【핵심 용어】 ▸ Customer Managed KMS Key: 크로스 계정 공유에 필요한 정책 제어 ▸ AMI Copy: 암호화 키 변경 및 권한 재설정 필수 ▸ kms:ReEncrypt*: 새 계정의 KMS 키로 재암호화 권한 【정답 포인트】 ▸ B가 정답입니다. AWS 관리형 키는 계정 간 공유 불가이므로 고객 관리형 키 필수. AMI 사본 생성 시 대상 계정의 KMS 키로 재암호화되며, 이를 위해 kms:ReEncrypt* 권한 필요. 복사된 AMI에만 특정 계정 권한 설정하여 보안 유지. 원본 AMI는 AWS 관리형 키로 암호화되어도, 공유할 AMI는 고객 관리형 키로 재암호화됩니다. 【오답 체크】 (A) 원본 AMI가 AWS 관리형 키로 암호화되어 있으므로, 키 정책만 수정해서는 공유 불가. 다른 계정은 AWS 관리형 키에 접근할 수 없습니다. 80~95자 (C) 공개(public)로 설정하면 승인되지 않은 계정도 접근 가능하여 보안 요구사항 위배. 특정 계정만 허용해야 합니다. 75~90자 (D) AWS 관리형 키는 키 정책 수정이 불가능합니다(AWS 관리). 크로스 계정 공유를 지원하지 않으므로 시스템 구조상 불가능합니다. 85~100자 【시험 포인트】 ▸ AWS 관리형 vs 고객 관리형 KMS 키: 크로스 계정은 고객 관리형만 가능 ▸ AMI 공유 시 암호화 키 재설정 필수(kms:ReEncrypt*) ▸ EBS 암호화 AMI 크로스 계정 공유 = 사본 생성 + 키 정책 + AMI 권한 3단계

해설

【핵심 용어】 ▸ FSx for Windows: SMB 프로토콜 네이티브 지원, Windows ACL 호환 ▸ Multi-AZ: 가용성 영역 장애 및 유지 관리 자동 처리 ▸ Managed Service: AWS 관리형으로 운영 부담 최소 【정답 포인트】 ▸ B가 정답입니다. FSx for Windows File Server는 SMB 프로토콜 네이티브 지원, Windows ACL 완벽 호환, Multi-AZ로 자동 장애 조치 제공. 가용성 영역 장애나 유지 관리 시에도 투명하게 장애 조치되어 모든 요구사항 충족. AWS 완전 관리형이므로 운영 오버헤드 최소입니다. 【오답 체크】 (A) 단일 Storage Gateway는 단일 AZ에만 배포되어 장애 시 데이터 접근 불가. 고가용성 요구사항 미충족입니다. 75~90자 (C) Storage Gateway + ALB 구성은 복잡하고, ACL 문제 발생 가능. Storage Gateway는 파일 시스템이 아닌 게이트웨이일 뿐입니다. 80~95자 (D) DFSR(분산 파일 시스템 복제)은 RTO/RPO가 길고, 사용자가 직접 구성/관리 필요. 관리 복잡도 높음. 자동 장애 조치가 아닙니다. 85~100자 【시험 포인트】 ▸ FSx for Windows = Windows File Server 관리형 대체, SMB + Windows ACL 네이티브 지원 ▸ Multi-AZ = 자동 장애 조치, 투명한 가용성 ▸ Storage Gateway는 온프레미스↔AWS 계층화, 파일 공유는 아님