정답 · 해설

해설

【핵심 용어】 ▸ 계정 암호 정책—IAM에서 계정 수준의 암호 규칙 정의 ▸ 글로벌 적용—모든 신규/기존 사용자에 자동 반영 【정답 포인트】 ▸ IAM 계정 암호 정책은 복잡성, 최소 길이, 교체 기간 등을 일괄 설정 ▸ 개별 설정 불필요, 신규 사용자도 자동 적용 【오답 체크】 (B)IAM은 사용자 개별 정책 미지원(계정 단위만) ▸ (C)타사 솔루션은 불필요(AWS 기본 기능으로 충분) ▸ (D)CloudWatch는 모니터링용, 정책 설정 기능 없음 【시험 포인트】계정 전체 암호 정책→IAM 계정 암호 정책이 정답

해설

【핵심 용어】 ▸ AWS Batch—배치 처리 최적화 서비스 ▸ 다중 언어 지원—컨테이너 기반 작업 실행 【정답 포인트】 ▸ Batch는 다양한 언어/형식의 작업을 컨테이너로 패키징하여 관리 ▸ EventBridge 일정과 결합으로 자동 스케일링 및 순차 실행 제공 【오답 체크】 (B)App Runner는 웹 애플리케이션용, 배치 작업에 부적합 ▸ (C)Lambda는 15분 제한으로 1시간 작업 불가능 ▸ (D)Auto Scaling은 비용 낭비, 복잡한 조정 필요 【시험 포인트】다중 언어 배치 작업→AWS Batch+EventBridge 조합이 정답

해설

【핵심 용어】 ▸ NAT 게이트웨이—관리형 아웃바운드 NAT 서비스 ▸ 퍼블릭 서브넷 위치—인터넷 게이트웨이와 통신 필요 【정답 포인트】 ▸ NAT 게이트웨이는 AWS 관리형으로 패치/유지보수 자동화 ▸ 퍼블릭 서브넷 배치로 프라이빗 인스턴스의 아웃바운드 인터넷 통신 지원 【오답 체크】 (A)NAT 인스턴스는 수동 관리 필요(운영 오버헤드 높음) ▸ (B)NAT는 퍼블릭 서브넷에만 배치 가능 ▸ (D)NAT 게이트웨이는 퍼블릭만 지원(프라이빗 배치 불가) 【시험 포인트】관리형 아웃바운드 NAT→NAT 게이트웨이(퍼블릭) 선택이 정답

해설

【핵심 용어】 ▸ 리전 수준 EBS 기본 암호화—모든 신규 EBS에 자동 적용 ▸ 기본 KMS 키—리전 내 EBS 암호화 기본값 설정 【정답 포인트】 ▸ (B)EKS 클러스터 생성 후 개별 EBS 암호화는 수동이므로 번거로움 ▸ (D)IAM 역할+키 정책으로 EKS가 KMS 키에 접근 권한 보유 【오답 체크】 (A)Kubernetes 플러그인은 표준 솔루션 아님 ▸ (C)리전 기본 설정만으로는 정책(IAM 역할) 구성 불완전 ▸ (E)비밀에 키 저장은 보안 위협, Kubernetes는 EBS 관리 불가 【시험 포인트】EBS 암호화+권한 관리→리전 기본값+IAM 역할 조합이 정답

해설

【핵심 용어】 ▸ S3+DynamoDB 분리—이미지와 메타데이터 저장소 분리 ▸ 지리적 코드 파티셔닝—같은 코드의 업데이트는 단일 파티션 처리 【정답 포인트】 ▸ DynamoDB는 지리적 코드 기반 파티셔닝으로 높은 동시성 업데이트 지원 ▸ S3는 이미지 저장소로 확장성 우수+비용 효율적 【오답 체크】 (A)RDS는 대량 이미지 저장에 비용 비효율 ▸ (C)DynamoDB에 이미지 저장 시 매우 비싼 비용(최대 400KB 제한) ▸ (D)RDS+S3 조합은 메타데이터 쿼리 성능 낮음 【시험 포인트】대용량 파일+높은 동시성→S3+DynamoDB 분리 저장 정답

해설

