정답 · 해설

해설

【핵심 용어】 ▸ Shield Advanced — DDoS 공격 감지/완화, DRT(전문팀) 지원, 상세 감사 로그 ▸ WAF — 애플리케이션 계층 공격(SQL 인젝션, XSS) 방어, DDoS 완화 불충분 ▸ Inspector — 취약점 스캔, DDoS 방어 역할 아님 【정답 포인트】 ▸ "DDoS 공격" 명시 → Shield Advanced (DDoS 전문) ▸ "구성 변경 최소화" → Shield 자동 활성화 (CloudFront 추가 불필요) ▸ "감사 추적" → Shield Advanced 로깅 + DRT 분석 【오답 체크】 (A) WAF는 애플리케이션 수준 공격(L7) 방어, 용량 기반 DDoS(L3/L4) 완화 불가 (B) Inspector는 인스턴스 취약점 평가용, DDoS 방어 관계 없음 (D) CloudFront는 성능 개선, DDoS 보호 기능 약함. Shield Advanced가 더 적절 【시험 포인트】 ▸ DDoS 조합: Shield Standard (무료, 기본) + Shield Advanced (고급, DRT) ▸ "구성 변경 최소화" = 기존 ALB 유지, Shield 추가만 ▸ 함정: WAF는 DDoS가 아닌 다른 공격(SQL인젝션), CloudFront 과다

해설

【핵심 용어】 ▸ EFS (Elastic File System) — NFS 기반, 다중 AZ 자동 지원, 여러 인스턴스 동시 마운트 ▸ EBS (Elastic Block Store) — 블록 스토리지, 단일 AZ, 일반적으로 한 인스턴스만 연결 ▸ EBS 다중 연결 — 제한적 지원, 추가 배포 필요 【정답 포인트】 ▸ "여러 컨테이너 간 공유" + "높은 가용성" → EFS (NFS) ▸ EFS = 자동 다중 AZ 복제, 별도 설정 불필요 ▸ 운영 오버헤드 최소 = 관리형 서비스(EFS), 수동 동기화 불필요 【오답 체크】 (A) EBS 다중 연결은 제한적(io1/io2만), AZ 내 공유만, 높은 가용성 미충족 (C) EBS 단일 볼륨은 한 인스턴스만 마운트 가능 (다중 컨테이너 불가) (D) EFS는 이미 다중 AZ, Lambda 동기화는 불필요 복잡성 추가 【시험 포인트】 ▸ "여러 컨테이너 공유" = 네트워크 파일 시스템 필요 (EFS) ▸ 공유 스토리지 선택: EFS (높은 가용성) vs EBS (단일 AZ) ▸ 함정: EBS 다중 연결, Lambda 동기화는 과복잡

해설

【핵심 용어】 ▸ RDS Proxy — 연결 풀링, 과다 연결 방지, 성능 예측 가능화 ▸ RDS 사용자 지정 엔드포인트 — 특정 인스턴스 부분집합 쿼리, 연결 풀링 아님 ▸ Lambda VPC 배포 — RDS 프라이빗 접근 필수 (네트워크 격리) 【정답 포인트】 ▸ "예측할 수 없는 트래픽" + "과부하 방지" → RDS Proxy (연결 풀링) ▸ "프라이빗 RDS" → Lambda VPC 내 배포 (프라이빗 네트워크 접근) ▸ RDS Proxy = 매우 많은 짧은 연결 → 제한된 DB 연결 집약화 【오답 체크】 (A) 사용자 지정 끝점은 연결 풀링 기능 없음, 급증 트래픽 미방지 (C) Lambda VPC 외부 배포는 RDS 프라이빗 접근 불가 (D) Proxy는 맞으나 Lambda VPC 외부 = 프라이빗 RDS 접근 불가 【시험 포인트】 ▸ 급변 트래픽 + DB 성능 → RDS Proxy (연결 관리) ▸ 프라이빗 리소스 → Lambda VPC 내부 배포 필수 ▸ 함정: 사용자 지정 끝점과 Proxy 혼동, Lambda 배치 위치

해설

