AWS SAA-C03 Dump 201-250

AWS SAA-C03  Dump 201-250

Answer: B

요구사항 
- 모바일 앱 사용자 대상 마케팅·커뮤니케이션 서비스
- SMS로 확인(검증) 메시지 발송
- 사용자가 SMS에 회신 가능 (양방향 SMS)
- 응답을 1년간 저장해 분석

B. Amazon Pinpoint 여정 구성 + 이벤트를 Kinesis 데이터 스트림으로 전송(분석·보관)
Amazon Pinpoint는 마케팅·알림용 메시징(이메일, SMS, 푸시 등) 서비스이며, 지원 리전에서 양방향 SMS를 지원합니다.
     발송: 검증/마케팅용 SMS 발송 가능.
     수신: 사용자가 보낸 SMS 회신(인바운드) 수신·처리 가능 → “사용자가 SMS에 회신할 수 있어야 한다” 충족.
이벤트를 Kinesis 데이터 스트림으로 전송:
    Pinpoint를 Kinesis Data Streams(또는 Firehose)로 이벤트 전송하도록 구성하면, 발송·수신·전달 등 이벤트가 스트림으로 들어갑니다.
    Kinesis(Firehose)에서 S3 등에 저장하고, 수명 주기로 1년 보관해 분석·보관에 사용할 수 있습니다.
“SMS 발송 + 회신 수신 + 응답 1년 보관·분석”을 한 서비스(Pinpoint) + 이벤트 스트리밍(Kinesis)으로 만족합니다.

Amazon SNS VS Amazon Pinpoint
SNS : 알림·이벤트 전달 (Pub/Sub, 1:1 알림) , “이 이벤트를 구독자/엔드포인트로 보낸다” , 주로 시스템/앱이 트리거 (예: 주문 완료 알림, 에러 알림, 푸시)

 

Pinpoint : 마케팅·참여·캠페인 (대상자 분석 + 메시지), “누가, 언제, 어떤 채널로 반응했는지”까지 다룸, 마케팅·온보딩·재참여 (이메일/SMS/푸시 캠페인, 세그먼트, 여정, 분석).

이메일
    SNS: 이메일 발송만 (토픽 구독자에게 푸시). 템플릿·캠페인·오픈/클릭 분석은 없음.
    Pinpoint: 이메일 발송 + 템플릿, 캠페인, 오픈/클릭/바운스 등 상세 분석, A/B 테스트 등.
SMS
    SNS: SMS 발송만 (한 방향). 인바운드(사용자 회신) 수신 불가.
    Pinpoint: SMS 발송 + 인바운드 수신 (지원 리전에서 양방향 SMS). 회신을 받아서 저장·분석 가능.
푸시
    SNS: 모바일 푸시 발송 (FCM, APNs 등으로 전달).
    Pinpoint: 푸시 발송 + 앱/캠페인 단위 분석, 세그먼트·여정에 활용.

 

Answer: B

요구사항 
- 데이터를 S3 버킷으로 이동
- S3에 저장될 때 암호화 필수
- 암호화 키는 매년 자동 순환
- 최소 운영 오버헤드

B. KMS 고객 관리형 키 생성 + 자동 키 순환 활성화 + S3 버킷 기본 암호화에 해당 키 사용 후 데이터 이동
KMS 고객 관리형 키(CMK)에서 자동 키 순환을 켜면, KMS가 365일(1년)마다 키 자료를 자동으로 순환합니다.
S3 버킷 기본 암호화를 이 고객 관리형 KMS 키로 설정하면, 버킷에 올라가는 객체가 해당 키로 자동 암호화됩니다.
운영 부담: 키 생성·자동 순환 활성화·S3 기본 암호화 설정만 하면 되고, 매년 수동으로 키를 바꿀 필요가 없어 최소 오버헤드입니다.

D. 고객 키 자료로 사전 암호화 + KMS에 키 가져오기 + 자동 순환
가져온(imported) 키는 KMS 자동 키 순환을 지원하지 않습니다. “매년 자동 순환” 요구를 만족할 수 없고, 클라이언트 측 암호화는 구조가 복잡해져 오버헤드가 늘어납니다.

 

Answer: B

요구사항 
- 고객 문자 → 웹 앱(EC2)이 약속 수락 → SQS에 메시지 적재
- 다른 앱(EC2)이 SQS에서 메시지 소비 → 회의 초대·확인 이메일 발송 → DynamoDB에 저장
- 문제: 규모가 커지면서 회의 초대가 도착하기까지 시간이 더 걸림

D. 회의 초대를 보내는 애플리케이션에 Auto Scaling 그룹 추가 + SQS 큐 깊이에 따라 스케일링
- 지연 원인은 SQS에 쌓인 메시지를 처리하는 쪽(회의 초대 발송 앱) 용량 부족일 가능성이 큽니다.
요청은 많아지는데 처리 인스턴스 수가 고정이면 큐가 길어지고, 초대 발송까지 시간이 늘어납니다.

 

회의 초대를 보내는 애플리케이션을 Auto Scaling 그룹으로 두고, SQS 큐 깊이(대기 메시지 수)를 스케일링 메트릭으로 쓰면:
    큐가 길어질 때 → 인스턴스 증가 → 더 많은 워커가 큐를 소비 → 초대 발송 지연 감소
    큐가 비면 → 인스턴스 감소 → 비용·리소스 절감
“규모 커질수록 초대가 늦게 온다”는 증상을 처리 용량을 큐 부하에 맞춰 늘리는 것으로 해결하는 방식이라 요구사항에 맞습니다.

 

Answer: C

요구사항 
- 구매 데이터 → S3, 추가 고객 데이터 → RDS
- 여러 팀이 모든 데이터(S3 + RDS)를 활용해 분석할 수 있어야 함
- 세분화된 권한으로 데이터 접근 제어
- 운영 오버헤드 최소화

C. AWS Lake Formation으로 데이터 레이크 구성 + Glue JDBC로 RDS 연결 + S3 등록 + Lake Formation 액세스 제어
AWS Lake Formation은 데이터 레이크를 한곳에서 구성·관리하고, 세밀한 권한을 부여하는 서비스입니다.
    S3 버킷 등록: 이미 있는 구매 데이터(S3)를 레이크에 등록해 그대로 사용할 수 있습니다.
    Glue JDBC 연결로 RDS: RDS 데이터를 Glue 카탈로그/연결로 레이크에 연결해, S3와 RDS를 하나의 카탈로그에서 다룰 수 있습니다.
    Lake Formation 액세스 제어: 데이터베이스·테이블·컬럼 단위로 “누가 어떤 데이터를 볼 수 있는지”를 제어할 수 있어 세분화된 권한 요구를 충족합니다.

 

팀은 Athena 등으로 레이크를 쿼리하고, Lake Formation이 접근을 제어하므로 별도 복사·ETL·권한 스크립트를 최소화할 수 있어 운영 오버헤드를 줄일 수 있습니다.

 

[S3 구매 데이터] ──등록──► [Lake Formation] ──► [Glue 카탈로그] ──► [Athena 등으로 쿼리]
[RDS 고객 데이터] ─JDBC──► [Glue 연결]     ──► [같은 카탈로그]   ──► [같은 SQL로 조인 가능]
                                    │
                                    └── Lake Formation이 "누가 무엇을 볼 수 있는지" 제어

 

Answer: C

요구사항
- 정적 문서로 된 마케팅 웹사이트
- CloudFront 사용, 웹사이트 호스팅이 CloudFront 오리진이 되어야 함
- 가장 비용 효율적이고 탄력적인 아키텍처
(현재는 SFTP로 업로드하지만, 요구는 “비용·탄력성”이 우선)

 

C. 프라이빗 S3 버킷 + CloudFront OAI로만 접근 허용 + AWS CLI로 콘텐츠 업로드
1. Amazon S3에 정적 파일만 두고 CloudFront 오리진으로 쓰는 구성이 비용·탄력성 모두 가장 유리합니다.
    비용: EC2/Lightsail처럼 서버를 돌리지 않아 저렴하고, 스토리지·요청 단위 과금만 발생합니다.
    탄력성: S3는 관리형 서비스로 가용성·내구성이 높고, 트래픽 증가에 맞춰 자동으로 대응합니다.

 

2. 프라이빗 버킷 + CloudFront OAI(원본 액세스 ID)
    버킷 정책으로 CloudFront OAI에서 오는 요청만 허용하면, 인터넷에서 S3에 직접 접근할 수 없고 CloudFront를 통해서만 제공됩니다. 보안상 유리합니다.

 

3. 업로드: 관리자가 AWS CLI로 콘텐츠를 S3에 업로드하면 됩니다. SFTP 대신 CLI를 쓰는 변경이 있지만, “가장 비용 효율적이고 탄력적인” 아키텍처 요구에는 C가 가장 잘 맞습니다.

 