【핵심 용어】 ▸ 수명 주기 정책—시간 경과에 따른 스토리지 클래스 자동 전환 ▸ 3단계 계층—Standard→IA→Glacier Deep Archive 【정답 포인트】 ▸ Standard는 일일 ML 모델 재교육(30일)에 최적 성능 ▸ 30일 후 IA로 전환(저비용), 1년 후 Glacier로 보관(최소 비용) 【오답 체크】 (A)Intelligent-Tiering은 접근 패턴 기반 자동 이동이므로 30일 경계 미보장 ▸ (B)동일 이유(자동 이동 예측 불가) ▸ (C)IA는 30일 이전 비용이 더 높음 【시험 포인트】다단계 수명 주기+성능 최적→명시적 시점 전환이 정답

해설

【핵심 용어】 ▸ Step Functions—서버리스 워크플로 오케스트레이션 ▸ 수동 승인—대기 상태(Wait for Task Token) 지원 【정답 포인트】 ▸ Step Functions는 Lambda, EC2, 컨테이너, 온프레미스 등 다양한 리소스 통합 가능 ▸ 상태 머신으로 복잡한 워크플로(승인 대기 포함) 관리 용이 【오답 체크】 (B)Glue는 ETL용, 오케스트레이션 기능 제한적 ▸ (C)SQS는 메시징만 가능, 워크플로 제어 불가 ▸ (D)EventBridge는 이벤트 라우팅만 가능(상태 추적 불가) 【시험 포인트】복잡한 워크플로+수동 승인→Step Functions 오케스트레이션 정답

해설

【핵심 용어】 ▸ RDS Proxy—데이터베이스 연결 풀 관리 ▸ 연결 재사용—기존 연결을 여러 애플리케이션과 공유 【정답 포인트】 ▸ RDS Proxy는 데이터베이스 연결 수 제한 문제 해결 ▸ 서버리스 워크로드의 스파이크 트래픽에 효과적+운영 자동화 【오답 체크】 (B)캐시는 연결 문제 해결 불가(조회 성능만 개선) ▸ (C)인스턴스 업그레이드는 연결 수 제한 근본 해결 안 됨 ▸ (D)다중 AZ는 고가용성만 제공, 연결 풀 관리 불가 【시험 포인트】연결 거부+변동 트래픽→RDS Proxy 연결 풀링이 정답

해설

【핵심 용어】 ▸ Auto Scaling 수명 주기 후크—인스턴스 시작/종료 시점 제어 ▸ 즉시 보고—라이프사이클 이벤트 트리거 【정답 포인트】 ▸ 수명 주기 후크는 인스턴스 시작/종료 시 정확히 감사 데이터 수집 ▸ 사용자 지정 스크립트로 실시간 보고 가능 【오답 체크】 (A)정기적 Lambda는 즉시성 부족(시작/종료 놓칠 수 있음) ▸ (C)사용자 데이터는 시작만 가능(종료 시 실행 불가) ▸ (D)수동 구성은 Auto Scaling과 자동 연계 불가 【시험 포인트】Auto Scaling 이벤트 감지+즉시 보고→수명 주기 후크 정답

해설

【핵심 용어】 ▸ UDP 게임 프로토콜—NLB 필수(Layer 4) ▸ DynamoDB 주문형—자동 확장(서버리스) 【정답 포인트】 ▸ NLB는 UDP 지원+극저지연 게임 통신 최적 ▸ DynamoDB 주문형은 동시 사용자 급증에 자동 확장(운영 없음) 【오답 체크】 (A)Route 53은 로드 밸런싱 불가(DNS만)+Aurora는 관계형(비관계형 데이터 부적합) ▸ (C)ALB는 HTTP/HTTPS만(UDP 불지원)+Global DB는 멀티리전(과도한 복잡성) ▸ (D)ALB는 UDP 미지원+글로벌 테이블은 경합성 필요(부하 관리 복잡) 【시험 포인트】UDP 게임+자동 확장→NLB+DynamoDB 주문형 조합 정답

해설

【핵심 용어】 ▸ 프로비저닝된 동시성—Lambda 초기화 시간 제거 ▸ 콜드 스타트—라이브러리 로드 지연 극복 【정답 포인트】 ▸ 프로비저닝 동시성은 함수를 미리 실행 상태로 유지 ▸ 라이브러리 로드 시간 생략으로 응답 지연 최소화 【오답 체크】 (A)직접 DB 연결은 보안 위험+API 우회(운영 복잡성 증가) ▸ (C)S3 캐시는 쿼리 지연 해결 아님(캐시 무효화 문제) ▸ (D)DB 크기는 연결 수 해결만(라이브러리 로드 지연 해결 안 됨) 【시험 포인트】Lambda 콜드 스타트+지연 감소→프로비저닝 동시성 정답

