본문 바로가기

자격증

AWS SAA-C03 Dump 351-400

by 천뱅 2026. 2. 1.

AWS SAA-C03 Dump 351-400

Answer: D

요구사항
데이터 관리 애플리케이션을 AWS로 이전
이벤트 기반 아키텍처로 전환
워크플로의 다양한 측면을 수행하면서 더 분산되고 서버리스로 구성
운영 오버헤드 최소화
→ 워크플로 오케스트레이션 + 서버리스(EC2 없음) + 분산·이벤트 기반 + 관리형이 필요함.

D. AWS Step Functions + 상태 머신 + Lambda
역할: AWS Step Functions에서 워크플로 구성 → 상태 머신 생성 → 상태 머신이 AWS Lambda를 호출해 워크플로 단계 처리
워크플로: Step Functions = 상태 머신 기반 워크플로 오케스트레이션 (순서, 분기, 재시도, 에러 처리)
서버리스: Lambda로 단계 처리 → EC2 없음 → “서버리스 개념 사용” 충족
분산: 단계별로 Lambda가 분리·호출 → 분산 구조
이벤트 기반: 상태 머신을 EventBridge·API 등으로 트리거 가능 → 이벤트 기반 활용
운영 최소화: Step Functions·Lambda 모두 관리형 → 운영 오버헤드 최소화

C가 틀린 이유
EventBridge는 이벤트 라우팅(이벤트 버스, 규칙, 타깃)용
순차·분기·상태·재시도가 있는 워크플로를 “EventBridge에서 구축”하는 구조는 아니며, Step Functions가 그 역할을 함
“일정에 따라 Lambda 호출”만으로는 다단계 워크플로 요구사항을 충족하기 어렵고, D(Step Functions + Lambda) 가 더 적합함

Answer: B

요구사항
온라인 멀티플레이어 게임용 네트워크 설계
UDP 네트워킹 프로토콜 사용
8개 AWS 리전에 배포
최종 사용자에게 고품질 게임 경험을 위해 대기 시간·패킷 손실 최소화 필요
→ UDP 지원 + 8개 리전 + 최종 사용자 → 최적 엔드포인트 라우팅으로 지연·패킷 손실 최소화가 필요함.

B. AWS Global Accelerator — UDP 리스너 + 엔드포인트 그룹
역할: AWS Global Accelerator 구성 — UDP 리스너와 리전별 엔드포인트 그룹(8개 리전) 설정
UDP: Global Accelerator는 UDP·TCP 지원 → 게임의 UDP 요구사항 충족
지연·패킷 손실 최소화: 고정 애니캐스트 IP로 사용자 트래픽 수신 → AWS 글로벌 네트워크로 가장 가깝고 정상인 엔드포인트로 라우팅 → 대기 시간·패킷 손실 최소화
8개 리전: 리전마다 엔드포인트 그룹(NLB, EC2 등)을 두면, 사용자는 한 IP로 접속하고 자동으로 최적 리전으로 연결됨
“최종 사용자에게 고품질 게임 경험, 대기 시간·패킷 손실 최소화”에 직접 대응

C가 틀린 이유
Amazon CloudFront는 HTTP(S)·WebSocket 등 웹/스트리밍용 CDN
일반 UDP 트래픽을 위한 “UDP 활성화” 옵션이 없고, 게임용 UDP 프로토콜 지원 대상이 아님 → UDP 게임 트래픽에는 Global Accelerator(B) 가 맞음

Answer: B

요구사항
단일 AZ EC2에서 3계층 웹 앱 + 자체 관리형 MySQL (EBS 1TB io2 프로비저닝 IOPS)
피크 시 읽기·쓰기 합계 1,000 IOPS 예상
2배 IOPS 용량 유지(→ 2,000 IOPS 필요)
중단 최소화, 성능 안정화, 비용 절감
DB 계층을 고가용·내결함·완전 관리형으로 이전
가장 비용 효율적으로 충족
→ 완전 관리형 DB + 다중 AZ + 2,000 IOPS 이상 + 비용 절감이 필요함.

B. RDS for MySQL 다중 AZ + gp2
역할: Amazon RDS for MySQL 다중 AZ 배포, 범용 SSD(gp2) EBS 사용
완전 관리형: RDS = 패치·백업·장애 조치 등 AWS 관리 → “완전 관리형” 충족
고가용·내결함: 다중 AZ = 주·대기 복제본, 자동 장애 조치 → “고가용·내결함” 충족
2배 IOPS: gp2 = GB당 3 IOPS 기준 → 1TB gp2 = 3,000 IOPS 기준 → 2,000 IOPS 요구 충족
비용 효율: gp2는 io2(프로비저닝 IOPS) 보다 저렴 → “비용 절감·가장 비용 효율적” 충족
중단 최소화: RDS 마이그레이션(스냅샷·DMS 등)으로 이전 가능, 이후 다중 AZ로 안정화

B: RDS for MySQL 다중 AZ + gp2 = 완전 관리형 + 고가용·내결함 + 2배 IOPS(gp2 1TB = 3,000 IOPS) + 비용 절감(io2 대비) → 요구사항 충족
A: io2 = 성능은 높으나 비용이 커 “가장 비용 효율적”에는 B가 유리
C: S3 = DB 아님
D: EC2 MySQL = 완전 관리형 아님

Answer: B

요구사항
서버리스 앱: API Gateway + Lambda + Amazon RDS for PostgreSQL
문제: 피크·예측 어려운 트래픽 시 DB 연결 타임아웃으로 애플리케이션 오류 증가
목표: 애플리케이션 오류 감소 + 최소한의 코드 변경
→ 연결 타임아웃 원인(연결 고갈)을 줄이면서 코드 변경을 최소화하는 방법이 필요함.

원인 정리
Lambda가 트래픽에 따라 동시 실행 수가 크게 늘어남
실행마다 DB 연결을 새로 열면 RDS max_connections를 넘기 쉬움 → 연결 타임아웃 → 애플리케이션 오류
해결 방향: 연결 풀링으로 실제 DB 연결 수를 줄이기

B. RDS Proxy 활성화
역할: RDS DB 인스턴스에 RDS Proxy를 붙이고, Lambda는 RDS 엔드포인트 대신 Proxy 엔드포인트로 연결
연결 타임아웃 감소: RDS Proxy가 연결 풀을 관리 → 많은 Lambda 동시 실행이 소수의 실제 DB 연결을 공유 → 연결 고갈·타임아웃 감소 → 애플리케이션 오류 감소
최소 코드 변경: 연결 문자열만 RDS Proxy 엔드포인트로 바꾸면 됨(로직 변경 거의 없음)
피크·예측 어려운 트래픽에도 연결 수를 풀 크기로 제어 가능

Answer: B

요구사항
Amazon S3 Standard에 데이터 객체 저장
75% 데이터가 30일 후 거의 액세스되지 않음
모든 데이터에 즉시 액세스 가능해야 함
동일한 고가용성·복원력 유지
스토리지 비용 최소화
→ 30일 후 저활용 데이터를 저렴한 스토리지 클래스로 옮기되, 즉시 액세스 + Standard와 같은 고가용·복원력(멀티 AZ) 이어야 함.

B. 30일 후 S3 Standard-IA로 이동
역할: S3 수명 주기 정책으로 30일 경과 객체를 S3 Standard-Infrequent Access(Standard-IA) 로 전환
즉시 액세스: Standard-IA는 검색 대기 시간 없음 — Standard와 같이 즉시 조회·다운로드 가능
동일 고가용·복원력: Standard-IA는 멀티 AZ 저장 → 가용성·내구성이 Standard와 동일한 수준
비용 최소화: Standard-IA는 저장 단가가 Standard보다 낮음 → 75% 데이터를 30일 후 IA로 옮기면 스토리지 비용 절감
“즉시 액세스” + “동일한 고가용성 및 복원력” + “스토리지 비용 최소화” 모두 충족

Answer: A, D

요구사항
공개 점수판을 데이터 센터 → AWS로 이전
ALB 뒤 Amazon EC2 Windows Server로 동적 애플리케이션 호스팅
고가용성 스토리지 필요
정적 파일 + 동적 서버 측 코드 구성
→ 정적 파일용 고가용 스토리지 1개 + 서버 측 코드용 고가용·공유 스토리지 1개, 총 2개 선택.

A. 정적 파일 → S3 + CloudFront
역할: 정적 파일을 Amazon S3에 저장하고, Amazon CloudFront로 엣지에서 캐싱
고가용성: S3·CloudFront 모두 멀티 AZ/엣지 기반 → 정적 파일 고가용·고성능 제공
정적 파일 요구사항에 직접 대응

D. 서버 측 코드 → FSx for Windows File Server
역할: 서버 측 코드를 Amazon FSx for Windows File Server에 저장하고, 각 EC2 Windows 인스턴스에 FSx 볼륨(공유) 탑재
Windows·고가용: FSx for Windows = SMB 공유, Windows Server와 호환, 다중 AZ 옵션으로 고가용 구성 가능
공유: 여러 EC2 Windows 인스턴스가 동일 FSx 공유를 마운트해 서버 측 코드 공유
동적 서버 측 코드 요구사항에 직접 대응

Answer: C

요구사항
ALB 뒤 EC2에서 앱 실행, CloudFront 오리진 = ALB
S3에 10억 개 이상 이미지, 초당 수천 개 처리
이미지 크기 동적 조정 + 고객에게 적절한 형식 제공
최소한의 운영 오버헤드
→ 요청 단위로 리사이즈·형식 변환이 가능하고, 확장·운영 부담이 적은 방식이 필요함.

C. Lambda@Edge + 이미지 라이브러리
역할: Lambda@Edge에 이미지 처리 라이브러리(예: Sharp) 포함 → 이미지를 제공하는 CloudFront 동작에 연결
동적 리사이즈: 요청(쿼리/헤더)에 따라 Lambda@Edge가 오리진(S3/ALB)에서 이미지를 가져와 리사이즈 후 반환
형식 제공: User-Agent·Accept 등에 따라 WebP/JPEG 등으로 변환해 반환
최소 운영: 서버리스 — EC2·이미지 서버 유지보수 불필요
확장: 엣지에서 실행되어 초당 수천 요청 처리에 적합
“동적 리사이즈 + 적절한 형식 + 최소 운영” 모두 충족

C: Lambda@Edge + 이미지 라이브러리 = 동적 리사이즈 + 형식 변환 + 엣지 처리·확장 + 최소 운영 → 요구사항 충족
A: EC2 + 라이브러리 = 운영·확장 부담 큼
B, D: 오리진 요청 정책·응답 헤더 정책 = 이미지 변환 기능 없음

Answer: C

