AWS SAA-C03 Dump 1-50

AWS SAA-C03  Dump 1-50

 

Answer: A

 

요구사항 

1. 여러 대륙의 글로벌 사이트 

2. 각 사이트 하루에 500GB

3. 최대한 빠르게 단일 S3 버킷으로 집계
4. 각 사이트는 고속 인터넷 연결 

5. 운영 복잡성 최소화

 

S3 Transfer Acceleration
• 전 세계 엣지 로케이션을 통해 가장 가까운 지점으로 업로드
• AWS 글로벌 네트워크를 활용해 대상 S3 버킷까지 고속 전송
• 글로벌 환경에서 업로드 지연 최소화

 Multipart Upload
• 500GB 같은 대용량 파일을 병렬로 업로드 가능
• 전송 속도 향상 + 실패 시 부분 재시도 가능

 

 

Answer: C

 

요구사항 

1. 로그 파일 분석
2. 로그는 이미 Amazon S3에 JSON 형식으로 저장
3. 쿼리는 단순 + 주문형(ad-hoc)
4. 기존 아키텍처 변경 최소화
5. 운영 오버헤드 최소화

 

Athena

S3에 저장된데이터를 그대로 SQL로 조회 가능
• 데이터 이동 X
• 로딩 X
• 인프라 프로비저닝 X

 

Answer: A

 

요구사항

1. AWS Organizations 사용 중
2. 관리 계정(Management Account)에 있는 S3 버킷
3. 조직(Organization) 내부 계정 사용자만 접근 가능하게 제한
4. 운영 오버헤드는 최소화

 

aws:PrincipalOrgID
• 요청을 보낸 주체가 특정 AWS Organization에 속해 있는지를 자동으로 검증
• 계정이 조직에 새로 추가되거나 제거되어도 정책 변경 불필요

 

S3 버킷 정책 한 번만 설정하면 끝
• 사용자/계정 개별 관리 X
• OU 구조 변경 영향 X
• 자동 확장성 O

 

Answer: A

 

요구사항

1. VPC 안의 EC2 인스턴스
2. Amazon S3 버킷의 로그를 처리
3.인터넷 연결 없이 S3 접근 필요
4. 프라이빗 네트워크 연결이 핵심

 

Gateway VPC Endpoint (for S3)
• VPC 내부에서 인터넷, NAT, IGW 없이 S3 접근 가능
• AWS 백본 네트워크를 통해 트래픽 전달
• S3 + DynamoDB 전용으로 설계됨

 

Answer: C

요구사항

1. 모든 사용자
2. 어떤 인스턴스로 접속해도
3. 동일한 문서 전체를 볼 수 있어야 함

Amazon EFS
• 여러 EC2 인스턴스가 동시에 마운트 가능
• 멀티 AZ, 공유 파일 시스템
• 웹 업로드 파일, 정적 리소스에 최적
• ALB + 다중 EC2 구조에서의 정석
• 상태 없는 EC2 + 공유 스토리지
• 스케일 아웃 시 추가 설정 불필요

 

 

Answer: B

요구사항 
1. 온프레미스 NFS 기반 NAS 사용 중
2. 비디오 파일 1MB ~ 500GB 총 70TB
3. 목적지: Amazon S3
4. 네트워크 대역폭 사용 최소화
5. 가능한 한 빠르게 마이그레이션
6. 운영 복잡성은 중요하지 않음 (속도 + 대역폭 우선)

AWS Snowball Edge
• 오프라인 데이터 전송
• 네트워크 대역폭 거의 사용 안 함
• 수십 TB ~ PB 단위 데이터 마이그레이션에 최적
• 대용량 파일(500GB)도 문제 없음
• 데이터가 더 이상 증가하지 않으므로 지속 동기화 필요 없음 딱 한 번 옮기고 끝

 

 

Answer: D

요구사항
1. 회사에 메시지 수집 애플리케이션 존재
2. 수십 개의 애플리케이션 / 마이크로서비스가 메시지를 소비
3. 메시지 트래픽이 급격히 변동 최대 초당 100,000건
4. 강한 분리(Decoupling)
5. 높은 확장성
6. 다수 소비자가 동시에 빠르게 소비 가능

SNS + SQS 패턴
• Publisher – Subscriber 모델
    - 메시지 생산자와 소비자 완전히 분리
SNS:
• 메시지를 즉시 fan-out
• 높은 처리량 (초당 수십만 건 이상 가능)
SQS:
• 각 소비자 애플리케이션마다 독립된 큐
• 소비 속도 달라도 서로 영향 없음
• 자연스러운 버퍼 역할

트래픽 폭증에도 SNS는 빠르게 전달 SQS가 메시지를 쌓아두며 안정성 확보

 

Answer: B

요구사항

• 분산 애플리케이션을 AWS로 마이그레이션
레거시 구조:
• 기본 서버(조정자) + 여러 컴퓨팅 노드
• 다양한 워크로드 처리
목표:
1. 탄력성(Elasticity) 극대화
2. 확장성(Scalability) 극대화
3. 현대적인 아키텍처

