정답 · 해설

해설

【핵심 용어】 ▸ EBS 암호화—볼륨 생성 시점의 설정 / ▸ 유휴 상태 암호화—AWS KMS 자동 적용 / 【정답 포인트】 ▸ '유휴 상태에서 암호화'→암호화된 볼륨 생성이 유일한 해법 / ▸ 기본 AWS 관리형 키 사용으로 추가 설정 불필요 / 【오답 체크】 (A)IAM 역할은 접근 제어만 담당, 암호화 활성화 불가(60자) / (C)태그는 메타데이터 추적 기능, 암호화 설정 아님(70자) / (D)KMS 키 정책은 권한 제어이지 암호화 활성화 아님(75자) / 【시험 포인트】 ▸ 정책/권한 vs 기술 설정의 명확한 구분 필수 / ▸ EBS 암호화=볼륨 레벨 기술 구현

해설

【핵심 용어】 ▸ Aurora Serverless—MySQL 호환 + 자동 확장 / ▸ 비용 최적화—미사용 시 비용 0으로 책정 / 【정답 포인트】 ▸ '데이터베이스 수정 필요 없음'→MySQL 완전 호환성 요구 / ▸ '산발적 사용'→서버리스 자동 확장이 비용 절감 핵심 / ▸ 스케일 다운 시 기본 요금만 청구 / 【오답 체크】 (A)DynamoDB는 NoSQL로 MySQL 코드 대량 변경 필수(80자) / (B)RDS 프로비저닝 기반으로 24/7 비용 발생, 산발적 사용에 비효율적(85자) / (D)EC2 자가관리는 운영 복잡도 증가, 예측 불가 확장에 부적합(80자) / 【시험 포인트】 ▸ MySQL 호환 + 예측 불가 사용 = Aurora Serverless 정답 / ▸ 프로비저닝 vs Serverless의 비용 패턴 차이

해설

【핵심 용어】 ▸ S3 퍼블릭 액세스 차단—계정/버킷 레벨 방어 / ▸ SCP(서비스 제어 정책)—조직 차원의 강제 정책 / 【정답 포인트】 ▸ '우발적 노출 방지'→사전 차단(Prevention)이 사후 대응보다 효과적 / ▸ 계정 수준 설정으로 모든 객체 보호 보장 / ▸ IAM 사용자가 설정 변경 불가능하도록 SCP로 강제 / 【오답 체크】 (A)GuardDuty는 위협 탐지만 가능, 자동 차단 기능 없음(75자) / (B)수동 변경은 실시간 보호 불가, 지연 발생으로 부적합(70자) / (C)Resource Access Manager는 리소스 공유 도구, 모니터링 기능 없음(75자) / 【시험 포인트】 ▸ 예방(Prevent) > 탐지(Detect) > 대응(Respond) 순서 / ▸ SCP = 조직 수준 강제, 개별 IAM 정책보다 우선

해설

【핵심 용어】 ▸ Amazon SES—관리형 대량 이메일 서비스 / ▸ 비동기 처리—웹 계층과 이메일 전송 분리 / 【정답 포인트】 ▸ '이메일 지연'→웹 애플리케이션 로직에서 분리 필수 / ▸ '운영 오버헤드 최소화'→서버 관리 불필요한 관리형 서비스 선택 / ▸ SES는 자동 확장, SMTP 호환으로 통합 용이 / 【오답 체크】 (A)EC2 추가 서버는 인프라 관리 부담 증가, 오버헤드 해결 불가(85자) / (C)SNS는 알림 기반 발송, 대량 이메일 마케팅에 부족(75자) / (D)Auto Scaling 관리로 복잡도 증가, 비용 더 높음(70자) / 【시험 포인트】 ▸ '대량 이메일' + '비동기' + '운영 최소' = SES / ▸ SNS(알림) vs SES(마케팅 이메일) 명확 구분

해설

【핵심 용어】 ▸ S3 파일 게이트웨이—온프레미스 NFS 공유→S3 투명 연결 / ▸ 거의 실시간—이벤트 기반 자동 동기화 / 【정답 포인트】 ▸ '거의 실시간'→S3 파일 게이트웨이의 자동 동기화 메커니즘 / ▸ '최소 관리 오버헤드'→스크립트 작성/관리 불필요 / ▸ 기존 네트워크 공유 인터페이스 유지로 애플리케이션 변경 최소화 / 【오답 체크】 (A)DataSync 예약 작업은 매일 끝날 때만 실행, 실시간 동기화 불가(85자) / (C)DataSync API 자동화는 스크립트 개발/관리 필요, 오버헤드 증가(80자) / (D)SFTP 스크립트는 폴링 기반으로 지연 발생, 운영 복잡(75자) / 【시험 포인트】 ▸ '거의 실시간' = 이벤트 기반(폴링 X) / ▸ Storage Gateway = 온프레미스 연결 최적화 도구