【핵심 용어】 ▸ Kinesis Data Stream → Firehose — 스트림 수집 → S3 자동 배치 저장 ▸ DMS — 데이터베이스 마이그레이션 (지속적 리플리케이션), 일반 "실시간" 수집 아님 ▸ DataSync — 파일 시스템 동기화, 실시간 이벤트 스트림 아님 【정답 포인트】 ▸ "실시간 데이터 수집" + "S3 배치" → Kinesis 스트림 (정보 입수) ▸ Firehose = 자동 배치 및 S3 저장 (관리형) ▸ 타사 애플리케이션 → Kinesis API (PUT 가능) ▸ 최소 관리 오버헤드 【오답 체크】 (B) DMS는 데이터베이스 마이그레이션(스키마 포함), 일반 데이터 수집용 아님 (C) DataSync는 파일/디렉토리 동기화, 실시간 이벤트 스트림 미지원 (D) Direct Connect는 고정 네트워크 연결, "실시간" 수집을 위한 과다 설정 【시험 포인트】 ▸ 실시간 스트림 수집 → Kinesis (스트림/Firehose) ▸ 스트림 → 배치 저장 → Kinesis Firehose (자동) ▸ 함정: DMS는 DB 마이그레이션, DataSync는 파일 동기화

해설

【핵심 용어】 ▸ RDS 복제 지연 — 주로 복제본 처리 병목, 쓰기 부하 누적 ▸ EC2 self-managed MySQL — 하드웨어 확장 자유도, 복제 제어 가능 ▸ Aurora — 관리형, 지연 최소화, 코드 변경 최소 【정답 포인트】 ▸ "복제 지연 최소화" + "코드 변경 최소" → EC2 MySQL (대규모 복제본) ▸ "저장 프로시저 유지" → 기존 MySQL 호환성 필요 ▸ 컴퓨팅 최적화 인스턴스 = 고처리량 복제 성능 ▸ 코드 변경 최소 (캐싱/Lambda 추가 없음) 【오답 체크】 (B) ElastiCache는 읽기 캐싱 (복제 지연 근본 해결 아님), 코드 변경 필요 (C) C는 정답과 동일하나 "대규모"라는 구체성 부족 (D) DynamoDB는 저장 프로시저 미지원, 마이그레이션 비용 높음 【시험 포인트】 ▸ 복제 지연 → 하드웨어 확장 (EC2 대규모) 또는 아키텍처 개선 ▸ "코드 변경 최소" = 기존 MySQL 호환성 필요 ▸ 함정: Aurora는 더 나으나 선택지에 없음, ElastiCache는 부분 해결

해설

【핵심 용어】 ▸ MSK (Amazon Managed Streaming for Apache Kafka) — 완전 관리형 Kafka, 인터넷 접근 설정 가능 ▸ 상호 TLS (mTLS) — 양방향 암호화 인증 (Kafka 클라이언트 ↔ 브로커) ▸ 퍼블릭 액세스 — MSK 클러스터를 인터넷 노출 (IAM 정책 + mTLS) 【정답 포인트】 ▸ "인터넷을 통해 공개적" → 퍼블릭 서브넷 배포 ▸ "전송 중 암호화" → mTLS 활성화 ▸ "운영 효율성" = 기존 VPC 재사용 (새 VPC 불필요) ▸ MSK는 자동 Kafka 관리, 로드 밸런서 추가 불필요 【오답 체크】 (B) 새 VPC 생성은 운영 복잡성 증가, 기존 리소스 통합 필요 (C) ALB는 HTTP 애플리케이션 계층, Kafka 바이너리 프로토콜 미지원 (D) NLB는 Kafka를 감싸기 위한 불필요 계층, MSK 자체 인터넷 설정 가능 【시험 포인트】 ▸ MSK 퍼블릭 액세스 = 퍼블릭 서브넷 + mTLS (로드 밸런서 불필요) ▸ "운영 효율성" = 최소 인프라 추가 ▸ 함정: ALB/NLB로 감싸는 것은 과복잡, MSK 자체 기능 활용

해설