SQS
• 작업을 비동기 큐로 분리
• 기본 서버(중앙 조정자) 제거 가능
• 컴퓨팅 노드는 큐에서 작업을 Pull
• 자연스러운 백프레셔(back-pressure) 제공

큐 크기(길이) 기반 Auto Scaling
• 워크로드 양에 직접 반응
트래픽 급증 시:
• SQS 메시지 증가
• EC2 인스턴스 자동 확장
트래픽 감소 시:
• 인스턴스 자동 축소

 

 

Answer: B

요구사항
온프레미스 SMB 파일 서버 운영 중
파일 특성 :
• 생성 후 처음 7일은 자주 접근 (저지연 중요)
• 7일 이후에는 거의 접근하지 않음
문제 :
• 전체 데이터 증가
• 온프레미스 스토리지 한계 도달

1. 최근 파일은 저지연 액세스 유지
2. 전체 저장 공간 확장
3. 파일 수명 주기 관리 제공
4. 운영 복잡성 최소화

Amazon S3 파일 게이트웨이
• 온프레미스에서 SMB 인터페이스 그대로 사용
• 최근에 접근한 파일은 로컬 캐시에 유지 → 저지연 보장
• 오래된 파일은 S3에 저장 → 사실상 무제한 스토리지 확장
S3 수명 주기 정책
• 파일 생성 후 7일
     → S3 Glacier Deep Archive 로 자동 전환
• 장기 미사용 데이터 저장 비용 최소화

 

 

Answer: B

요구사항
• 전자상거래 웹 애플리케이션
• Amazon API Gateway REST API 로 주문 정보 수신
• 주문 처리 시스템 요구사항
    • 주문이 접수된 순서대로 처리되어야 함
• 비동기 처리 구조 (API → 백엔드 처리)

SQS FIFO Queue
• 메시지 순서 보장 (First-In-First-Out)
• MessageGroupId 기준으로 순서 유지
• 중복 제거 (MessageDeduplicationId) 가능
전자상거래 주문처럼 순서가 중요한 데이터에 최적

 

Answer: A

요구사항
1. DB 자격 증명 관리의 운영 오버헤드를 최소화

AWS Secrets Manager
• 데이터베이스 자격 증명 전용 서비스
• 다음을 완전 자동화로 제공:
    - 비밀번호 저장
    - 암호화 (KMS 연동)
    - 자동 비밀번호 회전
    - 애플리케이션에서 API로 안전하게 조회
특히 Amazon Aurora, RDS와 네이티브 통합이 매우 잘 되어 있음

EC2
 └─ IAM Role
     └─ Secrets Manager
          └─ Aurora DB (자동 회전)
• EC2에 IAM Role만 부여
• 코드에 비밀번호 하드코딩 X
• 설정 파일 관리 X

Answer: A

현재 아키텍처
• 글로벌 사용자
• ALB 뒤의 EC2 → 동적 콘텐츠
• S3 버킷 → 정적 콘텐츠
• Route 53 커스텀 도메인 사용 중

요구사항
1. 정적 + 동적 데이터 모두 성능 개선
2. 지연 시간(Latency) 최소화
3. 글로벌 서비스에 적합
4. 운영 복잡도는 불필요하게 증가시키지 않음

S3 버킷과 ALB를 오리진으로 포함하는 Amazon CloudFront 배포를 생성하고, Route 53에서 CloudFront로 라우팅

Amazon CloudFront
• 전 세계 엣지 로케이션에서 콘텐츠 제공
• 정적 콘텐츠(S3) 캐싱 → 매우 빠름
• 동적 콘텐츠(ALB) 도 엣지에서 가속 (Dynamic Content Acceleration)
• Route 53과 자연스럽게 연동

User
 ↓
Route 53 (Custom Domain)
 ↓
CloudFront
 ├─ S3 (Static Content)
 └─ ALB → EC2 (Dynamic Content)
• 사용자는 항상 가장 가까운 엣지 로케이션으로 접속
• 지연 시간 최소화
• 단일 도메인 유지 → 운영 단순

Global Accelerator는 TCP/UDP 레벨 가속, 캐싱 X, 정적 콘텐츠 최적화 X

Answer: A

요구사항
1. 월별 자격 증명(Username/Password) 자동 교체
2. 다중 리전 지원
3. 운영 오버헤드 최소화

AWS Secrets Manager
Secrets Manager는 RDS 자격 증명 관리에 특화된 서비스
• 자동 비밀번호 회전 (Rotation)
• 다중 리전 비밀 복제
• 암호화 자동 처리
• RDS MySQL과 네이티브 통합
특히
• Lambda를 직접 만들 필요 X
• 회전 로직 직접 구현 X
• 운영 작업 최소화

 

Answer: C

요구사항
• 읽기 요청이 쓰기보다 훨씬 많음
• 트래픽 증가 시 DB 성능 급격히 저하
• 읽기 워크로드를 자동으로 확장
• 고가용성(HA) 유지
• 운영 오버헤드는 최소화

Amazon Aurora
• 다중 AZ 기본 지원 → 고가용성 충족
• Aurora Read Replica
    • 읽기 요청 분산 처리
    • 최대 15개까지 확장 가능
