AWS SAA-C03 Dump 151-200

AWS SAA-C03  Dump 151-200

 

Answer: A, C

요구사항 
규정 준수: ap-northeast-3 리전만 사용 가능
제약: VPC가 인터넷에 연결되면 안 됨 

AWS Control Tower 가드레일
- Control Tower는 가드레일(Guardrails) 로 데이터 상주·리전 제한을 예방·탐지할 수 있음.
- 가드레일은 SCP 등을 통해 AWS API 액세스를 제한해 원하는 리전만 허용 (예: ap-northeast-3만 사용, 나머지 리전에서 리소스 프로비저닝 방지)
- 인터넷 게이트웨이 생성 차단, S3 교차 리전 복제 차단 등 데이터 상주·네트워크 제어

따라서 “ap-northeast-3만 사용” + “VPC를 인터넷에 연결할 수 없음” 요구를 Control Tower 가드레일로 충족할 수 있다.

 

AWS Organizations SCP
Organizations SCP로 지정한 리전(ap-northeast-3) 외의 작업에 대한 액세스를 거부
필요 시 인터넷 게이트웨이 부착 등을 거부해 VPC 인터넷 연결 방지
문서 예시처럼 “승인된 리전만 허용” 형태로 구현 가능하므로, 리전 제한 + VPC 인터넷 차단 요구를 만족

AWS WAF 는 Web ACL 을 통해 특정 국가나 지리적 위치, IP 의 요청을 차단할 수 있으나 리전을 차단하는 옵션은 없음.

 

Answer: C 

요구사항 
3계층 웹 앱: 신입 직원 교육용
사용 시간: 하루 12시간만 접근
DB: Amazon RDS for MySQL
목표: 비용 최소화

D. Lambda로 RDS 시작/중지 + EventBridge 예약 규칙으로 Lambda 호출
1. 접근
    RDS는 가동 시간만 과금되므로, 사용하지 않는 12시간에는 인스턴스를 중지하면 비용이 줄어듦.
    “12시간만 액세스”이므로 일정에 맞춰 RDS를 시작/중지하는 방식이 비용 최소화에 맞음.

 

2. D의 역할
    Lambda: RDS API(StartDBInstance, StopDBInstance)를 호출해 DB 인스턴스를 시작·중지.
   EventBridge(CloudWatch Events) 예약 규칙:
     사용 시작 시각에 Lambda(시작) 호출
     사용 종료 시각에 Lambda(중지) 호출
    규칙의 이벤트 대상을 해당 Lambda로 두면, 예약만으로 매일 자동 시작/중지됨.
3. 효과
    RDS가 필요한 12시간만 켜지므로, 24시간 가동 대비 비용이 감소함.
    운영자는 수동으로 DB를 켜고 끌 필요 없음.

 

Answer: D

요구사항 
저장: Amazon S3 Standard, 파일 최소 128KB, 수백만 개
접근: 90일 초과 파일은 다운로드가 드묾
목표: 가장 많이 쓰는 파일은 쉽게 접근 가능하게 하면서 스토리지 비용 절감
조건: 가장 비용 효율적인 방법

D. 90일 후 S3 Standard → S3 Standard-IA로 전환하는 S3 수명 주기 정책 구현
1. 역할
    S3 수명 주기 정책으로 객체가 90일(또는 91일) 지나면 S3 Standard-IA로 자동 전환되게 설정.
    90일 미만: S3 Standard 유지 → 자주 쓰는 파일은 그대로 빠른 접근.
    90일 초과: Standard-IA로 이동 → 저장 단가가 낮아져 비용 절감.
2. 요구사항 충족
    “90일보다 오래된 벨소리는 다운로드가 드묾” → 90일을 기준으로 저장 계층만 바꾸면 됨.
    “가장 많이 액세스하는 파일을 쉽게 유지” → 최근(90일 미만) 객체는 Standard에 두면 됨.
    “스토리지 비용 절감” → 오래된 객체만 Standard-IA로 옮기면 됨.
수명 주기 정책은 추가 요금 없이 사용 가능하고, 90일 기준이 명확해 가장 비용 효율적인 구성이 됨.

 

Answer: B

요구사항 
저장소: Amazon S3, 의료 시험 결과
접근:
    일부 과학자: 새 파일 추가만 가능
    그 외 모든 사용자: 읽기 전용
제한: 어떤 사용자도 저장소의 파일을 수정·삭제할 수 없음
보존: 생성일로부터 최소 1년 보관

B. 보존 기간 365일의 규정 준수 모드(Compliance Mode)에서 S3 Object Lock 사용
1. 불변성·삭제 방지
    S3 Object Lock은 WORM(Write Once Read Many) 으로, 설정된 보존 기간 동안 객체 삭제·덮어쓰기를 막음.
    규정 준수 모드(Compliance Mode) 는 보존 기간 동안 어떤 권한으로도 삭제·덮어쓰기를 우회할 수 없음 (루트 포함).
    따라서 “어떤 사용자도 수정·삭제할 수 없음”을 정책이 아닌 스토리지 수준에서 보장함.

 

2. 1년 보존
    보존 기간 365일로 설정하면, 객체 생성일로부터 최소 1년 동안 삭제·덮어쓰기가 불가능함.
    “생성일로부터 최소 1년 보관” 요구를 충족함.

 

3. 과학자: 새 파일만 추가
    Object Lock이 있는 버킷에서도 새 객체 PUT은 가능함.
    과학자에게는 s3:PutObject (및 필요 시 버킷/접두사 제한)만 부여하고, s3:DeleteObject, s3:PutObjectLegalHold 등은 부여하지 않으면 “새 파일 추가만, 수정·삭제 불가”가 됨.

 

4. 그 외 사용자: 읽기 전용
s3:GetObject 등 읽기만 허용하는 IAM/버킷 정책으로 “읽기 전용” 제한을 둠.

거버넌스 모드는 s3:BypassGovernanceRetention 권한이 있으면 보존을 우회해 삭제할 수 있음.

 

Answer: C

요구사항 
대상: 기밀 미디어 파일 캐싱, 전 세계 사용자가 안정적으로 접근
저장: Amazon S3 버킷
조건: 요청 지리적 위치와 관계없이 콘텐츠를 빠르게 제공

C. Amazon CloudFront 배포 후 S3 버킷을 CloudFront 오리진(엣지 서버)에 연결
1. 캐싱
    CloudFront는 CDN으로, 오리진(S3)에서 가져온 콘텐츠를 전 세계 엣지 로케이션에 캐시함.
    “기밀 미디어 파일 캐싱”은 CloudFront 캐시를 사용하는 구성으로 충족함 (필요 시 비공개 오리진·OAC 등으로 보안 강화).

 

2. 지리적 위치와 무관한 빠른 전달
    사용자가 어디에 있든 요청은 가장 가까운 엣지로 가고, 캐시에 있으면 엣지에서 바로 응답함.
    “요청의 지리적 위치에 관계없이 콘텐츠를 신속하게 제공” 요구와 정확히 맞음.

 

3. S3 연결
    S3 버킷을 CloudFront 오리진으로 두면, 캐시 미스 시 CloudFront가 S3에서 가져와 엣지에 캐시한 뒤 사용자에게 전달함.
    “S3 버킷을 … 연결”은 S3를 CloudFront 오리진으로 연결하는 것으로 이해하면 됨.

CloudFront 는 로컬 캐시를 사용하여 응답을 제공하고, AWS Global Accelerator 는 요청을 프록시하고 응답을 위해 항상 애플리케이션에 연결합니다.

 

Answer: A, E

요구사항 
데이터: 다른 DB의 배치 + 네트워크 센서·앱 API의 라이브 스트림
목표: 한 곳으로 통합 → 비즈니스 분석
처리: 수신 데이터 처리 후 다른 Amazon S3 버킷에 준비
사용: 일회성 쿼리 + BI 도구로 가져와 KPI 대시보드
제약: 가장 적은 운영 오버헤드

 