【핵심 용어】 ▸ EFS (Elastic File System) — NFS 기반, 다중 AZ 지원, 여러 EC2 마운트 가능 ▸ EBS 스냅샷 — 블록 스토리지 백업, 복제본은 단일 AZ (다중 AZ 미지원) ▸ 인스턴스 스토어 — 임시 저장소, 인스턴스 중단 시 데이터 손실 【정답 포인트】 ▸ "여러 EC2 인스턴스에서 접근" + "여러 AZ" → EFS (NFS, 자동 다중 AZ) ▸ "파일 전송 불필요" → 공유 파일 시스템 (네트워크 마운트) ▸ 가용성 문제 해결 = 파일 공유 + 중복 【오답 체크】 (A) S3은 저장소 (EBS 대체), 고성능 파일 시스템 아님 (메타데이터 수정 필요) (B) EBS 복제본은 단일 AZ, "여러 AZ" 미지원, 수동 동기화 필요 (D) 인스턴스 스토어는 임시, 인스턴스 재부팅 시 데이터 손실 【시험 포인트】 ▸ "여러 EC2 + 여러 AZ" → EFS (자동 다중 AZ NFS) ▸ "파일 공유" vs "블록 스토리지": EFS (NFS) vs EBS (블록) ▸ 함정: EBS 복제는 단일 AZ, 인스턴스 스토어는 임시 저장소

해설

【핵심 용어】 ▸ AWS Outposts — 온프레미스에 AWS 하드웨어/소프트웨어 배포 ▸ 책임 분담 모델 — AWS (하드웨어/OS 관리) vs 고객 (물리적 환경, 보안) ▸ 운영팀 역할 — 데이터 센터 인프라 유지 (전력, 냉각, 보안) 【정답 포인트】 ▸ (A) 전원·네트워크 — 고객 책임 (데이터 센터 조건) ▸ (C) 물리적 보안·접근 제어 — 고객 책임 (보안 정책) ▸ (B) 하이퍼바이저·AWS 서비스 = AWS 책임 (Outposts 배포 후 관리) ▸ (D) 하드웨어 가용성 = AWS 책임 (장비 제공, 패치) ▸ (E) 물리적 유지관리 = AWS 책임 (배송, 설치, RMA) 【오답 체크】 (B) AWS가 하이퍼바이저/서비스 관리 (고객 책임 아님) (D) Outposts 랙 가용성 = AWS 책임 (SLA, 장비 교체) (E) 물리적 수리 = AWS 필드 엔지니어 역할 (F) 클러스터 용량 계획 = 애플리케이션 설계자 (운영팀만 아님) 【시험 포인트】 ▸ Outposts 책임: 고객 (물리 환경) vs AWS (소프트웨어 스택) ▸ "운영팀" = 데이터 센터 관리 (전력, 보안, 물리 공간) ▸ 함정: AWS 책임을 고객으로 오도, 애플리케이션 설계는 운영팀 외

해설

【핵심 용어】 ▸ Auto Scaling Group — 여러 AZ에 걸쳐 EC2 인스턴스 수를 자동으로 관리하는 서비스 ▸ Route 53 — DNS 기반 트래픽 라우팅으로 고가용성을 제공하는 서비스 【정답 포인트】 ▸ OSI 전송계층(TCP) — 단순 트래픽 분산이 목표 ▸ 비용 효율: Auto Scaling (A) 은 수평 확장의 기본, Route 53 (D) 은 DNS 페일오버 ▸ A+D 조합이 최소 비용으로 다중-AZ 고가용성 실현 【오답 체크】 (B) NLB 단독 사용 — 인스턴스가 여전히 단일 AZ에만 존재 (C) 복잡한 로드밸런서 조합 — 불필요한 비용 증가 (E) CloudWatch 경보 — 자동 복구보다 느린 수동 개입 【시험 포인트】 ▸ 고가용성 = 다중 AZ + 자동 복구 메커니즘 ▸ 비용 우선순위: Auto Scaling이 기본 핵심, 추가 로드밸런서는 선택적

해설

