정답 · 해설

해설

【핵심 용어】 ▸ 다중 AZ 복제 그룹—여러 AZ에 Primary/Replica 분산 배치 ▸ Redis 클러스터—데이터를 샤드로 분산, 수평 확장 가능 ▸ 장애 격리—노드 수준(Replica)과 지역 수준(AZ) 별도 대응 【정답 포인트】 ▸ "노드 수준 고가용성"→Primary/Replica 구조로 노드 장애 극복 ▸ "지역 수준 고가용성"→다중 AZ 배치로 AZ 장애 극복 ▸ "성능/데이터 손실 없음"→자동 페일오버로 무중단 보장 【오답 체크】 (B) AOF 파일—데이터 영속성만 제공, 고가용성 아님 (C) 클러스터 + 읽기 복제본—모드 변경으로 복잡도 증가, 단순 복제 그룹으로 충분 (D) Auto Scaling—자동 확장만 하며 장애 대응 아님 【시험 포인트】 ▸ 패턴: 다중 계층 장애(노드+AZ)→다중 AZ 복제 그룹 ▸ 함정: 클러스터 모드가 고급처럼 보이나, 단순 요구사항은 복제 그룹으로 충분

해설

【핵심 용어】 ▸ Amazon ElastiCache for Redis — 인메모리 캐시, 빠른 읽기/쓰기·위치 데이터 갱신에 적합 ▸ Amazon DynamoDB Accelerator (DAX) — DynamoDB 전용 캐시로 RDS 앞단 사용 불가 ▸ RDS Read Replica / Multi-AZ — 읽기 확장·가용성용이나 고빈도 쓰기 병목 해소엔 한계 【정답 포인트】 ▸ "실시간 위치 추적 + 빠른 갱신·조회" + "피크 시 읽기/쓰기 성능 부족" → 인메모리 캐시로 DB 부하 완화 ▸ RDS 앞에 ElastiCache for Redis를 두어 잦은 위치 갱신/조회를 캐시에서 처리 → 성능 개선 【오답 체크】 (A) Multi-AZ 복원은 가용성용이며 성능(쓰기 처리량) 향상과는 무관. (B) OpenSearch로 마이그레이션은 검색/분석용이며 대규모 재설계·부적합. (C) DAX는 DynamoDB 전용 캐시로 RDS PostgreSQL 앞에 배치 불가. 【시험 포인트】 RDS 읽기/쓰기 병목 + 저지연 요구 → ElastiCache for Redis. DAX는 DynamoDB 전용.

해설

【핵심 용어】 ▸ DynamoDB Deletion Protection — 테이블 실수 삭제 방지 설정, 켜두면 삭제 명령 차단 ▸ DynamoDB Point-in-Time Recovery (PITR) — 삭제 후 복구용이나 삭제 자체는 못 막음 ▸ CloudTrail + EventBridge + Lambda — 자동 복구 파이프라인이나 구축·유지 오버헤드 큼 【정답 포인트】 ▸ "실수로 테이블 삭제 방지" + "최소 운영 오버헤드" → 삭제 자체를 막는 Deletion Protection이 정답 ▸ 설정 한 번으로 삭제 명령을 차단해 재발 방지, 추가 인프라 불필요 【오답 체크】 (A) CloudTrail/EventBridge/Lambda 자동 복구는 개발·운영 부담이 큰 사후 대응. (B) 백업·수동 복구 계획은 데이터 손실 이후 복구일 뿐, 수동 개입 필요. (D) PITR은 삭제 후 복구 수단이지 삭제 발생 자체를 방지하지 못함. 【시험 포인트】 "삭제 방지"가 요구사항이면 사후 복구(PITR/백업)가 아니라 Deletion Protection 선택.

해설