• Aurora Auto Scaling
    • 읽기 트래픽 증가 시 자동으로 리드 레플리카 추가
    • 트래픽 감소 시 자동 축소
• 운영 오버헤드 ↓, 확장성 ↑

 

Answer: C

요구사항
• 프로덕션 VPC 들어오고 나가는 트래픽 보호
• 온프레미스에서는 검사 서버가 있었음
    • 트래픽 흐름 검사
    • 트래픽 필터링 (허용/차단)
• AWS에서도 동일한 기능 필요

AWS Network Firewall
• VPC 인라인 방화벽
• 지원 기능:
    • 상태 기반(Stateful) / 무상태(Stateless) 규칙
    • 트래픽 흐름 검사
    • IP / 포트 / 프로토콜 / 도메인 기반 필터링
• VPC Ingress / Egress 트래픽 보호 가능
• 온프레미스 검사 서버 역할을 그대로 대체 가능

 

Answer: B

요구사항
1. 데이터 레이크 (Amazon S3, Amazon RDS for PostgreSQL)
2. 데이터 시각화(Visualization) 필요
    • 모든 데이터 소스를 포함한 보고/대시보드
3. 접근 제어
    • 관리팀: 모든 시각화에 전체 액세스
    • 일반 직원: 제한된 액세스

Amazon QuickSight는 AWS의 대표적인 관리형 BI(시각화) 서비스
• S3, RDS(PostgreSQL) 직접 연결 가능
• 데이터 레이크 시각화에 최적화
• 서버 관리 필요 없음
사용자 / 그룹 기반 접근 제어 지원
• 관리자 그룹
    • 데이터 세트, 분석, 대시보드 전체 권한
• 일반 사용자 그룹
    • 읽기 전용, 특정 대시보드만 접근 가능

QuickSight는 IAM 역할 기반 권한 관리가 아님

 

 

Answer: A

요구사항
1. 애플리케이션은 Amazon EC2 인스턴스에서 실행됨
2. 문서 저장소로 Amazon S3 버킷 사용
3. EC2 인스턴스가 S3 버킷에 안전하게 접근해야 함
4. AWS 권장 방식, 운영 오버헤드 최소화가 전제

 EC2에서 AWS 서비스(S3)에 접근할 때의 표준 방식은 IAM Role
• EC2 인스턴스는 IAM 역할(Role) 을 통해 권한을 위임받음
• 자격 증명(Access Key, Secret Key)을 코드나 서버에 저장할 필요 없음
• AWS SDK / CLI가 임시 보안 자격 증명(STS) 을 자동으로 사용
• 보안 & 운영 측면에서 최적
    • 키 노출 위험 ❌
    • 키 회전 관리 ❌
    • 인스턴스 수가 늘어나도 역할만 붙이면 끝

 

Answer: A, B

요구사항
• 사용자가 이미지를 업로드
• 이미지 → S3 버킷 저장
• 자동으로 처리
• AWS Lambda로 이미지 압축
• 결과를 다른 S3 버킷에 저장
• 내구성 있는(state를 외부에 둔) + 상태 비저장 구성 요소
• 확장 가능하고 느슨하게 결합된 구조

 A. S3 → SQS 알림
• 사용자가 이미지를 업로드하면
• S3 이벤트 알림 → SQS
• 이벤트를 내구성 있게 버퍼링
• 갑작스러운 트래픽 폭증에도 안전

포인트
SQS = 내구성 있는 이벤트 큐
S3 이벤트를 바로 Lambda로 보내는 것보다 더 안정적

B. SQS → Lambda 트리거
• Lambda는 상태 비저장(stateless) 컴퓨트
• SQS 메시지를 하나씩 가져와 처리
• 처리 성공 시 메시지 자동 삭제
• 실패 시 재시도 / DLQ 구성 가능

📌 이 구조의 장점
• 자동 확장
• 재시도 내장
• 서버 관리 ❌
• 메시지 유실 ❌

흐름 : 
사용자 업로드
   ↓
S3 (원본 이미지 버킷)
   ↓ 이벤트 알림
SQS
   ↓
Lambda (이미지 압축)
   ↓
S3 (압축 이미지 버킷)

 

Answer: D

요구사항
• 3-계층 웹 애플리케이션
• 웹 서버로 들어오기 전 모든 트래픽 검사
• AWS Marketplace 타사 가상 방화벽 어플라이언스
• 어플라이언스는 IP 패킷을 수락하는 네트워크 인터페이스 기반
• 운영 오버헤드 최소화
즉, L3/L4 패킷 단위 검사 + 중앙 집중형 트래픽 인스펙션이 필요함

Gateway Load Balancer
GWLB는 AWS가 서드파티 네트워크 보안 어플라이언스용으로 만든 전용 서비스
GWLB의 핵심 특징
• L3/L4 IP 패킷 그대로 전달
• 방화벽, IDS/IPS, DPI 장비와 완벽 호환
• 확장, 고가용성 자동 처리
• 애플리케이션 VPC ↔ 검사 VPC 분리 가능
• 운영 오버헤드 최소

트래픽 흐름 
인터넷
 ↓
Application VPC
 ↓ (GWLB Endpoint)
