정답 · 해설

해설

【핵심 용어】 ▸ S3 Intelligent-Tiering — 액세스 패턴에 따라 계층 자동 이동, 검색 요금 없음, 즉시 가용 ▸ S3 Standard-IA — 저빈도 액세스, 검색 요금 발생 ▸ S3 Glacier / S3 Select — 아카이브, 즉시 액세스 아님 【정답 포인트】 ▸ "무작위 액세스 + 비용 절감 + 자주 접근하는 객체 즉시 가용 + 운영 효율 최고" → Intelligent-Tiering 수명주기 규칙으로 액세스 패턴에 맞춰 자동 계층화 【오답 체크】 (B) Glacier는 즉시 가용이 아니고 S3 Select도 무작위 애플리케이션 액세스에 부적합. (C) 스토리지 분석 + 수동 수명주기 규칙은 운영 부담 크고 IA 검색 요금 발생. (D) Lambda로 액세스 시 계층 전환은 커스텀 코드로 복잡, 운영 효율 낮음. 【시험 포인트】 "예측 불가한 무작위 액세스 + 비용 절감 + 즉시 가용" → S3 Intelligent-Tiering.

해설

【핵심 용어】 ▸ Amazon Neptune — 완전관리형 그래프 DB(정점·간선), 다단계 관계 탐색에 최적 ▸ 다대다 관계(연결) / 상호 연결 탐색 — 그래프 모델의 전형적 사례 ▸ Athena/QuickSight/RDS — 관계형·분석·시각화 도구, 깊은 그래프 순회에 비효율 【정답 포인트】 ▸ "사용자 프로필 + 다대다 연결 + 5단계까지 상호 연결 탐색 + 성능 효율" → 그래프 순회에 최적인 Neptune에 정점·간선으로 저장 【오답 체크】 (A) S3 + Athena SQL JOIN은 다단계 관계 탐색에 비효율적. (C) S3 + QuickSight는 시각화 도구로 관계 탐색 부적합. (D) RDS SQL JOIN 5단계는 조인 폭증으로 성능 저하. 【시험 포인트】 "다대다 관계 + 다단계 연결 탐색" → 그래프 DB Amazon Neptune.

해설

【핵심 용어】 ▸ AWS Site-to-Site VPN — 인터넷 위 IPsec 터널, 빠른 구성·저비용, 소량 트래픽에 적합 ▸ AWS Direct Connect — 전용 회선, 고대역폭이나 구축에 시간·비용 큼 ▸ Client VPN — 개별 사용자 원격 접속용, 사이트 간 연결 아님 【정답 포인트】 ▸ "안전한 연결 + 저대역폭·소량 트래픽 + 빠른 구성 + 가장 비용 효율" → Site-to-Site VPN이 즉시 구성 가능하고 저렴 【오답 체크】 (A) Client VPN은 개별 클라이언트 접속용으로 사이트 간 연결 목적과 다름. (B) Direct Connect는 회선 프로비저닝에 수 주 소요, 비용도 큼. (C) 배스천 호스트는 관리 접속용일 뿐 안전한 네트워크 연결 수단 아님. 【시험 포인트】 "소량 트래픽 + 빠르고 저렴한 안전 연결" → Site-to-Site VPN.

해설

【핵심 용어】 ▸ AWS Transfer Family (SFTP) — 완전관리형 SFTP 엔드포인트로 S3 연동 ▸ AWS Directory Service + AD Connector — 온프레미스 Microsoft AD를 ID 공급자로 연결 ▸ S3 File Gateway — SMB/NFS 프로토콜용, SFTP 아님 【정답 포인트】 ▸ "SFTP 유지 + S3 저장 + 온프레미스 AD 자격 증명 + 인증·파일 접근 방식 유지 + 최소 운영" → Transfer Family SFTP + Directory Service(AD Connector로 온프레미스 AD 연결) 【오답 체크】 (A) S3 File Gateway는 SMB 공유로 SFTP 프로토콜을 제공하지 않음. (B) EC2 Auto Scaling으로 자체 SFTP 운영은 관리 부담 큼. (D) Transfer Family를 쓰되 온프레미스 AD 연결에 필요한 AD Connector 구성이 빠져 자체 관리 AD와 통합이 불완전. 【시험 포인트】 "관리형 SFTP + 온프레미스 AD 인증" → Transfer Family + AD Connector.