요구사항
환자 기록(PHI) 을 Amazon S3에 저장
모든 PHI가 전송 중·저장 시 암호화되어야 함
규정 준수 팀이 미사용 데이터(at rest) 에 대한 암호화 키를 관리해야 함
→ 전송 암호화(HTTPS) + 저장 암호화(SSE) + 고객이 관리하는 키(KMS) 로 규정 준수 팀이 키 관리 가능해야 함.

C. SecureTransport + SSE-KMS + KMS 키를 규정 준수 팀이 관리
역할: S3 버킷 정책에 aws:SecureTransport 조건으로 HTTPS(TLS) 만 허용 → 전송 중 암호화 충족. 기본 암호화를 AWS KMS(SSE-KMS) 로 설정하고, 고객 관리형 KMS 키를 사용해 규정 준수 팀에 키 관리 권한 부여
전송 암호화: SecureTransport → HTTP 차단, HTTPS만 허용
저장 암호화: SSE-KMS → S3 객체가 KMS 키로 암호화됨
키 관리: 고객 관리형 KMS 키 사용 시 키 정책·로테이션 등으로 규정 준수 팀이 키를 관리할 수 있음 → “미사용 데이터에 대한 암호화 키를 관리” 충족
요구사항(전송·저장 암호화 + 키 관리) 모두 충족

C: SecureTransport(전송 암호화) + SSE-KMS(저장 암호화) + 고객 관리형 KMS 키(규정 준수 팀이 키 관리) → 요구사항 충족
A: ACM = S3 저장 암호화·키 관리와 무관
B: SSE-S3 = 키를 고객이 관리할 수 없음
D: Macie = 암호화·키 관리 아님

Answer: B

요구사항
동일 VPC에서 API Gateway 프라이빗으로 두 개의 REST API 운영
BuyStock REST 서비스가 CheckFunds REST 서비스를 호출(주식 구매 전 자금 확인)
문제: VPC 플로우 로그에서 BuyStock → CheckFunds 호출이 VPC가 아니라 인터넷으로 나가는 것으로 확인
목표: API가 VPC를 통해 통신하도록 수정, 코드를 가장 적게 변경
→ CheckFunds(API Gateway) 로 가는 트래픽이 인터넷이 아니라 VPC(PrivateLink) 로 가도록 해야 함.

B. 인터페이스 엔드포인트 사용
역할: API Gateway용 VPC 인터페이스 엔드포인트(PrivateLink) 를 VPC에 생성
동작: BuyStock 백엔드(Lambda/EC2 등)가 CheckFunds API를 호출할 때, API Gateway 호스트명이 인터페이스 엔드포인트의 프라이빗 IP로 이름 해석되도록 Private DNS 활성화 → 트래픽이 인터페이스 엔드포인트로만 가고 인터넷을 타지 않음
VPC 내 통신: PrivateLink로 API Gateway와 통신하므로 VPC 플로우 로그에서도 VPC 내/PrivateLink 경로로만 보이게 됨
최소 코드 변경: 엔드포인트 + Private DNS 설정만으로 기존 API Gateway URL을 그대로 써도 됨(이름 해석만 엔드포인트로 바뀜) → 코드 변경 최소

C. 게이트웨이 엔드포인트는 S3·DynamoDB 전용
API Gateway에는 게이트웨이 엔드포인트가 없고, 인터페이스 엔드포인트(B) 만 사용 가능 → C는 잘못된 선택

Answer: C

요구사항
1. 서브 밀리초(sub-millisecond) 지연 시간
• 멀티플레이어 게임 → 매우 빠른 읽기 성능 필요
• 일반 RDB(RDS)나 S3는 불리
• DynamoDB + DAX 는 대표적인 초저지연(read) 조합

2. 과거 데이터에 대한 일회성 쿼리
• 운영 DB에서 직접 분석 X
• S3 + Athena 조합이 정석
• “one-time query” → 배치/분석용 스토리지 필요

3. 운영 오버헤드 최소화
• 서버 관리, 스트리밍 파이프라인, 커스텀 스크립트 X
• 관리형 서비스 + 기본 기능 선호

C. Amazon DynamoDB + DAX + S3 + Athena
1. 실시간 게임 데이터 처리
• DynamoDB
완전 관리형 NoSQL
대규모 트래픽에 자동 확장
• DAX
인메모리 캐시

서브 밀리초 읽기 지연 시간 보장
게임, 랭킹, 상태 조회에 최적

2. 과거 데이터 분석
• DynamoDB 테이블 Export → S3
별도 서버나 스트림 관리 불필요
• Amazon Athena
S3 데이터에 대해 SQL로 일회성 쿼리
인프라 관리 없음

3. 운영 오버헤드 최소
• 서버 X
• 스트림 관리 X
• 배치 스크립트 X
• 모두 AWS 관리형 서비스

Answer: B, E

요구사항
특정 지불 ID에 대한 메시지가 전송된 순서대로 수신되어야 함
그렇지 않으면 결제가 잘못 처리될 수 있음
→ 지불 ID별로 메시지 순서 보장이 필요함

B. Kinesis Data Streams — 결제 ID를 파티션 키
역할: Amazon Kinesis Data Streams에 메시지를 쓸 때 결제 ID를 파티션 키로 사용
순서 보장: 같은 파티션 키는 같은 샤드로만 들어가고, 같은 샤드 안에서는 레코드 순서가 유지됨 → 같은 결제 ID에 대한 메시지는 전송 순서대로 소비 가능
지불 ID별 순서 요구사항 충족

E. SQS FIFO 큐 — 결제 ID를 메시지 그룹 ID
역할: Amazon SQS FIFO 큐에 메시지를 쓰고, 결제 ID를 메시지 그룹 ID(Message Group ID) 로 설정
순서 보장: FIFO 큐는 메시지 그룹 ID별로 전송 순서(FIFO) 를 보장 → 같은 결제 ID끼리는 전송된 순서대로 수신·처리 가능
지불 ID별 순서 요구사항 충족

Answer: B, E

요구사항
지불 ID별로 메시지 순서가 보장되어야 함

B. Amazon Kinesis Data Streams — 파티션 키 = 결제 ID
동작: 같은 파티션 키(결제 ID)를 가진 레코드는 같은 샤드로만 들어가고, 샤드 내에서는 FIFO 순서가 유지됩니다.
순서 보장: 같은 결제 ID → 같은 파티션 → 같은 샤드 → 처리 순서 보장.
적합: 이벤트 스트림, 실시간 처리, 재생(재처리)이 필요한 지불 이벤트에 적합.

E. Amazon SQS FIFO — 메시지 그룹 ID = 결제 ID
동작: FIFO 큐에서 메시지 그룹 ID(Message Group ID)를 결제 ID로 설정하면, 같은 그룹 ID의 메시지는 한 번에 하나씩, 순서대로 처리됩니다.
순서 보장: 같은 결제 ID = 같은 메시지 그룹 → 그룹 내 FIFO 보장.
적합: 큐 기반 비동기 처리, 지불 단계별 메시지(생성→검증→완료 등) 순서가 중요한 경우에 적합.

Answer: B, D

요구사항
저장 및 전송 중 데이터 암호화
저장: 서버 측 암호화(SSE)
전송: TLS 등 암호화된 연결만 허용
승인된 직원만 데이터 접근
KMS 사용 시: 키 정책(key policy)으로 어떤 보안 주체가 키를 사용할 수 있는지 제한

B. SNS + KMS 고객 관리 키 + 키 정책
SNS 서버 측 암호화: AWS KMS 고객 관리 키(CMK)로 SNS 주제 암호화 → 저장 시 암호화 충족.
키 정책: 키 정책에 “인증된 보안 주체 집합”만 kms:Decrypt, kms:GenerateDataKey 등 사용 가능하도록 제한 → 승인된 직원만 해당 데이터(복호화) 가능.
전송: SNS는 API 호출이 HTTPS(TLS)로 이루어지므로, 별도 설정 없이도 전송 중 암호화가 적용됨.
→ SNS 쪽 요구사항을 충족하는 올바른 조합입니다.

D. SQS + KMS 고객 관리 키 + 키 정책 + 대기열 정책(TLS)
SQS 서버 측 암호화: KMS 고객 관리 키로 SQS 큐 SSE 활성화 → 저장 시 암호화 충족.
키 정책: 키 정책으로 키 사용을 “인증된 보안 주체 집합”으로 제한 → 승인된 직원만 큐 메시지 복호화/접근 가능.
대기열 정책: aws:SecureTransport 조건으로 TLS를 통한 연결만 허용하도록 설정 → 전송 중 암호화를 정책 수준에서 강제.
→ SQS 쪽에서 저장·전송 암호화와 접근 제어를 모두 만족하는 올바른 조합입니다.

A. SQS SSE는 켜지만, “기본 키 정책”은 AWS 관리형 키(aws/sqs)를 전제로 함. 고객 관리 키가 아니어서 승인된 직원만 키 사용하도록 제한하기 어렵고, 전송 중 암호화(TLS)를 정책으로 강제하는 내용이 없음.
C. SNS 암호화 + TLS 조건은 맞는 방향이지만, “기본 키 정책”만 언급되어 있어 AWS 관리형 키에 가깝고, 고객 관리 키 + 키 정책으로 “승인된 보안 주체만” 제한한다는 요구를 명확히 충족하지 못함. B가 더 적절함.
E. SQS + 고객 관리 키 + TLS 조건은 맞지만, 키 사용 제한을 “IAM 정책”으로만 한다고 되어 있음. KMS에서는 키 정책이 우선이며, 키 사용 허용/거부는 키 정책에 반드시 반영해야 함. “키 정책을 적용하여 제한”이 아니라 IAM만으로 제한한다고 해서 E는 부적절함.

Answer: C

요구사항
“5분 전” 같은 특정 시점으로 DB 복원
지난 30일 동안의 어느 시점이든 복원 가능
즉, Point-in-Time Recovery(PITR) + 약 30일 보존이 필요합니다.

C. 자동 백업(Automated backups)
RDS 자동 백업을 사용하면 자동 백업과 트랜잭션 로그가 함께 활성화됩니다.
복원 시 특정 일시(초 단위)를 지정해 그 시점 상태로 복구할 수 있습니다(PITR).
보존 기간은 1~35일까지 설정 가능하므로, 30일로 설정하면 “지난 30일 동안 변경 5분 전” 복구 요구를 만족합니다.
따라서 “30일 이내, 사고 5분 전 시점으로 복원” 요구사항을 만족하는 기능은 자동 백업입니다.

Answer: D

구성
API Gateway → Lambda → DynamoDB, Cognito 사용자 풀으로 사용자 식별
요구사항
구독이 있는 사용자만 프리미엄 콘텐츠 접근
최소한의 운영 오버헤드로 구현

