AWS SAA-C03 Dump 101-150

AWS SAA-C03  Dump 101-150

 

 

Answer: A

요구사항 
- VPC에 퍼블릭·프라이빗 서브넷, IPv4 CIDR 사용
- 고가용성 : 3개 AZ 각각에 퍼블릭 서브넷 1개 + 프라이빗 서브넷 1개
- 인터넷 게이트웨이(IGW) 로 퍼블릭 서브넷의 인터넷 액세스 제공
- 프라이빗 서브넷의 EC2가 소프트웨어 업데이트 등을 위해 인터넷(아웃바운드) 에 접근할 수 있어야 함
즉, “프라이빗 서브넷에서 아웃바운드 인터넷만 허용”하면서 3 AZ 고가용성을 유지하는 구성을 고르는 문제다.

A. 각 AZ의 퍼블릭 서브넷마다 NAT 게이트웨이 1개(총 3개) 생성 → 각 AZ별 프라이빗 라우팅 테이블에서 비 VPC 트래픽(0.0.0.0/0) 을 해당 AZ의 NAT 게이트웨이로 보내기
1. 프라이빗 서브넷의 아웃바운드 인터넷
     프라이빗 서브넷에는 IGW로의 라우트를 두지 않는다.
    NAT 게이트웨이를 퍼블릭 서브넷에 두고, 프라이빗 서브넷의 기본 라우트(0.0.0.0/0) 를 NAT 게이트웨이로 보내면,
    트래픽 흐름: 프라이빗 EC2 → NAT 게이트웨이 → IGW → 인터넷
    따라서 “프라이빗 서브넷에 대한 인터넷 액세스”(아웃바운드)가 활성화된다.
2. 고가용성(3 AZ)
    AZ마다 퍼블릭 서브넷에 NAT 게이트웨이 1개를 두고,
    각 AZ의 프라이빗 서브넷은 같은 AZ의 NAT 게이트웨이만 사용하도록 라우팅하면,
    한 AZ에 장애가 나도 나머지 AZ의 프라이빗 서브넷은 해당 AZ의 NAT로 계속 아웃바운드 가능하다.
    “세 개의 가용 영역” 고가용성 요구를 만족한다.
3. NAT는 퍼블릭 서브넷에
    NAT 게이트웨이는 퍼블릭 서브넷에 두어 IGW로 나갈 수 있게 하는 것이 맞고, A는 “각 AZ의 퍼블릭 서브넷에” NAT를 둔다고 했으므로 올바르다.
정리하면, 프라이빗 아웃바운드 인터넷 + 3 AZ 고가용성을 동시에 만족하는 것이 A다.

 

Answer: A, B

요구사항 
- 온프레미스 데이터 센터를 AWS로 마이그레이션
- SFTP 서버가 NFS 기반 파일 시스템에 데이터 저장
- 200GB 데이터를 옮겨야 함
- 마이그레이션 후 서버는 Amazon EFS를 쓰는 EC2에서 호스팅되어야 함
즉, “온프레미스 NFS/SFTP 데이터 → EFS(및 EC2)” 로 자동 전송을 구현하는 데 필요한 2가지 단계를 고르는 문제다.

A. EFS 파일 시스템과 같은 가용 영역에서 EC2 인스턴스 시작
마이그레이션 대상 환경: SFTP 서버가 EFS를 사용하는 EC2에서 호스팅되어야 함.
EFS와 같은 AZ에서 EC2를 띄우면 지연·비용 측면에서 유리하고, EFS 마운트 후 SFTP 서버를 이 EC2에 구성하는 단계로 적합함.
따라서 “이 작업(마이그레이션)”을 위한 필수 단계 2개 중 하나로 A가 포함됨.
B. 온프레미스 데이터 센터에 AWS DataSync 에이전트 설치
온프레미스 NFS에 있는 200GB 데이터를 자동으로 옮기려면 DataSync를 쓰는 것이 맞음.
DataSync로 온프레미스 스토리지를 연동하려면 에이전트 설치가 필요하므로, 자동화를 위한 단계로 B가 정답에 포함됨.

C(X) : EBS 가 아니라 EFS 가 NFS 지원.
D(X) : 수동으로 할 필요가 없이 DataSync 같은 대안을 사용하면 됨.
E(X) : 온프레미스 SFTP 에 좀 더 적합한 건 DataSync 보다 TransferFamily가 더 적합해보입니다.

 

Answer: A

요구사항 
- AWS Glue ETL 작업이 매일 같은 시간에 실행
- S3 버킷의 XML 데이터 처리
- 매일 S3에 새 데이터만 추가됨
- 문제 : Glue가 매 실행마다 전체 데이터를 처리함 (이미 처리한 오래된 데이터까지 재처리)
- 목표 : Glue가 오래된 데이터를 재처리하지 않도록 함
즉, “이미 처리한 데이터는 건너뛰고, 새 데이터만 처리”하도록 하는 방법을 고르는 문제다.

A. 작업 북마크(Job Bookmarks) 를 사용하도록 작업을 편집
1. 작업 북마크의 역할
    AWS Glue Job Bookmarks는 어떤 데이터(파일/파티션) 를 이미 처리했는지 상태를 저장한다.
    다음 실행 시 저장된 북마크 이후의 새로 추가된 데이터만 읽어서 처리한다.
    따라서 “오래된 데이터를 재처리하지 못하도록” 하는 요구를 작업 북마크로 충족할 수 있다.
2. 구현 방식
    Glue 작업 설정에서 Job bookmark 를 활성화하고,
    데이터 소스가 북마크를 지원하도록 되어 있으면(예: S3, 일부 커넥터) 자동으로 증분 처리가 된다.
    “작업을 편집”해서 북마크만 켜면 되므로, 기존 작업 구조를 크게 바꾸지 않아도 된다.
3. 데이터 유지
    오래된 데이터를 삭제하지 않고 처리 대상에서만 제외하므로, 원본 데이터 보존과 재처리 방지 둘 다 만족한다.
    정리하면, 오래된 데이터 재처리 방지 = Glue Job Bookmarks 사용이 정답이다.

Answer: A, C

요구사항 
- 고가용성 웹사이트 인프라
- Windows 웹 서버가 EC2에서 동작
- 수천 개 IP에서 오는 대규모 DDoS 공격을 완화해야 함
- 다운타임 불가
즉, “대규모 DDoS 완화” + “다운타임 없음”을 만족하는 2가지 조치를 고르는 문제다.

A. AWS Shield Advanced를 사용해 DDoS 공격을 차단
AWS Shield Advanced는 Layer 3/4(네트워크/전송) 및 Layer 7(애플리케이션) DDoS 공격을 완화하는 관리형 서비스다.
수천 개 IP에서 오는 대규모 볼류메트릭/다중 소스 공격에 대응할 수 있고, 24/7 DRT 지원·비용 보호 등이 포함된다.
“수천 개의 IP 주소에서 시작되는 대규모 DDoS 공격을 완화” 요구를 직접 충족하는 조치다.
C. 정적·동적 콘텐츠 모두에 Amazon CloudFront를 사용하도록 웹사이트 구성
CloudFront를 웹사이트 앞단에 두면, 트래픽이 엣지에서 먼저 처리되고, 오리진(EC2)은 필요한 요청만 받는다.
CloudFront에는 AWS Shield Standard가 포함되어 일반적인 L3/L4 DDoS에 대한 기본 완화가 적용되고, Shield Advanced(A) 와 함께 쓰면 대규모 공격 완화가 강화된다.
엣지에서 트래픽을 흡수·필터링해 EC2 부하와 다운타임 위험을 줄이고, 고가용성에도 도움이 된다.
“정적 및 동적 콘텐츠 모두” CloudFront 사용 = 전체 웹 트래픽을 CDN 경유로 보내는 구성으로, DDoS 완화와 HA 모두에 유리하다.
A + C 조합: Shield Advanced로 DDoS 차단·완화, CloudFront로 엣지 보호·고가용성 확보.

 

Answer: D

요구사항 
- 서버리스 워크로드 배포
- EventBridge(CloudWatch Events) 규칙이 Lambda 함수를 호출
- 최소 권한 원칙으로 Lambda를 실행하는 데 사용할 권한 구성
즉, “EventBridge가 Lambda를 호출할 수 있게 하되, 필요한 권한만 주는” 구성을 고르는 문제다.

 

D. lambda:InvokeFunction을 작업으로, Service: events.amazonaws.com을 보안 주체로 사용해 리소스 기반 정책을 함수에 추가
1. EventBridge가 Lambda를 호출하려면
    Lambda는 리소스 기반 정책(Resource-based policy) 으로 “누가 이 함수를 호출할 수 있는지”를 제어한다.
    EventBridge가 Lambda를 호출하려면, Lambda 함수 쪽에 “events.amazonaws.com(EventBridge)이 InvokeFunction 할 수 있다”는 리소스 기반 정책이 있어야 한다.
2. 최소 권한
    작업: lambda:InvokeFunction 만 허용 → 호출에 필요한 권한만 부여.
    보안 주체: events.amazonaws.com 만 허용 → EventBridge만 호출 가능, 다른 서비스나 계정은 호출 불가.
    따라서 “최소 권한 원칙”을 만족한다.
3. 실행 역할 vs 리소스 기반 정책
    “Lambda를 실행하는 데 사용할 권한”이라고 했지만, 문맥상 EventBridge가 함수를 호출하는 권한을 묻는 것이므로, 호출 권한을 주는 리소스 기반 정책이 맞다.
    D는 “리소스 기반 정책을 함수에 추가”라고 했으므로, EventBridge → Lambda 호출을 허용하는 올바른 방법이다.
정리하면, EventBridge 호출 허용 + 최소 권한을 동시에 만족하는 것은 D다.

 

Answer: B

요구사항 
- Amazon S3에 기밀 데이터 저장
- 규정 준수 : 미사용(저장) 데이터 암호화 필요
- 암호화 키 사용이 감사 목적으로 기록되어야 함
- 키는 매년 순환해야 함
- 운영상 가장 효율적인 솔루션
즉, “저장 데이터 암호화 + 키 사용 감사 로그 + 매년 키 순환 + 최소 운영”을 만족하는 구성을 고르는 문제다.

D. 자동 순환이 있는 AWS KMS 키(SSE-KMS) 를 사용한 서버 측 암호화
1. 미사용 데이터 암호화
    SSE-KMS는 S3 객체를 KMS 키로 암호화해 저장하므로, “미사용(저장) 데이터 암호화” 요구를 충족한다.
2. 키 사용 감사 기록
    KMS는 CloudTrail과 연동되어, 키에 대한 Encrypt/Decrypt/GenerateDataKey 등 모든 사용이 자동으로 로그된다.
    “암호화 키 사용을 감사 목적으로 기록” 요구를 SSE-KMS가 충족한다.
3. 키 매년 순환
    KMS 고객 관리형 키에서 자동 키 순환을 켜면, AWS가 매년 새 백업 키를 만들고 기존 데이터는 기존 키로 복호화·새 데이터는 새 키로 암호화하는 방식으로 순환이 이뤄진다.
    “키는 매년 순환”을 자동으로 만족한다.