해설

【핵심 용어】 ▸ Amazon EventBridge — 이벤트 버스 + 규칙 라우팅, input transformer로 대상별 필요한 데이터만 변환 전달 ▸ 느슨한 결합(loose coupling) — 검증 단계 독립성, 향후 변경 수용 ▸ SQS/SNS — 큐/펍섭, 데이터 부분 전달·변환 특성 제한 【정답 포인트】 ▸ "각 검증 단계 Lambda가 주문 이벤트의 필요한 부분집합만 접근 + 느슨한 결합" → EventBridge 이벤트 버스 + 단계별 규칙 + input transformer로 필요한 데이터만 각 대상에 전달 【오답 체크】 (A) 단계별 SQS 큐 + 변환 Lambda는 구성 요소가 많아 운영 부담 큼. (B) SNS 메시지 필터링은 속성 기반 전달 여부만 결정, 본문을 부분집합으로 변환 전달하지 못함. (D) 동기 병렬 호출은 함수 간 강한 결합을 유발해 요건과 반대. 【시험 포인트】 "대상별 필요한 데이터만 전달 + 느슨한 결합" → EventBridge + input transformer.

해설

【핵심 용어】 ▸ Amazon Aurora MySQL Multi-AZ + read replica — 읽기 부하를 리더 엔드포인트로 분산 ▸ 리더 엔드포인트 — 읽기 전용 복제본으로 보고서 쿼리 오프로드 ▸ Multi-AZ 대기(standby) — 장애 조치용, 읽기 트래픽 처리 불가 【정답 포인트】 ▸ "신규 입력 성능 저하 원인 = 근무 시간 실시간 보고서" → 보고서 쿼리를 읽기 복제본(리더 엔드포인트)으로 분리하면 쓰기 성능 회복 【오답 체크】 (A) DynamoDB 리팩터링은 큰 변경이며 MySQL 요건과 맞지 않음. (B) 더 큰 EC2 DB는 보고서 부하를 분리하지 못해 근본 해결 아님. (D) Multi-AZ 백업/대기 인스턴스는 읽기 쿼리 엔드포인트로 사용 불가. 【시험 포인트】 "읽기(보고서)가 쓰기 성능 저해" → read replica + 리더 엔드포인트로 읽기 오프로드.

해설

【핵심 용어】 ▸ Amazon S3 interface endpoint (PrivateLink) — Direct Connect 프라이빗 VIF 경유로 온프레미스에서 S3에 프라이빗 접근 ▸ Direct Connect — 온프레미스와 AWS 전용 연결 ▸ 게이트웨이 엔드포인트 — VPC 내부 전용, 온프레미스에서 직접 사용 불가 【정답 포인트】 ▸ "온프레미스 인터넷 없음 + Direct Connect + S3 사용 + 가장 비용 효율" → VPC + S3 인터페이스 엔드포인트로 트래픽을 프라이빗하게 라우팅 【오답 체크】 (A) 퍼블릭 VIF는 AWS 퍼블릭 IP로 트래픽이 노출되어 보안 요건상 인터페이스 엔드포인트만큼 프라이빗하지 않음. (B) NAT 게이트웨이는 인터넷 경로가 필요하고 비용도 추가됨. (D) 온프레미스와 Direct Connect 간 VPC 피어링은 존재하지 않는 구성. 【시험 포인트】 "온프레미스에서 인터넷 없이 S3 프라이빗 접근" → S3 인터페이스 엔드포인트 + Direct Connect.

해설

【핵심 용어】 ▸ Route 53 multivalue answer routing — 상태 확인 기반으로 정상 레코드만 반환, 트래픽 분산 ▸ 상태 확인(health check) — 비정상 리전 제외 ▸ simple routing — 상태 확인 미지원 【정답 포인트】 ▸ "두 리전에 트래픽 분산 + DR + 비정상 리전에서 서비스 안 함" → multivalue answer 라우팅이 상태 확인으로 정상 리전만 응답하며 분산 【오답 체크】 (A) simple 라우팅은 상태 확인이 없어 비정상 리전을 제외하지 못함. (C) 단일 리전 ALB의 대상 그룹은 다른 리전 EC2 인스턴스 ID를 등록할 수 없음. (D) IP 기반 대상은 교차 리전 가능하나 단일 ALB가 단일 장애점이며 리전 분산·DR 요건에 부적합. 【시험 포인트】 "다중 리전 분산 + 비정상 제외" → Route 53 multivalue answer + 상태 확인.