D. API 사용 계획 및 API 키
API 사용 계획(Usage Plan): 호출 빈도/할당량·쓰로틀 설정 + 어떤 API/스테이지에 접근할 수 있는지 구분.
API 키: 클라이언트별(또는 구독 등급별)로 키를 발급하고, 해당 키를 특정 사용 계획에 연결 가능.
적용 방식
예: 무료 사용 계획 / 프리미엄 사용 계획 두 가지를 만든 뒤,
프리미엄 콘텐츠 API는 프리미엄 사용 계획이 연결된 API 키가 있을 때만 호출 가능하도록 설정.
구독 사용자에게는 프리미엄용 API 키(또는 프리미엄 계획에 연결된 키)를 발급/갱신하고, 비구독 사용자에게는 무료 계획만 연결된 키를 사용하게 하면, API Gateway 단에서 구독 여부에 따라 접근을 나눌 수 있음.

최소 운영 오버헤드
API Gateway 콘솔/API만으로 사용 계획·API 키·리소스 정책 설정 가능.
WAF 규칙 유지보수, DynamoDB 세분화 권한 설계, Lambda 안에 복잡한 권한 로직 넣는 것보다 설정 중심으로 처리 가능.
따라서 “구독 사용자만 프리미엄 접근 + 최소 운영” 요구를 만족하는 것은 D입니다.

Answer: A

시나리오 정리
UDP 기반 애플리케이션
Route 53 지연 시간 기반 라우팅으로 미국·아시아·유럽 온프레미스로 라우팅 중
규정 준수: 애플리케이션은 온프레미스에서 호스팅 유지
목표: 성능·가용성 개선 (호스팅은 그대로 두고 라우팅/가속만 개선)

A. NLB 3개 + Global Accelerator + CNAME
3개 리전에 NLB(Network Load Balancer) 를 두고, 각 NLB를 온프레미스 엔드포인트(IP 타깃) 로 트래픽을 보내도록 구성합니다. AWS Global Accelerator 로 가속기를 만들고 이 3개 NLB를 엔드포인트로 등록한 뒤, 애플리케이션 접근은 가속기 DNS를 가리키는 CNAME 으로 제공합니다.

UDP 지원: NLB는 Layer 4 로드밸런서로 UDP 를 지원하고, Global Accelerator도 Layer 4에서 UDP 를 지원합니다. 따라서 UDP 기반 앱에 적합합니다.
온프레미스 유지: NLB의 IP 타깃 기능으로 온프레미스 서버 IP를 등록해 트래픽만 전달하면 되므로, 실제 앱은 온프레미스에 그대로 둔 채 규정을 지킬 수 있습니다.
성능: Global Accelerator의 Anycast IP 와 AWS 글로벌 네트워크를 사용해 사용자 → 가장 가까운 엣지 → 해당 리전 NLB → 온프레미스로 라우팅되므로 지연이 줄고 성능이 개선됩니다.
가용성: 가속기가 엔드포인트(NLB)에 대해 헬스 체크 를 하고, 장애 시 다른 리전 NLB로 자동 페일오버 하므로 가용성이 높아집니다.

B. ALB는 Layer 7(HTTP/HTTPS) 전용이라 UDP를 지원하지 않습니다. UDP 앱에는 사용할 수 없습니다.
C. NLB는 UDP를 지원하지만, CloudFront 는 HTTP/HTTPS(및 WebSocket)용 CDN이라 UDP를 지원하지 않습니다. UDP 트래픽은 처리할 수 없습니다.
D. ALB와 CloudFront 모두 UDP 미지원 이라 UDP 기반 애플리케이션 요구사항을 만족할 수 없습니다.

Answer: A

요구사항
모든 신규 사용자에게 적용
특정 복잡성 요구 사항 (길이, 대·소문자, 숫자, 기호 등)
IAM 사용자 암호에 대한 필수 교체 기간 (만료 일수)

A. 전체 AWS 계정에 대한 암호 정책 설정
계정 수준 암호 정책(Account password policy)을 설정하면 해당 AWS 계정의 모든 IAM 사용자에 일괄 적용됩니다.
복잡성: 최소 길이, 대문자/소문자/숫자/비영숫자 요구, 이전 암호 재사용 방지 등 설정 가능
필수 교체 기간: “암호 만료”를 활성화하고 일수(최대 365일) 지정 가능
신규 사용자: 계정에 추가되는 모든 신규 IAM 사용자는 이 정책을 따르며, 기존 사용자도 다음 암호 변경 시부터 적용됨
별도 도구 없이 IAM 콘솔/CLI에서 한 번 설정하면 되므로 운영 부담이 적습니다.

B. IAM에는 사용자별 암호 정책이 없습니다. 암호 정책은 계정당 하나만 있으며, 계정에 설정한 정책이 모든 IAM 사용자에 적용됩니다. “각 IAM 사용자에 대한 암호 정책”은 지원되지 않습니다.
C. 복잡성·교체 기간은 AWS 계정 암호 정책으로 충분히 설정 가능합니다. 타사 소프트웨어는 불필요하고 운영 복잡도만 늘어납니다.
D. IAM 사용자 생성 시 CloudWatch 이벤트로 “암호를 적절한 요구 사항으로 설정”하는 방식은 일반적으로 쓰이지 않고, 복잡성·만료 기간 같은 정책은 계정 암호 정책으로 정의하는 것이 맞습니다. 또한 “Create_newuser” 같은 표준 이벤트 이름으로 동작하는 구조가 아니므로 부적절합니다.

Answer: A

요구사항
일정에 따라 여러 개의 1시간 작업 실행
서로 다른 팀, 공통 프로그래밍 언어 없음 → 언어/런타임이 제각각
단일 EC2에서 돌리면 성능·확장성 우려
최소한의 운영 오버헤드로 해결

A. AWS Batch + EventBridge로 작업 실행·예약
AWS Batch로 각 작업을 Job으로 정의해 실행하고, Amazon EventBridge(CloudWatch Events) 로 일정(cron) 에 맞춰 해당 Job을 제출하는 방식입니다.

다양한 언어: Batch는 컨테이너(도커 이미지) 기반이라, 팀마다 다른 언어로 만든 작업을 각각 다른 이미지로 넣을 수 있습니다. 공통 언어가 없어도 됩니다.

1시간 작업: Batch Job은 최대 24시간까지 실행 가능하므로, 1시간짜리 작업을 그대로 실행할 수 있습니다.
성능·확장성: Batch가 컴퓨팅 환경(EC2 또는 Fargate) 을 관리하고, 작업 양에 맞춰 리소스를 늘렸다 줄였다 합니다. 한 EC2에 몰아넣지 않아도 되므로 성능·확장성 문제를 줄일 수 있습니다.

예약: EventBridge 규칙으로 cron 표현식을 두어 “매일 9시”, “매주 월요일”처럼 Job 제출 시점을 정할 수 있습니다.
최소 운영: Batch·EventBridge 모두 관리형 서비스라, AMI·ASG·스케줄러 서버를 직접 관리할 필요가 없어 운영 부담이 적습니다.

Answer: C

요구사항
프라이빗 서브넷의 EC2가 인터넷에 있는 라이선스 서버와 통신해야 함 (아웃바운드만 필요)
관리형 솔루션으로 운영·유지보수를 최소화해야 함

C. 퍼블릭 서브넷의 NAT 게이트웨이 + 프라이빗 서브넷 기본 경로
NAT 게이트웨이를 퍼블릭 서브넷에 두고, 각 프라이빗 서브넷의 경로 테이블에서 기본 경로(0.0.0.0/0)를 그 NAT 게이트웨이로 보내는 구성입니다.

NAT는 퍼블릭 서브넷에: NAT(인스턴스든 게이트웨이든)는 인터넷으로 나가려면 인터넷 게이트웨이(IGW) 로 가는 경로가 있어야 합니다. IGW 경로가 있는 서브넷이 퍼블릭 서브넷이므로, NAT는 반드시 퍼블릭 서브넷에 두어야 합니다. 그래야 프라이빗 서브넷 → NAT → IGW → 인터넷(라이선스 서버) 흐름이 됩니다.

NAT 게이트웨이 선택: NAT 인스턴스는 EC2를 직접 관리(패치, 장애 대응, 고가용성 구성)해야 해서 운영 부담이 큽니다. NAT 게이트웨이는 AWS 관리형이라 프로비저닝만 하면 되고, 가용성·패치·모니터링을 AWS가 담당하므로 “관리형·최소 유지보수” 요구에 맞습니다.

경로 설정: 프라이빗 서브넷의 기본 경로를 NAT 게이트웨이로 두면, 해당 서브넷의 EC2에서 나가는 트래픽이 NAT 게이트웨이를 거쳐 인터넷으로 나가므로 라이선스 서버 통신이 가능합니다.

A. NAT 인스턴스를 퍼블릭 서브넷에 두고 경로를 넣으면 연결성은 됩니다. 다만 인스턴스는 OS 패치, 장애 대응, 고가용성 구성 등을 직접 해야 해서 관리형·최소 유지보수 요구를 충족하지 못합니다. “관리형 솔루션”에는 NAT 게이트웨이가 적합합니다.

B. NAT 인스턴스를 프라이빗 서브넷에 두면, 그 서브넷에는 IGW로 가는 경로가 없어서 NAT 자체가 인터넷에 나갈 수 없습니다. 따라서 프라이빗 EC2 → 인터넷(라이선스 서버) 통신이 불가능합니다.

D. NAT 게이트웨이를 프라이빗 서브넷에 두는 것도 같은 이유로 잘못된 설계입니다. 프라이빗 서브넷에는 IGW 경로가 없으므로 NAT 게이트웨이를 통한 아웃바운드 인터넷 접속이 되지 않습니다.

Answer: B, D

요구사항
EKS 클러스터 + EBS 기반 관리형 노드 그룹
유휴 데이터는 KMS 고객 관리형 키(CMK) 로 암호화
최소한의 운영 오버헤드로 적용

B. EKS 클러스터 생성 후 EBS 볼륨을 찾아 고객 관리형 키로 암호화 활성화
클러스터 생성 후 노드에 붙는 EBS 볼륨을 식별하고, 해당 볼륨(또는 앞으로 생성될 볼륨)이 고객 관리형 키(CMK) 로 암호화되도록 설정하는 단계입니다. 새 노드 그룹/볼륨은 생성 시 CMK를 지정해 암호화하고, 기존 볼륨이 있다면 암호화 정책(예: 기본 EBS 암호화에 CMK 지정, 또는 노드 그룹/런치 템플릿에서 암호화 키 지정)을 적용해 “EBS는 모두 CMK로 암호화” 상태로 맞춥니다. 이렇게 해야 유휴 데이터(디스크)가 CMK로 보호됩니다.