Answer: D

요구사항
- EC2 CreateImage API 호출이 회사 계정 내에서 일어날 때마다 알림 전송
- AWS API 호출 캡처 필요
- 최소한의 운영 오버헤드

C. CreateImage API 호출에 대한 EventBridge 규칙 생성 → 대상은 SNS 주제
1. Amazon EventBridge(구 CloudWatch Events)는 CloudTrail이 기록한 API 이벤트를 받을 수 있습니다.
    CloudTrail이 관리 이벤트를 EventBridge로 보내도록 설정되어 있으면, CreateImage 같은 EC2 API 호출이 이벤트로 들어옵니다.
2.  EventBridge 규칙에서:
    이벤트 패턴: source = aws.ec2, detail.eventName = CreateImage 등으로 CreateImage 호출만 선택
    대상(Target): Amazon SNS 주제 → 호출될 때마다 SNS로 알림 전송
Lambda·쿼리·추가 스토리지 없이 규칙 + SNS만으로 동작하므로 운영 오버헤드가 가장 적습니다.

 

Answer: D

요구사항 
- 비동기 API: 사용자 요청 수집 → 요청 유형별로 해당 마이크로서비스에 전달
- API Gateway + Lambda(요청 받아 DynamoDB에 저장 후 마이크로서비스로 전달)
- DynamoDB 처리량을 예산 한도까지 프로비저닝했지만 가용성 문제와 요청 유실 발생

D. Amazon SQS 큐 + Lambda로 DynamoDB 쓰기 버퍼링
- 요청 유실은 Lambda가 DynamoDB에 직접 쓰다가 쓰로틀/장애/타임아웃이 나면, 그 요청을 다시 시도할 곳이 없어서 발생할 수 있습니다.

 

SQS를 쓰기 버퍼로 두면:
    1. Lambda(진입): API 요청을 받으면 DynamoDB에 바로 쓰지 않고, SQS에 메시지로 넣고 곧바로 성공 응답 반환.
    2. Lambda(소비): SQS를 트리거로 두고, 메시지를 꺼낸 뒤 DynamoDB 쓰기 + 마이크로서비스 전달 수행. 성공 시에만 메시지 삭제.

 

DynamoDB가 쓰로틀/장애여도 메시지는 SQS에 남고, 가시성 타임아웃 후 재시도되므로 요청이 유실되지 않습니다. (가용성 문제 완화)
기존 사용자: API는 그대로 “요청 접수” 후 응답하고, 백엔드만 SQS 경유로 바꾸면 되므로 기존 사용자 경험을 유지할 수 있습니다.

 

Answer: B

요구사항
- EC2 → S3로 데이터 이동
- API 호출·데이터가 공용 인터넷으로 나가면 안 됨
- EC2 인스턴스만 S3 버킷에 업로드 가능해야 함

A. EC2가 있는 서브넷에 S3용 인터페이스 VPC 엔드포인트 생성 + S3 버킷에 EC2 IAM 역할만 허용하는 리소스 정책
S3용 인터페이스 VPC 엔드포인트를 EC2가 있는 VPC(서브넷)에 만들면:
    EC2 → S3 트래픽이 VPC 엔드포인트(PrivateLink)로만 가서 퍼블릭 인터넷을 거치지 않습니다.
S3 버킷 리소스 정책에서 EC2 인스턴스에 붙은 IAM 역할만 s3:PutObject 등으로 허용하면, 그 EC2만 버킷에 업로드할 수 있어 “EC2만 액세스” 요구를 충족합니다.

B. ALB 스티키 세션(세션 선호도)
같은 클라이언트를 한 인스턴스로만 보내서, 그 인스턴스 메모리의 세션을 쓰게 하는 방식입니다. 그 인스턴스가 스케일 인으로 종료되면 세션이 사라집니다. “하루 종일 자주 확장·축소”하는 환경에서는 분산 세션 저장이 아니므로 요구사항을 완전히 충족하지 못합니다.

 

Answer: A

요구사항
- EC2 온디맨드 + 여러 AZ에서 자동 확장·축소
- ALB로 부하 분산
- 분산 세션 데이터 관리 필요
- 코드 변경 가능

 

A. Amazon ElastiCache로 세션 데이터 관리·저장
여러 EC2가 자주 확장·축소되면, 세션을 한 인스턴스 메모리에만 두면:
    다음 요청이 다른 인스턴스로 가면 세션 없음
    스케일 인으로 인스턴스가 종료되면 세션 유실
Amazon ElastiCache(Redis 또는 Memcached)에 세션을 저장하면:
    모든 EC2가 같은 ElastiCache에 세션을 읽고 씀 → 분산 세션 구현
    인스턴스가 늘어나거나 줄어들어도 세션은 ElastiCache에만 있으므로 유실되지 않음
코드 변경: 세션 저장소를 로컬 메모리 → Redis/Memcached(ElastiCache)로 바꾸면 되고, “코드 변경 가능” 조건에 맞습니다.

 

Answer: D

요구사항
- 주문 수집(빠름) / 주문 이행(느림) 프로세스가 피크 시 적절히 확장
- 스케일링 이벤트로 데이터 손실 없음
- AWS 리소스 활용 최적화

D. SQS 큐 2개(수집용·이행용) + EC2가 각 큐 폴링 + 인스턴스당 백로그 지표로 Auto Scaling 조정
SQS 큐 2개(수집용·이행용)를 두면:
    수집 인스턴스는 주문을 큐에 넣고, 이행 인스턴스는 큐에서 꺼내 처리하는 구조가 됩니다.
    인스턴스가 스케일 인으로 종료되어도 주문은 큐에 남아 있으므로 데이터 손실이 없습니다.

 

인스턴스당 백로그(backlog per instance) 지표:
    (큐에 있는 메시지 수) / (현재 인스턴스 수) 로 “인스턴스 하나당 처리 대기 작업 수”를 나타냅니다.
    이 값을 CloudWatch 사용자 지정 지표 등으로 만들고, 이 지표를 기준으로 Auto Scaling을 조정하면:
        백로그가 크면 → 인스턴스 증가 (이행 용량 확대)
        백로그가 작으면 → 인스턴스 감소 (과도한 인스턴스 방지)
    그래서 피크 때는 충분히 확장하면서, 평소에는 인스턴스를 줄여 리소스 활용을 최적화할 수 있습니다.
“트래픽이 가장 많은 시간에 적절히 확장” + “리소스 활용 최적화”를 동시에 만족합니다.

 

Answer: D

요구사항
- 여러 리전에 걸쳐 EC2, Lambda, RDS, SNS, SQS 등 리소스 존재
- 리소스에 "application" 태그(이름)와 애플리케이션별 값이 붙어 있음
- 해당 태그가 붙은 모든 구성 요소를 식별하는 가장 빠른 방법 필요

D. AWS Resource Groups Tag Editor로 애플리케이션 태그 기준 전역 리소스 조회
AWS Resource Groups Tag Editor는 태그로 리소스를 검색·그룹화하는 전용 기능입니다.
    태그 조건 지정: 예) application = myapp 또는 특정 값들
    여러 리전·여러 리소스 타입(EC2, Lambda, RDS, SNS, SQS 등)을 한 번에 검색
    콘솔/API로 전역(멀티 리전) 조회 가능
별도 스크립트·로그 분석 없이 한 화면/한 쿼리로 “application 태그가 있는 모든 리소스”를 볼 수 있어 가장 빠르게 요구사항을 충족합니다.

 

Answer: A

요구사항
- DB를 하루 1회 S3로 내보내기 (2~5GB)
- S3 액세스 패턴: 가변적이고 빠르게 변함
- 즉시 사용 가능 (검색 대기 없음)
- 최대 3개월 동안 접근 가능
- 검색 시간을 늘리지 않으면서 가장 비용 효율적인 스토리지 클래스 선택

A. S3 지능형 계층화(S3 Intelligent-Tiering)
S3 Intelligent-Tiering은 접근 패턴에 따라 객체를 자동으로 적절한 계층으로 옮깁니다.
즉시 사용 가능: 아카이브/글로벌러 검색처럼 대기 시간이 없음 → “검색 시간을 늘리지 않음” 충족.
가변·예측 어려운 액세스에 적합: 접근이 줄면 저비용 계층으로 이동해 저장 비용이 줄고, 접근 시 추가 검색 요금이 없음.
“가변적이고 빠르게 변하는” 패턴에서는 고정된 Standard-IA/Glacier보다 자동 계층 이동 + 검색 요금 없음인 Intelligent-Tiering이 비용 효율이 좋습니다.
3개월 보관·즉시 접근·비용 최소화를 동시에 만족합니다.

 

Answer: A

