정답 · 해설

해설

【핵심 용어】 ▸ Auto Scaling — 자동 용량 조정, 원활한 확장 ▸ 스팟 집합 — 비용 절감, 비용 효율성 극대 ▸ Aurora — 빠른 성능 【정답 포인트】 ▸ ASG + ALB → 자동 확장, 로드 분산 최적 ▸ 스팟 → 비용 효율적 ▸ Aurora → 높은 IOPS, 성능 보증 ▸ 완전 자동화 → 수동 개입 불필요 【오답 체크】 (A) 온디맨드만 → 비용 높음, 자동화 부족 (B) Route 53 가중치 → ALB보다 느림, 자동 확장 미지원 (C) Lambda 수동 → 느린 확장, 인스턴스 재타입 위험 【시험 포인트】 자동 확장+비용 효율 = ASG + 스팟 + Aurora

해설

【핵심 용어】 ▸ 예약 인스턴스 — 예측 가능, 저비용 ▸ 스팟 → 변동성, 초저비용, 중단 허용 【정답 포인트】 ▸ 기본 용량(24시간) → 예약 인스턴스로 보증 ▸ 피크 용량(8시간 추가) → 스팟으로 절감 ▸ 상태 비저장 → 인스턴스 중단 영향 최소 【오답 체크】 (A) 스팟만 → 예측 불가, 가용성 위험 (C) 온디맨드+스팟 → 온디맨드 비용 낭비 (D) 전용+온디맨드 → 예약 인스턴스 대비 높음 【시험 포인트】 예측 변동 = 예약(기본) + 스팟(추가)

해설

【핵심 용어】 ▸ S3 수명 주기 → 자동 티어링, 비용 최적 ▸ Glacier Deep Archive → 10년 보관, 초저비용 【정답 포인트】 ▸ S3 직접 저장 → CloudWatch Logs보다 비용 절감 ▸ 수명 주기 정책 → 자동 이동, 관리 간소 ▸ Deep Archive → 7년 초과 요구사항 최적 【오답 체크】 (A) AWS Backup → 수명 주기 정책보다 비용 높음 (C) CloudWatch Logs → 저장소 비용 높음, Backup 불필요 (D) CloudWatch + S3 Lifecycle → 불가능(CWL 자체 전환 미지원) 【시험 포인트】 빈번한 접근(1월) + 장기 보관(10년) = S3 + 수명 주기

해설

【핵심 용어】 ▸ DLQ(Dead Letter Queue) — 실패 메시지 보관 ▸ SQS → SNS → 신뢰성 증대 【정답 포인트】 ▸ 장애 시 대상 → SQS 대기열로 재시도 ▸ Lambda 폴링 → 대기열에서 메시지 처리 ▸ 영구 손실 방지 → 모든 메시지 처리 보증 【오답 체크】 (A) 다중 AZ → 네트워크 장애 해결 불가 (B) 메모리 증설 → 네트워크 문제와 무관 (C) SNS 재시도 → 한계 있음, 실패 메시지 손실 가능 【시험 포인트】 신뢰성 보증 = SQS DLQ + Lambda 폴링

해설

【핵심 용어】 ▸ 복합 경보 — 다중 지표 AND/OR 조건 ▸ 오경보 감소 → 정확한 조건 설정 【정답 포인트】 ▸ CPU 50% 단독 → 경보 없음 ▸ CPU 50% + IOPS 높음 → 경보 발생 ▸ 복합 경보 → 이 조건 정확히 구현 【오답 체크】 (B) 대시보드 → 수동 모니터링, 자동 조치 불가 (C) Synthetics → 외부 모니터링, 내부 지표 미사용 (D) 단일 경보 → 다중 조건 AND 미지원 【시험 포인트】 다중 조건 AND = CloudWatch 복합 경보

해설