【핵심 용어】 ▸ Predictive Scaling(예측 스케일링) — 과거 일간/주간 워크로드 패턴을 학습해 미리 용량 확보 ▸ Target Tracking(대상 추적) 동적 스케일링 — 지표(CPU 등)를 목표값에 맞춰 실시간 조정 ▸ Step/Simple Scaling, Scheduled Scaling — 임계값·시간 기반이나 예측 기능 없음 【정답 포인트】 ▸ "일간·주간 과거 추세 분석 + 예측에 따라 사전 확보" → Predictive Scaling ▸ "실시간 사용률 변화에도 대응" → Target Tracking 동적 스케일링 병행 → 예측+실시간 조합이 정답 【오답 체크】 (A) Step scaling(CPU 기반)은 반응형이며 과거 추세 예측 기능이 없음. (C) Scheduled scaling은 고정 일정 기반이라 실시간 변동·예측 학습에 대응 못함. (D) Simple scaling + 쿨다운 조정은 예측·추세 분석과 무관한 단순 반응형. 【시험 포인트】 "과거 추세 예측 + 실시간 대응" 동시 요구 → Predictive Scaling + Target Tracking.

해설

【핵심 용어】 ▸ Amazon ElastiCache for Redis — 반복 조회 결과를 인메모리 캐시, DB 읽기 부하 오프로딩·비용 효율 ▸ Aurora Read Replica / Auto Scaling — 읽기 확장이나 복제본 추가는 비용 증가·반복읽기엔 비효율 ▸ Multi-writer — 쓰기 확장용으로 반복 읽기 병목과 무관 【정답 포인트】 ▸ "반복되는 동일 읽기(배송 상세)" + "가장 비용 효율적으로 완화" → 캐시로 반복 조회를 흡수 ▸ 애플리케이션과 DB 사이에 ElastiCache for Redis를 두면 복제본 추가 없이 반복 읽기 부하 제거 【오답 체크】 (B) 읽기 복제본 추가는 인스턴스 비용이 늘고 이미 한계, 반복 읽기엔 캐시가 더 효율적. (C) Aurora Auto Scaling(복제본)도 복제본 비용을 계속 발생시켜 비용 효율성 낮음. (D) 멀티 라이터는 쓰기 확장 기능으로 반복 읽기 병목 해소와 무관. 【시험 포인트】 "동일 읽기 반복 + 비용 효율" → ElastiCache 캐싱. 복제본 추가는 비용 대비 비효율.

해설

【핵심 용어】 ▸ DynamoDB Eventually Consistent Read(기본) — 최근 쓰기가 아직 반영 안 될 수 있음(구 데이터 반환 가능) ▸ DynamoDB Strongly Consistent Read — 항상 최신 쓰기 반영값 반환(약간의 지연·비용 증가) ▸ GSI — 대체 조회용 인덱스이나 GSI 자체는 결과적 일관성만 지원 【정답 포인트】 ▸ "최신 데이터가 반환되지 않음 + 지연은 허용 범위" → 기본 결과적 일관성 때문 ▸ 강력한 일관성 읽기(Strongly Consistent Read) 요청으로 항상 최신값 반환 → 정답 【오답 체크】 (A) DynamoDB에는 "읽기 복제본" 개념이 없음(잘못된 표현). (B) GSI는 결과적 일관성만 제공해 최신 데이터 문제를 해결하지 못함. (D) 결과적 일관성 읽기는 현재 기본값으로, 오히려 구 데이터 문제의 원인. 【시험 포인트】 DynamoDB에서 "최신 데이터 안 나옴" → 강력한 일관성 읽기(Strongly Consistent Read).

해설

【핵심 용어】 ▸ AWS WAF — SQL injection·XSS 등 L7 웹 공격을 룰로 차단하는 웹 애플리케이션 방화벽 ▸ RDS Parameter Group — DB 엔진 파라미터(보안 설정 포함) 관리 ▸ Security Group / NACL — L3/L4 네트워크 접근 제어, SQL injection 같은 L7 공격 방어 불가 ▸ AWS Network Firewall — VPC 네트워크 트래픽 필터링용, 웹 애플리케이션 공격 특화 아님 【정답 포인트】 ▸ "SQL injection 등 웹 기반 공격 차단" + "최소 운영 오버헤드" → 관리형 AWS WAF ▸ 애플리케이션 앞에 WAF 배치 + RDS 파라미터 그룹으로 DB 보안 설정 → 요구 충족 【오답 체크】 (A) SG/NACL은 IP/포트 기반 L4 제어라 SQL injection 등 L7 공격을 막지 못함. (C) Network Firewall은 네트워크 계층 필터링용으로 웹 공격 방어에 특화되지 않음. (D) DB 계정 분리는 최소 권한 관행(이미 적용)이며 SQL injection 자체를 차단하지 못함. 【시험 포인트】 SQL injection·XSS 등 웹 공격 차단 → AWS WAF(L7). 네트워크 방화벽/SG는 L4.