E. AWS Lake Formation 청사진으로 수집 대상 식별 + AWS Glue로 크롤·추출·Parquet으로 S3 로드
1. 역할
    Lake Formation 청사진: 데이터 레이크에 어떤 데이터를 수집할지 정의·식별.
    AWS Glue: 소스 크롤(스키마 발견) → 추출 → Apache Parquet으로 S3에 로드.
    배치(다른 DB)는 Glue ETL로 S3에 넣고, 스트림은 별도로 Kinesis Firehose 등으로 S3에 적재한 뒤 같은 레이크(S3)로 통합하는 패턴에 잘 맞음.

 

2. 효과
    “모든 데이터를 한 곳으로 통합” → S3 데이터 레이크.
    “수신 데이터를 처리한 다음 다른 S3 버킷에 준비” → Glue ETL + Parquet → S3로 충족.
    Glue·Lake Formation은 관리형이라 운영 오버헤드가 적음.

 

A. 일회성 쿼리에 Amazon Athena, KPI 대시보드에 Amazon QuickSight
1. 역할
    Athena: S3에 준비된 데이터에 SQL로 일회성 쿼리 실행. 서버리스라 클러스터 관리 없음.
    QuickSight: Athena(또는 S3)에 연결해 KPI 대시보드 생성. AWS 관리형 BI.
2. 효과
    “일회성 쿼리” → Athena.
    “비즈니스 인텔리전스 도구로 가져와 KPI 표시” → QuickSight.
    둘 다 관리형이라 운영 오버헤드 최소.
E는 “수집·통합·S3 준비”, A는 “쿼리·시각화(KPI)”를 담당하는 조합입니다.

 

Answer:  D, E

요구사항 

Aurora PostgreSQL DB 클러스터에 데이터 저장
데이터: 5년 보관 후 모두 삭제
감사 로그: DB 내 작업 감사 로그 무기한 보관
현재: Aurora 자동 백업 구성됨

E. AWS Backup으로 백업 수행 + 5년 보관
1. 역할
    Aurora 자동 백업은 최대 35일 보존만 지원하므로, 5년 보관은 자동 백업만으로는 불가능함.
    AWS Backup으로 Aurora를 백업 대상에 넣고, 백업 플랜에서 보존 기간 5년 후 삭제(또는 콜드 스토리지 후 삭제) 규칙을 두면 됨.

2. 효과
    “모든 데이터를 5년간 보관하고 5년이 지나면 삭제” → AWS Backup 보존 규칙으로 충족.
    자동 백업을 넘어서는 장기 보관·삭제 정책을 한 곳에서 관리할 수 있음.

 

D. DB 클러스터에 대한 Amazon CloudWatch Logs 내보내기 구성
1. 역할
    Aurora는 DB 로그(오류 로그, 느린 쿼리, 감사 로그 등)를 CloudWatch Logs로 내보내기할 수 있음.
    DB 클러스터에서 로그 내보내기를 켜고, CloudWatch Logs 로그 그룹에 만료하지 않음(무기한 보관) 을 설정하면 됨.
2. 효과
    “데이터베이스 내에서 수행되는 작업의 감사 로그를 무기한으로 유지” → CloudWatch Logs 내보내기 + 무기한 보존으로 충족.

 

Answer: A

요구사항 
실시간 스트리밍: 공연 영상 실시간 전송
온디맨드 스트리밍: 공연 영상 주문형 재생
전 세계 온라인 시청자
목표: 실시간·온디맨드 둘 다 성능 향상

A. Amazon CloudFront
1. 역할
CloudFront는 전 세계 엣지 로케이션을 가진 CDN으로, 오리진(미디어 서버·S3·MediaPackage 등)에서 받은 스트리밍 콘텐츠를 엣지에서 캐시·전달함.

 

2. 온디맨드 스트리밍
    영상 파일이 엣지에 캐시되면, 시청자는 가장 가까운 엣지에서 받음.
    전 세계 시청자에게 지연·대역폭 측면에서 성능이 좋아짐.

 

3. 실시간 스트리밍
    라이브 오리진(예: MediaLive → MediaPackage)을 CloudFront 오리진으로 두면, 실시간 스트림이 엣지로 전달되어 전 세계 시청자에게 저지연·고품질로 배포됨.
    HLS/DASH 등 스트리밍 프로토콜도 CloudFront로 제공 가능함.

 

4. 정리
실시간·온디맨드 둘 다 “엣지에서 전달”로 성능을 높이는 서비스는 CloudFront임.

B (AWS Global Accelerator)
트래픽 라우팅(고정 IP, 저지연)용이라 콘텐츠 캐싱을 하지 않음.
온디맨드는 캐시가 있어야 대량 시청자에게 효율적이므로, “실시간·온디맨드 둘 다 성능 향상”에는 CloudFront가 더 적합함.

 

Answer: C,A

요구사항
구성: 공개 서버리스 앱 (API Gateway + Lambda)
문제: 봇넷의 사기성 요청으로 트래픽 급증
목표: 승인되지 않은 사용자의 요청을 차단

A. 정품 사용자에게만 공유하는 API 키로 사용량 계획 생성
1. 역할
    API Gateway 사용량 계획(Usage Plan) 에 API 키를 연결하면, API 키가 있는 요청만 허용할 수 있음.
    정품 사용자(앱·파트너 등)에게만 API 키를 공유하면, 키가 없는 봇·사기 요청은 403 등으로 차단됨.
2. 효과

    “승인되지 않은 사용자” = API 키가 없는 호출자 → 차단.
    봇넷은 보통 키를 모르므로, 승인된 클라이언트만 통과시킬 수 있음.

 

C. 악성 요청을 대상으로 AWS WAF 규칙 구현 및 필터링
1. 역할
     AWS WAF를 API Gateway 앞에 두고, IP 평판, 요청 속도(rate), 지역, 알려진 악성 패턴 등으로 규칙을 만들어 차단·필터링함.
악성 요청은 Lambda가 실행되기 전에 WAF에서 걸러짐.
2. 효과
    봇넷·사기성 트래픽을 엣지에서 차단 → Lambda 호출·비용·부하 감소.
    “승인되지 않은 사용자”(악성 봇·사기 요청)를 규칙 기반으로 차단하는 단계가 됨.

 

A는 “누가 호출할 수 있는지”(API 키), C는 “어떤 요청을 막을지”(WAF 규칙)를 담당하는 이중 방어 조합입니다.

 

Answer: C

요구사항 
용도: 분석 앱 데이터 백업용 재해 복구
데이터: JSON, 약 300MB/월
접근: 필요한 경우 밀리초 단위로 액세스 가능해야 함
보관: 30일 보관
목표: 가장 비용 효율적인 솔루션

C. Amazon S3 Standard
1. 밀리초 단위 액세스
    S3 Standard는 객체 GET 시 즉시(밀리초) 반환됨.
    “필요한 경우 밀리초 단위로 액세스” 조건을 충족함.
    S3 Glacier(B) 는 검색에 수 시간~수십 시간이 걸려 “밀리초 액세스” 요구를 만족하지 못함.

 

2. 30일 보관
    S3 수명 주기로 30일(또는 31일) 후 삭제하거나, 30일만 보관하는 정책으로 구성 가능함.
3. 비용 효율
    300MB/월 수준이면 S3 Standard 요금이 매우 낮음.
    JSON 백업을 객체로 저장하기에 적합하고, 별도 DB·클러스터를 돌릴 필요가 없어 백업/DR 용도로 비용 효율적임.
4. 재해 복구
    다른 리전·다른 계정으로 복제(CRR) 하거나, 버전 관리·수명 주기와 조합해 DR 구성이 가능함.

 

Answer: B

요구사항 
현재: JSON 처리 → 결과를 온프레미스 SQL DB에 저장하는 소형 Python 앱
실행: 매일 수천 번
목표: AWS로 이전, 확장성 최대화, 운영 오버헤드 최소화, 고가용성

B. JSON을 S3에 넣고, S3 도착 시 Lambda(Python)로 처리 후 Aurora에 저장
1. 확장성
    Lambda는 동시 실행 수가 자동으로 늘어나며, “매일 수천 번” 실행에도 별도 용량 설계 없이 대응 가능함.
    S3는 문서 수·용량이 늘어나도 자동 확장됨.
    Aurora도 스토리지·연결 수가 자동 확장되어, “확장성 최대화”에 잘 맞음.