【핵심 용어】 ▸ EventBridge 예약 규칙 — 크론 기반 자동화로 지정된 시간에 이벤트 트리거 ▸ Lambda 함수 — 서버리스 컴퓨팅으로 자동 실행 및 관리 불필요 ▸ DB 인스턴스 시작/중지 — RDS API 호출로 비용 최소화 【정답 포인트】 ▸ 12시간 일정 → EventBridge 예약 규칙(크론 식 설정) ▸ 자동 실행 → Lambda 함수로 시작/중지 API 호출 ▸ 비용 절감 → 12시간 미사용 시간 DB 중지로 요금 절감 ▸ 자동화 → 수동 개입 없이 정책 기반 관리 【오답 체크】 (A) Session Manager → 수동 개입 필요로 자동화 불가, 매일 반복 불가능 (B) ElastiCache 추가 → 캐시 클러스터는 추가 비용 발생, 근본적 비용 절감 미흡 (C) EC2 크론 작업 → EC2 인스턴스 자체 유지비용 발생, 크론 관리 복잡도 【시험 포인트】 ▸ "일정 기반 자동화" = EventBridge + Lambda 조합 ▸ "비용 최소화" = 미사용 시간 리소스 중지 ▸ "운영 오버헤드 제거" = 서버리스 완전 자동화 ▸ 정기적 시작/중지 = EventBridge 스케줄링의 표준 사용 사례

해설

【핵심 용어】 ▸ S3 수명 주기 정책 — 지정된 시간 경과 후 객체를 자동으로 다른 스토리지 계층으로 이동 ▸ S3 Standard-IA — 접근 빈도 낮은 데이터 저장용 저비용 계층 ▸ 자동 전환 — 정책 기반으로 시간 경과에 따른 자동 이동 【정답 포인트】 ▸ 90일 이후 접근 빈도 변화 → 자동 스토리지 계층 전환 필요 ▸ 최근 데이터는 Standard 유지 → 빠른 접근성 보장 ▸ 비용 효율성 → 인프리퀀트 계층 비용이 Standard보다 저렴 ▸ 정책 기반 자동화 → 운영 관리 부담 제로 【오답 체크】 (A) S3 Standard-IA 초기 구성 — 높은 초기 비용 발생, 회수 비용 추가 (B) Intelligent-Tiering — 자동 이동하지만 90일 명시적 규칙 아님, 예측 불가 (C) S3 인벤토리 — 객체 메타데이터 수집 도구일 뿐 자동 이동 미지원 【시험 포인트】 ▸ "시간 기반 자동화" = S3 수명 주기 정책 지정 ▸ "접근 빈도 변화" = 단계적 비용 최적화 전략 ▸ "정책 구현" = 관리 오버헤드 제로, 비용 자동 최소화 ▸ 정기 스토리지 전환 = 수명 주기 정책의 핵심 기능

해설

【핵심 용어】 ▸ S3 Object Lock 규정 준수 모드 — 어떤 경우에도 변경/삭제 불가능한 WORM(Write Once, Read Many) ▸ 보존 기간(Retention) — 지정된 기간 후에만 객체 삭제 가능, 우회 불가능 ▸ 법적 컴플라이언스 — 규정 요구사항 자동 시행 【정답 포인트】 ▸ 파일 수정/삭제 방지 → 규정 준수 모드 필수(거버넌스는 관리자 우회 가능) ▸ 365일 보존 = 1년 최소 보관 요구 충족 ▸ 자동 시행 → 사용자 권한과 무관하게 보호 보장 ▸ 과학자/사용자 권한 분리 → 별도 IAM 정책으로 관리 【오답 체크】 (A) 거버넌스 모드 — 관리자가 우회 가능하므로 1년 강제 보관 미보장 (C) IAM 정책 — 실수나 악의적 변경 방지 불가, 규정 준수 아님 (D) Lambda 해시 추적 — 감시 목적일 뿐 실제 수정 방지 불가능 【시험 포인트】 ▸ "규정 준수 요구" = Object Lock 규정 준수 모드 필수 ▸ "삭제 불가" = WORM 특성으로만 달성 가능 ▸ "보존 기간 설정" = 자동화된 컴플라이언스 보장 ▸ 의료/법무 데이터 = Object Lock의 대표 사용 사례

해설