해설

【핵심 용어】 ▸ Amazon GuardDuty RDS Protection — Aurora 로그인 활동을 분석해 비정상·실패 로그인 등 위협 탐지 ▸ AWS Organizations 위임 관리자 — 조직 전체 멤버 계정에 GuardDuty 일괄 활성화 ▸ CloudTrail — API 호출 감사이나 DB 내부 로그인 시도는 캡처 안 함 【정답 포인트】 ▸ "악성 활동 방지 + 비정상 실패/미완료 로그인 식별" + "가장 운영 효율적" → GuardDuty의 RDS Protection ▸ 조직 멤버 계정에 활성화하면 별도 로그 파이프라인 없이 자동 위협 탐지 → 최소 운영 【오답 체크】 (A) SCP는 권한 경계 정책일 뿐 로그인 시도 탐지 기능이 없음. (C) Aurora general log를 CloudWatch/S3로 내보내면 수집·분석 파이프라인을 직접 구축해야 해 오버헤드 큼. (D) DB 이벤트를 CloudTrail로 중앙화하는 방식도 분석 로직 직접 구현 필요, 비효율. 【시험 포인트】 DB 대상 비정상 로그인·위협 탐지 자동화 → GuardDuty RDS Protection.

해설

【핵심 용어】 ▸ AWS Direct Connect Gateway — 여러 리전의 VPC(가상 프라이빗 게이트웨이)를 하나의 Direct Connect에 연결하는 글로벌 관문 ▸ Virtual Private Gateway (VGW) — VPC측 Direct Connect/VPN 종단점 ▸ Inter-Region VPC Peering — VPC 간 사설 통신이나 데이터센터 연결·확장성엔 부적합 【정답 포인트】 ▸ "두 리전 VPC + 두 데이터센터 연결" + "확장성 + 운영 오버헤드 감소" → Direct Connect Gateway ▸ CIDR 비중첩 전제하에 각 리전 VGW를 Direct Connect Gateway에 연결 → 리전 교차 연결을 확장성 있게 통합 【오답 체크】 (A) Inter-Region VPC 피어링은 VPC끼리만 연결, 데이터센터 통합·확장성 요구를 충족 못함. (B) 프라이빗 VIF는 동일 계정/리전 범위 제약이 있어 다중 리전 VPC 통합에 부적합. (C) EC2 기반 풀메시 VPN + CloudHub는 자체 관리 부담이 커 운영 오버헤드 증가. 【시험 포인트】 멀티 리전 VPC + 데이터센터를 Direct Connect로 통합·확장 → Direct Connect Gateway.

해설

【핵심 용어】 ▸ S3 Same-Region Replication (SRR) — 동일 리전 내 버킷 간 자동 복제, 관리형·저운영 ▸ S3 Cross-Region Replication — 다른 리전 복제(여기선 리전 이탈 금지라 부적합) ▸ Lambda/스크립트 복사 — 직접 구현·운영 필요, 오버헤드↑ 【정답 포인트】 ▸ "여러 계정 로그를 단일 S3로 중앙화 + us-west-2 이탈 금지 + 최소 운영·최저 비용" → S3 SRR ▸ 동일 리전 자동 복제로 코드 개발 없이 중앙 버킷에 집계 → 관리형·비용 효율 【오답 체크】 (A) S3 Lifecycle 정책은 버킷 간 객체 "복사" 기능이 없음(스토리지 클래스 전환/만료용). (C) 매일 PutObject로 전체 복사하는 스크립트는 개발·운영 부담 + 중복 전송 비용. (D) Lambda 트리거 복사는 계정별 함수 개발·유지 오버헤드 발생. 【시험 포인트】 동일 리전 다계정 로그 중앙화 + 최소 운영 → S3 Same-Region Replication.

해설