【핵심 용어】 ▸ AWS Cost Anomaly Detection — 머신러닝 기반 비정상 지출 자동 탐지 ▸ AWS Budgets — 정적 임계값 기반 예산 관리 도구 【정답 포인트】 ▸ 핵심: "비정상적인 지출" 감지 → 비용 이상 탐지 필요 ▸ 머신러닝이 과거 패턴으로부터 자동 학습, 편차 자동 감지 ▸ 자동 알림으로 조기 대응 가능 【오답 체크】 (A) Budgets — 고정 임계값만 설정, 비정상 패턴 감지 불가 (C) 가격 계산기 — 추정 도구일 뿐 모니터링 기능 없음 (D) CloudWatch — 메트릭 기반 모니터링, 비용 이상 전문성 부족 【시험 포인트】 ▸ "이상 탐지" = Cost Anomaly Detection (AWS 전용 기능) ▸ 머신러닝 활용 = 패턴 변화를 자동으로 감지하는 지능형 도구

해설

【핵심 용어】 ▸ Amazon Athena — S3의 로그 파일을 직접 SQL로 쿼리하는 서비스 ▸ CloudTrail 통합 — Athena는 CloudTrail 로그 자동 파싱 지원 【정답 포인트】 ▸ "보관 + 언제든 쿼리" → S3 저장소 + 쿼리 엔진 필요 ▸ Athena는 CloudTrail 이벤트 기록을 정의된 테이블로 자동 생성 ▸ SQL 쿼리로 즉시 분석 가능, 데이터 이동 불필요 【오답 체크】 (B) Neptune — 그래프 데이터베이스, 로그 쿼리에 부적합 (C) DynamoDB — 모든 CloudTrail 데이터 마이그레이션 필요, 비용 증가 (D) Athena 노트북 — CloudTrail의 로그 수신처가 아님 【시험 포인트】 ▸ "S3 저장 + SQL 쿼리" = Athena의 정의적 사용 ▸ CloudTrail과 Athena 네이티브 통합이 가장 간단한 방법

해설

【핵심 용어】 ▸ RDS 읽기 전용 복제본 — 읽기 작업 분산, 원본 DB 부하 감소 ▸ Read Replica — 동기식 쓰기, 비동기식 읽기 복제 【정답 포인트】 ▸ 보고서 = 읽기 집약적 작업 → 읽기 트래픽 분리 필요 ▸ 복제본 생성: SQL Server 엔터프라이즈 지원, 자동 관리 ▸ 보고서 엔드포인트만 변경, 원본은 쓰기 용도 유지 【오답 체크】 (B) DynamoDB 변환 — 스키마 재설계, 애플리케이션 코드 수정 필수 (C) 인스턴스 업그레이드 — 보고서 부하 특화 해결 못함, 비용만 증가 (D) Auto Scaling — RDS는 상태형 DB, Auto Scaling 불가 【시험 포인트】 ▸ "읽기 부하 분산" = Read Replica의 표준 용도 ▸ 최소 관리 노력 = AWS 자동 복제, 애플리케이션 수정만 필요

해설

【핵심 용어】 ▸ IAM 정책—AWS 리소스 접근 권한을 정의하는 JSON 기반 정책 문서 ▸ 최소 권한 원칙—필요한 최소한의 권한만 부여하는 보안 원칙 ▸ ARN(Amazon Resource Name)—AWS 리소스를 고유하게 식별하는 문자열 【정답 포인트】 ▸ "AdminTools 읽기·쓰기"→s3:GetObject, s3:PutObject 권한 필요 ▸ "CompanyConfidential 액세스 차단"→명시적 거부(Deny) 또는 미포함 ▸ "특정 버킷만"→버킷별 ARN 기반 세분화된 정책 필수 【오답 체크】 (B) 와일드카드(*) 포함—모든 S3 버킷 액세스 허용으로 보안 위반 (C) CompanyConfidential 포함—불필요한 액세스 권한으로 최소 권한 위반 (D) 관리자급 권한—AdminTools만 필요한데 과도한 권한 부여로 부적절 【시험 포인트】 ▸ 패턴: 특정 리소스만 액세스→ARN 기반 정책으로 세분화 ▸ 함정: 버킷 정책과 IAM 정책 혼동 주의, 최소 권한이 정답의 핵심