4. 운영상 가장 효율적
    키 순환·암호화·감사 로깅을 관리형(KMS + CloudTrail) 으로 처리하므로, 수동 순환(C)이나 고객 제공 키(A)보다 운영 부담이 적다.
정리하면, 암호화 + 키 사용 감사 + 매년 순환 + 최소 운영을 한 번에 만족하는 것이 D다.

C. Amazon S3 관리형 키(SSE-S3)를 사용한 서버 측 암호화
SSE-S3는 S3가 키를 관리하며, 키 사용이 CloudTrail에 KMS처럼 상세히 기록되지 않는다.
“암호화 키 사용을 감사 목적으로 기록”을 감사용 키 사용 로그 수준으로 충족하려면 KMS(SSE-KMS) 가 필요하다.
S3 관리형 키는 “매년 순환”을 고객이 제어하는 구조도 아니어서, D가 더 요구사항에 맞다.

 

Answer: B

요구사항 
- 다층 아키텍처로 위치 추적
- 피크 시간 대응
- 기존 분석 플랫폼에서 사용할 데이터
- REST API로 데이터 접근 가능해야 함

B. Amazon API Gateway와 AWS Lambda 사용
1. REST API 제공
    API Gateway: REST API를 만들고 관리하는 서비스.
    Lambda: 요청 처리·비즈니스 로직(위치 저장/조회 등) 구현.
    두 서비스를 붙이면 “REST API로 데이터 접근” 요구를 직접 충족합니다.
2. 다층 구조에 잘 맞음
    API 계층: API Gateway (엔드포인트, 인증, 스로틀링)
    애플리케이션 계층: Lambda (저장/조회 로직)
    데이터 계층: Lambda가 DynamoDB, RDS 등에 연결해 위치 데이터 저장·조회
    역할이 나뉘어 있어 “다층 아키텍처”에 적합합니다.
3. 피크 시간 대응
    API Gateway와 Lambda 모두 자동 확장.
    트래픽이 몰려도 별도 용량 설계 없이 대응 가능합니다.
4. 기존 분석 플랫폼 연동
    Lambda에서 위치 데이터를 S3, Redshift 등으로 전달하거나, DB에 넣어두고 분석 플랫폼이 조회하도록 구성할 수 있습니다.
“REST API로 접근”과 “분석 플랫폼에서 사용”을 동시에 만족시키기 좋습니다.

 

Answer: D

요구사항 
- RDS에 자동차 목록 저장
- 자동차 판매 시: 웹사이트에서 목록 제거 + 여러 대상 시스템으로 데이터 전송
이 흐름을 지원하는 아키텍처 선택

D. RDS 이벤트 알림 → SNS → 여러 SQS 대기열 → Lambda로 대상 업데이트
1. 여러 대상으로의 팬아웃
    “데이터를 여러 대상 시스템으로 보내야 한다”는 요구가 있음.
    SNS 1개 주제 → 여러 SQS 대기열 구조가 “한 번 발생한 이벤트를 여러 시스템이 각자 소비”하는 표준 패턴입니다.
    보기 D가 이 패턴을 정확히 설명합니다.
    “SNS 주제를 여러 SQS 대기열로 보냅니다” → 1:N 팬아웃.
2. 역할 분리
    SNS: 이벤트(판매 완료) 발행 및 다중 구독자에게 전달
    SQS: 각 대상별로 대기열을 두어 버퍼링·재시도·독립 처리
    Lambda: 각 대기열에서 메시지를 꺼내 해당 대상 시스템을 업데이트
3. 다중 대상 확장성
    대상이 늘어나면 SNS에 SQS 구독만 추가하면 되고, Lambda는 대상별로 나누어 두면 됩니다.
    A, B는 단일 SQS만 언급해 “여러 대상”을 명시적으로 지원하는 구조가 아닙니다.
4. 표현상 정답으로 볼 수 있는 이유
    시험에서는 “RDS 이벤트 알림”을 “RDS/애플리케이션에서 발생하는 판매 이벤트 알림” 정도로 넓게 보는 경우가 있습니다.
    실제 구현 시에는 “애플리케이션이 RDS에서 목록 제거 후 SNS로 메시지 발행”하는 방식이 일반적입니다.
보기 중에서는 SNS → 여러 SQS → Lambda 구조를 정확히 말한 것이 D이므로 D를 정답으로 선택하는 것이 타당합니다.

  [목록 제거 / RDS 업데이트]
        ↓
  RDS 이벤트 알림 (또는 앱이 SNS 발행)
        ↓
   Amazon SNS 주제 (1개)
        ↓
   ┌────┼────┬────┐
   ↓    ↓    ↓    ↓
 SQS  SQS  SQS  SQS  (대상별 대기열)
   ↓    ↓    ↓    ↓
 Lambda → 각 대상 시스템 업데이트

 

Answer: D

요구사항 
- Amazon S3에 데이터 저장
- 데이터가 변경되지 않도록 (불변성)
- 새 객체는 “회사가 수정하기로 결정할 때까지” 기간 제한 없이 변경 불가
- 객체 삭제는 회사 AWS 계정 내 특정 사용자만 가능

 

D. S3 객체 잠금 버킷 + 버전 관리 + 법적 보존(Legal Hold) + 삭제 권한 사용자에게 PutObjectLegalHold
1. “기간 제한 없이, 회사가 결정할 때까지”
    법적 보존(Legal Hold)은 기간이 없고, 보존을 해제할 때까지 객체를 삭제·덮어쓸 수 없습니다.
    “일정하지 않은 시간 동안 … 회사가 객체를 수정하기로 결정할 때까지”라는 요구와 정확히 맞습니다.
    회사가 수정·삭제를 결정하면 → Legal Hold 해제 → 그다음 삭제/수정 가능.
2. 특정 사용자만 삭제 가능
    Legal Hold가 걸린 객체는 Legal Hold를 해제해야 삭제할 수 있습니다.
    Legal Hold 해제에는 s3:PutObjectLegalHold 권한이 필요합니다.
    따라서 삭제가 허용된 사용자에게만 s3:PutObjectLegalHold(및 s3:DeleteObject 등)를 부여하면, “특정 사용자만 객체를 삭제할 수 있다”는 요구를 만족합니다.
3. S3 Object Lock + 버전 관리
    S3 Object Lock 활성화 버킷에서만 Legal Hold/보존 기간을 사용할 수 있고, Object Lock 사용 시 버전 관리는 필수입니다.
    D는 “S3 객체 잠금 버킷 생성 + 버전 관리 활성화 + 객체에 법적 보존”을 모두 포함하므로, 불변성과 삭제 제어를 함께 충족합니다

 

Answer: C, D

요구사항 
현재: 사용자 → EC2(웹 서버) → 이미지 수신·리사이즈 → S3 저장
문제: 업로드 요청이 느림
목표: 결합도 감소, 웹사이트 성능 개선

C. 미리 서명된 URL로 브라우저에서 S3로 직접 업로드
업로드 경로를 사용자 → EC2 → S3에서 사용자 → S3로 변경합니다.
EC2는 presigned URL만 발급하고, 실제 바이너리는 받지 않습니다.
효과
업로드 속도: EC2를 거치지 않아 대용량 업로드가 빨라집니다.
결합도: 웹 서버가 업로드 트래픽·디스크 I/O에서 분리됩니다.
확장성: 업로드 부하는 S3로만 가서 EC2 스케일 부담이 줄어듭니다.
D. S3 이벤트 알림으로 업로드 시 Lambda 호출 → Lambda에서 이미지 리사이즈
원본(또는 업로드된 이미지)이 S3에 들어오면 S3 이벤트로 Lambda가 실행되고, Lambda가 리사이즈 후 S3에 다시 저장하는 구조입니다.
효과
결합도: 리사이즈 로직이 EC2에서 분리되어 Lambda로 이동합니다.
웹 서버 성능: EC2가 리사이즈(CPU/메모리) 작업을 하지 않아 응답이 가벼워집니다.
운영: 리사이즈는 이벤트 기반으로 자동 처리됩니다.

[사용자] --(1) presigned URL 요청--> [EC2 웹서버]
                <--(2) presigned URL 반환--
[사용자] --------(3) 이미지 직접 업로드 --------> [S3]
                                                                                   |
                                                                                   v (4) S3 이벤트
                                                                             [Lambda] 리사이즈
                                                                                  |
                                                                                  v (5) 리사이즈 이미지 저장
                                                                                 [S3]

 

Answer: D

요구사항 
현재: EC2 ActiveMQ → EC2 소비자 → EC2 MySQL (전부 단일/수동 구성)
목표: 가장 높은 가용성 + 낮은 운영 복잡도

D. Amazon MQ(활성/대기) + 2 AZ에 걸친 소비자 Auto Scaling 그룹 + RDS MySQL Multi-AZ
1. 소비자 계층 가용성·운영 복잡도
    D: 소비자를 2개 AZ에 걸친 Auto Scaling 그룹으로 구성
    → AZ/인스턴스 장애 시 ASG가 대체 인스턴스 기동, 트래픽을 여러 AZ에 분산
    C: “다른 가용 영역에 소비자 EC2 인스턴스를 추가”만 언급
    → 고정된 인스턴스 수, ASG 없음 → 장애 시 자동 복구·분산이 약함
“가장 높은 가용성”을 위해서는 소비자도 ASG + Multi-AZ인 D가 맞습니다.
2. 메시지 브로커
    A: EC2에서 직접 운영하는 ActiveMQ → 장애 조치·패치 등 운영 부담 큼
    B·C·D: Amazon MQ (관리형, 활성/대기 2 AZ) → 고가용성 + 낮은 운영 복잡도
3. 데이터베이스
    A·B: “다른 가용 영역에 MySQL 복제” → 자체 구축 복제 → 장애 조치·동기화 등 운영 복잡
    C·D: RDS MySQL Multi-AZ → 장애 시 자동 페일오버, 관리형 → 낮은 운영 복잡도
4. 요구사항 매칭
    고가용성: 메시지 브로커(Amazon MQ 활성/대기), 소비자(ASG + 2 AZ), DB(RDS Multi-AZ) 모두 고가용 구성
    낮은 운영 복잡도: Amazon MQ·RDS는 관리형, 소비자는 ASG가 인스턴스 생명 주기·복구 담당

 

Answer: 

요구사항 
현재: 온프레미스에서 컨테이너화된 웹 앱 실행, 요청 증가로 수용 불가
목표:
최소한의 코드 변경
최소한의 개발 노력
최소한의 운영 오버헤드
증가하는 요청 처리

A. Amazon ECS + AWS Fargate + Service Auto Scaling + Application Load Balancer
1. 최소 코드 변경·최소 개발 노력
    이미 컨테이너 이미지가 있음 → 그대로 ECS에서 실행하면 됨.
    코드/언어를 바꾸거나 웹 앱을 다시 작성할 필요 없이, 기존 컨테이너를 배포 대상만 AWS로 바꾸는 수준이면 충분함.
    ECS는 컨테이너 표준(Docker 등)을 그대로 사용하므로 이전 비용이 가장 적음.