D. 고객 관리형 키 권한을 부여하는 정책이 있는 IAM 역할 생성 후 EKS 클러스터에 연결
EBS 볼륨을 CMK로 암호화·사용하려면, 볼륨을 생성·연결하는 주체(EC2/노드)에 KMS 권한이 있어야 합니다. kms:CreateGrant, kms:Decrypt, kms:DescribeKey 등 CMK 사용에 필요한 권한을 부여한 IAM 정책을 만들고, 이 정책이 붙은 IAM 역할을 EKS 클러스터(또는 노드 그룹/노드 IAM 역할)에 연결해야 합니다. 이 역할이 없으면 노드가 CMK로 암호화된 EBS를 마운트·사용할 수 없어, B만으로는 동작하지 않습니다. 따라서 “EBS 암호화 설정(B)”과 “KMS 사용 권한 부여(D)” 조합이 필요합니다.

Answer: B

요구사항
수백만 개 고해상도 GIS 이미지, 지리 코드당 이미지 1개
자연 재해 시: 몇 분마다 수만 개 이미지 업데이트(순간 부하 급증)
가용성·확장성 필요, 비용 효율 중요

정답: B. S3에 이미지 + DynamoDB에 지리 코드·S3 URL
이미지는 Amazon S3에 저장하고, 지리 코드를 키로, 이미지 S3 URL을 값으로 하는 메타데이터는 Amazon DynamoDB에 저장하는 구성입니다.

확장성: 자연 재해 시 “몇 분마다 수만 건 업데이트”처럼 쓰기 부하가 몰려도 DynamoDB는 자동으로 수평 확장합니다. 쓰기 용량만 늘리거나 온디맨드로 두면 됩니다. RDS Oracle은 쓰기 확장에 한계가 있어 이런 버스트에 불리합니다.

가용성: S3와 DynamoDB 모두 다중 AZ, 고가용성 설계이며, RDS만 쓰는 것보다 객체 저장(S3)과 메타데이터(DynamoDB)를 나누면 장애 영향이 줄어듭니다.

비용 효율: 수백만 개의 대용량 이미지(바이너리)는 S3에 두는 것이 RDS/Oracle에 BLOB으로 넣는 것보다 훨씬 저렴합니다. 메타데이터(키–URL)만 DynamoDB에 두면 항목 크기가 작아 비용이 적고, 지리 코드 기준 조회에도 적합합니다.
데이터 모델: “지리 코드당 이미지 하나”이므로 지리 코드 = 파티션 키, S3 URL = 속성으로 두면 조회·갱신이 단순합니다.

---

A. 이미지와 지리 코드를 모두 Oracle 테이블에 저장하면, 수백만 개 대용량 이미지를 RDS 스토리지에 두게 되어 스토리지 비용이 크고, 대량 BLOB I/O로 성능 한계가 빠르게 옵니다. “몇 분마다 수만 건 업데이트” 같은 버스트에 RDS 쓰기 확장성도 부족해 비용·확장성 모두 불리합니다.
C. DynamoDB 항목 크기 제한은 400KB입니다. 고해상도 GIS 이미지는 보통 그보다 훨씬 커서, 이미지 자체를 DynamoDB에 저장하는 것은 불가능합니다. DAX는 캐시일 뿐 이 제한을 바꾸지 않으므로 C는 요구사항을 만족할 수 없습니다.
D. 이미지는 S3, 메타데이터(지리 코드·URL)는 Oracle RDS에 두는 경우입니다. 이미지 비용은 줄지만, “몇 분마다 수만 건” 메타데이터 업데이트는 RDS 쓰기 한계에 부딪힙니다. 인스턴스 스케일 업에만 의존하게 되어 확장성·비용 모두 DynamoDB+S3(B)보다 불리합니다.

Answer: D

요구사항
자동차 IoT 센서 → Kinesis Data → S3 저장, 매년 수조 개 객체 생성
매일: 지난 30일 데이터로 ML 모델 재교육 → 0~30일 데이터는 자주 접근
연 4회: 지난 12개월 데이터로 분석·다른 ML 모델 학습 → 30일~1년 데이터는 가끔 접근
1년까지: 최소 지연으로 사용 가능해야 함
1년 이후: 보관(아카이브) 목적으로만 보관
가장 비용 효율적인 스토리지 구성 필요

D. S3 Standard + 수명 주기(30일 → Standard-IA, 1년 → Glacier Deep Archive)
S3 Standard에 적재한 뒤, 수명 주기 정책으로
30일 후 → S3 Standard-IA
1년 후 → S3 Glacier Deep Archive 로 옮기는 구성입니다.

0~30일: 매일 ML 재교육으로 자주 접근 → Standard가 적합합니다. 조회 수수료 없고, 자주 쓰는 데이터에 비용 효율적입니다.

30일~1년: 연 4회만 사용 → Standard-IA로 이동하면 스토리지 단가는 Standard보다 낮고, 조회는 필요할 때만 하므로 비용이 적습니다. Standard-IA는 객체 조회 지연이 짧아 “1년까지 최소 지연” 요구를 만족합니다.

1년 이후: 보관만 하면 되므로 Glacier Deep Archive로 이동해 장기 보관 비용을 최소화합니다.
접근 패턴(30일/1년/1년 초과)이 명확하므로, 수명 주기로 스토리지 클래스를 단계별로 바꾸는 방식이 가장 비용 효율적입니다.

Answer: D

요구사항
us-east-1 내 3개 VPC → VPC 간 통신 필요
단일 온프레미스 데이터 센터로 매일 수백 GB 전송, 지연에 민감
비용 효율을 최대한 높인 네트워크 설계 필요

D. Direct Connect 1개 + Transit Gateway + VPC·DX 연결
데이터 센터에서 AWS로 Direct Connect 연결 1개만 두고, Transit Gateway(전송 게이트웨이) 를 만들어 각 VPC 3개와 Direct Connect를 모두 Transit Gateway에 연결하는 구성입니다.

비용 효율: Direct Connect를 1개만 쓰면 포트·시간당 비용을 한 번만 내면 됩니다. 3개 VPC마다 VPN 또는 DX를 따로 두는 것보다 훨씬 저렴합니다.

VPC 간 통신: 3개 VPC를 모두 Transit Gateway에 연결하면, TGW가 허브가 되어 VPC 간 라우팅이 됩니다. 같은 리전이면 TGW를 통한 VPC 간 트래픽에 추가 데이터 전송 비용이 없어 비용 효율적입니다.

온프레미스 연결: Direct Connect 1개를 Direct Connect Gateway에 붙이고, 이 DX Gateway를 Transit Gateway와 연결하면, 3개 VPC 모두 한 개의 DX로 데이터 센터와 통신할 수 있습니다. 수백 GB/일·지연 민감 트래픽에는 VPN보다 Direct Connect가 적합합니다.

구성 요약: 데이터 센터 ↔ Direct Connect(1개) ↔ Direct Connect Gateway ↔ Transit Gateway ↔ VPC1, VPC2, VPC3. VPC 간은 TGW, 온프레미스와는 DX 1개로 모두 해결됩니다.

⸻
AWS Transit Gateway는 여러 VPC, 온프레미스 네트워크, VPN, Direct Connect를 하나의 중앙 허브로 연결하는 네트워크 라우터 서비스다.

TGW 없을 때 문제 (VPC Peering 지옥)
• VPC가 10개면 → 피어링 45개
• 라우팅 테이블 복잡
• 전이 라우팅 불가
• 온프레미스 연결 시 구성 난이도 ↑
관리 지옥 + 확장성 없음

TGW 있으면
• 모든 VPC가 TGW 하나에만 연결
• 온프레미스도 TGW로 연결
• 중앙 집중식 라우팅
• 확장 쉬움

Answer: A

요구사항
주문 처리 분산 애플리케이션, 여러 서버리스 기능·AWS 서비스 포함
워크플로 중 수동 승인 단계 필요
여러 Lambda를 하나의 반응형 서버리스 앱처럼 동작하게 결합
EC2, 컨테이너, 온프레미스에서 돌아가는 데이터·서비스까지 오케스트레이션
최소한의 운영 오버헤드

A. AWS Step Functions
AWS Step Functions로 주문 처리 워크플로를 상태 머신으로 정의하는 방식입니다.

여러 Lambda 결합: 상태 머신에서 단계별로 Lambda를 호출해 “주문 검증 → 재고 확인 → 결제 → …”처럼 순서 있는 워크플로로 묶을 수 있습니다. 여러 Lambda가 하나의 반응형 서버리스 애플리케이션처럼 동작하게 할 수 있습니다.

수동 승인: Step Functions는 Wait for callback, Human approval 패턴을 지원합니다. 특정 상태에서 승인될 때까지 대기했다가, 승인/거부 결과를 받고 다음 단계로 넘어가도록 설계할 수 있어 “워크플로의 일부로 수동 승인” 요구를 충족합니다.
EC2·컨테이너·온프레미스 오케스트레이션: Activity 태스크로 워커(EC2, 컨테이너, 온프레미스)가 Step Functions 태스크를 폴링해 실행하고, 완료 시 콜백으로 상태 머신을 진행시킬 수 있습니다. Lambda뿐 아니라 EC2·컨테이너·온프레미스 서비스를 같은 워크플로에 포함해 오케스트레이션할 수 있습니다.

최소 운영: Step Functions는 관리형 서비스라 인프라·스케일링·모니터링을 AWS가 담당하고, 워크플로 정의만 작성하면 됩니다. 큐·이벤트를 직접 엮어서 구현하는 것보다 운영 부담이 적습니다.

Answer: A

요구사항
Amazon RDS for MySQL 사용
대부분의 연결이 서버리스 애플리케이션(Lambda 등)에서 발생
DB 트래픽이 불규칙하게 크게 변동
수요가 많을 때 데이터베이스 연결 거부 오류 발생
최소한의 운영 오버헤드로 해결 필요

원인: 연결 수 초과(Connection exhaustion)
서버리스(Lambda)는 동시 실행이 많을수록 각 실행이 DB 연결을 새로 열려고 합니다. RDS는 max_connections 제한이 있어, 동시 실행이 많아지면 이 한도를 넘어서 연결 거부가 발생합니다. I/O 부족이나 고가용성 부족이 아니라 연결 수 문제입니다.