2. 운영 오버헤드 최소화
    Lambda: 서버·OS·패치·스케일링을 관리할 필요 없음.
    S3: 스토리지 관리형.
    Aurora: DB 관리형.
    S3 이벤트로 “문서 도착 시 Lambda 실행”만 연결하면 되어, EC2·ECS·EBS를 직접 다루는 A·C·D보다 운영 부담이 적음.
3. 고가용성
    Lambda·S3·Aurora 모두 다중 AZ·관리형으로 고가용성 제공.
    별도 장애 조치 구성을 하지 않아도 기본적으로 고가용성에 가깝게 동작함.
4. 흐름
JSON 문서를 S3에 넣음 → S3 이벤트로 Lambda(Python) 호출 → Lambda가 JSON 처리 → 결과를 Aurora에 저장.
“JSON 처리 → SQL DB에 결과 저장” 요구를 그대로 만족하면서, 위 세 가지 목표를 모두 충족함.

 

Answer:  A

요구사항 
용도: HPC 인프라(재무 위험 모델링), Linux
구성: 워크플로당 수백 대 EC2 스팟, 단기 실행, 수천 개 출력 파일 → 영구 스토리지에 저장
필요
1. 온프레미스 데이터를 장기 영구 스토리지로 복사
2. 모든 EC2 인스턴스가 그 데이터를 처리할 수 있어야 함
3. 영구 스토리지와 통합된 고성능 파일 시스템으로 데이터 세트·출력 파일 읽기/쓰기

A. Amazon S3와 통합된 Amazon FSx for Lustre
1. 고성능 공유 파일 시스템
    FSx for Lustre는 Linux HPC용 병렬 파일 시스템으로, 수백 대 EC2가 동일한 네임스페이스를 마운트해 고대역폭·저지연으로 읽기/쓰기할 수 있음.
    “모든 EC2 인스턴스에서 데이터를 처리” + “고성능 파일 시스템” 요구를 Lustre가 충족함.

 

2. 영구 스토리지(S3) 통합
    FSx for Lustre는 S3 버킷을 데이터 리포지토리로 연결할 수 있음.
    S3 → Lustre: S3에 넣은 온프레미스 데이터·데이터 세트를 Lustre를 통해 HPC 워크로드가 고성능으로 읽음.
    Lustre → S3: 워크플로 출력을 Lustre에 쓰면 자동으로 S3에 내보내기 가능 → 영구 보관 및 이후 분석·장기 사용.
    “영구 스토리지와 통합된 고성능 파일 시스템”으로 읽기/쓰기 요구를 FSx for Lustre + S3가 만족함.

 

3. 온프레미스 → 영구 스토리지
    온프레미스 데이터를 S3로 복사(DataSync, Snowball 등)하면, Lustre가 S3와 연결되어 있으므로 같은 데이터를 HPC 인스턴스들이 Lustre를 통해 사용할 수 있음.
    “온프레미스 데이터를 장기 영구 스토리지로 복사”는 S3가 담당함.

 

Answer: A

요구사항 
현재: 온프레미스 컨테이너화 앱 → AWS로 이전
부하: 배포 직후 수천 명 사용자
고민: 규모에 맞는 컨테이너 배포 관리 방법
목표: 운영 오버헤드 최소화 + 고가용성 아키텍처

A. ECR에 이미지 저장 + ECS(Fargate)로 실행 + 대상 추적으로 자동 확장
1. 컨테이너 배포·확장 관리
    Amazon ECS가 컨테이너 오케스트레이션을 담당해, 태스크 수·배포·헬스체크를 관리함.
    대상 추적(Target Tracking) 으로 CPU 등 지표를 목표값에 맞춰 자동 확장하므로, “수천 명” 트래픽에 맞춰 용량이 늘어남.
    “규모에 맞게 컨테이너 배포를 관리하는 방법”을 ECS + 대상 추적으로 해결함.
2. 운영 오버헤드 최소화
    Fargate를 쓰면 컨테이너 호스트(EC2) 를 직접 두지 않아도 됨.
    서버 프로비저닝·OS 패치·용량 계획을 AWS가 담당하므로, ECS on EC2(B) 보다 운영 부담이 적음.
    ECR은 관리형 레지스트리라 이미지 저장·버전 관리만 하면 됨.
3. 고가용성
    ECS 서비스가 여러 가용 영역에 태스크를 분산하고, Fargate가 인프라 가용성을 관리함.
    대상 추적으로 부하에 맞춰 태스크 수가 유지되므로 고가용성에 부합함.
4. 정리
    ECR: 이미지 저장
    ECS Fargate: 서버 없이 컨테이너 실행
    대상 추적: 수요에 따른 자동 확장
→ “운영 오버헤드 최소화” + “고가용성” + “규모에 맞는 컨테이너 배포 관리”를 모두 만족하는 것은 A임.

 

Answer: C

요구사항 
발신자 앱: 처리할 페이로드가 포함된 메시지 전송
처리 앱: 해당 메시지 수신·처리
용량: 약 1,000개/시간
처리 시간: 메시지당 최대 2일 소요 가능
실패 시: 처리 실패 메시지는 보관하고, 나머지 메시지 처리에는 영향 없음
목표: 위를 만족하면서 운영상 가장 효율적인 솔루션

C. 발신자·처리 앱을 Amazon SQS와 연동 + 처리 실패 메시지는 배달 못 한 편지 대기열(DLQ)로 수집
1. 역할
    SQS는 메시지 큐로, 발신자가 큐에 메시지 전송, 처리 앱이 큐에서 메시지 수신·처리하는 구조에 적합함.
    배달 못 한 편지 대기열(DLQ) 을 두고, 최대 수신 횟수를 넘긴 메시지는 자동으로 DLQ로 이동하도록 설정함.
2. 장시간 처리(최대 2일)
    SQS visibility timeout으로 메시지가 처리 중일 때 다른 소비자가 받지 못하게 함.
    기본 최대 12시간이면, ChangeMessageVisibility로 처리 중에 visibility timeout을 연장해 2일에 가까운 처리도 가능함.
    1,000개/시간 규모는 SQS로 충분히 처리 가능함.
3. 실패 시 나머지에 영향 없음
    처리 실패·재시도 초과 메시지는 DLQ로 이동해 메인 큐에서 제거됨.
    나머지 메시지는 메인 큐에서 계속 처리되므로, “처리 실패 메시지가 나머지 처리에 영향을 주지 않도록 보관” 요구를 충족함.
4. 운영 효율
    SQS·DLQ는 관리형이라 큐·재시도·DLQ 전달을 AWS가 처리함.
    Redis·EC2(A)나 Kinesis(B)처럼 인프라·스트림을 직접 관리할 필요가 없어 운영상 가장 효율적인 선택임.

 

Answer: D

요구사항 
구성: 정적 웹사이트, S3 오리진 + Amazon CloudFront
보안 정책: 모든 웹사이트 트래픽이 AWS WAF에서 검사되어야 함

D. OAI로 S3 접근 제한 + 배포에서 AWS WAF 활성화
1. 모든 트래픽 WAF 검사
    CloudFront 배포에 AWS WAF Web ACL을 연결하면, 해당 배포로 들어오는 모든 요청이 WAF를 거친 뒤 캐시/오리진으로 처리됨.
    “배포에서 AWS WAF를 활성화” = CloudFront 배포에 WAF Web ACL을 연결하는 것을 의미하므로, 모든 웹사이트 트래픽이 WAF에서 검사되도록 할 수 있음.

 

2. S3 접근 제한
    원본 액세스 ID(OAI) 로 CloudFront만 S3에 접근하도록 하면, 사용자는 CloudFront(→ WAF) 경로로만 접근 가능하고, S3로의 직접 접근은 차단됨.
    OAI + S3 버킷 정책으로 “CloudFront(OAI)만 S3 접근”을 구현하는 것이 일반적인 패턴임.

 

3. 정리
D는 (1) OAI로 S3 접근 제한, (2) 배포에서 WAF 활성화를 모두 포함하므로, “모든 트래픽 WAF 검사” + “S3 보호” 요구를 충족함

 

Answer: D