2. 최소 운영 오버헤드
    Fargate: 서버(EC2)를 직접 관리할 필요 없음. 컨테이너만 정의하면 됨.
    Service Auto Scaling: 트래픽 증가 시 태스크 수 자동 증가, 감소 시 축소 → 수동 용량 관리 최소화.
    ALB: 트래픽 분산·헬스체크는 ALB가 담당.
    따라서 “최소한의 운영 오버헤드” 조건을 잘 충족함.
3. 요청 증가 대응
    ALB로 들어오는 요청을 여러 ECS 태스크에 분산.
    Service Auto Scaling으로 부하에 따라 태스크 수가 늘어나 증가하는 요청 수를 처리할 수 있음.
4. 다른 보기와의 차이
    B: EC2 2대 고정 → 확장성·자동 복구 부족, EC2 관리(패치·모니터링 등)로 운영 부담 증가.
    C: Lambda + 새 코드 → 컨테이너 앱을 함수 단위로 다시 작성해야 하므로 코드 변경·개발 노력이 큼. “최소 변경·최소 개발”에 맞지 않음.
     D: ParallelCluster/HPC는 웹 요청 처리용이 아니라 대규모 연산용. 웹 앱에는 부적합하고 운영도 복잡함.

 

Answer: C

요구사항 
데이터: 50TB, 온프레미스 → AWS
변환: 온프레미스 사용자 지정 앱이 매주 데이터 변환 실행 → AWS에서 계속 실행되도록 구성
제약: 데이터 센터에 추가 워크로드용 네트워크 대역폭 없음
목표: 데이터 전송 + AWS에서 변환 실행, 최소 운영 오버헤드

C. AWS Snowball Edge Storage Optimized로 데이터 복사 후, AWS Glue로 사용자 지정 변환 작업 구성
1. 네트워크 대역폭 없음 → 물리적 전송
    50TB를 네트워크로 보내는 방식(DataSync 등)은 대역폭 제약으로 비현실적.
    Snowball Edge Storage Optimized는 디스크에 복사 후 물리 배송으로 데이터를 옮기므로 네트워크를 쓰지 않음 → 요구사항 충족.
2. 변환 작업을 AWS에서 실행
    데이터는 Snowball으로 S3 등 AWS 스토리지로 들어온 뒤, AWS Glue로 변환 작업 구성.
    Glue는 AWS가 관리하는 서버리스 ETL로, “사용자 지정 변환”을 스크립트/잡으로 구현 가능 → AWS 클라우드에서 계속 실행하는 요구 충족.
3. 최소 운영 오버헤드
    Snowball: 주문·복사·반송만 하면 되고, 데이터 적재는 AWS가 처리.
    Glue: 서버 관리 없이 잡만 정의하면 됨 → EC2에 앱 직접 올리는 것보다 운영 부담이 적음.
4. 50TB 규모
    Snowball Edge Storage Optimized는 대용량(약 80TB급)에 맞고, Snowcone(8TB급)보다 50TB에 적합함.
AWS Glue는 인프라 관리가 필요 없는 서버리스(Serverless) 데이터 통합 및 ETL(추출, 변환, 적재) 서비스입니다.

[온프레미스 50TB]
       ↓ (로컬 복사, 네트워크 미사용)
Snowball Edge Storage Optimized
       ↓ (물리 반송)
   Amazon S3 (등)
       ↓
   AWS Glue (사용자 지정 변환 작업, 매주 실행 등)

 

Answer: C

요구사항 
현재: 단일 EC2 + DynamoDB(메타데이터), 사진 업로드·프레임 추가
변화: 사용자 증가, 동시 접속자가 시간·요일에 따라 크게 변동
목표: 증가·변동하는 사용자 수에 맞춰 확장 가능한지 확인하고 대응

C. Lambda로 사진 처리, S3에 사진 저장, DynamoDB로 메타데이터 유지
1. 변동 트래픽에 대한 자동 확장
    Lambda: 동시 요청이 늘어나면 자동으로 더 많은 실행이 뜸. “시간·요일에 따라 크게 달라지는 동시 접속자”에 맞춰 서버 수를 고정하지 않고 대응 가능.
    EC2 3대로 고정하는 방식(D)은 피크 때는 부족, 한가할 때는 과잉이 되어 “변동 트래픽”에는 맞지 않음.
2. 저장소 역할 구분
    사진(대용량 바이너리) → S3
    용량·요청 수에 맞춰 확장, 객체 스토리지에 적합.
    메타데이터(프레임 종류, 사용자 정보 등) → DynamoDB
    이미 사용 중인 구조 유지, 키-값 조회에 적합하고 자동 확장됨.
    C는 “사진은 S3, 메타데이터는 DynamoDB”로 역할이 명확함.
3. 사진 처리
    Lambda에서 업로드된 이미지를 받아 프레임 추가 등 처리 후 S3에 저장하는 구성은 일반적인 패턴이며, Lambda가 동시 처리량에 맞춰 스케일함.

 

Answer: C

요구사항 
현재: EC2(퍼블릭 서브넷) → 인터넷 → S3
새 요구: S3로 가는 파일 전송 트래픽이 인터넷을 거치지 않고, 비공개 경로만 사용

C. EC2를 프라이빗 서브넷으로 이동 + S3용 VPC 엔드포인트 생성 + 프라이빗 서브넷 라우팅 테이블에 엔드포인트 연결
1. 비공개 경로로 S3 접근
    S3용 VPC Gateway 엔드포인트를 쓰면, VPC → S3 트래픽이 AWS 백본만 사용하고 공용 인터넷을 지나지 않음.
    라우팅 테이블에 S3 접두사(prefix)를 해당 Gateway 엔드포인트로 보내면, EC2에서 나간 S3 요청이 자동으로 그 엔드포인트로 가서 S3까지 비공개로 전달됨.
2. EC2를 프라이빗 서브넷으로 이동
    퍼블릭 서브넷에 두면 기본적으로 IGW를 통해 인터넷으로 나갈 수 있어, 실수나 설정에 따라 S3 트래픽이 인터넷으로 나갈 여지가 있음.
    프라이빗 서브넷으로 옮기면 IGW로의 기본 경로가 없고, S3는 오직 VPC 엔드포인트로만 가도록 라우팅할 수 있어 “인터넷 미경유”를 명확히 만족함.
3. 구조 요약
    EC2(프라이빗) → (같은 VPC 내) S3 Gateway 엔드포인트 → S3
    인터넷 구간 없음 → 규정 요구사항(비공개 경로) 충족.

Direct Connect는 온프레미스 ↔ AWS 전용

[EC2] (프라이빗 서브넷)
   |
   | (같은 VPC, 라우팅: S3 접두사 → Gateway 엔드포인트)
   v
[S3 VPC Gateway 엔드포인트]  --------(AWS 내부 네트워크)--------> [Amazon S3]

 

Answer: A, D

요구사항
현재: 널리 쓰는 CMS 사용 → 패치·유지보수 부담
재설계: 새 솔루션으로 전환
특성: 연 4회 업데이트, 동적 콘텐츠 불필요 → 사실상 정적 웹사이트
목표: 높은 확장성, 향상된 보안, 최소한의 운영 오버헤드

A. 웹사이트 앞에 Amazon CloudFront 구성 + HTTPS 사용
S3를 오리진으로 두고 CloudFront로 전 세계 엣지에서 캐시·전송.
HTTPS로 암호화·신원 보장을 제공합니다.
효과
확장성: CDN으로 글로벌 트래픽 분산, 오리진(S3) 부하 감소.
보안: HTTPS로 전송 암호화, DDoS 완화(Shield 연동), 필요 시 WAF 연동 가능.
운영: CloudFront는 관리형 서비스로 운영 부담이 적음.

D. 새 웹사이트 + S3 버킷 생성, 정적 웹사이트 호스팅으로 S3에 배포
CMS·웹 서버(EC2) 없이 정적 파일만 S3에 올려 제공하는 구조입니다.
“동적 콘텐츠 불필요”, “연 4회 업데이트”에 맞는 최소 구성입니다.
효과
운영 최소화: 서버·OS·CMS 패치 없음, 연 4회만 S3에 파일 업로드하면 됨.
확장성: S3가 트래픽·용량 자동 확장.
보안: 퍼블릭 읽기는 S3 버킷 정책으로 제어, CloudFront(A)와 함께 사용하면 추가 보안·HTTPS 적용 가능.

 

Answer: A

요구사항 
현재: 애플리케이션 로그가 CloudWatch Logs 로그 그룹에 저장됨
새 정책: 모든 애플리케이션 로그를 거의 실시간으로 Amazon OpenSearch Service에 저장
목표: 최소한의 운영 오버헤드로 위 요구 충족

A. CloudWatch Logs 구독을 OpenSearch로 스트리밍
1. 네이티브 연동
    CloudWatch Logs 구독으로 OpenSearch Service를 직접 대상으로 지정할 수 있음.
    Firehose, Lambda, Kinesis Data Streams 같은 중간 구성 없이 로그 그룹 → OpenSearch 한 번에 연결 가능.
2. 최소한의 운영 오버헤드
    AWS가 제공하는 기본 연동이므로, Firehose 전송 스트림·Lambda 코드·에이전트 등을 따로 만들 필요가 없음.
    로그 그룹에 구독만 구성하면 되므로 운영 부담이 가장 적음.
3. 거의 실시간
    문서대로 “실시간에 가깝게” OpenSearch 클러스터로 스트리밍되므로 near real-time 요구를 충족함.

Amazon CloudWatch Logs는 AWS 리소스, 애플리케이션 및 시스템에서 발생하는 로그 데이터를 중앙 집중식으로 수집, 모니터링 및 저장하는 서비스

C (Firehose): CloudWatch Logs → Firehose → OpenSearch 로, 전송 스트림·버퍼·대상 설정 등 추가 리소스를 구성해야 함. 동작은 가능하지만 A보다 구성·운영이 많음.
A: 로그 그룹 구독만으로 OpenSearch로 직접 스트리밍하므로 최소 운영 조건에 더 잘 맞음.

 

Answer: 

요구사항 
규모: 약 900TB 텍스트 문서 저장소
환경: 여러 가용 영역의 EC2에서 동작하는 웹 앱이 접근
요구: 스토리지가 수요에 맞춰 확장 가능해야 함
제약: 전체 비용에 대한 우려 → 가장 비용 효율적인 스토리지 선택

D. Amazon S3
1. 900TB 규모·확장성
    S3는 객체 스토리지로, 용량이 사실상 무제한에 가깝고 용량 계획 없이 확장 가능함.
    900TB도 S3에 적합한 규모이며, 트래픽이 많아져도 스토리지 측면에서 확장 이슈가 없음.
2. 다중 AZ·내구성
    S3 Standard는 리전 내 여러 AZ에 자동 복제되어 내구성·가용성을 제공함.
    여러 AZ의 EC2에서 동일 버킷에 접근할 수 있어, “여러 가용 영역의 EC2” 요구와 맞음.
3. 비용 효율
    S3: 대략 $0.023/GB/월 수준(리전에 따라 다름) → 900TB 기준 월 수만 달러대.
    EFS: 대략 $0.30/GB/월 수준 → 900TB면 월 수십만 달러대로 훨씬 비쌈.
    900TB 급 대용량 문서 저장에는 S3가 EFS·EBS보다 훨씬 저렴함.