【핵심 용어】 ▸ CloudFront — 글로벌 콘텐츠 전송 네트워크(CDN)로 엣지 로케이션에서 캐싱 ▸ 엣지 서버 — 지리적으로 분산된 캐시 서버로 사용자 근처에서 콘텐츠 제공 ▸ 레이턴시 감소 — 글로벌 사용자에게 빠른 응답 시간 제공 【정답 포인트】 ▸ 글로벌 사용자 → CDN 필수(지연시간 최소화) ▸ S3 오리진 + CloudFront = 캐싱 자동화로 원본 부하 감소 ▸ 미디어 파일 스트리밍 → CloudFront의 대표적 사용 사례 ▸ 신속 제공 → 엣지에서 로컬 캐시 활용 【오답 체크】 (A) DataSync — 온프레미스↔클라우드 데이터 동기화 도구(배포 아님) (B) Global Accelerator — 애플리케이션 성능 최적화용(콘텐츠 캐싱 미지원) (D) SQS — 메시지 큐 서비스(콘텐츠 배포 용도 아님) 【시험 포인트】 ▸ "지리적 분산" + "빠른 제공" = CloudFront CDN ▸ "S3 + CloudFront" = 정적 콘텐츠 글로벌 배포의 표준 패턴 ▸ "전 세계 사용자" 언급 → 즉각적 CloudFront 선택 신호 ▸ 미디어 스트리밍 = CloudFront 최적 활용 분야

해설

【핵심 용어】 ▸ AWS Lake Formation — 데이터 레이크 자동 구축으로 수집, 정리, 보안 관리 ▸ AWS Glue — 자동 크롤링 및 ETL으로 데이터 카탈로깅 및 변환 ▸ Amazon Athena — S3의 SQL 기반 일회성 쿼리 분석 서비스 ▸ Amazon QuickSight — 대시보드 및 KPI 시각화 BI 도구 【정답 포인트】 ▸ 배치+스트림 통합 → Lake Formation으로 데이터 레이크 구축 (E) ▸ Glue로 자동 크롤링/ETL → Parquet 포맷(최적화 분석) (E) ▸ 일회성 쿼리 → Athena(서버리스, 오버헤드 최소) (A) ▸ BI 시각화 → QuickSight로 KPI 대시보드 (A) ▸ "운영 오버헤드 최소" = 서버리스(Athena) + 자동화(Lake Formation) 【오답 체크】 (B) Kinesis Data Analytics — 스트림 실시간 분석용(일회성 배치 쿼리 아님) (C) Lambda 커스텀 함수 — 운영 오버헤드 증가, 자동화 미흡 (D) OpenSearch — 검색/로깅 특화(분석 BI 용도 아님), 고비용 【시험 포인트】 ▸ "운영 오버헤드 최소" = 서버리스(Athena) + 자동화(Lake Formation) ▸ "배치+스트림 통합" = 데이터 레이크 패턴 ▸ "BI + 대시보드" = QuickSight(A와 함께) ▸ 2개 선택: 데이터 수집 (E) + 분석/시각화 (A)

해설

【핵심 용어】 ▸ AWS Backup — 중앙 집중식 백업 관리로 명시적 보존 정책 적용 ▸ CloudWatch Logs 내보내기 — 감사 로그를 S3로 장기 저장 ▸ 감사 로그(Audit Log) — DB 내 모든 작업 기록, 규정 준수 증거 【정답 포인트】 ▸ 데이터 5년 보관 → AWS Backup으로 명시적 보존 정책 설정 (E) ▸ 감사 로그 무기한 → CloudWatch Logs를 S3로 내보내기 (D) ▸ Backup은 PITR 및 보존 정책 제공 → 명시적 5년 보관 (E) ▸ 데이터와 로그는 분리된 요구사항 → D+E 조합 【오답 체크】 (A) 수동 스냅샷 — 자동화 부족, 유지관리 부담, 5년 강제 미보장 (B) 자동 백업 수명 주기 정책 — Aurora에서 미지원되는 기능 (C) 자동 백업 최대 보존 — Aurora는 기본 35일이 최대(5년 불가능) 【시험 포인트】 ▸ "명시적 보존 기간" → AWS Backup의 보존 정책 설정 ▸ "감사 로그 장기 보관" → CloudWatch Logs 내보내기 ▸ "데이터와 로그 분리" → 별도 요구사항(D+E) ▸ "자동 백업만으로는 5년 보관 불가능" → AWS Backup 필수