요구사항 
내용: 글로벌 이벤트 일일 보고서를 정적 HTML로 온라인 게시
트래픽: 전 세계 사용자 수백만 조회
저장: Amazon S3 버킷
목표: 효율적이고 효과적인 솔루션 설계

D. S3 버킷을 오리진으로 Amazon CloudFront 사용
1. 효과적(성능·접근성)
    CloudFront는 전 세계 엣지 로케이션에서 콘텐츠를 캐시함.
    사용자는 가장 가까운 엣지에서 HTML을 받으므로 지연 시간이 줄고, 수백만 조회를 안정적으로 처리할 수 있음.
    “전 세계 사용자, 수백만 조회”에 맞는 표준 구성임.
2. 효율적(비용·부하)
    캐시 적중이 많아지면 S3로 가는 요청이 줄어들어 S3 비용·부하가 감소함.
    S3 한 버킷만 두고, 엣지 캐시로 전 세계를 커버하므로, 여러 리전에 S3를 복제하는 것보다 단순하고 비용 효율적임.
3. 구현
    S3 버킷을 CloudFront 오리진으로 두고, 정적 HTML을 해당 오리진에서 제공하도록 설정하면 됨.
    “S3 버킷과 함께 Amazon CloudFront를 오리진으로 사용”은 “CloudFront 배포의 오리진으로 S3 버킷을 사용”하는 의미로 이해하면 됨.

 

Answer: D

요구사항 
구성: 프로덕션 앱, EC2 플릿에서 SQS 메시지 병렬 처리
트래픽: 예측 어렵고, 간헐적
목표: 다운타임 없이 지속적으로 메시지 처리
제약: 가장 비용 효율적인 솔루션

D. 기본 예약 + 추가 온디맨드
1. “다운타임 없이 지속적으로”
    스팟 인스턴스는 회수(interruption) 될 수 있어, 추가 용량까지 스팟에 의존하면 트래픽이 많을 때 스팟이 줄어들어 처리 지연·백로그가 생길 수 있음.
    “가동 중지 시간이 없어야 한다”는 요구에는 중단 위험이 있는 스팟은 적합하지 않음.
    따라서 추가 용량도 온디맨드(D) 로 두는 것이 맞고, C(추가 용량 스팟) 는 오답.

 

2. “예측 불가·간헐적 트래픽”
     예약 인스턴스만으로 “필요한 최대 용량”까지 채우면(B), 예측 가능한 부하에 맞는 구매가 되어 간헐적·예측 불가 트래픽에는 비효율적임.
     기본(최소) 용량만 예약으로 두고, 나머지는 온디맨드로 두는 D가 “예측 불가·간헐적”에 맞음.

 

3. 비용·유연성
    기본 용량: 예약 인스턴스 → 항상 켜 둘 최소 인스턴스 비용 절감.
    추가·변동 트래픽: 온디맨드 → 중단 없이 유연하게 확장.
C보다 버스트 비용은 더 나가지만, “다운타임 없음”을 지키려면 D가 정답.

C (예약 + 스팟): 추가 용량에 스팟 사용 → 스팟 회수 시 처리 지연/백로그 가능 → “다운타임 없음”과 충돌.

 

Answer: D

요구사항 
대상: 조직 내 모든 AWS 계정에서 특정 서비스 또는 작업에 대한 액세스 제한
조직: AWS Organizations의 대규모 조직에 속함
조건: 확장 가능, 권한을 유지할 수 있는 단일 지점

D. 루트 조직 단위(OU)에 서비스 제어 정책(SCP)을 만들어 해당 서비스 또는 작업에 대한 액세스를 거부
1. 역할
    서비스 제어 정책(SCP) 은 조직 단위(OU) 또는 루트에 연결해, 그 OU(및 하위 OU)에 속한 모든 계정에 최대 권한을 제한함.
    루트 OU에 SCP를 두면 조직 전체에 적용되므로, “모든 계정”에서 특정 서비스/작업을 거부할 수 있음.
2. 단일 지점
    루트 OU의 SCP 한 곳에서 정책을 관리하면, 모든 계정에 동일한 제한이 적용됨.
    “권한을 유지할 수 있는 단일 지점” 요구를 충족함.

3. 확장 가능
    새 계정을 조직에 추가하면 자동으로 해당 SCP가 적용됨.
    계정별로 정책을 따로 만들 필요가 없어 확장 가능함.
4. 서비스/작업 제한
     SCP에서 Deny 효과로 특정 서비스(예: 특정 AWS 서비스) 또는 작업(API 액션)을 거부하면, 해당 조직 내 계정의 모든 IAM 주체에 상한이 걸림.

 

Answer: C

 

요구사항 
- 공용 웹 애플리케이션, ALB 사용
- DDoS 공격 위험 감소가 목표

C. AWS Shield Advanced
AWS Shield Advanced는 DDoS 전용 서비스입니다.
L3/L4/L7 DDoS에 대한 상시 탐지 및 자동 완화
ALB, CloudFront, Route 53, Elastic IP 등에 적용 가능
공격 시 확장 비용 보상, 24/7 DRT 지원, 상세 보고
DDoS “위험을 줄이는” 요구에 가장 직접적으로 맞는 서비스입니다.

 

Answer: C
 
요구사항 

- ALB 뒤 EC2에서 웹 애플리케이션 실행
- 특정 국가에서만 애플리케이션 접근 허용 (지역 제한)

C. VPC 의 Application Load Balancer 에서 AWS WAF 를 구성합
AWS WAF에는 Geo Match(지리적 매치) 조건이 있습니다.
요청 출발 국가(국가 코드) 기준으로 허용/차단 규칙을 만들 수 있습니다.
“특정 국가에서만 액세스” 요구사항에 그대로 대응합니다.
WAF는 ALB에 연결할 수 있으므로, VPC 내 ALB 앞단에서 트래픽을 필터링할 수 있습니다.
국가별 허용 목록만 관리하면 되고, IP 목록을 직접 관리할 필요가 없습니다.

 

Answer: B

요구사항 
- 항목 가격 기반 세금 계산 조회 API
- 연휴에 문의 급증 → 응답 지연
- 확장 가능하고 탄력적인(elastic) 설계 필요

 

B. Amazon API Gateway 를 사용하여 REST API 를 설계합니다. API Gateway 는 세금 계산을 위해 항목 이름을 AWS Lambda 에 전달
API Gateway + Lambda 조합이 “확장 가능·탄력적” 요구에 가장 잘 맞습니다.
Lambda: 동시 실행 수가 요청 수에 맞춰 자동으로 늘어나고, 연휴처럼 트래픽이 급증해도 별도 용량 설계 없이 대응 가능합니다.
API Gateway: REST API 진입점으로, 호출 수에 따라 자동으로 스케일됩니다.
사용량 기반 과금: 요청이 없을 때는 비용이 거의 없고, 연휴에만 많이 써도 그때만 비용이 늘어납니다.
세금 계산처럼 요청당 짧은 연산에 적합한 패턴입니다

 

Answer: C

요구사항 
- CloudFront 배포, 사용자가 제출하는 민감한 정보 존재
- HTTPS 사용 중이지만 추가 보안 계층 필요
- 민감한 정보는 전체 스택에서 보호되어야 함
- 정보에 대한 액세스는 특정 애플리케이션으로만 제한되어야 함

C. 필드 수준 암호화 프로필을 구성
필드 수준 암호화는 요청 안의 특정 필드(예: 신용카드, SSN)만 암호화하는 기능입니다.
뷰어 → CloudFront → 오리진 구간 전체에서 해당 필드는 암호화된 상태로 전달됩니다.
복호화는 오리진에 키를 가진 특정 애플리케이션만 할 수 있으므로, “정보에 대한 액세스를 특정 애플리케이션으로 제한”하는 요구와 정확히 맞습니다.
“민감한 정보를 전체 애플리케이션 스택에서 보호” = 데이터(내용) 자체를 암호화하는 것이고, 이는 필드 수준 암호화가 담당하는 역할입니다

 

Answer: B

요구사항 
- 브라우저 기반 앱, S3에 저장된 비디오·이미지 제공
- 모든 사용자에게 동일한 정적 콘텐츠
- 전 세계 수백만 사용자가 미디어 접근
- 오리진 부하 감소 + 사용자에게 파일 제공
가장 비용 효율적인 방법 필요

 