Gateway Load Balancer
 ↓
가상 방화벽 어플라이언스
 ↓
웹 서버

 

Answer: D

요구사항 
1. 동일한 AWS 리전
2. 프로덕션 EBS 데이터를 테스트 환경으로 복제
3. 테스트에서 데이터를 수정해도 프로덕션에 영향 없어야 함
4. 일관되게 높은 I/O 성능 요구
5. 복제에 필요한 시간을 최소화해야 함
즉, 공유 ❌ (완전 복제 필요), 스냅샷 기반 복제 , 초기 성능 저하 없이 바로 고성능 I/O 필요

 EBS 빠른 스냅샷 복원(Fast Snapshot Restore, FSR)
• Lazy loading 없음
• 볼륨 생성 직후부터 최대 IOPS / 처리량
• 대용량 데이터라도 즉시 고성능
• 복제 시간 단축 + 성능 보장

C. EBS 스냅샷에서 볼륨을 생성하면:
• 처음 읽는 블록은 S3에서 가져오느라 느림(초기 I/O 성능 저하)
• 이걸 Lazy Loading 문제라고 함
• 대량 데이터일수록 워밍업 시간 김

 

Answer: D

요구사항
1. 하루 1회 웹사이트 오픈
2. 매일 24시간 동안 정확히 하나의 상품만 판매
3. 피크 시간에 시간당 수백만 요청
4. 밀리초(ms) 단위 지연 시간
5. 운영 오버헤드 최소화

즉, 트래픽 폭발적 (이벤트/드롭 커머스 구조), 서버 관리, 확장 관리 최소화, 글로벌 캐싱 + 서버리스가 유리

S3 + CloudFront + API Gateway + Lambda + DynamoDB

1. 정적 콘텐츠
• S3 + CloudFront
• 전 세계 엣지 로케이션 캐시
• 밀리초 단위 응답
• 수백만 요청도 문제 없음
• 서버 관리 ❌

2. 백엔드 처리
• API Gateway + Lambda
• 트래픽 급증 시 자동 확장
• 초당 수만~수십만 요청 처리 가능
• 오픈 시간에만 호출 → 비용 효율적

 3. 데이터 저장
• DynamoDB
• 단일 상품 구조에 최적
• 초고속 읽기/쓰기
• 트래픽 급증에도 성능 유지
• 서버/커넥션 관리 ❌

 

 

Answer: B

요구사항 
1. 접근 패턴이 섞여 있음 
    • 자주 액세스되는 파일 
    •  거의 안 쓰이지만 패턴이 예측불가 

S3 Intelligent-Tiering
• 멀티 AZ 저장 → AZ 장애에도 안전
• 접근 패턴을 자동으로 모니터링
• 객체를 자동으로 비용 최적 계층으로 이동
    • Frequent Access
    • Infrequent Access
• 접근 패턴을 미리 알 필요 없음
• 성능 저하 없음
• 검색 시 추가 복잡도 없음

 

Answer: B

요구사항 
1. 현재 S3 Standard 사용
2. 처음 1개월 동안은 자주 접근
3. 1개월 이후에는 접근하지 않음
4. 데이터는 무기한 보관

S3 Glacier Deep Archive 
• S3 스토리지 중 가장 저렴
• 장기 보관(수년~무기한)에 최적
• 조회 시간은 느리지만 문제에서는 1개월 이후 접근하지 않음
• 수명 주기 정책으로 자동 전환 가능
• 운영 오버헤드 거의 없음

 

Answer: B

요구사항
1. EC2 비용 증가 원인 분석
2. 원치 않는 인스턴스 유형의 수직 확장(vertical scaling) 식별
3. 최근 2개월간 비용 비교 그래프 필요
4. 심층 분석(Drill-down) 필요

 Amazon Cost Explorer
• 서비스별 / 인스턴스 유형별 / 기간별 비용 분석 가능
• 그래프 자동 생성
• 필터 & 그룹화 기능으로 수직 확장(t2 → m5 → r5 등) 추적 가능
• 콘솔에서 바로 사용 가능 → 추가 구성 불필요

비용 증가 원인 분석 → Cost Explorer
예산 초과 알림 → Budgets
원시 데이터 / 커스텀 분석 → CUR(Cost and Usage Report) + QuickSight

 

Answer: D

요구사항 
1. API Gateway + Lambda → Aurora PostgreSQL
2. 대용량 데이터 처리
3. POC 단계에서 Lambda 할당량(동시성)을 크게 늘려야 했음
4. 확장성 문제 발생
5. 구성 노력은 최소화
6. 서버리스 아키텍처 유지가 유리함

현재 문제점 API 요청이 들어올 때마다
    → Lambda가 즉시 DB(Aurora)에 쓰기
    → 동시 쓰기 폭증
결과:
• Lambda 동시성 증가 필요
• DB 커넥션 고갈
• 확장성 저하

SQS를 사용하면
API Gateway
   ↓
Lambda #1 (수신 전용)
   ↓
SQS Queue
   ↓
Lambda #2 (DB 로딩 전용)
   ↓
Aurora PostgreSQL