해설

【핵심 용어】 ▸ EventBridge 일정—크론 표현식 기반 자동 트리거 ▸ Lambda 함수—서버리스 작업 실행(운영 오버헤드 없음) 【정답 포인트】 ▸ Lambda+EventBridge는 완전 서버리스로 관리 인프라 불필요 ▸ 비용 최소화: 함수 실행만 비용(상시 실행 없음) 【오답 체크】 (A)탄력적 크기 조정은 일정 기반 아님(항상 최소 인스턴스 실행) ▸ (B)파트너 솔루션은 추가 비용/종속성 ▸ (C)crontab은 인스턴스 상시 실행 필요(비용 절감 미흡) 【시험 포인트】일정 기반 자동 시작/중지→Lambda+EventBridge 서버리스 정답

해설

【핵심 용어】 ▸ Aurora 복제본—프라이머리와 독립적으로 읽기 쿼리 처리 가능 ▸ 코드 최소 변경—기존 PostgreSQL 마이그레이션 용이 【정답 포인트】 ▸ PostgreSQL 기반→Aurora PostgreSQL 직접 호환 ▸ 읽기 쿼리 분리→복제본이 보고서 처리, 프라이머리는 쓰기 전담 ▸ 수평 확장성→복제본 추가로 쿼리 성능 향상 【오답 체크】 (A)DocumentDB는 MongoDB 호환으로 PostgreSQL 스키마 재작성 필요 ▸ (C)RDS 읽기 전용 복제본은 지원 안 함, 다중 AZ는 장애 조치용 ▸ (D)DynamoDB는 관계형 쿼리 지원 불가, 스키마 완전 변경 필요 【시험 포인트】"최소 코드 변경"→PostgreSQL 호환 솔루션 ▸ "읽기 쿼리 분리"→복제본 오프로드

해설

【핵심 용어】 ▸ TLS—전송 중 데이터 암호화(in-transit encryption) ▸ NLB→계층 4(전송 계층) 로드 밸런싱 【정답 포인트】 ▸ "전송 중 보안"→TLS/SSL로 클라이언트-NLB 간 암호화 ▸ NLB는 TLS 리스너 지원→서버 인증서 배포로 해결 ▸ 3계층 트래픽 흐름에서 클라이언트 진입점 보호 【오답 체크】 (B)Shield/WAF→DDoS 방어, 전송 암호화 목적 아님 ▸ (C)ALB로 변경→불필요한 아키텍처 변경, NLB도 TLS 가능 ▸ (D)EBS 암호화→저장소 보안, 전송 중 보안과 무관 【시험 포인트】"전송 중" 키워드→TLS/SSL 암호화 선택 ▸ NLB에서 TLS 구성 가능

해설

【핵심 용어】 ▸ License Included—소켓/코어 기반 기존 라이센스 재사용 ▸ Dedicated Host—물리 서버 단위 구매로 라이센스 적용 가능 【정답 포인트】 ▸ "기존 라이센스 사용"→Host 레벨 제어 필수 ▸ "용량 예측 가능"→RI(예약)으로 선할인 획득 ▸ Dedicated Reserved Host→물리 서버 예약+라이센스 모니터링 용이 【오답 체크】 (B)온디맨드 호스트→라이센스 비용 절감 미흡 ▸ (C)인스턴스 단위→소켓/코어 라이센스 추적 어려움 ▸ (D)온디맨드 인스턴스→예약 할인 미적용으로 비용 높음 【시험 포인트】"소켓/코어 라이센스"→Host 단위 구매 ▸ "기존 라이센스"+"예측 가능"→Reserved Host

해설

【핵심 용어】 ▸ POSIX 호환—Unix/Linux 표준 파일 인터페이스 필요 ▸ 다중 AZ 공유→네트워크 파일 시스템 필수 ▸ EFS-IA—저접근 데이터 자동 이동으로 비용 최적화 【정답 포인트】 ▸ "POSIX 호환"→S3(객체 저장소) 제외, EFS 선택 ▸ "다중 AZ 공유"→EFS Multi-AZ 기본 제공 ▸ "30일 후 드물게 접근"→Standard-IA로 자동 이동 설정 【오답 체크】 (A)S3 Glacier→조회 지연(분 단위), POSIX 미지원 ▸ (B)S3 Standard-IA→객체 저장소, 공유 파일 시스템 아님 ▸ (D)One Zone-IA→단일 AZ, "고가용성" 요구 미충족 【시험 포인트】POSIX+다중 AZ→EFS만 가능 ▸ "초기 자주, 이후 드물게"→IA 계층 수명 주기