4. 웹 앱 연동
    EC2 웹 앱이 S3 API(SDK) 또는 Presigned URL로 문서를 읽기/쓰기하면 됨. 텍스트 문서 제공·다운로드에 적합함.

 

Answer: B

요구사항 
대상: us-east-1, ap-southeast-2의 API Gateway REST API (로열티 클럽)
위협: SQL 인젝션, 교차 사이트 스크립팅(XSS)
범위: 여러 계정에서 이 API들을 보호
목표: 최소한의 관리 노력으로 위 요구 충족

B. 두 리전에 AWS Firewall Manager 설정 + AWS WAF 규칙을 중앙에서 구성
1. SQL 인젝션·XSS 대응
    이 두 가지는 애플리케이션 계층(L7) 공격이므로 AWS WAF로 대응함.
    WAF 관리형 규칙 그룹(AWS Managed Rules – SQLi, Known Bad Inputs 등)으로 SQL 인젝션·XSS를 차단할 수 있음.
    Firewall Manager는 WAF 정책을 중앙에서 정의하고, 그 정책 안에 이런 WAF 규칙을 넣어 여러 계정/리전에 배포하는 역할을 함.
2. 여러 계정 + 최소 관리 노력
    “여러 계정에서 이러한 API Gateway … API를 보호” → 계정마다, 리전마다 WAF를 따로 설정하면 관리 부담이 큼.
    Firewall Manager는 다중 계정·다중 리전에 대해 WAF 정책을 한 번 정의하고, 조직/계정 단위로 자동 적용하는 서비스임.
    따라서 “최소한의 관리 노력” 조건을 만족하려면 B(Firewall Manager로 WAF 규칙 중앙 구성)가 적합함.
3. 두 리전
    API가 us-east-1, ap-southeast-2에 있으므로, Firewall Manager 정책을 두 리전 모두 대상으로 하면 각 리전의 API Gateway 단계에 Web ACL이 연결됨.
4. A와의 차이
    A: 각 리전에 WAF를 직접 설정하고 Web ACL을 API 단계에 연결. 단일 계정이면 가능하지만, 여러 계정이면 계정·리전마다 반복 설정이 필요해 관리 노력이 커짐.
    B: Firewall Manager로 한 곳에서 WAF 규칙(Web ACL 정책)을 정의하고, 여러 계정·두 리전에 일괄 적용 → 관리 노력 최소화.

 

Answer: B

요구사항 
us-west-2: NLB 1개 → EC2 3대
eu-west-1: NLB 1개 → EC2 3대 (새로 추가)
사용자: 미국·유럽 중심
목표: 모든 EC2(6대)로 트래픽을 라우팅하면서 성능·가용성 개선
제약: 이미 NLB 2개가 구성되어 있음

B. AWS Global Accelerator 표준 액셀러레이터 + us-west-2·eu-west-1 엔드포인트 그룹 + 두 NLB를 엔드포인트로 추가
1. 기존 NLB 그대로 사용
    Global Accelerator는 NLB를 엔드포인트로 직접 등록할 수 있음.
    NLB를 ALB로 바꾸거나, EC2에 EIP를 붙일 필요 없이 현재 2개 NLB 위에 GA만 붙이면 됨.
2. 모든 EC2로 트래픽 분산
    엔드포인트 그룹 2개: us-west-2(해당 NLB), eu-west-1(해당 NLB).
    각 NLB 뒤에 EC2 3대씩 있으므로, GA → NLB → EC2 흐름으로 6대 EC2 모두 트래픽을 받을 수 있음.
3. 성능·가용성
    Anycast: 사용자는 가까운 GA 엣지로 접속 → AWS 백본으로 해당 리전 NLB까지 전달.
    헬스 기반 라우팅: 한 리전/NLB 장애 시 다른 리전 NLB로 자동 전환.
    미국 사용자 → us-west-2 NLB, 유럽 사용자 → eu-west-1 NLB 쪽으로 자연스럽게 흐르도록 구성 가능.
4. CloudFront·Route 53 조합과의 차이
    A·D는 CloudFront + Route 53을 오리진으로 쓰는 구조.
    CloudFront 오리진은 HTTP(S) 용이고, 오리진으로 “Route 53 레코드”를 쓰면 해결되는 IP가 한쪽일 수 있어, 지리/지연 기반 으로 두 NLB를 골고루 쓰기 어렵고 구성이 복잡해짐.
GA(Global Accelerator)는 L4(TCP/UDP) 에서 두 NLB를 엔드포인트로 직접 묶고, 한 쌍의 Anycast IP로 들어온 트래픽을 두 리전으로 나누는 용도에 맞음.

 

          [미국·유럽 사용자]
                      ↓
AWS Global Accelerator (Anycast IP)
                      ↓
  ┌─────┴─────┐
  ↓                                           ↓
us-west-2                      eu-west-1
엔드포인트                        엔드포인트
  ↓                                           ↓
 NLB 1                                 NLB 2
  ↓                                           ↓
EC2×3                                 EC2×3  → 모든 6대 EC2로 트래픽 전달

 

Answer: A

요구사항 
현재: 다중 AZ 암호화되지 않은 RDS DB 인스턴스, 일일 스냅샷
목표: 앞으로 DB와 스냅샷이 항상 암호화되도록 함
제약: 기존 RDS 인스턴스에는 생성 후 암호화 설정을 켤 수 없음

A. 최신 DB 스냅샷 사본을 암호화한 뒤, 그 스냅샷을 복원해 기존 DB 인스턴스를 교체
1. RDS 암호화 제약
    이미 만들어진 암호화되지 않은 RDS 인스턴스에는 나중에 암호화를 켤 수 없음.
    암호화된 DB를 쓰려면 암호화된 스냅샷에서 새 인스턴스를 복원해야 함.
2. 올바른 절차 (A안)
    최신 스냅샷의 사본을 만들 때 암호화 활성화
    → RDS “스냅샷 복사” 시 암호화 옵션을 켜고 KMS 키를 지정하면, 암호화된 스냅샷이 생성됨.
        그 암호화된 스냅샷을 복원
    → 복원 시 새 RDS 인스턴스가 만들어지며, 이 인스턴스는 암호화된 상태.
        기존 인스턴스 교체
    → 애플리케이션을 새(암호화된) 인스턴스로 옮기고, 기존(암호화 안 된) 인스턴스는 제거.
3. “앞으로 항상 암호화” 충족
    새 인스턴스가 암호화되어 있으므로, 이 인스턴스에서 찍는 이후 모든 스냅샷도 자동으로 암호화됨.
따라서 “데이터베이스와 스냅샷이 앞으로 항상 암호화되도록” 하는 요구를 만족함.

 

Answer: B

요구사항
목표: 개발자가 애플리케이션 데이터를 암호화할 수 있도록 확장 가능한 키 관리 인프라 구축
제약: 운영 부담을 줄이는 방향으로 설계

B. AWS Key Management Service(AWS KMS)를 사용하여 암호화 키를 보호
1. 키 관리 인프라 제공
    KMS는 암호화 키의 생성·저장·회전·사용을 AWS가 관리하는 관리형 키 관리 서비스입니다.
    개발자는 KMS API로 데이터 암·복호화만 하면 되고, 키 저장·HSM·가용성은 AWS가 담당합니다.
2. 확장성
    키 수·요청량이 늘어나도 용량을 미리 준비할 필요 없이 사용할 수 있어, “확장 가능한 키 관리 인프라”에 맞습니다.
3. 운영 부담 감소
    키 보관·하드웨어(HSM)·자동 회전·백업을 AWS가 처리하므로, 운영 부담을 줄이기 위해 KMS 도입이 적합합니다.
    CloudTrail과 연동해 키 사용 이력을 감사할 수 있어, 별도 로깅 인프라 부담도 줄어듭니다.
4. 개발자 지원
    S3, EBS, RDS, Lambda 등 여러 서비스와 통합되어, 개발자가 애플리케이션 데이터 암호화를 쉽게 적용할 수 있습니다.

 

Answer: D

요구사항
현재: EC2 2대에서 동적 웹 앱 실행, 각 인스턴스에서 SSL 종료 (자체 인증서)
문제: 트래픽 증가로 SSL 암·복호화 때문에 웹 서버 CPU가 한계에 도달
목표: 애플리케이션 성능 개선

D. SSL 인증서를 ACM으로 가져온 뒤, ACM 인증서를 쓰는 HTTPS 리스너가 있는 Application Load Balancer 생성
1. SSL 부하를 EC2에서 제거
    ALB에 HTTPS 리스너를 두면, SSL 종료가 ALB에서 이루어짐.
    클라이언트 ↔ ALB: HTTPS, ALB ↔ EC2: HTTP(또는 필요 시 HTTPS)로 구성 가능.
    EC2는 SSL 암·복호화를 하지 않음 → SSL 때문에 쓰이던 CPU가 줄어들어 성능이 개선됨.
2. 기존 인증서 활용
    “SSL 인증서를 ACM으로 가져옵니다” → 이미 쓰던 인증서를 ACM에 import해서 ALB에서 사용할 수 있음.
    ACM에서 발급한 인증서를 쓰는 것도 가능함.
3. 운영 부담 감소
    ALB는 관리형 서비스라 SSL 처리·스케일은 AWS가 담당.
    EC2를 프록시로 추가해 SSL을 옮기는 방식(C)보다 서버 추가·관리 없이 해결 가능.
4. 트래픽 증가 대응
    ALB가 트래픽을 받고 EC2로 분산하므로, SSL 처리와 애플리케이션 처리가 분리되어 확장에 유리함.

 

Answer: A

 

요구사항
워크로드: 매우 동적인 배치 처리, 많은 EC2 사용
특성: 상태 비저장, 언제든 시작·중단 가능 (중단해도 부작용 없음)
실행 시간: 보통 60분 이상
목표: 확장 가능하고 비용 효율적인 구성

A. EC2 스팟 인스턴스 사용
1. 비용 효율
    스팟은 온디맨드 대비 최대 약 90% 할인 가능.
    “많은 EC2”, “동적 배치”처럼 변동이 큰 워크로드에서 비용 절감 효과가 큼.
2. 상태 비저장·중단 가능과의 정합성
    “상태 비저장”, “주어진 시간에 시작·중지 가능”, “부정적 영향 없음” → 중단되어도 재시작/재시도 가능한 워크로드.
    스팟은 중단(리클레임) 될 수 있지만, 재시작해도 되는 배치에 적합함.
    중단되면 다른 스팟/온디맨드에서 같은 작업을 다시 돌리면 됨.
3. 동적·확장 가능
    수요에 따라 필요한 만큼 스팟을 요청·해제할 수 있어, “매우 동적인” 배치에 맞음.
    오토 스케일링 등과 함께 쓰면 확장 가능하게 운영 가능.
4. 60분 이상 실행
    한 작업이 60분 이상 걸리는 조건이므로, 최대 15분 제한이 있는 Lambda(D) 는 부적합함.

 

Answer: A, E

요구사항 
구조: 웹 계층(로드 밸런서 → EC2), DB 계층(RDS)
보안: EC2와 RDS는 공용 인터넷에 노출되면 안 됨
연결: EC2는 아웃바운드 인터넷 필요(타사 결제 등)
가용성: 고가용성 필요