해설

【핵심 용어】 ▸ S3 Intelligent-Tiering—AI 기반 자동 계층화 / ▸ 액세스 패턴 자동 분석—인간 개입 최소화 / 【정답 포인트】 ▸ '액세스 패턴을 알지 못함'→자동 분류 메커니즘 필수 / ▸ '페타바이트 규모'→수동 분석 비현실적, 자동 최적화 필요 / ▸ 여러 버킷에 일관된 정책 적용 가능 / 【오답 체크】 (B)스토리지 클래스 분석은 추천만 제공, 수동 결정 필요(80자) / (C)Glacier Instant Retrieval은 모든 데이터에 부적합, 검색 비용 발생(85자) / (D)One Zone-IA는 재해 복구성 떨어짐, 중요 데이터에 부족(75자) / 【시험 포인트】 ▸ '액세스 패턴 불명' = Intelligent-Tiering만 해결 / ▸ 자동 vs 수동 = 규모(페타바이트)에 따라 선택

해설

【핵심 용어】 ▸ CloudFront—정적 콘텐츠 CDN 캐싱 / ▸ RDS 읽기 복제본—읽기 부하 분산 / 【정답 포인트】 ▸ '정적 콘텐츠'→CloudFront로 엣지 서버 캐싱 / ▸ '페이지 로드 느림'→데이터베이스 읽기 병목 해결 필요 / ▸ 두 가지 병목(정적+동적) 동시 해결 / 【오답 체크】 (A)Redshift는 OLAP 분석 데이터베이스, OLTP 게임 점수 부적합(85자) / (C)S3는 정적 호스팅 기능, 성능 개선 안 함(60자) / (E)다중 AZ는 고가용성(HA), 성능 개선 아님(65자) / 【시험 포인트】 ▸ 정적 콘텐츠 느림 = CDN(CloudFront) / ▸ 읽기 병목 = 읽기 복제본 / ▸ OLTP vs OLAP 명확 구분

해설

【핵심 용어】 ▸ Compute Savings Plan—EC2+Lambda 포함 유연함 / ▸ VPC 연결 Lambda—프라이빗 서브넷에서 EC2 직접 접근 / 【정답 포인트】 ▸ 'EC2+Lambda'→Compute Savings Plan만 두 서비스 커버 / ▸ '1년+함수 증가'→장기 할인 극대화 필요 / ▸ '직접 네트워크 액세스'→VPC 연결은 프라이빗 배치 필수 / 【오답 체크】 (A)EC2 Instance Plan은 Lambda 할인 미포함, 비효율적(75자) / (B)퍼블릭 서브넷은 인터넷 경유 트래픽, 대기 시간 증가(80자) / (D)Lambda 서비스 VPC 유지는 EC2 프라이빗 서브넷 접근 불가(85자) / 【시험 포인트】 ▸ Compute Savings Plan > EC2 Instance Plan / ▸ VPC 연결 = 프라이빗 서브넷 배치

해설

【핵심 용어】 ▸ 신뢰 정책(Trust Policy)—역할 가정 권자 지정 / ▸ 계정 간 AssumeRole—개발 계정에서 프로덕션 역할 사용 / 【정답 포인트】 ▸ '개발 계정 사용자'→프로덕션 역할 가정(AssumeRole) 필요 / ▸ 신뢰 정책에 개발 계정 주체 추가 / ▸ 최소 권한: 필요한 권한만 부여, 관리자 권한 제외 / 【오답 체크】 (A)관리자 액세스는 최소 권한 원칙 위반(65자) / (C)퍼블릭 액세스 차단 해제는 보안 저하, 요구 불일치(75자) / (D)프로덕션 계정에 별도 사용자는 자격 증명 관리 복잡(80자) / 【시험 포인트】 ▸ 계정 간 접근 = 신뢰 정책 구성 / ▸ AssumeRole = 임시 권한 가정

해설

【핵심 용어】 ▸ SCP—Organizations 레벨에서 모든 계정 권한 제한 / ▸ EBS 기본 암호화—계정 속성에서 자동 활성화 / 【정답 포인트】 ▸ C)SCP로 ec2:Encrypted=false 거부→정책 제약 강제 / ▸ E)계정 기본 암호화 설정→사용자 개입 최소화 / ▸ 정책+기술 이중 방어로 암호화 보장 / 【오답 체크】 (A)콘솔 속성은 EBS 기본 암호화와 다름, 불완전(75자) / (B)IAM 권한 경계는 Organizations OU에 직접 연결 불가(80자) / (D)각 계정별 정책은 Organizations 범위 미달(65자) / 【시험 포인트】 ▸ Organizations = SCP가 최상위 제약 메커니즘 / ▸ EBS = 계정 기본 암호화로 기술적 기본값 설정

