AWS SAA-C03 Dump 301-350
Answer: C
요구사항
온프레미스 Windows 파일 서버 → Amazon FSx for Windows File Server
30TB
대학 여러 부서가 쓰는 공유 1Gbps 링크
데이터 전송 성능 최대화 (마이그레이션 효율 극대화)
사용 대역폭 제어 → 다른 부서 영향 최소화
5일 이내 완료
C. AWS DataSync
1. FSx for Windows File Server 지원
DataSync 작업 대상으로 Amazon FSx for Windows File Server를 지정할 수 있어, 온프레미스 Windows 파일 서버 → FSx 마이그레이션에 적합합니다.
2. 대역폭 제어(쓰로틀)
작업/스케줄에서 Bandwidth limit(대역폭 제한) 을 설정할 수 있습니다.
예: 1Gbps 중 500Mbps만 사용하도록 제한해, 공유 링크에서 다른 부서에 주는 영향을 줄일 수 있습니다.
“사용하는 대역폭의 양을 제어” 요구를 직접 충족합니다.
3. 전송 성능·효율
증분 전송, 검증, 병렬화 등으로 주어진 대역폭 안에서 전송 효율을 높입니다.
“데이터 전송 성능을 최대화”는, 제한된 대역폭 안에서의 성능 최대화로 해석할 수 있어 DataSync가 적합합니다.
4. 5일 일정
대역폭을 적절히 제한해도(예: 500Mbps 수준) 30TB를 5일 안에 옮기는 것이 가능합니다
Answer: A, C
요구사항
앱이 원시(raw) 형식으로 S3에 업로드 → S3에서 직접 재생
원시 형식이 커서 버퍼링·재생 문제 발생
성능·확장성 극대화
→ 파일 크기/형식 개선(트랜스코딩) + 전송·캐싱 개선(CDN) 이 필요하고, 둘 다 관리형이어야 합니다.
C. Amazon Elastic Transcoder
원시 → 적합한 형식으로 변환(해상도·비트레이트·코덱 조정).
파일 크기 감소 → 버퍼링·재생 문제 직접 해결.
관리형 서비스라 트랜스코딩 파이프라인 운영 부담이 적음 → “운영 오버헤드 최소화” 충족.
A. Amazon CloudFront
전송·캐싱을 엣지에서 처리 → 지연 감소, 오리진(S3) 부하 감소.
모바일 사용자에게 가까운 엣지에서 스트리밍 → 성능·확장성 극대화.
관리형 CDN이라 EC2로 CDN 구축(D)보다 운영 부담이 적음.
Answer: D
요구사항
Amazon ECS 클러스터, Fargate 시작 유형(EC2 인스턴스 없음)
CPU·메모리 모니터링 중, 활용도 감소 시 비용 절감 원함
→ 활용도가 낮을 때 태스크 수를 줄이는(스케일 인) 자동 조정 필요
ECS 서비스의 태스크 수를 조정하는 건 Application Auto Scaling이 담당 (EC2 Auto Scaling이 아님)
D. Application Auto Scaling + 대상 추적 정책
역할: ECS 서비스의 원하는 태스크 수(desired count)를 자동 조정
대상 추적(Target Tracking): 목표 메트릭(예: CPU 70%) 설정 → 목표보다 높으면 스케일 아웃, 낮으면 스케일 인
활용도 감소 시 태스크 감소 → Fargate 비용 절감
ECS(Fargate/EC2 공통)에 대해 AWS가 권장하는 관리형 조정 방식
A가 틀린 이유
EC2 Auto Scaling은 EC2 인스턴스 개수만 조정함
Fargate는 EC2 인스턴스를 쓰지 않으므로, EC2 Auto Scaling으로는 ECS 태스크 수를 바꿀 수 없음
스케줄 기반도 “활용도 감소 시” 동적 스케일 인과는 맞지 않음
B가 틀린 이유
Lambda + CloudWatch 경보로 ECS desired count를 바꾸는 건 가능하지만, 직접 구현하는 커스텀 방식
Application Auto Scaling + 대상 추적이 ECS용 표준·관리형 방식이고, 스케일 인/아웃이 한 정책으로 자연스럽게 동작
“운영 부담 최소화”와 “활용도 감소 시 비용 절감”에는 D가 더 적합
C가 틀린 이유
EC2 Auto Scaling + 단순 조정 정책 → 역시 EC2 인스턴스만 조정
Fargate 환경에는 조정할 EC2 인스턴스가 없으므로, ECS 태스크 수는 변하지 않음
ECS 서비스를 스케일하려면 Application Auto Scaling을 써야 함
Answer: A
요구사항
다른 AWS 리전에 재해 복구(DR) 사이트 구축
정기적으로 두 리전의 NFS 파일 시스템 간에 대량 데이터 송수신
최소한의 운영 오버헤드로 충족
→ NFS(파일 시스템)용 관리형·정기 동기화 서비스가 필요함.
A. AWS DataSync
역할: 온프레미스·AWS 스토리지 간, 또는 AWS 스토리지 간(리전 간 포함) 자동 데이터 전송
NFS 파일 시스템 지원: Amazon EFS, FSx 등 NFS 호환 스토리지 간 리전 간 복제·동기화 가능
정기 전송: 스케줄 기반 반복 작업 설정 가능 → “정기적으로” 요구사항 충족
관리형 서비스 → 에이전트·네트워크 최적화·재시도 등 AWS가 관리 → 운영 오버헤드 최소
Answer: C
요구사항
AWS에서 호스팅되는 게임 애플리케이션용 공유 스토리지
SMB 클라이언트로 데이터 액세스 필요 (Windows 파일 공유 프로토콜)
완전히 관리되는(fully managed) 솔루션
→ SMB를 지원하고, 공유 파일 시스템 역할을 하며, AWS가 운영을 담당하는 서비스가 필요함.
C. Amazon FSx for Windows File Server
역할: Windows 호환 공유 파일 시스템, SMB 프로토콜 지원
완전 관리형: 패치, 백업, 고가용성 등 AWS가 관리 → “완전히 관리되어야 합니다” 충족
애플리케이션 서버가 SMB 클라이언트로 FSx 파일 시스템에 연결해 공유 스토리지로 사용 가능
게임 서버 여러 대가 동일 FSx를 마운트해 공유 스토리지로 사용하는 패턴에 적합
A가 틀린 이유
DataSync는 데이터 전송·동기화 서비스(원본 ↔ 대상 간 복사/스케줄 작업)임
“탑재 가능한 파일 시스템”을 앱 서버가 실시간으로 마운트해 공유 스토리지로 쓰는 용도가 아님
공유 스토리지 + SMB 액세스를 제공하는 서비스가 아니라서 요구사항과 맞지 않음
Answer: A
요구사항
EC2에서 지연 시간에 민감한 애플리케이션 + 인메모리 DB
분당 10만 건 이상 트랜잭션 → 높은 네트워크 처리량 필요
데이터 전송 비용 최소화 + 비용 효율적인 네트워크 설계
→ 같은 AZ 안에서 저지연·고처리량이면서 데이터 전송 요금이 나가지 않도록 설계해야 함.
데이터 전송 비용
같은 가용 영역(AZ) 내 트래픽: 무료
같은 리전, 서로 다른 AZ 간 트래픽: 과금 (AZ 간 데이터 전송 요금)
리전 간은 더 비쌈
→ 데이터 전송 비용을 최소화하려면 앱·DB를 같은 AZ에 두고, AZ 간 전송을 피해야 함.
배치 그룹
클러스터(Cluster): 같은 랙/네트워크에 배치 → 최저 지연, 고처리량(인스턴스 간 최대 10Gbps), HPC·인메모리 DB에 적합
파티션(Partition): 파티션별로 분산 (대규모 분산 DB용)
스프레드(Spread): 하드웨어 분산 (고가용성)
A. 같은 리전·같은 AZ + 클러스터 배치 그룹
같은 AZ에 모든 EC2(앱 + 인메모리 DB) 배치 → AZ 간 데이터 전송 없음 → 데이터 전송 비용 최소화
클러스터 배치 그룹 → 인스턴스가 물리적으로 가깝게 배치 → 최저 지연, 높은 네트워크 처리량(10Gbps급)
지연 시간 민감 + 분당 10만+ 트랜잭션 + 데이터 전송 비용 최소화를 모두 만족
Answer: D
요구사항
온프레미스에서 애플리케이션 서버 운영 → AWS로 마이그레이션
온프레미스 iSCSI 스토리지 확장 필요를 최소화
최근에 액세스한 데이터만 로컬에 저장 (나머지는 클라우드)
→ 애플리케이션은 iSCSI로 접근, 로컬은 캐시만 두고 전체 데이터는 AWS에
D. Storage Gateway 볼륨 게이트웨이 — 캐시 볼륨
역할: 온프레미스에 iSCSI 볼륨을 노출하고, 주(primary) 데이터는 Amazon S3에 저장
캐시 볼륨: 최근에 읽은 데이터만 게이트웨이 로컬 디스크에 캐시 → “최근 액세스한 데이터만 로컬” 요구사항 충족
전체 데이터는 S3에 있으므로 온프레미스 iSCSI 스토리지 확장을 최소화
앱 서버는 기존처럼 iSCSI로 볼륨에 접근
Answer: B, D
요구사항
통합 결제를 쓰는 여러 AWS 계정
90일간 여러 Amazon RDS for Oracle 온디맨드 고성능 DB 인스턴스 실행
재무 팀은 통합 결제 계정 및 다른 모든 계정에서 Trusted Advisor 접근 가능
적절한 계정으로 Trusted Advisor의 RDS 관련 권장 사항을 보고, 적절한 Trusted Advisor 검사를 검토해 RDS 비용을 줄여야 함
→ 어디서(어느 계정에서) 볼지 + 어떤 검사를 볼지 두 가지를 골라야 함.
B. 통합 결제 계정의 Trusted Advisor로 모든 RDS 검사 동시 확인
역할: 통합 결제(관리) 계정에서 Trusted Advisor를 쓰면, 조직 내 모든 연결 계정의 권장 사항을 한곳에서 볼 수 있음
RDS가 여러 계정에 흩어져 있어도, 한 계정(통합 결제 계정)에서 모든 RDS 관련 검사를 동시에 확인 가능 → 재무 팀이 “적절한 AWS 계정”으로 효율적으로 검토하는 단계에 해당
따라서 “어디서 볼지”에 대한 답은 B
D. RDS 유휴 DB 인스턴스 Trusted Advisor 검사 검토
역할: Trusted Advisor의 “Amazon RDS 유휴 DB 인스턴스” 검사는 사용률이 낮거나 거의 쓰이지 않는 RDS 인스턴스를 찾아줌
이런 인스턴스를 종료·축소하면 RDS 비용을 바로 줄일 수 있음 → “RDS 비용을 줄인다”는 요구사항에 직접 대응하는 검사 선택 단계
따라서 “어떤 검사를 볼지”에 대한 답은 D
Trusted Advisor는 AWS 계정과 리소스 사용 현황을 분석해서, 비용 절감·성능·보안·내결함성·서비스 한도 관련 권장 사항(추천) 을 알려주는 서비스
• Trusted Advisor “지금 AWS 환경이 잘 쓰이고 있나? 문제 있나?”
• Cost Explorer “돈을 어디에, 얼마나, 왜 쓰고 있지?”
Answer: A
요구사항
스토리지 비용 최적화 필요
더 이상 액세스하지 않거나 거의 액세스하지 않는 S3 버킷을 찾아야 함
최소한의 운영 오버헤드로 달성
→ “어떤 버킷이 거의/전혀 안 쓰이는지”를 접근 패턴(액세스 빈도) 으로 보고, 관리형 도구로 처리하는 게 좋음.
A. S3 Storage Lens + 고급 활동 메트릭
역할: S3 Storage Lens는 조직/계정 단위 S3 사용·활동 분석용 관리형 대시보드
고급 활동 메트릭(Advanced activity metrics) 에서 버킷/접두사별 액세스 빈도를 볼 수 있음 → “더 이상/거의 액세스하지 않는 버킷” 식별에 적합
최소 운영 오버헤드: 설정 후 대시보드에서 바로 확인, 별도 로그 수집·쿼리·파이프라인 구축 불필요
스토리지 비용 최적화(저활용 버킷 식별) 목표에 맞고, 운영 부담이 적음
B가 틀린 이유
Management Console의 S3 대시보드는 버킷 목록·스토리지 용량·스토리지 클래스 등 위주
버킷별 액세스 빈도·접근 패턴을 분석하는 기능이 없음 → “더 이상/거의 액세스하지 않는 버킷”을 체계적으로 찾기 어려움
C가 틀린 이유
BucketSizeBytes는 버킷 용량(크기) 메트릭일 뿐, 언제/얼마나 액세스했는지 정보가 없음
액세스 패턴(rarely/no access) 분석에는 액세스 관련 메트릭이 필요함
Athena로 CloudWatch 메트릭 분석하는 구성은 설정·쿼리 유지보수 등 운영 오버헤드가 큼 → “최소한의 운영 오버헤드”와 맞지 않음
D가 틀린 이유
CloudTrail로 S3 데이터 이벤트를 켜면 API 호출(액세스) 로그는 남지만, 버킷별·접두사별로 집계·분석하려면 CloudWatch Logs + 쿼리/스크립트/Lambda 등 직접 파이프라인을 만들어야 함
“최소한의 운영 오버헤드”보다 구성·운영 부담이 큰 방식 → 이 목표에는 A(Storage Lens)가 더 적합
Answer: B
요구사항
us-east-1 S3 버킷에 대용량 데이터셋(형식 지정 파일) 저장
웹 앱(ALB + EC2)에서 구매 후 S3 서명 URL로 파일 액세스 제공
고객이 북미·유럽에 분산
데이터 전송 비용 감소 + 성능 유지 또는 개선
→ 전 세계 사용자에게 가까운 엣지에서 전달하고 오리진(S3) 부하·전송량을 줄이는 구성이 필요함.
B. CloudFront 배포 + CloudFront 서명 URL
역할: 기존 S3(us-east-1)를 오리진으로 두고 Amazon CloudFront 배포 → 고객 요청은 CloudFront URL로 보냄
비용: 엣지에서 캐시 히트 시 S3로 가지 않음 → S3 이그레스·반복 전송 감소 → 데이터 전송 비용 감소
성능: 북미·유럽 사용자에게 가장 가까운 엣지에서 제공 → 지연 시간 감소, 성능 유지·개선
액세스 제어: CloudFront를 쓰면 URL이 CloudFront 도메인이 되므로 S3 서명 URL 대신 CloudFront 서명 URL(또는 서명 쿠키) 로 전환해야 함 → “CloudFront 서명 URL로 전환”이 맞음
Answer: C
요구사항
사용자가 앱에서 견적 요청
견적 유형별로 구분 (유형별 처리)
24시간 이내 응답
분실 금지 (메시지 유실 없음)
운영 효율 극대화, 유지보수 최소화
→ 견적 유형별로 라우팅되고, 유실되지 않는(내구성) 큐 기반이면서 관리형인 구성이 필요함.
C. SNS 1개 + SQS 구독 + SNS 메시지 필터
역할: 단일 SNS 주제에 견적 요청 게시 → 견적 유형별 SQS 큐가 SNS를 구독 → SNS 메시지 필터(필터 정책) 로 유형별로 해당 큐에만 전달
분실 금지: SQS에 메시지가 저장됨(기본 14일 보존) → 소비 전까지 유지, 내구성 충족
견적 유형별 구분: 필터 정책으로 quote_type 등 속성에 따라 유형별 SQS 큐로만 라우팅
24시간 이내: 백엔드가 각자 SQS에서 폴링해 처리하면 됨, 보존 기간 내 처리 가능
운영·유지보수: SNS·SQS 모두 관리형 → 큐/컨슈머 인프라 직접 운영 불필요, KCL·스트림 유지보수 없음 → 운영 효율·유지보수 최소화
Answer: B
요구사항
여러 EC2 인스턴스, 각각 여러 EBS 데이터 볼륨 연결
EC2 인스턴스 구성 + 데이터를 야간에 백업
다른 AWS 리전에서 복구 가능해야 함(리전 간 복구)
운영상 가장 효율적인 방식
→ 인스턴스 구성 + 볼륨 데이터 모두 백업하고, 다른 리전으로 복사하며, 관리형 서비스로 운영 부담을 줄이는 구성이 필요함.
B. AWS Backup + EC2 인스턴스를 리소스로
역할: AWS Backup으로 백업 계획 생성 → 야간 스케줄 설정, 다른 리전으로 복사 옵션 설정, EC2 인스턴스를 리소스로 등록
EC2 인스턴스를 리소스로 추가하면: 연결된 EBS 볼륨 스냅샷 + 인스턴스 메타데이터(구성) 를 함께 백업 → “EC2 인스턴스 구성 및 데이터” 요구사항 충족
다른 리전에 복사: 백업 계획에서 리전 간 복사 설정 → “다른 AWS 리전에서 복구” 충족
운영 효율: 완전 관리형 — Lambda·스크립트 유지보수 없이 계획만 설정하면 됨
Answer: C
요구사항
AWS에서 모바일 앱 구축
수백만 명에게 도달(확장성)
승인된 사용자만 모바일에서 회사 콘텐츠 시청
→ 대규모 전달 + 접근 제어가 필요함
C. Amazon CloudFront + 서명 URL
역할: CloudFront로 스트리밍 콘텐츠 전달, 서명 URL(Signed URL) 로만 접근 허용
확장성: CloudFront는 CDN으로 전 세계 엣지에서 전달 → 수백만 사용자 규모에 적합
승인된 사용자만: 서명 URL은 유효 기간·사용자 식별을 포함할 수 있음 → 로그인/승인 후에만 URL 발급하면 승인된 사용자만 콘텐츠 시청 가능
스트리밍: CloudFront는 비디오/오디오 스트리밍에 적합
Answer: B
요구사항
온프레미스 MySQL DB, 글로벌 영업 팀 사용
드물게 액세스하는 패턴(레어 액세스)
가동 중지 시간 최소화로 마이그레이션
특정 인스턴스 유형을 선택하지 않고 AWS로 마이그레이션 → 향후 사용자 증가 대비
→ MySQL 호환 + 인스턴스 타입 미선택(자동 용량) + 레어 액세스에 맞는 비용이 필요함
B. MySQL용 Amazon Aurora Serverless
역할: Aurora Serverless는 MySQL 호환이며, 인스턴스 타입을 선택하지 않음 — 로드에 따라 ACU(용량) 가 자동으로 스케일
특정 인스턴스 유형 미선택: 프로비저닝된 인스턴스가 아니라 서버리스 → “특정 인스턴스 유형을 선택하지 않고” 요구사항 충족
드물게 액세스: 유휴 시 스케일 다운 → 레어 액세스 패턴에 맞는 비용 효율
향후 사용자 증가: 트래픽 증가 시 자동 스케일 업 → 인스턴스 타입을 미리 정할 필요 없음
마이그레이션: AWS DMS 등으로 다운타임 최소화 마이그레이션 가능
Answer: D
요구사항
온프레미스에서 맞춤형 앱 취약점으로 침해 발생 → EC2로 마이그레이션 중
EC2 인스턴스의 취약점을 능동적으로 스캔
결과를 자세히 설명하는 보고서를 생성·전달
→ 취약점 스캔 + 상세 보고서 자동화가 필요함
D. Amazon Inspector + 에이전트 + Lambda
역할: Amazon Inspector는 취약점 관리 서비스로, EC2 인스턴스에 대한 CVE·패키지 취약점·네트워크 노출 등을 스캔함
능동적 스캔: Inspector 에이전트를 EC2에 배포하면 해당 인스턴스를 주기적·능동적으로 스캔
상세 결과: Inspector가 취약점·심각도·권장 조치 등을 담은 상세 finding/리포트 제공
보고서 생성·배포 자동화: Lambda로 Inspector 결과를 가져와 보고서를 만들고(SNS·이메일·S3 등으로) 배포하도록 구성 가능 → “결과를 자세히 설명하는 보고서를 보내는” 요구사항 충족
Answer: C
요구사항
EC2에서 스크립트 실행 → SQS 큐 폴링·처리
큐에 쌓이는 메시지가 늘어나도 처리 능력 유지(확장성)
운영 비용 절감
→ 메시지량에 맞춰 스케일 + 비용 절감이 필요함
C. SQS 처리 로직을 AWS Lambda로 마이그레이션
역할: EC2 스크립트(SQS 폴링·처리)를 Lambda 함수로 옮기고, SQS를 Lambda 이벤트 소스로 연결
확장성: SQS → Lambda 이벤트 소스 매핑으로 메시지가 늘어나면 Lambda 동시 실행 수가 자동 증가 → “점점 더 많은 메시지 처리 능력 유지” 충족
비용 절감: 실행한 만큼만 과금(호출·실행 시간), 큐가 비어 있으면 컴퓨팅 비용 거의 없음 → EC2 24/7 대비 운영 비용 절감
운영: EC2·OS·패치·스케일 관리 불필요 → 운영 부담 감소
Answer: A
요구사항
레거시 앱: 데이터를 CSV로 생성해 S3에 저장
COTS 앱: 복잡한 SQL로 Amazon Redshift + S3 데이터만 분석 가능
COTS는 레거시가 만든 .csv 파일을 직접 처리할 수 없음
레거시 앱은 수정 불가(다른 형식으로 출력 불가)
COTS가 레거시 데이터를 사용할 수 있게 해야 함
최소한의 운영 오버헤드
→ 레거시가 S3에 넣는 CSV를 Redshift(또는 COTS가 SQL로 조회 가능한 형태)로 적재해야 하고, 관리형 ETL이 필요함.
A. AWS Glue ETL 작업
역할: 스케줄로 실행되는 AWS Glue ETL 작업으로 S3의 .csv를 읽어 변환 후 Amazon Redshift에 적재
COTS 연동: COTS는 Redshift에서 복잡한 SQL 실행 → Glue가 CSV를 Redshift 테이블로 넣으면 COTS가 레거시 데이터를 Redshift에서 사용 가능
레거시 미수정: 레거시는 계속 CSV만 S3에 저장하면 됨
운영 오버헤드 최소: Glue는 관리형 서버리스 ETL — 클러스터·OS·크론 직접 관리 불필요
Answer: A, D
요구사항
전체 IT 환경을 AWS로 마이그레이션한 뒤
사용자가 적절한 변경 제어 없이
과도한 크기의 EC2 인스턴스 프로비저닝
보안 그룹 규칙 수정
인벤토리·구성 변경을 추적·감사할 전략 필요
→ 누가, 언제, 무엇을 바꿨는지 기록 + 설정 상태·규정 준수 검사가 필요함.
A. AWS CloudTrail 활성화 후 감사에 활용
역할: API 호출 기록 — 누가(principal), 언제, 어떤 API를 호출했는지 로그
추적: RunInstances, AuthorizeSecurityGroupIngress 등으로 과대 사이즈 EC2 프로비저닝, 보안 그룹 규칙 변경을 시간순으로 추적 가능
감사: CloudTrail 로그로 “누가 어떤 변경을 했는지” 감사(audit) 가능
인벤토리·구성 변경 추적·감사 요구사항에 직접 대응
D. AWS Config 활성화 후 감사·규정 준수를 위한 규칙 생성
역할: 리소스 구성 이력·인벤토리 기록 + 규칙으로 규정 준수·정책 위반 검사
추적: EC2 인스턴스·보안 그룹 등 구성 변경 이력을 저장 → 무엇이 어떻게 바뀌었는지 추적
감사: Config 규칙으로 예) “허용된 인스턴스 타입만 사용”, “보안 그룹 특정 포트 제한” 등 정책 위반·규정 준수 검사 → 감사·컴플라이언스에 활용
인벤토리·구성 변경 추적·감사 요구사항에 직접 대응
Answer:
요구사항
수백 대 Amazon EC2 Linux 인스턴스
기존: 공유 SSH 키로 인스턴스 관리
감사 후: 모든 공유 키 제거 지시
EC2에 대한 보안 액세스 제공
최소한의 관리 오버헤드
→ SSH 키 없이 안전하게 접속하고, 키·배스천 등 운영 부담을 줄이는 방식이 필요함.
A. AWS Systems Manager Session Manager
역할: SSH 키·포트 22 없이 EC2에 브라우저 또는 CLI로 세션 연결
인증: IAM 기반 — 사용자/역할로 접근 제어, 공유 SSH 키 불필요
공유 키 제거: SSH 키를 쓰지 않으므로 모든 공유 키 제거 요구사항 충족
최소 관리: 관리형 서비스 — 배스천·키 배포·키 로테이션·방화벽 규칙 관리 불필요
보안: 트래픽이 AWS를 통해 암호화되어 전달되며, CloudTrail에 세션 로그 기록 가능
SSH/RDP·키·인바운드 22/3389 없이, IAM으로 제어되는, 감사 가능한 EC2(및 온프레미스) 쉘/세션 접속을 제공하는 관리형 원격 접속 서비스입니다.
Answer: A
요구사항
EC2 인스턴스 플릿으로 온프레미스에서 JSON 데이터 수집, 최대 1MB/s
EC2 재부팅 시 진행 중인 데이터 손실 → 손실 최소화 필요
데이터 과학 팀이 거의 실시간으로 수집 데이터 쿼리 필요
확장 가능한 구조
→ 재부팅에 강한(내구성) 수집 + 거의 실시간 쿼리 + 확장성이 필요함.
A. Kinesis Data Streams + Kinesis Data Analytics
역할: 수집 데이터를 Kinesis Data Streams(KDS) 에 게시 → Kinesis Data Analytics(KDA) 로 스트리밍 SQL 쿼리
데이터 손실 최소화: KDS는 내구성·복제·보존이 있음 → EC2가 재부팅돼도 이미 KDS에 들어간 데이터는 유지, EC2 메모리/로컬 디스크에만 있던 데이터만 손실 → “진행 중 데이터 손실” 최소화
거의 실시간 쿼리: KDA가 스트림 위에서 SQL 실행(슬라이딩 윈도우 등) → 수집 직후 거의 실시간으로 쿼리 가능
확장성: KDS는 샤드 단위로 스케일, 1MB/s 규모에 적합
| 서비스 | 쿼리 방식 | 데이터 위치 | 용도 |
| Athena | SQL | S3 | S3 파일 검색·분석 |
| Redshift | SQL | Redshift 클러스터 | 웨어하우스·BI·배치 분석 |
| Redshift Spectrum | SQL | S3 | S3를 Redshift 스타일로 쿼리 |
| OpenSearch | 검색/집계 API, Kibana | OpenSearch | 인덱스 로그·검색·메트릭 |
| Kinesis Data Analytics | 스트리밍 SQL | Kinesis 스트림 | 실시간 스트림 쿼리 |
| QuickSight | 시각화·쿼리 UI | Redshift/Athena/S3 등 | 대시보드·리포팅 |
Answer: D
요구사항
Amazon S3 버킷에 업로드되는 모든 객체가 암호화되도록 해야 함
→ PutObject 시 서버 측 암호화(SSE) 를 강제해야 함.
D. PutObject 시 x-amz-server-side-encryption 헤더 없으면 거부
역할: 버킷 정책에서 PutObject를 조건부로 거부 — x-amz-server-side-encryption 헤더가 없는 요청만 거부
x-amz-server-side-encryption: 클라이언트가 업로드 시 서버 측 암호화(SSE-S3 또는 SSE-KMS) 를 요청할 때 쓰는 헤더
헤더 없으면 거부 → 업로드할 때 반드시 이 헤더를 보내야 하므로, 모든 업로드 객체가 암호화됨
“업로드된 모든 객체가 암호화되도록” 요구사항에 직접 대응
Answer: C
요구사항
모바일에서 이미지 업로드 → 앱이 썸네일 생성 후 “업로드 완료” 메시지 반환
썸네일 생성은 최대 60초 걸릴 수 있음
사용자에게는 “원본 이미지가 수신됐다”는 응답을 더 빨리 주고 싶음
서로 다른 애플리케이션 계층 사이에 요청을 비동기로 전달해야 함
→ 업로드 수신과 썸네일 생성을 비동기로 분리하고, 즉시 “이미지 수신됨”만 응답하는 구조가 필요함.
C. Amazon SQS 큐 + 즉시 “이미지 수신됨” 응답
역할: 이미지 업로드 시 썸네일 생성 작업을 SQS 큐에 메시지로 넣고, 앱이 바로 “이미지가 수신되었습니다” 메시지를 사용자에게 반환
빠른 응답: 썸네일을 기다리지 않고 업로드 수신 직후 응답 → “더 빠른 응답 시간” 충족
비동기·계층 분리: 업로드 계층 → (SQS 메시지) → 썸네일 생성 계층으로 큐를 통한 비동기 전달 → “서로 다른 계층에 요청을 비동기로 전달” 충족
내구성: SQS에 작업이 쌓이므로 썸네일 워커가 나중에 처리 가능 (최대 60초 걸려도 사용자 대기 없음)
Answer: B
요구사항
건물 입구에 배지 판독기(센서) 가 있고, HTTPS로 메시지 전송
배지 스캔 시 누가 어떤 입구에 접근 시도했는지 메시지로 전송
이 센서 메시지를 처리하는 시스템 필요
고가용성(HA) 필요
보안 팀이 분석할 수 있도록 결과 제공 필요
→ HTTPS로 메시지 수신 + 메시지 처리 + 고가용성 + 분석용 결과 저장이 필요함.
B. API Gateway + Lambda + DynamoDB
역할: API Gateway로 HTTPS 엔드포인트 제공 → Lambda가 메시지 처리 → DynamoDB에 결과 저장
HTTPS: API Gateway가 HTTPS 지원 → 판독기(센서)가 HTTPS로 메시지 전송 가능
고가용성: API Gateway·Lambda·DynamoDB 모두 관리형·멀티 AZ → 고가용성 충족
처리: Lambda에서 메시지 파싱·검증 후 DynamoDB에 누가, 언제, 어떤 입구 등 저장
분석: DynamoDB(또는 DynamoDB + QuickSight/리포트)로 보안 팀이 조회·분석 가능
Answer: B
요구사항
온프레미스 파일 스토리지 볼륨 — iSCSI 장치로 마운트, 수백 TB
재해 복구(DR) 계획 수립
최종 사용자가 대기 시간 없이 온프레미스 시스템의 모든 파일 유형에 즉시 액세스
기존 인프라 변경 최소화
→ iSCSI 유지 + 모든 데이터가 로컬에 있어 지연 없음 + DR용 백업/복구가 필요함.
D. Storage Gateway 볼륨 게이트웨이 — 저장 볼륨
역할: 저장 볼륨(Stored volumes) — 전체 데이터가 온프레미스에 있고, 비동기 스냅샷만 S3로 전송
즉시 액세스·무지연: 데이터가 전부 로컬이므로 캐시 미스 없이 모든 파일에 즉시 액세스 가능 → “대기 시간 없이 즉시 액세스” 충족
iSCSI 유지: 볼륨 게이트웨이가 iSCSI 제공 → 기존 파일 서버가 iSCSI로 마운트하는 방식 유지, 인프라 변경 최소
DR: 예약된 스냅샷으로 S3에 백업 → 재해 시 스냅샷을 EBS로 복원 후 EC2에 연결해 복구
수백 TB: 저장 볼륨은 로컬에 전체 데이터를 두므로, 캐시 용량 제한(10TB 등)과 무관하게 모든 데이터에 즉시 접근 가능
Answer: A
요구사항
S3에 웹 앱 호스팅
Amazon Cognito로 사용자 인증 → JWT 반환
JWT로 다른 S3 버킷의 보호된 리소스 접근
문제: 배포 후 사용자가 오류 발생, 보호된 콘텐츠에 접근 불가
목표: 보호된 콘텐츠 접근을 위한 적절한 권한 제공
→ 인증(Cognito, JWT)은 되지만 S3 접근 권한(자격 증명) 이 없어서 발생하는 문제로 보는 것이 타당함.
개념 정리
Cognito User Pool: 로그인 → JWT 발급 (인증)
Cognito Identity Pool(자격 증명 풀): JWT 등으로 임시 AWS 자격 증명(IAM 역할 기반) 발급 → 이 자격 증명으로 S3 등 AWS 리소스 접근
보호된 S3 접근 = Identity Pool이 부여하는 IAM 역할에 해당 S3 버킷에 대한 s3:GetObject 등 권한이 있어야 함
A. Cognito 자격 증명 풀에서 적절한 IAM 역할 사용
역할: 자격 증명 풀(Identity Pool) 이 보호된 S3에 접근 가능한 IAM 역할을 맡도록 설정
동작: 사용자가 Cognito로 로그인해 JWT를 받으면, Identity Pool이 위 IAM 역할의 임시 자격 증명을 발급 → 클라이언트가 이 자격 증명으로 S3에 요청 → 보호된 콘텐츠 접근 가능
문제 원인: Identity Pool에 연결된 IAM 역할에 해당 S3 버킷(또는 prefix)에 대한 권한이 없거나 잘못됐을 가능성이 큼
해결: Identity Pool을 업데이트해 보호된 콘텐츠용 S3 권한을 가진 IAM 역할을 사용하도록 변경 → 요구사항 충족
Answer: A, B
요구사항
S3 Standard 버킷에 대용량 자산 업로드
멀티파트 업로드 병렬 사용, 동일 객체 재업로드 시 덮어쓰기
업로드 후 30일: 자주 액세스
30일 이후: 덜 자주 사용, 객체별 액세스 패턴이 일관되지 않음
저장 비용 최적화 + 고가용성·탄력성(내구성) 유지
→ 30일 이후 비용 절감 + 알 수 없는 액세스 패턴 대응 + 멀티 AZ 유지가 필요함.
A. 30일 후 S3 Intelligent-Tiering으로 이동
역할: 수명 주기 정책으로 30일 지난 객체를 S3 Intelligent-Tiering 스토리지 클래스로 전환
비용: Standard 대비 저장 비용 절감, 액세스가 없으면 자동으로 Infrequent Access 티어로 이동
일관되지 않은 액세스: 액세스 패턴을 모를 때 자동 티어링으로 적절한 티어에 둠 → 가끔 액세스해도 Intelligent-Tiering은 추가 검색 요금 없이 Frequent 티어로 올려줌 (Standard-IA는 검색 요금 있음)
고가용성·내구성: 멀티 AZ 스토리지 클래스라 “고가용성과 탄력성 유지” 충족
B. 불완전한 멀티파트 업로드 정리 수명 주기 정책
역할: S3 수명 주기 정책에서 불완전한 멀티파트 업로드(AbortIncompleteMultipartUpload) 를 일정 기간(예: 7일) 후 정리(삭제) 하도록 설정
비용: 중단·실패한 멀티파트 업로드의 고아 파트가 남아 있으면 스토리지 비용이 발생 → 정리하면 비용 절감
멀티파트 업로드 사용 시 권장 사항이므로 요구사항과 직접 연결됨
Answer: A
요구사항
VPC 내 프라이빗 서브넷의 EC2 — 매우 민감한 데이터
회사 정책: EC2는 승인된 타사 소프트웨어 리포지토리(타사 URL) 로만 인터넷 접근 가능 (제품 업데이트용)
그 외 인터넷 트래픽은 차단
→ 아웃바운드 트래픽을 도메인/URL 기준으로 제한해야 함
A. AWS Network Firewall + 도메인 목록 규칙 그룹
역할: 프라이빗 서브넷 아웃바운드 트래픽을 AWS Network Firewall로 보내고, 도메인 목록 규칙 그룹(Domain list rule group) 으로 필터링
도메인 목록 규칙 그룹: 승인된 타사 리포지토리 도메인만 목록에 넣고 허용, 나머지는 기본 거부 → “승인된 타사 URL만, 나머지 인터넷 차단” 충족
Network Firewall: 상태 저장 네트워크 방화벽 — 아웃바운드 트래픽 경로에 배치해 도메인/IP/포트 기준 제어 가능
프라이빗 서브넷 라우팅 테이블을 Network Firewall로 보내도록 설정하면, EC2 → 인터넷 구간에서만 허용된 도메인으로 나가도록 제한 가능
B가 틀린 이유
AWS WAF는 웹 애플리케이션용 — ALB, CloudFront, API Gateway 앞에 붙어 인바운드 HTTP/HTTPS 요청을 필터링
EC2에서 나가는 아웃바운드 트래픽(예: EC2가 외부 URL로 요청) 경로에는 WAF가 없음 → “EC2 아웃바운드를 승인 URL만 허용”하는 용도로 사용 불가
소스/대상 IP 규칙만으로는 URL/도메인 단위 제어가 어렵고, 요구사항은 “승인된 타사 URL만”이므로 A(Network Firewall + 도메인 목록) 가 맞음
C가 틀린 이유
보안 그룹은 IP 주소·포트·프로토콜(및 보안 그룹) 기준만 필터링
URL/도메인 기준 규칙을 넣을 수 없음 → “승인된 소프트웨어 리포지토리 URL만 허용”을 보안 그룹만으로 구현 불가
타사 리포지토리는 IP가 자주 바뀌므로 IP 기반만으로는 정책 유지가 어렵음
D가 틀린 이유
ALB는 인바운드 트래픽을 EC2 등으로 분산하는 용도
EC2가 시작하는 아웃바운드 트래픽(EC2 → 인터넷)은 ALB를 거치지 않음 → “모든 아웃바운드를 ALB로 보낸다”는 구성 자체가 성립하지 않음
“아웃바운드만 승인 URL로 제한”하는 요구사항에는 Network Firewall(A) 가 적합함
Answer: D
요구사항
3계층 전자상거래: S3 웹사이트 + ALB 뒤 EC2 3대 API
API: 정적·동적 프론트 + 판매 요청을 비동기로 처리하는 백엔드 워커
신제품 출시 등으로 판매 요청이 급증할 것으로 예상
모든 요청이 성공적으로 처리되어야 함
→ 급증 시 요청 유실 없음 + 처리 용량 확보가 필요함.
→ “비동기 처리”이므로 큐로 요청을 버퍼링하는 구성이 적합함.
D. CloudFront(정적) + SQS 큐
역할: 정적 콘텐츠는 CloudFront로 전달, 판매 요청은 SQS 큐에 넣고, EC2(API/워커) 가 큐에서 꺼내 비동기 처리
모든 요청 성공 처리: SQS에 요청이 쌓이므로 유실 없음(내구성). 급증 시에도 API가 큐에만 넣고, 워커가 처리할 때까지 큐에 보관 → “모든 요청이 성공적으로 처리” 가능
급증 대응: 트래픽이 몰려도 큐가 버퍼 역할을 하고, 워커/EC2는 Auto Scaling 등으로 늘리면 됨
정적 콘텐츠: CloudFront로 캐시해 오리진(EC2/S3) 부하 감소
Answer: B
요구사항
보안 감사: EC2 인스턴스가 정기적으로 패치되지 않음
대규모 EC2 전체에 대해 정기적인 보안 스캔 실행
정기적으로 EC2 인스턴스 패치
인스턴스별 패치 상태 보고서 제공
→ 취약점 스캔 + 예약 패치 + 패치 상태 보고가 필요함.
D. Amazon Inspector + Systems Manager Patch Manager
역할: Amazon Inspector로 EC2 소프트웨어 취약점 스캔, Systems Manager Patch Manager로 정기 패치 및 패치 상태 보고
정기 보안 스캔: Inspector — CVE·패키지 취약점·네트워크 노출 등 EC2 취약점 스캔, 대규모 인스턴스에 에이전트만 배포하면 됨
정기 패치: Patch Manager — 패치 베이스라인·유지 관리 윈도우로 예약 패치 실행
패치 상태 보고: Patch Manager — 패치 준수(compliance) 정보로 인스턴스별 패치 상태 확인·보고 가능
요구사항(스캔 + 패치 + 보고)을 한 솔루션으로 충족
Answer: A
요구사항
Amazon RDS DB 데이터를 암호화해야 함
인스턴스에 저장되는 데이터에 대한 암호화 → 미사용 데이터(encryption at rest) 암호화
→ 스토리지(디스크)에 저장된 데이터를 암호화하는 것이 목표
A. KMS 키 생성 + DB 인스턴스 암호화 활성화
역할: AWS KMS에서 고객 관리형 키(또는 AWS 관리형 키) 사용, RDS DB 인스턴스 생성/수정 시 암호화 활성화
동작: RDS가 KMS 키로 EBS 볼륨·스냅샷·백업 등을 암호화 → 미사용 데이터(at rest) 암호화
요구사항: “RDS DB 데이터 암호화(미사용 데이터)”를 충족하는 표준 방식
Answer: B
요구사항
30일 이내에 데이터 센터 → AWS로 20TB 마이그레이션
네트워크 대역폭: 15Mbps, 사용률 70% 초과 불가
→ 실질 사용 가능: 15 × 0.7 = 10.5 Mbps
네트워크로 가능한가?
20TB = 20 × 8 = 160 Tb
30일 = 30 × 24 × 3600 ≈ 2,592,000초
30일 안에 20TB를 보내려면: 160 Tb ÷ 2,592,000초 ≈ 61.7 Mbps 필요
실제 사용 가능: 10.5 Mbps → 네트워크만으로는 30일 내 전송 불가
→ 인터넷/전용선 전송으로는 요구사항을 만족할 수 없음.
A. AWS Snowball
역할: 오프라인 마이그레이션 — 온프레미스에서 Snowball 디바이스로 데이터 복사 후 물리적으로 AWS로 배송
대역폭 제약 회피: 전송은 고객 내부 네트워크(LAN 등)에서 Snowball으로 복사 → 15Mbps 인터넷 링크를 쓰지 않음
30일 가능: 디바이스로 복사(내부망 속도) + 배송 + AWS 측 업로드까지 30일 내 완료 가능
20TB 규모도 Snowball Edge 등으로 처리 가능
B가 틀린 이유
DataSync는 네트워크(인터넷/전용선) 로 전송
10.5Mbps로 20TB를 보내면 수 개월 걸림 → 30일 내 완료 불가
Answer: B
요구사항
기밀·민감 파일에 대한 안전한 접근 제공
권한 있는 사용자만 파일 접근
직원 기기로 안전하게 다운로드
현재: 온프레미스 Windows 파일 서버에 저장
문제: 원격 사용 증가로 파일 서버 용량 부족
→ Windows 파일 서버 유지 + 확장 가능 + 권한 기반 접근 + 원격에서 안전 접근·다운로드가 필요함.
B. FSx for Windows File Server + AD 통합 + AWS Client VPN
역할: 파일을 Amazon FSx for Windows File Server로 이전, 온프레미스 Active Directory와 연동, AWS Client VPN으로 원격 접속
권한 있는 사용자만: AD 통합으로 기존 AD 사용자/그룹으로 접근 제어 → 권한 있는 사용자만 접근
안전한 다운로드: Client VPN 터널 안에서 FSx 접근 → 암호화된 경로로 파일 다운로드
용량·확장: FSx는 관리형·확장 가능 → 온프레미스 파일 서버 용량 부족 해소
Windows 파일 서버: SMB 유지 → 기존 사용 방식(드라이브 매핑 등) 유지 가능
Answer: C
요구사항
ALB 뒤 EC2(Auto Scaling, 다중 AZ)에서 앱 실행
매월 1일 자정 월말 재무 계산 일괄 처리 실행
배치 실행 시 앱이 크게 느려지고, EC2 CPU가 즉시 100% → 앱 중단
워크로드 처리 + 다운타임 방지 필요
→ 예측 가능한 시점(매월 1일 자정)에 용량을 미리 늘려 배치를 받아줘야 함.
C. EC2 Auto Scaling 예약 조정 정책
역할: 예약 조정(Scheduled scaling) 으로 매월 1일 자정 전에 인스턴스 수를 늘리고, 배치 종료 후 다시 줄이는 스케줄 설정
다운타임 방지: 배치가 시작되기 전에 이미 용량을 확보 → CPU 100%·앱 중단 위험 감소
예측 가능한 스파이크에 맞는 선제적 스케일 아웃 → “워크로드 처리 + 다운타임 방지” 충족
Answer: A
요구사항
고객이 온프레미스 Microsoft Active Directory로 인증해 Amazon S3에 저장된 파일을 다운로드
고객 앱은 SFTP 클라이언트로 파일 다운로드
운영 오버헤드 최소화 + 고객 애플리케이션 변경 없음
→ SFTP 엔드포인트 + S3 백엔드 + AD 인증 + 관리형 서비스가 필요함.
A. AWS Transfer Family (SFTP for S3) + AD 인증
역할: AWS Transfer Family로 S3용 SFTP 서버 구성, 통합 Active Directory 인증 설정
SFTP: 고객이 기존 SFTP 클라이언트 그대로 사용 → 고객 앱 변경 없음
S3: SFTP로 접근 시 S3 버킷/객체가 파일로 노출 → S3에 저장된 파일 다운로드 가능
AD 인증: Transfer Family가 온프레미스 AD(또는 AD Connector)와 연동 → AD 사용자만 접근
운영: 관리형 서비스 — SFTP 서버·OS 직접 운영 불필요 → 운영 오버헤드 최소화
Answer: B
요구사항
수요 급증으로 AMI에서 대규모 EC2 프로비저닝 필요
Auto Scaling 그룹에서 인스턴스 실행
최소 초기화 대기 시간 필요 → 인스턴스가 가능한 한 빨리 사용 가능해야 함
→ AMI 기반 인스턴스가 가장 빨리 준비되도록 하는 구성이 필요함.
개념: EBS 스냅샷 복원과 대기 시간
AMI가 EBS 스냅샷 기반이면, 인스턴스 기동 시 볼륨이 스냅샷에서 복원됨
일반 복원: 볼륨 생성 후 첫 접근 시 스냅샷에서 블록을 읽어옴(지연 로딩) → 초기 I/O 지연 발생
EBS Fast Snapshot Restore(FSR): 스냅샷에 FSR을 켜두면, 그 스냅샷에서 만든 볼륨이 생성 시점에 이미 완전히 복원됨 → 초기화 대기 최소화
B. EBS 빠른 스냅샷 복원(FSR) + 스냅샷 기반 AMI + ASG AMI 교체
역할: 스냅샷에 EBS Fast Snapshot Restore(FSR) 활성화 → 그 스냅샷으로 AMI 생성 → Auto Scaling 그룹의 시작 템플릿/구성에서 해당 AMI 사용
최소 초기화 대기: FSR로 볼륨이 생성 시 곧바로 사용 가능 → 스케일 아웃 시 새 인스턴스의 EBS 초기화 대기 시간 최소화
대규모 프로비저닝: ASG가 같은 AMI로 여러 인스턴스를 띄울 때, 각 인스턴스의 볼륨이 빠르게 준비됨
Answer: A
요구사항
다중 계층 웹 앱: Aurora MySQL + EC2 애플리케이션 계층
IT 보안 지침: DB 자격 증명을 암호화하고 14일마다 교체
최소한의 운영 노력으로 충족
→ 자격 증명 암호화 + 14일 주기 자동 교체 + 관리형 서비스로 운영 부담 최소화가 필요함.
A. KMS + Secrets Manager + 14일 사용자 지정 순환
역할: AWS KMS 키로 암호화, AWS Secrets Manager에 DB 자격 증명 저장 → Aurora DB 클러스터와 연결, 14일 사용자 지정 순환 설정
암호화: Secrets Manager는 KMS로 시크릿 암호화 저장
14일마다 교체: Secrets Manager 자동 순환으로 14일 주기 설정 가능, Aurora 사용자 비밀번호까지 자동 갱신
Aurora 연동: 시크릿을 Aurora와 연결하면 순환 시 DB 비밀번호가 자동 업데이트됨
최소 운영: 관리형 서비스 — 순환 로직·Lambda 유지보수 불필요 → 최소한의 운영 노력 충족
B가 틀린 이유
Parameter Store로 자격 증명 저장·KMS 암호화는 가능하나, 14일마다 교체는 직접 구현해야 함
Lambda로 14일마다 비밀번호 교체 = 순환 로직·스케줄·에러 처리 등 운영 부담 증가
“최소한의 운영 노력”에는 Secrets Manager 내장 순환(A) 가 더 적합함
C가 틀린 이유
EFS에 자격 증명 파일 저장 + Lambda로 14일마다 순환 = 직접 구축·운영
EFS 마운트·파일 권한·Lambda 유지보수·앱에서 파일 읽기 등 운영 부담이 큼
“최소한의 운영 노력”과 맞지 않음
D가 틀린 이유
S3에 자격 증명 파일 저장 + 앱이 주기적으로 다운로드 + Lambda로 14일마다 순환 = 직접 구축·운영
동기화·캐시·에러 처리 등 운영 복잡도와 유지보수 부담이 있음
“최소한의 운영 노력”에는 Secrets Manager(A) 가 더 적합함
Answer: A
요구사항
Amazon RDS for MySQL: 기본(primary) + 읽기 전용 복제본 5개
복제본 지연: 1초를 초과하면 안 됨
정기 예약 저장 프로시저 실행
문제: 트래픽 증가 시 피크 시 복제본 지연 증가
목표: 복제 지연 최소화 + 앱 코드 변경 최소 + 지속적 운영 오버헤드 최소
→ 복제 지연이 적은 DB + MySQL 호환 + 관리형이 필요함.
A. Amazon Aurora MySQL로 마이그레이션
역할: Amazon Aurora MySQL로 이전 → 읽기 복제본을 Aurora 복제본으로 교체, Aurora Auto Scaling 구성, 저장 프로시저는 Aurora MySQL에서 그대로 사용(또는 네이티브 함수로 전환)
복제 지연 최소화: Aurora는 스토리지 수준 복제(redo 로그 스트림)로, RDS MySQL의 binlog 복제보다 지연이 훨씬 적음 → 1초 이내(보통 밀리초 단위) 유지에 유리
앱 변경 최소: MySQL 호환 → 연결 문자열(리더 엔드포인트 등)만 조정하면 됨
운영 최소화: 관리형 + Aurora Auto Scaling으로 읽기 복제본 수 자동 조정 → 지속적 운영 부담 감소
저장 프로시저: Aurora MySQL에서 저장 프로시저 지원 → 로직 유지 가능
Answer: D
요구사항
대규모 SaaS 플랫폼 재해 복구(DR) 계획
모든 데이터는 Amazon Aurora MySQL DB 클러스터에 저장
데이터를 보조 AWS 리전에 복제해야 함
가장 비용 효율적으로 충족
→ Aurora 데이터를 보조 리전으로 복제하는 관리형·비용 효율 솔루션이 필요함.
D. Aurora 글로벌 데이터베이스 + 보조 리전에 최소 1개 DB 인스턴스
역할: Aurora 글로벌 데이터베이스로 주 리전 → 보조 리전 스토리지 수준 복제 설정, 보조 리전에 최소 1개 DB 인스턴스 지정
데이터 복제: Aurora 글로벌 DB가 주 → 보조 리전으로 자동 복제 (보통 1초 미만 지연)
비용 효율: DMS·별도 복제 파이프라인 없이 Aurora 기본 기능으로 복제 → 복제 비용·운영 부담 최소
DR 준비: 보조 리전에 최소 1개 인스턴스가 있으므로 장애 시 빠른 페일오버 가능 (인스턴스 추가 대기 불필요)
“보조 리전에 데이터 복제” + “가장 비용 효율적” + “DR 가능” 모두 충족
Answer: C
요구사항
사용자 지정 앱이 자격 증명이 내장된 상태로 Amazon RDS MySQL에서 정보 조회
경영진: 최소한의 프로그래밍 노력으로 앱을 더 안전하게 만들어야 함
→ 내장 자격 증명 제거 + 안전한 저장소 + 앱은 저장소에서 로드 + 자동 교체(순환) 를 관리형 기능으로 처리하는 것이 필요함.
C. Secrets Manager 저장 + 앱에서 로드 + Secrets Manager로 RDS 자격 증명 순환 일정
역할: RDS MySQL에 앱용 사용자 자격 증명 생성 → AWS Secrets Manager에 저장 → 앱은 Secrets Manager에서 DB 자격 증명 로드, Secrets Manager로 RDS MySQL 앱 사용자 자격 증명 교체 일정 설정
보안 강화: 자격 증명을 코드에서 제거하고 Secrets Manager(KMS 암호화)에 두고, 앱은 런타임에 API로 조회 → 내장 자격 증명 제거
최소 프로그래밍: 자격 증명 순환을 Secrets Manager 내장 RDS 순환으로 설정 → 별도 Lambda 작성·유지보수 불필요 → “최소한의 프로그래밍 노력” 충족
RDS 연동: Secrets Manager가 RDS MySQL 사용자 비밀번호를 주기적으로 갱신하고 시크릿도 함께 업데이트
A가 틀린 이유
KMS는 암호화 키 생성·관리용이며, DB 자격 증명(사용자명/비밀번호) 을 저장·조회하는 서비스가 아님
“KMS에서 데이터베이스 자격 증명을 로드”하는 구성은 KMS 용도와 맞지 않음 → 자격 증명 저장·로드는 Secrets Manager(C) 가 맞음
Answer: A
요구사항
미디어 회사 웹 사이트: ALB + EC2 + Amazon Aurora
사이버 보안 팀: 애플리케이션이 SQL 주입에 취약하다고 보고
이 문제를 어떻게 해결할지 제시
→ HTTP 요청 단계에서 SQL 주입 시도를 차단·필터링하는 구성이 필요함.
A. ALB 앞에 AWS WAF + 적절한 Web ACL
역할: ALB 앞에 AWS WAF를 두고, Web ACL에 SQL 주입 방지 규칙(예: AWS Managed Rules – SQL injection)을 연결
동작: 사용자 요청 → WAF(요청 내용 검사) → SQL 주입 패턴이면 차단 → 정상만 ALB → EC2·Aurora
SQL 주입 대응: WAF는 HTTP/HTTPS 요청 본문·헤더·쿼리를 검사해 SQL 주입 패턴을 가진 요청을 차단할 수 있음
관리형: AWS Managed Rules for SQL injection 등으로 규칙만 설정하면 됨 → “SQL 주입에 취약한 문제”를 가장 직접적으로 해결
Answer: D
요구사항
AWS Lake Formation으로 관리하는 Amazon S3 데이터 레이크
데이터 레이크 데이터 + Aurora MySQL 운영 데이터를 QuickSight에서 시각화
마케팅 팀이 데이터베이스 열의 일부만 접근하도록 열 수준 권한 적용
최소한의 운영 오버헤드
→ 데이터 레이크·DB 통합 + 열 수준 접근 제어 + Lake Formation 활용이 필요함.
D. Lake Formation 청사진 + Lake Formation 열 수준 제어 + QuickSight(Athena)
역할: Lake Formation 청사진으로 Aurora MySQL → S3 데이터 레이크 수집, Lake Formation으로 QuickSight 사용자(마케팅 팀)에 대한 열 수준 권한 설정, QuickSight는 Amazon Athena를 데이터 소스로 사용
열 수준 권한: Lake Formation은 Data Catalog 테이블·열 단위 권한을 지원 → 마케팅 팀에게 허용된 열만 부여 가능
QuickSight + Athena: QuickSight가 Athena로 쿼리하면 Lake Formation이 적용된 권한으로 열 수준 필터가 적용됨
운영 최소화: Lake Formation으로 수집·권한 관리, Athena는 서버리스 → EMR·클러스터 운영 불필요
A가 틀린 이유
EMR로 DB → QuickSight SPICE 수집 시 필요한 열만 포함하는 ETL은 가능하나, 사용자(팀)별 열 수준 접근 제어는 EMR만으로는 어렵고, Lake Formation이 제공하는 열 수준 권한과는 다름
EMR는 클러스터 관리로 운영 부담이 있고, “최소한의 운영 오버헤드”에는 D(Lake Formation + Athena) 가 더 적합함
B가 틀린 이유
IAM 정책은 리소스(버킷·접두사)·서비스 수준 제어용이며, 테이블·열 단위(열 수준) 접근 제어를 지원하지 않음
“열 수준 권한”을 IAM만으로 적용하는 것은 불가능하고, Lake Formation(D) 가 열 수준 제어에 적합함
C가 틀린 이유
S3 버킷 정책은 객체·접두사 단위 접근 제어용이며, 쿼리 결과의 특정 열만 허용하는 열 수준 제어를 할 수 없음
“QuickSight 사용자에 대한 열 수준 액세스 제어를 S3 버킷 정책으로”는 기술적으로 맞지 않음 → Lake Formation(D) 가 맞음
Answer: C
요구사항
매주 스크립트 배치 작업이 EC2(Auto Scaling 그룹)에서 실행
트랜잭션 수는 가변이지만, 실행 시 기준 CPU 사용률은 60% 이상
작업 실행 30분 전에 용량을 프로비저닝해야 함
현재: 엔지니어가 ASG 파라미터를 수동으로 수정
제약: ASG에 필요한 용량 추세를 분석할 리소스 없음
목표: ASG 원하는 용량을 자동으로 수정하는 방법 필요, 최소한의 운영 오버헤드
→ 예측 가능한 시점(매주) 에 30분 전 용량 확보 + 트랜잭션 변동 반영 + 추세 분석 없이 자동화가 필요함.
C. 예측 조정 정책 + CPU 60% 목표 + 30분 전 사전 실행(프리워밍)
역할: 예측 조정(Predictive scaling) 정책 생성 — 예측(forecast) 기반으로 스케일, 스케일링 지표 = CPU 사용률, 목표 60%, 정책에서 작업 실행 30분 전에 인스턴스가 사전 실행(프리워밍) 되도록 설정
30분 전 용량: 예측 조정은 과거 패턴·예측으로 부하 시점을 예측하고, 인스턴스 워밍 시간(프리워밍) 을 30분으로 두면 부하 예상 시점 30분 전에 인스턴스를 늘림 → “작업 실행 30분 전 용량 프로비저닝” 충족
자동화: 추세 분석 리소스 불필요 — 예측 조정이 과거 메트릭으로 자동 예측 → “용량 추세 분석할 리소스 없음” 조건 충족
가변 트랜잭션: 예측이 주간 변동을 반영해 필요 용량을 자동 조정 → “트랜잭션 수는 다를 수 있음”에 대응
최소 운영: 관리형 예측 조정 — 수동 ASG 조정·별도 추세 분석 불필요
Answer: B
요구사항
재해 복구(DR) 아키텍처 설계
MySQL DB가 프라이빗 서브넷 EC2에서 실행, 예약 백업 있음
DR 설계에 여러 AWS 리전 포함 필요
최소한의 운영 오버헤드
→ 다중 리전 DR + 관리형으로 운영 부담 최소화가 필요함.
C. Amazon Aurora 글로벌 데이터베이스
역할: MySQL을 Amazon Aurora 글로벌 데이터베이스로 이전 — 주 리전에 기본 DB 클러스터, DR 리전에 보조 DB 클러스터
다중 리전: Aurora 글로벌 DB는 주 리전 + 보조 리전(최대 5개) 구성 → 여러 AWS 리전 포함
데이터 복제: 스토리지 수준 복제로 주 → 보조 리전 자동 복제 (보통 1초 미만 지연)
최소 운영: 관리형 — 복제·페일오버·패치 등 AWS가 담당, EC2·MySQL 직접 운영 불필요
“다중 리전 DR” + “최소한의 운영 오버헤드” 모두 충족
B가 틀린 이유
RDS Multi-AZ + 다른 가용 영역의 읽기 복제본 = 같은 리전 내 다른 AZ
요구사항은 “여러 AWS 리전” 이므로 리전 간(크로스 리전) DR이 필요함
다중 리전 요구사항 미충족
Answer: A
요구사항
Java 앱이 Amazon SQS로 메시지 구문 분석
256KB 초과 메시지는 구문 분석 불가
50MB까지 큰 메시지를 구문 분석할 수 있게 해야 함
코드를 가장 적게 변경하여 충족
→ SQS 메시지 크기 제한(256KB) 을 우회하면서, 앱 변경을 최소화하는 방식이 필요함.
제약: SQS 메시지 크기
SQS 최대 메시지 크기 = 256KB (고정, 변경 불가)
50MB를 SQS 메시지 본문에 직접 넣을 수 없음 → 큰 페이로드는 S3 등에 두고, SQS에는 참조만 넣는 패턴 필요
A. Java용 Amazon SQS Extended Client Library + S3
역할: Amazon SQS Extended Client Library for Java 사용 → 256KB 초과 메시지는 자동으로 S3에 저장하고, SQS 메시지에는 참조(포인터) 만 넣음
동작: 앱은 기존처럼 메시지 전송/수신 API만 쓰고, 큰 페이로드 저장·조회는 라이브러리가 S3로 처리 → 50MB까지 처리 가능(실제로는 S3 기준 2GB까지 지원)
코드 변경 최소: 표준 SQS 클라이언트를 Extended Client로 교체 + S3 버킷 설정만 하면 됨 → “코드를 가장 적게 변경” 충족
표준 패턴: AWS가 권장하는 “큰 메시지 = S3 + SQS 참조”를 라이브러리로 자동화한 방식
Answer: A
요구사항
주요 웹 앱 콘텐츠에 대한 접근 제한 + 권한 부여로 콘텐츠 보호
서버리스 아키텍처 + 100명 미만 사용자용 인증 솔루션
기본 웹 애플리케이션과 통합, 웹 콘텐츠 전역 제공
사용자 증가에 따라 확장 가능
가능한 한 낮은 로그인 대기 시간
가장 비용 효율적으로 충족
→ 인증 + 권한 부여(콘텐츠 보호) + 전역 전달 + 저지연 + 서버리스·비용 효율이 필요함.
A. Cognito + Lambda@Edge + CloudFront (정답)
역할: Amazon Cognito로 인증, Lambda@Edge로 권한 부여(인가), Amazon CloudFront로 전 세계 웹 앱·콘텐츠 제공
인증: Cognito = 관리형 사용자 풀, 서버리스, 100명 미만에 비용 효율적, 저지연
권한 부여: Lambda@Edge가 CloudFront 엣지에서 Cognito JWT 검증 후 허용/거부 → 콘텐츠 접근 제한 (권한 부여 기술)
전역 제공: CloudFront = CDN으로 전 세계 엣지에서 콘텐츠 제공
저지연: Lambda@Edge가 엣지에서 검증 → 지역 Lambda보다 로그인·인가 지연 최소화
확장·비용: Cognito·Lambda@Edge·CloudFront 모두 사용량 기반 → 사용자 증가에 따라 확장, 비용 효율적
Answer: C
요구사항
온프레미스 NAS — SMB·NFS 공유를 클라이언트 워크스테이션에 제공
새 NAS 구매·지원 계약 갱신 원하지 않음
일부는 자주 액세스, 대부분 비활성
데이터를 Amazon S3로 마이그레이션
S3 수명 주기 정책 사용
클라이언트에는 동일한 모양과 느낌(SMB/NFS 파일 공유) 유지
AWS Storage Gateway를 솔루션에 포함
→ SMB·NFS를 그대로 제공하면서 백엔드는 S3이고 S3 수명 주기가 적용되는 파일 게이트웨이가 필요함.
D. Amazon S3 File Gateway
역할: S3 File Gateway는 NFS·SMB 파일 공유를 클라이언트에 제공하고, 백엔드 스토리지는 Amazon S3
동일한 모양과 느낌: 클라이언트는 기존처럼 SMB/NFS로 접근 → NAS와 동일한 파일 공유 경험
S3 마이그레이션: 파일은 S3 버킷(객체) 로 저장 → “데이터를 S3로 마이그레이션” 충족
S3 수명 주기: S3 버킷에 수명 주기 정책 설정 가능 → 자주 쓰는 데이터는 Standard, 비활성 데이터는 IA/Glacier 등으로 이동
Storage Gateway 중 SMB·NFS + S3 조합은 S3 File Gateway만 해당
C가 틀린 이유
Amazon FSx File Gateway는 Amazon FSx(Windows File Server 또는 NetApp ONTAP)를 백엔드로 하는 파일 공유
백엔드가 S3가 아니라 FSx이므로, “데이터를 S3로 마이그레이션” 및 “S3 수명 주기 정책” 요구사항과 맞지 않음
S3 백엔드 + 수명 주기는 S3 File Gateway(D) 가 맞음
Answer: A
요구사항
EC2에서 애플리케이션 실행, 특정 인스턴스 제품군·다양한 크기로 표준화
향후 3년 동안 비용 절감 극대화
향후 6개월 내 애플리케이션 인기도·사용량에 따라 인스턴스 패밀리·크기 변경 가능해야 함
→ 장기 할인(3년) + 인스턴스 패밀리·크기 변경 유연성이 동시에 필요함.
A. 컴퓨팅 절감 플랜 (Compute Savings Plan)
역할: Compute Savings Plan = 시간당 컴퓨팅 사용량($) 에 대해 1년 또는 3년 약정 → EC2·Fargate·Lambda 사용에 할인 적용
3년 비용 절감: 3년 약정(전액 선결제 등) 시 높은 할인 → “3년 비용 절감 극대화” 충족
유연성: 인스턴스 패밀리·크기·리전·OS 변경 가능 — 예: m5 → c5, large → xlarge로 바꿔도 절감 플랜 할인이 그대로 적용 → “6개월 내 인스턴스 패밀리·크기 변경” 가능
가장 비용 효율적으로 “3년 절감 + 6개월 내 변경”을 동시에 만족
B가 틀린 이유
EC2 인스턴스 절감 플랜은 같은 인스턴스 패밀리 내에서만 크기·리전·OS 변경 가능
인스턴스 패밀리 변경(예: m5 → c5)은 적용 대상이 아님 → “인스턴스 패밀리 및 크기 변경” 중 패밀리 변경 요구사항 미충족
Compute Savings Plan(A) 는 패밀리·크기 모두 변경 가능하므로 A가 적합함
C가 틀린 이유
영역 예약 인스턴스(Zonal RI) 는 특정 AZ의 특정 인스턴스 타입에 고정
인스턴스 패밀리·크기 변경 시 해당 RI는 적용되지 않음 → 유연성 없음, 요구사항 미충족
D가 틀린 이유
표준 예약 인스턴스(Standard RI) 는 특정 인스턴스 타입(리전 단위)에 고정
인스턴스 패밀리·크기 변경 시 RI는 다른 타입에 적용되지 않음 → 유연성 없음, 요구사항 미충족
Answer:
요구사항
웨어러블로 많은 참가자 데이터 수집 → Amazon DynamoDB 저장, 앱으로 분석
데이터 워크로드는 일정하고 예측 가능
DynamoDB 예상 예산 이하 유지
가장 비용 효율적으로 충족
→ 예측 가능한 워크로드에 맞춰 용량을 정해 두고, 비용을 예측 가능하게 만드는 구성이 필요함.
B. 프로비저닝 모드 + RCU·WCU 지정 (정답)
역할: 프로비저닝 모드로 RCU(읽기 용량 단위)·WCU(쓰기 용량 단위) 를 예상 워크로드에 맞게 지정
비용 효율: 워크로드가 일정·예측 가능할 때 프로비저닝이 온디맨드보다 일반적으로 저렴 (시간당 고정 단가로 용량만 맞추면 됨)
예산 관리: 용량(RCU/WCU) 을 고정하면 월 비용이 예측 가능 → “예상 예산 이하 유지”에 유리
요구사항: “일정·예측 가능” + “예산 이하” + “가장 비용 효율적”을 한 번에 만족
B: 프로비저닝 모드 + RCU·WCU 지정(예상 워크로드 기준) → 일정·예측 가능 워크로드에 비용 효율 + 예산 예측 가능 → 요구사항 충족
A: Standard-IA는 저장·접근 패턴에 따라 선택 사항, “가장 비용 효율”의 핵심은 B(프로비저닝)
C, D: 온디맨드는 RCU/WCU 지정·예약 용량 개념이 없고, 일정 워크로드에는 프로비저닝이 더 적합
Answer: B
요구사항
ap-southeast-3 리전 Amazon Aurora PostgreSQL에 기밀 데이터 저장
AWS KMS 고객 관리형 키로 DB 암호화
인수된 회사로, ap-southeast-3의 인수 회사 AWS 계정과 데이터베이스 백업을 안전하게 공유해야 함
→ 암호화된 스냅샷을 다른 계정이 복호화·사용할 수 있도록 안전하게 공유해야 함.
B. 스냅샷 생성 + KMS 키 정책에 인수 회사 계정 추가 + 스냅샷 공유
역할: 데이터베이스 스냅샷 생성(고객 관리형 KMS 키로 암호화) → KMS 키 정책에 인수 회사 AWS 계정을 추가(해당 계정이 키로 복호화할 수 있도록) → 인수 회사 계정과 스냅샷 공유
안전한 공유: 스냅샷은 그대로 암호화 상태로 공유되고, 인수 회사는 키 정책으로 부여된 권한으로 복호화 후 복사/복원 가능
동작: 크로스 계정으로 스냅샷을 공유하면, 인수 회사는 스냅샷을 보지만 복호화하려면 해당 KMS 키 사용 권한이 필요함 → 키 정책에 인수 회사 계정 추가가 필수
“기밀 데이터를 안전하게 공유” 요구사항 충족
A: 암호 해제 스냅샷 공유 = 보안 위반
C: AWS 관리형 키 = 키 정책 수정·다른 계정 추가 불가
D: 스냅샷 다운로드·S3 업로드 = RDS 스냅샷 공유 방식 아님
Answer: A, D
요구사항
us-east-1 Amazon RDS for Microsoft SQL Server 단일 AZ, 100GB — 고객 트랜잭션 저장
DB 인스턴스에 대한 고가용성 및 자동 복구 필요
1년에 여러 번 RDS에서 보고서 실행
보고 프로세스 때문에 트랜잭션이 고객 계정에 반영되는 데 시간이 더 걸림
보고 프로세스 성능 개선 필요
→ 고가용성·자동 복구 1개 + 보고 성능 개선 1개, 총 2개 선택.
A. 단일 AZ → 다중 AZ 배포로 수정
역할: 단일 AZ DB 인스턴스를 다중 AZ 배포로 변경
고가용성: 주 인스턴스 + 다른 AZ의 대기(standby) → AZ 장애 시 자동 장애 조치
자동 복구: 장애 시 자동 페일오버로 복구
“고가용성 및 자동 복구” 요구사항 충족
C. 다른 AZ에 읽기 전용 복제본 생성 + 보고는 복제본으로
역할: 다른 가용 영역에 읽기 전용 복제본 생성, 보고 관련 요청은 모두 읽기 전용 복제본으로 보냄
보고 성능: 보고 쿼리가 복제본에서만 실행되므로 주 인스턴스(OLTP) 부하가 줄어듦 → 보고 프로세스 성능 향상 + 트랜잭션 반영 지연 완화
“보고 프로세스 성능 향상” 요구사항 충족
A: 다중 AZ로 전환 → 고가용성·자동 복구 충족
C: 읽기 전용 복제본 생성 + 보고는 복제본으로 → 보고 성능 향상 + 주 인스턴스(트랜잭션) 부하 감소
B: 스냅샷 복원 = 지속 복제·자동 장애 조치 아님
D: RDS Custom = 고가용성·보고 성능 해결 아님
E: RDS Proxy·유지보수 기간 제한 = 보고 성능 향상 아님
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 401-450 (0) | 2026.02.02 |
|---|---|
| AWS SAA-C03 Dump 351-400 (0) | 2026.02.01 |
| AWS SAA-C03 Dump 251-300 (0) | 2026.01.30 |
| AWS SAA-C03 Dump 201-250 (0) | 2026.01.30 |
| AWS SAA-C03 Dump 151-200 (1) | 2026.01.30 |