요구사항
- ALB(Application Load Balancer)를 XSS(교차 사이트 스크립팅)·SQL 인젝션 같은 애플리케이션 수준 공격으로부터 보호
- 적절한 트래픽 필터링 구현
- 인프라·운영 인력 최소
- 서버 관리·업데이트·보호 책임을 줄일 것

A. AWS WAF 규칙 구성 후 ALB에 연결
- AWS WAF(Web Application Firewall)는 애플리케이션 계층(L7) 공격을 막는 서비스입니다.
    SQL 인젝션, XSS 등은 WAF 규칙(매니지드 규칙 그룹 또는 커스텀 규칙)으로 차단할 수 있습니다.
    WAF를 ALB에 연결하면 ALB로 들어오는 요청이 WAF를 먼저 거쳐 악성 요청만 걸러집니다.
- 관리형 서비스: 규칙만 설정·연결하면 되고, 방화벽 EC2를 둘 필요가 없어 인프라·운영 부담이 적습니다.
- “서버 관리·업데이트·보호 책임 감소” 요구에도 맞습니다.

 

Answer: B

요구사항
- 매일 수백 개의 .csv 파일이 S3에 적재
- Apache Parquet로 변환 후 변환 데이터 버킷에 저장
- 최소한의 개발 노력

B. AWS Glue 크롤러로 데이터 검색 + Glue ETL 작업으로 변환 후 변환 데이터 버킷에 출력
AWS Glue는 서버리스 ETL 서비스로, CSV → Parquet 같은 변환에 맞게 설계되어 있습니다.
    Glue 크롤러: S3의 CSV 스키마를 자동 검색해 카탈로그에 등록합니다.
    Glue ETL 작업: 소스(S3 CSV)와 대상(S3 Parquet)을 지정하면, Glue가 Spark 기반 스크립트를 생성·실행해 변환합니다. 직접 Spark/코드를 거의 쓰지 않고 설정 위주로 구성할 수 있어 개발 노력이 적습니다.

 

출력: ETL 작업의 대상(Output) 에 변환된 데이터 버킷을 지정하면 됩니다.
수백 개 파일·대용량도 Glue(Spark)가 처리할 수 있어, “매일 수백 개” 요구에 적합합니다.

 

Answer: A

요구사항
- 700TB 백업 데이터, 온프레미스 NAS
- 드문 규제 요청용 접근, 7년 보관
- 1개월 이내 마이그레이션 완료
- 공용 인터넷 500Mbps 전용 대역폭
- 최저 비용으로 마이그레이션·저장

A. AWS Snowball로 데이터 전송 + 수명 주기 정책으로 S3 Glacier Deep Archive 전환
1개월 내 700TB 전송 불가(네트워크만 사용 시)
    700TB ÷ 500Mbps ≈ 133일 이상 소요 → 인터넷/VPN/Direct Connect만으로는 1개월 달성 불가.

AWS Snowball(또는 700TB면 Snowmobile) 사용:
    디바이스를 데이터센터로 보내고, NAS → Snowball로 로컬 네트워크로 복사한 뒤 AWS로 반송.
    전송은 물리 배송이라 500Mbps 제한을 받지 않고, 1개월 내 완료 가능.
저장 비용 최소화:
    Snowball은 데이터를 S3에 적재.
    수명 주기 정책으로 S3 Glacier Deep Archive로 자동 전환하면, 7년 보관·드문 접근에 가장 저렴한 스토리지 클래스를 쓸 수 있음.
따라서 “1개월 내 마이그레이션 + 최저 비용 전송·저장”을 동시에 만족합니다.

 

Answer: B

요구사항
- 수백만 개 객체가 있는 S3 버킷 (CloudFront 오리진)
- 기존 객체와 앞으로 추가될 모든 객체에 암호화 적용
- 최소한의 노력

B. 버킷 기본 암호화 활성화 + S3 Inventory로 암호화 안 된 객체 목록(.csv) 생성 + S3 배치 작업(복사)으로 해당 객체 암호화
버킷 기본 암호화 설정: 새로 올라오는 모든 객체는 자동으로 암호화됩니다.
기존(수백만 개) 미암호화 객체:
    S3 Inventory: 암호화 상태가 포함된 리포트를 주기적으로 생성해, 암호화되지 않은 객체 목록을 .csv(또는 매니페스트)로 얻을 수 있습니다.
    S3 Batch Operations: 그 목록(매니페스트)을 대상으로 복사(Copy) 작업을 만들고, 같은 키로 복사 + 서버 측 암호화(SSE) 를 지정하면, 기존 객체를 암호화된 상태로 덮어쓰는 효과가 납니다. 로컬로 내려받을 필요 없이 S3 안에서 처리됩니다.
수백만 개도 한 번 설정한 배치 작업으로 처리 가능하고, 로컬 저장소·수동 작업이 없어 최소한의 노력으로 요구사항을 충족합니다.

C. KMS 키 생성 + 버킷에 SSE-KMS 설정 + 버전 관리 활성화
기본 암호화는 그 이후에 올라오는 객체만 암호화합니다. 이미 있는 수백만 개 객체는 그대로 비암호화로 남습니다. “모든 기존 객체 암호화” 요구를 충족하지 못합니다.
그러니까 문제의 요구사항 기존 객체 + new 객체 를 암호화 하려면 B로 해야함 

 

Answer: A

요구사항
- ALB 뒤 애플리케이션, 데이터는 Amazon Aurora
- 재해 복구(DR) 구성 필요
- 최대 30분 데이터 손실 허용 (RPO)
- 기본(1차) 인프라가 정상일 때는 2차가 부하를 처리할 필요 없음 → 활성-수동(standby) 구조

A. 두 번째 리전에 필요한 인프라·앱 배포 + Route 53 활성-수동 장애 조치 + 두 번째 리전에 Aurora 복제본 생성
- 두 번째 리전에 앱·인프라 배포: DR 시 사용할 스탠바이 앱·ALB 등이 미리 준비됩니다.
- Route 53 활성-수동 장애 조치: 평소에는 1차 리전만 사용하고, 1차 장애 시에만 2차 리전으로 트래픽 전환 → “기본이 정상일 때 2차는 부하 처리 안 함” 조건을 만족합니다.
- 두 번째 리전에 Aurora 복제본: Aurora Global Database의 보조 클러스터(또는 크로스 리전 복제본)를 두면 지속적으로 복제되어 RPO를 30분 이내로 유지할 수 있고, 재해 시 복제본 승격(promote) 만 하면 되어 RTO도 짧습니다.

 

Answer: A, E

상황
- 퍼블릭 서브넷의 EC2(탄력적 IP)에서 웹 서버 실행
- 기본 보안 그룹 사용
- 기본 네트워크 ACL이 모든 트래픽 차단으로 변경됨
- 어디서나 포트 443으로 웹 서버 접근 가능해야 함

A. 소스 0.0.0.0/0, TCP 443 허용 규칙이 있는 보안 그룹 생성
보안 그룹은 인바운드에서 “누가 접속할 수 있는지”를 정합니다.
인바운드: 소스 0.0.0.0/0, 프로토콜 TCP, 포트 443 허용 → 어디서나 HTTPS(443) 접근 가능.
보안 그룹은 상태 저장(stateful) 이라, 이 인바운드만 허용해도 응답 트래픽은 자동으로 허용됩니다.

E. NACL: 인바운드 TCP 443(소스 0.0.0.0/0) 허용 + 아웃바운드 TCP 32768–65535(대상 0.0.0.0/0) 허용
네트워크 ACL은 상태 비저장(stateless) 이라 인바운드·아웃바운드를 각각 허용해야 합니다.
인바운드: 소스 0.0.0.0/0, TCP 443 → 클라이언트 → 서버(443) 허용.
아웃바운드: 서버 → 클라이언트 응답은 목적지 포트가 임시 포트(32768–65535) 이므로, 아웃바운드에서 TCP 32768–65535, 대상 0.0.0.0/0 허용이 필요합니다.
E는 위 두 규칙을 모두 포함하므로 NACL 측면에서 올바른 조합입니다.

 

Answer: D

요구사항
상태 저장 애플리케이션, 인메모리 작업 수행
M5 EC2, CloudFormation 배포
트래픽 증가에 따라 성능 저하·지연 발생
운영상 가장 효율적인 방식으로 해결

D. CloudFormation 템플릿 수정해 EC2를 R5로 교체 + CloudWatch 에이전트로 애플리케이션 지연 시간 커스텀 메트릭 생성
R5 인스턴스: 메모리 최적화 제품군입니다. “인메모리 작업”이 많다면 메모리가 병목일 가능성이 크므로, M5보다 메모리 비중이 큰 R5로 교체하면 성능 개선에 도움이 됩니다.