【핵심 용어】 ▸ S3 양방향(Two-way) 복제 — 3개 리전 버킷 간 상호 복제로 어디에 올려도 전 리전에 반영 ▸ S3 Multi-Region Access Point (MRAP) — 단일 글로벌 엔드포인트로 가장 가까운 리전 버킷에 라우팅 ▸ 단방향 복제 — 한 소스에서만 전파되어 원격 리전 업로드가 원본에 역전파 안 됨 【정답 포인트】 ▸ 업로드·스트리밍 모두 근거리 리전에서 처리해야 하므로, 어느 리전에 올려도 전 리전 동기화 필요 → 3개 리전 양방향 복제(C) ▸ 앱 변경 최소화 + 업로드·스트리밍 모두 저지연 → MRAP ARN을 업로드·스트리밍 모두에 사용(E) 【오답 체크】 (A) us-east-2 단방향 복제는 원격 리전에서의 업로드가 다른 리전으로 전파되지 않음. (B) 순차 단방향 복제(us→eu→ap)도 원격 업로드 역전파 불가로 근거리 저지연 미달. (D) 스트리밍만 MRAP 사용하고 업로드는 미변경 → 업로드 저지연 요구를 충족 못함. 【시험 포인트】 전 리전 어디서든 업로드+조회 저지연 → 양방향 복제 + 업로드·스트리밍 모두 MRAP 사용.

해설

【핵심 용어】 ▸ S3 Transfer Acceleration — 엣지 로케이션 경유로 S3 업로드 지연 최소화(업로드 가속) ▸ Amazon CloudFront — 콘텐츠 다운로드/전송(캐싱) 가속용, 업로드 최적화 목적 아님 ▸ S3 리전 배치 — 업로드 지역이 리전과 다를 수 있어 원거리 업로드는 여전히 느림 【정답 포인트】 ▸ "콘텐츠 업로드 지연 최소화(LOWEST latency for uploads)" → S3 Transfer Acceleration ▸ 전 세계 사용자의 S3 업로드를 엣지 경유로 가속 → 업로드 저지연 요구 정확히 충족 【오답 체크】 (A) CloudFront는 다운로드 배포 가속이 주목적, 업로드 최적화 도구가 아님. (C) EC2로 먼저 업로드 후 S3 복사는 추가 홉·운영 오버헤드로 지연·복잡도 증가. (D) 다중 CloudFront 배포는 전송(다운로드)용이며 업로드 지연을 줄이지 못함. 【시험 포인트】 "업로드 저지연" → S3 Transfer Acceleration. CloudFront는 다운로드/전송 가속.

해설

【핵심 용어】 ▸ Amazon SNS — 팬아웃(pub/sub) + 메시지 필터링(구독 필터 정책)으로 필요한 메시지만 전달 ▸ Amazon SQS — 각 대상 Lambda의 버퍼 큐로 안정적 폴링·처리 ▸ Amazon EventBridge — 이벤트 라우팅 가능하나 여기선 SNS+SQS 팬아웃이 표준 저오버헤드 패턴 【정답 포인트】 ▸ "여러 대상 Lambda로 팬아웃 + 필요한 메시지만 수신(필터링) + 최소 운영" → SNS 토픽 + 구독 SQS 큐 + 필터 정책 ▸ SNS 메시지 필터링으로 각 큐가 필요한 메시지만 받고, Lambda가 각 SQS를 폴링 → 요구 충족 【오답 체크】 (B) EventBridge도 가능하나 문항은 SNS 필터링 팬아웃을 최적 저오버헤드 패턴으로 봄. (C) MSK(Kafka)는 클러스터 운영 부담이 크고 "최소 운영"에 반함, Lambda 직접 발행 구조도 부정확. (D) 다중 SQS 직접 전송은 팬아웃/필터링 로직을 애플리케이션이 직접 구현해야 함. 【시험 포인트】 "팬아웃 + 메시지 필터링 + 최소 운영" → SNS(+SQS 구독). 필터링은 SNS의 핵심 기능.

해설