해설

【핵심 용어】 ▸ Amazon EFS — 여러 EC2·다중 AZ에서 동시 마운트 가능한 공유 파일 시스템 ▸ EBS 볼륨/스냅샷 — 단일 인스턴스 연결(다중 동시 마운트·다중 AZ 공유 부적합) ▸ 인스턴스 스토어 — 휘발성, 공유 불가 【정답 포인트】 ▸ "인스턴스 간 전송 없이 + 여러 EC2·다중 AZ에서 25GB+ 파일 공유 접근" → EFS를 모든 인스턴스에 마운트하면 공유 파일 시스템으로 해결 【오답 체크】 (A) S3로 이전은 파일 접근 방식이 바뀌고 파일 시스템 형태 공유가 아님. (B) EBS 스냅샷/볼륨은 여러 인스턴스·AZ에 동시 마운트 불가. (D) 인스턴스 스토어는 휘발성이며 공유되지 않음. 【시험 포인트】 "다중 EC2·다중 AZ 공유 파일 시스템" → Amazon EFS.

해설

【핵심 용어】 ▸ Amazon EBS 암호화 + RDS 암호화 (KMS) — 인스턴스 볼륨·DB 저장 데이터 암호화, 최소 변경으로 적용 ▸ ACM — TLS 인증서(전송 중 암호화), 저장 시 암호화 아님 ▸ CloudHSM — 전용 HSM, 구성 변경·운영 부담 큼 【정답 포인트】 ▸ "PII 저장 시 암호화 + 인프라 최소 변경" → EBS 암호화 + RDS 암호화를 KMS 키로 활성화하면 최소 변경으로 요건 충족 【오답 체크】 (A) ACM 인증서는 전송 중 암호화(TLS)용으로 저장 시 암호화 요건에 부적합. (B) CloudHSM은 동작하나 변경·운영 부담이 커 "최소 변경"과 어긋남. (C) SSL은 전송 중 암호화로 저장 데이터 암호화가 아님. 【시험 포인트】 "저장 시(at rest) 암호화 + 최소 변경" → EBS/RDS 암호화 + KMS.

해설

【핵심 용어】 ▸ S3 게이트웨이 엔드포인트 — VPC에서 S3로 프라이빗 접근, NAT/인터넷 경유 불필요, 무료 ▸ NAT 인스턴스/게이트웨이 — 인터넷 경유 트래픽 처리(포화·비용 발생) ▸ Transit Gateway — VPC/온프레미스 라우팅용, S3 프라이빗 접근 수단 아님 【정답 포인트】 ▸ "NAT 네트워크 포화로 S3 업로드 타임아웃 + 인터넷 우회 없이 S3 접근" → S3 게이트웨이 엔드포인트를 만들고 라우팅 테이블 갱신하면 NAT를 거치지 않음 【오답 체크】 (A) 관리형 NAT 게이트웨이도 여전히 인터넷을 경유함. (B) NAT 인스턴스 크기만 키워도 인터넷 경유 구조는 동일. (D) Transit Gateway는 S3 프라이빗 접근을 제공하지 않음. 【시험 포인트】 "인터넷/NAT 우회 + S3 프라이빗 접근" → S3 게이트웨이 엔드포인트.

해설

【핵심 용어】 ▸ AWS Global Accelerator — AWS 백본 사용으로 TCP/UDP 연결 가속, 글로벌 지연 개선 ▸ RTMP(TCP) 라이브 스트림 — 가속된 TCP 연결이 필요 ▸ CloudFront — HTTP 콘텐츠 캐싱·배포용, 수집 TCP 가속 아님 【정답 포인트】 ▸ "전 세계 리포터 + RTMP + 최고 품질 + 방송 시스템으로 가속된 TCP 연결" → Global Accelerator가 AWS 엣지 진입 후 백본으로 TCP를 가속 【오답 체크】 (A) CloudFront는 콘텐츠 배포·캐싱용으로 업스트림 RTMP TCP 수집 가속에 부적합. (C) Client VPN은 보안 접속일 뿐 네트워크 가속 아님. (D) EC2 + Elastic IP는 가속 기능을 제공하지 않음. 【시험 포인트】 "글로벌 TCP 연결 가속" → AWS Global Accelerator.