CloudWatch 에이전트: EC2는 기본(내장) 메트릭으로 메모리 사용률·애플리케이션 지연 시간을 제공하지 않습니다. CloudWatch 에이전트를 설치하면 메모리·디스크와 커스텀 메트릭(애플리케이션 지연 시간 등)을 CloudWatch로 보낼 수 있어, 향후 용량 계획과 성능 추적에 쓸 수 있습니다.

CloudFormation 템플릿 수정으로 인스턴스 타입(R5)과 에이전트 배포를 코드로 관리하면, 운영상 일관되고 효율적인 변경이 됩니다.

CloudFormation AWS 인프라를 코드(yaml, json)로 정의하고, 버튼 한 번으로 그대로 만들어주는 서비스

 

Answer: B

요구사항
- API Gateway로 사용자 요청을 받는 새 API
- 요청량이 매우 가변적 → 몇 시간 동안 요청이 없을 수 있음
- 비동기 처리이지만 요청 후 몇 초 이내 완료
- 최저 비용으로 위 요구사항 충족
- API가 호출할 컴퓨팅 서비스 선택

B. AWS Lambda 함수
AWS Lambda는 요청이 있을 때만 실행되고, 실행 횟수·실행 시간만큼 과금됩니다.
    몇 시간 동안 요청이 없으면 → 실행 0회 → 비용 0 (프로비저닝 비용 없음)
    요청이 오면 → API Gateway가 Lambda를 호출 → 몇 초 안에 처리 가능
가변적인 트래픽에 맞춰 자동 확장되며, 별도 인스턴스/노드를 둘 필요가 없어 유휴 시간이 긴 패턴에서 비용이 가장 낮습니다.
API Gateway와 Lambda 조합은 “API 수신 → 몇 초 안에 처리” 패턴에 맞고, 비동기 처리도 Lambda(또는 Lambda가 SQS 등에 넘기는 구조)로 구현 가능합니다.

 

Answer: D

요구사항
- Amazon Linux EC2 인스턴스 그룹에서 애플리케이션 실행
- 규정 준수: 애플리케이션 로그 파일을 7년 보관
- 보고 도구가 모든 로그 파일에 동시에 접근해 분석
- 가장 비용 효율적인 스토리지

D. Amazon S3
Amazon S3는 대용량·장기 보관에 맞고, 7년 보관에 적합합니다.
    내구성·가용성이 높고, 수명 주기 정책으로 오래된 로그는 Glacier 등으로 옮겨 비용을 줄일 수 있습니다.
동시 접근: 보고 도구(또는 Athena 등)가 S3의 객체들을 동시에 읽고 조회할 수 있어, “모든 파일에 동시에 액세스” 요구를 충족합니다.
비용: 7년치 로그처럼 용량이 커지는 데이터는 S3(및 Glacier)가 EBS·EFS보다 단위 용량당 비용이 낮아 “가장 비용 효율적”입니다.
EC2는 CloudWatch Logs 에이전트 → S3, 또는 앱/스크립트가 직접 S3에 업로드하는 방식으로 로그를 S3에 모을 수 있습니다.

 

Answer:  A

요구사항
- 외부 공급업체가 회사 AWS 계정에서 작업 수행
- 공급업체 자동화 도구는 공급업체 소유 AWS 계정에서 실행
- 공급업체는 회사 계정 IAM 권한이 없음
- 공급업체에 이 액세스 권한을 어떻게 줄지 결정

A. 회사 계정에 IAM 역할 생성 → 공급업체(또는 공급업체 역할)가 AssumeRole 하도록 위임 + 역할에 필요한 정책 연결
크로스 계정 액세스의 권장 방식은 회사 계정에 IAM 역할을 만들고, 공급업체 계정이 그 역할을 가정(AssumeRole) 하는 것입니다.
    1. 회사 계정에 IAM 역할 생성
    2. 역할의 신뢰 정책(Trust Policy) 에 공급업체 AWS 계정 ID(및 필요 시 공급업체의 특정 IAM 역할/사용자)를 넣어, “이 계정(또는 이 역할)만 이 역할을 Assume 할 수 있다”고 설정
    3. 그 역할에 공급업체가 필요한 권한만 담은 IAM 정책 연결
공급업체 측 자동화는 STS AssumeRole로 이 역할을 가정해 임시 자격 증명을 받고, 그 자격 증명으로 회사 계정 리소스에 접근합니다.
장기 자격 증명(액세스 키/비밀번호) 를 공유할 필요가 없고, 역할·정책으로 최소 권한과 감사를 유지할 수 있어 적절한 방식입니다.

 

Answer: A, D

요구사항
Java Spring Boot 앱이 EKS 포드로 프라이빗 서브넷에서 실행
Amazon DynamoDB에 데이터 쓰기 필요
인터넷으로 트래픽이 나가지 않도록 하면서 DynamoDB와 통신

A. EKS 포드에 충분한 권한이 있는 IAM 역할 연결 
포드가 DynamoDB API를 호출하려면 IAM 권한이 필요합니다.
IRSA(IAM Roles for Service Accounts) 로 IAM 역할을 쿠버네티스 서비스 계정에 연결하고, 포드는 그 서비스 계정을 사용해 역할을 가정(AssumeRole) 하며 임시 자격 증명으로 DynamoDB에 접근합니다.
액세스 키를 코드에 넣을 필요가 없고, “DynamoDB에 쓰기” 등 필요한 권한만 역할에 부여하면 됩니다.

 

D. DynamoDB용 VPC 엔드포인트 생성 
DynamoDB VPC 엔드포인트(Gateway 타입)를 쓰면, VPC 안의 트래픽이 퍼블릭 인터넷을 거치지 않고 AWS 네트워크 안에서만 DynamoDB로 갑니다.
프라이빗 서브넷의 포드 → VPC 엔드포인트 → DynamoDB 이므로 “인터넷에 트래픽 노출 없이” DynamoDB와 상호작용할 수 있습니다.

 

Answer: C, E

요구사항
- 단일 리전의 EC2로 웹 앱 재호스팅 완료
- 고가용성·내결함성으로 재설계
- 트래픽이 실행 중인 모든 EC2 인스턴스에 무작위로 분산되어야 함

C. Amazon Route 53 다중값 응답(Multivalue) 라우팅 정책 생성 
Multivalue 응답 라우팅은 한 쿼리에 여러 값(예: 인스턴스 IP) 을 무작위 순서로 돌려줍니다.
각 인스턴스(또는 ALB 등)에 대한 레코드를 여러 개 두고 Multivalue를 쓰면, 클라이언트가 받은 목록 중 하나를 쓰게 되어 트래픽이 여러 인스턴스에 무작위로 분산됩니다.
“실행 중인 모든 EC2에 무작위로 도달” 요구에 맞는 라우팅 방식입니다.

 

E. EC2 4대 배치 — 가용 영역당 2대씩 2개 AZ 
고가용성·내결함성을 위해 최소 2개 가용 영역(AZ) 에 인스턴스를 나누는 것이 기본입니다.
한 AZ에 2대, 다른 AZ에 2대 = 2개 AZ에 균등 분산이라, 한 AZ 장애 시에도 나머지 AZ에서 2대가 서비스할 수 있어 내결함성을 만족합니다.
3대(2+1)보다 4대(2+2)가 장애 시 용량이 균형 있어 E가 더 적합합니다.

A. Route 53 장애 조치(Failover) 라우팅
주/보조(1차/2차)로 전환하는 용도라, “모든 인스턴스에 무작위로 분산”하는 용도가 아닙니다.

B. Route 53 가중(Weighted) 라우팅
비율(가중치)로 나누는 방식이라, “무작위로 모든 인스턴스에 도달”이라는 요구에는 다중값 응답(C) 이 더 직접적으로 맞습니다

 

Answer: B

요구사항
- 사용자 활동 데이터 수집·분석을 AWS로 마이그레이션
- 저장소가 계속 커져 페타바이트 규모까지 성장
- 기존·신규 데이터에 대해 SQL 기반 온디맨드 분석 가능
- 고가용성 데이터 수집
- 최소한의 운영 오버헤드

B. Kinesis Data Firehose → Amazon Redshift
B 는 데이터 수집 및 분석을 위한 완전히 관리되고 확장 가능한 솔루션을 제공합니다. KDF 는 대량의 스트리밍 데이터를 처리하도록 자동으로 확장하여 데이터 수집 프로세스를 간소화합니다. 강력하고 완전히 관리되는 데이터 웨어하우징 솔루션인 Redshift 클러스터에 데이터를 직접 로드할 수 있습니다.
Amazon Redshift 는 클라우드에서 완벽하게 관리되는 페타바이트 규모의 데이터 웨어하우스 서비스입니다.

 

Answer: A, E

요구사항
- EC2에서 RESTful 웹 서비스로 수천 개 원격 장치에서 데이터 수집
- EC2가 원시 데이터 수신 → 변환 → S3 저장
- 원격 장치가 곧 수백만 개로 증가
- 확장성 + 운영 오버헤드 최소화