A. RDS Proxy
RDS Proxy를 두고, 애플리케이션이 RDS가 아니라 RDS Proxy에만 연결하도록 구성하는 방식입니다.
연결 풀링: RDS Proxy가 클라이언트 연결을 풀링합니다. 수천 개의 Lambda 연결 요청을 받아도, 실제 RDS에는 제한된 수의 연결만 유지하고 그 위에서 다중화(multiplexing)합니다. 그래서 연결 수 초과를 막을 수 있습니다.
서버리스에 적합: Lambda처럼 짧은 수명·많은 동시 실행 환경에서 연결을 Proxy가 관리해 주므로, “수요가 많을 때 연결 거부” 현상을 줄이는 데 맞는 솔루션입니다.
최소 운영: RDS Proxy는 관리형 서비스라, 프록시 생성 후 애플리케이션 연결 문자열만 Proxy 엔드포인트로 바꾸면 됩니다. 인스턴스 마이그레이션이나 앱 로직 대규모 변경 없이 적용 가능해 운영 부담이 적습니다.

Answer: B

요구사항
EC2 Auto Scaling 그룹으로 인스턴스 프로비저닝
시작되는 즉시 감사 시스템에 보고 전송
종료되는 즉시 감사 시스템에 보고 전송
소프트웨어 버전·패치·설치된 시스템 등 Amazon EC2 정보를 중앙 감사 시스템에 집중화하는 것이 목표

B. EC2 Auto Scaling 수명 주기 후크(Lifecycle Hook)
EC2 Auto Scaling 수명 주기 후크를 사용해, 인스턴스가 시작될 때(EC2_INSTANCE_LAUNCHING) 와 종료될 때(EC2_INSTANCE_TERMINATING) 에 각각 사용자 지정 스크립트를 실행하고, 그 스크립트에서 감사 데이터를 감사 시스템으로 보내는 방식입니다.

시작 시: 인스턴스가 런칭 상태로 들어갈 때 LAUNCHING 후크가 발생합니다. 후크에서 Lambda를 호출하거나, 인스턴스 내부에서 스크립트를 실행해 버전·패치·설치 정보를 수집해 감사 시스템으로 보낸 뒤, 후크를 완료(CompleteLifecycleAction)하면 됩니다.

종료 시: 인스턴스가 종료 상태로 들어갈 때 TERMINATING 후크가 발생합니다. 이 시점에 같은 방식으로 스크립트를 실행해 “종료 시점” 감사 데이터를 보낸 뒤, 후크를 완료할 수 있습니다. 종료되는 순간을 정확히 잡을 수 있습니다.

즉시 동작: 수명 주기 후크는 인스턴스 상태 전환 시점에 바로 트리거되므로, “시작 및 종료되는 즉시” 보고한다는 요구를 가장 직접적으로 만족합니다.

효율성: 예약된 Lambda로 주기적으로 돌리거나, user data만 쓰는 방식보다 “시작/종료 시점”에만 실행되므로 불필요한 폴링·중복 실행이 없고, 종료 시 보고도 놓치지 않습니다.

Answer: B

요구사항
실시간 멀티플레이어 게임, UDP로 클라이언트–서버 통신
Auto Scaling 그룹으로 게임 서버 확장
하루 중 수요 급증 → 트래픽 분산·DB 모두 수요에 맞춰 확장 필요
게이머 점수·기타 비관계형 데이터 저장
개입 없이 확장되는 DB 솔루션 필요

B. NLB(트래픽 분산) + DynamoDB 주문형(데이터 저장)
트래픽 분산: Network Load Balancer(NLB) 는 Layer 4 로드밸런서로 UDP를 지원합니다. 게임 트래픽(UDP)을 Auto Scaling 그룹의 인스턴스에 분산하는 데 적합합니다.
데이터 저장: Amazon DynamoDB 주문형(On-Demand) 은 비관계형(키-값) 스토어로, 게이머 점수 같은 데이터에 맞습니다. 용량을 미리 정하지 않고 트래픽에 따라 자동으로 확장되므로 “개입 없이 확장” 요구를 충족합니다.

Answer: B

요구사항
API Gateway + Lambda + RDS 구조의 프론트엔드 앱
API 요청 시 Lambda가 많은 라이브러리를 로드한 뒤 RDS에 연결해 처리 후 응답
모든 사용자의 응답 대기 시간을 가능한 한 낮추기
운영 변경 횟수는 최소화

B. Lambda 프로비저닝된 동시성(Provisioned Concurrency)
프로비저닝된 동시성을 해당 Lambda 함수에 설정하면, 지정한 개수만큼의 Lambda 인스턴스가 미리 워밍(warm) 되어 대기합니다. 런타임과 “많은 라이브러리”가 이미 로드된 상태이므로, 요청이 들어와도 콜드 스타트가 거의 발생하지 않아 첫 바이트까지의 지연이 줄어듭니다.
대기 시간 감소: 콜드 스타트가 제거되면 라이브러리 로딩·초기화 시간이 사라져, 모든 사용자에 대해 응답 대기 시간이 낮아집니다.
운영 변경 최소화: 기존 구조(API Gateway → Lambda → RDS)는 그대로 두고, Lambda 설정만 프로비저닝된 동시성으로 바꾸면 됩니다. 아키텍처 변경이나 프론트엔드·DB 직접 연결 같은 큰 변경이 없어 “운영 변경 최소화”에 맞습니다.

Answer: D

요구사항
EC2 인스턴스와 RDS DB 인스턴스 사용 중
업무 시간 외에 EC2·DB를 자동으로 시작·중지
비용과 인프라 유지 관리를 최소화

D. Lambda로 EC2·RDS 시작/중지 + EventBridge로 예약 실행
EC2와 RDS를 시작·중지하는 Lambda 함수를 만들고, Amazon EventBridge의 스케줄 규칙(cron/rate) 으로 업무 시작/종료 시각에 맞춰 해당 Lambda를 호출하는 구성입니다.

자동 시작·중지: Lambda에서 AWS SD 로 StartInstances/StopInstances(EC2), StartDBInstance/StopDBInstance(RDS, 지원 엔진)를 호출하면 됩니다. EventBridge로 “매일 09:00에 시작”, “매일 18:00에 중지”처럼 예약할 수 있어 업무 시간 외 자동 제어가 가능합니다.

비용 최소화: Lambda·EventBridge는 호출 시에만 과금되고, 스케줄러용 EC2를 24/7 돌릴 필요가 없어 비용이 적습니다.
유지 관리 최소화: 별도 EC2, cron 서버, OS 패치가 필요 없고, Lambda 코드와 EventBridge 규칙만 관리하면 되어 인프라 유지 관리가 최소입니다.

Answer: B

요구사항
3계층 웹 앱 + PostgreSQL DB(문서 메타데이터 저장), 문서 본문은 S3
매달 보고: 핵심 용어로 메타데이터 검색 → 회사가 검토하는 문서 찾기
보고 프로세스는 관계형 쿼리 사용, 몇 시간 소요
보고 프로세스가 문서 수정·신규 추가를 방해하면 안 됨
보고 속도를 높이되, 애플리케이션 코드 변경은 최소화

B. Aurora PostgreSQL + Aurora 복제본으로 보고 전용 쿼리
Amazon Aurora PostgreSQL 클러스터를 만들고 Aurora 복제본(읽기 전용) 을 추가한 뒤, 보고서 생성 쿼리만 Aurora 복제본으로 보내는 구성입니다.
보고 속도·영향 분리: 무거운 보고 쿼리를 주 인스턴스가 아니라 복제본에서 실행하면, 주 인스턴스는 문서 메타데이터 쓰기(수정·신규 추가)와 일반 앱 읽기만 담당합니다. 보고 부하가 주 인스턴스를 덜어 주고, 보고와 OLTP가 분리되어 보고가 문서 수정·추가를 방해하지 않습니다.
엔진 유지: Aurora PostgreSQL은 PostgreSQL 호환이므로 기존 관계형 쿼리·스키마를 그대로 사용할 수 있고, 애플리케이션 코드 변경은 최소로 둘 수 있습니다. 보고 모듈만 복제본 엔드포인트로 연결하도록 바꾸면 됩니다.
복제본 활용: Aurora는 읽기 전용 복제본을 여러 개 둘 수 있고, 복제본에만 보고 쿼리를 보내면 됩니다.

Answer: A

요구사항
3계층: 사용자 장치(센서) → NLB → 웹 계층 EC2 → 애플리케이션 계층 EC2 → DB
목표: 전송 중인 데이터(data in transit) 의 보안을 개선
즉, 전송 구간 암호화(TLS) 가 필요합니다.

A. NLB에 TLS 수신기 구성 + 서버 인증서 배포
NLB에 TLS 수신기(TLS listener) 를 두고, 서버 인증서(ACM 또는 IAM)를 NLB에 연결하는 구성입니다.
전송 중 데이터 보안: TLS 수신기를 쓰면 클라이언트 ↔ NLB 구간 트래픽이 TLS로 암호화됩니다. “전송 중인 데이터의 보안”을 직접적으로 개선하는 방법입니다.
NLB와의 관계: NLB는 Layer 4 로드밸런서이지만 TLS 종료(TLS termination) 를 지원합니다. TLS 수신기 + ACM/서버 인증서만 설정하면 되고, 기존 NLB 구조를 유지할 수 있습니다.

TLS 수신기(TLS Listener) 는 로드밸런서(NLB, ALB 등)에서 TLS(SSL)로 암호화된 트래픽을 받는 포트/설정을 말합니다.

TLS 수신기가 하는 일
클라이언트 → 로드밸런서 구간에서 TLS(HTTPS 등)로 암호화된 연결을 받습니다.
지정한 포트(예: 443)로 들어오는 트래픽에 대해 서버 인증서로 TLS 핸드셰이크를 하고, 복호화한 뒤 백엔드(EC2 등)로 전달합니다.

NLB에서의 TLS 수신기
NLB에는 수신기(Listener) 를 여러 개 둘 수 있습니다.
프로토콜을 TLS로 두고, 포트(보통 443)와 서버 인증서(ACM 등)를 지정하면, 그게 TLS 수신기입니다.
클라이언트는 NLB의 해당 포트로 TLS(암호화) 로 연결하고, NLB가 그 트래픽을 받아서 백엔드로 넘깁니다.

Answer: A

요구사항
상용 기성(COTS) 앱을 온프레미스 → AWS로 마이그레이션
소켓·코어 기반 소프트웨어 라이선스 모델
용량·가동 시간이 예측 가능
이미 구매한 기존 라이선스를 그대로 사용(BYOL)

A. 전용 예약 호스트(Dedicated Reserved Hosts)
전용 호스트(Dedicated Host) 는 물리 서버 한 대 전체를 고객 전용으로 쓰는 옵션입니다. 그 호스트의 소켓 수·코어 수를 알 수 있어서, “소켓·코어 단위”로 과금하는 라이선스 조건을 맞추기 좋습니다. 예약(Reserved) 으로 1년/3년 약정을 걸면 온디맨드보다 할인이 크고, 용량·가동 시간이 예측 가능할 때 가장 비용 효율적입니다.