A. Auto Scaling 그룹으로 프라이빗 서브넷에서 EC2 기동 + 프라이빗 서브넷에 RDS Multi-AZ 배포
EC2를 프라이빗 서브넷에서만 기동 → 공용 인터넷에 직접 노출되지 않음.
RDS를 프라이빗 서브넷에 두고 Multi-AZ로 구성 → DB도 비공개 + 고가용성.
효과
“EC2·RDS는 공용 인터넷에 노출되지 않는다”는 요구를 충족.
ASG로 웹 계층 확장, RDS Multi-AZ로 DB 계층 가용성 확보.

 

E. 2 AZ에 걸쳐 퍼블릭 2개·프라이빗 2개·NAT 게이트웨이 2개로 VPC 구성 + ALB는 퍼블릭 서브넷에 배포
퍼블릭 서브넷 2개(AZ당 1개): 인터넷 게이트웨이, NAT 게이트웨이, ALB 배치.
프라이빗 서브넷 2개(AZ당 1개): EC2(A), RDS(A) 배치.
NAT 게이트웨이 2개(AZ당 1개): 프라이빗 서브넷의 EC2가 아웃바운드 인터넷(타사 결제 등)만 나갈 수 있게 함.
효과
EC2·RDS는 프라이빗에만 두고, 인바운드 인터넷 노출 없음.
EC2는 NAT를 통해 아웃바운드 인터넷만 사용 → “인터넷 액세스 필요” 충족.
ALB는 퍼블릭에 두어 인터넷 사용자가 접속 가능.
2 AZ + AZ당 NAT → 고가용성 (한 AZ 장애 시에도 다른 AZ로 서비스 유지).

아키텍처 구조
[인터넷 사용자]
       ↓
[ALB] (퍼블릭 서브넷, 2 AZ)  ← E
       ↓
[EC2] (프라이빗 서브넷, ASG, 2 AZ)  ← A
  ↖ 아웃바운드: [NAT GW] (퍼블릭)  ← E
       ↓
[RDS Multi-AZ] (프라이빗 서브넷, 2 AZ)  ← A

 

Answer: B

요구사항
- 스토리지 비용 감소 현재 전부 S3 Standard → 더 저렴한 스토리지 클래스 활용
- 모든 데이터 최소 25년 보관 삭제 정책 없이 장기 보관
- 최근 2년 데이터 높은 가용성 + 즉시 검색 가능

B. 2년 후에 객체를 S3 Glacier Deep Archive로 전환하는 S3 수명 주기 정책을 설정
1. 최근 2년 데이터: 높은 가용성 + 즉시 검색
    2년 이후에만 Deep Archive로 전환하므로, 최근 2년치 데이터는 S3 Standard에 그대로 유지됩니다.
    S3 Standard는 다중 AZ, 즉시 검색 가능 → “높은 가용성”, “즉시 검색 가능” 조건을 충족합니다.
2. 2년이 지난 데이터: 비용 절감
    2년이 지난 객체만 Glacier Deep Archive로 이동 → 가장 저렴한 스토리지로 비용 감소.
    25년 보관도 Deep Archive로 계속 보관하면 됩니다.
3. 구현
    수명 주기 규칙: 객체가 730일(2년) 경과 후 S3 Glacier Deep Archive로 전환.
    별도 삭제 규칙을 두지 않으면 25년 보관도 만족합니다.

 

Answer: D

요구사항 
비디오 처리 : 가능한 최대 I/O 성능, 최소 10TB
미디어 콘텐츠 저장 : 300TB, 매우 높은 내구성
아카이브 미디어 (사용 종료) : 900TB

D. EC2 인스턴스 스토어(최고 성능) + Amazon S3(내구성) + Amazon S3 Glacier(아카이브)
1. 비디오 처리 – 가능한 최대 I/O 성능, 10TB
    EC2 인스턴스 스토어는 호스트에 직접 연결된 로컬 NVMe 스토리지로, 지연 시간·처리량 측면에서 EBS보다 높은 성능을 냅니다.
    “가능한 최대 I/O 성능”이라는 표현에 맞는 선택은 인스턴스 스토어입니다.
    10TB 이상이 필요하면 인스턴스 스토어가 큰 인스턴스 타입을 선택하면 됩니다.
2. 미디어 콘텐츠 – 300TB, 매우 내구성
    Amazon S3는 99.999999999%(11 9’s) 내구성, 다중 AZ 복제로 “매우 내구성 있는” 스토리지에 적합합니다.
    300TB처럼 대용량 객체 저장에는 S3가 표준이며, EFS보다 비용·내구성 면에서 유리합니다.
3. 아카이브 – 900TB
   “더 이상 사용하지 않는 아카이브”에는 Amazon S3 Glacier(또는 Glacier Deep Archive)가 맞습니다.
    장기 보관·저비용 요구를 충족합니다.

 

Answer: B

요구사항 
- 컨테이너에서 애플리케이션 실행
- 상태 비저장, 인프라 내 중단 허용 (인스턴스가 바뀌어도 괜찮음)
- 비용과 운영 오버헤드 최소화

B. Amazon EKS 관리형 노드 그룹에서 스팟 인스턴스 사용
1. 비용 최소화
    스팟 인스턴스를 쓰면 온디맨드 대비 최대 약 90%까지 비용을 줄일 수 있습니다. 상태 비저장·중단 허용 워크로드에 적합합니다.
2. 운영 오버헤드 최소화
    EKS: Kubernetes 제어 평면을 AWS가 관리합니다.
    관리형 노드 그룹: 노드 생성·업데이트·스케일링을 AWS가 처리합니다.
    컨테이너 오케스트레이션과 노드 생명 주기를 직접 관리할 필요가 적어, A(EC2 ASG에 직접 컨테이너 올리는 방식)보다 운영 부담이 적습니다.
3. 중단 허용
    스팟이 회수되면 EKS가 다른 노드에서 파드를 다시 띄우므로, “기본 인프라 내에서 중단 허용” 조건을 만족합니다.

C, D (온디맨드) - 온디맨드는 스팟보다 비용이 높아 “비용 최소화”에는 맞지 않습니다.

 

Answer: A, E

요구사항 
현재: 온프레미스, 컨테이너화된 웹 앱이 여러 Linux 호스트에서 실행, PostgreSQL 사용
문제: 인프라 유지보수와 용량 계획으로 인한 운영 부담이 성장을 제한
이 운영 오버헤드를 줄이는 조치 

A. PostgreSQL 데이터베이스를 Amazon Aurora로 마이그레이션
DB 계층의 운영을 줄이기 위한 선택입니다.
효과
Aurora는 관리형 서비스로, 백업·패치·고가용성·스토리지 자동 확장을 AWS가 담당합니다. Aurora PostgreSQL은 기존 PostgreSQL과 호환되므로 마이그레이션이 상대적으로 수월합니다. DB용 용량 계획·인프라 유지보수 부담이 크게 줄어듭니다.

 

E. 웹 애플리케이션을 Amazon ECS에서 AWS Fargate로 호스팅하도록 마이그레이션
웹(컨테이너) 계층의 인프라·용량 계획 부담을 줄이기 위한 선택입니다.
효과
앱이 이미 컨테이너화되어 있으므로 ECS에 올리기 적합합니다. Fargate를 쓰면 컨테이너 호스트(EC2)를 직접 두지 않아도 되어, 서버 프로비저닝·OS 패치·용량 계획을 AWS가 맡습니다. “인프라 및 용량 계획 유지 관리”가 가장 큰 부담이었다면, 이 조치로 그 부분이 크게 줄어듭니다.

 

Answer: B

요구사항
구성: 여러 AZ의 EC2, ALB 뒤의 Auto Scaling 그룹
목표: 그룹의 모든 인스턴스에서 CPU 사용률이 40% 또는 그 근처일 때 성능이 가장 좋음
필요: 이 원하는 성능(CPU ~40%)을 유지하는 방법

B. 대상 추적(Target Tracking) 정책을 사용해 Auto Scaling 그룹을 동적으로 확장
“CPU를 40% 근처로 유지”하는 것이 목표이므로, 목표값을 지정하고 그에 맞춰 인스턴스 수를 자동으로 조정하는 방식이 맞습니다.
대상 추적(Target Tracking) 정책은 목표 지표와 목표값(여기서는 CPU 40%)을 하나 지정하고, ASG가 그 목표값에 수렴하도록 인스턴스를 늘리거나 줄입니다.
즉, 부하가 늘면 인스턴스를 늘려 CPU를 내리고, 부하가 줄면 인스턴스를 줄여 CPU를 올려서, 동적으로 40% 근처를 유지할 수 있습니다. “그룹의 모든 인스턴스에서 원하는 성능(CPU ~40%)을 유지”하는 요구와 정확히 맞습니다.

 

Answer: D

요구사항 
저장소: Amazon S3 버킷
제공 방식: CloudFront를 통해서만 파일 제공
제한: S3 URL로 직접 접근 불가 (CloudFront URL로만 접근)

D. 원본 액세스 ID(OAI) 생성 → CloudFront에 OAI 할당 → S3 버킷 권한은 OAI에만 읽기 허용
역할
CloudFront만 S3에 접근할 수 있게 하고, 나머지(브라우저 등)는 S3에 직접 접근하지 못하게 하는 표준 방식입니다.
절차
1. Origin Access Identity(OAI) 생성
    - CloudFront가 S3에 접근할 때 쓰는 전용 식별자입니다.
2. CloudFront 배포의 S3 오리진에 이 OAI를 연결
    - CloudFront가 S3를 읽을 때 항상 이 OAI로 요청합니다.
3. S3 버킷 정책에서 OAI에 대해서만 s3:GetObject 허용
    - 다른 주체(익명, IAM 사용자 등)는 S3 객체에 접근할 수 없습니다.
결과
- CloudFront URL → OAI로 S3 접근 → 정상 제공
- S3 URL 직접 접근 → OAI가 아님 → 거부
→ “S3 URL에 대한 직접 탐색을 통한 접근 불가” 요구를 충족합니다.

 

Answer: A

요구사항 
제공 대상: 사용자에게 다운로드 가능한 과거 실적 보고서 (정적 파일)
규모: 전 세계로 확장 가능해야 함
조건: 비용 효율, 인프라 프로비저닝 최소화, 가능한 가장 빠른 응답 시간

A. Amazon CloudFront 및 Amazon S3
역할
    - 보고서를 정적 파일(PDF 등)로 두고, S3에 저장한 뒤 CloudFront로 전 세계에 제공하는 구성입니다.
요구사항 충족
    - 가능한 가장 빠른 응답 시간: CloudFront가 엣지 캐시로 동작해 사용자와 가장 가까운 엣지에서 파일을 제공합니다. 글로벌 사용자에게 지연 시간 최소화에 적합합니다.
    - 전 세계 확장: CloudFront와 S3는 자동 확장되며, 별도 용량 계획 없이 전 세계 트래픽을 처리할 수 있습니다.
    - 인프라 프로비저닝 최소화: EC2·로드밸런서 등을 두지 않고, S3(스토리지) + CloudFront(배포) 만 사용하는 관리형·서버리스 구조입니다.
    - 비용 효율: 사용한 스토리지·전송량·요청 수만 과금되며, 유휴 서버 비용이 없습니다.

 