• 완전 비동기 처리
• 트래픽 버스트 완충(Buffering)
• Lambda 자동 확장 (SQS 기반 폴링)
• DB 쓰기 속도에 맞춰 처리량 조절 가능
• Lambda 동시성 강제 증가 불필요
• 구성 변경 최소 (서버리스 유지)

 

Answer: A

요구사항
• Amazon S3 버킷의 상태/구성 확인
• 핵심 포인트는 S3 버킷의 구성(Configuration)을 지속적으로 확인하는 것

AWS Config
• AWS 리소스의 구성 상태를 지속적으로 기록
• 구성 변경 이력 추적
• 규칙(Config Rule)을 통해
    • S3 퍼블릭 액세스 차단 여부
    • 버킷 암호화 설정 여부
    • 정책 준수 여부 등을 자동 평가

 

Answer: A

 

요구사항 
1. Amazon CloudWatch 대시보드에 애플리케이션 지표 표시
2. 제품 관리자에게 AWS 계정이 없음
3. 대시보드에 주기적으로 접근해야 함
4. 최소 권한 원칙(Least Privilege) 준수
5. 운영 오버헤드 최소화

CloudWatch 대시보드는 AWS 계정이 없어도 공유 가능
• 이메일 기반으로 공유 링크 생성
• 링크를 가진 사람은 읽기 전용으로 대시보드만 접근 가능
• IAM 사용자 생성 X
• 자격 증명 관리 X
• 최소 권한 원칙 완벽 충족 
• 운영 오버헤드 최소 

 

Answer: B

요구사항
• 여러 AWS 계정 (AWS Organizations 사용)
• 전사 공통 SSO 필요
• 사용자 / 그룹 관리는 계속 온프레미스 Microsoft AD
• 보안팀 관점 → 표준적이고 관리 쉬운 방식

AWS Management Console + IAM Identity Center(구 AWS SSO)
→ 양방향 트러스트 필수

AWS 공식 요구사항
• AWS Managed Microsoft AD는 단방향 / 양방향 트러스트 모두 지원
다음 서비스들은 양방향 트러스트가 필요
• AWS IAM Identity Center (AWS SSO)
• AWS Management Console
• Amazon Chime
• Amazon Connect
• Amazon QuickSight
• Amazon WorkSpaces / WorkDocs / WorkMai

 

Answer: A

 

요구사항
1. UDP 기반 VoIP 서비스
    → ALB 불가, NLB 또는 Global Accelerator 필요
2. 여러 AWS 리전에 배포
3. 가장 지연 시간이 짧은 리전으로 사용자 라우팅
4. 리전 간 자동 장애 조치(Failover)
5. Auto Scaling 그룹 기반 EC2

1. UDP 지원
• NLB: UDP 지원
• ALB: TCP/HTTP/HTTPS만 지원
VoIP는 UDP 기반 → NLB 필수

2. 지연 시간이 가장 짧은 리전으로 라우팅 AWS Global Accelerator
• Anycast IP 사용
• AWS 글로벌 엣지 네트워크 활용
• 사용자를 네트워크 기준으로 가장 가까운 리전으로 라우팅
→ Route 53보다 네트워크 레벨에서 더 빠르고 정확

3. 자동 리전 장애 조치 Global Accelerator
• 엔드포인트(NLB) 상태 헬스체크
• 리전 장애 시 자동으로 다른 리전으로 트래픽 전환

 

Answer: C

요구사항
1. Amazon RDS MySQL 
2. 월 1회, 48시간만 테스트 실행
3. 테스트 기간 외에는 DB 사용 안 함
4. 컴퓨팅/메모리 성능은 낮추면 안 됨
5. 테스트 실행 비용을 최대한 줄이기

RDS 인스턴스가 실행 중일 때만 컴퓨팅 비용 발생
• 스냅샷은 S3에 저장 → 저렴
• 테스트는 월 2일(48시간)만 필요
한 달에 한 번 48 시간 동안만 사용하고, 가장 비용 효율적인 방법을 사용해야하므로 스냅샷이 제일 저렴.

 

Answer: A

1. 대상 리소스
• Amazon EC2 인스턴스
• Amazon RDS DB 인스턴스
• Amazon Redshift 클러스터
2. 요구 사항
• 모든 리소스가 태그로 구성되어 있는지 보장
• 태그 누락 여부를 지속적으로 검사
• 구성 및 운영 오버헤드 최소화

AWS Config
• 리소스 구성 상태를 지속적으로 평가
• EC2, RDS, Redshift 모두 기본 지원
• required-tags 같은 관리형 규칙 제공
• 태그 누락 시 자동 감지,  콘솔 / 알림 / 보고서로 확인 가능

 

Answer: B

요구사항 
HTML, CSS, JavaScript 정적 콘텐츠 호스팅

S3에 정적 웹 사이트를 호스팅한다

 

Answer: C

요구사항
1. 트래픽 특성
• 피크 시 수십만 명 사용자
• 수백만 건의 금융 트랜잭션
2. 기능 요구
• 여러 내부 애플리케이션과 공유
• 거의 실시간(near real-time) 처리
• 확장성 필수
3. 데이터 처리
• 문서 DB(DynamoDB)에 저장 이전
• 민감 데이터 제거(마스킹/필터링) 필요
• 이후 저지연 검색 필요