라이선스: 소켓·코어 기반 라이선스는 보통 “특정 물리 서버(소켓/코어)” 기준이라, 전용 호스트를 쓰면 해당 호스트의 소켓/코어에 맞춰 라이선스를 적용할 수 있습니다. 전용 인스턴스만 쓰면 물리 호스트·소켓/코어를 직접 보장·확인하기 어렵고, 라이선스 조건에 맞지 않을 수 있습니다.

비용: 예측 가능한 워크로드이므로 예약(Reserved) 이 온디맨드보다 저렴합니다. 그래서 “가장 비용 효율적인 EC2 요금 옵션”은 전용 호스트 + 예약 = A. 전용 예약 호스트가 됩니다.

전용 호스트(Dedicated Host)
물리 서버 한 대 전체가 사용자 전용입니다.
그 호스트의 소켓 수, 코어 수, vCPU 수를 AWS 콘솔/API로 정확히 확인할 수 있습니다.
인스턴스는 그 호스트 위에만 배치되므로, “어떤 물리 서버 몇 소켓·몇 코어에서 돌아가는지”를 라이선스 조건에 맞춰 제어할 수 있습니다.
전용 인스턴스(Dedicated Instance)
인스턴스가 다른 고객과 공유하지 않는 전용 하드웨어에서만 실행됩니다.
하지만 어떤 물리 호스트인지, 소켓·코어 구성은 노출되지 않습니다.
“이 인스턴스는 전용 하드웨어에서만 실행된다”는 보장만 있고, “이 호스트는 소켓 2개, 코어 24개다”처럼 물리 구성을 세게 제어·확인하는 용도로는 쓰기 어렵습니다.

Answer: C

요구사항
여러 가용 영역에 걸친 EC2 Linux 인스턴스에서 애플리케이션 실행
고가용성 + POSIX 호환 스토리지
최대 데이터 내구성
EC2 인스턴스 간 공유 가능
처음 30일: 자주 접근 → 30일 이후: 드물게 접근
가장 비용 효율적인 구성

C. EFS Standard + 수명 주기로 EFS Standard-IA 이동
Amazon EFS(Elastic File System) 는 NFS 기반이라 POSIX 호환 파일 시스템입니다. 여러 EC2에서 동일한 파일 시스템을 마운트해 공유할 수 있고, 여러 AZ에 걸쳐 사용할 수 있습니다.
EFS Standard: 다중 AZ에 데이터가 저장되어 고가용성과 높은 내구성을 만족합니다.
수명 주기 관리(Lifecycle Management): 일정 기간(예: 30일) 동안 접근이 없으면 파일을 EFS Standard-IA(Infrequent Access) 로 자동 이동할 수 있습니다. “처음 30일은 자주, 이후는 드물게” 접근 패턴에 맞추면 비용을 줄일 수 있어 비용 효율적입니다.
공유: 여러 AZ의 EC2 인스턴스가 동일한 EFS를 마운트해 공유 스토리지로 사용할 수 있습니다.

A, B. S3 는 객체 스토리지이며 POSIX 호환 파일 시스템이 아닙니다. EC2에서 일반 디렉터리처럼 마운트해 POSIX API로 읽고 쓰는 용도로는 적합하지 않고, S3FS 등은 제약이 많습니다. “POSIX 호환 스토리지” 요구를 충족하지 못합니다.

Answer: C

요구사항
퍼블릭 서브넷: 로드 밸런서(이미 SG에서 0.0.0.0/0 포트 443 허용)
프라이빗 서브넷: 웹 서버(HTTPS만 사용), MySQL
정책: 최소 권한 — 각 리소스는 필요한 최소한의 액세스만 허용

C. 웹 서버 SG는 로드 밸런서에서만 443, MySQL SG는 웹 서버 SG에서만 3306
웹 서버용 보안 그룹: 로드 밸런서 보안 그룹에서만 포트 443 허용
트래픽 경로는 사용자 → 로드 밸런서 → 웹 서버이므로, 웹 서버는 로드 밸런서에서 오는 443만 받으면 됨.
0.0.0.0/0 포트 443을 허용하면 불필요하게 넓어져 최소 권한에 어긋남.
보안 그룹은 다른 보안 그룹을 참조할 수 있으므로, “로드 밸런서 SG → 웹 서버 443”으로 제한하는 것이 맞음.
MySQL 서버용 보안 그룹: 웹 서버 보안 그룹에서만 포트 3306 허용
MySQL은 웹 서버만 접속하면 되므로, 웹 서버 SG에서만 3306 허용하면 최소 권한 충족.
보안 그룹으로 “웹 서버 SG → MySQL 3306”만 허용하는 것이 정확함.

Answer: B

요구사항
다중 계층: 프론트엔드·백엔드(EC2), DB(RDS for MySQL)
문제: 동일한 데이터 세트를 반환하라는 호출이 자주 발생 → DB 부하·성능 저하
목표: 백엔드 성능 개선

B. Amazon ElastiCache로 대용량 데이터 세트 캐싱
Amazon ElastiCache(Redis 또는 Memcached)를 두고, 자주 요청되는 데이터 세트(쿼리 결과) 를 메모리 캐시에 저장하는 방식입니다.
동작: 백엔드에서 같은 데이터 요청이 오면 먼저 캐시를 확인합니다. 캐시에 있으면(캐시 히트) RDS에 가지 않고 캐시에서 바로 반환하고, 없으면(캐시 미스) RDS에서 조회한 뒤 그 결과를 캐시에 넣어 둡니다.
효과: “동일한 데이터 세트를 반환하라는 호출이 자주” 오는 경우, 반복 호출이 RDS를 반복해서 치지 않고 캐시에서 처리되므로 DB 부하 감소와 백엔드 응답 시간 단축으로 성능이 개선됩니다.

Answer: D, E

요구사항
배포 엔지니어가 CloudFormation 템플릿으로 여러 AWS 리소스 생성
최소 권한 원칙에 따라 작업하도록 해야 함

D. 배포 엔지니어용 IAM 사용자 생성 후, CloudFormation 작업만 허용하는 IAM 정책이 붙은 그룹에 추가
CloudFormation 스택 생성·업데이트·삭제·조회 등 CloudFormation에 필요한 작업만 허용하는 정책을 만들어, 그 정책이 연결된 그룹에 배포 엔지니어 IAM 사용자를 넣는 방식입니다. 다른 서비스(EC2, S3 등)에 대한 직접 권한은 주지 않으므로 최소 권한을 만족합니다.

E. 배포 엔지니어가 사용할 IAM 역할 생성 후, CloudFormation 스택 및 AWS 관련 작업에 필요한 권한만 명시적으로 정의
CloudFormation을 실행할 IAM 역할을 만들고, 그 역할에 CloudFormation 스택 작업(CreateStack, UpdateStack, DeleteStack, DescribeStacks 등)과 스택 실행에 필요한 최소한의 AWS 권한(예: iam:PassRole 등)만 명시적으로 부여하는 방식입니다. “필요한 것만 구체적으로 정의”하므로 최소 권한에 맞습니다.
D는 사용자 + 그룹 + CloudFormation 전용 정책, E는 역할 + CloudFormation·관련 작업만 명시한 정책으로, 둘 다 최소 권한 원칙을 적용하는 올바른 조합입니다.

Answer: D

요구사항
2계층: 웹 계층(EC2 Auto Scaling, 퍼블릭 서브넷, 다중 AZ), DB 계층(RDS MySQL, 프라이빗 서브넷)
웹 계층이 제품 정보 조회를 위해 DB 접근 필요
문제: 웹 앱에서 DB에 연결할 수 없음. DB는 정상 가동 중.
NACL, 보안 그룹, 라우팅 테이블은 모두 기본값 상태

D. RDS 보안 그룹에 웹 계층 보안 그룹에서 오는 인바운드 허용
데이터베이스 계층(RDS) 보안 그룹에 인바운드 규칙을 추가해, 웹 계층 EC2가 사용하는 보안 그룹에서 MySQL 포트(3306) 로 들어오는 트래픽을 허용하는 구성입니다.

원인: RDS가 “가동 중”인데 연결이 안 되는 경우, 같은 VPC 안에서는 대부분 RDS 보안 그룹이 웹 서버에서 오는 3306 트래픽을 허용하지 않아서입니다. 기본 보안 그룹만 쓰면 다른 보안 그룹에서 오는 트래픽이 막혀 “DB 연결 불가”가 됩니다.

조치: RDS 인스턴스에 붙은 보안 그룹에
프로토콜/포트: TCP 3306
소스: 웹 계층 EC2의 보안 그룹
을 인바운드로 추가하면, 웹 앱이 의도한 대로 DB에 연결할 수 있습니다.

Answer: A

요구사항
단일 가용 영역 RDS for MySQL에 대규모 데이터 세트
프로덕션 DB의 쓰기 작업에는 영향 없이 비즈니스 보고 쿼리만 실행하고 싶음

A. RDS 읽기 복제본으로 보고 쿼리 처리
RDS 읽기 복제본(Read Replica) 을 하나 두고, 비즈니스 보고 쿼리는 복제본에서만 실행하는 구성입니다.
쓰기와 분리: 프로덕션 DB(주 인스턴스)는 쓰기와 필요한 읽기만 담당하고, 보고 쿼리는 읽기 전용 복제본에서 실행합니다. 복제본이 보고 부하를 받아도 주 인스턴스의 쓰기 성능에는 영향을 주지 않습니다.
동작: 복제본은 주 인스턴스에서 비동기 복제로 데이터를 받습니다. 보고는 복제본에서만 돌리므로, CPU·메모리·I/O 경합이 주 인스턴스 쓰기와 분리됩니다.

Answer: A, D

요구사항
3계층 전자상거래: EC2(Auto Scaling) + ALB, RDS for MariaDB(다중 AZ)
트랜잭션 중 고객 세션 관리를 최적화
세션 데이터를 지속적으로 저장해야 함

A. ALB에서 고정 세션(세션 선호도) 활성화
ALB 고정 세션(Sticky Session / Session Affinity) 을 켜면, 같은 클라이언트 요청이 같은 EC2 인스턴스로 갑니다. 트랜잭션 동안 한 클라이언트가 한 인스턴스에 묶이므로, 세션을 그 인스턴스에서만 다루거나 Redis 접근을 줄이는 식으로 세션 관리가 단순해지고 최적화됩니다.