Answer: C

요구사항
현재: 온프레미스 Oracle DB
목표: AWS로 마이그레이션, 가능한 최신 버전으로 업그레이드
DR: 데이터베이스 재해 복구 구성
운영: 정상 운영·DR 모두 운영 오버헤드 최소화
제약: 데이터베이스의 기본 운영 체제(OS)에 대한 액세스 유지

C. Oracle을 Amazon RDS Custom for Oracle로 마이그레이션 + 다른 리전에 읽기 전용 복제본 생성
OS 접근 유지
“데이터베이스의 기본 운영 체제에 대한 액세스를 유지 관리해야 합니다”는 OS 레벨 접근(SSH 등) 이 필요하다는 의미입니다.
일반 RDS: OS에 대한 고객 접근을 제공하지 않음 → B, D는 이 요구를 충족하지 못함.
RDS Custom: OS 접근을 허용하는 관리형 DB 서비스(커스텀 설정, 에이전트 등이 필요할 때 사용). → C가 유일하게 “OS 접근 유지”를 만족.

DR
다른 AWS 리전에 읽기 전용 복제본을 두면, 리전 장애 시 해당 복제본을 활용한 DR 구성이 가능합니다. 리전 단위 재해 복구 요구를 충족합니다.

운영 오버헤드 최소화
RDS Custom은 백업·패치·모니터링 등은 AWS가 관리하고, 필요한 경우에만 OS에 접근하는 구조라, Oracle을 EC2에 직접 설치·관리하는 A보다 운영 부담이 적습니다. “정상 운영 및 DR 설정을 위한 운영 오버헤드 최소화”에 부합합니다.
업그레이드
마이그레이션 시 RDS Custom for Oracle의 지원 버전 중 최신으로 프로비저닝하면 “가능한 최신 버전으로 업그레이드” 요구를 충족할 수 있습니다.

 

Answer: C

요구사항 
서버리스로 전환, SQL로 기존·신규 데이터 분석
데이터는 Amazon S3에 저장
암호화 필요, 다른 AWS 리전에 복제 필요
최소한의 운영 오버헤드

C. 기존 S3 버킷에 데이터 로드 + CRR로 다른 리전 복제 + SSE-S3 암호화 + Amazon Athena로 쿼리
SQL로 S3 데이터 분석
데이터가 S3에 있는 상태에서 SQL로 분석하려면 Amazon Athena가 적합합니다. S3에 있는 데이터를 그대로 두고 SQL로 쿼리하며, 서버 프로비저닝·데이터 로딩 없이 동작해 운영 오버헤드가 적습니다.
RDS(B, D)는 데이터를 DB에 적재·관리하는 서비스라, “S3에 저장된 데이터를 SQL로 분석”하는 용도에는 Athena가 더 맞고 오버헤드도 적습니다.

 

암호화
SSE-S3를 사용하면 S3가 키를 관리하므로 KMS 키 생성·관리·다중 리전 키 설정이 필요 없습니다. “암호화 필요”를 만족하면서 운영을 최소화할 수 있습니다.
CRR 대상 버킷에도 복제 시 암호화가 유지됩니다.

 

다른 리전 복제
S3 교차 리전 복제(CRR) 를 사용해 암호화된 객체를 다른 리전 버킷으로 복제하면 “다른 AWS 리전에 복제” 요구를 충족합니다. SSE-S3로 암호화된 객체도 CRR로 복제 가능합니다.

 

기존 버킷 사용
이미 사용 중인 S3 버킷에 데이터를 두고, 해당 버킷에 기본 암호화(SSE-S3)와 CRR만 설정하면 되므로, 새 버킷을 만들고 데이터를 옮기는 A·B보다 구성·이동이 적어 운영 오버헤드가 적습니다.

 

Answer: D

요구사항 
연결 대상: 외부 공급자 서비스 (공급자 VPC에서 호스팅)
보안 요구:
    연결은 비공개
    대상 서비스로만 제한 (공급자 VPC 전체가 아님)
    연결은 회사 VPC에서만 시작 (회사가 클라이언트, 공급자가 서비스 제공자)

D. 공급자에게 대상 서비스에 대한 VPC 엔드포인트(서비스)를 만들도록 요청하고, AWS PrivateLink로 해당 서비스에 연결
PrivateLink 동작
- 공급자: 대상 서비스를 VPC 엔드포인트 서비스(NLB 뒤에 노출)로 제공
- 회사: 자신의 VPC에 인터페이스 VPC 엔드포인트를 만들고, 이 엔드포인트를 통해 공급자 엔드포인트 서비스에 연결
요구사항 충족
- 비공개: 트래픽이 인터넷을 거치지 않고 AWS 네트워크(PrivateLink) 안에서만 흐름
- 대상 서비스로 제한: 회사는 그 엔드포인트 서비스(대상 서비스)에만 연결 가능. 공급자 VPC 전체나 다른 리소스에는 접근하지 않음
- 회사 VPC에서만 시작: 회사 리소스가 자신의 VPC 안의 엔드포인트를 통해 아웃바운드로만 연결. 공급자가 회사 VPC로 들어오는 연결을 시작할 필요 없음
따라서 “비공개 + 대상 서비스로만 제한 + 회사 VPC에서만 시작”을 모두 만족하는 방식은 PrivateLink이고, 그 구체적 구현이 D입니다.

 

Answer: A, C

요구사항 
원본: 온프레미스 PostgreSQL
대상: Amazon Aurora PostgreSQL
조건: 마이그레이션 동안 온프레미스 DB는 계속 사용 가능해야 함
목표: 온프레미스 DB와 Aurora가 동기화된 상태 유지 (온라인 마이그레이션)

C. AWS DMS 복제 인스턴스(복제 서버) 생성
역할
AWS DMS로 마이그레이션·동기화를 하려면 복제 인스턴스(Replication Instance) 가 필요합니다. 이 인스턴스가 원본과 대상 사이에서 변경 사항을 읽고 쓰는 복제 엔진을 실행합니다.
“복제 서버를 생성한다”는 말은 이 DMS 복제 인스턴스를 만드는 것을 의미합니다.
효과
온프레미스 PostgreSQL에 대한 연결, Aurora에 대한 쓰기, CDC(변경 데이터 캡처)가 이 복제 인스턴스를 통해 이루어지므로, 동기화를 위해 반드시 필요한 단계입니다.

A. 지속적인 복제 작업(Continuous Replication Task) 생성
역할
DMS에서 실제로 원본 → 대상으로 데이터를 옮기고, 이후 지속적으로 변경 사항을 반영하는 것은 복제 작업(Replication Task) 입니다.
“지속적인 복제 작업”은 풀 로드 + CDC(연속 복제) 로 설정된 작업으로, 초기 풀 로드 후에도 온프레미스에서 발생하는 변경이 Aurora에 계속 반영됩니다.
효과
온프레미스 DB는 그대로 서비스 가능
Aurora는 초기 데이터 복사 후에도 실시간에 가깝게 동기화 유지
→ “온프레미스 DB는 액세스 가능” + “Aurora와 동기화된 상태 유지” 요구를 충족합니다.

 

Answer: B

요구사항 
구성: AWS Organizations로 사업부별 전용 AWS 계정 사용
문제: 한 계정 루트 사용자 이메일로 온 알림을 놓침
목표: 앞으로 모든 알림을 놓치지 않기
제약: 향후 알림은 계정 관리자로만 제한

B. 루트 이메일을 소수 관리자용 배포 목록으로 구성 + AWS 계정 대체 연락처(Alternate Contact) 구성
루트 이메일 수신 보장
각 계정의 루트 사용자 이메일을 배포 목록(DL) 으로 두고, 그 DL을 소수의 계정 관리자만 받는 주소로 설정하면, AWS가 루트로 보내는 메일이 관리자들에게 전달됩니다. 한 사람이 놓쳐도 다른 관리자가 볼 수 있어 알림을 놓치지 않기 요구를 충족합니다.
계정 관리자로 제한
배포 목록 수신자를 계정 관리자(소수의 관리자) 로만 두면, “알림은 계정 관리자로 제한” 조건을 만족합니다. 조직 전체가 아닌 관리자만 수신합니다.
대체 연락처(Alternate Contact)
AWS 콘솔 또는 API로 대체 연락처(운영·청구·보안 연락처)를 설정하면, 중요한 알림 일부는 루트 이메일 대신 이 연락처로도 갈 수 있습니다. 관리자 이메일을 대체 연락처로 등록해 두면, 루트 이메일을 덜 의존하면서도 알림을 관리자가 받을 수 있습니다.
정리
- 루트 이메일 → DL → 소수 관리자만 수신 → 알림 누락 방지 + 관리자로 제한
- 대체 연락처 = 관리자 → AWS가 보내는 중요 알림을 관리자가 직접 수신

 

Answer: A

요구사항 
현재: 단일 AZ의 EC2에서 RabbitMQ, 주문 처리 앱, PostgreSQL 모두 실행
목표: 최고 수준의 가용성 + 최소한의 운영 오버헤드로 아키텍처 재설계

B. Amazon MQ RabbitMQ 활성/대기 + 앱용 다중 AZ ASG + RDS PostgreSQL 다중 AZ
1. 메시지 큐 – Amazon MQ RabbitMQ 활성/대기
    RabbitMQ를 EC2에서 직접 운영하면 클러스터·미러링·장애 조치를 직접 구성해야 해 운영 부담이 큼.
    Amazon MQ는 관리형 RabbitMQ로, 활성/대기(2 AZ) 구성으로 고가용성을 제공하고, 장애 조치·패치는 AWS가 담당해 운영 오버헤드가 적음.
2. 주문 처리 애플리케이션 – 다중 AZ Auto Scaling 그룹
    상태 비저장 워크로드에 맞게 다중 AZ ASG로 배치하면 AZ 장애 시에도 다른 AZ 인스턴스가 처리하고, 용량도 자동 조정되어 가용성·운영 부담 모두 개선됩니다.
3. 데이터베이스 – RDS PostgreSQL 다중 AZ
    PostgreSQL을 EC2에서 운영하면 복제·페일오버·백업·패치를 직접 관리해야 해 운영 부담이 큼.
    RDS PostgreSQL 다중 AZ는 자동 페일오버·백업·패치를 AWS가 처리하므로 가용성과 운영 오버헤드 최소화를 동시에 만족합니다.
    DB는 상태 유지가 필요하므로, “인스턴스 수만 늘리는” ASG에는 맞지 않고, RDS Multi-AZ가 적합합니다.
4. 정리
메시지 큐: Amazon MQ (관리형, 활성/대기)
앱: 다중 AZ ASG
DB: RDS PostgreSQL 다중 AZ
→ “최고 가용성 + 최소 운영 오버헤드”를 모두 만족하는 것은 B입니다.

 

Answer: D

요구사항 
초기 S3 버킷: 매일 파일 수신, 규모·파일 수 증가
- 파일이 초기 버킷에 들어올 때 자동으로 분석 S3 버킷으로 이동
- Lambda로 복사된 데이터에 패턴 일치 코드 실행
- 데이터 파일을 Amazon SageMaker Pipelines 파이프라인으로 전달
제약: 최소한의 운영 오버헤드