해설

【핵심 용어】 ▸ API 키 + 사용량 계획 — 인증된 사용자 식별 및 속도 제한 ▸ AWS WAF — DDoS 및 봇넷 공격의 악성 요청 차단 ▸ 다층 방어 — 엣지 차단 + 인증으로 보안 강화 【정답 포인트】 ▸ 봇넷 사기성 요청 → WAF로 IP/패턴 기반 차단 (C) ▸ 정품 사용자 식별 → API 키 사용량 계획으로 접근 제어 (A) ▸ 이중 방어 — WAF(악성 차단) + API 키(인증) ▸ 조합 효과 — 악성 트래픽 즉시 차단, 정품 사용자만 접근 【오답 체크】 (B) Lambda 내 IP 필터링 — Lambda 호출 비용 발생, 비효율적 방어 (D) 비공개 API 전환 — 기존 사용자 영향, 엔드포인트 변경 불편 (E) 각 사용자 IAM 역할 생성 — 운영 오버헤드 극도로 증가 【시험 포인트】 ▸ "봇넷 공격" = WAF 필수 대응 (C) ▸ "승인된 사용자" = API 키 인증 (A) ▸ "엣지 차단 + 인증" = 다층 방어 전략 ▸ "2개 선택: 보안 계층 (C) + 접근 제어 (A)"

해설

【핵심 용어】 ▸ S3 Standard — 밀리초 단위 접근성 보장하는 일반 스토리지 ▸ 수명 주기 정책 — 30일 후 자동 삭제 또는 아카이브 ▸ 재해 복구(DR) — 빠른 복구 시간 목표(RTO) 지원 【정답 포인트】 ▸ 밀리초 단위 액세스 → S3 Standard(즉시 검색 가능) ▸ 30일 보관 → S3 수명 주기로 자동 관리 ▸ 월 300MB 적은 데이터량 → 저비용 우선 ▸ JSON 형식 → 구조화 불필요(S3로 충분) ▸ 비용 효율성 → Glacier나 database보다 경제적 【오답 체크】 (A) OpenSearch — 검색/로깅 특화(일반 백업 아님), 고비용 (B) Glacier — 즉시 접근 불가(검색에 시간 소요 → RTO 미충족) (D) RDS — 데이터베이스 백업 용도(JSON 파일 저장 비효율) 【시험 포인트】 ▸ "밀리초 단위 접근" = S3 Standard 필수 ▸ "30일 보관" = 수명 주기 정책으로 자동화 ▸ "작은 데이터량(300MB)" = 저비용 솔루션 ▸ "재해 복구 + 빠른 접근" = S3 Standard의 가치 제안 ▸ JSON 파일 정적 저장 = S3의 표준 사용 사례

해설

【핵심 용어】 ▸ AWS Lambda — 서버리스 컴퓨팅으로 자동 확장, 운영 관리 불필요 ▸ S3 이벤트 트리거 — 객체 도착 시 자동 Lambda 실행 ▸ Amazon Aurora — 관리형 고가용성 데이터베이스 【정답 포인트】 ▸ 매일 수천 번 실행 → 서버리스 확장성(Lambda) ▸ 운영 오버헤드 최소화 → 관리형 서비스(Lambda + Aurora) ▸ S3 + Lambda = 이벤트 기반 자동화 ▸ Aurora = 고가용성 데이터베이스 ▸ 확장성 최대화 → 동시 실행 자동 제어 【오답 체크】 (A) EC2 인스턴스 — 수동 확장 필요, 관리 오버헤드 증가 (C) EBS 다중 연결 — 복잡도 증가, JSON 파일 저장 방식 부적절 (D) ECS + EC2 — Lambda보다 운영 부담 증가, 인스턴스 관리 필요 【시험 포인트】 ▸ "운영 오버헤드 최소" = 서버리스(Lambda) ▸ "매일 수천 번" = 자동 확장 필요 ▸ "고가용성" = Aurora(관리형 고가용성) ▸ "이벤트 기반 처리" = S3 + Lambda 조합 ▸ Python 애플리케이션 클라우드 마이그레이션 = Lambda의 표준 사용 사례