D. Amazon ElastiCache for Redis 클러스터로 고객 세션 정보 저장
Redis는 인메모리 키-값 저장소로, 세션 데이터 저장에 많이 쓰입니다. 여러 EC2 인스턴스가 같은 Redis에 세션을 읽고 써서 공유 세션 저장소가 되고, Redis의 RDB/AOF 등으로 디스크에 지속 저장할 수 있어 “세션 데이터를 지속적으로 저장” 요구를 충족합니다. 지연 시간이 짧아 트랜잭션 중 세션 접근에 유리합니다.
조합: A로 “같은 클라이언트 → 같은 인스턴스”를 유지하고, D로 “세션은 Redis에 영구·공유 저장”을 하면, 트랜잭션 중 세션 관리가 최적화되고 세션 데이터는 지속적으로 저장됩니다.

B. DynamoDB로도 세션을 저장할 수는 있지만, 시험 정답은 A, D입니다. 세션처럼 짧은 지연이 중요한 경우에는 ElastiCache for Redis가 더 일반적이고, “트랜잭션 중 세션 관리 최적화”에는 Redis가 더 적합합니다.
C. Cognito User Pools는 인증(가입, 로그인, JWT) 용입니다. 전자상거래의 세션(장바구니, 체크아웃 상태 등) 은 애플리케이션 세션 저장소(Redis, DynamoDB 등)로 다루는 영역이므로 C는 부적절합니다.
E. Systems Manager Application Manager는 운영·관리(인벤토리, 문제 해결 등)용이며, 애플리케이션 세션 데이터 저장용이 아니므로 E는 틀립니다

Answer: C

요구사항
3계층 상태 비저장(stateless) 웹 애플리케이션
웹/앱 계층: EC2 + Auto Scaling(동적 조정 정책)
DB 계층: RDS for PostgreSQL
EC2에는 임시 로컬 스토리지가 필요 없음(상태 없음)
RPO = 2시간
백업 전략: 확장성 극대화 + 리소스 활용 최적화

C. 웹/앱 계층은 최신 AMI 유지 + RDS 자동 백업·지정 시간 복구
웹·애플리케이션 계층: 최신 AMI(Amazon Machine Image) 를 유지합니다. 상태 비저장이므로 EC2 디스크를 주기적으로 스냅샷할 필요가 없고, AMI 하나(골든 이미지) 로 배포·복구·Auto Scaling에 사용합니다. 필요 시 AMI만 주기적으로 갱신하면 됩니다. 인스턴스 수가 늘어나도 AMI는 하나만 관리하므로 확장성이 좋고, 불필요한 EBS 스냅샷을 만들지 않아 리소스 활용이 최적화됩니다.
데이터베이스 계층: RDS 자동 백업을 켜고 지정 시간 복구(PITR) 를 사용합니다. 자동 백업과 트랜잭션 로그로 보존 기간 내 어느 시점으로든 복구할 수 있어, RPO 2시간을 충족합니다.

A. EC2 인스턴스와 “데이터베이스 EBS 볼륨”을 2시간마다 스냅샷한다는 구성입니다. RDS는 EBS 볼륨을 직접 스냅샷하는 방식이 아니라 RDS 자동 백업·수동 DB 스냅샷을 사용합니다. 상태 비저장 EC2를 2시간마다 스냅샷하는 것은 인스턴스가 많을수록 확장성·비용 측면에서 비효율적이고, “리소스 활용 최적화”에도 맞지 않습니다.
B. EBS 스냅샷 수명 주기 정책으로 EC2 EBS를 백업하는 방식입니다. 상태 비저장 웹/앱 계층에서는 EC2 디스크에 중요한 상태가 없어, 주기적 EBS 스냅샷은 불필요한 스토리지·비용이 들고 최적화되지 않습니다. 웹/앱 계층은 AMI 유지가 적절합니다.
D. EC2 EBS를 2시간마다 스냅샷하는 부분이 문제입니다. 상태 비저장이므로 모든 인스턴스의 EBS를 주기적으로 스냅샷하는 것은 확장성·비용 모두 불리하고, “확장성 극대화·리소스 활용 최적화” 요구를 충족하지 못합니다. RDS 쪽(자동 백업 + PITR)은 맞지만, EC2 전략 때문에 C보다 부적절합니다.

Answer: A

요구사항
퍼블릭 웹 애플리케이션: 웹 서버(EC2), DB(RDS for MySQL)
동적 IP를 쓰는 글로벌 고객이 안전하게 접근할 수 있어야 함
보안 그룹 구성 방법

A. 웹 서버는 0.0.0.0/0 포트 443, DB는 웹 서버 SG에서만 3306
웹 서버 보안 그룹: 0.0.0.0/0에서 포트 443(HTTPS) 인바운드 허용
고객이 동적 IP이고 글로벌이므로, 특정 IP 목록으로 제한할 수 없습니다.
퍼블릭 웹 앱이므로 누구나 HTTPS(443) 로 접근할 수 있어야 하고, 0.0.0.0/0 포트 443만 열면 됩니다.
443만 열고 3306 등은 열지 않으므로 웹 계층은 접근 범위가 제한됩니다.
DB 인스턴스 보안 그룹: 웹 서버 보안 그룹에서만 포트 3306 인바운드 허용
DB는 웹 서버만 접속하면 되므로, 웹 서버가 붙은 보안 그룹에서 오는 3306만 허용합니다.
인터넷(0.0.0.0/0)이나 고객 IP에서 3306을 열지 않아 DB가 노출되지 않고, 최소 권한에 맞습니다.

B. 웹 서버 SG에서 “고객의 IP 주소”에서만 443을 허용하는 방식입니다. 고객이 동적 IP이면 IP가 자주 바뀌어 목록을 유지할 수 없고, 글로벌이라 IP 범위도 넓어 “고객 IP만 허용”하는 구성은 실현 가능하지 않습니다.
C. 웹 서버는 “고객 IP”만 허용(위와 같은 이유로 비현실적)이고, DB는 고객 IP에서 3306을 허용하는 구성입니다. DB를 인터넷의 고객 IP에 열어두는 것은 매우 위험하고, RDS는 보통 웹 서버(또는 앱 서버)에서만 접근하도록 해야 합니다.
D. 웹 서버는 0.0.0.0/0 포트 443으로 적절하지만, DB를 0.0.0.0/0 포트 3306으로 열면 전 세계 누구나 MySQL에 접속 시도를 할 수 있어 보안 요구사항을 위반합니다.

Answer: C

요구사항
음성 통화 녹음 → 오디오 파일을 Amazon S3에 저장
오디오에서 텍스트 추출(음성 → 텍스트)
텍스트에서 고객 PII(개인 식별 정보) 제거
위 요구를 만족하는 솔루션 설계

C. Amazon Transcribe(PII 수정) + Lambda(S3 업로드 시 전사 작업 시작) + 출력 S3
Amazon Transcribe로 전사(transcription) 작업을 구성하고, PII 수정(redaction) 을 켭니다. 오디오가 S3에 업로드되면 Lambda가 트리거되어 Transcribe 전사 작업을 시작하고, 전사 결과(텍스트)는 별도 S3 버킷에 저장하는 구성입니다.
오디오 → 텍스트: Amazon Transcribe는 음성-텍스트 변환(speech-to-text) 서비스라, S3 오디오 파일에서 텍스트를 추출하는 데 적합합니다. Textract는 문서(이미지/PDF) OCR용이므로 오디오에는 사용하지 않습니다.

PII 제거: Transcribe의 PII 수정(PII redaction) 기능을 사용하면, 전사된 텍스트에서 이름, SSN, 날짜 등 PII를 자동으로 탐지·마스킹(제거) 할 수 있어 “텍스트에서 고객 PII 제거” 요구를 충족합니다.

자동화: S3에 오디오가 업로드되면 Lambda가 실행되어 해당 파일을 입력으로 Transcribe 전사 작업을 시작하고, 출력을 별도 S3 버킷에 저장하면 원본 오디오와 PII가 제거된 텍스트를 분리해 관리할 수 있습니다.

Answer: D

요구사항
다중 계층 전자상거래: EC2 + RDS for MySQL(다중 AZ)
RDS: 최신 세대, 2,000GB 스토리지, gp3(범용 SSD) EBS
문제: 수요가 많을 때 DB 성능이 앱에 영향. CloudWatch 로그 분석 결과 읽기·쓰기 IOPS가 20,000을 넘으면 항상 성능 저하
목표: 애플리케이션 성능 개선

D. 2,000GB gp3 1개 → 1,000GB gp3 2개로 교체
2,000GB gp3 볼륨 1개를 1,000GB gp3 볼륨 2개로 바꾸는 구성입니다.
gp3 IOPS 한도: gp3는 볼륨당 최대 16,000 IOPS까지 프로비저닝할 수 있습니다. 볼륨이 2,000GB여도 단일 볼륨 기준으로는 16,000 IOPS가 상한입니다.
20,000 IOPS 초과 시: 로그에서 IOPS가 20,000을 넘을 때 성능이 떨어진다면, 단일 gp3 한도(16,000) 를 넘어서는 구간이 있다는 뜻입니다. 한 개 볼륨만으로는 20,000 IOPS를 안정적으로 감당하기 어렵습니다.
2개 볼륨으로 나누면: 1,000GB gp3를 2개 쓰면, 각 볼륨이 각각 최대 16,000 IOPS까지 가능하므로 총 IOPS 용량은 최대 32,000 IOPS 수준이 됩니다. 스토리지 총량(2,000GB)은 유지하면서 집계 IOPS 한도를 늘려, 20,000을 넘는 부하에도 성능 저하를 줄일 수 있습니다.

A. 마그네틱 볼륨은 IOPS가 매우 낮아(수십~수백 수준) 현재처럼 높은 IOPS가 필요한 워크로드에는 성능이 크게 나빠집니다. 부적절합니다.
B. gp3에서 IOPS를 늘리는 것만으로는 볼륨당 상한이 16,000 IOPS라, 20,000을 넘는 구간은 한 개 볼륨으로는 해결할 수 없습니다. “IOPS 수를 늘린다”고 해도 단일 gp3 한도를 넘을 수 없어 요구사항을 충족하지 못합니다.
C. io2(프로비저닝된 IOPS SSD) 로 바꾸면 볼륨당 64,000 IOPS 등 더 높은 IOPS를 낼 수 있어 기술적으로는 가능합니다. 하지만 정답이 D인 경우, 시험에서는 “동일 gp3를 유지하면서 볼륨 수를 늘려 집계 IOPS 용량을 키우는 것(D)”을 더 적절한 해법으로 보는 것으로 보입니다. (비용·구성 복잡도 등에서 D를 선호하는 관점일 수 있습니다.)

Answer: C

상황
지난주 프로덕션 배포 중 IAM 사용자가 AWS 리소스 구성을 변경함
보안 그룹 규칙 일부가 원하는 대로 설정되지 않음
어떤 IAM 사용자가 그 변경을 했는지 확인해야 함