E. API Gateway로 원시 데이터 수신 → Kinesis Data Streams → Firehose로 S3 전달 
API Gateway: 장치 요청을 받는 REST API를 서버리스로 제공하고, 트래픽에 맞춰 자동 확장됩니다.
Kinesis Data Streams: API Gateway(또는 중간 Lambda)에서 넣은 데이터를 스트리밍으로 버퍼링·처리합니다.
Kinesis Data Firehose: 스트림(또는 직접 수집)을 소스로 해 S3로 전달하고, 필요 시 Lambda로 변환도 할 수 있어 수신·변환·S3 저장을 관리형으로 처리합니다.
EC2 없이 수신·버퍼·저장이 이어지므로 확장성과 운영 최소화를 동시에 만족합니다.

 

A. AWS Glue로 S3에 쌓인 데이터 처리 
Glue: S3에 이미 저장된 데이터를 배치 ETL로 변환·정제하는 관리형 서비스입니다.
E로 원시 데이터가 S3에 쌓이고, A로 추가 변환·정규화·분석용 테이블을 만드는 2단계 구조로 쓸 수 있습니다.
Glue는 서버리스·관리형이라 운영 오버헤드를 줄이면서 “확장 가능한 처리”를 만족합니다.

 

Answer: B

상황
- CloudTrail 로그를 3년 보관
- S3 버전 관리 활성화
- 3년 후 현재 객체 삭제 수명 주기 정책 존재
- 4년차 이후에도 객체 수가 계속 증가 (새 로그 수는 일정)
- 3년 초과 객체를 가장 비용 효율적으로 삭제할 방법 필요
객체가 계속 늘어나는 이유
- S3 버전 관리가 켜져 있으면, 수명 주기로 “현재 버전”만 만료/삭제해도 이전 버전(비현재 버전) 은 그대로 남습니다.
그래서 “현재 버전만 3년 후 삭제”로는 과거 버전이 쌓여 객체 수가 계속 늘어납니다.

B. S3 수명 주기 정책에서 현재 버전뿐 아니라 이전 버전(비현재 버전)도 삭제되도록 구성
S3 수명 주기에서 비현재 버전 만료(NoncurrentVersionExpiration) 를 설정하면, 이전 버전도 지정한 기간(예: 비현재가 된 지 0일 또는 3년 후)에 자동 삭제됩니다.
현재 버전 만료와 비현재 버전 만료를 함께 두면, 3년이 지난 로그는 현재·이전 버전 모두 삭제되어 객체 수 증가가 멈춥니다.

 

Answer: C

요구사항
- API가 여러 모니터링 장치에서 실시간 데이터 수신 → RDS에 저장
- 데이터량 변동 → 트래픽 많을 때 API 타임아웃 발생
- 원인: DB가 API에서 오는 쓰기 트래픽을 감당하지 못함
- DB 연결 수 최소화 + 트래픽 많을 때 데이터 유실 없음

C. API가 수신 데이터를 SQS 큐에 쓰도록 수정 + SQS가 호출하는 Lambda가 큐에서 읽어 DB에 기록
1. API → SQS: API는 수신 데이터를 DB가 아니라 SQS에 넣고 곧바로 응답합니다.
    DB 부하와 분리되어, 트래픽이 많아도 API가 DB 대기 때문에 타임아웃할 일이 줄어듭니다.
    SQS는 내구성이 있어, 피크 때도 데이터가 큐에 쌓이고 유실되지 않습니다.
2. SQS → Lambda → RDS: Lambda가 SQS를 소비하고, 배치 단위로 RDS에만 씁니다.
    DB에 접속하는 주체가 Lambda(소수의 동시 실행) 로 한정되어 연결 수가 줄어듭니다.
    필요하면 RDS Proxy를 쓰면 연결 수를 더 줄일 수 있습니다.
따라서 “DB 연결 최소화”와 “트래픽 많을 때 데이터 유실 방지”를 동시에 만족합니다.

 

Answer: A

요구사항
- EC2에서 MySQL 직접 운영, 복제·확장을 수동으로 관리
- 수요에 따라 DB 계층 컴퓨팅 용량을 추가·제거하는 과정을 단순화
- 최소한의 운영으로 성능·확장성·내구성 향상

 A. Aurora MySQL용 Amazon Aurora Serverless로 데이터베이스 마이그레이션
Amazon Aurora Serverless (MySQL) 는 MySQL 호환 Aurora 엔진에 서버리스 컴퓨트를 붙인 형태입니다.
    용량 자동 조정: 부하에 따라 ACU(Aurora Capacity Unit) 가 자동으로 늘었다 줄었다 해서, “필요에 따라 컴퓨트 추가·제거”를 수동 없이 처리할 수 있습니다.
    운영 최소화: 인스턴스 크기·복제·스케일링을 직접 관리할 필요가 줄어듭니다.
    성능·확장성·내구성: Aurora의 스토리지 자동 확장, 다중 AZ 복제, 6복사본 등이 그대로 적용됩니다.
MySQL → Aurora MySQL 이라 엔진이 같아 마이그레이션 부담이 적고, “MySQL 데이터베이스” 요구와도 맞습니다.

 

Answer: C

요구사항
NAT 인스턴스 2개가 필요한 트래픽을 감당하지 못할 것이라는 우려
고가용성, 내결함성, 자동 확장이 가능한 구성 필요

C. NAT 인스턴스 2개 제거 후, 서로 다른 가용 영역에 NAT 게이트웨이 2개로 교체
NAT 게이트웨이는 AWS가 관리하는 NAT 서비스로, NAT 인스턴스보다 적합합니다.
    자동 확장: 게이트웨이당 최대 약 45Gbps까지 확장되며, 인스턴스 크기·개수를 직접 조정할 필요가 없습니다.
    관리형: OS·패치·모니터링을 AWS가 담당해 운영 부담이 적습니다.
서로 다른 가용 영역(AZ)에 2개를 두면:
    한 AZ에 장애가 나도 다른 AZ의 NAT 게이트웨이가 동작해 고가용성·내결함성을 만족합니다.
    각 AZ의 프라이빗 서브넷은 해당 AZ의 NAT 게이트웨이를 사용하도록 라우팅하면 됩니다.

정리:
고가용성·내결함성 → 서로 다른 AZ에 NAT 게이트웨이 2개
자동 확장·최소 운영 → NAT 게이트웨이(관리형, 용량 자동 확장)
→ C가 정답입니다

 

Answer: B

요구사항
- VPC A: Elastic IP가 있는 EC2에서 애플리케이션 실행
- VPC B: 데이터베이스 위치
- 동일 AWS 계정
- 필요한 액세스를 가장 안전하게 제공할 방법

 

B. VPC A와 VPC B 사이에 VPC 피어링 연결 구성
VPC 피어링은 두 VPC를 프라이빗으로 연결합니다.
    트래픽이 퍼블릭 인터넷을 거치지 않고 AWS 네트워크 안에서만 이동합니다.
    EC2(VPC A) → 피어링 링크 → VPC B → DB 로 비공개 통신이 가능합니다.

 

보안 그룹으로 DB는 VPC A의 CIDR 또는 EC2 보안 그룹에서 오는 트래픽만 허용하면 되어, 노출 범위를 최소화할 수 있습니다.
DB를 퍼블릭에 노출하지 않고, 가장 안전한 접근 방식입니다.

 

Answer: C

요구사항
- EC2에서 고객용 데모 환경 실행, 환경별 VPC로 격리
- RDP 또는 SSH 액세스가 설정되면 운영 팀에 알림 필요

C. VPC Flow Logs를 CloudWatch Logs로 전송 + 메트릭 필터 생성 + 알림 동작이 있는 CloudWatch 지표 경보 생성
VPC Flow Logs는 VPC 내 네트워크 트래픽(소스/대상 IP, 포트, 허용/거부 등)을 기록합니다.
    RDP = 3389, SSH = 22 포트 트래픽을 로그에서 식별할 수 있습니다.
CloudWatch Logs에 Flow Logs를 보내고, 메트릭 필터로:
    목적지 포트 22(SSH) 또는 3389(RDP) 이고 ACCEPT인 로그를 카운트하는 메트릭을 만듭니다.
CloudWatch 지표 경보에서:
    해당 메트릭이 조건(예: 1 이상)을 만족하면 ALARM 상태로 전환하고,
    알림 동작으로 SNS 등을 호출해 운영 팀에게 알립니다.
따라서 “RDP/SSH 액세스가 발생했을 때”를 실제 트래픽 기준으로 감지하고 알릴 수 있어 요구사항에 맞습니다.