Kinesis Data Streams
• 거의 실시간 스트리밍 (ms~초 단위)
• 수백만 TPS까지 수평 확장 가능
• 여러 소비자 애플리케이션이 동시에 동일 데이터 소비 가능 (fan-out)

Lambda + DynamoDB 조합
Lambda:
• 상태 비저장
• 실시간으로 민감 데이터 제거
• 운영 오버헤드 거의 없음
DynamoDB:
• 저지연 문서형 NoSQL
• 검색 성능 매우 우수
• 자동 확장

Producer
 → Kinesis Data Streams
    → Lambda (민감 데이터 제거)
        → DynamoDB (저지연 검색)
    → 다른 내부 앱들 (실시간 소비)

 

Answer: B

요구사항
1. AWS 리소스의 구성 변경 사항 추적
• 누가, 언제, 어떤 설정이 바뀌었는지
• 리소스의 상태(state) 변화 추적
2. AWS 리소스에 대한 API 호출 기록
• 누가 어떤 API를 호출했는지
• 감사(Audit), 보안, 규정 준수 목적

AWS Config
• 리소스 구성(Configuration) 추적 전용 서비스
    • 보안 그룹 규칙 변경
    • EC2 인스턴스 타입 변경
    • S3 퍼블릭 설정 변경
    • 현재 상태 + 변경 이력을 관리
• 규정 준수, 거버넌스에 핵심

AWS CloudTrail
• 모든 AWS API 호출 로그
    • RunInstances
    • PutBucketPolicy
    • ModifyDBInstance
• 누가(사용자/역할), 언제, 어떤 IP에서 호출했는지 기록
• 감사 및 보안 분석에 필수

구성 변경 추적 = AWS Config, API 호출 기록 = CloudTrail

 

Answer: D

요구사항
2. 대규모 DDoS 공격
• 감지 + 보호 둘 다 필요
3. ELB 뒤의 EC2 아키텍처
4. DNS는 타사 서비스 사용
• Route 53 의존 불가

AWS Shield Advanced
• 대규모 DDoS 공격 방어 전용 서비스
• L3 / L4 / L7 공격까지 보호
• 실시간 공격 탐지
• AWS DDoS Response Team(DRT) 지원
• 비용 보호(DDoS로 인한 스케일 비용 보호)

ELB에 직접 연결 가능
• Route 53 없이도 보호 가능
• ELB, ALB, NLB, CloudFront 모두 지원

 

Answer: B

요구사항
1. 두 AWS 리전
2. Amazon S3 버킷에 데이터 저장
3. AWS KMS 고객 관리형 키(CMK) 사용
4. 두 S3 버킷이 동일한 KMS 키로 암·복호화
5. 데이터와 키는 각 리전에 모두 존재

다중 지역 KMS 키 (Multi-Region CMK)
• 논리적으로 동일한 키
• 각 리전에 물리적으로 복제
• 한 리전에서 암호화한 데이터를 다른 리전에서 같은 키로 복호화 가능
 문제에서 요구한
 “동일한 KMS 키로 암호화 및 복호화”
 “데이터와 키는 각 리전에 저장” 을 유일하게 만족

 

Answer: B

요구사항
1. EC2 인스턴스에 원격으로 안전하게 접근
2. 기본 AWS 서비스 사용
3. AWS Well-Architected Framework 준수
4. 반복 가능하고 표준화된 프로세스

B. IAM 역할 + AWS Systems Manager Session Manager
• SSH 키, Bastion Host 불필요
• 퍼블릭 IP 없어도 접근 가능
• IAM 기반 접근 제어 → 보안 강화
• CloudTrail 로 접속 기록 감사 가능
• AWS Well-Architected 보안/운영 우수 사례
• 신규 인스턴스에도 역할만 붙이면 자동 적용

 

Answer: C

요구사항
• Amazon S3 정적 웹 사이트 호스팅
• 전 세계 사용자 증가
• 지연 시간(Latency) 감소
• 가장 비용 효율적인 방법

C. CloudFront + S3
• 전 세계 엣지 로케이션 캐싱
• S3 정적 웹 사이트와 최적의 조합
• 트래픽 증가 시 자동 확장
• Route 53과 자연스럽게 연동
• 가장 비용 효율적인 글로벌 콘텐츠 전송 방식

Answer: A

요구사항
• Amazon RDS for MySQL
• 데이터 2TB, 범용 SSD(gp2/gp3)
• 천만 행 이상
• 매일 수백만 건의 UPDATE/INSERT
• 일부 INSERT가 10초 이상 지연
• 원인 판단: 스토리지 성능 문제

A. 스토리지 유형을 프로비저닝된 IOPS SSD로 변경
• 스토리지 IOPS를 보장
• 대용량 DB + 쓰기 집중 워크로드에 최적
• UPDATE/INSERT 지연의 정석적인 해결책
• AWS 권장 아키텍처

Answer: A

