AWS SAA-C03 Dump 501-550
Answer: C
요구사항
고객 결제 데이터를 Amazon S3 기반 회사 데이터 레이크로 수집
평균 1분마다 결제 데이터 수신 (스트리밍 수준)
결제 데이터를 실시간으로 분석 필요
그 다음 데이터 레이크로 수집
위를 가장 효율적으로 만족하는 방법 선택
C. Amazon Kinesis Data Firehose로 수집, Amazon Kinesis Data Analytics로 실시간 분석
Kinesis Data Firehose는 스트리밍 데이터 수집 후 S3 등으로 전달하는 서비스라, “결제 데이터를 데이터 레이크(S3)로 수집”에 적합함.
Kinesis Data Analytics는 Firehose(또는 스트림) 를 소스로 실시간 분석(SQL 또는 Flink)을 할 수 있어, “결제 데이터를 실시간으로 분석” 요구를 충족함.
Firehose로 수집·S3 적재와 실시간 분석을 한 파이프라인으로 구성할 수 있어, “가장 효율적으로” 충족함.
틀린 이유
A. Kinesis Data Streams + Lambda로 실시간 분석은 가능하지만, 데이터 레이크(S3)로의 수집은 Firehose를 붙이거나 Lambda가 S3에 쓰는 식으로 별도 구성이 필요함. “수집 → 실시간 분석 → 데이터 레이크”를 한 번에 담는 구성에는 Firehose + Data Analytics(C)가 더 적합함.
B. AWS Glue는 배치 ETL용이라, “1분마다 수신”하는 스트리밍 수집에는 맞지 않음. 실시간 수집·분석에는 Kinesis Firehose·Data Analytics(C)가 맞음.
D. API Gateway + Lambda는 요청·응답 기반이라, 스트리밍 수집 → S3 데이터 레이크 패턴에는 Kinesis Firehose(C)가 더 적합하고, 실시간 분석도 Data Analytics(C)가 스트리밍에 맞음.
Answer: C, E
요구사항
EC2에서 CMS로 웹사이트 운영
단일 EC2 + Aurora MySQL Multi-AZ 데이터 계층
웹사이트 이미지는 EC2에 마운트된 EBS에 저장
웹사이트 성능·복원력 개선을 위한 작업 조합 2개 선택
C. 웹사이트 이미지를 모든 EC2 인스턴스에 마운트된 Amazon EFS로 이동
단일 EC2 + EBS는 단일 장애점이고, 인스턴스를 늘려도 이미지를 공유하기 어렵다. EFS로 이미지를 옮기고 모든 EC2에서 마운트하면, 여러 인스턴스가 같은 이미지를 쓰게 되어 복원력·확장성이 좋아진다.
EFS는 관리형·다중 AZ라 이미지 스토리지의 가용성도 높아진다. CMS가 쓰는 파일 경로를 그대로 쓸 수 있어 애플리케이션 변경을 줄일 수 있다.
E. 기존 EC2에서 AMI 생성, ALB 뒤 ASG로 최소 2대 프로비저닝, 웹사이트용 CloudFront 배포 구성
단일 EC2를 ASG 최소 2대 + ALB로 바꾸면, 한 대가 나가도 다른 대가 트래픽을 받아 복원력이 좋아진다. AMI로 기존 EC2 구성을 그대로 새 인스턴스에 쓸 수 있다.
CloudFront를 웹사이트 앞에 두면 정적 콘텐츠(이미지) 를 엣지에서 캐시해 응답 속도(성능) 가 좋아진다.
C + E로 이미지 공유(EFS) + 다중 인스턴스(ASG·ALB) + 엣지 캐시(CloudFront) 를 맞추면 성능·복원력 요구를 충족한다.
틀린 이유
A. S3를 “모든 EC2에 탑재”하는 방식은 s3fs·File Gateway 등으로 가능하지만, 지연·일관성 측면에서 EFS보다 불리한 경우가 많고, CMS가 쓰는 파일 경로를 그대로 쓰기에는 EFS(C)가 더 적합하다.
B. 기본 EC2의 NFS 공유를 쓰면, 그 EC2가 나가면 이미지에 접근할 수 없어 복원력이 개선되지 않는다. EFS(C)는 관리형·다중 AZ라 이미지 스토리지 복원력에 유리하다.
D. Global Accelerator는 엣지 캐시를 하지 않는다. 웹사이트 정적 이미지 성능 개선에는 CloudFront(E)가 맞고, D는 “성능·복원력 개선” 요구를 E만큼 잘 충족하지 못한다.
Answer: A
요구사항
회사: 인프라 모니터링 서비스 운영
목표: 고객 AWS 계정의 EC2·CloudWatch를 가장 안전하게 조회
필요: 고객 계정에서 EC2 Describe, CloudWatch 지표 읽기 API 호출
A. 고객이 회사 계정을 신뢰하는 IAM 역할을 자신의 계정에 만들고, 읽기 전용 EC2·CloudWatch 권한을 부여하는지 확인
크로스 계정 역할 + AssumeRole: 고객 계정에 IAM 역할을 두고, 신뢰 정책으로 회사 계정(또는 회사 측 IAM 역할)만 이 역할을 Assume 하도록 제한. 회사는 STS AssumeRole로 임시 자격 증명만 사용.
장기 자격 증명 불필요: 액세스 키/비밀 키를 만들거나 저장할 필요가 없어 유출·로테이션 부담이 없음.
최소 권한: 해당 역할에 EC2·CloudWatch 읽기 전용만 부여하면 됨.
고객 주도: 역할·신뢰 정책·권한을 고객 계정에서 관리하므로, 고객이 “누가 내 계정에 들어올 수 있는지”를 명확히 통제·감사할 수 있음.
AWS가 권장하는 크로스 계정 액세스 패턴(역할 + AssumeRole)과 일치함.
틀린 이유
B. 토큰 판매기는 회사 측 구현 방식에 가깝고, 그 아래에 “고객이 만든 역할 + 신뢰 정책”이 있어야 함. “가장 안전하게 고객 계정 접근 권한을 얻는 방법”의 정답은 고객이 역할·신뢰 정책을 갖추는지 확인하는 A.
C. IAM 사용자 + 장기 액세스/비밀 키는 유출·로테이션 위험이 있고, 암호화 저장이라도 장기 자격 증명이라는 점에서 역할 기반 임시 자격 증명보다 덜 안전함.
D. Cognito는 앱 사용자 인증(웹/모바일)용이며, AWS 리소스(EC2·CloudWatch)에 대한 크로스 계정 API 액세스를 얻는 시나리오와 맞지 않음.
Answer: C
요구사항
규모: 수백 개 AWS 계정, us-east-1의 여러 VPC
조직: 네트워킹 팀이 클라우드 네트워크 관리를 위한 전용 AWS 계정 보유
목표: VPC들을 연결하되 운영상 가장 효율적인 방식 선택
C. 네트워킹 팀 계정에 Transit Gateway 생성, 각 VPC에서 TGW로 정적 경로 구성
허브-스포크 한 곳 관리: Transit Gateway(TGW)는 리전당 하나의 허브로, 수천 개 VPC·VPN·DX를 붙일 수 있어 네트워킹 팀 계정에서 중앙 관리 가능.
규모에 맞는 연결 수: VPC 피어링은 N개 VPC당 O(N²) 개 연결이 필요하지만, TGW는 VPC당 TGW attachment 1개만 필요해 수백 계정·다수 VPC에서 운영 부담이 적음.
크로스 계정 지원: RAM(Resource Access Manager)으로 TGW를 공유하거나 크로스 계정 attachment를 사용해 “네트워킹 팀 계정 하나 + 수백 계정 VPC” 구조 구현 가능.
관리형 서비스: TGW는 AWS 관리형이라 Transit VPC처럼 VPN 터미널용 EC2·소프트웨어 라우팅을 직접 운영할 필요가 없음.
경로 구성: 각 VPC의 라우팅 테이블에서 TGW attachment로 가는 경로(정적 또는 전파)만 두면 되므로 운영이 단순함.
틀린 이유
A. VPC 피어링은 1:1이라 VPC가 많을수록 필요한 피어링 수가 N×(N−1)/2로 급증하고, 새 VPC마다 기존 VPC 모두와 피어링·경로 테이블을 갱신해야 해서 수백 계정에서는 운영 효율이 떨어짐.
B. VPC 간 트래픽을 인터넷(NAT·IGW)으로 보내는 구성은 보안·지연·비용 측면에서 부적절하고, NAT 게이트웨이는 VPC-to-VPC 허브 연결 용도가 아님.
D. Transit VPC(각 VPC에 VPN 게이트웨이 + 중앙 전송 VPC)는 TGW 이전 방식으로, VPN 터널·EC2 기반 라우팅을 직접 관리해야 해서 운영 부담이 크고, 같은 목적이라면 TGW(C)가 더 효율적임.
Answer: C
요구사항
워크로드: 야간 배치 작업(데이터 처리), EC2 인스턴스
환경: 온디맨드 결제 Auto Scaling 그룹
내결함성: 한 인스턴스 실패 시 다른 인스턴스가 재처리
실행 시간: 현지 시간 매일 00:00~06:00(하루 6시간)
목표: 위 조건을 만족하면서 가장 비용 효율적인 EC2 제공
C. Auto Scaling 그룹용 새 시작 템플릿에서 스팟 인스턴스 사용, CPU 기반 확장 정책 적용
스팟 = 큰 할인: 스팟은 온디맨드 대비 최대 90% 수준 할인으로, 같은 용량을 쓰더라도 비용이 가장 낮음.
배치에 적합: “한 인스턴스 실패 시 다른 인스턴스가 재처리” → 중단 허용 가능한 배치이므로 스팟 중단을 재시도/재처리로 흡수 가능.
야간 6시간만 사용: 00:00~06:00만 사용하면 스팟을 쓰는 시간만 과금되고, 나머지 18시간은 인스턴스가 없으면 비용 없음(ASG 스케일 인/0 가능).
CPU 기반 확장: 배치 부하에 맞춰 CPU 사용량으로 인스턴스 수를 늘리거나 줄이면, 필요한 만큼만 스팟을 써서 비용 절감.
시작 템플릿: 기존 ASG는 유지한 채 새 시작 템플릿만 스팟으로 바꾸면 되므로 도입이 단순함.
틀린 이유
A. 1년 EC2 절약 플랜은 약정 기반 할인이라 비용은 줄어들 수 있으나, 스팟보다 할인 폭이 작고 6시간/일만 쓰는 변동 워크로드에는 스팟이 더 비용 효율적임.
B. 1년 예약 인스턴스는 24시간 기준으로 약정하는데, 실제 사용은 하루 6시간뿐이라 나머지 18시간은 예약 비용만 내고 쓰지 않게 되어 비효율적임.
D. 인스턴스 크기만 키우고 CPU 기반 확장을 쓰는 것은 단가를 올리는 것이어서 비용 절감이 아니라 오히려 비용 증가 가능성이 큼.
Answer: C
요구사항
기능: 사용자가 웹사이트에서 사진 업로드
트래픽: 대규모 이벤트 시 수요 급증 예상
목표: 업로드 트래픽을 가장 확장성 있게 처리하는 방식
C. 앱에서 S3 presigned URL 발급, 사용자 브라우저가 해당 URL로 S3에 직접 업로드
앱 서버 우회: 파일 데이터가 애플리케이션 서버를 거치지 않고, 브라우저 → S3로 직접 전송되어 앱 서버가 병목이 되지 않음.
S3 확장성: S3는 대용량·고동시 업로드를 처리하도록 설계되어 있어, 이벤트 시 트래픽 급증에도 대응 가능.
앱 부하는 최소: 앱은 “presigned URL 생성”만 하면 되므로 CPU·메모리·네트워크 부하가 작고, 업로드 수가 늘어나도 서버 스케일을 크게 늘릴 필요가 없음.
표준 패턴: 대용량 업로드를 웹에서 받을 때 권장하는 “presigned URL + 직접 S3 업로드” 패턴과 일치함.
틀린 이유
A. 브라우저 → 앱 서버 → S3 구조는 모든 업로드 트래픽이 앱 서버를 통과해, 대규모 이벤트 시 앱 서버가 병목이 되고 확장성에 불리함.
B. Storage Gateway 파일 게이트웨이는 온프레미스·NFS/SMB용이며, 브라우저에서 직접 업로드하는 대규모 웹 트래픽 수용용이 아니고, 용도도 다름.
D. EFS는 NFS 프로토콜로 EC2 등에서 마운트해 쓰는 공유 파일시스템이며, 브라우저가 “직접” 업로드할 수 있는 구조가 아니고, 대량 업로드 수집에는 S3가 적합함.
Answer: A
요구사항
앱: 여행 발권 웹 애플리케이션, 현재 북미 단일 데이터 센터 DB 기반
목표: 글로벌 사용자 대상으로 앱을 여러 AWS 리전에 배포
제약: 웹은 리전별로 따로 배포, 예약 DB는 전 세계적으로 일관된 단일 기본 DB 유지
성능: 예약 DB 업데이트 시 평균 지연 시간 1초 미만
A. 앱을 DynamoDB로 전환하고, 중앙 예약 테이블에 전역 테이블(Global Tables) 사용, 리전별로 해당 리전 엔드포인트 사용
리전별 쓰기: DynamoDB 전역 테이블은 리전마다 복제본을 두고, 각 리전 배포는 해당 리전의 엔드포인트로 읽기·쓰기. 업데이트 요청이 원격 리전이 아니라 사용자와 가까운 리전으로 가므로 쓰기 지연이 짧음(보통 수십 ms 수준).
1초 미만 충족: 쓰기가 사용자와 같은 리전에서 처리되므로 글로벌 사용자도 예약 업데이트 시 평균 대기 시간을 1초 미만으로 유지하기 쉬움.
단일 논리 테이블: 전역 테이블은 하나의 예약 테이블이 여러 리전에 자동 복제되는 구조라, “전 세계적으로 일관된 단일 예약 DB” 요구와 맞음(복제는 보통 1초 이내).
리전별 배포와 정합: 앱을 리전별로 배포하고, 각 배포에서 해당 리전 DynamoDB 엔드포인트만 쓰면 되므로 설계가 단순함.
틀린 이유
B. Aurora MySQL + 리전별 읽기 전용 복제본은 쓰기가 한 리전(기본)에만 가능함. 아시아·유럽 사용자의 예약 업데이트는 기본 리전까지 왕복해야 해서 지연이 커지고, 1초 미만을 보장하기 어려움.
C. RDS MySQL + 리전별 읽기 복제본도 쓰기는 기본 리전으로만 가므로 B와 동일한 이유로 글로벌 쓰기 지연 조건을 충족하기 어려움.
D. 리전마다 Aurora Serverless 인스턴스를 두고 Lambda/이벤트 스트림으로 동기화하는 방식은 “단일 기본 DB”가 아니라 다중 DB 동기화 구조이고, 운영이 복잡하며 Aurora의 표준 글로벌 구성도 아님.
Answer: B, D
요구사항
환경: Microsoft Windows Server 워크로드, us-west-1 EC2
현재: 필요할 때만 수동으로 이미지 백업
목표: us-west-1 재해 시 us-west-2에서 빠른 복구, 24시간 이상 데이터 손실 없음(RPO ≤ 24시간), EC2 백업 전부 자동화, 최소 관리
B. EC2 AMI 수명 주기 정책으로 태그 기반 백업 생성, 하루 2회 예약, us-west-2로 복사본 자동 구성
태그 기반·자동 백업: AMI 수명 주기 정책으로 특정 태그가 붙은 EC2만 자동 AMI 생성·정리 가능.
하루 2회: 12시간 간격으로 RPO 12시간 이하, “24시간 이상 데이터 손실 없음” 충족.
리전 복사 자동화: 정책에서 대상 리전 us-west-2를 지정하면 AMI가 us-west-2로 자동 복사되어, 재해 시 해당 리전에서 바로 복구 가능.
관리 최소화: 정책·일정·복사 대상만 설정하면 되고, Lambda 등 추가 구성 불필요.
D. AWS Backup으로 백업 볼트·태그 기반 EC2 백업 계획 생성, 사본 대상 us-west-2 지정, 하루 2회 일정
태그 기반·자동 백업: AWS Backup 백업 계획에서 리소스 태그로 EC2를 선택해 일괄 백업 가능.
하루 2회: 12시간 간격으로 RPO 12시간 이하, 24시간 데이터 손실 제한 충족.
크로스 리전 복사 내장: 백업 계획에서 사본(복사) 대상 리전을 us-west-2로 정의하면 AWS Backup이 자동으로 해당 리전에 복사본 생성·유지.
관리 최소화: Lambda·커스텀 스크립트 없이 백업·복사·일정을 AWS Backup만으로 처리.
틀린 이유
A. 하루 2회 백업은 맞지만, “필요에 따라 이미지를 복사”는 수동 복사라 us-west-2 복사가 자동화되지 않아 재해 복구와 최소 관리 요구를 충족하지 못함.
C. AWS Backup에 크로스 리전 복사 기능이 있음에도 Lambda로 복사를 구현하면 불필요한 운영·관리 부담이 생겨 “최소한의 관리”에 맞지 않음.
E. “요청 시 us-west-2에 복사”는 온디맨드 복사라, 재해 전에 us-west-2에 복사본이 자동으로 준비되지 않아 신속 복구 요구를 충족하기 어려움.
Answer: B
요구사항
환경: 2계층(웹·앱), 2 AZ, 퍼블릭(ALB)·프라이빗(EC2) 서브넷
문제: 앱이 느리게 동작, 보안 감사 결과 소수 IP에서 수백만 건 불법 요청
목표: 영구 대책을 검토하는 동안 즉시 성능 문제 해소(악성 트래픽 차단)
B. 웹 계층(퍼블릭) 서브넷 NACL 수정, 리소스를 소모하는 IP에 대한 인바운드 거부 규칙 추가
NACL은 Deny 지원: 보안 그룹은 Allow만 가능하고, NACL은 Allow/Deny 모두 가능해 특정 IP를 명시적으로 거부할 수 있음.
진입 지점에서 차단: 악성 트래픽이 들어오는 곳은 웹 계층(ALB가 있는 퍼블릭 서브넷). 해당 서브넷 NACL에서 차단하면 ALB·웹 서버에 도달하기 전에 트래픽이 차단됨.
즉시 적용: NACL 규칙 변경만으로 바로 적용되며, 새 서비스 도입 없이 기존 네트워크 설정만 수정하면 됨.
리소스 절약: 차단이 서브넷 경계에서 이루어져 ALB·EC2 연결·CPU 소모가 줄어 성능이 개선됨.
틀린 이유
A. 보안 그룹은 Deny 규칙을 지원하지 않음. Allow만 가능하므로 “해당 IP 거부”를 보안 그룹으로 구현할 수 없음.
C. 앱 계층 보안 그룹 수정은 Deny 미지원이며, 차단해도 트래픽이 이미 ALB·웹 계층을 통과한 뒤라 ALB·연결 리소스 소모는 그대로라 즉시 성능 개선에 불리함.
D. 앱 계층 서브넷 NACL에서 차단하면 요청이 이미 ALB와 웹 계층을 지난 뒤이므로, 악성 트래픽이 진입하는 웹 계층 서브넷(B) 에서 차단하는 것이 맞음.
Answer: C
요구사항
환경: ap-southeast-2·eu-west-1 두 리전에 애플리케이션
통신: eu-west-1 VPC의 앱 → ap-southeast-2 VPC의 DB, 안전하게 통신
목표: 위를 만족하는 네트워크 설계
C. 두 VPC 간 VPC 피어링 구성, 서브넷 경로 테이블 업데이트, ap-southeast-2 DB 보안 그룹에서 eu-west-1 앱 서버 IP(CIDR) 허용
리전 간 VPC 피어링: eu-west-1 VPC와 ap-southeast-2 VPC 간 인터 리전 VPC 피어링을 만들면 두 리전 VPC 간 트래픽이 AWS 백본으로 전달되어 안전하게 통신 가능.
경로 테이블: 피어 연결의 대상 VPC CIDR으로 가는 경로를 각 서브넷 경로 테이블에 추가해야 트래픽이 피어를 통해 전달됨.
리전이 다르면 SG ID 참조 불가: 보안 그룹 규칙의 “소스”에 다른 리전의 보안 그룹 ID를 넣는 것은 지원되지 않음. 따라서 DB 쪽에서는 eu-west-1 앱 서버의 IP(CIDR) 를 소스로 허용해야 함.
규칙 위치: 연결을 시작하는 쪽은 eu-west-1 앱이므로, ap-southeast-2의 DB 보안 그룹에 “eu-west-1 앱 서버 IP(또는 VPC CIDR)에서 오는 인바운드 허용” 규칙을 두는 것이 맞음.
틀린 이유
A. “eu-west-1 애플리케이션 보안 그룹에, ap-southeast-2 DB IP에서 오는 트래픽 허용”은 방향이 반대임. 앱 → DB 연결이므로, 인바운드 허용 규칙은 ap-southeast-2 DB 보안 그룹에 두고, 소스는 eu-west-1 앱(IP/CIDR) 이어야 함.
B. ap-southeast-2 DB 보안 그룹에서 eu-west-1 애플리케이션 서버의 보안 그룹 ID를 소스로 참조하는 방식은 리전이 다르면 지원되지 않음. 리전 간에는 반드시 IP/CIDR 로 허용해야 함.
D. Transit Gateway + 피어링으로 리전 간 연결은 가능하지만, “eu-west-1 애플리케이션 서버의 보안 그룹 ID를 참조하는 인바운드 규칙”은 다른 리전 SG 참조이므로 지원되지 않음. DB SG에서는 eu-west-1 앱의 IP(CIDR) 를 사용해야 함.
Answer: C
요구사항
용도: PostgreSQL 스키마를 쓰는 소프트웨어 개발
구성: 개발자용 여러 개발 환경·DB 필요
사용 패턴: 개발 환경당 평균 8시간 근무의 절반 = 하루 약 4시간만 사용
목표: 위를 가장 비용 효율적으로 만족하는 방식
C. 개발 환경마다 Amazon Aurora 온디맨드(서버리스) PostgreSQL 호환 DB 구성
온디맨드·자동 확장: Aurora Serverless(온디맨드 용량)는 사용량에 따라 용량이 늘었다 줄었다 하므로, 사용하지 않는 시간에는 최소 용량(또는 0.5 ACU 등)으로 과금되어 24시간 풀가동 대비 비용이 적음.
간헐 사용에 유리: 하루 4시간만 쓰는 개발 DB는 24시간 풀가동 Aurora(A)나 RDS(B)보다, 쓰는 시간만큼만 용량·비용이 나가는 Aurora 온디맨드가 더 저렴함.
PostgreSQL 호환: Aurora PostgreSQL 호환이므로 기존 PostgreSQL 스키마·애플리케이션을 그대로 사용 가능.
환경별 분리: 개발 환경마다 별도 Aurora(온디맨드) 클러스터를 두면 환경 분리와 비용 효율을 동시에 만족함.
틀린 이유
A. 개발 환경마다 일반 Aurora PostgreSQL을 두면 클러스터가 24시간 풀가동되어, 하루 4시간만 쓰는 개발 DB에는 비용이 과함. 온디맨드(서버리스)보다 비용 효율이 떨어짐.
B. RDS for PostgreSQL Single-AZ도 24시간 풀가동이라, 사용하지 않는 시간에도 인스턴스 비용이 발생해 간헐적 개발 용도에는 비효율적임.
D. S3 + S3 Select는 객체 스토리지·단순 쿼리용이며, PostgreSQL 스키마·트랜잭션·관계형 DB 기능을 제공하지 않음. “PostgreSQL 데이터베이스 스키마를 사용하는 소프트웨어” 요구를 충족하지 못함.
Answer: A
요구사항
환경: AWS Organizations, 계정·리소스에 태그 사용, AWS Backup으로 인프라 백업
목표: 모든 AWS 리소스를 백업 대상에 포함
제약: 최소한의 운영 오버헤드로 위를 충족
A. AWS Config로 태그가 없는 리소스 찾기 → 프로그래밍으로 태그 부여 → 백업 계획에서 태그로 대상 지정
백업 계획은 태그 기반: AWS Backup 백업 계획은 리소스 태그로 대상을 지정할 수 있어, “이 태그가 있는 리소스는 모두 백업”으로 통일할 수 있음.
누락 원인 = 태그 없음: 태그가 없는 리소스는 태그 기반 계획에 포함되지 않으므로, 태그가 없는 리소스를 찾아 태그를 붙이면 “모든 리소스 백업”에 가까워짐.
Config로 미태그 리소스 식별: AWS Config로 “특정 태그가 없는 리소스”를 규칙/쿼리로 찾고, 리미디에이션(자동 수정) 또는 스크립트로 해당 리소스에 백업용 태그를 부여할 수 있음.
운영 부담 최소: Config 규칙·자동 수정(또는 주기 스크립트)으로 태그를 맞추고, 이후에는 백업 계획이 태그만 보고 자동으로 새 리소스까지 포함하므로 수동 검토를 최소화할 수 있음.
틀린 이유
B. “실행 중이 아닌 모든 리소스”만 식별하면 실행 중인 리소스는 빠져 “모든 리소스 백업” 요구를 충족하지 못함. 또한 리소스를 “백업 볼트에 추가”하는 방식은 AWS Backup의 “백업 계획 + 대상 선택(태그/리소스 유형)” 모델과 맞지 않음.
C. 계정 소유자에게 리소스를 수동 검토·식별하도록 하면 운영 부담이 커져 “최소한의 운영 오버헤드” 요구에 맞지 않음.
D. Amazon Inspector는 취약점 분석용 서비스로, 백업 대상 식별이나 “백업 규정 준수” 리소스 식별 용도가 아님.
Answer: A
요구사항
기능: 사용자가 AWS에서 호스팅되는 앱에 이미지 업로드, 여러 기기 유형에 맞게 자동 리사이즈
트래픽: 하루 종일 예측하기 어려운 트래픽 패턴
목표: 고가용성과 확장성 극대화
A. S3에 정적 웹사이트 호스팅, 업로드 시 Lambda 호출로 이미지 리사이즈 후 S3에 저장
S3 + Lambda: 업로드된 객체에 대해 S3 이벤트로 Lambda를 호출하면, Lambda가 여러 크기로 리사이즈한 뒤 S3에 저장하는 패턴으로 “여러 기기 유형용 자동 리사이즈”를 구현할 수 있음.
확장성 극대화: Lambda는 동시 실행 수가 자동으로 늘어나 예측 불가한 트래픽에도 대응하고, S3도 대용량·고동시 업로드를 처리하도록 설계되어 있어 트래픽 급증에 유리함.
고가용성: S3·Lambda 모두 AWS 관리형 멀티 AZ 서비스라 가용성이 높고, 별도 서버 관리가 필요 없음.
운영 최소화: EC2·ECS·큐 운영 없이 S3 이벤트 + Lambda만으로 리사이즈 파이프라인을 구성할 수 있음.
틀린 이유
B. Step Functions로 리사이즈 후 RDS에 이미지 저장은, 이미지 같은 대용량 바이너리를 RDS에 넣는 비권장 패턴이며, 이미지는 S3에 두는 것이 맞음. 정적 웹 호스팅도 이미지 저장소로 RDS를 쓰는 것은 부적절함.
C. EC2 웹 서버 + EC2에서 리사이즈 프로세스는 인스턴스 수·스케일링을 직접 관리해야 하고, 예측 불가한 트래픽에서 Lambda보다 확장성이 떨어지며 “확장성 극대화” 요구를 충족하기 어려움.
D. ECS + SQS + EC2 리사이저는 구성이 복잡하고, 리사이즈 워크로드는 Lambda가 더 단순·확장성 좋음. EC2 기반 리사이저는 서버리스 대비 확장성·운영 효율이 떨어짐.
Answer: B
요구사항
환경: EC2 마이크로서비스 → EKS 마이그레이션
제어 플레인: 엔드포인트 프라이빗 액세스 = true, 퍼블릭 액세스 = false (API 서버는 VPC 내부에서만 접근)
데이터 플레인: 프라이빗 서브넷에 노드 배치
문제: 노드가 클러스터에 조인하지 못함
목표: 노드가 클러스터에 조인하도록 수정
B. 노드가 제어 플레인에 접근할 수 있도록 인터페이스 VPC 엔드포인트 생성
원인: 퍼블릭 액세스가 꺼져 있어 EKS API 서버는 프라이빗 엔드포인트(PrivateLink) 로만 제공됨. 프라이빗 서브넷의 노드는 인터넷이 없어, 제어 플레인에 도달하려면 VPC 안에서 해당 엔드포인트로 가는 경로가 필요함.
인터페이스 VPC 엔드포인트: EKS API용 인터페이스 VPC 엔드포인트를 노드가 있는 서브넷(또는 같은 VPC의 서브넷)에 두면, 노드 → 엔드포인트 → EKS 제어 플레인으로 트래픽이 VPC 내부에서만 흐름.
노드 조인: 노드는 조인·헬스체크·설정 수신을 위해 제어 플레인과 통신해야 하므로, 이 경로가 있어야 조인 오류가 해결됨.
추가 엔드포인트: 이미지 풀 등이 필요하면 ECR(ecr.api, ecr.dkr), S3용 게이트웨이 엔드포인트 등도 함께 두는 것이 일반적임.
틀린 이유
A. AmazonEKSNodeRole에 IAM 권한을 부여해도, 노드가 네트워크상으로 제어 플레인에 도달하지 못하면 조인할 수 없음. 퍼블릭 끄고 프라이빗만 쓸 때는 먼저 VPC 엔드포인트(B) 로 접근 경로를 만들어야 함.
C. 퍼블릭 액세스가 false이므로 퍼블릭 서브넷에 노드를 두어도 제어 플레인에 대한 퍼블릭 엔드포인트가 없어 조인 문제는 그대로임. 요구사항대로 데이터 플레인은 프라이빗 서브넷에 두어야 함.
D. 노드 보안 그룹에서 아웃바운드를 허용해도, 목적지(EKS API) 로 가는 경로가 없으면 소용없음. 퍼블릭이 꺼진 상태에서는 인터페이스 VPC 엔드포인트를 만들어 제어 플레인에 대한 경로를 확보해야 함.
Answer: B, C, E
요구사항
상황: 온프레미스 애플리케이션을 AWS로 마이그레이션
선택 솔루션: Amazon Redshift
질문: 이 시나리오에서 Redshift에 적합한 사용 사례 3개 선택
B. 클라이언트 측 및 서버 측 암호화 지원
Redshift는 저장 데이터 암호화(서버 측, KMS)와 전송 중 암호화(TLS)를 지원함.
규정·보안 요구사항을 맞추는 데 적합한 사용 사례에 해당함.
C. 지정된 시간 동안 애플리케이션이 활성 상태가 아닐 때 분석 워크로드 구축
Redshift는 분석·데이터 워허우징용으로, 배치 리포트·BI·대용량 SQL 쿼리에 적합함.
비활성 시간에만 분석을 돌리거나, 클러스터 일시 중지/재개로 비활성 구간에는 비용을 줄이면서 분석 워크로드를 운영할 수 있음.
E. 페타바이트 규모의 데이터와 분당 수천만 건의 요청을 지원하도록 전 세계적으로 확장
Redshift는 페타바이트 규모의 데이터 워허우징과 대용량 분석 쿼리 동시 실행에 맞게 설계됨.
“전 세계적으로 확장”은 여기서 대규모(글로벌 스케일) 데이터·쿼리 처리 능력을 의미하는 맥락으로, Redshift의 대용량 분석 용도에 부합함.
틀린 이유
A. Redshift Data API로 컨테이너·이벤트 기반 앱에서 쿼리하는 것은 가능하지만, 문제에서 요구한 “Redshift에 적합한 사용 사례” 3개(B, C, E)에 비해 핵심 강점(암호화, 분석 워크로드·비활성 시간 활용, 페타바이트·대규모 분석)으로 보지 않고 제외된 것으로 보임.
D. 백엔드 DB 부하를 줄이기 위한 캐싱은 ElastiCache(Redis/Memcached)나 DynamoDB DAX 등이 담당하는 영역이며, Redshift는 캐시가 아니라 데이터 워허우스라 이 사용 사례에는 부적합함.
F. Redshift는 RDS/Aurora처럼 보조(읽기) 복제본을 콘솔에서 만드는 방식이 아니며, 단일 리전 클러스터(리더 + 컴퓨트 노드) 또는 스냅샷 기반 복구 구조라 “클러스터의 보조 복제본 생성”은 Redshift의 표준 사용 사례가 아님.
Answer: B
요구사항
기능: 고객이 재무 정보를 검색하는 API 제공
트래픽: 연중 최대 사용 시간에 요청 증가 예상
성능: API가 낮은 대기 시간으로 일관되게 응답해 고객 만족 보장
인프라: API용 컴퓨팅 제공, 최소한의 운영 오버헤드
B. API Gateway + 프로비저닝된 동시성을 사용하는 Lambda 함수
API Gateway: 관리형 API 서비스로, 인증·스로틀링·모니터링을 AWS가 담당해 운영 부담이 적음.
Lambda: 서버리스 컴퓨팅으로 서버·클러스터 관리가 없고, 트래픽 증가 시 자동으로 동시 실행 수가 늘어남.
프로비저닝된 동시성: 미리 실행 환경을 준비해 두어 콜드 스타트를 제거하고, 요청 시 일관되게 낮은 지연을 제공함. “낮은 대기 시간으로 일관되게 응답” 요구에 직접 부합함.
피크 대응: 최대 사용 시간에 맞춰 프로비저닝된 동시성 수를 늘리거나, Lambda 자동 확장에 맡기면 됨. 운영 오버헤드는 최소로 유지됨.
틀린 이유
A. ALB + ECS는 컨테이너 클러스터·태스크 정의·스케일 정책 등을 직접 관리해야 해서 운영 부담이 크고, “최소한의 운영 오버헤드” 요구를 충족하기 어려움.
C. ALB + EKS는 Kubernetes 클러스터·노드·컨트롤 플레인 관리로 운영 부담이 가장 커서, 최소 운영 요구에 맞지 않음.
D. 예약된 동시성(Reserved Concurrency) 은 동시 실행 상한만 정하는 것이고, 실행 환경을 미리 준비하는 프로비저닝된 동시성이 아님. 콜드 스타트를 줄이지 못해 “일관되게 낮은 대기 시간”을 보장하기 어렵고, 정답은 B(프로비저닝된 동시성)임.
Answer: A
요구사항
대상: AWS Systems Manager Session Manager 로그 전부
목적: 보관을 위해 Amazon S3 버킷으로 전송
목표: 위를 가장 운영 효율적으로 만족하는 방식
A. Systems Manager 콘솔에서 S3 로깅 활성화 후, 세션 데이터를 보낼 S3 버킷 지정
기본 기능 사용: Session Manager는 세션 로그를 S3로 보내는 옵션을 제공함. 콘솔에서 S3 로깅을 켜고 버킷만 지정하면 됨.
추가 구성 최소화: 에이전트 설치, CloudWatch 로그 그룹, 구독, Firehose, SSM 문서·EventBridge 등 별도 파이프라인 없이 한 번 설정으로 해결됨.
운영 효율: 로그 형식·전송·권한은 AWS가 처리하므로, 설정·유지보수 부담이 가장 적음.
틀린 이유
B. CloudWatch 에이전트는 인스턴스의 일반 로그를 CloudWatch Logs로 보내는 용도이며, Session Manager 세션 로그는 Session Manager 서비스가 생성·관리함. Session Manager 로그를 S3로 보관하려면 B처럼 에이전트·Logs·내보내기를 조합할 필요가 없고, A의 기본 S3 로깅이 더 단순하고 적합함.
C. SSM 문서 + EventBridge는 인스턴스의 서버 로그를 수집·업로드하는 패턴에 가깝고, Session Manager 세션 로그와는 별개임. 문서 작성·스케줄·대상 관리 등으로 운영 부담이 커서 “가장 운영 효율적”이 아님.
D. CloudWatch 에이전트 → Logs → 구독 → Kinesis Data Firehose → S3는 일반 로그 파이프라인용이며, Session Manager 전용 로그에는 맞지 않음. 구성 요소가 많아 운영 효율이 A보다 떨어짐.
Answer: A
요구사항
환경: Amazon RDS MySQL DB 인스턴스
문제: RDS 디스크 공간이 부족해짐
목표: 다운타임 없이 디스크 공간을 늘리고, 최소한의 노력으로 해결
A. RDS 스토리지 자동 확장(Storage Auto Scaling) 활성화
저장 용량 자동 증가: RDS Storage Auto Scaling을 켜면, 사용 가능 공간이 임계값 이하로 떨어질 때 스토리지가 자동으로 증가해 디스크 부족을 줄일 수 있음.
다운타임 없음: 스토리지 확장은 온라인으로 적용되며, 애플리케이션 중단 없이 용량만 늘어남.
최소 노력: 콘솔/CLI에서 자동 확장 활성화, 최대 스토리지 한도만 설정하면 되며, 백업·복원·인스턴스 교체 등 추가 작업이 필요 없음.
틀린 이유
B. 인스턴스 크기(인스턴스 클래스)를 늘리는 것은 CPU·메모리를 키우는 것이지 스토리지 용량(GB) 을 늘리는 것이 아님. 디스크 공간 부족 문제를 해결하지 못함.
C. 스토리지 유형을 프로비저닝된 IOPS로 바꾸는 것은 IOPS 성능 변경이지 저장 용량(GB) 증가가 아님. 디스크 공간 부족에는 해당하지 않음.
D. 백업 → 용량 늘린 새 인스턴스 생성 → 복원 → 이전 인스턴스 중지 방식은 작업 단계가 많고, 전환 시 다운타임이 발생할 수 있으며 “최소한의 노력” 요구를 충족하지 못함.
Answer: B
요구사항
역할: 컨설팅 회사, 전 세계 고객에게 데이터 수집·분석용 솔루션·도구 제공
목표: 공통 솔루션·도구 집합을 중앙에서 관리·배포하고, 고객이 셀프서비스로 사용
B. 고객용 AWS Service Catalog 제품 생성
중앙 관리: Service Catalog에서 제품(Products) 을 정의해, CloudFormation 템플릿·솔루션·도구를 한 곳에서 관리·버전 관리할 수 있음.
공통 집합 배포: 제품을 포트폴리오로 묶어, 조직 단위·계정·고객 계정에 일괄 배포·공유할 수 있음.
셀프서비스: 고객/사용자는 Service Catalog 콘솔에서 제품 목록을 보고, 승인된 제품만 직접 프로비저닝할 수 있어 “공통 솔루션·도구를 셀프서비스로 사용” 요구에 맞음.
통제: 어떤 제품을 누구에게 제공할지, 어떤 IAM/권한으로 실행할지 중앙에서 제어 가능함.
틀린 이유
A. CloudFormation 템플릿만 만들면 “파일 공유”에 가깝고, 중앙에서 관리·배포하는 카탈로그나 셀프서비스 포털이 없음. 제품 단위 관리·승인·배포는 Service Catalog가 담당함.
C. Systems Manager에는 “템플릿” 형태의 제품 카탈로그가 없고, 주로 운영 작업(패치, Run Command 등)용이라, “공통 솔루션·도구의 중앙 관리·셀프서비스 배포”에는 맞지 않음.
D. AWS Config는 리소스 설정 기록·규정 준수 평가용이며, 솔루션·도구를 관리·배포하거나 셀프서비스로 제공하는 용도가 아님.
Answer: B
요구사항
환경: EC2 웹 애플리케이션, 백엔드 스토리지 Amazon DynamoDB
트래픽: 예측 불가
처리량: DB 읽기·쓰기 보통~높음
목표: 트래픽에 맞춰 확장하면서 가장 비용 효율적인 DynamoDB 구성
B. DynamoDB Standard 테이블 클래스 + 온디맨드(On-Demand) 모드
온디맨드 = 요청당 과금: 용량을 미리 정하지 않고, 실제 읽기·쓰기 요청량만큼만 과금됨. 예측 불가한 트래픽에서 과다 프로비저닝(유휴 비용) 이나 과소 프로비저닝(쓰로틀링) 을 피할 수 있음.
자동 확장: 트래픽이 늘어나면 DynamoDB가 자동으로 처리량을 늘려 주므로, “트래픽에 대응하여 확장” 요구를 만족함.
비용 효율: 트래픽이 낮을 때는 사용량만 과금되고, 높을 때는 필요한 만큼만 지불하므로 예측 불가·보통~높은 처리량 조건에서 가장 비용 효율적인 선택에 가깝음.
Standard 클래스: 자주 접근하는 데이터에 적합한 기본 테이블 클래스로, “보통~높은” 읽기·쓰기에 맞음.
틀린 이유
A. 프로비저닝 모드 + Auto Scaling은 최소·최대 용량 범위 안에서만 조정됨. 예측 불가 트래픽에서는 최대를 크게 잡아 유휴 비용이 나가거나, 최대를 작게 잡아 스파이크 시 쓰로틀링이 발생해 “가장 비용 효율적”이 되기 어려움.
C. Standard-IA는 접근 빈도가 낮은 데이터용이라, “보통~높은” 읽기·쓰기에는 적합하지 않음. 프로비저닝 모드는 A와 같은 이유로 예측 불가 트래픽에 비효율적임.
D. Standard-IA + 온디맨드도 Standard-IA가 “자주 접근하는” 워크로드에 맞지 않고, 이 시나리오에서는 Standard + 온디맨드(B)가 더 적합함.
Answer: C
요구사항
환경: 여러 비즈니스, 각 팀이 자체 AWS 계정 보유, AWS Organizations 소속
데이터: 각 팀 계정의 DynamoDB 테이블에 제품 재고
앱: 공유(중앙) AWS 계정에 재고 보고 앱 배포
필요: 앱이 모든 팀의 DynamoDB 테이블에서 항목을 읽을 수 있어야 함
목표: 위를 가장 안전하게 만족하는 인증 방식
C. 비즈니스 계정마다 BU_ROLE(신뢰 정책 + DynamoDB 읽기), 인벤토리 계정에 APP_ROLE(AssumeRole 권한), 앱은 APP_ROLE 사용 후 교차 계정 BU_ROLE 수임
역할 기반·임시 자격 증명: 장기 액세스 키를 저장하지 않고, APP_ROLE로 동작한 뒤 STS AssumeRole로 각 팀 계정의 BU_ROLE 임시 자격 증명을 받아 DynamoDB에 접근함.
최소 권한: 각 BU_ROLE에는 해당 계정의 DynamoDB 테이블 읽기만 부여하고, 신뢰 정책으로 인벤토리 계정의 APP_ROLE만 Assume 할 수 있게 제한함.
감사·통제: 어떤 계정의 어떤 역할이 인벤토리 계정을 신뢰하는지 명확하고, CloudTrail로 AssumeRole·DynamoDB 호출을 추적할 수 있음.
표준 패턴: AWS가 권장하는 크로스 계정 액세스(역할 + AssumeRole)와 일치함.
틀린 이유
A. Secrets Manager에 저장하는 것은 보통 장기 자격 증명(액세스 키 등) 이며, 30일마다 순환해도 “저장된 키” 방식이라 역할 기반 임시 자격 증명(C) 보다 보안 수준이 낮음. DynamoDB 크로스 계정 접근에는 역할 + AssumeRole이 더 안전함.
B. 각 비즈니스 계정에 IAM 사용자 + 액세스 키를 두고 앱에서 사용하는 방식은 장기 자격 증명을 관리·저장해야 하며, 유출·로테이션 부담이 크고 “가장 안전한” 옵션이 아님.
D. ACM은 TLS/SSL 인증서용 서비스이며, DynamoDB API 인증은 IAM으로 이루어짐. DynamoDB를 ACM 인증서로 “인증”하는 구성은 지원되지 않고, 요구사항을 충족하지 못함.
Answer: B, C
요구사항
환경: Amazon EKS에서 애플리케이션 실행, 컨테이너 사용
워크로드: 하루 종일 일정하지 않음(변동)
목표: EKS가 워크로드에 따라 확장·축소되도록 하고, 최소한의 운영 오버헤드로 구현할 2가지 단계 조합
B. Kubernetes Metrics Server로 수평 파드 자동 확장(HPA) 활성화
Metrics Server: 클러스터 내 CPU·메모리 등 리소스 메트릭을 제공해, HPA가 이 메트릭을 사용할 수 있게 함.
HPA: CPU·메모리 등 사용률에 따라 파드 수를 자동으로 늘리거나 줄임. 워크로드가 늘면 파드가 늘고, 줄면 파드가 줄어듦.
표준 방식: Kubernetes 기본 컴포넌트만 사용하므로 추가 개발·운영 부담이 적음.
C. Kubernetes Cluster Autoscaler로 클러스터 노드 수 관리
Cluster Autoscaler: 스케줄되지 않은 Pending 파드가 있으면 노드 추가, 사용률이 낮은 노드는 노드 제거해 노드 수를 자동으로 조정함.
B와 연동: HPA(B)가 파드를 늘리면, 노드가 부족할 때 Cluster Autoscaler(C)가 노드를 늘리고, HPA가 파드를 줄이면 Cluster Autoscaler가 남는 노드를 줄여 비용·운영을 최소화함.
관리형 활용: EKS에서 권장하는 방식으로, 커스텀 스크립트·Lambda 없이 최소 운영으로 워크로드에 맞춘 확장·축소가 가능함.
틀린 이유
A. Lambda로 EKS 클러스터 크기를 조정하려면 메트릭 수집·판단·ASG/EKS API 호출 등 직접 구현이 필요해 운영 부담이 크고, EKS에서는 Cluster Autoscaler(C)가 표준이므로 “최소 운영”에 맞지 않음.
D. API Gateway는 API 관리·엔드포인트 노출용이며, EKS의 확장·축소와는 무관함.
E. App Mesh는 서비스 메시·네트워크 관찰용이며, 파드/노드 자동 확장 기능을 제공하지 않음.
Answer: D
요구사항
환경: 마이크로서비스 기반 서버리스 웹 애플리케이션
기능: 여러 DynamoDB 테이블에서 데이터를 검색할 수 있어야 함
제약: 애플리케이션 기본 성능에 영향을 주지 않아야 함
목표: 위를 운영상 가장 효율적인 방식으로 만족
D. DynamoDB 커넥터를 사용한 Amazon Athena Federated Query
워크로드 분리: Athena는 분석·검색용 쿼리를 담당하고, 앱의 기본 트래픽(API Gateway·Lambda → DynamoDB 읽기/쓰기)과 경로가 다름. 검색·분석이 기본 OLTP와 같은 DynamoDB 읽기 용량을 쓰지 않도록 분리할 수 있음.
기본 성능 유지: 검색/분석은 Athena + DynamoDB 커넥터로 처리하고, 앱은 기존처럼 DynamoDB를 직접 사용하면 기본 성능에 영향을 주지 않고 데이터 검색 기능을 제공할 수 있음.
다중 테이블 검색: Athena Federated Query의 DynamoDB 커넥터로 여러 DynamoDB 테이블을 SQL로 조회·조인할 수 있음.
운영 효율: Athena는 관리형 서비스라 쿼리 엔진·커넥터만 설정하면 되고, 별도 검색 인프라·ETL 파이프라인을 운영할 필요가 적음.
틀린 이유
A. AppSync 파이프라인 리졸버는 앱 요청 경로에 포함되어, 검색 트래픽이 앱 API·DynamoDB와 같은 경로를 타면 기본 성능에 영향을 줄 수 있음. 검색을 기본 트래픽과 분리하는 측면에서 Athena(D)가 더 적합함.
B. CloudFront + Lambda@Edge는 엣지 캐싱·요청/응답 변형용이며, “여러 DynamoDB 테이블 검색”을 제공하는 전용 솔루션이 아님.
C. API Gateway + Lambda로 DynamoDB를 조회할 수는 있지만, 이 경로를 앱과 공유하면 검색 부하가 기본 성능에 영향을 줄 수 있음. “기본 성능에 영향 없이”를 운영상 가장 효율적으로 만족하려면 검색 워크로드를 Athena(D)처럼 분리하는 편이 적합함.
Answer: C
요구사항
목적: IAM 권한 관련 액세스 거부(AccessDenied)·무단(Unauthorized) 오류를 분석·해결
환경: AWS CloudTrail 사용 중(로그 수집)
목표: 위를 최소한의 노력으로 수행
C. Amazon Athena로 CloudTrail 로그 쿼리해 오류 식별
CloudTrail + S3: CloudTrail 로그는 S3에 저장되며, Athena는 S3 데이터를 SQL로 조회할 수 있음.
최소 구성: Athena에서 CloudTrail 로그 경로를 가리키는 테이블을 만들고(또는 CloudTrail용 테이블 생성 가이드 활용), errorCode가 'AccessDenied', 'Unauthorized' 등인 이벤트를 SELECT로 필터링하면 됨.
추가 개발 없음: Glue ETL·Batch·커스텀 스크립트 없이 SQL만으로 오류 이벤트를 찾을 수 있어 노력이 적음.
운영 효율: 쿼리만 실행하면 되므로, “최소한의 노력” 요구에 맞음.
틀린 이유
A. AWS Glue는 ETL·데이터 카탈로그용이며, “CloudTrail에서 오류만 찾기”에는 커스텀 스크립트·잡이 필요해 Athena로 직접 쿼리하는 것보다 노력이 큼.
B. AWS Batch는 배치 컴퓨팅용이라, CloudTrail 로그 분석을 하려면 커스텀 스크립트·잡 정의가 필요하고, Athena 한두 번의 쿼리보다 구성·운영 부담이 큼.
D. QuickSight는 시각화·대시보드용이라, 데이터 소스(Athena 등) 연결·대시보드 생성이 선행되어야 함. “오류 식별”만 하면 될 때는 Athena 쿼리(C) 가 더 단순하고 노력이 적음.
Answer: A
요구사항
목적: 기존 AWS 사용 비용을 운영 비용 대시보드에 반영
접근: 프로그래밍 방식으로 사용 비용 데이터 접근
데이터: 현재 연도 비용 데이터 접근 + 향후 12개월 비용 예측
목표: 위를 최소한의 운영 오버헤드로 만족
A. 페이지네이션을 사용한 AWS Cost Explorer API로 사용 비용 데이터 접근
프로그래밍 접근: Cost Explorer API(GetCostAndUsage, GetCostForecast 등)를 호출해 대시보드 백엔드에서 비용·사용량 데이터를 직접 조회할 수 있음.
현재 연도 비용: GetCostAndUsage로 과거·현재 연도 비용·사용량을 기간·그룹별로 조회 가능함.
향후 12개월 예측: GetCostForecast API로 향후 12개월 비용 예측 값을 조회할 수 있음.
페이지네이션: 결과가 많을 때 페이지네이션으로 대량 데이터를 안정적으로 가져와 대시보드에 연동 가능함.
최소 운영: CSV 다운로드·FTP·SMTP 파이프라인 없이 API 연동만으로 해결되므로 운영 부담이 적음.
틀린 이유
B. Cost Explorer CSV 보고서는 콘솔에서 다운로드하거나 예약 보고서로 받는 방식이라, 대시보드가 API로 직접 조회하는 구조가 아니고, 예측(forecast) 도 CSV만으로는 바로 쓰기 어려움. “프로그래밍 방식 접근”과 “최소 운영”에는 API(A)가 더 적합함.
C. AWS Budgets는 예산·임계값 알림용이며, 비용 데이터를 FTP로 전송하는 표준 기능이 없고, 대시보드가 API로 비용을 조회하는 요구와 맞지 않음.
D. Budgets 보고서를 SMTP(이메일) 로 보내는 것은 알림·리포트 전달용이며, 대시보드가 프로그래밍 방식으로 비용·예측을 가져오는 용도가 아님. 비용·예측 조회는 Cost Explorer API(A)가 맞음.
Answer: D
요구사항
환경: Amazon Aurora PostgreSQL, 작성자(Writer) 인스턴스
상황: 확장 연습 중 작성자 장애 조치 수행 → 애플리케이션 3분 다운타임 발생
목표: 확장 연습 시 다운타임을 줄이고, 최소한의 운영 오버헤드로 해결
D. DB 앞단에 Amazon RDS Proxy 구성, 앱은 프록시 엔드포인트로 연결
RDS Proxy 역할: 앱은 프록시 엔드포인트에만 연결하고, Proxy가 Aurora(Writer/Reader)와의 연결을 관리함.
장애 조치 시: Writer가 바뀌면 RDS Proxy가 새 Writer로 자동 재연결하고, 기존 연결을 정리·재시도함. 앱은 Proxy만 바라보므로 엔드포인트 변경·수동 스위치 없이 장애 조치를 흡수할 수 있음.
다운타임 감소: 앱이 직접 Writer 엔드포인트에 붙어 있을 때보다, Proxy가 재연결을 처리해 연결 복구 시간이 짧아져 3분 수준 다운타임을 줄일 수 있음.
최소 운영: Proxy 생성·앱 연결 대상만 Proxy 엔드포인트로 바꾸면 되고, 추가 복제본·보조 클러스터·캐시 구축 없이 설정만으로 개선 가능함.
틀린 이유
A. 읽기 전용 복제본을 늘리는 것은 읽기 부하 분산용이며, Writer 장애 조치 시 앱이 새 Writer에 재연결되는 시간을 줄이지 않음. 다운타임 원인(연결/재연결)을 해결하지 못함.
B. 같은 리전에 보조 Aurora 클러스터를 두고, 장애 조치 시 앱이 보조 Writer 엔드포인트를 쓰도록 바꾸는 방식은 수동 또는 커스텀 스위치 로직이 필요하고, Aurora 클러스터 내 자동 장애 조치만으로는 해결되지 않음. 운영 부담이 크고 “최소 운영”에 맞지 않음.
C. ElastiCache for Memcached는 캐시로, 쓰기 트래픽이나 Writer 장애 조치 시 DB 연결 재설정과 무관함. 3분 다운타임(연결/장애 조치)을 줄이는 방법이 아님.
Answer: D
요구사항
환경: 단일 리전, EC2 웹·앱, ELB + Auto Scaling, Aurora 글로벌 데이터베이스 클러스터
목표: 전 세계 확장, 가동 중지 시간 최소화 → 가장 내결함성 높은 솔루션
D. 웹·앱을 두 번째 리전에 배포, Aurora 글로벌 DB로 기본·보조 리전 구성, Route 53 장애 조치 + 필요 시 보조를 기본으로 승격
Aurora 글로벌 DB: 기본 리전에 Primary 클러스터, 두 번째 리전에 Secondary 클러스터(읽기 복제, 필요 시 Primary로 승격). 리전 간 복제는 Aurora가 관리하며 RPO가 짧음(보통 1초 미만).
두 리전에 웹·앱: 기본 리전과 두 번째 리전 모두에 웹·앱 계층을 두어, 한 리전 장애 시 다른 리전이 트래픽을 받을 수 있음.
Route 53 장애 조치: 상태 확인으로 기본 리전을 모니터링하고, 장애 시 두 번째 리전으로 라우팅해 가동 중지 시간을 줄임.
보조 → 기본 승격: 장애 조치 시 두 번째 리전의 DB는 원래 보조(읽기 전용). 필요 시 보조를 기본으로 승격해야 두 번째 리전 앱이 쓰기까지 수행할 수 있어 완전한 장애 조치가 됨. D는 이 단계를 포함함.
내결함성: 두 리전에 풀 스택(웹·앱·DB) + 글로벌 DB + Route 53 장애 조치 + 승격까지 포함해 가장 내결함성이 높음.
틀린 이유
A. Aurora 글로벌 DB + Route 53 장애 조치는 있으나 “보조를 기본으로 승격”이 없음. 장애 조치 후 두 번째 리전 DB는 보조(읽기 전용) 상태로 남아 쓰기가 불가하므로, 완전한 장애 조치·내결함성 측면에서 D보다 부족함.
B. “교차 리전 Aurora 복제본”은 글로벌 DB가 아닌 일반 크로스 리전 읽기 복제 패턴. Aurora 글로벌 DB(D)가 리전 간 복제·RPO·관리 측면에서 더 적합하고, “가장 내결함성”에는 D가 더 맞음.
C. 두 번째 리전에 별도 Aurora를 두고 DMS로 복제하는 방식은 Aurora 글로벌 DB보다 구성이 복잡하고, 복제 지연·RPO·장애 조치 관리 측면에서 “가장 내결함성”에는 D(글로벌 DB + 승격)가 더 적합함.
Answer: C
요구사항
환경: 데이터 분석 회사, 일괄 처리 시스템을 AWS로 마이그레이션
수신: FTP로 하루 동안 주기적으로 수천 개의 작은 데이터 파일 수신
처리: 온프레미스는 밤에 처리해 몇 시간 걸림 → AWS에서는 가능한 한 빨리 처리
제약: 파일 전송하는 FTP 클라이언트 변경 최소화
동작: 파일 처리 성공 후 수신 파일 삭제, 파일당 3~8분 소요
목표: 위를 운영상 가장 효율적으로 만족
C. AWS Transfer Family로 FTP 서버 구성, 파일 도착 시 S3 이벤트로 AWS Batch 작업 호출, 처리 후 파일 삭제
FTP 클라이언트 변경 최소: AWS Transfer Family는 관리형 FTP(SFTP) 서비스로, 기존 FTP 클라이언트가 그대로 접속할 수 있어 “FTP 클라이언트 변경 최소화”를 만족함. (저장 백엔드는 S3 사용 시 S3 이벤트와 연동 가능.)
가능한 한 빨리 처리: Transfer Family에서 파일이 S3에 올라오면 S3 이벤트 알림으로 파일 도착 시점에 바로 AWS Batch 작업을 호출할 수 있음. 야간 일괄이 아니라 파일 도착 즉시 처리해 “가능한 한 빨리” 요구를 충족함.
3~8분 처리에 적합: 파일당 3~8분이면 AWS Batch가 적합함. Lambda 15분 한계 안이지만, 수천 개 파일·재시도·큐 관리 측면에서 Batch가 일괄 처리에 더 잘 맞음.
처리 후 삭제: Batch 작업이 파일 처리에 성공한 뒤, 같은 작업 또는 후처리에서 해당 S3 객체를 삭제하면 “처리 후 수신 파일 삭제” 요구를 만족함.
운영 효율: Transfer Family(관리형 FTP), S3(관리형 스토리지), Batch(관리형 일괄 처리)만으로 구성 가능해 EC2 FTP·야간 스케줄·Glacier 복구 없이 운영 부담이 적음.
※ 보기 문장에는 “EBS 볼륨에 저장”이라고 되어 있으나, S3 이벤트 알림을 쓰려면 파일이 S3에 저장되어야 함. Transfer Family는 S3를 백엔드로 사용할 수 있으므로, 정답 설계는 FTP → S3 저장, S3 이벤트 → Batch로 이해하는 것이 맞음.
틀린 이유
A. 파일을 S3 Glacier Flexible Retrieval에 넣고 야간 EventBridge로 Batch를 돌리면, Glacier 복구 지연과 야간 처리로 “가능한 한 빨리” 요구를 충족하지 못함. FTP 클라이언트는 EC2 FTP로 유지할 수 있으나, 처리 시점·속도 측면에서 부적합함.
B. EC2 FTP + EBS에 저장하고 야간 EventBridge로 Batch를 호출하면, “파일 도착 즉시 처리”가 아니고 야간 일괄이라 “가능한 한 빨리”에 맞지 않음. FTP·스토리지·스케줄을 직접 관리해 운영 부담도 큼.
D. Transfer Family + S3 + Lambda + S3 이벤트로 “파일 도착 즉시 처리 후 삭제”는 가능함. 다만 일괄 처리 시스템·파일당 3~8분·수천 개 파일을 고려하면 AWS Batch가 작업 큐·재시도·배열 작업에 유리하고, 시험 해설상 C(Transfer Family + S3 이벤트 + Batch + 처리 후 삭제) 가 “운영상 가장 효율적인” 정답으로 제시됨.
Answer: B
요구사항
환경: 워크로드를 AWS로 마이그레이션
데이터: 거래·민감 데이터가 있는 데이터베이스
목표: AWS 클라우드 솔루션으로 보안 강화 + 데이터베이스 운영 오버헤드 감소
B. Amazon RDS로 DB 마이그레이션, 유휴(저장) 암호화 구성
운영 부담 감소: RDS는 관리형 DB로, OS·DB 엔진 패치, 백업, 다중 AZ, 읽기 복제 등은 AWS가 담당해 EC2에 DB 직접 설치·운영하는 것보다 운영 오버헤드가 적음.
보안 강화: RDS 유휴 암호화를 켜면 저장 데이터가 KMS로 암호화되어, 민감·거래 데이터 보호에 도움이 됨.
요구사항 충족: “데이터베이스의 운영 오버헤드를 줄이고 보안을 강화”하는 데, 관리형 DB + 저장 데이터 암호화가 직접적으로 맞음.
틀린 이유
A. DB를 EC2로 옮기면 OS·DB 설치·패치·백업·고가용성 등을 직접 관리해야 해 운영 부담이 늘어나고, “운영 오버헤드 감소” 요구를 충족하지 못함.
C. 거래·민감 데이터가 있는 데이터베이스를 S3로 옮기면 트랜잭션·쿼리·관계형 모델을 잃어 “데이터베이스” 요구와 맞지 않음. Macie는 S3 객체의 민감 데이터 탐지용이라, DB 마이그레이션·운영 부담 감소 답이 아님.
D. RDS는 운영 부담 감소에 적합하지만, CloudWatch Logs는 로그 수집·모니터링용이며 저장 데이터 암호화나 DB 본문 보호 기능이 아님. “보안 강화”에는 RDS 유휴 암호화(B)가 맞음.
Answer: C
요구사항
환경: TCP·UDP 멀티플레이어 온라인 게임, Route 53으로 여러 리전의 NLB로 트래픽 라우팅
목표: 사용자 증가에 대비한 성능 개선, 온라인 게임 지연 시간 감소
제약: TCP·UDP 트래픽 지원 필요
C. NLB 앞에 AWS Global Accelerator 추가, 리스너 포트를 TCP·UDP에 맞게 구성
TCP·UDP 지원: Global Accelerator는 TCP·UDP를 지원해 멀티플레이어 게임 트래픽을 그대로 전달할 수 있음.
지연 시간 감소: 클라이언트는 Anycast IP로 가장 가까운 AWS 엣지에 접속하고, 이후 AWS 백본으로 해당 리전 NLB까지 전달됨. 인터넷 구간이 짧아져 지연 시간이 줄어듦.
고정 엔드포인트: Anycast IP가 고정되어 있어, 클라이언트·DNS 변경 없이 백엔드 리전·NLB를 바꿀 수 있음.
다중 리전: Global Accelerator의 엔드포인트 그룹으로 여러 리전 NLB를 등록하고, 상태·지연 기반으로 트래픽을 분배할 수 있어 사용자 증가에 대응 가능함.
틀린 이유
A. CloudFront는 HTTP/HTTPS용 CDN이라 TCP·UDP를 지원하지 않음. 멀티플레이어 게임의 TCP·UDP 트래픽은 CloudFront로 전달할 수 없음.
B. ALB는 Layer 7(HTTP/HTTPS) 전용이라 UDP를 지원하지 않음. “TCP 및 UDP 멀티플레이어” 요구를 충족하지 못함.
D. API Gateway는 REST/HTTP API용이며, 원시 TCP·UDP 게임 트래픽을 처리하지 않음. API 캐싱은 HTTP 응답용이라 실시간 게임 지연 개선과는 무관함.
Answer: A
요구사항
상황: 타사 데이터 피드와 연동, 데이터 준비 시 웹후크로 알림
구현: 웹후크 수신 시 데이터를 가져오는 Lambda 함수 작성됨
필요: 제3자가 웹후크로 Lambda를 호출할 수 있도록 공개
목표: 위를 가장 효율적으로 만족하는 방식
A. Lambda 함수 URL 생성 후, 웹후크용으로 해당 URL을 타사에 제공
Lambda 함수 URL: Lambda에 전용 HTTP(S) 엔드포인트를 부여해, 타사가 HTTP POST(웹후크) 로 해당 URL만 호출하면 Lambda가 직접 실행됨.
구성 최소: API Gateway·ALB·SNS·SQS 없이 함수 URL 하나만 만들고 URL만 타사에 전달하면 됨.
웹후크와 일치: 타사는 기존처럼 “URL로 HTTP POST”만 하면 되므로, 웹후크 방식 변경이 거의 없음.
운영 효율: 인증·스로틀은 함수 URL 옵션으로 처리 가능하고, 추가 인프라 없이 “가장 효율적” 요구를 충족함.
틀린 이유
B. ALB를 Lambda 앞에 두고 ALB URL을 타사에 주면, ALB·타깃 그룹·리스너 등 추가 인프라가 필요해 Lambda 함수 URL만 쓰는 A보다 구성·비용이 크고 효율이 떨어짐.
C. SNS 주제에 Lambda를 구독시키고 타사에 SNS를 알려주는 방식은, 타사가 SNS Publish API(AWS 서명) 를 호출해야 해서 일반적인 “HTTP 웹후크 POST”와 맞지 않음. HTTP 웹후크를 그대로 받으려면 URL 엔드포인트(A 또는 API Gateway 등)가 필요함.
D. SQS 대기열은 공개 HTTP 웹후크 수신 엔드포인트가 아니라, 메시지를 넣으려면 AWS API(SendMessage 등) 호출이 필요함. 타사가 단순히 “URL로 POST”하는 웹후크를 보내는 방식과 맞지 않고, 그대로 쓰기엔 비효율적임.
Answer: A, D, F
요구사항
환경: 한 AWS 리전에 워크로드, Amazon API Gateway REST API로 고객 접근, Route 53 DNS
목표: 모든 고객에게 개별적이고 안전한 URL 제공
제약: 가장 높은 운영 효율성으로 만족할 3단계 조합 선택
A. 등록기관에 도메인 등록, Route 53 호스팅 영역에서 와일드카드 사용자 지정 도메인·API Gateway를 가리키는 레코드 생성
도메인: API용 도메인(예: api.company.com)을 등록기관에서 등록하거나 기존 도메인 사용.
와일드카드 레코드: Route 53 호스팅 영역에서 와일드카드 레코드(예: .api.company.com)를 두고 API Gateway 엔드포인트를 가리키면, customer1.api.company.com, customer2.api.company.com 등 모든 고객 서브도메인이 한 레코드로 같은 API로 연결됨.
운영 효율: 고객마다 레코드를 만들 필요 없이 한 번 설정으로 모든 고객 URL을 처리할 수 있음.
D. API Gateway와 같은 리전의 ACM에서 사용자 지정 도메인과 일치하는 와일드카드 인증서 요청
HTTPS: 고객별 URL을 안전하게 제공하려면 API Gateway 사용자 지정 도메인에 ACM 인증서가 필요함.
와일드카드 인증서: .api.company.com 같은 와일드카드 인증서를 쓰면 customer1.api.company.com, customer2.api.company.com 등 모든 고객 서브도메인을 한 인증서로 커버함.
동일 리전: API Gateway 사용자 지정 도메인에 쓰는 ACM 인증서는 API Gateway와 같은 리전에 있어야 하므로, 같은 리전에서 와일드카드 인증서를 요청해야 함.
F. API Gateway에서 REST API용 사용자 지정 도메인 이름 생성, ACM 인증서 연결
사용자 지정 도메인: API Gateway에서 REST API용 사용자 지정 도메인 이름(예: .api.company.com 또는 api.company.com)을 만들고, ACM 인증서(D) 를 연결함.
매핑: 사용자 지정 도메인을 API 스테이지에 매핑하면, Route 53(A)으로 들어온 고객별 URL이 같은 API로 라우팅되고 HTTPS로 서비스됨.
운영 효율: API는 하나만 두고, 사용자 지정 도메인·인증서만 설정하면 모든 고객에게 개별·안전한 URL을 제공할 수 있음.
틀린 이유
B. API Gateway 사용자 지정 도메인에 쓰는 ACM 인증서는 API Gateway와 같은 리전에 있어야 함. 다른 리전의 ACM 인증서는 API Gateway에 연결할 수 없음.
C. 고객마다 호스팅 영역을 하나씩 만들면 호스팅 영역·레코드 수가 폭증해 관리 부담이 크고, “가장 높은 운영 효율성”에 맞지 않음. 와일드카드 레코드(A)가 효율적임.
E. 고객마다 여러 API 엔드포인트를 만들면 API·스테이지가 불필요하게 늘어나고, 운영·비용이 커져 “가장 높은 운영 효율성”과 맞지 않음. 하나의 API + 와일드카드 사용자 지정 도메인(A, D, F)이 적합함.
Answer: A (PII만 강조하면 C도 가능)
요구사항
환경: Amazon S3에 데이터 저장
규정: 데이터에 PII(개인 식별 정보) 포함 금지
상황: S3 버킷에 PII가 포함된 객체가 일부 존재
목표: S3 버킷에서 PII를 자동으로 감지하고 보안 팀에 알림
A. Amazon Macie 사용, EventBridge에서 SensitiveData 이벤트 필터, 보안팀에 SNS 알림
Macie: S3 객체의 민감 데이터( PII, 금융 정보 등) 를 자동으로 탐지하는 서비스로, “S3에서 PII 감지” 요구에 적합함.
EventBridge: Macie 결과를 이벤트로 받아 SensitiveData 유형만 필터하면, 민감 데이터 발견 시에만 다음 단계로 넘김.
SNS: 필터된 이벤트를 보안 팀용 SNS 토픽으로 보내 즉시 알림(이메일, SMS 등)을 보낼 수 있어 “보안 팀에 알려야 한다”는 요구를 충족함.
자동화: Macie 스캔 → EventBridge 필터 → SNS 알림까지 구성만 하면 되고, 별도 스크립트 없이 운영 가능함.
틀린 이유
B. GuardDuty는 위협 탐지(악성 IP, 자격 증명 침해 등)용이며, S3 객체 내용에서 PII를 찾는 기능이 없어 이 요구사항에는 맞지 않음.
D. GuardDuty 사용은 B와 같은 이유로 PII 감지 용도가 아님.
C. Macie + EventBridge + SensitiveData:S3Object/Personal 필터 + SQS도 요구사항을 만족할 수 있음. PII만 골라 알리려면 SensitiveData:S3Object/Personal이 더 정확하고, 알림은 SQS 대기열을 구독하는 방식으로 구현 가능함. “PII만 감지”를 강조하면 C를 정답으로 두는 출제도 가능함.
정리:
“민감 데이터 전반 감지 + 보안팀 즉시 알림”이면 A(Macie + SensitiveData + SNS).
“PII에 한정해 감지”를 강조하면 C(Macie + SensitiveData:S3Object/Personal + SQS)를 선택하는 경우가 있습니다. 시험에서 정답이 C로 나온다면, PII 전용 이벤트 타입과 알림 파이프라인으로 이해하면 됩니다.
• SQS → 사람에게 알림 아님
• “보안 팀에 알려야 한다” → SNS가 더 적절
Answer: C
요구사항
환경: 여러 AWS 계정 → 중앙 계정 S3 버킷에 VPC Flow Logs·CloudTrail 로그 저장
0~30일: 빈번한 분석을 위해 고가용·빠른 접근 필요
30~90일: 백업 목적으로 추가 60일 보관
90일 후: 객체 삭제
목표: 위를 가장 비용 효율적으로 만족
C. 생성 후 30일이 지나면 S3 Glacier Flexible Retrieval로 전환, 90일 후 만료(삭제) 규칙 설정
0~30일: 객체는 생성 시 S3 Standard(기본)에 두어 빈번한 분석에 맞는 고가용·빠른 접근을 유지함.
30일 경과 시: 수명 주기 규칙으로 S3 Glacier Flexible Retrieval로 전환해, 30~90일 구간은 백업용으로만 두고 저장 비용을 낮춤.
90일 후: 수명 주기 만료(삭제) 규칙으로 객체를 삭제해 “90일 후 삭제” 요구를 충족함.
비용 효율: 30일 이후 구간을 Glacier로만 전환하고, 90일에는 삭제만 하므로 중간에 불필요한 스토리지 클래스 이동·이중 과금이 없음.
틀린 이유
A. 30일 후에도 S3 Standard로 유지하고 90일에 삭제하면, 30~90일 구간(백업용)에도 Standard 요금이 계속 발생해 비용 효율이 떨어짐. 백업 구간은 Glacier(C)로 내리는 것이 더 저렴함.
B. “90일 후 Glacier로 이동”과 “90일 후 삭제”를 동시에 두면, 90일 시점에 삭제되므로 Glacier 이동은 의미가 없고, 수명 주기 설계가 맞지 않음. 30일 전환만으로 충분함.
D. 30일 후 One Zone-IA, 90일 후 Glacier 이동 + 삭제는 B와 같이 90일 시 삭제와 Glacier 이동이 겹치고, 30~90일 구간을 Glacier로 한 번만 전환하는 C보다 구조가 복잡하고 비용 효율이 떨어짐.
Answer: B
요구사항
환경: Amazon EKS 클러스터 구축
목표: EKS에 저장되는 모든 시크릿이 Kubernetes etcd 키-값 저장소에서 암호화되도록 함
B. 새 KMS 키 생성 후, EKS 클러스터에서 Amazon EKS KMS 시크릿 암호화 활성화
etcd 암호화: EKS KMS 시크릿 암호화를 켜면, EKS가 지정한 KMS 키로 Kubernetes Secrets를 etcd에 저장할 때 암호화함(엔벨로프 암호화).
요구사항 충족: “EKS에 저장되는 모든 시크릿이 etcd에서 암호화”라는 조건을 클러스터 설정만으로 만족함.
운영: 클러스터 생성 시 또는 기존 클러스터에 KMS 키 지정 후 “시크릿 암호화” 옵션만 활성화하면 됨. 앱 코드·시크릿 저장 위치 변경 불필요.
틀린 이유
A. Secrets Manager로 시크릿을 “관리·교체·저장”하는 것은 시크릿을 AWS 쪽에 두는 방식이라, etcd에 저장된 시크릿을 암호화하는 요구와 다름. 요구사항은 “EKS(etcd)에 있는 시크릿의 암호화”임.
C. EBS CSI 드라이버는 퍼시스턴트 볼륨(EBS) 용이며, etcd나 Kubernetes Secrets 암호화와 무관함.
D. alias/aws/ebs KMS 키와 기본 EBS 암호화는 EBS 볼륨 암호화용이며, etcd(제어 플레인 시크릿 저장소) 암호화에는 사용되지 않음. EKS 시크릿 암호화는 EKS KMS 시크릿 암호화(B) 로 설정해야 함.
Answer: D
요구사항
환경: Amazon RDS PostgreSQL 프로덕션, 현재 Single-AZ
목표: 데이터 과학자에게 거의 실시간 읽기 전용 접근 제공
제약: 복잡한 쿼리가 프로덕션에 영향을 주지 않아야 함
필요: 고가용성 솔루션, 가장 비용 효율적으로 충족
D. Single-AZ → 읽기 가능 대기 2개를 둔 다중 AZ 클러스터 배포, 데이터 과학자에게 읽기 엔드포인트 제공
다중 AZ 클러스터 = Aurora: Writer + 읽기 가능 대기(리플리카) 2개 구성은 Aurora 클러스터 패턴임. 읽기 엔드포인트(Reader Endpoint) 는 읽기 전용 트래픽을 리플리카들에 분산함.
프로덕션 영향 없음: 데이터 과학자는 읽기 엔드포인트만 사용하므로 Writer에는 연결하지 않고, 복잡한 쿼리 부하가 프로덕션 쓰기 인스턴스에 걸리지 않음.
거의 실시간: Aurora 복제 지연은 보통 100ms 미만 수준이라, 읽기 전용 용도로 “거의 실시간” 요구를 만족함.
고가용성: 다중 AZ + 리플리카 2대로 Writer/Reader 장애에 대비하고, 읽기 엔드포인트가 정상 리플리카로만 트래픽을 보냄.
비용 효율: Aurora는 스토리지가 클러스터 공유라, RDS에서 Primary + 읽기 복제본 2대를 따로 두는 것보다 스토리지·관리 측면에서 유리할 수 있음. 읽기 엔드포인트 하나로 읽기 부하를 처리해 구성이 단순함.
틀린 이유
A. 프로덕션 인스턴스만 키우고 데이터 과학자가 같은 인스턴스를 쓰면, 복잡한 쿼리가 프로덕션 CPU·I/O를 사용해 “프로덕션에 영향을 주지 않는다”는 요구를 충족하지 못함.
B. RDS 표준 Multi-AZ에서 보조(Standby) 인스턴스는 장애 조치용이며 읽기 연결을 허용하지 않음. 데이터 과학자에게 “보조 인스턴스 접근”을 주는 구성은 지원되지 않음.
C. Multi-AZ + 읽기 복제본 2개로 데이터 과학자에게 읽기 전용을 주는 것은 가능하지만, “다중 AZ 클러스터 배포 + 읽기 엔드포인트”(D)는 Aurora의 Reader Endpoint를 쓰는 구조로, 리플리카 관리·고가용·비용 측면에서 요구사항에 더 잘 맞음. 정답은 D.
Answer: A
요구사항
환경: 3 AZ에서 동작하는 3계층 웹 앱(ALB, EC2 웹 서버, EC2 MySQL)
현재: 웹 서버가 세션 상태 보유, DB는 EC2 MySQL 단일 구성
예상: 애플리케이션 트래픽 급증
목표: 미래 용량 수요 대응 + 3개 AZ 모두에서 고가용성 확보
A. RDS MySQL 다중 AZ DB 클러스터 + ElastiCache Redis(HA) 세션·캐시 + 3 AZ Auto Scaling 그룹
DB 고가용: MySQL을 RDS for MySQL 다중 AZ DB 클러스터로 이전하면 여러 AZ에 Writer/Reader가 분산되어 DB 장애 시 자동 장애 조치로 3 AZ 수준 DB 고가용성을 만족함.
세션·캐시: ElastiCache for Redis(고가용 구성) 로 세션과 읽기 캐시를 공유하면, 웹 서버를 3 AZ ASG로 늘려도 세션 유지와 읽기 부하 감소가 가능함.
웹 계층 확장·고가용: 웹 서버를 3개 AZ에 걸친 Auto Scaling 그룹으로 옮기면 트래픽 증가에 확장 가능하고, AZ 장애 시에도 3 AZ 고가용성을 유지할 수 있음.
변경 범위: MySQL·앱 로직은 유지한 채 RDS·Redis·ASG만 도입하는 구성이라, 요구사항을 가장 직접적으로 충족함.
틀린 이유
B. ElastiCache Memcached는 Redis보다 세션용으로 불리함(지속성·복제 구조가 Redis보다 약함). 세션 상태 + 읽기 캐시에는 Redis(A) 가 적합함.
C. MySQL을 DynamoDB로 바꾸면 스키마·쿼리·트랜잭션 전반을 바꿔야 해 애플리케이션 변경이 크고, “3 AZ 고가용·확장”만으로는 이 정도 전환을 요구하지 않음.
D. RDS를 단일 AZ로 두면 DB가 한 AZ에만 있어 3개 AZ 모두에서의 고가용성을 만족하지 못함. DB도 다중 AZ가 필요하므로 A가 맞음.
Answer: A
요구사항
환경: 글로벌 비디오 스트리밍, Amazon CloudFront CDN 사용
목표: 여러 국가에 단계적으로 콘텐츠 배포
제약: 배포 국가 밖에 있는 시청자는 콘텐츠를 볼 수 없어야 함
A. CloudFront에 허용 목록(allow list) 기반 지리적 제한 추가, 사용자 지정 오류 메시지 설정
지리적 제한: CloudFront Geo Restriction에서 허용 목록(allow list) 에 “콘텐츠를 배포하는 국가”만 넣으면, 해당 국가에서만 접근 가능하고 나머지 국가는 차단됨.
요구사항 충족: “배포 국가 밖 시청자는 볼 수 없음”을 국가 단위로 강제할 수 있음.
사용자 지정 오류: 차단된 요청에 대해 403 등 사용자 지정 오류 페이지/메시지를 설정해, “이 지역에서는 시청할 수 없습니다” 등으로 안내 가능.
틀린 이유
B. 서명된 URL·쿠키는 누가·언제 접근하는지 제어하는 용도이며, 어느 국가에서 접근하는지는 제어하지 않음. 배포 국가 밖 사용자도 서명된 URL을 받으면 접근할 수 있어 지리적 제한을 만족하지 못함.
C. 데이터 암호화는 전송/저장 보안용이며, 국가별 접근 차단 기능이 아님. 암호화만으로는 “배포 국가 밖 시청 불가”를 보장할 수 없음.
D. 서명된 URL에 시간 제한을 두는 것은 접근 기간 제어일 뿐, 지리적(국가) 제한이 아님. 국가별 차단에는 Geo Restriction(A)이 필요함.
Answer: B
요구사항
환경: 온프레미스 Microsoft SQL Server Standard (VM)
목표: AWS로 DR(재해 복구) 강화
RPO: 30초 이하
RTO: 60분 이하
제약: DR 비용 가능한 한 최소화
B. AWS에 SQL Server용 웜 스탠바이 RDS 구성, AWS DMS에 CDC(Change Data Capture) 설정
RPO 30초 이하: DMS CDC로 온프레미스 SQL Server의 변경을 거의 실시간으로 RDS에 반영하므로, 데이터 손실 구간을 30초 이하로 유지할 수 있음.
RTO 60분 이하: 웜 스탠바이 RDS가 이미 기동 중이므로, 장애 시 애플리케이션 연결만 RDS로 전환하면 되어 60분 이내 복구가 가능함.
비용 최소화: SQL Server Enterprise나 온프레미스·AWS 이중 활성 구성 없이, 관리형 RDS(웜 스탠바이) + DMS만으로 DB DR을 구현해 라이선스·운영 비용을 줄일 수 있음.
표준 패턴: 온프레미스 SQL Server → AWS RDS로의 DB DR에 DMS CDC + RDS 웜 스탠바이 조합이 권장되는 방식임.
틀린 이유
A. Always On 가용성 그룹 + SQL Server Enterprise는 Enterprise 라이선스 비용이 크고, “비용 최소화” 요구와 맞지 않음. 현재 Standard 사용 조건에서도 비용이 증가함.
C. Elastic Disaster Recovery는 VM/디스크 단위 복제에 적합하고, SQL Server DB에 특화된 복제·일관성 보장 측면에서는 DMS CDC + RDS(B)가 더 적합함. DB DR·비용 측면에서 B가 더 나음.
D. 매일 밤 백업만 S3에 보관하면 RPO가 최대 약 24시간이 되어, “RPO 30초 이하” 요구를 충족하지 못함.
Answer: D
요구사항
현재: 온프레미스 Oracle DB로 고객 정보 처리·저장
목표: AWS DB 서비스로 가용성 향상, 애플리케이션 성능 개선, 보고를 기본 DB에서 오프로드
제약: 운영상 가장 효율적인 방식
D. 다중 AZ 인스턴스 배포의 Amazon RDS로 Aurora 생성, 보고는 리더(Reader) 인스턴스로 연결
Aurora 다중 AZ 클러스터: Aurora는 다중 AZ 클러스터로 Writer 1개 + Reader 다수 구성, 자동 장애 조치로 고가용성을 제공함.
보고 오프로드: 리더 인스턴스에 보고 트래픽만 보내면, 기본 Writer는 OLTP만 담당해 보고 부하가 기본 DB에서 분리되고 성능이 개선됨.
운영 효율: Aurora는 관리형 서비스로 패치·백업·장애 조치·읽기 확장이 자동에 가깝고, 리더만 추가해 보고 전용 엔드포인트로 연결하면 됨.
엔진 전환: Oracle → Aurora는 엔진 변경이 필요하지만, “가용성·성능·보고 오프로드·운영 효율”을 한꺼번에 만족하려면 Aurora + 리더(D)가 가장 잘 맞는 선택임.
틀린 이유
A. 여러 리전에 RDS 인스턴스를 두고 보고를 별도 인스턴스로 보내는 구성은 리전 간 복제·관리가 들어가 운영이 무거워져 “운영상 가장 효율적”이 아님.
B. 단일 AZ RDS Oracle + 읽기 전용 복제본은 고가용성이 떨어짐(AZ 장애 시 복구 시간 길어짐). “더 높은 가용성” 요구를 충족하기 어려움.
C. RDS for Oracle 다중 AZ 클러스터 배포는 가능하지만, 읽기 확장·리더 전용 엔드포인트는 Aurora보다 단순하지 않고, “보고 오프로드 + 운영 효율” 측면에서 Aurora(D)가 더 적합함.
Answer: A, C, E
요구사항
환경: AWS에서 웹 애플리케이션 구축
트래픽: 클라이언트 요청이 예측 불가, 오랫동안 유휴 가능
접근 제어: 가입비를 낸 고객만 로그인·사용 가능
목표: 위를 가장 비용 효율적으로 만족하는 3가지 단계 조합
A. DynamoDB에서 사용자 정보를 조회하는 Lambda 생성, API Gateway REST 엔드포인트 생성 후 API 호출을 Lambda로 라우팅
서버리스: Lambda + API Gateway + DynamoDB는 요청당 과금이라, 예측 불가·장시간 유휴 트래픽에서 유휴 비용 없음, “가장 비용 효율적”에 부합함.
DynamoDB: 사용자 정보·구독 정보 저장·조회에 적합하고, 사용량에 따라 용량이 늘어나 비용 효율적임.
API Gateway: REST API 수락·인증 연동(Cognito 등)을 한 곳에서 처리 가능함.
C. 사용자 인증용 Amazon Cognito 사용자 풀 생성
User Pool: 가입·로그인·JWT 발급 등 웹 앱 사용자 인증용. “가입비를 지불한 고객만 로그인”은 Cognito User Pool으로 구현함.
API Gateway 연동: API에서 Cognito User Pool을 인증자로 지정하면, 로그인한 유료 회원만 API를 호출하도록 제어 가능함.
E. AWS Amplify로 HTML/CSS/JS 프론트엔드 제공, 통합 CloudFront 구성 사용
Amplify: 정적 프론트엔드(HTML, CSS, JS) 호스팅 + CloudFront 연동으로 배포·캐싱을 한 번에 구성 가능함.
비용 효율: 스토리지·요청당 과금, 예측 불가·유휴 트래픽에 유리하고, 별도 EC2/ECS 없이 최소 운영으로 제공 가능함.
틀린 이유
B. ALB + ECS + RDS는 항상 동작하는 서버·DB가 필요해 예측 불가·장시간 유휴 트래픽에서 유휴 비용이 크고, “가장 비용 효율적” 요구를 충족하기 어려움.
D. Cognito Identity Pool은 AWS 리소스 접근용 임시 자격 증명 발급용이며, “웹 앱 로그인·유료 회원만 사용” 같은 앱 사용자 인증에는 User Pool(C) 이 맞음.
F. S3 정적 웹 호스팅은 정적 파일만 제공하며, PHP는 서버에서 실행해야 하므로 S3만으로는 불가능함. PHP를 쓰려면 EC2/Lambda 등이 필요하고, 정적만 쓸 때도 비용·운영 측면에서 Amplify+CloudFront(E) 조합이 더 적합함.
Answer: B
요구사항
환경: Amazon CloudFront로 인터넷에 콘텐츠 제공, 원본은 Amazon S3
접근: 프리미엄 고객만 미디어 스트림·파일 콘텐츠 접근
기능: 영화 대여·음악 다운로드 등 주문형 콘텐츠 제공
목표: 위를 만족하는 솔루션
B. 프리미엄 고객에게 CloudFront 서명 URL 생성·제공
접근 제한: CloudFront 서명 URL(또는 서명 쿠키)을 가진 요청만 콘텐츠에 접근 가능. 서명 URL을 프리미엄 고객에게만 발급하면 비프리미엄은 접근 불가.
주문형 콘텐츠: 대여·다운로드마다 만료 시간이 있는 서명 URL을 생성해 제공하면, 기간·용도별 접근 제어가 가능함.
CloudFront 경로: 콘텐츠가 CloudFront로 제공되므로, 접근 제어는 CloudFront 서명 URL/쿠키로 하는 것이 맞고, S3 직접 접근용 presigned와 구분됨.
운영: 백엔드에서 고객 등급·구매 정보를 보고 서명 URL만 발급하면 되므로, 별도 인증 게이트웨이 없이 구현 가능함.
틀린 이유
A. S3 서명 쿠키는 S3 직접 접근용이라, “CloudFront 배포로 콘텐츠 제공” 구조에서는 접근 제어를 CloudFront에서 하는 CloudFront 서명 URL/쿠키(B) 가 적합함.
C. 원본 액세스 제어(OAC)는 오리진(S3)에谁能 접근할 수 있는지를 제한하는 것(CloudFront만 S3에 접근하도록)이며, 최종 사용자(프리미엄 vs 비프리미엄) 구분에는 사용하지 않음.
D. 필드 수준 암호화는 요청/응답의 특정 필드 암호화용이며, “비프리미엄 고객 차단”이나 프리미엄 전용·주문형 접근 제어 기능이 아님.
Answer: A, E
요구사항
환경: 여러 AWS 계정에서 EC2 실행, 계정별로 개별 과금
상황: Savings Plan 구매 후, 비즈니스 변경으로 많은 EC2 인스턴스 폐기
목표: 다른 AWS 계정에서도 Savings Plan 할인을 받을 수 있도록 하는 2가지 단계 조합
A. 마스터(관리) 계정의 AWS 계정 관리 콘솔에서 결제 기본 설정의 할인 공유 활성화
할인 공유: Organizations 관리(지급인) 계정에서 Billing 기본 설정의 할인 공유(Share discount) 를 켜면, Savings Plan·RI 할인이 조직에 연결된 모든 멤버 계정의 사용량에 적용됨.
Savings Plan 적용 범위: 관리 계정이 아닌 멤버 계정에서 발생한 EC2 등 사용량에도, 관리 계정에 있는 Savings Plan 할인이 적용됨.
필수 단계: 다른 계정에서 할인을 쓰려면 먼저 조직으로 묶은 뒤(E), 이 설정(A)을 해야 함.
E. 기존 EC2·Savings Plan이 있는 계정으로 AWS Organizations 조직 생성, 다른 AWS 계정을 마스터 계정에서 조직에 초대·가입
조직 생성: EC2 인스턴스와 Savings Plan을 보유한 기존 계정 중 하나를 Organizations 관리(마스터) 계정으로 두고, 해당 계정에서 AWS Organizations로 조직을 생성함.
다른 계정 가입: 다른 AWS 계정을 관리 계정에서 조직에 초대·연결해 멤버 계정으로 만듦. 이렇게 하면 모든 계정이 동일한 지급인(관리 계정) 아래에서 통합 결제됨.
할인 적용: 관리 계정에서 할인 공유(A)를 켜면, Savings Plan을 구매한 계정이 관리 계정이든 멤버 계정이든, 모든 멤버 계정의 EC2 등 사용량에 할인이 적용됨.
틀린 이유
B. “Savings Plan을 구매한 계정”에서 할인 공유를 켠다고 했을 때, 그 계정이 멤버 계정이면 할인 공유 설정은 관리(마스터) 계정에서만 가능함. 할인 공유는 관리 계정 기준이므로, 정답은 A(마스터 계정에서 활성화) 이고 B는 잘못된 위치를 가리킴.
C. AWS RAM은 VPC, Transit Gateway 등 리소스 공유용이며, Savings Plan은 RAM으로 공유하지 않음. Savings Plan 할인은 Organizations + 결제 기본 설정의 할인 공유(A) 로 처리함.
D. 새 지급인(관리) 계정을 만들어 그 계정으로 조직을 생성하면, 기존 계정·Savings Plan을 그 새 조직 아래로 옮겨야 해서 구조가 복잡해짐. 문제는 “기존 계정들에서 Savings Plan 할인 사용”이므로, 기존 계정 중 하나를 관리 계정으로 두는 E가 요구사항에 맞음.
Answer: A
요구사항
환경: 퍼블릭 REST API에 지역 API Gateway 사용, 사용자 지정 도메인 → Route 53 별칭 레코드
목표: 새 API 버전을 고객 영향 최소, 데이터 손실 최소로 릴리스
A. API Gateway 카나리아 릴리스 스테이지 생성 → 트래픽 일부를 카나리아로 지정 → 검증 후 프로덕션으로 승격
카나리아 배포: API Gateway 카나리아 배포로 트래픽의 일부만 새 버전(카나리아 스테이지)으로 보내고, 나머지는 기존 프로덕션 스테이지로 유지함.
고객 영향 최소: 처음에는 소수 트래픽만 새 API를 사용하므로, 문제가 있어도 영향 범위가 제한됨.
데이터 손실 최소: 점진적 전환으로 이상 시 카나리아 비율을 낮추거나 롤백할 수 있어, 잘못된 배포로 인한 대량 오류·데이터 손실 위험을 줄일 수 있음.
검증 후 승격: 카나리아에서 동작·성능을 확인한 뒤, 문제 없으면 카나리아 스테이지를 프로덕션으로 승격하거나 트래픽 비율을 100%로 늘리는 방식으로 완전 전환 가능함.
틀린 이유
B. Merge 모드로 가져온 뒤 바로 프로덕션 스테이지에 배포하면 전체 트래픽이 한 번에 새 버전으로 가서, 문제 발생 시 모든 고객이 영향을 받아 “고객 영향 최소”를 만족하지 못함.
C. Overwrite 모드로 API를 덮어쓴 뒤 프로덕션에 배포하는 것도 한 번에 전환하는 구조라, 장애 시 영향이 크고 “고객 영향·데이터 손실 최소”에 불리함.
D. 새 API에 사용자 지정 도메인을 붙이고 Route 53 별칭을 새 API로만 가리키면, 모든 트래픽이 한 번에 새 API로 전환됨. 점진적 전환이 아니므로 고객 영향·데이터 손실 최소화에는 카나리아(A)가 적합함.
Answer: B
요구사항
현재: 기본 웹사이트 DNS는 Route 53에서 호스팅, 도메인은 ALB를 가리킴
목표: 기본 웹사이트를 사용할 수 없을 때 사용자를 백업 정적 오류 페이지로 보냄
제약: 변경·인프라 오버헤드 최소화
B. Route 53 활성-수동 장애 조치 구성, ALB 상태 확인 실패 시 S3 정적 오류 페이지로 트래픽 전송
장애 조치 라우팅: Route 53에서 Primary 레코드 = ALB, Secondary 레코드 = S3 정적 오류 페이지. Primary에 상태 확인을 붙이면, ALB가 비정상일 때 자동으로 Secondary(S3)로 전환됨.
최소 변경: 기존 ALB 레코드는 Primary로 두고, S3 오류 페이지용 Secondary 레코드와 ALB용 상태 확인만 추가하면 됨. EC2 등 새 인프라 불필요.
데이터 손실 최소화: 장애 시 즉시 백업 페이지로 전환되어 사용자는 오류 페이지를 보게 되고, 복구 후 상태 확인이 통과하면 다시 ALB로 트래픽이 돌아감.
틀린 이유
A. 지연 시간 라우팅은 가장 빠른 엔드포인트로 보내는 정책이라, ALB 장애 시 “Primary 실패 → 백업으로 전환”하는 장애 조치 동작이 아님. 백업 오류 페이지 요구를 충족하지 못함.
C. 오류 페이지를 EC2에서 호스팅하면 인스턴스·관리 부담이 생겨, S3 정적 호스팅만 쓰는 B보다 인프라 오버헤드가 큼. “최소 변경”에 맞지 않음.
D. 다중값 응답 라우팅은 여러 정상 엔드포인트 중 하나를 반환하는 용도에 가깝고, “Primary 비정상일 때만 Secondary(백업 페이지)로 보내기”에는 장애 조치 라우팅(B) 이 맞는 패턴임.
Answer: D
요구사항
목표: 백업 비용 절감, 온프레미스 백업 인프라 단순화, 물리적 백업 테이프 제거
제약: 기존 온프레미스 백업 애플리케이션·워크플로우 유지(기존 투자 보존)
질문: 솔루션 설계자가 추천할 방안
D. AWS Storage Gateway를 iSCSI 기반 가상 테이프 라이브러리(VTL)로 구성해 백업 앱과 연결
VTL = 가상 테이프: Storage Gateway VTL은 iSCSI로 가상 테이프 드라이브·테이프 라이브러리를 노출해, 백업 앱이 기존처럼 “테이프에 백업”하는 방식 그대로 사용할 수 있음.
기존 워크플로우 유지: 백업 소프트웨어·잡 설정을 바꾸지 않고, 물리 테이프 대신 가상 테이프에 쓰도록만 전환하면 됨.
물리 테이프 제거: 가상 테이프는 S3(및 선택 시 Glacier)에 저장되므로 테이프 장비·물리 테이프 유지 비용을 줄일 수 있음.
비용 절감: 테이프 하드웨어·운송·보관 비용 감소, S3/Glacier로 스토리지 비용 최적화 가능.
틀린 이유
A. Storage Gateway 파일 게이트웨이(NFS) 는 “파일 공유 → S3” 용도라, 테이프 기반 백업 앱의 워크플로우(테이프 드라이브/라이브러리)를 그대로 쓰려면 맞지 않음. 테이프 제거하면서 기존 앱을 유지하려면 VTL(D) 가 적합함.
B. EFS는 NFS 파일 시스템이며, 온프레미스 백업 앱이 테이프 대신 NFS 타깃으로 바꿔야 함. 테이프 기반 워크플로우를 그대로 유지하는 요구를 충족하지 못함.
C. EFS는 iSCSI를 지원하지 않고 NFS만 지원함. “iSCSI로 EFS에 연결”은 잘못된 설명이라 성립하지 않음.
Answer: A
요구사항
환경: 여러 위치의 데이터 수집 센서, 대용량 데이터를 회사로 스트리밍
목표: AWS에서 대용량 스트리밍 데이터를 수집·처리
조건: 확장 가능, 거의 실시간 수집, Amazon S3에 저장(향후 보고용), 최소한의 운영 오버헤드
A. Amazon Kinesis Data Firehose로 스트리밍 데이터를 S3로 전달
스트리밍 수집 전용: Kinesis Data Firehose는 스트리밍 데이터 수집·전달용 관리형 서비스로, 센서/앱에서 보낸 데이터를 버퍼링한 뒤 S3 등으로 자동 전달함.
확장성: 수신 처리량이 늘어나도 서비스가 자동으로 확장되며, 대용량 스트리밍에 맞게 설계되어 있음.
거의 실시간: 버퍼 크기·간격을 설정해 수 초~수 분 단위로 S3에 전달할 수 있어, “거의 실시간” 수집 요구를 충족함.
S3 연동: S3가 기본 지원 대상이라, 추가 ETL 없이 향후 보고용으로 S3에 저장하기 적합함.
최소 운영: 서버·스트림 샤드 관리·커스텀 코드 없이 Firehose 스트림 생성·소스 연결·S3 버킷 지정만 하면 되므로 운영 부담이 적음.
틀린 이유
B. AWS Glue는 배치 ETL·데이터 카탈로그용이며, 실시간 스트리밍 수집 서비스가 아님. 대용량 스트리밍 수집에는 Firehose가 적합함.
C. Lambda로 스트리밍 데이터를 받아 S3에 넣을 수는 있으나, 대용량·고처리량일 때 동시 실행 한도·페이로드 제한이 있고, Kinesis Data Streams 등과 조합해 직접 관리할 부분이 많아 “최소 운영”에는 Firehose(A)가 더 적합함.
D. AWS DMS는 DB 마이그레이션·CDC용으로, 센서 스트리밍 데이터 수집용이 아님. DMS로는 센서 스트리밍을 S3로 전달하는 구조를 만들기 어렵고, 요구사항과 맞지 않음.
Answer: B
요구사항
환경: 재무·데이터 분석·개발 부서별 별도 AWS 계정
목적: 비용·보안을 위해 각 계정이 사용할 수 있는 AWS 서비스를 제한
제약: 최소한의 운영 오버헤드로 위를 충족
B. AWS Organizations에서 부서별 OU 생성, 각 OU에 서비스 제어 정책(SCP) 연결
OU로 부서 구분: Organizations에서 부서별 조직 단위(OU) 를 만들고, 각 부서 계정을 해당 OU에 배치함.
SCP로 서비스 제한: 서비스 제어 정책(SCP) 에서 허용/거부할 서비스를 정의하고, OU에 연결하면 해당 OU의 모든 계정에 적용됨. (예: 특정 OU에서 EC2 사용 거부, 특정 서비스만 허용 등)
비용·보안: 부서별로 서비스 사용 범위를 제한해 비용과 권한을 통제할 수 있음.
최소 운영: OU 구조와 SCP를 한 번 설정하면, 계정만 OU에 넣어도 정책이 적용되므로 지속적인 운영 부담이 적음.
틀린 이유
A. Systems Manager는 운영 작업(패치, Run Command 등)용이며, 계정/OU 단위로 서비스 사용을 제한하는 기능은 없음. “어떤 서비스를 쓸 수 있는지” 제어는 SCP(B)가 담당함.
C. CloudFormation은 리소스 프로비저닝용이라, “특정 서비스만 프로비저닝”은 할 수 있지만 다른 서비스 사용 자체를 막지는 못함. 사용자가 콘솔/CLI로 다른 서비스를 쓰는 것을 막으려면 Organizations + SCP(B)가 필요함.
D. Service Catalog는 승인된 제품만 프로비저닝하도록 하는 용도이며, 서비스 사용 허용/거부를 계정 수준에서 강제하는 것은 SCP의 역할임. “각 계정이 사용할 수 있는 서비스를 제어”하려면 Organizations + SCP(B)가 적합함.
Answer: B
요구사항
환경: 다중 계층 전자상거래(ALB·웹 퍼블릭, MySQL 클러스터 EC2는 프라이빗 서브넷)
필요: MySQL이 타사(인터넷 호스팅) 제품 카탈로그·가격 정보를 조회해야 함
목표: 보안 극대화, 운영 오버헤드는 늘리지 않음
B. 퍼블릭 서브넷에 NAT 게이트웨이 배포, 프라이빗 서브넷 라우팅 테이블에서 인터넷 바운드 트래픽을 NAT 게이트웨이로 전송
NAT 게이트웨이: 프라이빗 서브넷의 MySQL EC2는 퍼블릭 IP 없이 아웃바운드만 NAT 게이트웨이를 거쳐 인터넷(타사 API)에 접속할 수 있음.
보안: 인터넷 → IGW → 프라이빗 서브넷으로의 인바운드 경로는 없고, 아웃바운드만 허용되므로 DB 계층이 노출되지 않음.
최소 운영: NAT 게이트웨이는 관리형 서비스라 NAT 인스턴스처럼 패치·고가용성 구성을 직접 할 필요가 없어 운영 부담이 적음.
라우팅: 프라이빗 서브넷 경로 테이블에 0.0.0.0/0 → NAT 게이트웨이만 두면, 해당 서브넷의 MySQL 트래픽이 NAT 게이트웨이를 통해 나감.
틀린 이유
A. NAT 인스턴스는 EC2를 직접 관리(패치, 장애 대응, 고가용성)해야 해서 운영 부담이 커지며, “운영 오버헤드를 늘리지 않는다”는 조건에 맞지 않음.
C. 프라이빗 서브넷에서 인터넷 바운드 트래픽을 IGW로 직접 보내려면, 해당 인스턴스에 퍼블릭 IP가 필요하고, DB 계층이 인터넷에 노출되어 보안이 약해짐. IGW는 NAT를 하지 않아 프라이빗 IP만으로는 외부와 통신이 안 됨.
D. 가상 프라이빗 게이트웨이(VGW)는 사이트 간 VPN·Direct Connect용이라, 일반 인터넷(타사 API)으로 나가는 경로가 아니며, 이 요구사항을 충족하지 못함.
Answer: B, D
요구사항
환경: Lambda 환경 변수를 AWS KMS 키로 암호화
목표: 환경 변수를 복호화·사용하는 데 필요한 권한이 있는지 확인
질문: 올바른 권한을 구현하기 위해 솔루션 설계자가 수행해야 할 단계 2개 선택
B. Lambda 실행 역할에 AWS KMS 권한 추가
Lambda가 실행될 때 실행 역할(Execution Role) 로 KMS API를 호출함.
실행 역할에 kms:Decrypt (및 필요 시 kms:DescribeKey 등) 권한을 부여해야, Lambda가 KMS로 암호화된 환경 변수를 복호화할 수 있음.
따라서 Lambda 실행 역할에 KMS 권한을 추가하는 단계가 필요함.
D. AWS KMS 키 정책에서 Lambda 실행 역할 허용
KMS 키는 키 정책(Key Policy) 으로 어떤 주체(Principal)가 해당 키를 사용할 수 있는지 제어함.
Lambda 실행 역할이 KMS Decrypt를 호출하려면, 해당 KMS 키 정책에서 그 실행 역할을 Principal로 넣고 kms:Decrypt 등을 허용해야 함.
따라서 KMS 키 정책에서 Lambda 실행 역할을 허용하는 단계가 필요함.
틀린 이유
A. Lambda 리소스 정책은 “누가 Lambda를 호출할 수 있는지”(invoke 권한)를 제어함. 환경 변수 복호화는 실행 중인 Lambda의 실행 역할이 KMS를 호출하는 것이므로, KMS 권한은 실행 역할(B)과 키 정책(D)에 두어야 함.
C. Lambda에는 “함수 정책”이라는 별도 KMS 정책이 없음. KMS 사용 권한은 실행 역할(B) 과 KMS 키 정책(D) 에서 설정함.
E. KMS 키 정책은 Principal(역할/사용자 등) 을 허용하지, “Lambda 리소스 정책”을 허용하는 것이 아님. 허용해야 하는 것은 Lambda 실행 역할(D) 임.
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 601-650 (0) | 2026.02.03 |
|---|---|
| AWS SAA-C03 Dump 551-600 (0) | 2026.02.03 |
| AWS SAA-C03 Dump 451-500 (0) | 2026.02.02 |
| AWS SAA-C03 Dump 401-450 (0) | 2026.02.02 |
| AWS SAA-C03 Dump 351-400 (0) | 2026.02.01 |