D. S3 버킷 간 복제 구성 + 분석 버킷에서 EventBridge로 이벤트 전송 + ObjectCreated 규칙으로 Lambda·SageMaker 타깃
1. 자동 복사 – S3 복제
- “파일이 초기 버킷에 들어갈 때 자동으로 분석 버킷으로 이동”은 S3 복제(Replication) 로 구현하는 것이 가장 단순합니다.
- 초기 버킷(소스) → 분석 버킷(대상)으로 같은 리전 복제 또는 CRR를 설정하면, 객체 생성 시 S3가 자동으로 복사합니다.
- 별도 복사용 Lambda를 두지 않아도 되어 운영 오버헤드가 적습니다.
2. 복사 후 처리 – EventBridge + Lambda + SageMaker
- 복제가 완료되면 분석 버킷에 객체가 생성됩니다.
- S3 이벤트 알림의 직접 대상은 보통 Lambda, SNS, SQS, EventBridge 등입니다. SageMaker Pipelines는 S3 이벤트에서 직접 호출할 수 없고, EventBridge(또는 Step Functions 등) 를 통해 트리거하는 구성이 필요합니다.
- 따라서 분석 버킷 → S3 이벤트를 EventBridge로 전송 → ObjectCreated 규칙에서
     Lambda(패턴 일치 코드)
    SageMaker Pipelines
를 타깃으로 두는 D 구성이 요구사항을 충족합니다.
3. 최소 운영 오버헤드
- 복사: S3 복제만 사용 (복사 Lambda 없음)
- 트리거: EventBridge 규칙으로 Lambda·SageMaker만 연결
→ “최소한의 운영 오버헤드”와 잘 맞습니다.

SageMaker는 데이터 과학자와 개발자가 기계 학습(ML) 모델을 쉽고 빠르게 구축, 학습 및 배포할 수 있도록 지원하는 AWS의 완전 관리형 서비스

 

Answer: A, C
 
요구사항
데이터 수집 계층: EC2, 사용이 산발적·예측 어려움, 언제든 중단 가능한 워크로드
프런트엔드: Fargate, 내년 활용도 예측 가능
API 계층: Lambda, 내년 활용도 예측 가능
이 구성을 가장 비용 효율적으로 만드는 구매 옵션 

A. 데이터 수집 계층에 스팟 인스턴스 사용
데이터 수집 계층 특성
    - 사용이 산발적·예측 불가 → 예약 인스턴스·장기 약정은 용량 예측이 어려워 비효율적
    - 언제든 중단 가능 → 인스턴스가 중간에 회수되어도 괜찮은 워크로드
스팟이 맞는 이유
    - 온디맨드 대비 최대 약 90% 할인 가능
    - 중단 허용 워크로드에 AWS가 권장하는 방식
    - 사용이 들쭉날쭉해도 쓴 만큼만 비용 발생
    → 데이터 수집 계층은 스팟이 가장 비용 효율적이므로 A 선택.

 

C. 프런트엔드 및 API 계층에 대한 1년 Compute Savings Plan 구매
프런트엔드(Fargate)·API(Lambda) 특성
    - 내년 활용도 예측 가능 → 1년 약정으로 할인 받기 적합
Compute Savings Plan
    - Fargate, Lambda, EC2 모두 적용
    - $/시간 기준으로 컴퓨트 사용량에 대해 약정하면 할인
    - EC2 Instance Savings Plan은 EC2만 적용되고, Fargate·Lambda에는 적용되지 않음
    → 프런트엔드(Fargate)와 API(Lambda) 둘 다 할인받으려면 Compute Savings Plan이 맞고, 1년 약정이면 C가 정답.

 

Answer: A

요구사항 
포털: 글로벌/지역 속보·경보·날씨, 정적 + 동적(개인화) 콘텐츠
현재: EC2 API 서버 → ALB → HTTPS로 제공
전 세계 사용자에게 가능한 한 빠르게 제공 → 모든 사용자 대기 시간 최소화

 

A. 단일 AWS 리전에 애플리케이션 스택을 배포합니다. Amazon CloudFront 를 사용하여 ALB 를 오리진으로 지정하여 모든 정적 및 동적 콘텐츠를 제공

 

1. CloudFront 엣지가 전 세계에 훨씬 많음
    CloudFront는 수백 개 엣지 로케이션이 있어, 아시아·남미 등 어느 지역 사용자나 가까운 엣지가 있음.
    “두 리전”만 두는 B는 리전이 2개뿐이면 (예: us-east-1, eu-west-1) 아시아·남미 사용자는 어느 리전이든 먼 상태일 수 있음.
    “전 세계 사용자 대기 시간 최소화”에는 엣지가 많은 CloudFront(A) 가 유리함.

 

2. 사용자 관점 지연은 “사용자 ↔ 가장 가까운 지점”
    A: 사용자는 항상 가장 가까운 CloudFront 엣지에만 연결함.
    정적: 엣지에서 바로 응답 → 지연 최소.
    동적: 사용자 → 가까운 엣지 → (엣지가) ALB 오리진으로 요청 → 응답은 다시 엣지를 거쳐 사용자에게.
    즉, 긴 구간은 “엣지 ↔ 오리진(ALB)” 이고, “사용자 ↔ 엣지” 는 항상 짧게 유지됨.
    ALB를 오리진으로 쓰는 것은 기술적으로 가능하고(지문처럼 EC2/HTTP 서버 앞에 ALB를 두고, CloudFront 오리진을 그 ALB로 두면 됨), 이 구성을 통해 모든 사용자의 첫 구간 지연을 최소화할 수 있음.

 

3. 정적·동적 모두 “가능한 한 빨리”
    정적: 엣지 캐시로 가장 빠름.
    동적: 오리진이 한 리전이어도, 사용자는 가까운 엣지와만 통신하고, 엣지–오리진 구간은 AWS 백본으로 처리되므로, “단일 리전     ALB만 두고 CloudFront 없이 직접 ALB로 가는 경우”보다 전반적으로 유리함.
    지문에서 “모든 정적 및 동적 콘텐츠를 (CloudFront로) 제공”하는 A가 “가능한 한 빨리 전 세계 사용자에게”라는 목표와 맞음.

 

4. 운영·복잡도
    A: 기존 단일 리전 + ALB 위에 CloudFront만 추가하면 됨.
    B: 두 리전에 스택 배포·동기화·Route 53 구성 등이 필요해 더 복잡함.
    “대기 시간 최소화”를 최소 변경으로 달성하는 방법은 A.

 

Answer: C

요구사항 
앱: 수정된 Linux 커널에서 동작, UDP만 사용
프런트엔드 계층이 필요하고, 다음을 만족해야 함:
    - 저지연
    - 가장 가까운 엣지로 트래픽 라우팅
    - 고정(정적) IP로 애플리케이션 엔드포인트 진입

C. AWS Global Accelerator로 요청을 Network Load Balancer로 전달 + EC2 Auto Scaling 그룹의 EC2에서 애플리케이션 실행

1. UDP 지원
    Application Load Balancer(ALB) 는 HTTP/HTTPS(L7) 만 지원 → UDP 불가. (A, D는 부적합)
    CloudFront 는 HTTP/HTTPS 용 → UDP 불가. (B 부적합)
    Network Load Balancer(NLB) 는 TCP·UDP 지원 → UDP 트래픽에 적합.
    Global Accelerator 는 클라이언트 트래픽을 받아 NLB 등으로 전달하므로, NLB와 함께 사용하면 UDP 요구를 충족함.
    → UDP를 지원하는 조합은 Global Accelerator + NLB인 C가 맞음.

 

2. 고정 IP
    Global Accelerator 는 2개의 고정(정적) Anycast IP 를 제공함.
    클라이언트는 이 IP로 접속하면 되고, “엔드포인트 진입을 위한 고정 IP” 요구를 만족함.
    Route 53은 DNS 기반이라 “고정 IP 제공”이 아님.

 

3. 가장 가까운 엣지·저지연
    Global Accelerator는 Anycast 로, 사용자가 가장 가까운 엣지로 연결됨.
    엣지에서 AWS 백본을 통해 리전 내 NLB·EC2로 전달되므로 저지연 경로를 제공함.
    “가장 가까운 엣지로 라우팅 + 저지연” 요구와 일치함.

 

4. 수정된 Linux 커널
    “수정된 Linux 커널에서 실행” → 커스텀 커널/OS 가 필요하므로 EC2 가 적합함.
    Lambda는 커널/OS를 제어할 수 없음 → (A, B)의 Lambda는 부적합.

→ 애플리케이션은 EC2 Auto Scaling 그룹의 EC2(C, D)에서 실행하는 구성이 맞고, 이 중 UDP·고정 IP·엣지 라우팅을 만족하는 것은 C임.

 

Answer: D

 

요구사항 
현재: 온프레미스 모놀리식 애플리케이션
목표: AWS로 마이그레이션
제약·요구
    프론트엔드·백엔드 코드를 최대한 유지
    애플리케이션을 더 작은 애플리케이션으로 분리
    팀별로 각 애플리케이션 관리
    확장 가능 + 운영 오버헤드 최소화

D. Amazon ECS에서 애플리케이션 호스팅 + ECS를 대상으로 Application Load Balancer 설정
1. 코드 최대한 유지
    기존 모놀리식을 컨테이너 이미지로 패키징하면, 대부분의 프론트엔드·백엔드 코드를 그대로 옮길 수 있음.
    Lambda는 함수 단위로 재구성해야 해 코드 구조를 크게 바꿔야 하므로, “코드를 최대한 유지”에는 맞지 않음.
    ECS는 기존 코드를 컨테이너로 감싸서 배포하는 방식에 잘 맞음.

 

2. 더 작은 애플리케이션으로 분리
     모놀리식을 서비스 단위로 나누면, 각 서비스 = ECS 서비스 하나로 두기 좋음.
    ECS에서는 서비스별로 태스크 수·배포·롤아웃을 따로 설정할 수 있어, “더 작은 애플리케이션”을 자연스럽게 표현함.
    ALB는 경로/호스트별로 서로 다른 ECS 서비스(타깃 그룹) 로 라우팅할 수 있어, 작은 앱들이 하나의 진입점 뒤에 나뉘어 서비스   되도록 할 수 있음.

3. 팀별로 각 애플리케이션 관리
    “애플리케이션 = ECS 서비스”로 두면, 팀마다 자신이 담당하는 ECS 서비스만 배포·스케일·관리하면 됨.
    서비스 단위로 독립 배포·스케일이 가능해 “다른 팀이 각 애플리케이션을 관리”하는 모델과 잘 맞음.

 

4. 확장성·운영 오버헤드
    ECS는 서비스 단위 Auto Scaling으로 각 작은 앱을 독립적으로 확장 가능.
    Fargate를 쓰면 서버(EC2)를 관리할 필요 없이 컨테이너만 관리하면 되어 운영 오버헤드를 줄일 수 있음.
    ALB가 트래픽을 ECS 서비스로 분산하므로, 확장된 서비스에 맞춰 트래픽이 분배됨.

 

Answer: B