요구사항
1. 수천 개 Edge 장치 → 대량 이벤트 수집
2. 매일 1TB, 이벤트 크기 2KB → 스트리밍 수집 필수
3. 고가용성
4. 비용 최소화
5. 추가 인프라 관리 원하지 않음
6. 즉각적인 분석 유지
7. 14일 동안 데이터 보관

Kinesis Data Firehose
• 수천 개 Edge 장치에서 직접 데이터 수집 가능
• 완전 관리형, 자동 스케일
• 고가용성 기본 제공
• 문제에서 요구한 “추가 인프라 관리 없음” 충족
Amazon S3
• 대량 데이터 저장 최저 비용
• 1TB/일 같은 로그·경고 데이터에 최적
Lifecycle 정책
• 14일 이후 → Glacier 자동 이동
• 운영 개입 없음
• 장기 보관 비용 최소화

Answer: B

요구사항
1. 여러 SaaS 소스와 통합하여 데이터 수집
2. 현재 구조 EC2가 SaaS API 연동 -> 데이터 수신 -> S3 업로드 ->업로드 완료 후 사용자 알림
3. 애플리케이션 성능이 느림
4. 성능 최대한 개선
5. 운영 오버헤드는 최소화

Amazon AppFlow
• SaaS ↔ AWS 서비스 전용 완전 관리형 통합 서비스
• EC2 완전히 제거 가능
• 자동 확장
• 재시도, 오류 처리 내장

 

SaaS → S3 직접 전송에 최적화된 서비스 AppFlow
• Salesforce, Zendesk, ServiceNow 등

업로드 완료 알림 처리 방식 S3 Event Notification → SNS
• 이벤트 기반
• EC2 폴링 제거

Answer: C

요구사항
• 단일 VPC
• EC2 인스턴스 여러 AZ, 여러 서브넷, 서로 통신 X
• EC2 ↔ Amazon S3 이미지 다운로드/업로드
• 단일 NAT Gateway 경유
• 문제점 : 데이터 전송 요금 증가
• 목표 : 리전 데이터 전송 요금 회피 + 가장 비용 효율적

EC2 → NAT Gateway → Internet → S3
• NAT Gateway 데이터 처리 요금
• AZ 간 데이터 전송 요금

S3 Gateway VPC Endpoint
• VPC 내부에서 S3로 직접 연결
• NAT Gateway 완전히 우회
• 인터넷 미사용
• AZ 간 데이터 전송 요금 
• 시간당 비용 (Gateway Endpoint는 무료)
• 트래픽 기반 과금 

EC2 → VPC Endpoint → S3

 

Answer: B

• 온프레미스 애플리케이션
• 시간에 민감한 대량 데이터
대상: Amazon S3
문제:
    • 인터넷 대역폭 제한
    • 내부 사용자 불만
요구 사항:
1. 적시 백업
2. 인터넷 연결 영향 최소화
3. 장기 솔루션

AWS Direct Connect 
• 온프레미스 ↔ AWS 간 전용 회선
• 공용 인터넷을 사용하지 않음
• 안정적이고 예측 가능한 대역폭
• 대량 데이터 전송에 최적
• 장기 사용 시 비용 효율적

 

On-Prem → Direct Connect → AWS → S3

 

Answer: A, B

요구사항
• 중요한 데이터가 있는 S3 버킷
• 우발적인 삭제(accidental deletion)로부터 보호
• 보안 강화가 아니라 삭제 복구/방지가 목적

A. S3 버전 관리 (Versioning)
• 객체가 삭제되더라도 실제 데이터는 이전 버전으로 남아 있음
삭제 시:
• 객체가 완전히 사라지는 게 아니라
• Delete Marker만 추가됨
• 언제든지 이전 버전으로 복구 가능

B. MFA 삭제 (MFA Delete)
• 버전 관리가 활성화된 버킷에서만 사용 가능
• 다음 작업 시 MFA 인증 필수
    • 객체의 영구 삭제
    • 버전 관리 비활성화
• 실수나 악의적인 삭제를 강력하게 차단

Answer: B, E

 

SNS → Lambda 구조에서 네트워크 장애로 메시지가 유실되는 문제를 어떻게 막을 것인가

B. SNS → SQS 구독
• SNS 주제에 SQS 대기열을 구독시킴
• SNS는 메시지를 SQS에 안정적으로 전달
• SQS는 메시지를 보존 (최대 14일)

E. Lambda가 SQS를 폴링
• Lambda를 SQS 이벤트 소스로 연결
• Lambda가 실패하면? 메시지는 다시 대기열로 복귀, 성공할 때까지 재시도
• at-least-once 처리 보장

 

Answer: B

요구사항
1. SFTP로 업로드되는 대용량 파일 (200GB 초과 가능)
2. PII(개인 식별 정보) 포함 여부를 탐지
3. PII가 발견되면 관리자에게 경고
4. 문제 대응(조치)을 자동화

대용량 객체를 자동으로 PII 분석 + 관리형 서비스 + 이벤트 기반 알림

Amazon Macie
• 완전 관리형 PII 탐지 서비스
• S3 객체를 자동으로 스캔
• 이름, 이메일, 전화번호, 주민번호 등 PII 자동 분류
• 대용량 객체 지원 (수백 GB 가능)

 