RDP(Remote Desktop Protocol, 원격 데스크톱 프로토콜)는 원격으로 다른 컴퓨터의 화면을 보고 조작할 때 쓰는 마이크로소프트 프로토콜

 

Answer: A, B

요구사항
- 새 AWS 계정 생성
- 루트 사용자(root user) 액세스 보호
- 이를 위한 2가지 작업 선택

A. 루트 사용자가 강력한 암호를 사용하도록 함 
강한 암호는 루트 계정의 첫 번째 방어선입니다.
추측·사전 공격에 견디도록 길이·복잡성·고유성을 갖추는 것이 좋습니다.
“루트 액세스 보호”의 기본 조치입니다.

B. 루트 사용자에 대한 MFA(다단계 인증) 활성화 
MFA를 켜면 비밀번호만으로는 로그인할 수 없고, 두 번째 요소(OTP·하드웨어 키 등)가 필요합니다.
AWS에서도 루트 사용자에는 반드시 MFA를 권장합니다.
루트는 계정 전체 권한을 가지므로, A(강한 암호) + B(MFA) 로 보호하는 것이 표준입니다.

 

Answer: C

요구사항
- ALB 뒤 EC2(EBS 지원) + Amazon Aurora
- 모든 애플리케이션 데이터가 유휴(at rest) 및 전송 중(in transit) 에 암호화되어야 함

C. KMS로 EBS·Aurora 유휴 암호화 + ALB에 ACM 인증서 연결해 전송 중 암호화
1. 유휴 암호화(at rest)
    EBS: 볼륨 암호화 시 AWS KMS 키 사용(기본 또는 고객 관리형 CMK).
    Aurora: 스토리지 암호화를 KMS 키로 설정.
→ EBS·Aurora 모두 KMS로 유휴 암호화 가능.

 

2. 전송 중 암호화(in transit)
    ALB에 AWS Certificate Manager(ACM) 인증서를 붙여 HTTPS 리스너를 두면, 클라이언트–ALB 구간이 TLS로 암호화됩니다.
    Aurora는 TLS 지원하므로, 앱–DB 구간도 암호화 가능.
→ “전송 중”은 ALB에 ACM 인증서를 쓰는 것이 맞고, KMS는 인증서가 아니라 키 관리용입니다.

 

Answer: C

요구사항
- 온프레미스 Oracle → Amazon Aurora PostgreSQL 이전
- 여러 앱이 동일 테이블에 읽기/쓰기
- 앱을 한 달 간격으로 하나씩 마이그레이션
- 마이그레이션 기간 동안 두 DB 간 데이터 동기화 필요
- 읽기/쓰기 많음 → 최소 다운타임·운영 부담 목표

C. AWS DMS(AWS Database Migration Service)와 함께 AWS Schema Conversion Tool 을 사용
1. AWS Schema Conversion Tool (SCT) 사용
    Oracle → PostgreSQL(Aurora)은 스키마/객체 변환이 필요하므로 SCT가 적합합니다.
    SCT로 스키마 변환 후 DMS로 데이터 이전·동기화하는 구성이 표준입니다.
2. 전체 로드 + CDC
    전체 로드: 기존 데이터를 Aurora로 한 번 옮깁니다.
    CDC: 전체 로드 이후 Oracle에서 발생하는 변경을 지속적으로 Aurora에 반영해, 앱을 한 달씩 옮기는 동안에도 두 DB가 동기화되도록 합니다.
    “데이터는 마이그레이션하는 동안 두 데이터베이스에서 동기화 상태를 유지해야 합니다” 요구사항을 충족합니다.
3. 메모리 최적화 복제 인스턴스
    DMS는 트랜잭션 로그 처리, 변경 버퍼링 등으로 메모리 사용이 큽니다.
    읽기/쓰기가 많은 환경에서는 메모리 최적화 복제 인스턴스가 적합하고, AWS 권장사항과도 일치합니다.
4. 테이블 매핑으로 모든 테이블 선택
    여러 앱이 같은 테이블을 사용하므로, 일부만 선택하면 동기화가 깨집니다.
    모든 테이블을 매핑에 포함해야 두 DB가 일치한 상태를 유지할 수 있습니다.

 

Answer: D

요구사항 
3계층 이미지 공유 앱: 프론트엔드(EC2) / 애플리케이션(EC2) / MySQL(EC2)
목표: 확장 가능·고가용성, 애플리케이션 변경 최소화

D. 프런트엔드 계층과 애플리케이션 계층에 로드 밸런싱된 다중 AZ AWS Elastic Beanstalk 환경을 사용 Amazon RDS 다중 AZ DB 인스턴스로 이동

1. 프론트엔드 + 애플리케이션: Elastic Beanstalk 다중 AZ
     로드 밸런서 + 다중 AZ로 고가용성
     EB가 EC2 기반이므로 기존 앱 구조를 크게 바꾸지 않고 이전 가능
     오토 스케일링으로 확장성 확보
2. DB: Amazon RDS Multi-AZ
     기존 MySQL 유지 → 스키마·쿼리·드라이버 변경 최소
     Multi-AZ로 고가용성 (자동 장애 조치)
3. 이미지: Amazon S3
     이미지 저장·제공은 S3가 적합 (용량 무제한, 내구성, 저비용)
     DB나 EC2 디스크에 이미지 저장하는 방식보다 확장·운영 측면에서 유리
    앱 변경은 “업로드/다운로드 경로를 S3로 연결” 수준으로 최소화 가능
→ 확장성·고가용성 + 최소 변경 조건을 모두 만족합니다.

A. Lambda·DynamoDB 도입 시, 기존 EC2 + MySQL 구조를 크게 바꿔야 함. “최소한의 변경” 요구사항에 맞지 않음.

 

Answer: A

요구사항
- VPC-A(계정 A): 앱이 도는 EC2
- VPC-B(계정 B): 파일이 있는 EC2
- 서로 다른 AWS 계정의 두 VPC
- 조건: 보안 유지, 단일 장애 지점 없음, 대역폭 문제 없음

A. VPC 피어링
1. 계정 간 연결 지원
    VPC 피어링은 다른 AWS 계정의 두 VPC를 연결하는 공식 방식입니다.
    한 계정에서 피어링 요청을 생성하고, 다른 계정에서 수락하면 됩니다.
2. 단일 장애 지점 없음
     피어링은 AWS 백본 네트워크를 쓰는 논리적 연결입니다.
     별도의 단일 게이트웨이/장비에 의존하지 않아, 일반적인 “단일 장애 지점”이 없습니다.
3. 대역폭 제한 없음
     같은 리전 내 피어링 트래픽은 AWS 내부 네트워크로 전달되며,
     피어링 자체에 대한 대역폭 제한이나 추가 과금이 없어 대역폭 문제가 없습니다.
4. 보안
     퍼블릭 인터넷을 거치지 않고,
     보안 그룹·네트워크 ACL로 트래픽을 제어할 수 있어 보안 요구를 만족합니다.

 

Answer: C

요구사항
- 엔지니어 팀용 계정별 실험 환경
- 지정된 달의 EC2 사용량(비용)이 계정별 임계값을 넘으면 즉시 알림
- 비용 효율이 가장 좋은 방법 필요

C. AWS Budget을 사용하여 일일 보고서 생성 임계값 초과 시 알림을 받도록 Amazon Simple Notification Service(Amazon SNS) 주제를 구성

1. 계정 단위 예산
    AWS Budgets로 계정(또는 링크된 계정)마다 예산을 만들 수 있어, “각 계정의 특정 임계값” 요구사항에 맞습니다.
2. 기간 = 매월
    예산 기간을 월별(monthly)로 설정할 수 있어, “지정된 달” 기준 EC2 사용량 모니터링에 적합합니다.
3. 범위 = EC2
     예산 범위(scope)를 EC2 서비스만 선택할 수 있어, EC2 사용량만 임계값과 비교할 수 있습니다.
4. 임계값 알림
    예산에 경고 임계값(예: 80%, 100%)을 설정하고,
    SNS 주제를 연결하면 임계값 초과 시 알림을 받을 수 있습니다.
5. 비용 효율
     예산 2개까지 무료, 이후에는 예산당 소액 요금으로,
     CUR + Athena + EventBridge 같은 별도 파이프라인 없이 한 서비스로 해결되므로 가장 비용 효율적입니다.

Cost Explorer는 보고·분석용이라, “임계값 초과 시 SES 알림 보내기” 같은 알림 설정 기능이 없습니다
CUR + Athena + EventBridge + SNS로 직접 구현하는 방식은 구성·운영이 복잡하고, S3·Athena·이벤트 규칙 등 비용과 관리 부담이 크다

 

Answer: A

요구사항
- Go 1.x 단일 Lambda로 마이크로서비스 구현
- 클라이언트는 HTTPS로 호출
- IAM으로 호출 인증
- 운영상 가장 효율적인 배포 방식 필요