해설

【핵심 용어】 ▸ 클러스터 배치 그룹—EC2 인스턴스를 동일 AZ에 배치하여 최저 지연시간 제공 ▸ EBS 다중 연결—단일 EBS 볼륨을 최대 16개 인스턴스에 동시 연결 ▸ HPC(고성능컴퓨팅)—노드 간 긴밀한 통신과 낮은 지연이 필수 요구사항 【정답 포인트】 ▸ "가장 낮은 지연시간"→클러스터 배치 그룹으로만 달성 가능 ▸ "공유 블록 장치"→EBS 다중 연결로 단일 볼륨 다중 인스턴스 연결 ▸ HPC 표준 구성→클러스터 배치 + EBS 다중 연결의 조합 【오답 체크】 (B) EFS 사용—NFS 기반 파일 시스템이지 블록 레벨 다중 연결 아님 (C) 파티션 배치 그룹—인스턴스 간 지연시간이 클러스터보다 증가 (D) 스프레드 배치 그룹—인스턴스 분산 배치로 지연시간 최악 【시험 포인트】 ▸ 패턴: 배치 그룹 선택=(클러스터→지연↓)/(파티션→균형)/(스프레드→가용성) ▸ 함정: EBS 다중 연결을 공유 스토리지로 오인하기 쉬움, 정확한 용어 학습 필수

해설

【핵심 용어】 ▸ EC2 예약 인스턴스—기본 부하용 고정 할인 요금제(1년/3년 약정) ▸ EC2 스팟 인스턴스—피크 부하용 최대 90% 할인(중단 위험) ▸ Auto Scaling—최소~최대 범위 내에서 자동 인스턴스 조정 【정답 포인트】 ▸ "최소 2개 기본 부하"→예약 인스턴스로 비용 고정화 및 가용성 보장 ▸ "최대 5개 피크 부하(+3개)"→추가 3개는 스팟으로 극적 절감 ▸ "항상 사용 가능"→기본 부하는 반드시 온디맨드/예약으로 보장 【오답 체크】 (A) 모두 스팟—중단 위험으로 가용성 보장 불가 (B) 5개 Savings Plan—최대값 전체를 고정으로 오버프로비저닝 (D) Savings Plan + 온디맨드—온디맨드 비용이 스팟보다 훨씬 높음 【시험 포인트】 ▸ 패턴: 최소값→예약/Savings, 초과분→스팟으로 조합이 표준 ▸ 함정: Savings Plan이 예약보다 저렴하나 최대 사용량 예측 필요

해설

【핵심 용어】 ▸ CloudFront—엣지 로케이션 캐싱으로 원본 조회 감소 및 성능 향상 ▸ S3 Standard-IA—저장소 비용 낮음(약 60%) but 요청당 비용 높음 ▸ 요청비 누적—빈번한 요청 시 요청당 비용이 총 비용의 대부분 차지 【정답 포인트】 ▸ "총 S3 비용 절감"→저장소 비용 아닌 요청비가 주 비용 ▸ "CloudFront 캐싱"→S3 원본 조회 극적 감소(80~90%) ▸ "밀리초 액세스"→CloudFront 엣지에서 캐시 제공으로 보장 【오답 체크】 (A) 요청자 지불—S3 비용 주체만 변경, 절감 효과 없음 (B) Standard로 변경—저장소 비용 3배 이상 증가, 역효과 (C) Transfer Acceleration—업로드 속도만 개선, 요청비 영향 없음 【시험 포인트】 ▸ 패턴: "Standard-IA + 빈번한 요청"→요청비 폭증 신호 = CloudFront ▸ 함정: 저장소 비용만 봐서는 전체 비용 파악 불가

해설