Amazon CloudFront
CloudFront는 S3 정적 콘텐츠용으로 가장 적합하고 비용 효율적입니다.
    캐시: 첫 요청만 S3(오리진)로 가고, 이후는 엣지에서 응답 → 오리진 부하 크게 감소
    글로벌 배포: 전 세계 엣지 로케이션에서 응답 → 수백만 사용자에게 낮은 지연
    서버 없음: EC2/캐시 서버를 둘 필요 없이 사용량만큼 과금
S3 + CloudFront 조합은 정적 미디어 배포의 표준 패턴이며, 캐시 히트로 S3 요청·트래픽이 줄어 비용이 낮아집니다

 

Answer: B

요구사항 
ALB 뒤 단일 가용 영역(AZ)에 EC2 Auto Scaling 그룹, 웹 서버 6대
애플리케이션 수정 없이 인프라만으로 고가용성(HA) 확보 필요

 

2 개의 가용 영역 각각에서 3 개의 인스턴스를 사용하도록 Auto Scaling 그룹을 수정
- 고가용성의 기본은 한 리전 안에서 여러 AZ에 분산하는 것입니다.
- Auto Scaling 그룹을 2개 AZ에 걸치도록 수정하면:
    AZ당 3대씩 총 6대로 용량 유지
    한 AZ 장애 시에도 나머지 AZ의 3대가 서비스 유지
- ALB는 여러 AZ의 서브넷을 등록해 두면 자동으로 각 AZ로 트래픽을 나누므로, 인프라만 변경하면 되고 애플리케이션 변경은 필요 없습니다.

 

Answer: B

요구사항 

API Gateway + Lambda → Aurora PostgreSQL 주문 처리
판매 시 주문 급증 → 타임아웃, 일부 주문 미처리
원인: DB에 열린 연결이 많아서 CPU·메모리 사용률 상승

 

B. Amazon RDS 프록시를 사용하여 데이터베이스에 대한 프록시를 생성 RDS 프록시 엔드포인트를 사용하도록 Lambda 함수를수정

Amazon RDS Proxy는 애플리케이션(Lambda)과 DB 사이에 두는 연결 풀링 서비스입니다.
Lambda 동시 실행이 많아도, Proxy가 소수의 DB 연결만 유지하고 여러 Lambda 요청을 그 연결들에 나눠 씁니다.
DB 쪽 연결 수·부하 감소 → CPU·메모리 안정 → 타임아웃 완화.
최소 변경: Lambda의 DB 연결 설정만 Aurora 엔드포인트 → RDS Proxy 엔드포인트로 바꾸면 됩니다. 애플리케이션 로직 변경은 거의 없습니다.

 

Answer: A

요구사항 
- 프라이빗 서브넷의 EC2에서 실행되는 애플리케이션
- DynamoDB 테이블 접근 필요
- 트래픽이 AWS 네트워크를 벗어나지 않도록 하면서
- 가장 안전한 방법 선택

A. DynamoDB 용 VPC 엔드포인트를 사용
DynamoDB용 VPC 엔드포인트(Gateway 타입)를 쓰면:
    EC2 → DynamoDB 구간 트래픽이 VPC와 AWS 백본 안에서만 이동합니다.
    인터넷, IGW, NAT를 거치지 않으므로 트래픽이 AWS 네트워크를 벗어나지 않습니다.
퍼블릭 인터넷 노출이 없고, VPC 엔드포인트 정책으로 접근을 제한할 수 있어 가장 안전한 방식입니다.

 

Answer: B

요구사항 
- DynamoDB에 미디어 메타데이터 저장
- 읽기 집약적, 지연 발생
- 추가 운영 인력 없음 → 관리 부담 최소
- 애플리케이션 재구성 없이 DynamoDB 성능 개선

B. Amazon DynamoDB Accelerator(DAX)
- DAX는 DynamoDB 전용 인메모리 캐시로, DynamoDB와 동일한 API를 사용합니다.
- 앱은 엔드포인트만 DynamoDB → DAX로 바꾸면 됩니다. GetItem, Query, Scan 등 기존 호출 방식 유지 → 애플리케이션 재구성 불필요.
- 읽기 요청이 DAX에서 캐시되면 지연 시간이 크게 줄어들고, DynamoDB로 가는 읽기 부하도 감소합니다.
- 완전 관리형이라 캐시 서버 운영·패치 등 추가 운영 부담이 거의 없습니다.

 

Answer: A

요구사항
- 단일 리전에 EC2 + RDS
- 다른 리전에 데이터 백업
- 최소한의 운영 부담으로 구현

AWS Backup

- AWS Backup은 EC2(EBS), RDS를 포함해 여러 서비스의 백업을 한 곳에서 관리하는 서비스입니다.
- 백업 플랜에서 리전 간 복사(Cross-Region Copy)를 설정하면, 백업이 자동으로 다른 리전으로 복사됩니다.
- EC2(EBS)와 RDS를 동일한 백업 플랜으로 처리할 수 있어, 한 번 설정해 두면 운영 부담이 적습니다.
- 백업·복사·수명 주기를 자동화하므로 “최소한의 운영 오버헤드” 요구에 맞습니다.

 

Answer: A

요구사항 
- RDS 접속용 DB 사용자명·암호를 안전하게 보관
- Systems Manager Parameter Store에 보안(암호화) 파라미터로 저장
- 이 파라미터를 EC2에서 실행 중인 애플리케이션이 읽어야 함

 

A. Parameter Store 읽기 + KMS Decrypt 권한이 있는 IAM 역할을 만들어 EC2에 연결
EC2에서 다른 AWS 서비스를 호출하려면 IAM 역할(Instance Profile)을 인스턴스에 연결해야 합니다. 정책만으로는 EC2에 권한을 줄 수 없습니다.
Parameter Store 보안 파라미터는 KMS로 암호화되므로, 파라미터 값을 읽으려면:
1. Parameter Store 읽기 권한: 해당 파라미터에 대한 ssm:GetParameter 등
2. KMS Decrypt 권한: 파라미터 암호화에 사용된 KMS 키에 대한 kms:Decrypt
이 두 권한을 가진 IAM 역할을 만들고, 그 역할을 EC2 인스턴스에 할당하면 EC2 위 앱이 파라미터를 안전하게 읽을 수 있습니다.

 

Answer:  B, C 

요구사항 
- 외부 사용자 → API Gateway → NLB → EC2
- SQL 인젝션 등 웹 익스플로잇 차단
- 대규모·정교한 DDoS 탐지 및 완화

B. NLB와 함께 AWS Shield Advanced 사용 
- Shield Advanced는 대규모·정교한 DDoS에 대한 탐지·완화용 서비스입니다.
- NLB, Elastic IP, EC2 등 리소스를 보호할 수 있고, 24/7 DRT, 비용 보호, 상세 보고를 제공합니다.
- “대규모 정교한 DDoS 감지 및 완화” 요구에 맞는 선택입니다.

 

C. Amazon API Gateway에 AWS WAF 사용 
- AWS WAF는 SQL 인젝션, XSS 등 웹 익스플로잇을 막는 서비스입니다.
- WAF는 API Gateway, ALB, CloudFront 등에 연결할 수 있고, NLB에는 연결할 수 없습니다 (NLB는 L4).
- 이 아키텍처에서는 외부 트래픽이 API Gateway로 들어오므로, WAF는 API Gateway에 연결해야 SQL 인젝션 등 웹 공격을 막을 수 있습니다.

 

WAF는 NLB에 연결되지 않습니다. NLB는 L4 로드 밸런서라 WAF 지원 대상이 아닙니다

 

Answer: A

요구사항
- C2 레거시 → ECS 마이크로서비스로 전환
- 마이크로서비스 간 통신 방식 권장
- 데이터는 순차 처리해도 되고, 결과 순서는 불필요 (비동기·디커플링에 적합)