1. HTTPS + IAM
    API Gateway가 HTTPS 엔드포인트를 제공하고, IAM 인증을 활성화하면 SigV4 서명 검증을 API Gateway가 처리합니다. Lambda에 인증 로직을 넣을 필요가 없습니다.

 

2. 운영 효율
    요청 검증: API Gateway에서 스키마/파라미터 검증 설정 가능 → Lambda에서 검증 코드 최소화.
    속도 제한·스로틀링: 사용량 플랜·스테이지별 스로틀로 별도 구현 없이 적용 가능.
    API 구성: 리소스·메서드·스테이지·배포를 한 곳에서 관리할 수 있어, “운영상 효율적”이라는 표현과 잘 맞습니다.

 

3. 추가 인프라 없이 확장·관리
    API Gateway + Lambda만으로 관리형 HTTPS API를 구성할 수 있어, “운영상 가장 효율적인 방식”으로 기능을 배포하는 선택지로 적합합니다.

 

Answer: C

요구사항

- 데이터 웨어하우스: AWS (이미 마이그레이션됨)
- Direct Connect 보유
- 본사 사용자 → 시각화 도구로 데이터 웨어하우스 쿼리
- 쿼리 결과: 평균 50MB (캐시 없음) ← 비용의 핵심
- 시각화 웹 페이지: 약 500KB
목표: 데이터 전송 송신(egress) 비용 최소화

 

D. 데이터 웨어하우스 → 같은 리전 시각화 도구
1. 50MB가 리전 밖으로 나가지 않음
    시각화 도구를 데이터 웨어하우스와 같은 리전에 두면
  데이터 웨어하우스 → 시각화 도구 구간은 같은 리전 내부 전송입니다.
    리전 내 전송은 인터넷/DC egress보다 훨씬 저렴합니다.

 

2. AWS egress는 500KB만 발생
    사용자는 Direct Connect로 시각화 도구에 접속합니다.
    AWS 쪽에서 나가는(egress) 트래픽은 500KB 웹 페이지만 Direct Connect로 나가므로,
    50MB는 AWS egress 비용이 전혀 발생하지 않습니다.

 

3. Direct Connect 사용
    본사 접속을 인터넷이 아니라 Direct Connect로 하면,
    그 500KB egress도 인터넷 요금보다 낮은 DC 요금이 적용됩니다.
→ 데이터 전송 송신 비용이 가장 낮은 구성은 D입니다.

C. 데이터 웨어하우스 → Direct Connect → 온프레미스 시각화 도구

 

Answer: C

요구사항
- 온라인 학습 회사, PostgreSQL에 학생 기록 보관
- 여러 AWS 리전에서 데이터를 항상 온라인으로 사용 가능
- 최소한의 운영 오버헤드
핵심은 “여러 리전” + “항상 온라인”입니다. 한 리전만이 아니라, 다른 리전에서도 실시간으로 쿼리 가능한 DB가 있어야 합니다.

C. Amazon RDS for PostgreSQL DB 인스턴스로 마이그레이션합니다. 다른 리전에서 읽기 전용 복제본 생성
1. 여러 리전에서 사용 가능
    다른 리전에 읽기 전용 복제본(Cross-Region Read Replica) 을 두면,
    해당 리전에서 항상 쿼리 가능한(온라인) DB가 존재합니다.
    읽기 트래픽은 각 리전의 복제본으로 분산 가능합니다.
2. 항상 온라인
    복제본은 지속적으로 복제되는 라이브 DB라서,
    스냅샷처럼 “복원해야만 쓰는” 형태가 아닙니다.
    다른 리전 사용자도 지연 시간을 줄여 읽기 쿼리를 할 수 있습니다.
3. 운영 오버헤드 최소
    RDS가 복제·장애 감지·복제본 생성/관리를 처리합니다.
    콘솔/CLI에서 “다른 리전 읽기 복제본 생성” 수준의 설정으로 가능해,
    EC2에 직접 클러스터/복제를 구성하는 것보다 훨씬 가볍습니다.

 

Answer: C

요구사항 
- EC2 인스턴스 7개로 웹 애플리케이션 호스팅
- 요구사항: DNS 쿼리 응답에 정상인 EC2 인스턴스의 IP 주소를 모두 반환
즉, 여러 개의 IP를 돌려주고, 헬스 체크로 정상 인스턴스만 포함해야 합니다.

C. 다중값 라우팅 정책(Multivalue routing policy)
1. 여러 IP 반환
    Multivalue는 한 번의 DNS 응답에 최대 8개의 레코드(IP) 를 넣어서 반환하는 정책입니다.
    인스턴스가 7개이므로, 정상인 것들의 IP를 모두 응답에 담을 수 있습니다.
2. 정상 인스턴스만 반환
    Multivalue는 헬스 체크를 지원합니다.
    각 A 레코드에 헬스 체크를 연결하면, 헬스 체크에 통과한 인스턴스의 IP만 응답에 포함됩니다.
    “모든 정상적인 EC2 인스턴스의 IP” 요구사항과 일치합니다.
3. 용도와의 일치
    Route 53 문서상 Multivalue는 “여러 리소스의 IP를 반환하고, 헬스 체크로 정상인 것만 반환”하는 용도로 설명됩니다.
    단순히 “여러 IP + 헬스 체크”가 목적일 때 쓰는 정책이므로, 이 문제 요구사항에 가장 잘 맞습니다.

 

Answer: A

요구사항
의학 연구실 데이터 → Amazon S3 (클리닉별 읽기 전용)
전국 여러 클리닉의 온프레미스 파일 기반 애플리케이션에서 사용
최소한의 지연 시간으로 제공 필요

A. Storage Gateway 파일 게이트웨이
1. 파일 기반 접근
    File Gateway는 S3를 NFS 또는 SMB 파일 공유처럼 노출합니다.
    온프레미스 파일 기반 앱이 기존처럼 파일 공유로 접근할 수 있습니다.
2. 클리닉별 배포
    각 클리닉에 File Gateway를 VM으로 두면, 해당 클리닉의 온프레미스 앱만 그 게이트웨이를 사용합니다.
    전국 여러 클리닉 = 클리닉당 한 대씩 File Gateway 배포하는 구성과 맞습니다.
3. 지연 시간 최소화
    File Gateway는 로컬 캐시를 사용합니다.
    자주 쓰는 데이터는 게이트웨이에서 바로 제공하고, 필요할 때만 S3에서 가져와 지연을 줄일 수 있습니다.
4. S3 + 읽기 전용
    실제 데이터는 S3에 있고, 버킷 정책/IAM으로 클리닉별 읽기 전용 제어가 가능합니다.
    File Gateway는 S3에 대한 접근만 담당하므로, 이 모델과 잘 맞습니다.

 

Answer: C

요구사항
- 단일 EC2에 웹 서버 + DB가 함께 있음 (CMS)
- 목표: 고가용성(HA) + 사용자 요구에 맞는 확장

C. Aurora를 다른 AZ 읽기 복제본과 함께 사용하고, 두 AZ에 ALB와 AMI 기반 Auto Scaling 그룹 구성
1. DB 고가용성
     Aurora로 이전하고 다른 가용 영역에 읽기 전용 복제본을 두면, DB가 다중 AZ로 구성됩니다.
    한 AZ 장애 시에도 다른 AZ의 복제본으로 장애 조치 가능 → DB 고가용성 충족.
2. 웹 계층 고가용성
    ALB를 두 가용 영역에 구성 → 로드 밸런서 자체도 다중 AZ.
    AMI로 웹 서버 이미지를 만들고, 두 AZ에 걸친 Auto Scaling 그룹에 배포 → 웹 서버가 한 AZ에만 있는 구조가 아님.
    한 AZ 장애 시에도 다른 AZ의 인스턴스가 트래픽 처리 가능.
3. 확장성
    Auto Scaling 그룹으로 트래픽에 따라 EC2 인스턴스 수를 자동으로 늘리거나 줄일 수 있어, “사용자 요구에 맞게 확장” 요구사.   항을 만족합니다.

4. 일관된 배포
    원본 EC2에서 AMI를 만들어 동일한 웹 서버 구성을 여러 인스턴스에 적용할 수 있습니다.

 

Answer: A

요구사항
ALB → 단일 대상 그룹 → 최소 2대 EC2
환경별 Auto Scaling 그룹 (개발 / 프로덕션)
프로덕션: 트래픽이 많은 기간 있음
목표: 개발 환경을 가장 비용 효율적으로 구성
핵심: 개발 환경만 비용을 줄이면 되고, 프로덕션 성능/가용성은 유지해야 함.