【핵심 용어】 ▸ 동적 스케일링—메트릭(CPU/네트워크) 변화에 실시간 대응 ▸ 예측 조정—과거 데이터로 학습하여 사전 확장 ▸ 일정 조정—특정 시간에 정해진 규모로 조정 ▸ 수동 스케일링—관리자 직접 개입으로 조정 【정답 포인트】 ▸ "임의의 요일 갑자기 증가"→패턴 예측 불가능 ▸ "동적 스케일링"→메트릭 변화 즉시 감지·대응 ▸ "성능 유지"→트래픽 발생 후 빠른 응답 필수 【오답 체크】 (A) 수동 스케일링—반응 속도 느림, 자동화 없음 (B) 예측 조정—학습 데이터 필요, 임의의 패턴은 예측 어려움 (D) 일정 조정—정해진 시간만 작동, 랜덤 트래픽 대응 불가 【시험 포인트】 ▸ 패턴: 예측 불가능한 부하→동적 스케일링 자동 매핑 ▸ 함정: 예측 조정이 고급처럼 보이나, 패턴이 없으면 무용지물

해설

【핵심 용어】 ▸ RDS Proxy—연결 풀링으로 빈번한 개설·종료 오버헤드 제거 ▸ 서버리스 애플리케이션—Lambda 등 인스턴스당 연결 관리 어려움 ▸ 연결 풀 고갈—동시 연결 초과로 신규 연결 실패 【정답 포인트】 ▸ "자주 열고 닫기"→연결 생명 사이클 오버헤드 문제 ▸ "RDS Proxy"→기존 연결 재사용으로 오버헤드 제거 ▸ "코드 변경 없이"→투명한 중간 프록시 계층으로 조용히 해결 【오답 체크】 (A) 최대 연결 증가—임시 방편일 뿐 한계 있음 (B) 인스턴스 크기 증가—연결 관리 문제는 미해결 (D) 예약 인스턴스—비용 절감일 뿐 연결 문제 무관 【시험 포인트】 ▸ 패턴: 람다 + RDS 빈번 연결→RDS Proxy 필수 패턴 ▸ 함정: DB 메트릭은 정상이므로 성능 증설로 착각하기 쉬움

해설

【핵심 용어】 ▸ 클러스터 배치 그룹—동일 AZ 배치로 최저 지연시간, 높은 처리량 제공 ▸ 전용 인스턴스 테넌시—단일 고객 전용 하드웨어, 격리만 제공 ▸ Elastic Inference—ML 추론 가속기, HPC 네트워크와 무관 【정답 포인트】 ▸ "긴밀한 노드 간 통신"→클러스터 배치 그룹 필수 ▸ "낮은 지연시간 + 높은 처리량"→동일 AZ 집중 배치의 이점 ▸ CPU/메모리는 이미 적합→네트워크 성능 개선에 집중 【오답 체크】 (B) 전용 테넌시—하드웨어 격리만 하며 네트워크 성능 무관 (C) Elastic Inference—AI/ML 추론용으로 HPC 통신 무관 (D) 용량 예약—인스턴스 확보만 하며 성능 개선 효과 없음 【시험 포인트】 ▸ 패턴: HPC 지연시간↓→클러스터 배치 자동 매핑 ▸ 함정: CPU/메모리만 확장해서는 성능 병목 해결 불가

해설

【핵심 용어】 ▸ Cold Start—Lambda 함수 첫 호출 시 런타임 초기화 지연(수백~수천ms) ▸ 프로비저닝된 동시성—사전 준비된 실행 환경으로 Cold Start 제거 ▸ 예약된 조정—정해진 시간에 동시성 자동 조정 【정답 포인트】 ▸ "매일 사용 시작 시 대기시간 길다"→매일 아침 Cold Start 발생 패턴 ▸ "예약된 조정"→직원 사용 전에 미리 동시성 증가 ▸ "시간대 맞춤"→점심/퇴근 후에 수준 조정하여 비용 최적화 【오답 체크】 (A) 조절 제한 증가—API 부하 제한이지 Cold Start 미해결 (C) CloudWatch 경보—사후 대응으로 사전 예방 아님 (D) 메모리 증가—Cold Start 단축 효과 있으나 예약 조정만큼 효율적 아님 【시험 포인트】 ▸ 패턴: 정해진 시간의 Cold Start→예약된 조정으로 사전 준비 ▸ 함정: 메모리 증가도 도움이 되지만 예약 조정이 더 우월