Answer: D

요구사항 
• 용량 보장 (Guaranteed Capacity)
• 1주일: 장기 계약(1~3년)이 아닌 단기적인 이벤트 대응
• 3개의 가용 영역

D - "필요한 지역(리전)과 3 개의 가용 영역을 지정하는 온디맨드 용량 예약을 생성합니다."

용량 보장 기능: 온디맨드 용량 예약(On-Demand Capacity Reservations)은 예약 인스턴스(RI)와 달리, 구매 즉시 해당 AZ에 컴퓨팅 용량을 물리적으로 확보해 줍니다. 용량이 부족하여 인스턴스 생성에 실패하는 상황을 방지할 수 있습니다.

기간의 유연성: 용량 예약은 약정이 필요 없습니다. 1주일 이벤트가 끝나면 언제든지 종료할 수 있어 단기 프로젝트에 적합합니다.

위치 지정: 문제에서 요구한 '3개의 특정 가용 영역'을 지정하여 각 AZ별로 정확한 용량을 확보할 수 있습니다.

예약 인스턴스는 1년 또는 3년 약정이 필수 

Answer: D

요구사항
내구성(Durability): 인스턴스가 중단, 종료 또는 하드웨어 장애가 발생하더라도 데이터가 사라지지 않아야 합니다. (인스턴스 스토어는 인스턴스 종료 시 데이터가 삭제됨)

고가용성(High Availability): 여러 가용 영역(AZ)에서 접근 가능하거나 장애 시에도 서비스가 유지되어야 합니다.

카탈로그 데이터: 웹 사이트에서 항목을 보여주기 위한 데이터이므로, 필요할 때 즉시 읽고 쓸 수 있는 성능이 필요합니다.

D - "카탈로그를 Amazon Elastic File System(Amazon EFS) 파일 시스템으로 이동합니다."

내구성 및 가용성: Amazon EFS는 데이터를 여러 가용 영역(Multi-AZ)에 걸쳐 복제하여 저장합니다. 따라서 하나의 AZ에 장애가 발생해도 데이터는 안전하며 서비스가 지속됩니다.

공유 스토리지: 여러 EC2 인스턴스가 동시에 EFS에 마운트하여 카탈로그 데이터를 읽고 쓸 수 있어 웹 서버 확장에 유리합니다.

관리형 서비스: 서버리스 형태의 파일 시스템으로, 용량이 자동으로 확장되며 관리 부담이 적습니다

 

Answer: B

요구사항
1년 이내 데이터: 무작위 액세스(Random Access)가 발생하며, 가장 빠른 검색 속도가 필요함.
1년 이후 데이터: 액세스 빈도가 낮으며(Infrequent Access), 검색 지연(Latency)이 허용됨.
검색 기능(Query): 대량의 파일 중 원하는 파일을 찾을 수 있는 쿼리 기능이 필요함.
최적화: 위 조건을 만족하면서 비용을 최소화해야 함.

B - "Amazon S3 Intelligent-Tiering에 저장 + 1년 후 Glacier Flexible Retrieval 이동 + Athena & S3 Glacier Select로 쿼리"

비용 효율성: 1년 동안의 무작위 액세스에 대해 Intelligent-Tiering이 계층을 자동 관리하여 비용을 아껴줍니다.
검색의 편의성: RDS(D 보기)처럼 별도의 인덱싱 데이터베이스를 구축하고 유지 관리하는 오버헤드 없이, Athena를 통해 S3에 있는 파일을 바로 쿼리하는 것이 클라우드 네이티브한 방식입니다.
Glacier Select 활용: 1년이 지나 Glacier로 넘어간 파일들에 대해서도 전체를 복원할 필요 없이 Glacier Select로 필요한 부분만 빠르게 쿼리할 수 있다는 점이 결정적인 차별점입니다.

 

Answer: D

요구사항
대규모 관리: 1,000개의 EC2 인스턴스라는 대규모 환경입니다.
보안 긴급성: "가능한 한 빨리" 보안 취약성을 수정해야 합니다.
타사 소프트웨어 패치: OS 기본 업데이트뿐만 아니라 특정 타사 소프트웨어를 대상으로 합니다.

D - "AWS Systems Manager Run Command 를 사용하여 모든 EC2 인스턴스에 패치를 적용하는 사용자 지정 명령을 실행합니다."

즉각성 (Ad-hoc): 문제에서 요구한 것은 "가능한 한 빨리"입니다. Run Command는 대기 시간이나 예약 없이 실행 즉시 1,000대의 인스턴스에 명령을 동시 전달합니다.

타사 소프트웨어 지원: Patch Manager(B)는 주로 OS 및 표준 애플리케이션 패치에 특화되어 있습니다. 특정 "타사 소프트웨어"의 커스텀 패치 로직을 실행하기에는 사용자 지정 스크립트를 즉시 쏠 수 있는 Run Command가 가장 유연하고 적합합니다.

에이전트 기반 자동화: Systems Manager 에이전트(SSM Agent)가 설치되어 있다면 SSH 접속 없이도 안전하게 대량의 인스턴스를 제어할 수 있습니다.