해설

【핵심 용어】 ▸ Amazon EBS Snapshots Archive — 장기 보관용 저비용 스냅샷 아카이브 계층 ▸ EBS 스냅샷 수명주기 정책 — 데일리 유지 + 월간 아카이브 자동화 ▸ Glacier Deep Archive / EBS direct API — EBS 스냅샷 네이티브 아카이브 아님 【정답 포인트】 ▸ "데일리 스냅샷 1개월 유지 + 월간 스냅샷 7년 보관 + 최소 관리 + 비용 효율" → 기존 정책 유지하고 월간 스냅샷을 EBS Snapshots Archive로 7년 보관 규칙 추가 【오답 체크】 (A) EBS 스냅샷을 S3 Glacier Deep Archive로 직접 복사하는 네이티브 경로가 아님. (C) 월간 스냅샷을 표준 계층에 7년 보관은 비용이 큼. (D) EBS direct API로 S3 IA에 저장은 커스텀 구현으로 복잡. 【시험 포인트】 "EBS 스냅샷 장기 보관 저비용" → EBS Snapshots Archive.

해설

【핵심 용어】 ▸ AWS Backup — 관리형 백업, 규칙 기반 교차 리전 복제 지원(EFS 리소스 할당) ▸ 교차 리전 복제(cross-Region copy) — 백업 규칙으로 자동화 ▸ EFS-to-EFS backup / rsync / S3 CRR 스크립트 — 커스텀·비관리형 방식 【정답 포인트】 ▸ "EFS 데이터를 다른 리전에 AWS 관리형 서비스로 복제 + 비용 효율" → AWS Backup 백업 계획에 일일 백업 + 타 리전 복제 규칙을 두고 EFS 할당 【오답 체크】 (A) EFS-to-EFS backup 솔루션은 구식·커스텀 방식. (B) 야간 스크립트 + S3 CRR은 커스텀 스크립트로 운영 부담. (C) VPC 피어링 + rsync는 수동 방식. 【시험 포인트】 "관리형 교차 리전 백업" → AWS Backup 백업 계획 + 복제 규칙.

해설

【핵심 용어】 ▸ EC2 Auto Scaling + ALB (다중 AZ) — 웹 계층 확장·고가용성 ▸ Amazon RDS Multi-AZ — DB 계층 고가용성(대기 인스턴스 자동 장애 조치), 최소 관리 ▸ 자체 관리 EC2 DB / 교차 리전 복제 — 관리 부담 큼 【정답 포인트】 ▸ "고가용성 + 확장 + 최소 관리" → 웹은 다중 AZ Auto Scaling + ALB, SQL Server DB는 RDS Multi-AZ 배포 【오답 체크】 (A) 읽기 복제본은 고가용성 장애 조치 목적이 아니며 Multi-AZ 대비 요건과 어긋남. (B) DB를 교차 리전 EC2 2대로 복제 운영은 관리 부담 큼. (D) DB를 EC2 3대 자체 운영은 관리 오버헤드 큼. 【시험 포인트】 "관리형 DB 고가용성" → RDS Multi-AZ, 웹은 ASG + ALB.

해설

【핵심 용어】 ▸ AWS Storage Gateway (File Gateway) — 온프레미스에 SMB/NFS 공유 제공, 로컬 캐시로 저지연, S3로 자동 복사 ▸ 코드 수정 없이 파일을 AWS로 복사 + 저지연 SMB 유지 ▸ FSx for Windows / EFS / Snowball — 접근 방식 변경·물리 전송 등 부적합 【정답 포인트】 ▸ "SMB 공유 + 저지연 + 코드 수정 없이 파일을 AWS로 복사 + 기존 VPN" → File Gateway가 로컬 SMB 공유를 유지하면서 S3로 복사 【오답 체크】 (A) EFS는 NFS 기반으로 온프레미스 SMB 워크플로 유지·저지연 접근에 부적합. (B) FSx for Windows는 클라우드 파일 서버로 앱이 가리키는 대상을 바꿔야 해 코드 변경 필요. (C) Snowball은 일회성 물리 전송으로 지속 복사에 부적합. 【시험 포인트】 "온프레미스 SMB 유지 + S3 자동 복사" → Storage Gateway(File Gateway).