해설

【핵심 용어】 ▸ Amazon FSx for Lustre — HPC 최적화 병렬 고성능 파일 시스템 ▸ S3 통합 — 영구 데이터 저장소와의 자동 동기화 ▸ 병렬 처리 — 수백 개 인스턴스의 동시 파일 접근 【정답 포인트】 ▸ HPC 워크로드 → Lustre(병렬 파일 처리 최적화) ▸ 스팟 인스턴스 수백 개 → 고성능 파일 시스템 필수 ▸ S3 통합 → 출력 파일 자동 저장, 영구 스토리지 역할 ▸ 온프레미스→클라우드 데이터 복사 가능 ▸ 낮은 레이턴시 — Lustre의 병렬 성능 【오답 체크】 (B) Windows 파일 서버용 FSx — Linux HPC 환경 부적합 (C) EBS + Glacier — 고성능 파일 시스템 아님(HPC 비최적) (D) EBS gp2 + S3 — 저성능(병렬 처리 미지원, HPC 요구사항 미충족) 【시험 포인트】 ▸ "HPC" = Lustre 파일 시스템 지정 ▸ "병렬 처리" = Lustre의 강점(POSIX 준수) ▸ "S3 통합" = 출력 파일 자동 보관 ▸ "수백 개 인스턴스" = 고성능 공유 스토리지 필수 ▸ 재무 모델링 = HPC의 대표 사용 사례

해설

【핵심 용어】 ▸ Amazon SQS — 메시지 큐로 발신자와 수신자 분리 ▸ Dead Letter Queue(DLQ) — 처리 실패 메시지의 격리 ▸ 메시지 보관 — 최대 14일 동안 메시지 유지 【정답 포인트】 ▸ 시간당 1,000개 메시지 → SQS 확장성 지원 ▸ 최대 2일 처리 → SQS 장기 보존(기본 4일) ▸ 처리 실패 격리 → DLQ로 별도 관리 ▸ 다른 메시지 영향 없음 → SQS의 독립적 처리 ▸ 운영 효율 → 관리형 서비스 【오답 체크】 (A) Redis EC2 — 관리 부담 증가, 고가용성 미보장, 수동 관리 (B) Kinesis — 실시간 스트림 처리용(2일 대기 부적합) (D) SNS — 발행-구독 알림(메시지 보관 불가능, 순서 미보장) 【시험 포인트】 ▸ "배달 못한 편지" = DLQ 언급 → SQS 지정 ▸ "처리 실패 격리" = SQS DLQ의 핵심 기능 ▸ "메시지 버퍼링" = 큐 기반 솔루션 ▸ "운영 효율" = 관리형 SQS(EC2 관리 불필요) ▸ 비동기 처리 + 실패 처리 = SQS의 표준 사용 사례

해설

【핵심 용어】 ▸ OAI(Origin Access Identity) — CloudFront만 S3에 접근 가능하도록 제한 ▸ AWS WAF → CloudFront — 모든 트래픽 검사로 보안 강화 ▸ 정적 웹사이트 보안 — 계층화된 접근 제어 【정답 포인트】 ▸ 모든 웹사이트 트래픽 검사 → WAF를 CloudFront에 연결 ▸ S3 직접 접근 방지 → OAI로 CloudFront만 허용 ▸ 보안 정책 준수 → 두 가지 제어 통합 ▸ 접근 제어 + 콘텐츠 검사 = 이중 방어 【오답 체크】 (A) WAF ARN 기반 S3 정책 — CloudFront 경유 트래픽만 WAF 검사 불가 (B) CloudFront가 모든 요청을 WAF로 "전달" — 미지원 기능 (C) 보안 그룹은 S3에 적용 불가(EC2용), 완전한 솔루션 아님 【시험 포인트】 ▸ "모든 트래픽 WAF 검사" = CloudFront에 WAF 활성화 ▸ "S3 보호" = OAI로 직접 접근 방지 ▸ "정적 웹사이트 보안" = CloudFront + OAI + WAF 조합 ▸ "계층화 보안" = WAF(검사) + OAI(접근 제어) ▸ 정책 준수 = 모든 조건 충족 필수

