AWS SAA-C03 Dump 51-100
Answer: B, D
요구사항
- 데이터 소스: 주문 배송 통계 REST API
- 처리: 통계 추출 → 읽기 쉬운 HTML로 가공
- 전달: 매일 아침, 여러 이메일 주소로 보고서 발송
즉, “매일 아침 스케줄” + “API 조회 → HTML 보고서 → 다수 수신자 이메일” 을 만족하는 조합을 고르는 문제
B. Amazon SES로 데이터를 HTML로 포맷하고 보고서를 이메일로 보냄
HTML 이메일: SES는 HTML 본문 이메일 발송을 지원합니다.
다수 수신자: 수신자 목록을 지정해 한 번에 여러 주소로 보낼 수 있습니다.
요구사항의 “읽기 쉬운 HTML 형식” + “여러 이메일 주소로 보고서”를 직접 충족합니다.
D. EventBridge(CloudWatch Events) 예약 이벤트로 Lambda를 호출해, 그 Lambda가 애플리케이션 API를 쿼리하도록 구성
매일 아침 실행: EventBridge 규칙에 cron(예: cron(0 8 * * ? *))을 넣어 “매일 아침” 한 번 실행되게 할 수 있습니다.
API 조회: Lambda에서 해당 REST API를 호출해 배송 통계를 가져옵니다.
흐름: EventBridge(스케줄) → Lambda(API 호출 + 데이터 가공/HTML 생성) → SES(B 선택지)로 이메일 발송.
“배송 통계 추출”과 “스케줄 실행”을 담당하는 단계로 적합합니다.
정리: D가 “언제, 어떻게 데이터를 가져올지”, B가 “어떤 서비스로 어떻게 보낼지”를 담당하는 조합입니다.
Answer: C
요구사항
- 온프레미스 → AWS 마이그레이션 : AWS에서 동일/유사 기능 제공
- 출력 파일 크기 : 수십 GB ~ 수백 TB (매우 크고 가변)
- 표준 파일 시스템 구조 : 디렉터리/파일처럼 쓰는 POSIX 파일시스템 (NFS 등), 객체 스토리지 아님
- 자동 확장 : 워크로드에 맞춰 스토리지·컴퓨트 모두 확장
- 고가용성 : 다중 AZ, 장애 시에도 서비스 유지
- 최소 운영 오버헤드 : 관리형 서비스 위주, 운영 부담 최소화
C. 다중 AZ Auto Scaling 그룹의 EC2 + Amazon EFS
1. 표준 파일 시스템 구조
Amazon EFS는 관리형 NFS로, POSIX 파일시스템을 제공합니다.
EC2에서 마운트해 기존처럼 디렉터리/파일로 읽고 쓸 수 있어, “표준 파일 시스템 구조로 저장” 요구를 충족합니다.
2. 다양한 크기·자동 확장
EFS는 용량을 미리 프로비저닝하지 않고, 파일 추가/삭제에 따라 자동으로 늘었다 줄었다 합니다.
수십 GB ~ 수백 TB(페타바이트 수준)까지 대응 가능합니다.
EC2는 Auto Scaling 그룹으로 트래픽/로드에 맞춰 인스턴스 수가 자동으로 늘어나므로, 컴퓨트도 자동 확장됩니다.
3. 고가용성
다중 AZ ASG: 한 AZ 장애 시 다른 AZ 인스턴스로 처리 가능.
EFS: 한 리전 내 여러 AZ에 자동으로 분산되어 저장되므로 고가용성입니다.
4. 최소 운영 오버헤드
EFS는 서버/디스크 프로비저닝·패치 없이 관리형으로 제공됩니다.
EC2 + ASG + EFS 조합은 Kubernetes 없이 단순해, EKS보다 운영 부담이 적습니다.
Answer: C
요구사항
S3에 회계 기록 저장 : 저장소는 Amazon S3
1년 동안 즉시 액세스 : 첫 1년은 검색/다운로드 지연 없이 접근 가능해야 함
이후 9년 더 보관 : 총 10년 보관
10년 동안 누구도 삭제 불가 : 관리자·루트 포함, 어느 사용자도 10년 전에는 삭제/보존기간 단축 불가 (진짜 WORM)
최대한의 복원력 : 가용성·내구성 측면에서 최대 복원력 (멀티 AZ 등)
C. 1년 후 S3 Standard → S3 Glacier Deep Archive 수명 주기 전환 + 규정 준수 모드 S3 Object Lock 10년
1. 1년 동안 즉시 액세스
첫 1년은 S3 Standard에 보관 → 즉시 조회·다운로드 가능.
2. 이후 9년 보관
수명 주기로 1년 후 S3 Glacier Deep Archive로 전환 → 10년까지 보관.
2년차부터는 “즉시 액세스” 요구가 없으므로 아카이브 스토리지가 적합.
3. 10년 동안 누구도 삭제 불가
S3 Object Lock – 규정 준수(Compliance) 모드
보존 기간 동안 루트·관리자 포함 삭제 및 보존 기간 단축 불가.
s3:BypassGovernanceRetention 같은 권한으로도 우회 불가.
IAM/ACP가 아니라 스토리지 수준 WORM이라 “관리자·루트도 삭제 불가”를 만족.
4. 최대한의 복원력
S3 Standard: 멀티 AZ, 99.99% 내구성.
Glacier Deep Archive: S3와 동일한 99.999999999% 내구성, 멀티 AZ 기반.
둘 다 단일 AZ가 아니라 복원력이 높음.
Answer: C
요구사항
Windows 워크로드 : Windows 환경, Windows 파일 공유(SMB) 사용
현재 구조 : 2대의 EC2에서 Windows 파일 공유, 서로 동기화·중복 복사
목표 : 고가용성 + 내구성 있는 스토리지
접근 방식 유지 : 사용자가 지금처럼 파일에 접근
즉, Windows SMB 파일 공유를 유지하면서 고가용성·내구성을 갖춘 관리형 솔루션을 고르는 문제입니다.
C. 다중 AZ 구성의 Windows 파일 서버용 Amazon FSx로 확장하고, 모든 데이터를 FSx로 마이그레이션
1. 접근 방식 유지
FSx for Windows File Server는 SMB(Windows 파일 공유) 를 제공합니다.
사용자는 계속 \\도메인\공유 형태로 접근하므로 “사용자가 현재 파일에 액세스하는 방식을 보존”합니다.
2. 고가용성
다중 AZ FSx for Windows는 여러 AZ에 복제되어 자동 장애 조치를 지원합니다.
2대 EC2가 서로 동기화하던 구조를, 관리형 다중 AZ 파일 서버 하나로 대체할 수 있습니다.
3. 내구성
FSx는 AWS 관리형 스토리지 위에서 복제·백업을 처리해 데이터 내구성을 제공합니다.
4. 운영 부담 감소
EC2 2대 동기화·장애 조치를 직접 구성할 필요 없이, 관리형 Windows 파일 서버로 전환할 수 있습니다.
Answer: C
요구사항
여러 서브넷 VPC : EC2 + RDS를 쓰는 애플리케이션용 VPC
2 AZ × 3 서브넷 = 6개 : AZ당 퍼블릭 서브넷, 프라이빗 서브넷, DB 전용 서브넷
RDS 접근 제한 : 프라이빗 서브넷의 EC2만 RDS에 접근 가능해야 함 (퍼블릭 서브넷 EC2는 접근 불가)
즉, “RDS에는 프라이빗 서브넷 EC2만 접속 가능하게” 만족하는 방법을 고르는 문제다.
C. 프라이빗 서브넷 EC2에 붙은 보안 그룹의 인바운드를 허용하는 보안 그룹을 만들고, 그 보안 그룹을 DB 인스턴스에 연결
RDS에 “누가 접속할 수 있는지”는 보안 그룹으로 제어한다.
보안 그룹은 허용(Allow) 규칙만 가진다. “프라이빗 EC2만 허용” = “그 EC2들이 쓰는 보안 그룹만 인바운드 허용”으로 구현하면 된다.
DB용 보안 그룹에서 인바운드를 “프라이빗 서브넷 EC2에 붙은 보안 그룹”만 허용하도록 만들고, 이 보안 그룹을 RDS에 연결하면:
프라이빗 서브넷 EC2(해당 SG) → RDS: 허용
퍼블릭 서브넷 EC2(다른 SG) → RDS: 규칙에 없음 → 차단
따라서 “프라이빗 서브넷 EC2만 RDS 접근” 요구사항을 정확히 충족한다.
Answer: C
요구사항
- Route 53에 도메인 등록 : 회사 도메인을 이미 보유, 생성할 필요 X
- API Gateway : ca-central-1 리전의 리전(Regional) API Gateway가 백엔드 API 공용 인터페이스
- 타사 서비스 : 해당 API를 안전하게 사용
목표 : 타사가 HTTPS로 접속하고, 회사 도메인과 그 도메인용 인증서로 API Gateway URL을 쓰도록 구성
C. 리전 API Gateway 엔드포인트(커스텀 도메인) 생성 → 회사 도메인 연결 → 동일 리전(ca-central-1) ACM에 인증서 가져오기 → API Gateway 엔드포인트에 인증서 연결 → Route 53에서 해당 엔드포인트로 트래픽 라우팅
1. 리전 API Gateway
ca-central-1에 있는 API이므로, 커스텀 도메인도 리전 API Gateway 기준으로 구성하는 것이 맞다.
2. 커스텀 도메인 + 인증서
API Gateway에서 커스텀 도메인 이름을 만들고 회사 도메인(예: api.company.com)을 연결한다.
리전 API Gateway는 커스텀 도메인용 인증서를 API Gateway가 있는 리전(ca-central-1) 의 ACM에 두어야 한다.
C는 “동일한 리전의 ACM으로 인증서 가져오기”라고 했으므로 ca-central-1에 인증서를 두는 올바른 구성이다.
3. 인증서를 API Gateway 엔드포인트에 연결
커스텀 도메인 리소스(엔드포인트)에 ACM 인증서를 붙이면, 클라이언트가 회사 도메인으로 접속할 때 해당 인증서로 HTTPS가 제공된다.
4. Route 53
회사 도메인에 대한 A(별칭) 레코드를 만들어, API Gateway 커스텀 도메인 엔드포인트로 트래픽을 보내면 된다.
C는 “API Gateway 엔드포인트로 트래픽을 라우팅하도록 Route 53 구성”으로 이 흐름을 설명한다.
정리하면, 리전 API Gateway + 같은 리전 ACM + 커스텀 도메인 + Route 53 조합으로 “회사 도메인 + 해당 인증서로 HTTPS API”를 만드는 표준 방식이다.
Answer: B
요구사항
소셜 미디어 웹사이트 : 사용자가 이미지를 업로드해 공유
검증 목표 : 이미지에 부적절한 콘텐츠가 없는지 확인
즉, “이미지용 부적절 콘텐츠 감지”를 관리형 서비스로 최대한 쉽게 만드는 방법을 고르는 문제다.
B. Amazon Rekognition으로 부적절한 콘텐츠를 감지하고, 신뢰도가 낮은 예측에는 인적 검토를 사용
1. 이미지 분석에 맞는 서비스
Amazon Rekognition은 이미지·동영상 분석 전용 서비스다.
Content Moderation 기능으로 이미지에서 부적절한 콘텐츠(폭력, 선정적 콘텐츠 등)를 감지하고, 신뢰도 점수를 반환한다.
2. 신뢰도가 낮은 경우 인적 검토
Rekognition이 낮은 신뢰도로 반환한 결과만 사람이 다시 검토하면, 자동화와 품질을 함께 만족시킬 수 있다.
Amazon A2I 등으로 이런 워크플로를 붙일 수 있다.
정리하면, “이미지 + 부적절 콘텐츠 감지 + 개발 최소화”에 가장 잘 맞는 조합이다.
Answer: C
요구사항
- 컨테이너에서 중요한 애플리케이션 실행 : 확장성·가용성 요구 충족
- 중요 애플리케이션 유지보수에 집중 : 인프라보다 앱 운영에 집중
- 기본 인프라 책임 회피 : 컨테이너 워크로드를 돌리는 밑단 인프라(서버)의 프로비저닝·관리 책임을 지지 않겠다
즉, “컨테이너는 쓰되, 서버(EC2 등)는 프로비저닝·관리하지 않는 방식”을 고르는 문제다.
C. AWS Fargate에서 Amazon ECS를 사용
1. 인프라 프로비저닝·관리 책임 없음
Fargate는 서버리스 컨테이너 실행 서비스다.
EC2를 띄우거나, OS 패치하거나, 노드 스케일링할 필요가 없다.
태스크(컨테이너 + CPU/메모리)만 정의하면, AWS가 그 아래 서버를 관리한다.
“컨테이너화된 워크로드를 실행하는 기본 인프라의 프로비저닝 및 관리에 대한 책임을 원하지 않는다”는 요구와 정확히 맞는다.
2. 확장성·가용성
ECS가 오케스트레이션(스케줄링, 서비스 단위 스케일링, ALB 연동)을 담당하고, Fargate가 그 위에서 실행된다.
다중 AZ, Auto Scaling, 로드 밸런서와 함께 사용해 확장성·가용성을 맞출 수 있다.
3. 애플리케이션 유지보수에 집중
서버 관리가 없으므로, 팀은 컨테이너 이미지·태스크 정의·앱 로직에만 집중하면 된다.
정리하면, “컨테이너는 쓰되 서버는 관리하지 않는다”는 조건을 만족하는 건 ECS + Fargate다.
Answer: D
요구사항
- 300개 이상의 글로벌 웹사이트·앱 : 여러 소스에서 클릭스트림 발생
- 매일 30TB 이상 : 대용량·고처리량 수집·저장·분석 필요
- 목표 : 클릭스트림 데이터를 전송(수집·이동) 하고 처리(분석) 할 플랫폼
즉, “많은 소스 → 한곳으로 수집·전송 → 대용량 분석”을 만족하는 아키텍처를 고르는 문제다.
D. Kinesis Data Streams로 데이터 수집 → Kinesis Data Firehose로 S3 데이터 레이크로 전송 → Redshift에서 분석
1. 수집(전송의 첫 단계)
Kinesis Data Streams는 실시간 스트리밍 수집용 서비스다.
300개 이상 웹/앱에서 SDK·API 등으로 이벤트를 보내면, 고처리량으로 수집할 수 있다.
30TB/일 수준의 스트리밍 이벤트 수집에 적합하다.
2. 데이터 레이크로 전송
Kinesis Data Firehose는 스트림을 받아 S3로 연속 전달한다.
Data Streams → Firehose → S3 구성으로 “클릭스트림을 S3 데이터 레이크로 전송”하는 표준 패턴이다.
전송 중 간단한 변환도 가능하다.
3. 처리·분석
Firehose로 Redshift에 직접 적재하거나, S3에 쌓인 데이터를 Redshift로 로드해 분석(쿼리·BI) 할 수 있다.
30TB/일급 대용량 분석에는 Redshift가 적합하다.
4. 관리형·확장성
Kinesis·Firehose·S3·Redshift 모두 관리형이라, 인프라 프로비저닝·운영 부담이 상대적으로 적다.
정리하면, “수집(Streams) → 전송(Firehose → S3) → 분석(Redshift)” 흐름이 요구사항에 맞다.
Answer: C
요구사항
- ALB 뒤 웹사이트 : HTTP·HTTPS를 각각 처리하도록 리스너가 있음
- 목표 : 모든 요청이 HTTPS를 쓰도록 웹사이트로 전달
즉, HTTP(80)로 들어오는 요청을 HTTPS(443)로 리디렉션하는 방법을 고르는 문제다.
C. ALB에서 리스너 규칙을 만들어 HTTP 트래픽을 HTTPS로 리디렉션
1. ALB 리스너 규칙
ALB에는 포트별 리스너(예: 80, 443)가 있고, 각 리스너에 규칙(액션) 을 둘 수 있다.
HTTP(80) 리스너의 기본 액션(또는 규칙)을 Redirect로 두고, 프로토콜을 HTTPS, 포트 443으로 지정하면 된다.
2. 동작 방식
사용자가 http://example.com 으로 접속하면 ALB가 HTTP 301/302 리디렉션 응답을 보내 https://example.com 으로 보낸다.
사용자는 한 번만 HTTP로 요청하고, 이후에는 HTTPS로 접속하게 된다.
3. 요구사항 충족
“요청이 HTTPS를 사용하도록 모든 요청을 웹사이트로 전달” = HTTP 요청을 HTTPS URL로 리디렉션하는 것과 동일하다.
ALB의 리디렉션 액션은 이 목적에 맞는 표준 방법이다.
D NLB는 4계층(L4) 로드 밸런서다.
SNI는 TLS에서 호스트명을 알려주는 용도로, “HTTP를 HTTPS로 리디렉션”과는 별개다.
Answer: C
요구사항
- 2계층 웹 앱 : EC2(애플리케이션) + RDS(데이터베이스)
- 하드코딩 금지 : 애플리케이션 코드에 DB 자격 증명을 넣지 않음
- 정기적 자동 교체 : DB 자격 증명을 자동으로 순환(rotation) 하는 방식
- 최소 운영 오버헤드 : 순환·관리 로직을 직접 만들지 않고 관리형 기능 활용
즉, “자격 증명은 코드 밖에 두고, 자동 순환을 최소 운영으로 구현”하는 방법을 고르는 문제다.
C. DB 자격 증명을 AWS Secrets Manager에 저장 → 보안 비밀 자동 순환 활성화 → EC2 역할로 Secrets Manager 접근 권한 부여
1. 하드코딩 제거
자격 증명은 Secrets Manager에만 저장하고, EC2 앱은 IAM 역할로 GetSecretValue API를 호출해 런타임에 조회한다.
코드에는 자격 증명을 넣지 않는다.
2. 정기적 자동 교체(순환)
Secrets Manager는 RDS 자격 증명용 자동 순환을 제공한다.
순환 시 Secrets Manager가 RDS 비밀번호를 변경하고, 보안 비밀 값을 갱신한다.
사용자가 순환 로직(Lambda 등)을 직접 만들 필요가 없어 운영 오버헤드가 최소다.
3. 최소 운영
순환 스케줄 설정, RDS 연동, 비밀 값 갱신을 AWS가 처리한다.
EC2에는 Secrets Manager 접근용 IAM 역할만 붙이면 된다.
정리하면, “자격 증명 보관 + 자동 순환 + 최소 운영”을 한 번에 만족하는 건 Secrets Manager다.
Answer: D
요구사항
- ALB 뒤 공개 웹 애플리케이션 : ALB에 SSL/TLS 종료
- 에지에서 암호화 : 클라이언트–ALB 구간을 SSL/TLS로 암호화
- 외부 CA에서 발급한 인증서 : DigiCert, 회사 CA 등 AWS가 아닌 인증 기관에서 발급한 인증서 사용
- 매년 만료 전 교체 : 인증서 만료 전에 정기적으로 교체해야 함
즉, “외부 CA 인증서를 쓰면서, 만료 전에 교체하는 방법”을 고르는 문제다.
D. ACM으로 SSL/TLS 인증서를 가져오기(Import) → ALB에 적용 → EventBridge(CloudWatch Events) 로 만료 시 알림 → 수동으로 인증서 교체
1. 외부 CA 인증서 사용
“가져옵니다”는 ACM의 인증서 가져오기(Import) 를 의미한다.
외부 CA에서 발급받은 인증서(인증서 본문 + 개인키 + 체인)를 ACM에 올리면, ALB에 그 인증서를 붙여서 사용할 수 있다.
따라서 “외부 CA에서 발급한 SSL/TLS 인증서로 에지 암호화” 요구를 충족한다.
2. 매년 만료 전 교체
ACM에서 가져온(Import) 인증서는 자동 갱신이 없다.
AWS가 갱신해 주는 것은 “ACM에서 발급 요청한 공인 인증서”뿐이다.
그래서 “만료 전에 교체”는 만료 시점 알림 + 수동 교체로 처리하는 것이 맞다.
EventBridge(CloudWatch Events) 로 만료일 근처에 알림을 보내고, 새 인증서를 외부 CA에서 발급받아 다시 ACM에 가져와 ALB에 적용하는 방식이 요구사항에 맞다.
3. 최소한의 설계
외부 CA 인증서를 쓰는 경우, “관리형 갱신”을 쓸 수 없으므로 “알림 + 수동 교체”가 현실적인 최소 운영 방식이다.
정리하면, 외부 CA 인증서 = Import, Import 인증서 = 자동 갱신 없음 → 따라서 D(가져오기 + 알림 + 수동 교체) 가 정답이다.
Answer: A
요구사항
- 문서 관리 앱 : 700,000명 등록, AWS 인프라
- 기능 : 큰 .pdf 파일을 .jpg 이미지로 변환
- 파일 크기 : PDF 평균 5MB
- 저장 : 원본(PDF) 와 변환본(JPG) 둘 다 보관
- 확장성 : 수요가 빠르게 늘어나도 대응 가능해야 함
- 비용 : 가장 비용 효율적인 솔루션
즉, “PDF→JPG 변환 + 원본/변환본 보관 + 확장 가능 + 비용 효율”을 만족하는 구성을 고르는 문제다.
A. PDF를 Amazon S3에 저장 → S3 PUT 이벤트로 Lambda 호출 → Lambda가 PDF를 JPG로 변환 후 S3에 다시 저장
1. 원본·변환본 보관
원본 PDF는 S3에 업로드된 그대로 두고, 변환된 JPG를 같은 버킷(또는 다른 prefix/버킷)에 저장하면 된다.
S3는 대용량·저비용 객체 스토리지라 “원본 + 변환본 보관”에 적합하다.
2. 확장성
S3 이벤트로 Lambda가 호출되므로, 업로드 건수만큼 자동으로 병렬 처리된다.
Lambda와 S3 모두 관리형이라 트래픽이 늘어나도 별도 용량 설계 없이 확장된다.
3. 비용 효율
서버리스: EC2를 상시 켜 두지 않아 유휴 비용이 없다.
실행 시에만 과금: Lambda(호출 수·실행 시간) + S3(저장·요청).
수요가 들쭉날쭉하거나 급증해도 “쓰는 만큼만” 지불하므로 가장 비용 효율적이다.
4. 5MB PDF 처리
Lambda는 S3에서 객체를 읽어 처리하므로 5MB PDF도 문제 없다.
메모리·실행 시간 한도 내에서 변환 라이브러리(pdf2image, ImageMagick 등) 사용 가능하다.
정리하면, “저장은 S3, 변환은 이벤트 기반 Lambda”로 확장성 + 비용 효율을 동시에 만족한다.
Answer: D
요구사항
- 온프레미스 : Windows 파일 서버, 5TB 이상 파일 데이터, 사용자·앱이 매일 사용
- AWS로 Windows 워크로드 이전 중 : 마이그레이션 진행 단계
- 이전 과정 동안 : AWS 파일 스토리지와 온프레미스 파일 스토리지 둘 다 접근 가능해야 함
- 최소 지연 시간 : 각 위치(온프레미스 / AWS)에서 해당 스토리지에 낮은 지연으로 접근
- 운영 오버헤드 최소 : 관리형 서비스 위주
- 기존 파일 액세스 패턴 유지 : Windows SMB(\\서버\공유) 방식 크게 바꾸지 않음
- Site-to-Site VPN 사용 중
즉, “마이그레이션 기간 동안 온프레미스·AWS 양쪽에서 지연 최소로 파일에 접근하고, Windows 파일 공유 방식과 운영 부담을 유지하는 방법”을 고르는 문제다.
D. AWS에 Windows 파일 서버용 FSx 배포 → 온프레미스에 FSx 파일 게이트웨이 배포 → 온프레미스 데이터를 FSx 파일 게이트웨이(→ FSx)로 이동 → 클라우드 워크로드는 FSx, 온프레미스 워크로드는 FSx 파일 게이트웨이 사용
1. 양쪽 스토리지에 최소 지연으로 접근
AWS 쪽 : 데이터는 FSx for Windows(AWS)에 있고, 클라우드 워크로드는 FSx를 직접 사용 → 같은 리전 내 접근이라 지연 최소.
온프레미스 쪽 : FSx File Gateway를 온프레미스에 두면, 온프레미스 사용자·앱은 로컬 게이트웨이를 통해 같은 FSx 데이터에 접근한다.
게이트웨이가 자주 쓰는 데이터를 로컬에 캐시하므로, 캐시 히트 시 온프레미스에서 낮은 지연으로 접근 가능하다.
따라서 “AWS 파일 스토리지”와 “온프레미스에서의 파일 접근” 둘 다 최소 지연으로 만족한다.
2. 기존 파일 액세스 패턴 유지
FSx for Windows = SMB(Windows 파일 공유).
FSx File Gateway도 동일한 SMB 인터페이스를 제공하므로, \\서버\공유 방식으로 접근하는 패턴을 크게 바꾸지 않아도 된다.
3. 운영 오버헤드 최소
FSx for Windows, FSx File Gateway 모두 관리형 서비스다.
온프레미스에는 게이트웨이 VM만 설치·설정하면 되고, 패치·스토리지 용량 등은 AWS가 많이 담당한다.
4. 마이그레이션 과정에 적합
데이터는 FSx(AWS) 에 한 곳에 두고, 온프레미스는 FSx File Gateway로 그 데이터에 접근한다.
점진적으로 온프레미스 워크로드를 AWS로 옮기면서도, 온프레미스 사용자는 계속 로컬 게이트웨이를 통해 같은 데이터에 접근할 수 있다.
정리하면, “하이브리드 + 최소 지연 + Windows SMB 유지 + 최소 운영”을 한 번에 만족하는 건 D(FSx + FSx File Gateway) 다.
A. AWS에 FSx for Windows만 배포, 온프레미스 데이터를 FSx로 이동, 모든 워크로드를 FSx 사용으로 재구성
데이터가 FSx(AWS) 한 곳에만 있다.
온프레미스 사용자·앱은 FSx에 접근하려면 VPN으로 AWS까지 모든 요청이 나가므로, 지연이 크다.
“최소 지연 시간으로 AWS 및 온프레미스 파일 스토리지에 액세스”에서, 온프레미스 쪽 접근이 “로컬에 가까운 스토리지”가 아니라 원격 FSx라 최소 지연을 만족하지 못한다.
요구사항
- API Gateway + Lambda로 PDF·JPEG 보고서 업로드
- PHI(Protected Health Information) 식별 : 보고서에서 보호 대상 건강 정보를 찾아야 함
- 최소한의 운영 오버헤드 : 관리형 서비스 활용, 커스텀 모델·복잡한 유지보수 지양
즉, “PDF/JPEG에서 텍스트 추출 → 그 텍스트에서 PHI 식별”을 운영 부담이 적은 방식으로 구현하는 방법을 고르는 문제다.
C. Amazon Textract로 보고서에서 텍스트 추출 → Amazon Comprehend Medical으로 추출된 텍스트에서 PHI 식별
1. 텍스트 추출
Textract는 PDF·JPEG·PNG 등 문서/이미지에서 텍스트를 추출하는 관리형 서비스다.
병원 보고서처럼 문서형 PDF·JPEG에 적합하고, 폼·테이블도 처리할 수 있다.
Lambda에서 Textract API만 호출하면 되므로 운영 부담이 적다.
2. PHI 식별
Comprehend Medical은 의료/헬스케어 텍스트용 관리형 NLP 서비스다.
PHI(이름, 날짜, 의료 기록 번호 등)와 의료 개체(약물, 진단명 등)를 사전 학습된 모델로 식별한다.
별도 학습·배포 없이 API 호출만으로 PHI 검출이 가능해 운영 오버헤드가 최소다.
3. 운영 오버헤드
Textract + Comprehend Medical 모두 관리형 API라, Lambda에서 호출만 추가하면 된다.
모델 학습·인프라·규칙 엔진 유지보수가 필요 없다.
정리하면, “문서에서 텍스트 뽑기 = Textract”, “의료 텍스트에서 PHI 찾기 = Comprehend Medical”이 요구사항에 가장 잘 맞는다.
Answer: C
요구사항
- 많은 파일, 약 5MB씩, S3 저장
- 보관 정책 : 삭제하려면 4년 보관 후 삭제 가능
- 즉각적인 액세스가 항상 필요 : 중요한 비즈니스 데이터, 재생산 어려움 → 언제나 즉시 조회 가능해야 함
- 접근 패턴 : 처음 30일은 자주 접근, 30일 이후는 거의 접근 안 함
즉, “즉시 접근은 유지하면서, 30일 이후에는 저렴한 티어로 옮겨 비용을 최소화”하는 구성을 고르는 문제다.
C. 30일 후 Standard → S3 Standard-IA, 4년 후 삭제
1. 처음 30일 : 자주 액세스 → S3 Standard 유지.
2. 30일 이후 : 자주 액세스하지는 않지만 즉각적인 액세스가 항상 필요 → S3 Standard-IA로 전환
(다중 AZ + 즉시 조회 가능).
3. 4년 경과 후 : 보관 정책상 “4년 보관 후 삭제 가능”이고, 중요한 비즈니스 데이터이므로 정책에 따라 삭제하는 것이 맞다.
→ 수명 주기에서 4년 후 삭제로 설정.
즉, 즉시 접근 + 중요한 데이터에 맞는 다중 AZ(Standard-IA) + 4년 후 삭제를 모두 만족하는 것이 C다.
Answer: D
요구사항
- 여러 EC2가 SQS 큐 메시지를 처리하고, RDS에 쓰고, 처리 후 메시지를 삭제함
- 문제 : RDS에 중복 레코드가 가끔 생김. SQS 큐에는 중복 메시지 자체는 없음
- 목표 : 메시지가 한 번만 처리되도록 함
즉, “같은 메시지가 두 번 이상 처리되어 RDS에 중복이 생기는 것”을 막는 방법을 고르는 문제다.
D. ChangeMessageVisibility API로 가시성 시간 초과(Visibility Timeout)를 늘린다
1. 중복이 나는 이유
Consumer가 메시지를 Receive하면 그 메시지는 Visibility Timeout 동안 보이지 않음(invisible).
이 시간 안에 처리하고 DeleteMessage를 호출해야 한다.
처리 시간이 Visibility Timeout보다 길어지면, 시간이 지나 메시지가 다시 보임(visible) 이 되어 다른 인스턴스(또는 같은 인스턴스)가 같은 메시지를 다시 받을 수 있다.
그러면 같은 메시지로 RDS에 한 번 더 쓰게 되어 중복 레코드가 생긴다.
SQS에는 동일 메시지가 한 개만 있어도, “한 번 받고 → 처리 늦어짐 → 다시 보임 → 다시 받아서 처리”가 되면 RDS에는 중복이 생긴다.
2. ChangeMessageVisibility의 역할
ChangeMessageVisibility로 해당 메시지의 Visibility Timeout을 늘릴 수 있다.
처리하는 쪽에서 “아직 처리 중이니, 이 메시지는 더 오래 보이지 않게 해 달라”고 호출하면, 그동안 다른 인스턴스가 같은 메시지를 받지 않게 된다.
그래서 처리 시간이 길어져도 메시지가 도중에 다시 노출되지 않고, 한 번만 처리되도록 할 수 있다.
3 구현 방식
메시지를 받은 뒤 처리하는 동안, Visibility Timeout이 만료되기 전에 주기적으로(또는 한 번) ChangeMessageVisibility를 호출해 시간을 늘린다.
처리 완료 후 DeleteMessage를 호출해 메시지를 삭제한다.
정리하면, “메시지가 한 번만 처리되게” 하려면 처리 중에는 메시지가 다시 보이지 않게 해야 하고, 그걸 Visibility Timeout 연장으로 하는 것이 D(ChangeMessageVisibility) 다.
Answer: A
요구사항
- 온프레미스를 AWS로 확장하는 하이브리드 아키텍처
- 일관되게 짧은 지연 시간 + 고가용성 연결 필요
- 비용 최소화, 기본 연결이 실패할 경우에는 더 느린 트래픽을 받아들일 수 있음
즉, “평상시에는 짧은 지연·고가용성을 유지하고, 비용은 줄이면서, 장애 시에는 느린 백업으로도 괜찮다”는 조건을 만족하는 구성을 고르는 문제다.
A. 리전에 AWS Direct Connect 연결 프로비저닝 → 기본 Direct Connect 장애 시 백업으로 VPN 연결 프로비저닝
1. 일관되게 짧은 지연 시간 + 고가용성
Direct Connect는 전용 회선으로, 인터넷을 거치지 않아 지연이 낮고 변동이 적다.
평상시 트래픽을 Direct Connect로 보내면 “일관되게 짧은 지연 시간”과 고가용성 요구를 충족한다.
2. 기본 실패 시 더 느린 트래픽 수용
백업을 VPN(인터넷 터널) 로 두면, Direct Connect보다 지연이 크고 변동도 있다.
“기본 연결이 실패할 경우 더 느린 트래픽을 기꺼이 받아들인다”는 조건과 맞다.
3. 비용 최소화
Direct Connect는 한 개만 두고, 백업은 VPN 하나로 구성한다.
VPN은 전용 회선 비용이 없어 Direct Connect 2회선보다 비용이 적다.
“비용을 최소화해야 한다”는 요구를 만족한다.
정리하면, 주 회선 = Direct Connect, 백업 = VPN 조합이 요구사항에 맞다.
Answer: B
요구사항
- ALB + EC2(Auto Scaling) 에서 비즈니스 크리티컬 웹 앱 실행
- Aurora PostgreSQL이 단일 가용 영역에만 배포된 상태
- 목표 : 애플리케이션 고가용성, 다운타임·데이터 손실 최소화
- 제약 : 최소한의 운영 노력으로 구현
즉, “고가용성 + 다운타임·데이터 손실 최소 + 운영은 가볍게”를 만족하는 구성을 고르는 문제다.
B. 여러 가용 영역을 쓰도록 Auto Scaling 그룹 구성 + 데이터베이스를 다중 AZ로 구성 + 데이터베이스에 Amazon RDS Proxy 구성
1. 고가용성
ASG(Auto Scailing Group)를 여러 AZ에 두면, 한 AZ 장애 시에도 다른 AZ의 EC2가 서비스한다.
Aurora/RDS 다중 AZ로 두면 Primary 한 AZ, Standby 다른 AZ에 두고 자동 장애 조치가 되므로 DB 다운타임·데이터 손실을 줄일 수 있다.
ALB도 여러 AZ에 타깃을 두면 트래픽을 여러 AZ로 분산할 수 있어, 앱·DB 모두 고가용성이 확보된다.
2. 다운타임·데이터 손실 최소화
다중 AZ DB는 동기 복제로 Standby가 최신 상태를 유지하고, 장애 시 자동 failover로 복구 시간을 짧게 한다.
스냅샷 복구처럼 “몇 시간 분량 손실 + 긴 복구 시간”이 아니라, 최소한의 다운타임·데이터 손실로 맞춘다.
3. 최소한의 운영 노력
다중 AZ ASG : 같은 리전 내에서 서브넷만 여러 AZ로 지정하면 된다.
다중 AZ DB : 콘솔/CLI에서 “Multi-AZ” 활성화만 하면 되고, 장애 조치는 AWS가 담당한다.
RDS Proxy : 연결 풀링·장애 조치 시 연결 재사용을 관리해 주므로, 앱 쪽 DB 연결 처리와 운영을 단순하게 만든다.
리전 여러 개를 쓰거나, 복잡한 커스텀 장애 조치 로직을 만들 필요가 없다.
정리하면, 한 리전 내에서 ASG 다중 AZ + DB 다중 AZ + RDS Proxy로 고가용성과 다운타임·데이터 손실 최소화를 최소 운영으로 만족하는 것이 B다.
C
ASG를 단일 AZ로 두면, 그 AZ 장애 시 앱 계층 전체가 중단된다. 고가용성을 만족하지 못한다.
시간별 스냅샷 복구는 최대 1시간 분량 데이터 손실 + 복구에 걸리는 시간(다운타임) 이 발생한다.
Answer: C
요구사항
- HTTP 애플리케이션이 NLB(Network Load Balancer) 뒤에 있음
- NLB 대상 그룹 = EC2 Auto Scaling 그룹 (여러 EC2에서 웹 서비스 실행)
- 문제 : NLB가 애플리케이션의 HTTP 오류를 감지하지 못함 → HTTP 오류 시 EC2를 수동으로 재시작해야 함
- 목표 : 사용자 정의 스크립트나 코드 없이 애플리케이션 가용성 개선
- 즉, “HTTP 수준에서 오류를 감지하고, 비정상 인스턴스를 자동으로 제거/교체”할 수 있어야 하며, NLB는 이걸 할 수 없다는 전제가 중요하다.
C. NLB를 Application Load Balancer(ALB)로 교체 → 회사 애플리케이션 URL로 HTTP 상태 확인 활성화 → 비정상 인스턴스 교체되도록 Auto Scaling 구성
1. HTTP 오류를 감지하려면 7계층 로드 밸런서가 필요
NLB는 4계층(TCP/UDP) 이라 포트가 열려 있는지(TCP) 만 확인한다.
HTTP 상태 코드(4xx, 5xx) 는 보지 못하므로, 앱이 500을 돌려도 NLB는 대상을 healthy로 볼 수 있다.
ALB는 7계층(HTTP/HTTPS) 이라 경로·예상 HTTP 상태 코드(예: 200) 로 헬스 체크를 할 수 있어, HTTP 오류가 나면 해당 타깃을 unhealthy로 표시할 수 있다.
2. 사용자 정의 스크립트/코드 없음
NLB → ALB 교체, ALB 리스너·타깃 그룹 헬스 체크 설정, Auto Scaling 그룹에서 ELB 헬스 체크 사용 등 설정만으로 구현 가능하다.
cron, 로그 파싱, 재시작 스크립트 같은 커스텀 코드가 필요 없다.
3. 가용성 개선
ALB가 HTTP 헬스 체크로 비정상 대상을 표시하면,
ALB는 해당 인스턴스로 트래픽을 보내지 않고
Auto Scaling 그룹이 ELB 헬스 체크를 사용하도록 되어 있으면, 비정상 인스턴스를 종료 후 새 인스턴스로 교체할 수 있다.
따라서 “HTTP 오류 발생 시 수동 재시작” 대신 자동으로 비정상 인스턴스 교체가 이루어진다.
정리하면, HTTP 오류 감지 + 비정상 인스턴스 자동 교체 + 스크립트/코드 없음을 만족하는 것은 ALB로 교체하고 HTTP 헬스 체크 + ASG 구성인 C다.
Answer: B
요구사항
- DynamoDB에 고객 정보를 저장하는 쇼핑 애플리케이션
- 데이터 손상 시를 가정한 복구 솔루션 필요
- RPO(복구 시점 목표) : 15분 — 최대 15분 분량의 데이터 손실까지 허용 (즉, 15분 단위 이내로 복구 시점을 잡을 수 있어야 함)
- RTO(복구 시간 목표) : 1시간 — 장애 발생 후 1시간 이내에 서비스 복구
즉, “데이터 손상이 나도 15분 이내 시점으로 되돌릴 수 있고(RPO), 1시간 안에 복구를 끝낼 수 있는(RTO) 방법”을 고르는 문제다.
B. DynamoDB 지정 시간 복구(Point-in-Time Recovery, PITR) 를 구성하고, RPO 복구 시 원하는 시점으로 복구
1. RPO 15분 충족
DynamoDB PITR은 지속적인 백업을 하며, 최근 35일 이내의 임의 시점으로 테이블을 복구할 수 있다.
데이터 손상이 발생했을 때 “손상 직전” 시점(예: 15분 전)으로 복구하면, 데이터 손실을 15분 이내로 줄일 수 있어 RPO 15분을 만족한다.
2. RTO 1시간 충족
PITR 복구는 새 DynamoDB 테이블을 해당 시점 데이터로 만드는 방식이다.
AWS가 복구를 수행하며, 테이블 크기에 따라 다르지만 일반적으로 1시간 이내에 복구를 완료할 수 있어 RTO 1시간 요구를 충족할 수 있다.
3. 데이터 손상 시나리오에 적합
“데이터 손상의 경우”에는 특정 시점으로 되돌리는 복구가 필요하다.
PITR은 시점 복구를 제공하므로, 손상 발생 이전 시점으로 되돌리기에 적합하다.
정리하면, RPO 15분 + RTO 1시간 + 데이터 손상 대응을 DynamoDB만으로 충족하는 표준 방법은 B(DynamoDB PITR) 다.
Answer: D
요구사항
- 사진 처리 애플리케이션이 같은 리전의 S3 버킷에서 사진을 자주 업로드·다운로드
- 데이터 전송 비용이 늘어나서, 이 비용을 줄이는 솔루션이 필요
즉, “VPC 안 앱 ↔ 같은 리전 S3” 트래픽의 데이터 전송 비용을 줄이는 방법을 고르는 문제다.
D. S3 VPC 게이트웨이 엔드포인트를 VPC에 만들고, S3 버킷 접근을 허용하는 엔드포인트 정책 연결
1. 데이터 전송 비용이 나는 이유
VPC의 앱(예: 프라이빗 서브넷 EC2)이 NAT 게이트웨이나 인터넷 게이트웨이를 통해 S3에 접근하면, 트래픽이 퍼블릭 인터넷 또는 NAT를 지나가며 데이터 전송/처리 비용이 발생한다.
같은 리전이라도 이 경로를 쓰면 비용이 든다.
2. S3 VPC 게이트웨이 엔드포인트
게이트웨이 엔드포인트는 VPC와 S3 사이 트래픽을 AWS 네트워크 안으로만 보낸다.
인터넷이나 NAT 게이트웨이를 경유하지 않으므로
NAT 게이트웨이 데이터 처리 비용 없음
인터넷으로 나가는 데이터 전송 비용 없음
같은 리전 S3 접근 시 데이터 전송 비용을 크게 줄일 수 있다.
3. 엔드포인트 정책
해당 엔드포인트로 접근 가능한 S3 버킷/객체를 제한할 수 있어, 보안과 비용 제어에 도움이 된다.
정리하면, “같은 리전 S3 접근 비용 줄이기”에는 S3 VPC 게이트웨이 엔드포인트가 표준 해법이다.
B. 퍼블릭 서브넷에 NAT 게이트웨이 배포, S3 접근을 허용하는 엔드포인트 정책 연결
NAT 게이트웨이는 프라이빗 서브넷에서 나가는 트래픽을 처리할 때 데이터 처리 비용(예: $0.045/GB)이 든다.
S3 접근을 NAT 게이트웨이로 보내면 데이터 전송/처리 비용이 그대로 발생하고, “비용을 줄인다”는 요구와 맞지 않는다.
엔드포인트 정책을 붙여도 NAT를 쓰는 한 비용 구조는 같다.
Answer: C, D
요구사항
- 프라이빗 서브넷 : Linux 애플리케이션 EC2
- 퍼블릭 서브넷 : Linux 배스천 호스트 EC2
- 접속 경로 : 사내 네트워크 → 회사 인터넷 연결 → 배스천 호스트 → 애플리케이션 서버
- 모든 EC2의 보안 그룹이 이 접근을 허용하도록 설정 (2개 선택)
즉, “사내 → 배스천만 허용”, “배스천 → 앱 서버만 허용”이 되도록 보안 그룹 2곳을 어떻게 바꿀지 고르는 문제다.
C. 배스천 호스트 보안 그룹을 회사의 외부 IP 범위에서만 인바운드 허용으로 변경
사내에서 회사 인터넷(아웃바운드) 로 나갈 때, AWS/인터넷 쪽에서 보이는 출발지 IP는 회사 방화벽/NAT의 외부(퍼블릭) IP다.
따라서 배스천 호스트는 “회사에서만 들어올 수 있게” 하려면 회사의 외부 IP 범위에서만 인바운드(SSH 등)를 허용해야 한다.
내부 IP 범위(B) 로 하면, AWS는 사내 내부 IP를 볼 수 없어서 접속이 막힌다.
D. 애플리케이션 인스턴스 보안 그룹을 배스천 호스트의 개인(프라이빗) IP에서만 인바운드 SSH 허용으로 변경
애플리케이션 서버는 배스천을 통해서만 접근 가능해야 하고, 인터넷에서 직접 접근되면 안 된다.
배스천(퍼블릭 서브넷)에서 앱(프라이빗 서브넷)으로 SSH할 때, 트래픽은 VPC 내부에서만 흐르므로 배스천의 프라이빗 IP가 출발지가 된다.
따라서 앱 서버 보안 그룹은 배스천의 개인(프라이빗) IP에서만 인바운드 SSH를 허용하는 것이 맞다.
공용 IP(E) 로 하면, VPC 내부 트래픽은 프라이빗 IP로 오기 때문에 매칭되지 않아 접속이 안 된다.
Answer: A, C
요구사항
- 2계층 웹 애플리케이션
- 웹 계층 : 퍼블릭 서브넷 EC2 (퍼블릭 웹)
- DB 계층 : 프라이빗 서브넷 EC2, Microsoft SQL Server (포트 1433)
- 보안이 최우선
즉, “퍼블릭 웹만 열고, DB는 웹 서버에서만 접근”하도록 보안 그룹 2가지를 고르는 문제다.
A. 웹 계층 보안 그룹에서 0.0.0.0/0으로부터 포트 443 인바운드 허용
웹 계층은 퍼블릭 웹이므로, 사용자가 HTTPS(443) 로 접속할 수 있어야 한다.
“0.0.0.0/0에서 포트 443 인바운드 허용” = 인터넷 누구나 웹 서버 443으로 접근 가능하게 하는 설정이다.
80(HTTP) 대신 443(HTTPS) 만 허용하면 암호화·보안에 유리해 “보안 최우선”과 맞다.
따라서 웹 계층에는 A(0.0.0.0/0 → 443 인바운드) 가 필요하다.
C. 데이터베이스 계층 보안 그룹에서 웹 계층 보안 그룹으로부터 포트 1433 인바운드 허용
SQL Server 기본 포트는 1433이다.
DB는 웹 서버만 접근할 수 있어야 하고, 인터넷(0.0.0.0/0)에서는 접근되면 안 된다.
따라서 DB 보안 그룹 인바운드에 “웹 계층 보안 그룹 → 포트 1433”만 허용하는 것이 맞다.
출처를 웹 계층 보안 그룹으로 두면, IP가 바뀌어도 웹 서버만 허용되므로 보안에 유리하다.
정리하면, DB 계층에는 C(웹 계층 SG → 1433 인바운드) 가 필요하다
B 아웃바운드는 “웹 서버가 어디로 나가는지”를 제어한다.
“0.0.0.0/0, 443 아웃바운드” = 웹 서버가 외부로 HTTPS 요청을 보내는 것은 허용하는 설정이라, 보안상 보통 허용한다.
하지만 문제에서 묻는 것은 “퍼블릭 접근(인바운드)”와 “DB는 웹에서만 접근”이라는 핵심 보안 구성이다.
Answer: A
요구사항
- 다계층 애플리케이션을 온프레미스 → AWS로 이전해 성능 개선
- 계층 간 RESTful 통신
- 문제 : 한 계층이 오버로드되면 트랜잭션이 삭제(유실) 됨
- 목표 : 이 문제를 해결하고 애플리케이션 현대화, 운영상 가장 효율적인 솔루션
즉, “오버로드 시 트랜잭션 유실 방지” + “현대화” + “운영 효율”을 동시에 만족하는 구성을 고르는 문제다.
A. Amazon API Gateway로 트랜잭션 수신 → AWS Lambda로 전달 → Amazon SQS를 애플리케이션 서비스 간 통신(메시징) 계층으로 사용
1. 트랜잭션 유실 방지
계층 간을 동기 REST로만 연결하면, 한 계층이 바쁠 때 요청이 거절·타임아웃되며 트랜잭션이 삭제된다.
SQS를 계층 사이에 두면, 상위 계층은 요청을 큐에 넣기만 하고, 하위 계층은 처리 가능할 때 큐에서 꺼내 처리한다.
따라서 한 계층이 오버로드되어도 요청이 큐에 쌓일 뿐 삭제되지 않아 트랜잭션 유실이 방지된다.
2. 현대화
API Gateway + Lambda + SQS 조합은 서버리스·이벤트 기반 구조다.
RESTful 서비스를 API Gateway로 노출하고, Lambda가 SQS에 메시지를 넣고, 다른 Lambda나 워커가 SQS에서 꺼내 처리하는 패턴으로 현대적인 아키텍처가 된다.
3. 운영상 가장 효율적
API Gateway·Lambda·SQS는 관리형 서비스라,
서버 프로비저닝·패치·스케일링을 직접 하지 않아도 되고
트래픽에 따라 자동으로 확장된다.
EC2·ASG를 계속 운영하는 방식보다 운영 부담이 적어 “운영상 가장 효율적”이라는 조건을 잘 충족한다.
정리하면, 트랜잭션 유실 방지(큐 도입) + 현대화(서버리스) + 운영 효율(관리형 서비스) 을 한 번에 만족하는 것이 A다.
Answer: B
요구사항
- 매일 10TB 계측 데이터, 단일 공장의 여러 기계
- 데이터 형태 : JSON 파일, 온프레미스 데이터 센터 SAN에 저장
- 목적 : Amazon S3로 전송 후 여러 시스템이 실시간에 가까운 분석에 사용
- 데이터 민감 → 안전한 전송 필요
목표 : 가장 안정적인 데이터 전송 솔루션
즉, “SAN의 파일(JSON) 을 S3로, 안전하고 안정적으로 보내는 방법”을 고르는 문제다.
B. AWS Direct Connect를 통한 AWS DataSync
1. 올바른 서비스: DataSync
DataSync는 온프레미스 스토리지(NFS, SMB 등) 또는 다른 AWS 스토리지와 S3·EFS·FSx 간 파일/객체 전송용 서비스다.
SAN에 있는 JSON 파일을 S3로 옮기는 시나리오에 맞다.
DMS는 데이터베이스 마이그레이션/복제용이라, SAN의 파일 전송에는 적합하지 않다.
따라서 A 또는 B(DataSync) 만 후보가 된다.
2. 가장 안정적인 전송: Direct Connect
Direct Connect는 전용 회선으로, 공용 인터넷을 쓰지 않는다.
지연·패킷 손실·혼잡 변동이 적어 공용 인터넷보다 안정적이다.
10TB/일처럼 대용량·정기 전송에 “가장 안정적인” 전송 경로를 원하면 Direct Connect가 맞다.
3. 안전한 전송
민감 데이터이므로 “안전한 전송”이 중요하다고 했을 때,
트래픽이 공용 인터넷을 거치지 않는 Direct Connect가 보안 측면에서도 유리하다.
DataSync는 전송 중 암호화도 지원하므로, Direct Connect 위에서 추가로 보안을 강화할 수 있다.
정리하면, 파일 전송 = DataSync, 안정성·보안 = Direct Connect → B(Direct Connect + DataSync) 가 정답이다.
Answer: C
요구사항
- 실시간 데이터 수집 아키텍처 구성
- API : 스트리밍되는 데이터를 실시간으로 변환하는 프로세스
- 스토리지 : 변환된 데이터를 저장할 솔루션
- 최소한의 운영 오버헤드 : 관리형·서버리스 위주
즉, “실시간 스트리밍 수집 + 스트리밍 중 변환 + 스토리지”를 운영 부담이 적게 만족하는 구성을 고르는 문제다.
C. API Gateway API를 Kinesis Data Streams로 데이터 전송하도록 구성 → Kinesis Data Firehose(원본: Data Streams) 생성 → Lambda로 변환 → Firehose로 S3에 전송
1. 실시간 수집
API Gateway가 스트리밍 데이터를 받아 Kinesis Data Streams로 보내면, 실시간 스트리밍 수집이 가능하다.
Kinesis Data Firehose가 Data Streams를 원본으로 사용해 S3까지 연속 전달하므로, 실시간에 가까운 파이프라인이 된다.
2. 스트리밍 중 변환
Firehose에서 Lambda를 호출해 레코드를 변환할 수 있다.
“데이터가 스트리밍될 때 변환하는 프로세스”를 Lambda(변환) + Firehose(전달) 로 구현할 수 있다.
3. 스토리지
Firehose가 변환된 데이터를 S3로 보내면, 스토리지 요구사항을 충족한다.
4. 최소한의 운영 오버헤드
API Gateway, Kinesis Data Streams, Kinesis Data Firehose, Lambda, S3는 모두 관리형·서버리스다.
EC2를 두지 않아 운영 부담이 최소다.
정리하면, 실시간 수집 + 스트리밍 변환 + S3 저장 + 최소 운영을 한 번에 만족하는 것이 C다.
Answer: B
요구사항
- 사용자 트랜잭션 데이터를 DynamoDB 테이블에 보관
- 7년간 보관 필요
- 가장 운영 효율성이 높은 솔루션 선택
즉, “DynamoDB 데이터를 7년 보관하면서 운영 부담이 가장 적은 방법”을 고르는 문제다.
B. AWS Backup으로 테이블에 대한 백업 일정 및 보존 정책 생성
1. 7년 보관
AWS Backup은 백업 플랜에서 보존 기간(Retention) 을 설정할 수 있다.
DynamoDB 테이블에 대한 백업 일정을 만들고, 보존 기간을 7년으로 두면 7년 보관 요구를 충족한다.
2. 운영 효율이 가장 높음
관리형 서비스로, 백업·보존·만료를 AWS가 처리한다.
백업 일정과 보존 정책만 설정하면 되고, Lambda 작성·EventBridge 규칙 유지·스크립트 운영이 필요 없다.
“가장 운영 효율성이 높은” 조건을 가장 잘 만족한다.
3. DynamoDB 지원
AWS Backup은 DynamoDB를 리소스 타입으로 지원하므로, 해당 테이블을 선택해 백업 플랜에 넣으면 된다.
정리하면, 7년 보관 + 최소 운영을 동시에 만족하는 것이 B(AWS Backup) 다.
Answer: A
요구사항
- DynamoDB 테이블로 데이터 저장 예정
- 비용 최적화가 중요
- 대부분 아침 : 테이블을 거의/전혀 사용하지 않음
- 저녁 : 읽기·쓰기 트래픽이 예측하기 어렵고, 급증이 매우 빠르게 발생
즉, “한가한 시간에는 비용을 줄이고, 예측 어렵고 급격한 트래픽에도 대응”하는 용량 방식을 고르는 문제다.
A. 온디맨드(On-Demand) 용량 모드로 DynamoDB 테이블 생성
1. 비용 최적화
온디맨드는 실제 요청(읽기/쓰기) 건수만큼만 과금된다.
아침처럼 거의 사용하지 않을 때는 요청이 적어 비용이 거의 나오지 않는다.
프로비저닝된 용량처럼 “사용 안 해도 최소 용량 비용”이 없어, 변동이 큰 트래픽에 비용 최적화에 유리하다.
2. 예측 어려운 저녁 트래픽
용량을 미리 정해 둘 필요가 없어, 트래픽이 얼마나 올지 예측하기 어려워도 그때그때 요청량만큼 처리·과금된다.
매우 빠른 트래픽 급증
온디맨드는 용량 한도 없이 트래픽에 맞춰 자동·즉시 확장된다.
프로비저닝 + Auto Scaling은 최소/최대 용량과 스케일 업 시간 제약이 있어, 급격한 스파이크에는 상대적으로 불리하다.
“트래픽 급증이 매우 빠르게 발생”할 때는 온디맨드가 더 적합하다.
정리하면, 아침에는 비용 최소 + 저녁 예측 불가·급격한 스파이크 대응을 동시에 만족하는 것이 A(온디맨드) 다.
Answer: B
요구사항
- 기존 AWS 계정의 EBS 기반 AMI를 MSP 파트너의 AWS 계정과 공유해야 함
- AMI의 EBS 스냅샷은 AWS KMS 고객 관리형 키로 암호화됨
- 가장 안전한 방법으로 공유해야 함
즉, “암호화된 AMI를 특정 계정(MSP)에만 안전하게 공유하는 방법”을 고르는 문제다.
B. AMI의 launchPermission을 수정해 MSP 파트너 계정과만 AMI 공유 → MSP 계정이 해당 키를 사용할 수 있도록 키 정책 수정
1. AMI·스냅샷은 특정 계정에만 공유
launchPermission에 MSP 파트너 계정 ID만 추가하면, 해당 계정만 그 AMI를 조회·실행할 수 있다.
다른 계정은 AMI를 볼 수 없고 실행할 수도 없어 접근 범위가 최소화된다.
암호화된 스냅샷 사용을 위해 KMS 키 공유
EBS 스냅샷이 고객 관리형 KMS 키로 암호화되어 있으면, 다른 계정에서 그 AMI/스냅샷을 쓰려면 같은 KMS 키로 복호화할 수 있어야 한다.
따라서 원본 계정의 KMS 키 정책에 MSP 파트너 계정을 추가해, 해당 계정이 그 키를 사용(복호화)할 수 있게 해야 한다.
B는 “MSP 계정이 키를 사용할 수 있도록 키 정책을 수정”이라고 했으므로, 이 조건을 충족한다.
2. 안전한 방식
AMI는 MSP 계정에만 공개(launchPermission).
키는 해당 키 정책으로 MSP 계정에만 허용.
공개 AMI·전체 공개 키 없이, 필요한 계정만 AMI와 키에 접근하는 표준적이고 안전한 방법이다.
정리하면, launchPermission(AMI 공유) + KMS 키 정책(복호화 권한) 조합이 가장 안전한 방법이다.
C. launchPermission으로 MSP 계정과만 AMI 공유, “암호화를 위해 MSP가 소유한 새 KMS 키를 신뢰하도록” 키 정책 수정
이미 만들어진 스냅샷은 원본 계정의 KMS 키로 암호화된 상태다.
“MSP가 소유한 새 KMS 키를 신뢰하도록 키 정책 수정”은 원본 키의 정책을 바꾸는 것인데, 그렇게 해도 이미 암호화된 스냅샷을 MSP 키로 바꾸거나 복호화할 수는 없다.
MSP가 AMI를 쓰려면 원본 키로 복호화할 수 있어야 하므로, 필요한 것은 원본 키 정책에 MSP 계정 추가이지, “MSP의 새 키 신뢰”가 아니다.
따라서 C는 기술적으로 맞지 않고, 안전한 공유 방법도 아니다.
Answer: C
요구사항
- 처리할 작업 수에 따라 노드를 추가·제거
- 프로세스는 병렬 실행
- 프로세서 애플리케이션은 상태 비저장(stateless)
- 느슨한 결합(loosely coupled) 으로 구성
- 작업 항목이 영구적으로 저장되어 있어야 함
즉, “작업을 영구 저장하고, 작업 수에 맞춰 노드를 늘리고 줄이는 느슨한 결합 아키텍처”를 고르는 문제다.
C. 처리할 작업을 Amazon SQS 대기열에 보관 → 프로세서 AMI → 시작 템플릿 → Auto Scaling 그룹 → SQS 대기열 항목 수에 따라 노드 추가·제거
1. 작업 항목이 영구적으로 저장
SQS는 메시지(작업)를 대기열에 보관한다.
워커가 처리해 삭제하기 전까지 메시지는 유지되며, 워커가 없거나 장애가 나도 작업이 사라지지 않는다.
“작업 항목이 영구적으로 저장” 요구를 충족한다.
2. 느슨한 결합
작업을 넣는 쪽은 SQS에만 전송하고, 워커는 필요할 때 SQS에서 가져가서 처리한다.
서로 직접 연결되지 않아 느슨한 결합 구조가 된다.
3. 작업 수에 따른 노드 추가·제거
Auto Scaling 조정 정책을 SQS 대기열의 메시지 수(ApproximateNumberOfMessagesVisible) 로 두면,
대기열에 작업이 많을 때 노드를 추가하고
작업이 줄면 노드를 제거할 수 있다.
“처리할 작업 수에 따라 노드 추가·제거”와 정확히 맞다.
4. 시작 템플릿
시작 템플릿(Launch Template) 은 시작 구성(Launch Configuration) 을 대체하는 현재 권장 방식이다.
AMI 기반 인스턴스 생성을 시작 템플릿으로 하는 구성이 적절하다.
정리하면, 작업 저장(SQS) + 느슨한 결합 + 작업 수 기반 스케일 + 시작 템플릿을 모두 만족하는 것이 C다.
Answer: B
요구사항
- ELB가 ACM으로 가져온(Import) 인증서 사용
- 만료 30일 전에 보안팀에 알림 필요
- 이 요구를 충족하는 방법 권장
즉, “30일 이내 만료되는 인증서를 찾아서 보안팀에게 알림”을 자동화하는 구성을 고르는 문제다.
B. 30일 이내 만료되는 인증서를 검사하는 AWS Config 규칙 생성 → AWS Config가 비준수 리소스를 보고할 때 EventBridge(CloudWatch Events) 로 연동 → SNS로 사용자 지정 알림 전송
1. 인증서 만료 검사
AWS Config는 ACM 인증서를 리소스로 다루며, 규칙으로 “만료일이 30일 이내인지” 같은 조건을 검사할 수 있다.
관리형 규칙(예: acm-certificate-expiration-check) 또는 커스텀 규칙으로 “30일 이내 만료”를 정의하면, 해당 인증서가 비준수(non-compliant) 로 보고된다.
2. 비준수 시 알림
Config가 규칙을 평가해 리소스가 비준수로 바뀌면 Config 상태 변경 이벤트가 발생한다.
EventBridge(CloudWatch Events) 에서 AWS Config 준수성 변경 이벤트를 구독하고, 해당 이벤트가 나올 때 SNS로 알림을 보내도록 구성하면 된다.
“30일 이내 만료” = 비준수 → EventBridge → SNS로 보안팀 알림이 가능하다.
3. 관리형·표준 방식
인증서 만료 검사와 준수성 평가는 Config 역할에 맞고, EventBridge + SNS는 AWS에서 권장하는 알림 패턴이다.
별도 Lambda로 만료일을 계산할 필요 없이, Config 규칙 + EventBridge + SNS만으로 요구사항을 충족할 수 있다.
정리하면, Config 규칙(30일 만료 검사) + EventBridge(Config 이벤트) + SNS(알림) 조합이 정답이다.
D. 30일 이내 만료되는 모든 인증서를 감지하는 EventBridge 규칙 생성, Lambda 호출, Lambda가 SNS로 알림
EventBridge 자체에는 “인증서 만료 30일 이내”를 감지하는 이벤트 소스가 없다.
Answer: C
요구사항
- 동적 웹사이트가 미국 온프레미스 서버에서 호스팅됨
- 유럽에서 제품 출시 예정 → 유럽 사용자의 사이트 로딩 시간 최적화 필요
- 백엔드는 미국에 두어야 함
- 며칠 안에 출시 → 즉시 적용 가능한 솔루션 필요
즉, “백엔드는 미국 유지하면서 유럽 사용자 로딩만 빠르게 하고, 바로 쓸 수 있는 방법”을 고르는 문제다.
C. 온프레미스 서버를 오리진으로 하는 Amazon CloudFront 사용
1. 유럽 로딩 시간 개선
CloudFront는 CDN으로, 전 세계 엣지 로케이션에 캐시를 둔다.
정적 자원(이미지, CSS, JS 등)은 유럽 엣지에 캐시되어, 유럽 사용자는 가까운 엣지에서 받아 로딩 시간이 줄어든다.
동적 요청은 여전히 오리진(온프레미스 미국) 으로 가므로, 전체 트래픽 중 상당 부분이 엣지에서 처리되어 체감 속도가 좋아진다.
2. 백엔드는 미국 유지
커스텀 오리진을 온프레미스 서버로 두면, 캐시 미스·동적 요청은 모두 미국 온프레미스로 간다.
백엔드를 유럽으로 옮기거나 복제할 필요가 없다.
3. 즉시 적용 가능
CloudFront 배포를 만들고 오리진을 온프레미스로 지정한 뒤, DNS만 CloudFront 도메인으로 바꾸면 된다.
사이트 마이그레이션이나 아키텍처 대규모 변경 없이 며칠 안에 적용 가능하다.
정리하면, 즉시성 + 유럽 로딩 개선 + 백엔드 미국 유지를 동시에 만족하는 것이 C(CloudFront + 온프레미스 오리진) 다.
Answer: B
요구사항
- 3계층 웹 아키텍처(웹·앱·DB) 비용 절감 목표
- 프로덕션 EC2 : 24시간 가동
- 개발·테스트 EC2 : 하루 최소 8시간 가동, 사용 안 할 때 자동 중지 예정
- 가장 비용 효율적인 EC2 구매 방식 선택
즉, “프로덕션은 24/7, 개발/테스트는 8시간+ 자동 중지”일 때 어떤 구매 옵션 조합이 가장 저렴한지를 묻는 문제다.
B. 프로덕션에는 예약 인스턴스(Reserved Instances) 사용, 개발·테스트에는 온디맨드(On-Demand) 사용
1. 프로덕션 24시간 → 예약 인스턴스
예약 인스턴스(RI) 는 1년/3년 약정으로 사용할 때 시간당 요금이 크게 할인된다.
24시간 계속 켜 두는 프로덕션에는 사용량이 예측 가능하므로 RI가 가장 비용 효율적이다.
스팟/스팟 블록은 중단 가능성이 있어 프로덕션 24/7에는 부적합하다.
2. 개발·테스트 8시간 + 자동 중지 → 온디맨드
개발·테스트는 필요할 때만 켜고, 나머지 시간에는 중지할 예정이다.
온디맨드는 실행한 시간만 과금되므로, 하루 8시간만 켜면 8시간만 비용이 발생한다.
예약 인스턴스를 쓰면 “예약 비용”은 24시간 기준으로 내고 실제로는 8시간만 써서 비효율이 된다.
따라서 개발·테스트에는 온디맨드가 비용·유연성 모두 맞다.
3. 자동 중지와의 궁합
“사용하지 않을 때 중지”하면 실행 시간이 8시간보다 더 줄어들 수 있다.
그만큼 온디맨드 비용만 줄어들고, 예약은 사용 여부와 관계없이 비용이 남으므로 개발/테스트에는 온디맨드가 유리하다.
정리하면, 프로덕션 = 예약, 개발/테스트 = 온디맨드 조합이 가장 비용 효율적이다.
Answer: A
요구사항
- 프로덕션 웹 앱: 사용자가 웹·모바일로 문서 업로드
- 새 규제 : 저장된 새 문서는 저장 후 수정·삭제가 불가 (불변 저장)
즉, “저장 후에는 수정·삭제를 아무도 할 수 없는” 스토리지 구성을 고르는 문제다.
A. S3 버전 관리와 S3 Object Lock이 활성화된 Amazon S3 버킷에 업로드 문서 저장
1. 저장 후 수정·삭제 불가
S3 Object Lock은 WORM(Write Once Read Many) 을 제공한다.
객체에 보존 기간을 두면, 그 기간 동안 덮어쓰기·삭제가 불가하다.
규정 준수(Compliance) 모드에서는 루트·버킷 소유자도 보존 기간을 줄이거나 객체를 삭제할 수 없다.
따라서 “저장 후 수정·삭제 불가”라는 규제 요구를 스토리지 수준에서 충족한다.
2. S3 버전 관리
Object Lock을 쓰려면 버킷에 버전 관리가 켜져 있어야 한다.
“S3 버전 관리 및 S3 객체 잠금이 활성화된 버킷”이라는 A의 설명이 이 요구와 맞다.
3. ACL·권한과의 차이
ACL·IAM으로 “읽기 전용”만 두는 것은 정책이라, 권한이 있는 사용자(예: 관리자)가 정책을 바꾼 뒤 수정·삭제할 수 있다.
Object Lock은 스토리지 수준에서 삭제·덮어쓰기를 막아, 규제·감사 요구에 더 적합하다.
정리하면, 저장 후 수정·삭제 불가를 보장하려면 S3 Object Lock(+ 버전 관리)이 정답이다.
C. S3 버전 관리 활성화 버킷에 저장, ACL로 모든 액세스를 읽기 전용으로 제한
ACL로 읽기 전용을 둬도, 버킷 소유자·루트는 정책을 변경한 뒤 객체 삭제·덮어쓰기가 가능하다.
Answer: A
요구사항
- 여러 웹 서버가 공통 RDS MySQL 다중 AZ 인스턴스에 자주 접근
- 보안 요구 : 사용자 자격 증명을 자주 교체해야 함
- 웹 서버가 안전하게 DB에 연결할 수 있는 방법 필요
즉, “자격 증명을 자주 바꾸면서 웹 서버가 안전하게 DB에 접속”하는 구성을 고르는 문제다.
A. AWS Secrets Manager에 DB 사용자 자격 증명 저장 → 웹 서버에 Secrets Manager 접근용 IAM 권한 부여
1 자격 증명 안전 보관
Secrets Manager는 DB 사용자명·비밀번호 같은 비밀 저장용 서비스다.
웹 서버는 IAM 역할로 GetSecretValue만 호출하면 되고, 코드·파일에 자격 증명을 넣을 필요가 없다.
2. 자주 교체(로테이션)
Secrets Manager는 RDS 자격 증명 자동 순환을 지원한다.
순환을 켜 두면 주기적으로 RDS 비밀번호를 바꾸고, Secrets Manager에 저장된 비밀도 함께 갱신한다.
“자격 증명을 자주 교체해야 하는 보안 요구”를 자동 순환으로 충족할 수 있다.
3. 웹 서버 연결
웹 서버는 시작 시 또는 연결 전에 GetSecretValue로 최신 자격 증명을 가져와 RDS에 접속하면 된다.
순환이 되어도 웹 서버는 항상 최신 비밀을 조회하므로, 여러 웹 서버가 공통 RDS에 안전하게 연결할 수 있다.
정리하면, 안전한 보관 + 자주 교체(자동 순환) + 웹 서버가 안전하게 연결을 한 번에 만족하는 것이 A(Secrets Manager) 다.
Answer: D
요구사항
- API Gateway → Lambda → Aurora MySQL에 고객 데이터 저장
- 문제 : DB 업그레이드 중에는 Lambda가 DB 연결을 할 수 없어, 그동안 들어온 고객 데이터가 기록되지 않음(유실)
- 목표 : DB 업그레이드 중에 생성되는 고객 데이터도 반드시 저장되도록 하는 솔루션
즉, “DB를 쓸 수 없는 동안에도 데이터를 잃지 않고, 나중에 DB에 기록”할 수 있는 구성을 고르는 문제다.
D. 고객 데이터를 Amazon SQS FIFO 대기열에 저장 → 대기열을 폴링해서 고객 데이터를 DB에 저장하는 새 Lambda 생성
1. DB 불가 시에도 데이터 유실 없음
Lambda가 고객 데이터를 받으면 먼저 SQS에 메시지로 넣는다.
DB가 업그레이드로 내려가 있어도 SQS에는 메시지가 그대로 쌓인다.
그래서 “DB 업그레이드 중에 생성되는 고객 데이터”가 유실되지 않고 보관된다.
2. DB 복구 후 일괄 기록
새 Lambda가 SQS를 폴링(또는 이벤트 소스로 트리거) 하면서 메시지를 꺼내 Aurora MySQL에 기록한다.
DB가 다시 올라오면, 쌓여 있던 메시지가 순서대로 처리되어 모든 고객 데이터가 DB에 기록된다.
3. FIFO의 역할
FIFO 큐를 쓰면 순서가 보장되어, 이벤트 발생 순서대로 DB에 적재할 수 있다.
고객 데이터의 순서가 중요한 경우 요구사항에 맞다.
정리하면, SQS = 버퍼로 두고, DB 쓰기 전용 Lambda가 큐를 비우는 구조가 “DB 업그레이드 중 데이터 유실 방지”를 만족한다.
A. Lambda와 DB 사이에 RDS Proxy 프로비저닝, Lambda가 RDS Proxy에 연결하도록 구성
RDS Proxy는 연결 풀링·장애 조치를 돕는 프록시다.
DB 인스턴스가 업그레이드로 완전히 내려가 있으면 Proxy를 통해서도 연결 자체가 불가하다.
Proxy는 “DB가 있을 때”의 연결 관리만 하므로, DB가 없는 동안 들어온 데이터를 어딘가에 쌓아 두는 기능은 없다.
따라서 “DB 업그레이드 중에 생성되는 데이터를 저장”하는 요구를 충족하지 못한다.
Answer: A
요구사항
- 미국 설문 조사 회사, 3TB 이상 데이터를 S3 버킷에 보관(계속 증가)
- 유럽 마케팅 회사(S3 버킷 보유)와 데이터 공유 시작
- 데이터 전송 비용을 가능한 한 낮게 유지하고 싶음
즉, “우리(설문 조사 회사)가 내는 데이터 전송 비용을 최소화하는” 공유 방식을 고르는 문제다.
A. 회사 S3 버킷에서 요청자 지불(Requester Pays) 구성
1. 데이터 전송 비용이 버킷 소유자에게 거의 없음
Requester Pays를 켜면, 버킷에서 데이터를 가져가는 쪽(요청자) 이 데이터 전송 비용과 요청 비용을 부담한다.
마케팅 회사가 설문 조사 회사의 S3 버킷에 접근해 데이터를 다운로드할 때, 마케팅 회사가 전송 비용을 지불하고, 설문 조사 회사(버킷 소유자) 는 그 전송에 대한 비용을 거의 내지 않는다.
“데이터 전송 비용을 가능한 한 낮게”
설문 조사 회사 입장에서 “우리가 내는 데이터 전송 비용”을 최소화하는 것이 목표이므로, 전송 비용을 요청자에게 넘기는 Requester Pays가 조건에 맞다.
2. 공유 방식과의 조합
교차 계정 액세스(버킷 정책 등)로 마케팅 회사가 접근할 수 있게 한 뒤, Requester Pays만 켜면 된다.
복제나 동기화 없이 기존 버킷 하나로 공유하면서, 설문 조사 회사의 전송 비용만 최소화할 수 있다.
정리하면, “우리 데이터 전송 비용을 가능한 한 낮게” = 요청자 지불(Requester Pays) 이 정답이다.
Answer: A
요구사항
- 기밀 감사 문서를 Amazon S3에 저장
- 버킷 정책으로 감사 팀 IAM 사용자만 최소 권한으로 접근
- 우려 : S3 버킷에서 실수로 문서가 삭제되는 것
- 목표 : 더 안전한 방식으로 감사 문서 보호 (실수로 인한 삭제 방지)
즉, “실수로 삭제되지 않도록” S3를 더 안전하게 만드는 방법을 고르는 문제다.
A. S3 버킷에서 버전 관리와 MFA 삭제(MFA Delete) 를 활성화
1. 실수로 삭제된 것처럼 보이는 경우 복구
S3 버전 관리를 켜면, “삭제”는 삭제 마커만 붙이고 이전 버전은 그대로 남는다.
실수로 삭제한 것처럼 보여도 이전 버전을 복구할 수 있어, 우발적 삭제에 대비할 수 있다.
2. 영구 삭제를 막는 MFA 삭제
MFA 삭제를 활성화하면, 객체 버전을 영구 삭제하거나 버킷의 버전 관리 설정을 변경하려면 버킷 소유자 계정의 MFA가 필요하다.
감사 팀 IAM 사용자에게 s3:DeleteObject 권한이 있어도, 영구 삭제는 버킷 소유자 MFA 없이는 할 수 없다.
따라서 실수나 단순 권한 남용만으로는 문서가 완전히 사라지지 않도록 할 수 있다.
3. 감사 문서 보호
버전 관리로 삭제 마커 제거 → 복구 가능.
MFA 삭제로 영구 삭제·버전 관리 해제를 제한해, “더 안전한 솔루션” 요구를 충족한다.
정리하면, 실수로 인한 삭제를 막고 복구 가능하게 하려면 버전 관리 + MFA 삭제(A) 가 정답이다.
B. 감사 팀 IAM 사용자 계정에 MFA 활성화
IAM 사용자 로그인 시 MFA는 콘솔/CLI 로그인 보안을 높이는 것이다.
한 번 로그인한 뒤에는 S3 삭제 권한이 있으면 s3:DeleteObject를 그대로 호출할 수 있어, S3 객체 삭제에 대한 추가 보호가 되지 않는다.
“실수로 문서가 삭제되는 것”을 S3 수준에서 막는 기능이 아니다
Answer: A
요구사항
- 공개 영화 데이터를 RDS 단일 AZ SQL DB에 저장
- 스크립트가 매일 임의 시간에 “새로 추가된 영화 수” 등을 쿼리
- 업무 시간 끝까지의 최종 합계를 보고해야 함
- 문제 : 스크립트가 돌 때 DB 성능이 개발 작업에 부적절함 (스크립트가 개발용 DB를 부하시킴)
- 목표 : 이 문제를 최소한의 운영 오버헤드로 해결
즉, “리포트용 스크립트가 개발용 DB를 방해하지 않게” 하면서, 운영 부담은 적게 하는 방법을 고르는 문제다.
B. 데이터베이스의 읽기 전용 복제본(Read Replica) 을 만들고, 스크립트가 읽기 전용 복제본만 쿼리하도록 구성
1. 워크로드 분리
개발 팀은 Primary(기본) DB만 사용하고,
스크립트는 읽기 전용 복제본만 쿼리하도록 바꾼다.
스크립트가 “새 영화 수” 같은 읽기 전용 쿼리만 하므로, 복제본에서만 실행해도 요구사항을 만족한다.
Primary는 스크립트 부하를 받지 않아 개발 작업에 적절한 성능을 유지할 수 있다.
2. 데이터 정합성
읽기 전용 복제본은 Primary와 비동기 복제로 동기화되므로, 스크립트가 “매일 임의 시간 + 업무 종료 시 최종 합계”를 보는 용도에는 충분하다.
3. 최소한의 운영 오버헤드
RDS Read Replica는 관리형으로 생성·복제가 이루어진다.
스크립트의 연결 대상(엔드포인트) 만 복제본으로 바꾸면 되고, 복제본 생성·유지보수는 AWS가 담당한다.
정리하면, 리포트 스크립트 → Read Replica, 개발 → Primary 로 분리하는 B가 정답이다.
A. DB 인스턴스를 다중 AZ 배포로 변경
다중 AZ는 고가용성(장애 조치) 용이다.
Primary와 Standby 역할만 바뀌는 것이지, “리포트 쿼리를 다른 인스턴스로 보낸다”는 워크로드 분리가 아니다.
스크립트가 여전히 Primary를 쿼리하면 성능 문제는 그대로라, “스크립트 실행 시 DB 성능이 개발에 부적절하다”는 문제를 해결하지 못한다.
Answer: A
요구사항
- VPC 내 EC2에서 애플리케이션 실행
- 애플리케이션이 S3 API로 객체 저장·읽기 필요
- 보안 규정 : 애플리케이션 트래픽이 인터넷을 통해 이동하면 안 됨
즉, “EC2 → S3” 트래픽이 인터넷을 거치지 않고 AWS 네트워크 안에서만 가도록 하는 방법을 고르는 문제다.
A. S3 게이트웨이 엔드포인트 구성
1. 인터넷 미경유
S3 VPC 게이트웨이 엔드포인트를 VPC에 두면, VPC 안에서 발생한 S3 API 트래픽이 퍼블릭 인터넷으로 나가지 않고 AWS 내부 네트워크로만 전달된다.
EC2 → (라우팅) → 게이트웨이 엔드포인트 → S3 경로가 인터넷을 사용하지 않으므로 “트래픽이 인터넷을 통해 이동할 수 없음” 요구를 충족한다.
2. NAT/IGW 불필요
게이트웨이 엔드포인트만으로 S3 접근이 가능하므로, NAT 게이트웨이나 인터넷 게이트웨이를 통해 나가는 경로가 필요하지 않다.
프라이빗 서브넷의 EC2도 인터넷 없이 S3에 접근할 수 있다.
3. S3 API 호출
PutObject, GetObject 등 S3 API 호출이 게이트웨이 엔드포인트를 통해 처리되므로, “S3 API를 호출하여 객체를 저장하고 읽는” 요구사항과 맞다.
정리하면, 인터넷 미경유로 S3 접근을 보장하는 표준 방법은 S3 게이트웨이 엔드포인트(A) 다.
Answer: A, C
요구사항
- S3 버킷에 민감한 사용자 정보 저장
- VPC 내 EC2에서 실행되는 애플리케이션 계층만 이 버킷에 보안적으로 접근해야 함
- 이를 위한 단계 조합 2개 선택
즉, “VPC 안 앱만 S3에 안전하게 접근”하도록 하는 2가지 구성을 고르는 문제다.
A. VPC 내에서 Amazon S3용 VPC 게이트웨이 엔드포인트 구성
S3 게이트웨이 엔드포인트를 쓰면 VPC → S3 트래픽이 퍼블릭 인터넷을 거치지 않고 AWS 네트워크 안에서만 전달된다.
EC2가 NAT/인터넷 없이 S3에 접근할 수 있어, 네트워크 경로가 더 안전해진다.
민감한 사용자 정보를 다루는 트래픽이 인터넷으로 나가지 않도록 하는 보안 액세스의 한 축이다.
C. VPC에서 실행되는 애플리케이션 계층으로만 액세스를 제한하는 버킷 정책 생성
버킷 정책에서 aws:sourceVpc, aws:sourceVpce 등 조건으로 특정 VPC 또는 VPC 엔드포인트에서 오는 요청만 허용할 수 있다.
“VPC에서 실행되는 애플리케이션 계층으로만 액세스를 제한” = 해당 VPC(또는 VPC 엔드포인트) 에서 나온 요청만 S3 접근 가능하게 하는 것이다.
다른 네트워크·다른 서비스는 버킷에 접근할 수 없어, 접근 범위를 최소화할 수 있다.
정리하면, A(게이트웨이 엔드포인트) 로 경로를 안전하게 하고, C(버킷 정책) 로 “VPC 앱만 허용”으로 제한하는 조합이 정답이다.
Answer: B
요구사항
- 온프레미스 MySQL 앱을 AWS로 마이그레이션 (탄력성·가용성 목표)
- 정상 시간에 DB 읽기 부하가 많음
- 현재 문제 : 4시간마다 프로덕션 DB 전체 내보내기로 스테이징 DB 채움
→ 이 동안 프로덕션 사용자는 허용할 수 없는 지연
→ 스테이징은 절차가 끝날 때까지 사용 불가
목표 :
1) 애플리케이션 지연 완화 (내보내기로 인한 프로덕션 부하 제거)
2) 스테이징을 지연 없이 계속 사용 가능
즉, “프로덕션은 읽기 부하·가용성 확보”, “스테이징은 프로덕션에 부담 주지 않고, 대기 없이 사용 가능”한 구성을 고르는 문제다.
B. 다중 AZ Aurora 복제본으로 프로덕션 구성 + 데이터베이스 복제(클론) 로 요청 시 스테이징 DB 생성
1. 프로덕션 지연 완화
Aurora MySQL + 다중 AZ + 읽기 전용 복제본으로 읽기 부하를 복제본으로 분산한다.
스테이징을 채우는 방식을 전체 내보내기(mysqldump) 가 아니라 Aurora 클론(또는 스냅샷 기반 복제) 으로 바꾼다.
클론/스냅샷은 스토리지 스냅샷 기반이라, 프로덕션 Primary에 mysqldump처럼 큰 부하를 주지 않는다.
따라서 “4시간마다 전체 내보내기”로 인한 프로덕션 지연이 사라진다.
2. 스테이징 지연 없이 사용
Aurora 클론은 “요청 시” 프로덕션 클러스터(또는 스냅샷)에서 새 클러스터를 만든다.
복제본을 쓰는 방식이면, 스테이징용으로 복제본을 분리해 독립 클러스터로 두고 사용할 수 있다.
전체 덤프 → 복원 과정이 없어서, “절차가 끝날 때까지 스테이징 사용 불가”가 아니라 클론/복제본 준비만 되면 바로 스테이징 사용이 가능하다.
“데이터베이스 복제를 사용하여 요청 시 스테이징 데이터베이스를 생성”은 이 패턴(클론/복제 기반 스테이징 생성)을 잘 표현한다.
3. 탄력성·가용성
다중 AZ Aurora + 복제본으로 프로덕션의 가용성과 읽기 확장성을 만족한다.
정리하면, 프로덕션 부하 제거 + 스테이징 대기 없이 사용을 동시에 만족하는 것은 B(Aurora + 복제/클론 기반 스테이징) 다.
A,D. mysqldump는 프로덕션(또는 복제본)에서 전체 덤프를 뜨므로, 실행 시간 동안 CPU/IO 부하가 발생한다.
C. RDS 다중 AZ Standby는 장애 조치용으로만 쓰이며, 일반 트래픽이나 스테이징 용도로 직접 사용할 수 없다.
Answer: C
요구사항
- 사용자가 S3에 작은 파일 업로드
- 업로드 후 각 파일에 일회성·단순 처리 필요: 변환 후 JSON으로 저장해 나중에 분석
- 각 파일은 업로드 후 최대한 빨리 처리되어야 함
- 수요 변동 : 어떤 날은 많은 파일, 어떤 날은 적거나 없음
- 최소한의 운영 오버헤드
즉, “업로드 즉시 단순 변환 → JSON 저장”을 수요 변동에 맞추고 운영은 가볍게 하는 구성을 고르는 문제다.
C. S3가 이벤트 알림을 SQS 대기열로 보내도록 구성 → Lambda가 대기열에서 읽어 데이터 처리 → 결과 JSON을 DynamoDB에 저장
1. 업로드 후 최대한 빨리 처리
S3 이벤트로 객체 생성 시 SQS에 메시지를 보내고, Lambda를 SQS 트리거로 두면, 파일이 올라올 때마다 곧바로 Lambda가 실행된다.
“각 파일은 업로드 후 최대한 빨리 처리” 요구를 충족한다.
2. 수요 변동 대응
Lambda는 호출 수만큼만 실행되고, SQS는 메시지 수만큼 버퍼링한다.
많은 날에는 Lambda가 자동으로 많이 늘고, 적은 날에는 호출만 적게 나가서 유휴 비용이 거의 없다.
“수요가 다양할 것”이라는 조건에 잘 맞는다.
3. 일회성 단순 처리
Lambda에서 S3 객체를 읽어 변환한 뒤 JSON으로 만들어 DynamoDB에 넣으면, “일회성 단순 처리 + JSON 저장”이 구현된다.
DynamoDB에 JSON 문서를 저장하는 것은 일반적인 패턴이다.
4. 최소한의 운영 오버헤드
S3, SQS, Lambda, DynamoDB 모두 관리형 서비스라, 인스턴스·클러스터·스케일 정책을 직접 관리할 필요가 없다.
“최소한의 운영 오버헤드” 조건을 잘 충족한다.
정리하면, 즉시 처리 + 수요 변동 + 단순 처리 + 최소 운영을 한 번에 만족하는 것이 C다.
Answer: D
요구사항
- 본사 사용자가 제품 데이터에 접근하는 애플리케이션
- 제품 데이터는 Amazon RDS MySQL DB 인스턴스에 저장
운영 팀 목표 :
1) 애플리케이션 성능 저하 격리
2) 쓰기 트래픽과 읽기 트래픽 분리
솔루션 설계자 : 애플리케이션 성능을 빠르게 최적화할 방법 권장
즉, “읽기와 쓰기를 분리해서 성능을 신속히 개선”하는 구성을 고르는 문제다.
D. 데이터베이스에 읽기 전용 복제본 생성 → 원본과 동일한 컴퓨팅·스토리지로 읽기 전용 복제본 구성
1. 읽기/쓰기 트래픽 분리
읽기 전용 복제본을 두면, 쓰기는 Primary(원본) 만 사용하고 읽기는 복제본으로 보낼 수 있다.
“쓰기 트래픽에서 읽기 트래픽을 분리” 요구를 읽기 전용 복제본으로 충족할 수 있다.
2. 성능 저하 격리
읽기 부하가 Primary에 몰리지 않아, 쓰기 성능이 읽기 쿼리 때문에 떨어지는 현상을 줄일 수 있다.
읽기 부하는 복제본에서 처리되므로 “애플리케이션 성능 저하 격리”에도 맞다.
3. 원본과 동일한 리소스
복제본을 원본과 같은 컴퓨팅·스토리지로 두면,
읽기 부하가 많아도 복제본이 부족한 용량으로 인해 병목이 되기 어렵고
“신속하게 최적화”할 때 용량 부족으로 다시 튜닝할 가능성을 줄일 수 있다.
“절반” 리소스(C)보다 동일 리소스(D)가 성능 최적화 관점에서 더 안전한 권장이다.
4. 빠른 적용
RDS 콘솔/CLI에서 읽기 전용 복제본 생성만 하면 되고, 애플리케이션에서 읽기 연결만 복제본 엔드포인트로 바꾸면 된다.
“신속하게 최적화” 조건을 만족한다.
정리하면, 읽기/쓰기 분리 + 성능 격리 + 빠른 최적화를 만족하는 것은 D(읽기 전용 복제본, 원본과 동일 리소스) 다.
복제본을 절반 리소스로만 두면, 읽기 부하가 많을 때 복제본이 병목이 되어 성능 최적화가 제한될 수 있다.
Answer: C
요구사항
- 리전이 us-east-1이 아닌 경우
Statement 2에 의해 모든 ec2:* 가 Deny → 어떤 리전에서도 EC2 작업 불가.
- 리전이 us-east-1인 경우
Statement 2는 적용되지 않음 (리전이 us-east-1이므로).
Statement 1만 적용:
SourceIp가 10.100.100.0/24 → TerminateInstance 허용
그 외 SourceIp → TerminateInstance에 대한 Allow 없음 → 종료 불가.
정리하면, us-east-1에서만 EC2 사용 가능. 그중 TerminateInstance는 요청자 SourceIp가 10.100.100.0/24일 때만 허용.
C. 사용자는 사용자의 소스 IP가 10.100.100.254일 때 us-east-1 리전에서 EC2 인스턴스를 종료할 수 있습니다.
10.100.100.254는 10.100.100.0/24 대역에 포함된다 (10.100.100.0 ~ 10.100.100.255).
따라서 aws:SourceIp 조건을 만족하고, 리전은 us-east-1이므로 Deny도 적용되지 않는다.
그 결과 TerminateInstance가 허용된다.
Answer: D
요구사항
- 대규모 Microsoft SharePoint가 온프레미스에 있음
- Microsoft Windows 공유 파일 저장소 필요 (SharePoint는 보통 SMB 사용)
- AWS로 마이그레이션 예정
- 저장소 솔루션 조건: 고가용성 + 액세스 제어를 위한 Active Directory 통합
즉, “Windows 공유 파일(SMB) + 고가용성 + AD 통합”을 만족하는 AWS 스토리지를 고르는 문제다.
D. Windows 파일 서버용 Amazon FSx 파일 시스템 생성 + 인증을 위해 Active Directory 도메인 설정
1. Windows 공유 파일 저장소
FSx for Windows File Server는 SMB(Windows 파일 공유) 를 제공한다.
SharePoint가 요구하는 Windows 공유 파일 저장소 형태와 맞다.
2. 고가용성
FSx for Windows는 다중 AZ 배포를 지원해 자동 장애 조치가 가능하다.
“고가용성” 요구를 충족한다.
3. Active Directory 통합
FSx for Windows는 Active Directory와 통합되어,
파일/폴더 액세스 제어를 AD 사용자·그룹 기반으로 할 수 있고
인증을 AD 도메인으로 처리할 수 있다.
“액세스 제어를 위해 Active Directory와 통합” 요구와 정확히 맞다.
4. SharePoint 마이그레이션
SharePoint 문서/파일 저장소로 SMB 공유를 쓰는 경우, AWS에서는 FSx for Windows가 표준 권장이다.
정리하면, Windows 공유 파일 + 고가용성 + AD 통합을 한 번에 만족하는 것은 D(FSx for Windows + AD) 다.
Answer: C
요구사항
- S3 업로드 → S3 이벤트 → SQS 표준 큐 → Lambda(이미지 처리 후 이메일 발송)
- 문제 : 업로드한 이미지 하나당 이메일이 여러 번 감
- 원인 : SQS 메시지가 Lambda를 두 번 이상 호출해 여러 이메일이 생성됨
- 목표 : 최소한의 운영 오버헤드로 이 문제 해결
즉, “같은 메시지가 여러 번 처리되는 것”을 막는 방법을 고르는 문제다.
C. SQS 대기열의 가시성 제한 시간(Visibility Timeout) 을 함수 제한 시간과 일괄 처리 창 제한 시간의 합보다 크게 설정
1. 중복 처리의 흔한 원인
Lambda가 메시지를 받아 처리하는 동안 그 메시지는 가시성 제한 시간만큼 숨겨진(invisible) 상태다.
이 시간이 Lambda 실행 시간(및 재시도) 보다 짧으면, Lambda가 아직 처리 중인데 메시지가 다시 보임(visible) 이 되어 다른 Lambda 인스턴스가 같은 메시지를 받아 한 번 더 처리할 수 있다. 그 결과 같은 이미지에 대해 이메일이 여러 번 나간다.
2. 가시성 제한 시간을 충분히 늘리기
가시성 제한 시간을 Lambda 함수 제한 시간 + 일괄 처리 창보다 크게 두면,
Lambda가 끝나고 DeleteMessage를 호출할 때까지 메시지가 다시 노출되지 않고
같은 메시지가 다른 Lambda에 한 번 더 전달되는 상황을 막을 수 있다.
따라서 “SQS 메시지가 Lambda를 두 번 이상 호출”하는 문제를 설정 한 번으로 줄일 수 있다.
3. 최소한의 운영 오버헤드
큐 타입 변경, 코드 수정, 새 리소스 없이 SQS 가시성 제한 시간만 조정하면 된다.
정리하면, 가시성 제한 시간 부족으로 인한 중복 호출을 막는 표준적이고 부담 적은 방법이 C다.
B. SQS 표준 큐를 FIFO로 변경, 메시지 중복 제거 ID로 중복 메시지 버리기
FIFO와 중복 제거를 쓰면 중복 전달을 줄일 수 있어, 기술적으로는 도움이 될 수 있다.
다만 표준 → FIFO 전환은 큐 식별자/이름 변경(.fifo), S3 이벤트 알림 대상 큐 변경, 필요 시 중복 제거 ID 설계 등 변경 범위와 운영 부담이 크다.
“최소한의 운영 오버헤드”로 보면, 가시성 제한 시간만 늘리는 C가 더 적합하다.
Answer: D
요구사항
- 온프레미스 데이터 센터에서 호스팅되는 게임 애플리케이션용 공유 스토리지 필요
- Lustre 클라이언트로 데이터에 접근할 수 있어야 함
- 솔루션은 완전히 관리되는(fully managed) 서비스여야 함
즉, “Lustre + 완전 관리형” 공유 스토리지를 고르는 문제다.
D. Lustre 파일 시스템용 Amazon FSx 생성 → 파일 시스템을 원본 서버에 연결 → 응용 프로그램 서버를 파일 시스템에 연결
1. Lustre 클라이언트 접근
Amazon FSx for Lustre는 Lustre 프로토콜을 지원하는 관리형 파일 시스템이다.
Lustre 클라이언트를 사용해 마운트·접근할 수 있어, “Lustre 클라이언트로 데이터에 액세스” 요구를 충족한다.
2. 완전 관리형
FSx for Lustre는 관리형 서비스로, 스토리지 서버·패치·모니터링·고가용성 구성을 AWS가 담당한다.
“완전히 관리되어야 한다”는 조건을 만족한다.
3. 공유 스토리지
Lustre는 병렬 파일 시스템으로, 여러 서버가 동시에 같은 파일 시스템에 접근하는 공유 스토리지 용도에 적합하다.
원본 서버·애플리케이션 서버를 모두 FSx Lustre에 연결하는 구성이 가능하다.
정리하면, Lustre + 완전 관리형을 동시에 만족하는 것은 D(FSx for Lustre) 다.
Answer: C
요구사항
- EC2에서 컨테이너화된 애플리케이션 실행
- 다른 비즈니스 앱과 통신 전에 보안 인증서를 다운로드해야 함
- 거의 실시간으로 인증서를 암호화·복호화할 수 있는 매우 안전한 솔루션
- 암호화된 데이터를 고가용성 스토리지에 저장
- 최소한의 운영 오버헤드
즉, “인증서를 안전하게 보관하고 필요할 때 빠르게 복호화해 쓰면서, 고가용성과 최소 운영을 만족”하는 구성을 고르는 문제다.
C. KMS 고객 관리형 키 생성, EC2 역할이 KMS로 암호화 사용, 암호화된 데이터를 S3에 저장
1. 암호화·복호화에 KMS 사용
KMS는 키 관리·암호화·복호화를 담당하는 AWS 관리형 서비스다.
EC2 역할에 KMS 사용 권한만 주면, 앱이 KMS API로 인증서를 암호화·복호화할 수 있어 거의 실시간에 가깝게 사용할 수 있다.
Lambda + Python 암호화 라이브러리(B)는 직접 구현·유지보수가 필요해, “암호화·해독에 적합한” 관리형 방식은 KMS가 맞다.
2. 고가용성 스토리지 = S3
“암호화된 후 고가용성 스토리지에 저장”을 S3로 충족하는 것이 C다.
S3는 다중 AZ, 99.99% 가용성으로 고가용성 스토리지로 명시되며, 암호화된 인증서(암호문)를 S3에 두는 구성이 요구사항과 맞다.
3. 최소 운영
KMS 키 생성·EC2 역할 권한·S3 버킷만 구성하면 되고, 암호화·복호화 로직을 직접 짜거나 Lambda를 유지보수할 필요가 없다.
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 151-200 (1) | 2026.01.30 |
|---|---|
| AWS SAA-C03 Dump 101-150 (0) | 2026.01.29 |
| AWS SAA-C03 Dump 1-50 (1) | 2026.01.28 |
| 리눅스마스터 - 사용자 관리 (0) | 2025.04.13 |
| 정렬 알고리즘 (0) | 2024.10.17 |