해설

【핵심 용어】 ▸ RDS 다중 AZ 클러스터—1기본+2읽기 복제본, 40초 이내 장애조치 / ▸ 리더 엔드포인트—읽기 트래픽 자동 분산 / 【정답 포인트】 ▸ 고가용성+빠른 장애조치→다중 AZ 클러스터만 가능 / ▸ 읽기 오프로드→리더 엔드포인트로 자동 분산 / ▸ 비용 효율: 추가 복제본 < 성능 이득 / 【오답 체크】 (A)다중 AZ 인스턴스+1복제본은 장애조치 60초 이상, 미달(85자) / (B)클러스터 아닌 다중 AZ 구성은 40초 기준 미충족(75자) / (C)보조 인스턴스 직접 읽기는 장애조치 영향 가능(75자) / 【시험 포인트】 ▸ RDS 클러스터 = 다중 읽기 복제본+빠른 장애조치 / ▸ 리더 엔드포인트 = 읽기 자동 분산

해설

【핵심 용어】 ▸ AWS Transfer Family—서버리스 SFTP/FTP 관리형 서비스 / ▸ EFS—높은 IOPS, 공유 스토리지, 파일 권한 제어 / 【정답 포인트】 ▸ 서버리스→Transfer Family로 EC2 관리 제거 / ▸ 고성능+권한→EFS는 IOPS 조절, 파일 레벨 권한 지원 / ▸ 퍼블릭 엔드포인트+보안 그룹으로 IP 제한 / 【오답 체크】 (A)EBS는 단일 인스턴스만 연결, 공유 불가(70자) / (C)S3는 파일 권한 관리 기능 부족, 사용자 권한 제어 어려움(75자) / (D)프라이빗 VPC 엔드포인트는 인터넷 소스 IP 제한 불가(80자) / 【시험 포인트】 ▸ Transfer Family = 서버리스 SFTP 호스팅 / ▸ EFS = 고IOPS 공유 스토리지 + 권한 제어

해설

【핵심 용어】 ▸ 불규칙 사용 패턴—며칠 유휴+갑작스런 대량 요청 / ▸ SQS+ECS—비동기 처리+메모리 효율 / 【정답 포인트】 ▸ SQS→비동기 API로 요청 버퍼링, 유휴시 자동 축소 / ▸ ECS→1GB 모델 메모리 로드 필요(Lambda 3GB 부족) / ▸ Auto Scaling→대기열 크기 기반 동적 확장 / 【오답 체크】 (A)Lambda 메모리 한계 및 SQS 비동기 구조 부재(70자) / (B)ALB는 동기 처리, App Mesh는 트래픽 관리만(75자) / (C)Lambda vCPU 스케일링 기능 없음, 지원 불가(70자) / 【시험 포인트】 ▸ 비동기+메모리 요구 = SQS+ECS 조합 / ▸ 불규칙 패턴 = Auto Scaling 기반 대기열 스케일

해설

【핵심 용어】 ▸ 자격 증명 기반 정책—User, Group, Role에 직접 연결 / ▸ 리소스 기반 정책—S3 버킷, SQS, Lambda 신뢰 정책 / 【정답 포인트】 ▸ A)역할(Role)→Identity-based policy 연결 가능 / ▸ B)그룹(Group)→Identity-based policy 연결 가능 / ▸ 둘 다 IAM 보안 주체 범주 / 【오답 체크】 (C)Organizations는 SCP 기반, 자격 증명 정책 미지원(75자) / (D,E)ECS/EC2 리소스는 리소스 기반 정책 사용, 자격 증명 정책 불가(85자) / 【시험 포인트】 ▸ 자격 증명 정책 = User, Group, Role만 / ▸ 리소스 정책 = AWS 리소스(EC2, S3 등)

해설

【핵심 용어】 ▸ 예약 인스턴스—24/7 상시 운영, 최대 할인 / ▸ 스팟 인스턴스—변동 워크로드, 최저가(90% 할인) / 【정답 포인트】 ▸ 프런트엔드 24/7→예약 인스턴스로 비용 극대화 / ▸ 백엔드 변동→스팟 인스턴스로 비용 최소화 / ▸ 예측 가능+가변 워크로드 동시 최적화 / 【오답 체크】 (A)Fargate는 컨테이너용, 애플리케이션 구조 변경 필요(75자) / (C)스팟은 중단 위험, 상시 프런트엔드에 부적합(70자) / (D)Fargate 비용은 스팟보다 비싸서 비효율적(70자) / 【시험 포인트】 ▸ 예측 가능 워크로드 = 예약 인스턴스 / ▸ 변동 워크로드 = 스팟 인스턴스