해설

【핵심 용어】 ▸ CloudFront — 글로벌 콘텐츠 전송 네트워크(CDN)로 엣지 로케이션에서 캐싱 ▸ 엣지 캐싱 — 지역별 빠른 콘텐츠 제공 ▸ 원본 부하 분산 — S3 요청 감소로 비용 절감 【정답 포인트】 ▸ 수백만 조회 → CDN 캐싱으로 S3 부하 분산 ▸ 전 세계 사용자 → CloudFront 엣지 로케이션 활용 ▸ 정적 HTML → CloudFront의 이상적 용도 ▸ 비용 효율 → 캐싱으로 S3 요청 감소 ▸ 효율적 제공 → 글로벌 캐싱 네트워크 【오답 체크】 (A) 미리 서명된 URL — 임시 접근 제한용(글로벌 캐싱 아님) (B) 교차 리전 복제 — 데이터 동기화(사용자 성능 미개선) (C) Route 53 지리적 근접 — DNS 라우팅(콘텐츠 캐싱 아님) 【시험 포인트】 ▸ "전 세계 사용자" + "수백만 조회" = CDN 필수 ▸ "정적 콘텐츠" = CloudFront의 핵심 사용 사례 ▸ "효율적 제공" = 글로벌 캐싱 네트워크 ▸ "단일 솔루션" = 글로벌 성능 + 비용 절감 동시 달성 ▸ 일일 보고서 정적 배포 = CloudFront의 표준 시나리오

해설

【핵심 용어】 ▸ 예약 인스턴스(RI) — 기본 용량의 저비용 장기 약정 ▸ 온디맨드 인스턴스 — 변동 용량의 유연한 공급 ▸ 스팟 인스턴스 — 저비용이지만 중단 위험(다운타임 초래) 【정답 포인트】 ▸ 다운타임 없음(지속 처리) → 스팟 불안정성 제외 ▸ 기본 용량 → RI(저비용, 안정적) ▸ 간헐적 트래픽(예측 불가) → 온디맨드로 유연 대응 ▸ 비용 효율 = RI + 온디맨드 계층화 ▸ 메시지 처리 보장 → 안정적 리소스 필수 【오답 체크】 (A) 스팟 독점 — 인스턴스 중단 위험(다운타임 초래) (B) RI 독점 — 간헐적 트래픽 시 유휴 자원 낭비 (C) 스팟 + RI — 중단 위험으로 다운타임 불가 【시험 포인트】 ▸ "다운타임 없음" = 스팟 인스턴스 배제 ▸ "예측 불가능" = 온디맨드 필요성 ▸ "비용 효율" = RI 기본 + 온디맨드 추가 ▸ "안정성 + 비용" = RI/온디맨드 계층화 전략 ▸ SQS 메시지 처리 = 지속성 보장 필수

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — 조직 차원의 통합 접근 제어 ▸ 루트 조직 단위 — 모든 계정을 포함하는 최상위 단위 ▸ 중앙 집중식 관리 — 단일 지점에서 권한 제어 【정답 포인트】 ▸ 모든 AWS 계정 → 조직 차원 정책(SCP) 필수 ▸ 확장성 → 루트 OU에 SCP로 상속 자동화 ▸ 단일 관리 지점 → 조직 수준의 중앙 집중식 제어 ▸ 개별 계정 역할 불필요 → 계정마다 정책 관리 제외 ▸ 신규 계정 자동 적용 → 상속 구조 【오답 체크】 (A) ACL — 리소스 수준 제어(조직 차원 아님) (B) 보안 그룹 — 네트워크 방화벽(권한 제어 아님) (C) 각 계정 역할 — 단일 지점 관리 불가, 확장성 문제 【시험 포인트】 ▸ "모든 AWS 계정" + "대규모 조직" = SCP ▸ "단일 지점 관리" = 루트 OU에 SCP ▸ "확장 가능" = 상속으로 신규 계정 자동 적용 ▸ "서비스 제한" = 명시적 거부 정책(SCP) ▸ "Organizations" = SCP의 필수 컨텍스트 ▸ 조직 전체 정책 = AWS Organizations의 핵심 기능