A. Amazon SQS 큐 사용 (생산자 → 큐 전송, 소비자 → 큐에서 처리)
Amazon SQS는 서비스 간 비동기 메시지 전달에 맞는 서비스입니다.
생산자: 메시지를 SQS 큐에 전송
소비자: 큐에서 메시지를 꺼내 처리 (처리 속도·순서는 소비자 쪽에서 제어)
메시지가 큐에 보관되어 내구성이 있고, 소비자가 실패하면 재시도·다시 처리할 수 있어 데이터 처리 시나리오에 잘 맞습니다.
여러 소비자(ECS 서비스)가 같은 큐를 구독해 수요에 맞춰 확장하기 쉽고, “결과 순서 불필요” 조건과도 맞습니다

 

Answer: B

요구사항 
- 온프레미스 MySQL을 AWS로 마이그레이션
- 과거 DB 중단으로 비즈니스 영향 발생 → 재발 방지
- 데이터 손실 최소화
- 모든 트랜잭션을 최소 2개 노드에 저장 (안정적인 복제)
- 안정적인 AWS DB 솔루션 (관리형 서비스 선호)

 B. 다중 AZ가 활성화된 Amazon RDS MySQL DB 인스턴스 생성(동기 복제)
Amazon RDS Multi-AZ는 다음을 만족합니다.
동기식 복제: 프라이머리에서 커밋된 트랜잭션이 스탠바이(다른 AZ)에 동기로 복제된 뒤에만 커밋이 완료됩니다. → “모든 트랜잭션을 최소 2개 노드에 저장”.
데이터 손실 최소화: 동기 복제이므로 프라이머리 장애 시에도 스탠바이에는 이미 동일 데이터가 있습니다.
고가용성: 프라이머리 장애 시 자동 페일오버로 스탠바이가 프라이머리로 전환됩니다.
RDS는 완전 관리형이므로 “안정적인 AWS 데이터베이스 솔루션” 요구에 맞습니다.

C 는 성능향상(읽기 분산)

 

Answer: A

요구사항
- 동적 주문 웹사이트
- 서버 유지보수·패치 최소화
- 고가용성
- 읽기·쓰기 용량을 가능한 한 빨리 확장 (수요 변화 대응)

A. S3 + API Gateway/Lambda + DynamoDB 온디맨드 + CloudFront
1. 서버 유지보수 최소화
    S3, API Gateway, Lambda, DynamoDB, CloudFront는 서버리스/완전 관리형이라 EC2처럼 OS·미들웨어 패치할 서버가 없습니다.

 

2. 고가용성
    위 서비스들은 다중 AZ·다중 엣지로 구성되어 있어 가용성 요구를 충족합니다.

3. 읽기·쓰기 용량을 빠르게 확장
    DynamoDB 온디맨드는 읽기·쓰기 모두 트래픽에 맞춰 자동·즉시 확장됩니다.

 

용량 단위를 미리 정하지 않아도 되고, 급격한 트래픽 증가에도 빠르게 대응할 수 있어 “가능한 한 빨리 읽기·쓰기 용량 확장”에 가장 잘 맞습니다.

 

Answer: A

요구사항
- Direct Connect 한 쌍으로 온프레미스 데이터 센터와 연결
- 가상 프라이빗 게이트웨이(VGW)로 비 VPC 트래픽 라우팅 (실제로는 VPC에 VGW가 연결되어 온프레미스로 라우팅)
- Lambda가 온프레미스 프라이빗 서브넷의 DB에 접근해야 함

 

A. 적절한 보안 그룹으로 Lambda 함수를 VPC에서 실행되도록 구성
- Lambda가 온프레미스에 도달하려면 VPC를 거쳐서 VGW → Direct Connect → 온프레미스 경로를 타야 합니다.
- Lambda를 VPC에 연결하면:
    Lambda가 해당 VPC의 서브넷에 ENI(VPC 안의 가상 네트워크 카드 Elastic Network Interface)를 갖게 되고,
    트래픽이 해당 서브넷의 라우트 테이블을 따릅니다.
- VPC에 이미 VGW가 붙어 있고 온프레미스 CIDR(IP 주소 범위를 한 번에 나타내는 표기법, Classless Inter-Domain Routing)로 가는 라우트가 있다면, Lambda → 서브넷 → VGW → Direct Connect → 온프레미스 DB로 통신할 수 있습니다.
보안 그룹으로 Lambda ENI의 아웃바운드에서 DB IP/포트만 허용하면, 요구사항을 만족하면서 최소 권한으로 구성할 수 있습니다.

 

Answer: B

요구사항
- ECS에서 실행 중인 애플리케이션이 S3 API로 이미지를 S3에 저장
- 이 애플리케이션이 S3에 접근할 권한을 갖도록 해야 함

B. S3 권한이 있는 IAM 역할을 만들고, 작업 정의의 taskRoleArn으로 지정
ECS 태스크(컨테이너) 안에서 돌아가는 애플리케이션이 AWS API(S3 등)를 호출할 때 쓰는 권한은 태스크 역할(Task Role)입니다.
태스크 역할은 작업 정의(Task Definition)의 taskRoleArn에 지정합니다.
따라서
    S3 읽기/쓰기 권한을 가진 IAM 역할을 만들고
    그 역할을 작업 정의에서 taskRoleArn으로 지정하면
컨테이너 안 앱이 S3 API를 호출할 때 이 역할의 자격 증명을 사용해 S3 접근 권한을 갖게 됩니다.

 

Answer: B

요구사항
- Windows 기반 애플리케이션을 AWS로 마이그레이션
- 여러 가용 영역에 흩어진 여러 EC2 Windows 인스턴스가
- 하나의 공유 Windows 파일 시스템을 사용해야 함

B. Windows 파일 서버용 Amazon FSx 구성 후, 각 Windows 인스턴스에 FSx 파일 시스템 마운트
 Amazon FSx for Windows File Server는 AWS가 관리하는 Windows 네이티브(SMB) 공유 파일 시스템입니다.
 SMB를 사용하므로 Windows EC2에서 네트워크 드라이브처럼 마운트 가능합니다.
한 파일 시스템을 여러 Windows 인스턴스가 동시에 공유할 수 있습니다.
다중 AZ 구성 지원으로 여러 AZ에 있는 EC2에서 접근할 수 있습니다.
“여러 AZ의 여러 EC2 Windows 인스턴스가 쓰는 공유 Windows 파일 시스템” 요구에 맞는 서비스입니다.

 

Answer: A, D

요구사항
- 로드 밸런싱된 프론트엔드 + 컨테이너 기반 앱 + 관계형 DB 전자상거래
- 고가용성(HA) + 가능한 한 적은 수동 개입

A. 다중 AZ 모드에서 Amazon RDS DB 인스턴스 생성 
RDS Multi-AZ는 프라이머리 1대 + 다른 AZ에 스탠바이 1대를 두는 구성입니다.
동기 복제 + 장애 시 자동 페일오버로 DB 계층 고가용성을 제공합니다.
페일오버·백업·패치는 AWS가 처리하므로 수동 개입이 적습니다.

 

D. Fargate 시작 유형으로 Amazon ECS 클러스터 생성 
ECS Fargate는 컨테이너용 서버리스 컴퓨팅입니다.
EC2 인스턴스를 직접 관리할 필요가 없어 패치·용량 관리 등 수동 작업이 줄어듭니다.
ECS 서비스로 여러 AZ에 태스크를 분산해 고가용성을 확보할 수 있습니다.
“동적 애플리케이션 로드”는 서비스 오토스케일링으로 대응 가능합니다.

 

Answer: A

요구사항
- S3를 데이터 레이크로 사용
- 새 파트너가 SFTP로 데이터 파일 업로드 필요
- 고가용성 SFTP 솔루션
- 운영 오버헤드 최소화

A. AWS Transfer Family로 공개 엔드포인트 SFTP 서버 구성 후 S3 데이터 레이크를 대상으로 지정
AWS Transfer Family(SFTP)는 완전 관리형 SFTP 서비스입니다.
파트너가 SFTP 클라이언트로 공개 엔드포인트에 연결해 파일을 올리면, 바로 S3에 저장되도록 설정할 수 있습니다 (별도 EC2·스크립트 불필요).
고가용성: AWS가 다중 AZ에서 서비스를 제공해 가용성이 높습니다.
운영 최소화: SFTP 서버·OS·cron·VPN을 직접 관리할 필요가 없고, 사용자/권한과 S3 버킷만 설정하면 됩니다.