C. AWS CloudTrail
AWS CloudTrail은 계정의 API 호출 이력을 기록하는 서비스입니다.
각 이벤트에 누가(principal/identity), 언제, 어떤 API를 호출했는지가 포함됩니다.

보안 그룹 변경 추적
보안 그룹 규칙 변경은 AuthorizeSecurityGroupIngress, RevokeSecurityGroupIngress, ModifySecurityGroupRules 등 API로 수행됩니다.
CloudTrail 이벤트에서 해당 API 호출을 찾으면, userIdentity 필드에 IAM 사용자(또는 역할) 가 기록되어 있어, “어떤 IAM 사용자가 변경했는지”를 확인할 수 있습니다.
정리: “누가 이 변경을 했는가?”를 알려면 API 호출 주체(identity)를 남기는 CloudTrail을 사용해야 합니다.

Answer: A

요구사항
자체 관리형 DNS 솔루션: 다른 리전의 EC2 + AWS Global Accelerator 표준 가속기 엔드포인트
DDoS 공격으로부터 보호 필요
솔루션 설계자가 해야 할 조치

A. AWS Shield Advanced 가입 후 가속기를 보호 리소스로 추가
AWS Shield Advanced에 가입한 뒤, 보호할 리소스로 Global Accelerator 가속기를 추가하는 구성입니다.
DDoS 방어: Shield Advanced는 L3/L4 DDoS 방어와 고급 보호·DRT 지원을 제공합니다. “DDoS 공격으로부터 보호” 요구를 충족하는 서비스입니다.
가속기를 보호 리소스로: Shield Advanced는 Global Accelerator 가속기를 보호 리소스로 지정할 수 있습니다. 트래픽이 클라이언트 → 가속기 → EC2로 들어오므로, 가속기를 보호하면 그 뒤의 EC2까지 포함한 솔루션 전체가 DDoS 보호 대상이 됩니다.
리소스 타입: Shield Advanced가 보호할 수 있는 리소스에는 Elastic IP, CloudFront, Global Accelerator, Route 53, ELB 등이 포함되고, 가속기를 추가하는 것이 올바른 사용법입니다.

Answer: C

요구사항
예약된 일일 작업: 판매 기록 집계·필터링(분석용)
판매 기록: Amazon S3에 저장, 객체당 최대 10GB
작업 소요 시간: 판매 이벤트 수에 따라 최대 1시간
CPU·메모리: 일정하고 미리 알려짐
목표: 작업 실행에 필요한 운영 노력 최소화

C. ECS Fargate + EventBridge 예약으로 일일 작업 실행
Amazon ECS 클러스터를 AWS Fargate 시작 유형으로 만들고, 일일 작업을 ECS 태스크로 정의한 뒤 Amazon EventBridge 예약 규칙으로 매일 해당 태스크를 실행하는 구성입니다.
1시간·대용량 처리: Lambda는 최대 실행 시간 15분이고 페이로드·메모리 제한으로 10GB 객체를 한 번에 다루기 어렵습니다. ECS 태스크는 실행 시간 제한이 없고, S3에서 대용량 객체를 읽어 처리할 수 있어 “최대 1시간”, “객체 최대 10GB” 요구를 충족합니다.
CPU·메모리: CPU·메모리가 일정하고 알려져 있으므로, Fargate 태스크 정의에서 필요한 CPU·메모리를 지정해 두면 됩니다.
운영 노력 최소화: Fargate는 서버(EC2)를 관리할 필요가 없고, 컨테이너 태스크만 정의하고 EventBridge로 매일 한 번 실행하면 됩니다. EC2 기반 ECS(D)보다 운영 부담이 적습니다.

A. Lambda는 실행 시간 최대 15분이라 “최대 1시간” 걸리는 작업을 실행할 수 없고, 10GB 크기 객체를 Lambda 단일 호출로 처리하는 것도 제한이 있어 요구사항을 만족하지 못합니다.
B. Lambda + API Gateway + EventBridge로 호출하는 구성도, Lambda 15분 제한과 대용량 객체 처리 제한은 그대로라 A와 같은 이유로 부적절합니다.
D. ECS EC2 시작 유형 + Auto Scaling 그룹은 작업 자체는 실행할 수 있지만, EC2 인스턴스·ASG·패치 등을 직접 관리해야 해 운영 노력이 큽니다. “운영 노력 최소화”에는 Fargate(C) 가 더 적합합니다.

Answer: C

요구사항
온프레미스 NAS → AWS로 600TB 이전
2주 이내 완료
데이터 민감 → 전송 중 암호화 필요
회사 인터넷 업로드: 100Mbps

시간·대역폭 계산
600TB ≈ 4,800,000 Gb(비트)
100Mbps로 전송 시: 4,800,000 ÷ 100 ÷ 3,600 ÷ 24 ≈ 555일 수준
2주(14일) 안에는 인터넷(100Mbps)으로 600TB 전송 불가
그래서 인터넷/VPN 기반 전송(A, B) 은 2주 조건을 만족할 수 없고, 오프라인 대량 이전(예: Snowball) 이 필요합니다.

C. AWS Snowball Edge Storage Optimized 다수 주문 후 S3로 전송
AWS Snow Family 콘솔에서 Snowball Edge Storage Optimized 디바이스를 여러 대 주문한 뒤, 온프레미스 NAS에서 디바이스로 데이터를 넣고, 디바이스를 AWS로 반송해 Amazon S3에 적재하는 방식입니다.

2주 충족: 디바이스를 현장으로 보내고, NAS와 로컬 네트워크로 데이터를 넣은 뒤 물리적으로 반송합니다. 100Mbps 인터넷에 의존하지 않으므로, 디바이스 수와 현장 작업만 맞추면 2주 내 완료가 가능합니다.

암호화: Snowball은 전송 중·저장 시 암호화를 지원합니다. 민감 데이터 요구를 충족합니다.

비용 효율: 600TB를 인터넷으로 보내면 비용·시간 모두 부담이 큽니다. Snowball은 디바이스·이전 작업 단위 과금으로, 대량 일회성 이전에 더 비용 효율적입니다.

용량: Snowball Edge Storage Optimized는 디바이스당 약 80TB 수준이므로, 600TB는 여러 대를 사용하면 됩니다.

Answer: B

요구사항
금융 회사 웹 앱: API Gateway 지역 API로 현재 주가 검색 제공
API 요청 수 증가 확인, HTTP 플러드 공격으로 서비스 중단 우려
목표: 해당 공격으로부터 애플리케이션 보호
최소한의 운영 오버헤드

B. AWS WAF 웹 ACL(속도 기반 규칙) + API Gateway 스테이지 연결
리전 AWS WAF 웹 ACL을 만들고 속도 기반 규칙(Rate-based rule) 을 넣은 뒤, 그 웹 ACL을 API Gateway 스테이지에 연결하는 구성입니다.
HTTP 플러드 대응: WAF 속도 기반 규칙은 일정 시간(예: 5분) 동안 같은 IP(또는 집합) 에서 들어오는 요청 수가 임계값을 넘으면 해당 소스를 차단합니다. HTTP 플러드(같은/비슷한 IP에서 대량 요청)를 자동으로 제한해 애플리케이션을 보호할 수 있습니다.
API Gateway 연동: API Gateway(REST API 스테이지)에 WAF 웹 ACL을 연결할 수 있어, “주가 검색 API” 앞단에서 속도 기반 차단을 적용할 수 있습니다.
최소 운영: WAF 속도 기반 규칙은 관리형 기능이라, 규칙만 설정하고 웹 ACL을 API Gateway에 붙이면 됩니다. 코드 작성·Lambda@Edge 유지보수가 필요 없어 운영 부담이 적습니다

----
A. CloudFront + 24시간 TTL은 캐싱으로 API로 가는 요청 수를 줄이는 효과는 있지만, HTTP 플러드 자체를 차단하는 기능은 없습니다. 캐시가 안 되는 요청(실시간 주가 등)에는 효과가 제한적이고, “플러드 공격으로부터 보호”라는 요구를 직접적으로 충족하지 못합니다.
C. CloudWatch 지표·알람은 모니터링·알림용입니다. 속도가 넘어가면 보안 팀에게 알리기만 하고, 요청을 막지는 않습니다. 공격 트래픽은 그대로 들어오므로 “보호” 요구를 만족하지 못합니다.
D. Lambda@Edge로 “정의한 속도를 넘는 IP 차단”을 구현할 수는 있지만, 직접 코드 작성·배포·유지보수가 필요해 운영 오버헤드가 큽니다. “최소한의 운영 오버헤드”에는 WAF 속도 기반 규칙(B) 이 더 적합합니다.

Answer: C

요구사항
맞춤형 웹 앱: DynamoDB에 날씨 데이터 저장
새 서비스: 새 날씨 이벤트가 기록될 때마다 4명의 내부 팀 관리자에게 경고
기존 애플리케이션 성능에 영향 없어야 함
최소한의 운영 오버헤드

C. DynamoDB 스트림 + 트리거(Lambda) → 단일 SNS 주제 → 팀 구독
DynamoDB 스트림을 테이블에 활성화하고, 스트림을 트리거(예: Lambda)로 연결한 뒤, 그 트리거가 단일 Amazon SNS 주제에 메시지를 보내고, 4명의 팀 관리자가 그 주제를 구독(이메일, SQS 등)하는 구성입니다.
기존 앱 성능에 영향 없음: 애플리케이션은 DynamoDB에만 쓰기하고, 스트림 처리는 비동기로 이어집니다. 쓰기 경로에 SNS 발행이나 알림 로직을 넣지 않으므로 지연·부하가 추가되지 않습니다.

새 이벤트 시 알림: DynamoDB 스트림은 항목 추가·변경 시 레코드를 내보냅니다. Lambda가 이 레코드를 받아 새 날씨 이벤트를 감지하고, 한 개의 SNS 주제에 메시지를 게시하면, 그 주제를 구독하는 4명의 팀 관리자가 모두 알림을 받을 수 있습니다.

최소 운영: DynamoDB 스트림, Lambda, SNS는 모두 관리형 서비스라, 스트림 활성화 + Lambda(트리거) + SNS 주제·구독만 구성하면 됩니다. 크론·스캔·플래그 관리가 필요 없어 운영 부담이 적습니다.

'자격증' 카테고리의 다른 글

AWS SAA-C03 Dump 451-500 (0)	2026.02.02
AWS SAA-C03 Dump 401-450 (0)	2026.02.02
AWS SAA-C03 Dump 301-350 (1)	2026.02.01
AWS SAA-C03 Dump 251-300 (0)	2026.01.30
AWS SAA-C03 Dump 201-250 (0)	2026.01.30

티스토리툴바