해설

【핵심 용어】 ▸ 최소 권한 원칙 — 필요한 최소 권한만 부여 ▸ 보안 그룹 우선 — 1차 방어선, 네트워크 ACL은 2차 ▸ 그룹 간 참조 — CIDR 대신 보안 그룹 ID로 통신 제한 【정답 포인트】 ▸ 웹 서버 SG → LB 보안 그룹만 443 허용(0.0.0.0/0 제외) ▸ MySQL SG → 웹 서버 SG에서만 3306 허용 ▸ 보안 그룹 체인 → 계층 간 최소 권한 실현 【오답 체크】 (A) 0.0.0.0/0 허용 → 최소 권한 원칙 위배 (B) 네트워크 ACL → 보안 그룹보다 관리 복잡, 우선순위 낮음 (D) LB에서 직접 443 → 로드 밸런서 SG 참조 필요, ACL은 부적절 【시험 포인트】 ▸ "최소 권한" → 보안 그룹 체이닝(SG 참조) 활용 ▸ 0.0.0.0/0 제외 → 특정 출처(LB SG)에서만 허용

해설

【핵심 용어】 ▸ 동일 데이터 반복 쿼리 — 캐싱으로 메모리 접근 우선 ▸ ElastiCache — Redis/Memcached 기반 고속 캐시 【정답 포인트】 ▸ "동일 데이터 세트" + "자주 요청" → 캐시 히트율 높음 ▸ ElastiCache 미초 응답 시간 → 데이터베이스 부하 감소 ▸ 대규모 데이터셋 → 메모리 기반 저장소로 효율적 처리 【오답 체크】 (A) SNS → 메시징 서비스, 캐싱 기능 없음 (C) 읽기 복제본 → 데이터베이스 부하 여전히 발생 (D) Kinesis Firehose → 스트리밍/ETL용, 캐싱 목적 아님 【시험 포인트】 ▸ "성능 저하" + "동일 데이터" 반복 → ElastiCache 캐싱 ▸ 데이터베이스 직접 호출 최소화 전략 선택

해설

【핵심 용어】 ▸ 최소 권한 원칙 — CloudFormation 작업에 필요한 권한만 부여 ▸ IAM 역할 → 서비스(EC2, Lambda) 임시 권한 부여 ▸ 명시적 정의 — 포괄적 권한(PowerUsers, Admin) 제외 【정답 포인트】 ▸ (D) CF 작업 전용 정책 → 최소 권한 구현 ▸ (E) IAM 역할 + 명시적 권한 → 스택별 세밀한 권한 제어 ▸ 조합: 사용자 정책 (D) + 역할 정책 (E) 으로 이중 제어 【오답 체크】 (A) 루트 자격증명 → 최소 권한 원칙 위배 (B) PowerUsers → 관리형 정책, CloudFormation 포함하지만 과도한 권한 (C) AdministratorAccess → 모든 권한 부여, 최소 권한 원칙 완전 위배 【시험 포인트】 ▸ 최소 권한 → 커스텀 정책 (D) + 역할 기반 권한 (E) ▸ 관리형 정책(PowerUsers, Admin) 제외하는 것이 핵심

해설

【핵심 용어】 ▸ 기본 보안 그룹 — 인바운드 트래픽 모두 차단 ▸ 보안 그룹 체이닝 — 출발 SG에서 도착 SG로 참조 【정답 포인트】 ▸ 기본 상태 라우팅/NACL → 문제 아님 ▸ "같은 VPC 내 통신" → 보안 그룹 설정만 필요 ▸ RDS 인바운드 규칙 → 웹 계층 SG 참조로 3306 허용 【오답 체크】 (A) NACL → 기본 Allow All이므로 이미 통신 가능 (B) 라우팅 테이블 → 같은 VPC 내 기본 경로 존재 (C) VPC 피어링 → 아키텍처 변경, 초과 복잡성 【시험 포인트】 ▸ 같은 VPC 라우팅/NACL 기본값 상태 → 보안 그룹이 병목 ▸ RDS 기본 보안 그룹 → 모든 인바운드 차단 상태 해결