[파트너/고객]  -- SFTP 클라이언트 --►  [AWS Transfer Family 엔드포인트]
                                                                                            │
                                                                                           ▼
                                                                            [Amazon S3 버킷]
                                                                                    (또는 EFS)

 

Answer: B, D

요구사항
- 계약 문서 5년 보관
- 5년 동안 덮어쓰기·삭제 불가 (WORM)
- 미사용 문서 암호화
- 매년 암호화 키 자동 교체
- 최소 운영 오버헤드

B. Amazon S3에 저장 + 규정 준수(Compliance) 모드 S3 객체 잠금 
S3 Object Lock으로 객체를 잠그면 지정한 기간 동안 덮어쓰기·삭제가 불가합니다.
규정 준수(Compliance) 모드:
보관 기간을 줄이거나 잠금을 해제할 수 없음 (루트 포함).
5년 보관 기간을 설정하면 그 기간 동안 변경·삭제가 불가능해 “5년 동안 덮어쓰기·삭제 불가” 요구를 충족합니다.
거버넌스 모드(A)는 특정 권한으로 보관 기간 변경이 가능해 이 요구보다 느슨합니다.

D. AWS KMS 고객 관리형 키로 서버 측 암호화 + 키 순환 구성
KMS 고객 관리형 키(CMK)로 S3 서버 측 암호화(SSE-KMS)를 사용하면 문서가 암호화되어 저장됩니다.
고객 관리형 키에서 자동 키 순환을 활성화하면 KMS가 매년(365일) 키 자료를 자동으로 순환합니다.
키 생성·순환을 AWS가 처리하므로 “매년 자동 키 교체”를 최소 운영으로 만족합니다.

 

Answer: B

요구사항 
- Java·PHP 기반 웹 애플리케이션을 온프레미스 → AWS로 이전
- 새 기능을 자주 테스트할 수 있어야 함
- 고가용성 + 관리형 + 최소 운영 오버헤드

B. Elastic Beanstalk에 배포 + URL 스와핑으로 여러 환경 전환
AWS Elastic Beanstalk은 Java·PHP 플랫폼을 지원해, 기존 Java/PHP 앱을 그대로 올리기 좋습니다.
관리형: 용량, 로드 밸런서, 헬스 체크, 패치 등을 AWS가 처리해 운영 부담이 적습니다.
고가용성: 다중 AZ, ALB 기반으로 구성 가능합니다.
새 기능 자주 테스트:
    여러 환경(예: 프로덕션, 스테이징, 기능 테스트용)을 두고
    새 버전을 테스트 환경에 배포한 뒤
    URL 스와핑으로 테스트 환경과 프로덕션 환경의 URL을 바꿔서, 검증된 버전을 바로 “라이브”로 전환할 수 있습니다.
→ “새 사이트 기능을 자주 테스트” 요구에 맞습니다.

AWS Elastic Beanstalk은 개발자가 애플리케이션 코드만 올리면, AWS가 실행에 필요한 인프라(EC2, 로드 밸런서, Auto Scaling 등)를 자동으로 만들고 관리해 주는 PaaS(Platform as a Service)입니다.

Elastic Beanstalk이 하는 일
    개발자: 애플리케이션(코드 + 설정)만 배포
    AWS: 그에 맞는 환경(Environment)을 만들어 줌
          EC2, ALB, Auto Scaling, 모니터링, 배포 방식 등
즉, “애플리케이션 중심”으로 배포하고, 인프라 세부 사항은 최소한만 다루게 해 줍니다.
EC2/ALB를 직접 만들지 않아도 되고, 필요하면 그 아래 리소스에 접근해 세밀하게 조정할 수 있습니다.

 

Answer: A

요구사항

- RDS MySQL에 고객/주문 데이터 저장
- 정규 업무 시간에 직원이 보고용 일회성 쿼리 실행
- 보고 쿼리가 오래 걸려서 주문 처리에서 타임아웃 발생
- 보고 쿼리는 그대로 두되, 주문 처리 타임아웃만 제거해야 함

A. 읽기 전용 복제본 생성 후, 보고 쿼리를 읽기 전용 복제본으로 보냄
읽기 전용 복제본(Read Replica)은 프라이머리 DB의 비동기 복제본으로, 읽기 전용입니다.
보고 쿼리만 읽기 복제본으로 보내면:
    프라이머리에는 주문 처리(쓰기 + 읽기)만 가므로 부하가 줄어들고, 타임아웃이 사라질 수 있습니다.
    보고 쿼리는 복제본에서 실행되므로, 직원이 쿼리를 막지 않으면서 주문 처리와 보고를 분리할 수 있습니다.
애플리케이션/직원 도구에서 보고용 연결만 읽기 복제본 엔드포인트로 바꾸면 되므로, 변경 범위가 작고 요구사항에 정확히 맞습니다.

 

Answer: B, E

 

요구사항 
- 대규모 의료 기록 디지털화, 매일 수백 건 추가
- 문서 스캔 → 업로드 후:
    문서 분석
    의료 정보 추출
    저장
    SQL로 쿼리 가능
확장성·운영 효율 극대화

B. 문서 정보를 S3에 저장 + Amazon Athena로 SQL 쿼리 
S3: 문서·추출 결과 저장, 용량 제한 없이 확장 가능.
Amazon Athena: S3에 있는 데이터(Parquet, JSON 등)를 표준 SQL로 조회. 서버리스라 운영 부담이 적음.
“대규모·매일 수백 건”에 맞고, “SQL 쿼리”와 “확장성·운영 효율”을 만족합니다.

E. 새 문서 업로드 시 Lambda 실행 + Textract(문서→텍스트) + Comprehend Medical(텍스트→의료 정보) 
Lambda: S3에 새 문서가 올라올 때만 실행 → 서버리스, 확장성·운영 효율 좋음.
Amazon Textract: 스캔 문서/PDF에서 텍스트·폼·테이블 추출(문서→원시 텍스트)에 적합.
Amazon Comprehend Medical: 텍스트에서 의료 개체(약물, 질환, 처치 등) 감지·추출에 사용.
문서 분석·의료 정보 추출 파이프라인을 서버리스로 구현하는 올바른 조합입니다.

 

Answer: A

요구사항
- EC2에서 배치 애플리케이션 실행
- 백엔드에 여러 Amazon RDS 데이터베이스
- 읽기가 많아서 DB 부하 발생
- 데이터베이스 읽기 수를 줄이면서 고가용성 확보

A. Amazon RDS 읽기 전용 복제본 추가
RDS 읽기 전용 복제본(Read Replica)은 읽기 부하 분산용으로 쓰는 RDS 기능입니다.
    쓰기는 프라이머리만 사용하고, 읽기는 복제본(들)으로 보내면 프라이머리로 가는 읽기 수가 줄어듭니다.
    애플리케이션에서 읽기용 연결만 복제본 엔드포인트로 바꾸면 되므로, RDS만으로 읽기 수(프라이머리 기준)를 줄일 수 있습니다.
고가용성: 복제본을 다른 가용 영역에 두면 읽기 가용성도 높아지고, 프라이머리 장애 시 복제본을 승격할 수 있습니다.
RDS 환경에서 “읽기 많음 → 읽기 수 줄이기 + 고가용성”에 대한 표준 답이 읽기 전용 복제본입니다.

 

Answer: A

요구사항
- EC2에 데이터베이스 구동 (RDS 아님)
- 고가용성
- 중단 시 자동 장애 조치

A. 같은 리전의 서로 다른 가용 영역에 EC2 2대 + DB 설치 + 클러스터 구성 + DB 복제
- 서로 다른 가용 영역(AZ)에 EC2 2대: 한 AZ 장애 시 다른 AZ의 인스턴스가 서비스 유지 → 고가용성 확보.
- 양쪽 EC2에 DB 설치 + DB 복제: Primary–Standby(또는 Master–Replica)로 데이터 동기/비동기 복제.
- 클러스터 구성: Pacemaker/Corosync, DB 내장 클러스터 등으로 Primary 장애 시 Standby를 자동으로 Primary로 승격 → 자동 장애 조치.
- EC2 기반 DB에서 “고가용성 + 자동 장애 조치”를 만족하는 표준 패턴입니다.

 