요구사항
Aurora: 글로벌 전자상거래 OLTP용 (Online Transaction Processing)
문제: 월별 대규모 보고 실행 시 전자상거래 앱 성능 저하
원인: CloudWatch에서 월별 보고 시점에 ReadIOPS·CPUUtilization 급증 → 보고 쿼리가 OLTP와 같은 Aurora를 사용해 리소스 경쟁

B. 월별 보고를 Aurora 복제본(Read Replica)으로 마이그레이션
역할
    주 인스턴스(Primary): 전자상거래 OLTP 전용
    읽기 복제본(Read Replica): 월별 보고 등 읽기 전용 쿼리 전용
    보고 쿼리를 복제본으로만 보내면, Primary의 ReadIOPS·CPU는 보고 때문에 급증하지 않고, 전자상거래 성능이 유지됨.

 

비용 효율
복제본 1대 추가만 하면 됨. 기존 Aurora 사용 방식 유지, 별도 DW(Data Warehouse)·ETL(Extract Transform, Load) 불필요.
복제본은 보고용이면 Primary보다 작은 인스턴스로도 가능해, 비용을 낮출 수 있음.
Redshift(A)처럼 새 서비스·데이터 동기화를 도입하지 않아 가장 단순하고 비용 효율적인 선택.

 

Answer: D

요구사항 
현재: 단일 EC2 온디맨드 한 대에 PHP 웹 앱 + 웹 서버 + MySQL 모두 구성
문제: 바쁜 시간대 성능 저하, 5xx 오류
목표: 원활한 확장 + 가장 비용 효율적인 솔루션

D. DB를 Aurora MySQL로 이전 + AMI·시작 템플릿 + 스팟 기반 Auto Scaling 그룹 + ALB 연결
1. DB 분리
MySQL을 Aurora MySQL로 옮기면 DB가 EC2에서 분리되고, EC2는 앱·웹 서버만 담당.
Aurora는 관리형이라 백업·패치·고가용성 부담이 줄고, 바쁜 시간대 DB 부하로 인한 5xx를 줄이는 데 도움이 됨.

 

2. 원활한 확장
AMI로 현재 웹 앱 구성을 고정하고, 시작 템플릿에 AMI를 넣어 Auto Scaling 그룹(ASG) 을 만들면, 부하에 따라 인스턴스 수가 자동으로 늘었다 줄었다 함.
“원활하게 확장”은 고정 2대(A) 보다 ASG로 수요에 맞춰 증감하는 D가 더 잘 맞음.

 

3. 비용 효율
ASG 인스턴스를 스팟으로 쓰면 온디맨드 대비 최대 약 90% 절감 가능.
트래픽이 적을 때는 ASG가 인스턴스를 줄여 비용이 떨어지고, 바쁜 때만 늘리므로 가장 비용 효율적인 선택이 됨.

 

4. ALB
ALB가 트래픽을 여러 EC2에 나누고, 헬스체크로 불량 인스턴스를 제외하므로 5xx 완화와 확장성 모두에 필요함.
D는 이 ALB를 ASG에 연결하는 구성임.

 

Answer: B

요구사항 
앱: 상태 비저장 웹 앱, ALB 뒤 EC2 온디맨드 그룹 (프로덕션)
사용 패턴:
    하루 8시간 – 사용량 많음
    나머지 시간 – 보통·안정
    주말 – 사용량 적음
목표: 가용성은 유지하면서 EC2 비용 최소화

B. 기본 사용량은 예약 인스턴스, 추가 용량은 스팟 인스턴스
역할
    기본 사용량(베이스라인): 항상 필요한 최소 인스턴스 수 → 예약 인스턴스(Reserved)
    추가 용량(피크): 하루 8시간 등 필요할 때만 더 쓰는 부분 → 스팟 인스턴스

 

가용성
    베이스라인은 예약 인스턴스로 유지되므로 중단·회수 없음 → 프로덕션 가용성 유지.
    추가 용량만 스팟이라, 스팟이 회수되어도 최소 인스턴스 수는 예약 인스턴스로 보장되므로 “가용성에 영향을 주지 않음” 조건을 만족함.

 

비용
    베이스라인: 예약이 온디맨드보다 훨씬 저렴 → 비용 최소화에 유리.
    추가 용량: 스팟이 온디맨드보다 저렴 → 피크 비용 절감.
   “비용 최소화”와 “가용성 유지”를 동시에 만족하는 조합은 B임.

 

Answer: B

요구사항 
대상: 중요 애플리케이션 로그 파일
보관: 10년
접근: 지난 달 로그는 자주 조회(문제 해결), 1개월 초과 로그는 거의 미접근
용량: 매월 10TB 이상
목표: 가장 비용 효율적인 스토리지 구성

B. Amazon S3에 로그 저장 + S3 수명 주기 정책으로 1개월 초과 로그를 S3 Glacier Deep Archive로 전환

 

저장소
    S3는 대용량 로그(10TB/월, 10년 ≈ PB급)에 적합하고, 용량·요청에 맞춰 확장됨.
    CloudWatch Logs는 수집·검색용으로, 10TB/월 규모에는 수집·저장 비용이 매우 커서 비용 효율이 나쁨.
    → 대용량 장기 보관은 S3가 맞음.

 

1개월 초과 로그 비용 절감
    “1개월 초과 로그는 거의 안 본다” → 저빈도 접근에 맞는 S3 Glacier Deep Archive로 옮기는 것이 단가 최저.
    S3 수명 주기 정책으로 객체가 30일(또는 31일) 경과 후 자동으로 Glacier Deep Archive로 전환되게 설정하면, 별도 스크립트·작업 없이 비용 최적화 가능.
    AWS Backup은 EBS·RDS 등 리소스 백업용이며, “S3 객체를 스토리지 클래스별로 전환”하는 용도는 S3 수명 주기가 맞음.
    → “1개월 초과 로그를 Deep Archive로”는 S3 수명 주기 정책(B) 이 적절함.

 

비용 효율
    최근 1개월: S3 Standard(또는 IA 등)로 빠른 접근.
    1개월 초과: Deep Archive로 자동 전환 → 장기 보관 비용 최소화.
    CloudWatch에 10TB/월 쌓지 않으므로, B가 가장 비용 효율적인 선택임.

 

Answer: D

요구사항
흐름: SNS 주제 → 새 데이터 전송 알림 → Lambda (처리·저장)
문제: 네트워크 연결 문제로 수집 워크플로가 가끔 실패하고, 실패 시 수동 재실행 전까지 해당 데이터가 수집되지 않음
목표: 모든 알림이 최종적으로 처리되도록 함

D. Amazon SQS 대기열을 장애 시 대상(또는 버퍼)으로 구성하고, Lambda가 대기열 메시지를 처리하도록 수정

 

문제의 본질
SNS가 Lambda를 직접 호출할 때, Lambda가 실패하면 SNS 재시도에 한계가 있고, 재시도 소진 후에는 메시지가 사라질 수 있음.
“네트워크 문제로 가끔 실패”는 일시적 오류이므로, 재시도 + 메시지 보존이 필요함.

 

SQS를 넣는 이유
SQS는 메시지를 삭제하기 전까지 큐에 보관함.
SNS → SQS → Lambda 구조로 바꾸면:
    1. SNS가 알림을 SQS로 보냄 (SQS를 SNS 구독자로 두거나, 실패 시 SQS로 보내는 식으로 구성).
    2. Lambda는 SQS에서 메시지를 꺼내 처리함.
    3. Lambda가 실패하면 메시지는 SQS에 남고, visibility timeout 후 다시 노출되어 Lambda가 자동 재시도함.
    4. 필요하면 DLQ(Dead Letter Queue) 로 최대 재시도 후 메시지를 옮겨, 나중에 수동 재처리할 수 있음.
그래서 일시적 네트워크 장애가 있어도 메시지는 유지되고, 복구 후 최종적으로 처리될 수 있음.

 

“장애 시 대상”의 의미
“대기열을 장애 시 대상으로 구성”은 SNS 구독에서 실패 시 SQS로 보내는 DLQ로 쓰거나, 또는 아예 SNS → SQS → Lambda로 두고 SQS를 “장애 시에도 메시지를 보관하는 대상”으로 쓰는 구성으로 이해할 수 있음.
어느 쪽이든 SQS가 버퍼/내구성을 제공하고, Lambda가 SQS 메시지를 처리하도록 바꾸는 D가 “모든 알림이 최종적으로 처리”되게 하는 핵심임.

 

Answer: A

요구사항 
- 이벤트 데이터를 수신하는 대로 처리
- 특정 순서로 작성된 데이터가 처리 전반에 걸쳐 그 순서가 유지되어야 함
- 운영 오버헤드 최소화

A. Amazon SQS FIFO 대기열 생성 + Lambda가 대기열 메시지 처리

 

1. 순서 유지
“처리 전반에 걸쳐 유지되어야 하는 특정 순서”는 선입선출(FIFO) 처리로 보장해야 함.
SQS FIFO 대기열은 메시지 그룹 단위로 전송·수신 순서를 보장함.
Lambda가 FIFO 큐를 이벤트 소스로 쓰면, 큐에서 꺼낸 순서대로 처리되므로 “처리 전반에 걸쳐 순서 유지” 요구를 충족함.

 

2. 수신 즉시 처리
이벤트가 SQS FIFO에 들어오면 Lambda가 트리거되어 수신하는 대로 처리할 수 있음.
별도 폴링·스케줄 없이 이벤트 기반으로 동작함.

 

3. 운영 오버헤드 최소화
SQS·Lambda 모두 관리형 서비스라 큐·서버를 직접 운영할 필요가 없음.
큐에 메시지 넣고, Lambda로 처리만 정의하면 됨.

 

Answer: A

요구사항 
- 인프라 메트릭 경보 구현 (EC2 마이그레이션)
- 알림 조건
     CPU만 50% 이상으로 단기간 증가 → 조치 불필요 (알림 없음)
     CPU 50% 이상 그리고 디스크 읽기 IOPS도 높을 때 → 즉시 조치 필요 (알림 발생)
- 오경보 최소화

A. 가능한 경우 Amazon CloudWatch 복합 경보(Composite Alarm) 생성

 

1. 역할
복합 경보는 여러 개의 지표 경보를 AND/OR로 묶어서, “둘 다 만족할 때만” 알림을 내는 용도로 씀.
경보 1: CPU 사용률 ≥ 50%
경보 2: 디스크 읽기 IOPS가 높음 (임계값 설정)
복합 경보: 경보 1 AND 경보 2 → 두 경보가 동시에 ALARM 상태일 때만 복합 경보가 ALARM.

 

2. 요구사항 충족
CPU만 높을 때: 경보 1만 ALARM → 복합 경보는 알림 없음 (조치 불필요 조건 충족).
CPU와 디스크 읽기 IOPS가 둘 다 높을 때: 두 경보 모두 ALARM → 복합 경보 알림 (즉시 조치 조건 충족).
“CPU만 올라갈 때 알림”을 막으므로 오경보가 줄어듦.

 

3. “가능한 경우”
 - CloudWatch에서 CPU·디스크 IOPS 지표를 사용할 수 있으면(EC2 상세 모니터링·EBS 지표 등) 복합 경보를 만들 수 있음.
- 지표가 없으면 먼저 지표를 켜고, 가능해지는 시점에 복합 경보를 구현하면 됨.