【핵심 용어】 ▸ S3 Inventory 보고서 — 버킷 객체 목록·암호화 상태를 파일로 제공(미암호화 객체 필터링 가능) ▸ S3 Batch Operations — 목록 기반 대량 객체 일괄 작업(기존 객체 암호화 등) ▸ SSE-C(고객 제공 키) — 고객이 키를 제공하는 서버 측 암호화 방식 ▸ S3 기본 암호화 — 신규 업로드 객체에 기본 적용될 암호화 지정 【정답 포인트】 ▸ "고객 제공 키(SSE-C)로 기존 + 향후 객체 모두 암호화" 요구 ▸ S3 Inventory로 미암호화 객체 목록 확보 → S3 Batch Operations로 기존 객체 SSE-C 암호화, 기본 암호화도 SSE-C로 설정 → 기존·미래 모두 커버 【오답 체크】 (B) SSE-KMS는 고객 제공 키(SSE-C)가 아님 + Storage Lens는 버킷 지표용으로 미암호화 객체 목록화에 부적합. (C) SSE-KMS 사용 + AWS Batch(잘못된 도구)로 요구(SSE-C)와 불일치. (D) 기존 미암호화 객체를 일괄 암호화하는 단계가 빠져 기존 객체 커버 불가. 【시험 포인트】 기존 대량 객체 암호화 → S3 Inventory + S3 Batch Operations. 키 요구가 고객 제공이면 SSE-C.

해설

【핵심 용어】 ▸ Amazon Route 53 Public Hosted Zone — 인터넷 공개 도메인 DNS 레코드를 호스팅하는 관리형 서비스 ▸ 존 파일 임포트(Import zone file) — 기존 제공자의 BIND 존 파일을 가져와 빠르게 마이그레이션 ▸ Private Hosted Zone — VPC 내부 전용 DNS로 공개 웹사이트엔 부적합 【정답 포인트】 ▸ "복원력 있는 관리형 DNS로 신속 마이그레이션 + AWS에서 실행" → Route 53 퍼블릭 호스팅 영역 생성 ▸ 기존 제공자의 존 파일을 임포트하면 레코드를 일괄 이전해 빠르게 전환 → 요구 충족 【오답 체크】 (B) 프라이빗 호스팅 영역은 VPC 내부용으로 공개 웹사이트 도메인 해석에 부적합. (C) Simple AD/AD는 디렉터리 서비스로 공개 DNS 호스팅 목적과 무관. (D) Route 53 Resolver 인바운드 엔드포인트는 하이브리드 DNS 쿼리 전달용이지 권한 DNS 호스팅 이전이 아님. 【시험 포인트】 관리형 공개 DNS로 이전 → Route 53 퍼블릭 호스팅 영역 + 존 파일 임포트.

해설

【핵심 용어】 ▸ AWS AppConfig — 애플리케이션 구성(설정)을 안전하게 관리·배포하는 관리형 서비스 ▸ AWS Secrets Manager — DB 자격증명 등 비밀 저장·자동 교체·검색을 관리형으로 제공 ▸ SSM Parameter Store — 파라미터/비밀 저장 가능하나 자동 교체는 Secrets Manager가 우위 【정답 포인트】 ▸ "앱 구성 관리 + 자격증명 안전 저장·검색 + 최소 관리 오버헤드" → AppConfig(구성) + Secrets Manager(자격증명) ▸ 각 목적에 맞는 관리형 서비스 조합으로 개발·운영 부담 최소화 【오답 체크】 (B) Lambda는 구성 저장소가 아님(용도 오용). (C) S3에 암호화 파일로 구성·자격증명을 직접 관리하면 교체·접근제어 부담이 커짐. (D) RDS에 자격증명을 저장하는 것은 비밀 관리 도구가 아니며 부적절. 【시험 포인트】 앱 구성 → AppConfig, 비밀·자격증명 → Secrets Manager(자동 교체).

해설

【핵심 용어】 ▸ RDS 전송 중 암호화(SSL/TLS) — AWS 제공 루트 CA 인증서를 클라이언트가 사용해 DB 연결 암호화 ▸ 저장 데이터 암호화(KMS) — 디스크 암호화용으로 전송 중 암호화와 별개(이미 적용됨) ▸ IAM DB 인증 — 인증 방식이지 전송 암호화 자체를 보장하지 않음 【정답 포인트】 ▸ "전송 중 데이터 암호화" 요구, 저장 암호화(KMS)는 이미 활성 ▸ AWS가 제공하는 루트 인증서를 다운로드해 모든 RDS 연결에 사용 → SSL/TLS로 전송 구간 암호화 【오답 체크】 (A) IAM DB 인증은 로그인 인증용이며 전송 데이터 암호화를 제공하지 않음. (B) 자체 서명 인증서는 RDS 표준 TLS 검증 체계와 맞지 않아 권장되지 않음. (C) 스냅샷 복원 + 저장 암호화는 이미 있는 at-rest 이슈로 전송 중 암호화와 무관. 【시험 포인트】 RDS 전송 중 암호화 → AWS 제공 루트 CA 인증서로 SSL/TLS 연결.