Answer: C

요구사항 
- 주문 시스템 → EC2로 요청 전송 → EC2가 처리 후 RDS에 저장
- 문제: 시스템 장애 시 주문이 유실되어 사용자가 다시 주문해야 함
- 요구: 시스템 중단 시에도 주문이 유실되지 않고, 자동으로 처리되는 탄력적인 구조

C. EC2를 Auto Scaling 그룹으로 + 주문 시스템은 SQS로 전송 + EC2는 큐에서 메시지 소비
1. Amazon SQS를 쓰면 주문을 메시지로 큐에 넣고, EC2가 큐에서 꺼내 처리하는 비동기·디커플링 구조가 됩니다.
    주문 시스템: 주문을 SQS 큐에 전송 (HTTP로 EC2에 직접 보내지 않음)
    EC2: 큐를 폴링해서 메시지(주문)를 가져와 처리 후 삭제
2. 탄력성:
    큐에 들어간 메시지는 SQS에 보관되므로, EC2가 죽거나 처리 중 실패해도 주문(메시지)은 유지됩니다.
    가시성 타임아웃 후 메시지는 다시 큐에 나타나 다른 EC2나 복구된 EC2가 다시 처리할 수 있습니다.
3. Auto Scaling 그룹: EC2 수를 조절해 주문 부하에 맞춰 확장·축소 가능합니다.
따라서 “중단 시에도 주문이 유실되지 않고 자동으로 처리되는 탄력적인 솔루션” 요구를 충족합니다.

 

Answer: D

요구사항 
- 대규모 EC2에서 DynamoDB에 읽기·쓰기
- 테이블 크기는 계속 증가, 앱은 최근 30일 데이터만 필요
- 비용·개발 노력 최소화

D. 앱에서 만료 시각(현재+30일) 속성 추가 + DynamoDB TTL로 해당 속성 사용
DynamoDB TTL(Time To Live)은 지정한 숫자(Unix 타임스탬프) 속성을 기준으로, 만료된 항목을 DynamoDB가 자동 삭제하는 기능입니다.

구성:
   앱 수정: 새 항목 쓸 때 “현재 시각 + 30일”을 Unix 타임스탬프로 계산해 한 속성(예: expiration)에 저장.
   DynamoDB: 테이블에서 TTL 속성을 그 속성으로 설정.

 

비용: 삭제는 DynamoDB가 처리하므로 추가 서비스·Lambda·EC2 불필요, 비용 최소.
개발: 앱에 속성 하나 추가 + 테이블에 TTL 한 번 설정으로 끝나서 개발·운영 부담이 가장 적습니다.

 

Answer: B, E

요구사항
- 온프레미스 Windows Server에서 Microsoft .NET 앱 실행
- Oracle Database Standard Edition 사용
- AWS로 마이그레이션 예정
- 개발 변경 최소화 (리팩터링 최소)
- 고가용성 AWS 환경

B. .NET 플랫폼으로 AWS Elastic Beanstalk에서 다중 AZ로 재호스팅 
Elastic Beanstalk은 .NET(Windows) 플랫폼을 지원합니다.
재호스팅(Rehost): 기존 .NET 앱을 그대로 Beanstalk에 올리면 되므로, 플랫폼·코드 변경을 최소화할 수 있습니다.
다중 AZ 배포로 EC2·ALB를 여러 AZ에 두면 고가용성을 만족합니다.
“.NET 앱을 최소 변경으로 AWS에 올리고 고가용성으로” 요구에 맞는 선택입니다.

E. 다중 AZ에서 AWS DMS로 Oracle → Amazon RDS for Oracle 마이그레이션 
RDS for Oracle은 동일한 Oracle 엔진을 사용하므로, 앱은 연결 문자열(엔드포인트) 정도만 바꾸면 됩니다. SQL·스키마·쿼리 로직은 그대로 둘 수 있어 개발 변경이 최소입니다.
AWS DMS로 온프레미스 Oracle의 스키마·데이터를 RDS Oracle로 이전할 수 있습니다.
다중 AZ RDS로 DB 계층 고가용성을 확보할 수 있습니다.
“Oracle을 최소 변경으로 AWS로 옮기고 고가용성으로” 요구에 맞는 선택입니다.

 

Answer: D

요구사항 
- 온프레미스 Kubernetes에서 컨테이너화된 앱 실행
- MongoDB로 데이터 저장
- 일부 환경을 AWS로 마이그레이션
- 코드 변경·배포 방식 변경 불가
- 운영 오버헤드 최소화

D. EKS + Fargate(컴퓨팅) + Amazon DocumentDB(MongoDB 호환, 데이터 스토리지)
1. Amazon EKS: AWS 관리형 Kubernetes 서비스입니다.
    기존에 쓰던 Kubernetes(kubectl, manifest, Helm 등)를 그대로 사용할 수 있어 배포 방식 변경이 없습니다.
2. EKS + Fargate: 컨테이너를 Fargate에서 실행하면 작업자 노드(EC2)를 직접 관리할 필요가 없어 패치·용량 관리 등 운영 오버헤드가 줄어듭니다.
3. Amazon DocumentDB (MongoDB 호환): MongoDB API/프로토콜을 지원하므로, 앱은 MongoDB 드라이버·연결 문자열만 DocumentDB 엔드포인트로 바꾸면 됩니다. DB 관련 코드 변경을 최소화할 수 있습니다.

 

따라서 “Kubernetes 유지 + 코드·배포 방식 변경 최소 + 운영 최소화” 요구를 모두 만족합니다.

 

Answer: B

요구사항
- 고객 콜 센터 기능 (음성 통화 기반)
- 여러 화자 인식 (누가 말했는지 구분)
- 대본(성적표) 파일 생성
- 대본 파일을 쿼리해 비즈니스 패턴 분석
- 기록(녹음) 파일은 감사 목적으로 7년 보관

B. Amazon Transcribe(여러 화자 인식) + Amazon Athena(성적표 파일 분석)
- Amazon Transcribe는 음성→텍스트 변환 서비스이며 화자 분리(Speaker Diarization)를 지원합니다.
    통화 녹음(오디오)을 넣으면 화자별로 구분된 대본을 만들어 줍니다 (Speaker 1, Speaker 2 등).
    “여러 화자 인식 + 대본 파일 생성” 요구에 맞는 서비스입니다.
- Amazon Athena는 S3에 있는 파일을 SQL로 조회하는 서비스입니다.
    Transcribe 결과(대본)는 보통 S3에 저장되므로, Athena로 대본 파일을 쿼리해 비즈니스 패턴 분석을 할 수 있습니다.
녹음 파일·대본 파일은 S3에 저장하고, 필요 시 S3 수명 주기·객체 잠금 등으로 7년 보관 정책을 적용할 수 있습니다.

 

Answer: D

요구사항
- Amazon Cognito로 사용자 관리
- 사용자 로그인 후 API Gateway REST API로 DynamoDB 데이터 조회
- REST API 접근 제어를 AWS 관리형으로 구현
- 개발·운영 부담 최소화

 D. API Gateway에서 Amazon Cognito 사용자 풀 권한 부여자 구성
- API Gateway의 Cognito 사용자 풀 권한 부여자(Cognito User Pool Authorizer)는 Cognito와 API Gateway를 직접 연결하는 기능입니다.
    클라이언트가 Authorization 헤더에 Cognito에서 발급한 JWT(ID 토큰/액세스 토큰)를 넣어 요청하면,
    API Gateway가 그 토큰을 Cognito에 보내 검증합니다.
    검증 성공 시에만 API를 호출할 수 있게 됩니다.
- AWS 관리형: 토큰 검증은 Cognito가 수행하고, 별도 Lambda·커스텀 인증 로직을 만들 필요가 없습니다.
- 개발 최소화: 이미 Cognito로 로그인하고 있다면, 앱은 로그인 후 받은 JWT를 API 요청 시 Authorization 헤더에 넣기만 하면 됩니다.
- 운영 최소화: 인증용 Lambda·API 키 검증 로직을 유지보수할 필요가 없습니다.