해설

【핵심 용어】 ▸ GP3—용량과 성능 독립 프로비저닝, 최적 가격 / ▸ io2/io1—초고성능 전용, 높은 비용 / 【정답 포인트】 ▸ 15,000 IOPS→io 시리즈 수준 불필요, GP3 충분 / ▸ 독립 프로비저닝→GP3만 용량/성능 분리 가능 / ▸ 비용 효율→GP3은 io2보다 약 50% 저렴 / 【오답 체크】 (A)GP2는 버스트만 IOPS 제한, 성능/용량 연동(80자) / (B,D)io2/io1은 매우 높은 비용, 극고성능 필요시만 적합(85자) / 【시험 포인트】 ▸ GP3 = 용량/성능 독립 조절, 중간 성능 / ▸ io2/io1 = 초고성능+높은 가용성, 높은 비용

해설

【핵심 용어】 ▸ Elastic Beanstalk—Apache Tomcat 기본 지원 / ▸ 부하 분산+롤링 배포—고가용성 자동 구성 / 【정답 포인트】 ▸ Tomcat→Beanstalk 사전 구성 환경 완벽 지원 / ▸ 고가용성→부하 분산+롤링 배포 기본 포함 / ▸ 운영→자동 스케일링, CloudWatch 통합 / 【오답 체크】 (A)Lambda는 Tomcat 미지원, 15분 제한 있음(70자) / (C)ElastiCache는 캐시, 데이터베이스 대체 불가(70자) / (D)수동 구성은 운영 부담 높음, 시간 소모(70자) / 【시험 포인트】 ▸ Tomcat+HA = Elastic Beanstalk 최적 / ▸ 롤링 배포 = 무중단 배포 구현

해설

【핵심 용어】 ▸ IAM 역할(실행 역할)—Lambda 자동 신뢰 관계 부여 / ▸ 자격 증명 보관 금지—환경변수/코드에 키 저장 위험 / 【정답 포인트】 ▸ 역할 기반→Lambda→DynamoDB 신뢰 체인 / ▸ 자동 관리→자격 증명 순환 불필요 / ▸ 감시→CloudTrail에서 역할 사용 추적 / 【오답 체크】 (A)환경변수 저장은 보안 위험, 노출 쉬움(75자) / (C)Parameter Store 좋으나 역할이 표준 방식, 복잡(80자) / (D)DynamoDB를 신뢰 서비스로 설정 불가(65자) / 【시험 포인트】 ▸ Lambda 권한 = 실행 역할(IAM Role) / ▸ 절대 금지 = 환경변수에 자격 증명 저장

해설

【핵심 용어】 ▸ Allow 명시문—기본 권한 허용(us-east-1 EC2 *) / ▸ 조건부 Deny—MFA 없으면 특정 작업 거부 / 【정답 포인트】 ▸ 기본→Allow ec2:* in us-east-1 / ▸ 제약→StopInstances/TerminateInstances는 MFA 필수 / ▸ 다른 작업→MFA 없어도 허용 / 【오답 체크】 (A)조건부 거부 무시, MFA 관계없음(60자) / (B)반대 해석, MFA 없으면 거부 아님(65자) / (C)리전 범위 확대, 정책에 명시 없음(65자) / 【시험 포인트】 ▸ Allow+Deny 조건 = Deny가 최종 결정 / ▸ 명시적 거부 = 다른 Allow 무효화

해설

【핵심 용어】 ▸ RDS Snapshot → Aurora 직접 변환 지원 ▸ mysqldump 덤프 → S3 경유 필수 【정답 포인트】 ▸ (A) RDS MySQL 스냅샷 직접 → Aurora MySQL로 변환 가능 ▸ (C) 논리적 덤프 → S3 업로드 후 Aurora 로드 【오답 체크】 (B) 스냅샷→S3 중간 단계 불필요, A가 더 효율적 (D) DMS로 스냅샷 마이그레이션은 과도한 리소스 사용 (E) DMS로 덤프 처리는 간단 덤프는 직접 로드 효율적 【시험 포인트】 ▸ 동종 엔진(MySQL→Aurora MySQL) = 스냅샷 직접 변환 ▸ 논리적 백업(mysqldump) = S3 경유 필수 ▸ Aurora 마이그레이션 = 두 가지 경로 모두 가능