해설

【핵심 용어】 ▸ Network Load Balancer (NLB) — 정적 IP(가용 영역별 Elastic IP 연결) 지원, 고정 IP 필요 시 사용 ▸ Application Load Balancer (ALB) — 고정 IP 미지원(가변 DNS 이름만 제공) ▸ Elastic IP — 고정 공인 IP, 클라이언트 방화벽 허용 목록에 등록 가능 【정답 포인트】 ▸ "클라이언트 방화벽이 허용된 IP만 접근 가능 = 고정 IP 필요" → Elastic IP를 붙일 수 있는 NLB ▸ NLB + Elastic IP로 고정 IP를 제공해 방화벽 화이트리스트 요구 충족 【오답 체크】 (B) ALB는 Elastic IP를 연결할 수 없어 고정 IP 요구를 충족 못함. (C) Route 53 A 레코드로 EIP를 가리켜도 로드밸런싱·확장 아키텍처 요구(ELB)를 대체 못함. (D) EC2 프록시는 단일 장애점·관리 부담을 만들고 관리형 ELB 요구에 반함. 【시험 포인트】 로드밸런서에 고정 IP 필요 → NLB + Elastic IP (ALB는 고정 IP 불가).

해설

【핵심 용어】 ▸ Cluster Placement Group — 동일 AZ 내 인스턴스를 물리적으로 근접 배치해 노드 간 최저 지연·고대역폭 제공 ▸ Enhanced Networking(향상된 네트워킹, ENA/SR-IOV) — 높은 PPS·낮은 지연·저지터 네트워크 성능 제공 ▸ EBS 최적화 / 다중 ENI / 계정 분리 — 스토리지·인터페이스·거버넌스용으로 노드 간 지연과 무관 【정답 포인트】 ▸ "노드 간 최저 지연" 요구 → 향상된 네트워킹(A)으로 인스턴스 네트워크 성능 극대화 ▸ 클러스터 배치 그룹(C)으로 인스턴스를 근접 배치해 노드 간 지연 최소화 → 두 조합이 정답 【오답 체크】 (B) 별도 계정 분리는 거버넌스 목적이며 지연에 오히려 악영향/무관. (D) 다중 ENI는 인터페이스 추가일 뿐 노드 간 지연을 낮추지 않음. (E) EBS 최적화는 스토리지 I/O 성능용으로 노드 간 네트워크 지연과 무관. 【시험 포인트】 노드 간 최저 지연 → Cluster Placement Group + Enhanced Networking.

해설

【핵심 용어】 ▸ AWS DataSync — 대량·다수 소규모 파일을 SMB/NFS에서 AWS 스토리지로 고속·관리형 전송 ▸ Amazon FSx for Windows File Server — SMB 프로토콜 지원 관리형 파일 스토리지(기존 SMB 앱 무변경 접근) ▸ FSx for Lustre — HPC/고성능 컴퓨팅용으로 일반 SMB 파일 공유엔 부적합 【정답 포인트】 ▸ "SMB 기반 + 앱 변경 없이 접근 + 수백만 소파일 + 최소 운영" → DataSync로 FSx for Windows File Server 이전 ▸ FSx for Windows는 SMB를 그대로 지원해 앱 수정 불필요, DataSync가 복잡 디렉터리·소파일 전송을 관리형으로 처리 【오답 체크】 (A) Direct Connect로 S3 이전은 객체 스토리지라 SMB 파일 접근 방식과 달라 앱 변경 필요. (B) FSx for Lustre는 HPC용으로 SMB 파일 공유 워크로드에 부적합. (D) Direct Connect + Volume Gateway는 블록 스토리지라 SMB 파일 액세스 요구와 불일치. 【시험 포인트】 SMB 파일 서버 이전 + 앱 무변경 → DataSync + FSx for Windows File Server.