A. 개발 환경 대상 그룹을 1대만 대상으로 재구성
1. 개발 비용 감소
    개발 환경의 대상 그룹을 EC2 1대만 대상으로 하도록 바꾸면, 개발 쪽에서는 인스턴스 1대만 유지하면 됨.
    최소 2대 → 1대로 줄어들어 EC2 비용이 약 절반으로 줄어듦.
2. 개발만 변경
    변경 대상은 개발 환경의 대상 그룹(및 개발 ASG 최소 용량) 만 해당.
    프로덕션 ALB/대상 그룹/ASG는 그대로 두면 되므로, “트래픽이 많은 프로덕션”에는 영향 없음.
3. 요구사항과의 일치
    “개발 환경을 가장 비용 효율적으로 구성” → 인스턴스 수를 줄이는 것이 가장 직접적인 비용 절감.
    개발은 고가용성 요구가 낮다고 보는 경우가 많아, 1대만 두는 구성이 합리적임.

 

Answer: D

상황: 

여러 AZ의 EC2에서 웹 앱 실행
EC2는 프라이빗 서브넷
인터넷 연결(Internet-facing) ALB 사용, EC2를 대상 그룹으로 지정

 

문제: 인터넷 트래픽이 EC2에 도달하지 않음

 

원인: ALB가 인터넷에 노출되지 않음
인터넷 연결 ALB가 프라이빗 서브넷에만 있으면, 인터넷 사용자는 ALB에 도달할 수 없습니다.
인터넷 → IGW → (라우팅) → ALB → EC2
IGW로 들어온 트래픽은 0.0.0.0/0 → IGW 경로가 있는 서브넷(퍼블릭 서브넷)으로만 갈 수 있음
ALB가 퍼블릭 서브넷에 있어야 인터넷 트래픽이 ALB에 도달하고, 그다음 EC2(프라이빗)로 전달 가능

D. 퍼블릭 서브넷 생성 후 ALB 연결
1. 각 AZ에 퍼블릭 서브넷 생성
    퍼블릭 서브넷 = 경로 테이블에 0.0.0.0/0 → 인터넷 게이트웨이가 있는 서브넷
    인터넷 트래픽이 IGW를 통해 이 서브넷으로 들어올 수 있음
2. ALB를 퍼블릭 서브넷에 연결
    ALB를 각 AZ의 퍼블릭 서브넷에 두면, 인터넷 사용자가 ALB의 퍼블릭 DNS/IP로 접속 가능
    ALB는 같은 VPC의 프라이빗 서브넷에 있는 EC2로 트래픽 전달 (VPC 내부 라우팅으로 기본 가능)
3. 프라이빗 서브넷 경로
    “프라이빗 서브넷에 대한 경로로 퍼블릭 서브넷에 대한 경로 테이블을 업데이트”는, 문맥에 따라 “퍼블릭 서브넷의 경로 테이블에      퍼블릭 구간 정리” 또는 “프라이빗↔퍼블릭 간 필요한 경로 보완” 정도로 이해할 수 있음.
    핵심은 ALB를 퍼블릭 서브넷에 두는 것이라 D의 주된 수정 내용이 맞음.
4. 권장 아키텍처 유지
    EC2는 그대로 프라이빗 서브넷에 두고, ALB만 퍼블릭에 두는 일반적인 패턴과 일치함.

 

Answer: C, E

요구사항
- Amazon RDS for MySQL 사용 중
- 읽기 지연 발생 → 읽기 전용 복제본 추가 예정
- 복제본을 만들기 전에 솔루션 설계자가 해야 할 작업 2가지 선택

C. 원본 DB 인스턴스에서 진행 중인 모든 트랜잭션이 완료되도록 함 
읽기 전용 복제본을 추가/전환하는 시점에 원본에서 장기 실행·진행 중인 트랜잭션이 있으면:
    복제본 생성/동기화가 길어지거나
    일시적으로 불일치·지연이 생길 수 있습니다.
그래서 구현 전에 원본에서 진행 중인 트랜잭션이 완료되도록 하는 것이 좋습니다.
    “구현하기 전에 수행해야 하는 작업”에 C가 포함되는 것이 맞습니다.

E. 백업 보존 기간을 0이 아닌 값으로 설정해 원본 인스턴스에서 자동 백업 활성화 
RDS에서 읽기 복제본을 만들려면 원본 인스턴스에 자동 백업이 활성화되어 있어야 합니다.
백업 보존 기간이 0이면 복제본 생성이 불가하므로, 0이 아닌 값으로 설정하는 것은 필수 선행 작업입니다.
따라서 E도 정답입니다.

 

Answer: D

요구사항
- EC2 한 대에서 S3 데이터를 처리하는 분석 소프트웨어 실행
- 문제: 일부 제출 데이터가 처리되지 않음, CloudWatch에서 EC2 CPU가 거의 100% 지속
- 목표: 성능 개선 + 사용자 부하에 따른 확장

D. SQS + 큐 크기 기반 Auto Scaling
1. 처리되지 않는 작업 방지
    요청을 먼저 Amazon SQS로 보내면, 작업이 큐에 쌓입니다.
    EC2가 바쁘더라도 작업이 버려지지 않고, 인스턴스가 큐에서 꺼내 처리할 때까지 대기합니다.
    “일부 제출된 데이터가 처리되지 않는다”는 문제를 줄일 수 있습니다.
2. 사용자 부하에 따른 확장
     큐 크기(대기열 깊이) 를 CloudWatch 메트릭으로 쓰고, 이 메트릭에 따라 EC2 Auto Scaling을 설정합니다.
    부하가 많으면 큐가 길어지고 → 인스턴스 수 증가, 부하가 줄면 큐가 짧아지고 → 인스턴스 수 감소.
    “사용자 부하에 따라 시스템을 확장” 요구사항을 충족합니다.
3. 성능 개선
    여러 EC2 인스턴스가 큐에서 작업을 가져와 병렬로 처리하므로, 한 인스턴스가 계속 100% CPU인 구조를 피할 수 있습니다.
    부하에 따라 인스턴스 수가 조절되므로 전체 처리량이 늘어납니다.
4. 아키텍처
    클라이언트 → 작업 제출 → SQS
    EC2 워커(소프트웨어 수정) → SQS에서 메시지 읽기 → S3 데이터 처리
    ASG → 큐 크기에 따라 EC2 수 증감

 

Answer: D

요구사항
AWS에서 호스팅되는 미디어 애플리케이션용 공유 스토리지
SMB 클라이언트로 데이터 접근 필요
솔루션은 완전히 관리형(fully managed) 이어야 함

D. Amazon FSx for Windows File Server
1. SMB 지원
    Amazon FSx for Windows File Server는 Windows 네이티브 SMB 파일 공유를 제공합니다.
    SMB 클라이언트가 그대로 파일 시스템에 연결해 사용할 수 있습니다.
2. 완전 관리형
    파일 서버 OS, 패치, 백업, 고가용성 등은 AWS가 관리합니다.
    EC2나 OS를 직접 관리할 필요가 없어 “완전히 관리되어야 한다”는 요구사항을 충족합니다.
3. 공유 스토리지
     여러 애플리케이션 서버가 동일한 FSx 파일 시스템을 SMB로 마운트해 공유 스토리지로 사용할 수 있습니다.
4. 구성
    Windows 파일 서버용 FSx 파일 시스템을 생성하고, 애플리케이션 서버를 해당 파일 시스템(SMB 공유)에 연결하면 됩니다

 

Answer:  D

요구사항
- VPC Flow Logs로 네트워크 트래픽 수집
- 90일 동안 로그를 자주 액세스
- 90일 이후에는 간헐적으로 액세스
- 위 요구사항을 만족하도록 로그 구성을 해야 함

D. S3 대상 + 90일 후 Standard-IA 전환
1. VPC Flow Logs 대상으로 S3 사용
    VPC Flow Logs는 CloudWatch Logs 또는 Amazon S3로만 보낼 수 있습니다. S3를 대상으로 하는 구성이 맞습니다.
2. 90일 동안 자주 액세스
    처음 90일은 S3 Standard에 보관하면 됩니다.
    자주 조회하는 구간에는 Standard가 적합합니다 (저장·조회 비용 구조가 빈번한 액세스에 맞음).
3. 90일 이후 간헐적 액세스
    S3 수명 주기 정책으로 90일이 지난 객체를 S3 Standard-IA로 전환하면 됩니다.
    Standard-IA는 저장 비용이 낮고, 가끔 조회할 때만 소량의 조회 비용이 발생해 “간헐적으로 액세스”하는 패턴에 맞습니다.
    로그는 삭제되지 않고 계속 보관되므로 90일 이후에도 조회 가능합니다.
4. 요구사항 정리
    로그 캡처: S3에 VPC Flow Logs 저장 
    90일간 자주 액세스: 초기에는 Standard 유지 
    이후 간헐적 액세스: 90일 후 Standard-IA로 전환