해설

【핵심 용어】 ▸ AWS Lambda (스케줄 실행) — 서버 없이 DynamoDB 스캔, EventBridge로 매일 예약 ▸ Amazon SNS — 이메일 알림 전송 ▸ Amazon SQS — 메시지 큐로 사람에게 직접 이메일 발송 불가 【정답 포인트】 ▸ "근무 기념일에 이메일 + 운영 효율 최고" → 매일 예약 실행되는 Lambda가 DynamoDB를 스캔하고 SNS로 이메일 전송(서버 관리 불필요) 【오답 체크】 (A) EC2 cron은 서버를 관리해야 해 운영 부담 큼. (B) EC2 cron + SQS는 서버 관리에 더해 SQS는 이메일 발송용이 아님. (D) SQS는 직원에게 직접 이메일을 보내지 못함(SNS가 적합). 【시험 포인트】 "예약 알림 + 서버리스" → 예약 Lambda + SNS 이메일.

해설

【핵심 용어】 ▸ Auto Scaling 예약 작업(scheduled action) — 예상 시점에 미리 용량 증설(사전 대응) ▸ CloudWatch 알람 스케일링 — 부하 발생 후 반응(사후) ▸ 매년 반복되는 홀리데이 급증 — 예측 가능한 시점 【정답 포인트】 ▸ "예상되는 피크 전에 사전 용량 확보로 성능 영향 최소화" → 피크 이전 시점에 확장하도록 반복 예약 작업 구성 【오답 체크】 (A) CloudWatch CPU 알람은 부하가 발생한 후 반응해 사전 대응이 아님. (C) min/max 수동 변경은 자동화된 사전 대응이 아님. (D) SNS 알림은 확장 동작을 수행하지 않음. 【시험 포인트】 "예측 가능한 시점의 사전 확장" → Auto Scaling 예약 작업.

해설

【핵심 용어】 ▸ AWS Secrets Manager — 비밀 저장 + RDS 자격 증명 자동 순환 기본 지원 ▸ Systems Manager Parameter Store — 비밀 저장 가능하나 자동 순환 미내장 ▸ AWS KMS 키 순환 — 암호화 키 순환일 뿐 DB 비밀번호 순환 아님 【정답 포인트】 ▸ "RDS 비밀번호 순환 + 최소 운영" → Secrets Manager에 저장 후 자동 순환 활성화 【오답 체크】 (B) Parameter Store는 매개변수 자동 순환 기능이 없음. (C) Lambda로 직접 순환 구현은 운영 부담 큼. (D) KMS 키 순환은 DB 비밀번호 순환과 무관. 【시험 포인트】 "DB 비밀번호 자동 순환 + 최소 운영" → Secrets Manager 자동 순환.

해설

【핵심 용어】 ▸ Amazon RDS Custom for Oracle — OS·DB 특권 접근 허용, 서드파티 기능·BYOL 지원 ▸ RDS for Oracle(표준) — 특권 접근 불가 ▸ DynamoDB / RDS PostgreSQL — 비호환·코드 재작성 필요 【정답 포인트】 ▸ "특권 접근 필요한 서드파티 기능 + BYOL + 비용 효율" → RDS Custom for Oracle이 특권 접근·커스터마이즈를 허용하며 관리형 이점 유지 【오답 체크】 (A) RDS for Oracle 표준은 특권 접근이 불가하고 Lambda로 DB 기능 대체 불가. (C) DynamoDB는 Oracle과 비호환. (D) PostgreSQL로 이전 + 앱 재작성은 비용이 큼. 【시험 포인트】 "Oracle 특권 접근·서드파티 기능 필요" → RDS Custom for Oracle.