AWS SAA-C03 Dump 401-450
Answer: A
요구사항
AWS로 기존 앱의 가용성·탄력성 향상
현재 앱은 온프레미스 데이터 센터에 있음
예기치 않은 정전으로 DB 서버 크래시 → 최근 데이터 손실 발생
단일 실패 지점(SPOF) 제거 필요
사용자 수요에 맞춰 확장 가능해야 함
A. 다중 AZ Auto Scaling(EC2) + 다중 AZ RDS
여러 가용 영역에 걸친 EC2 Auto Scaling 그룹으로 애플리케이션 서버를 두고, Amazon RDS를 다중 AZ(Multi-AZ) 로 구성하는 방식입니다.
단일 실패 지점 제거:
앱 계층: 여러 AZ에 EC2를 두면 한 AZ 장애 시에도 다른 AZ 인스턴스가 서비스 가능합니다.
DB 계층: RDS 다중 AZ는 주 인스턴스(1 AZ) + 대기 인스턴스(다른 AZ) 로, 주 인스턴스 장애 시 자동 장애 조치가 되므로 DB도 단일 실패 지점이 아니게 됩니다.
데이터 손실 완화:
RDS 다중 AZ는 동기 복제로 주 인스턴스와 대기 인스턴스가 동기화되므로, 정전 등으로 주 인스턴스가 죽어도 대기 인스턴스로 자동 전환되며 최근 커밋된 데이터는 유지됩니다. “DB 서버 크래시 후 데이터 손실” 같은 상황을 줄이는 데 적합합니다.
확장성:
Auto Scaling 그룹으로 트래픽에 맞춰 EC2 수를 늘리거나 줄일 수 있어 “사용자 요구에 맞게 확장” 요구를 충족합니다.
Answer: A
요구사항
EC2 앱 → Amazon Kinesis Data Streams(기본 설정)로 대량 스트리밍 데이터 전송
격일(이틀에 한 번) 로 앱이 데이터를 소비해 BI 처리용으로 Amazon S3에 기록
문제: S3가 앱이 Kinesis로 보낸 모든 데이터를 받지 못함
원인 파악 후 해결 필요
원인: Kinesis 데이터 보존 기간
Kinesis Data Streams의 기본 데이터 보존 기간은 24시간입니다.
소비자가 격일(48시간 주기) 로만 읽는다면, 24시간이 지난 데이터는 소비자가 읽기 전에 스트림에서 삭제(만료) 됩니다.
그래서 “S3가 Kinesis로 보낸 모든 데이터를 받지 못한다”는 현상이 발생합니다.
A. Kinesis 데이터 보존 기간 수정
Kinesis Data Streams의 데이터 보존 기간을 24시간보다 길게(예: 48시간, 7일 등) 늘리는 설정 변경입니다.
효과: 보존 기간을 소비 주기(격일) 이상으로 두면, 소비자가 이틀에 한 번 실행될 때도 그전에 적재된 데이터가 아직 스트림에 남아 있어 모두 읽을 수 있고, 그 결과 S3에 전송된 데이터가 누락 없이 기록됩니다.
적용 방법: Kinesis Data Streams의 데이터 보존 기간(retention period) 설정을 48시간 이상(필요 시 7일 등)으로 늘리면 됩니다.
Answer: D
요구사항
Lambda 함수로 파일을 Amazon S3에 업로드하는 애플리케이션
해당 작업에 필요한 권한을 부여해야 함
개발자에게는 S3 권한이 있는 IAM 사용자가 이미 있음
권한을 부여하려면 솔루션 설계자가 무엇을 해야 하는지 묻는 문제
D. 필요한 권한이 있는 IAM 실행 역할을 만들고 Lambda 함수에 연결
Lambda 실행 역할(Execution Role) 을 하나 만들고, 그 역할에 S3 업로드에 필요한 권한(예: s3:PutObject, s3:PutObjectAcl 등)을 부여한 뒤, 해당 역할을 Lambda 함수에 연결하는 구성입니다.
Lambda와 권한: Lambda는 IAM 사용자 자격 증명을 쓰지 않고, 실행 시 함수에 연결된 IAM 역할을 자동으로 맡습니다. 그래서 “S3에 업로드” 권한을 주려면 Lambda에 붙이는 IAM 역할에 S3 권한을 넣어야 합니다.
실행 역할: Lambda 콘솔/CLI에서 함수를 만들거나 수정할 때 “실행 역할”로 이 역할을 지정하면, Lambda가 이 역할로 임시 자격 증명을 받아 S3 API를 호출할 수 있습니다. 따라서 필요한 권한이 있는 IAM 실행 역할을 만들고, 그 역할을 Lambda 함수에 연결하는 것이 정답입니다.
Answer: D
요구사항
서버리스 앱: 새 문서가 S3에 업로드되면 Lambda 호출 → Lambda가 문서 처리
문제: 최근 마케팅 캠페인 이후 많은 문서가 올라왔는데, 많은 문서가 처리되지 않음
목표: 아키텍처 개선으로 이 문제 해결
원인: S3 → Lambda 직접 호출 시 버스트·쓰로틀링
S3에 문서가 많이 올라오면, 객체당 하나씩 S3 이벤트가 나가서 Lambda가 동시에 많이 호출됩니다.
Lambda에는 동시 실행 수(동시성) 제한이 있어, 이 한도를 넘으면 추가 호출이 쓰로틀링되고, 그때 발생한 S3 이벤트는 재시도·보관이 보장되지 않아 일부 문서가 처리되지 않은 채 사라질 수 있습니다.
D. SQS 대기열 생성 → 요청을 대기열로 보냄 → Lambda 이벤트 소스로 SQS 연결
Amazon SQS 대기열을 하나 만들고, S3 이벤트가 발생하면 그 요청(문서 정보) 을 SQS 메시지로 보냅니다. 그 다음 Lambda의 이벤트 소스를 SQS 대기열로 설정하는 구성입니다.
버퍼링: S3 → SQS → Lambda로 하면, 문서 업로드가 몰려도 요청이 먼저 SQS에 쌓이고, Lambda는 대기열에서 메시지를 꺼내 처리합니다. Lambda가 바쁘거나 쓰로틀되면 메시지는 대기열에 남아 있다가 나중에 다시 전달됩니다.
유실 방지: SQS는 메시지를 보관하고, Lambda–SQS 연동은 실패 시 재시도를 지원하므로, “많은 문서가 처리되지 않는다”는 현상을 줄일 수 있습니다.
처리량 조절: Lambda 동시성·SQS 배치 크기 등을 조정해, 한 번에 처리하는 양을 제어할 수 있습니다.
구성 요약: S3 이벤트 알림 대상을 SQS 대기열로 두고, Lambda는 SQS를 이벤트 소스로 두어 폴링하도록 설정하면 됩니다.
Answer: D, E
요구사항
소프트웨어 데모 환경: ALB 뒤 Auto Scaling 그룹의 EC2 인스턴스
근무 시간: 트래픽이 크게 증가
주말: 동작하지 않아도 됨
수요에 맞게 시스템을 확장할 수 있도록 2개 선택
D. 대상 추적 조정 정책으로 Auto Scaling 그룹을 인스턴스 CPU 사용률 기준으로 조정
대상 추적 조정 정책(Target tracking scaling policy) 을 쓰고, 인스턴스 CPU 사용률(예: 70%)을 목표로 두면, CPU가 올라갈 때(근무 시간·트래픽 증가) ASG가 인스턴스를 늘리고, CPU가 내려가면 인스턴스를 줄입니다. 그래서 근무 시간 수요에 맞춰 자동으로 확장·축소됩니다.
E. 예약된 조정으로 주말 동안 Auto Scaling 그룹의 최소·최대·원하는 용량을 0으로 변경, 주의 시작 시 기본값으로 복원
예약된 조정(Scheduled scaling) 으로 주말(예: 금요일 밤)에 ASG의 최소·최대·원하는 용량을 0으로 두면, 주말에는 인스턴스가 0대로 유지됩니다. 주의 시작(예: 월요일 아침)에 다시 기본값(예: min=2, max=10, desired=2)으로 되돌리면, 주중에는 다시 수요에 맞춰(D의 정책으로) 확장됩니다. “주말에는 동작하지 않아도 된다”는 요구를 충족합니다.
조합: D로 근무 시간 수요에 따른 확장, E로 주말 용량 0을 적용하면, 수요에 맞게 확장하면서 주말 비용을 줄일 수 있습니다.
---
A. ALB는 관리형 서비스로, 용량을 사용자가 “요청 속도에 따라 조정”하는 대상이 아닙니다. AWS Auto Scaling으로 “ALB 용량 조정”하는 설정은 없고, A는 부적절합니다.
B. VPC 인터넷 게이트웨이(IGW) 는 논리적 리소스로, 용량 확장을 Auto Scaling으로 하는 대상이 아닙니다. B는 잘못된 설명입니다.
C. 여러 리전에 EC2를 띄워 로드를 분산하는 것은, “근무 시간 수요에 맞춰 확장”과 “주말에는 동작 불필요”라는 요구와 직접 연결되지 않고, 데모 환경에는 과한 구성입니다. 요구사항을 만족하는 2개 조합은 D, E입니다.
Answer: C, D
요구사항
2계층: 퍼블릭 서브넷(웹 서버), 데이터베이스 서브넷(RDS for MySQL)
웹 서버: 포트 443으로 인터넷에서 접근 가능해야 함
DB 인스턴스: 포트 3306으로 웹 서버에서만 접근 가능해야 함
위를 만족하는 2개 단계 선택
C. 웹 서버용 보안 그룹 생성 후, 포트 443에서 0.0.0.0/0 인바운드 허용
웹 서버에 붙는 보안 그룹에서 인바운드로 프로토콜/포트 443, 소스 0.0.0.0/0을 허용하면, 인터넷(HTTPS)에서 웹 서버로 접근할 수 있어 “포트 443에서 인터넷에 열려 있어야 한다”는 요구를 충족합니다.
D. DB 인스턴스용 보안 그룹 생성 후, 포트 3306에서 웹 서버 보안 그룹 인바운드 허용
RDS(DB 인스턴스)에 붙는 보안 그룹에서 인바운드로 프로토콜/포트 3306, 소스 = 웹 서버 보안 그룹을 허용하면, 웹 서버만 DB(3306)에 접근할 수 있어 “포트 3306에서 웹 서버에서만 액세스 가능” 요구를 충족합니다. 퍼블릭 서브넷 CIDR 전체가 아니라 웹 서버 보안 그룹만 허용하므로 최소 권한에 맞습니다
Answer: D
요구사항
AWS에서 호스팅되는 게임 애플리케이션용 공유 스토리지
Lustre 클라이언트로 데이터에 접근할 수 있어야 함
완전 관리형 솔루션
D. Amazon FSx for Lustre
Amazon FSx for Lustre 파일 시스템을 만들고, 원본 서버와 애플리케이션 서버가 그 파일 시스템에 연결(마운트)하는 구성입니다.
Lustre 클라이언트: FSx for Lustre는 Lustre 프로토콜을 지원하는 관리형 파일 시스템입니다. Lustre 클라이언트를 사용하는 애플리케이션 서버가 Lustre 프로토콜로 마운트해 데이터에 접근할 수 있어 “Lustre 클라이언트로 데이터 접근” 요구를 충족합니다.
공유 스토리지: 여러 애플리케이션 서버가 동일한 FSx for Lustre 파일 시스템을 마운트해 공유 스토리지로 사용할 수 있습니다.
완전 관리형: FSx for Lustre는 AWS 관리형 서비스로, 파일 시스템 프로비저닝·패치·백업·고가용성 등은 AWS가 담당합니다.
Answer: B
요구사항
UDP로 수천 대의 지리적으로 분산된 원격 장치에서 데이터 수신
데이터 즉시 처리, 필요 시 장치로 다시 메시지 전송, 저장 없음
장치→앱 데이터 전송 지연 시간 최소화
다른 AWS 리전으로의 빠른 장애 조치 필요
B. Global Accelerator + 두 리전 NLB + ECS Fargate
AWS Global Accelerator를 두고, 두 리전에 각각 NLB(Network Load Balancer) 를 엔드포인트로 등록합니다. ECS Fargate 클러스터에서 ECS 서비스를 만들고, 그 서비스를 NLB 대상으로 두어 UDP 트래픽을 처리하는 구성입니다.
UDP 지원: NLB는 Layer 4 로드밸런서로 UDP를 지원합니다. ALB는 HTTP/HTTPS 전용이라 UDP를 쓸 수 없으므로, UDP 앱에는 NLB가 필요합니다.
지연 시간 최소화: Global Accelerator는 Anycast IP와 AWS 글로벌 네트워크를 사용해, 장치 트래픽이 가장 가까운 엣지로 들어가 정상 리전의 NLB로 전달됩니다. 지리적으로 분산된 장치에 대해 지연 시간을 줄이는 데 적합합니다.
빠른 리전 장애 조치: Global Accelerator가 엔드포인트(NLB) 헬스 체크를 하고, 한 리전이 비정상이면 다른 리전 NLB로 트래픽을 바로 전환합니다. DNS TTL에 의존하는 Route 53 장애 조치보다 네트워크 수준에서 더 빠른 장애 조치가 가능합니다.
처리: ECS Fargate 서비스가 NLB 뒤에서 UDP 패킷을 받아 즉시 처리하고, 필요 시 장치로 다시 보내는 로직을 담당합니다.
A. NLB는 Lambda를 대상(target) 으로 지정할 수 없습니다. NLB 대상은 EC2, IP, ALB 등이며, UDP 트래픽을 “Lambda로 전달해 처리”하는 구성은 지원되지 않습니다. 또한 Route 53 장애 조치는 DNS 기반이라 Global Accelerator보다 장애 조치가 느립니다.
C. Application Load Balancer(ALB) 는 Layer 7(HTTP/HTTPS) 전용이라 UDP를 지원하지 않습니다. UDP 기반 앱에는 C는 부적절합니다.
D. ALB는 UDP 미지원이라 UDP 앱에는 사용할 수 없고, Route 53 장애 조치는 Global Accelerator보다 장애 조치가 느립니다.
Answer: C
요구사항
Windows IIS 웹 애플리케이션을 AWS로 마이그레이션
현재 온프레미스 NAS의 파일 공유에 의존
IIS 웹 서버 → 여러 가용 영역의 EC2 + ELB 구성 예정
온프레미스 파일 공유를 대체할 스토리지 중 가장 탄력적·내구성 높은 선택
C. Amazon FSx for Windows File Server
Amazon FSx for Windows File Server로 파일 공유를 마이그레이션하는 방식입니다.
Windows·IIS와의 호환: IIS는 보통 SMB(Windows 파일 공유) 로 파일에 접근합니다. FSx for Windows File Server는 SMB를 지원하는 관리형 Windows 파일 서버라, 온프레미스 NAS(SMB)를 그대로 대체하기에 적합합니다.
탄력성·내구성: FSx for Windows는 다중 AZ 배포를 지원해, 한 AZ 장애 시에도 파일 공유가 유지됩니다. 여러 AZ의 EC2 인스턴스가 동일한 SMB 공유를 마운트해 사용할 수 있어 탄력적이고 내구성이 높습니다.
완전 관리형: 프로비저닝·패치·백업·고가용성은 AWS가 담당하므로, NAS를 직접 운영하는 것보다 관리 부담이 적습니다.
Answer: B
요구사항
EC2 인스턴스에 새 애플리케이션 배포
애플리케이션이 Amazon EBS 볼륨에 데이터 기록
EBS에 기록된 모든 데이터가 유휴 상태(at rest) 에서 암호화되어야 함
이 요구를 만족하는 솔루션 선택
B. 암호화된 EBS 볼륨 생성 후 EC2에 연결
EBS 볼륨을 생성할 때 암호화(encrypted) 를 지정하고, 그 암호화된 볼륨을 EC2 인스턴스에 연결하는 구성입니다.
유휴 데이터 암호화: EBS 볼륨을 암호화된 볼륨으로 만들면, 그 볼륨에 쓰이는 모든 데이터는 EBS/KMS로 유휴 상태에서 암호화됩니다. 애플리케이션이 그 볼륨에만 쓰도록 하면 “EBS에 기록된 모든 데이터가 유휴 상태에서 암호화된다”는 요구를 충족합니다.
적용 방법: 볼륨 생성 시 Encrypted 옵션을 켜거나, 리전 기본 EBS 암호화를 사용해 새 볼륨을 암호화된 상태로 만들고, 해당 볼륨을 EC2에 연결하면 됩니다.
A. IAM 역할은 EC2/애플리케이션이 AWS API를 호출할 때 쓰는 권한을 정의합니다. IAM 역할만으로는 “EBS 볼륨을 암호화한다”는 동작이 되지 않고, 볼륨을 암호화된 상태로 생성·연결(B) 해야 유휴 암호화가 적용됩니다.
C. EC2 인스턴스 태그(예: Encrypt=True)는 메타데이터일 뿐이며, EBS 볼륨의 암호화를 자동으로 켜주는 기능이 없습니다. 태그만으로는 “EBS에 기록된 모든 데이터가 유휴 상태에서 암호화된다”를 만족할 수 없습니다.
D. KMS 키 정책은 그 키를 누가 사용할 수 있는지를 제한합니다. 키 정책만으로는 “계정의 모든 EBS가 암호화된다”를 강제하지 않습니다. EBS 유휴 암호화를 만족하려면 암호화된 볼륨을 생성·연결(B) 하거나, 리전 기본 EBS 암호화를 켜는 등 볼륨/계정 수준 설정이 필요합니다.
Answer: C
요구사항
산발적 사용 패턴: 매달 초 많음, 매주 초 보통, 주중 예측 어려움
현재: 웹 서버 + MySQL DB(데이터 센터)
AWS로 이전 예정
데이터베이스 수정 없이 사용 가능해야 함
비용 효율적인 DB 플랫폼 선택
C. MySQL 호환 Amazon Aurora Serverless
Amazon Aurora Serverless(MySQL 호환) 를 사용하는 방식입니다.
데이터베이스 수정 불필요: Aurora Serverless는 MySQL 호환 API·프로토콜을 사용하므로, 기존 MySQL 앱은 스키마·쿼리·연결 방식을 바꾸지 않고 그대로 사용할 수 있어 “데이터베이스 수정이 필요하지 않은” 요구를 충족합니다.
비용 효율(산발적 사용): Aurora Serverless는 실제 부하에 따라 용량이 자동으로 늘었다 줄었다 합니다. 사용이 적을 때(주중 저사용)는 용량·비용이 줄고, 많을 때(매달 초·매주 초)는 자동으로 확장됩니다. 고정 인스턴스 크기를 24/7 유지하는 RDS MySQL보다 산발적 패턴에 맞춰 비용을 줄이기 좋습니다.
관리형: 인스턴스 크기·스케일링을 직접 관리할 필요가 없어, “비용 효율 + 수정 없음”을 함께 만족하기에 적합합니다.
Answer: D
요구사항
이미지 호스팅 회사: 객체를 Amazon S3 버킷에 저장
S3 버킷의 객체가 대중에게 우발적으로 노출되는 것을 방지해야 함
전체 AWS 계정의 모든 S3 객체는 비공개로 유지되어야 함
위를 만족하는 솔루션 선택
D. 계정 수준 S3 퍼블릭 액세스 차단 + SCP로 설정 변경 방지
계정 수준에서 S3 Block Public Access(퍼블릭 액세스 차단) 를 사용하고, AWS Organizations로 서비스 제어 정책(SCP) 을 만들어 IAM 사용자(및 역할) 가 해당 설정을 변경하지 못하도록 한 뒤, 해당 계정에 SCP를 적용하는 구성입니다.
우발적 공개 방지: S3 Block Public Access를 계정 수준으로 켜면, 해당 계정의 모든 S3 버킷에 대해 퍼블릭 액세스를 허용하는 버킷 정책·ACL 설정이 차단됩니다. 새 버킷·기존 버킷 모두 적용되므로, “객체가 대중에게 우발적으로 노출되는 것”을 사전에 막을 수 있습니다.
전체 계정의 객체 비공개 유지: 계정 단위로 차단을 두면, 계정 내 모든 S3 객체가 퍼블릭으로 열리는 설정 자체가 막혀 “전체 AWS 계정의 모든 S3 객체는 비공개” 요구를 충족합니다.
설정 변경 방지: IAM 사용자나 역할이 Block Public Access 설정을 끄거나 수정할 수 있으면, 실수나 악의로 다시 퍼블릭이 될 수 있습니다. SCP로 s3:PutAccountPublicAccessBlock 등 해당 설정 변경을 거부하면, 아무도 이 보호를 해제할 수 없어 요구사항을 안정적으로 유지할 수 있습니다.
Answer: B
요구사항
2계층 전자상거래: 웹 계층 + DB 계층, EC2에 배포
사용자 트래픽 증가 → 마케팅·주문 확인 이메일 전송에 상당한 지연 발생
복잡한 이메일 전송 이슈 해결에 쓰는 시간을 줄이고
운영 오버헤드를 최소화해야 함
B. 웹 인스턴스에서 Amazon SES로 이메일 전송
웹 인스턴스가 Amazon Simple Email Service(Amazon SES) API를 사용해 이메일을 보내도록 구성하는 방식입니다.
지연 완화: 웹 서버는 SES API 호출만 하면 되고, 실제 발송·재시도·배달은 SES가 처리합니다. 요청 경로에서 비동기로 SES를 호출하면 웹 계층 부하와 관계없이 이메일 전송 지연을 줄일 수 있습니다.
이메일 전송 이슈 감소: SES는 관리형 이메일 발송 서비스로, 발송 성공률·반송·스팸 필터·평판 등은 AWS가 관리합니다. 자체 SMTP/이메일 서버를 돌리지 않아 복잡한 이메일 전송 문제를 직접 해결할 일이 줄어듭니다.
운영 오버헤드 최소화: 이메일 전용 EC2·SMTP 서버·스케일링을 관리할 필요가 없고, SES API 호출만 추가하면 되어 운영 부담이 적습니다.
마케팅·주문 확인 메일: 수신자가 주문/캠페인마다 다른 동적 수신자이므로, SES처럼 “어떤 이메일 주소로든” 발송할 수 있는 서비스가 적합합니다
Answer: B
요구사항
비즈니스 시스템: 매일 수백 개 보고서 생성, CSV로 네트워크 공유에 저장
분석을 위해 이 데이터를 거의 실시간으로 AWS 클라우드에 저장해야 함
최소한의 관리 오버헤드로 위 요구 충족
B. S3 File Gateway + 비즈니스 시스템이 새 네트워크 공유 사용
Amazon S3 File Gateway(Storage Gateway File Gateway)를 만들고, S3 버킷에 매핑된 새 네트워크 공유(SMB 또는 NFS) 를 만든 뒤, 비즈니스 시스템이 기존 네트워크 공유 대신 이 새 공유에 보고서를 저장하도록 변경하는 구성입니다.
거의 실시간: File Gateway 공유는 S3에 백업됩니다. 비즈니스 시스템이 파일을 이 공유에 쓰면, File Gateway가 그대로 S3에 업로드합니다. 별도 전송 작업·스케줄 없이 저장 시점에 가깝게 S3에 반영되어 거의 실시간에 가깝습니다.
최소 관리 오버헤드: 별도 전송 스크립트·스케줄 작업·모니터링 앱을 둘 필요가 없습니다.
비즈니스 시스템은 기존처럼 네트워크 공유에 저장만 하면 되고, 저장 대상만 File Gateway 공유로 바꾸면 됩니다.
File Gateway는 AWS 관리형 구성요소라, 전용 EC2만 유지하면 되고 전송 로직은 직접 관리할 필요가 없어 관리 오버헤드가 적습니다.
데이터 흐름: 비즈니스 시스템 → (기존과 동일한 방식으로) File Gateway 네트워크 공유에 CSV 저장 → File Gateway가 S3에 업로드 → 분석용으로 S3 사용.
A. DataSync를 매일 끝날 때 한 번만 실행하면, 데이터가 하루에 한 번만 S3로 옮겨져 거의 실시간 요구를 충족하지 못합니다.
C. DataSync로 전송하고 DataSync API를 쓰는 애플리케이션을 두면, “새 파일 감지 → 전송 트리거” 로직을 개발·운영해야 해서 관리 오버헤드가 커집니다. 비즈니스 시스템이 File Gateway 공유에만 쓰면 자동으로 S3에 반영되는 B가 더 단순하고 관리 부담이 적습니다.
D. Transfer for SFTP와 네트워크 공유를 주기적으로 확인해 SFTP로 업로드하는 스크립트는, 스크립트 개발·실행 주기·모니터링을 직접 관리해야 하고, “거의 실시간”을 위해 짧은 주기로 돌리면 복잡도와 부담이 늘어납니다. 최소 관리 오버헤드에는 B가 더 적합합니다.
Answer: A
요구사항
페타바이트 규모 데이터가 Amazon S3 Standard에 저장
여러 S3 버킷에 분산, 접근 빈도가 제각각
모든 데이터에 대한 접근 패턴을 알 수 없음
S3 사용 비용 최적화를 위해 버킷별로 솔루션 적용
위를 가장 효율적으로 만족하는 방법 선택
A. S3 수명 주기로 객체를 S3 Intelligent-Tiering으로 전환
S3 수명 주기 구성에서, 객체를 S3 Intelligent-Tiering 스토리지 클래스로 전환(transition) 하는 규칙을 두는 방식입니다.
접근 패턴을 모를 때: S3 Intelligent-Tiering은 접근 패턴을 모르거나 변할 때 쓰기 좋습니다. 객체별로 실제 접근을 보고 자동으로 Frequent → Infrequent → Archive → Deep Archive 등 계층을 옮겨, “자주 쓰는 건 비싼 계층, 안 쓰는 건 저렴한 계층”으로 맞춥니다. 접근 패턴을 미리 알 필요가 없어 “모든 데이터의 접근 패턴을 알지 못함” 조건에 맞습니다.
비용 최적화: 자주 접근하는 데이터는 상대적으로 비싼 계층에, 드물게 접근하는 데이터는 저렴한 계층에 두어 전체 스토리지 비용을 줄입니다. Intelligent-Tiering은 접근 시 추가 조회 수수료 없이 계층만 바꾸므로, 잘못된 계층 선택으로 인한 조회 비용 폭증 위험이 적습니다.
효율성: 수명 주기 규칙만 두면 자동으로 객체가 Intelligent-Tiering으로 넘어가고, 이후 계층 이동도 서비스가 처리하므로 운영 부담이 적고 “가장 효율적으로” 비용을 최적화할 수 있습니다.
Answer: B, D
요구사항
글로벌 전자상거래, AWS에서 웹 애플리케이션 호스팅
정적·동적 콘텐츠 포함, OLTP 데이터는 Amazon RDS에 저장
문제: 웹사이트 사용자 페이지 로드 속도가 느림
이 문제 해결을 위한 2개 조치 선택
B. Amazon CloudFront 배포 설정
CloudFront는 CDN으로, 정적 콘텐츠(이미지, CSS, JS 등)를 엣지 로케이션에 캐시해 전 세계 사용자에게 가까운 엣지에서 전달합니다. 글로벌 사용자의 정적 리소스 로딩 지연이 줄어들어 페이지 로드 속도가 빨라집니다. 동적 콘텐츠도 캐시 정책에 따라 일부 캐시하거나, 최적화된 라우팅으로 지연을 줄일 수 있습니다.
D. RDS DB 인스턴스에 대한 읽기 전용 복제본 생성
읽기 전용 복제본을 두면 읽기 부하를 복제본으로 분산할 수 있습니다. 상품 목록·검색 결과 등 DB 읽기가 많은 페이지는 복제본에서 조회하도록 하면, 주 인스턴스 부하가 줄고 DB 응답 시간이 짧아져 페이지 로드 속도가 개선됩니다. OLTP 읽기 비중이 큰 전자상거래에는 읽기 복제본이 적합합니다.
조합: B로 정적·일부 동적 콘텐츠 전달 속도 개선, D로 DB 읽기 부하 분산 및 응답 시간 단축 → 페이지 로드 속도 문제 해결에 맞는 조합입니다.
Answer: C
요구사항
EC2 + Lambda로 애플리케이션 실행
VPC: 퍼블릭·프라이빗 서브넷, EC2는 프라이빗 서브넷 중 하나에서 실행
Lambda가 EC2에 직접 네트워크 접근해야 애플리케이션 동작
최소 1년 실행, 그동안 Lambda 함수 수 증가 예상
모든 애플리케이션 리소스에 대한 절감 극대화
서비스 간 네트워크 지연을 낮게 유지
C. Compute Savings Plan + Lambda 최적화 + Lambda를 EC2가 있는 프라이빗 서브넷에 연결
Compute Savings Plan을 구매하고, Lambda의 실행 시간·메모리·호출 수·전송 데이터 양을 최적화한 뒤, Lambda를 EC2가 있는 프라이빗 서브넷에 연결(VPC 설정) 하는 구성입니다.
절감 극대화: Compute Savings Plan은 EC2, Lambda, Fargate 등 컴퓨트 사용량에 적용됩니다. EC2만 적용되는 EC2 Instance Savings Plan과 달리, EC2와 Lambda 모두 절감 대상이 되어 “모든 애플리케이션 리소스 절감 극대화” 요구를 충족합니다. Lambda 수가 늘어나도 같은 플랜으로 커버됩니다.
Lambda → EC2 직접 접근·저지연: Lambda에 VPC를 설정하고 EC2가 있는 프라이빗 서브넷(및 필요한 보안 그룹)을 지정하면, Lambda가 같은 VPC 안에서 EC2의 프라이빗 IP로 접근할 수 있어 직접 네트워크 액세스와 낮은 지연을 만족합니다.
Lambda 최적화: 실행 시간·메모리·호출 수·데이터 전송량을 최적화하면 비용과 성능 모두에 도움이 됩니다.
A, B. EC2 Instance Savings Plan은 EC2 사용량에만 적용되고 Lambda에는 적용되지 않습니다. “모든 애플리케이션 리소스 절감 극대화”와 “Lambda 수 증가”를 고려하면 Compute Savings Plan(C) 이 맞습니다.
B. Lambda를 퍼블릭 서브넷에 두는 것만으로는 요구사항 위반이 아니지만, 정답이 C이므로 B는 “EC2 Instance Savings Plan” 때문에 부적절합니다.
D. Lambda를 Lambda 서비스 VPC(즉, 고객 VPC에 연결하지 않은 상태)에 두면, Lambda는 고객 VPC의 프라이빗 서브넷에 있는 EC2에 라우팅할 수 없습니다. “Lambda가 EC2에 직접 네트워크 액세스”해야 한다는 조건을 만족하려면 Lambda를 고객 VPC(EC2가 있는 프라이빗 서브넷)에 연결해야 하므로 D는 오답입니다.
Answer: B
요구사항
팀이 두 AWS 계정(개발·프로덕션)의 Amazon S3 버킷에 접근할 수 있어야 함
현재: 개발 계정의 IAM 사용자(IAM 그룹에 적절한 권한 부여)로 개발 계정 S3 버킷 접근 가능
프로덕션 계정에 IAM 역할이 이미 있음 → 그 역할에 프로덕션 S3 버킷 접근 정책이 붙어 있음
최소 권한 원칙을 지키면서 위 요구를 충족하는 방법 선택
B. 프로덕션 계정 역할의 신뢰 정책에 개발 계정을 주체로 추가
프로덕션 계정에 있는 IAM 역할의 신뢰 정책(Trust Policy) 에 개발 계정을 Principal로 추가하는 구성입니다.
크로스 계정 접근: 개발 계정 사용자가 프로덕션 계정의 S3에 접근하려면, 프로덕션 계정의 IAM 역할을 AssumeRole(역할 가정) 해야 합니다. 역할 가정이 허용되려면, 그 역할의 신뢰 정책에 “누가 이 역할을 가정할 수 있는지”가 정의되어 있어야 합니다. 개발 계정을 Principal로 넣으면(예: "AWS": "arn:aws:iam::개발계정ID:root" 또는 개발 계정의 특정 IAM 사용자/역할), 개발 계정 쪽 주체가 해당 역할을 가정할 수 있습니다.
동작: 개발 계정 사용자는 자기 계정 자격 증명으로 AssumeRole를 호출해 프로덕션 계정 역할의 임시 자격 증명을 받고, 그 자격 증명으로 프로덕션 S3에 접근합니다. 프로덕션 계정에는 별도 IAM 사용자를 만들 필요가 없습니다.
최소 권한: 프로덕션 역할에는 S3 접근 권한만 부여되어 있고, 신뢰 정책은 “개발 계정(또는 필요한 주체)만 역할 가정 가능”으로 제한할 수 있어 최소 권한을 지킬 수 있습니다.
Answer: C, E
요구사항
AWS Organizations(모든 기능 활성화), ap-southeast-2에서 EC2 워크로드
SCP로 다른 리전 리소스 생성 차단(이미 존재)
보안 정책: 유휴 데이터 암호화 필수
감사: 직원이 암호화 없이 EBS 볼륨 생성
목표: ap-southeast-2에서 모든 IAM 사용자·루트가 새 EC2 인스턴스를 시작할 때 암호화된 EBS만 사용
EBS 볼륨을 생성하는 직원에게 최소한의 영향으로 적용
E. 조직 관리 계정에서 기본 EBS 볼륨 암호화 설정 지정
리전/계정 기본 EBS 암호화를 켜고 기본 암호화 키를 지정하면, 해당 리전·계정에서 새로 생성되는 EBS 볼륨이 자동으로 암호화됩니다. EC2 인스턴스 루트 볼륨도 이 설정을 따릅니다. 직원은 별도로 “암호화 켜기”를 선택하지 않아도 되므로 영향이 최소입니다. 관리 계정에서 각 멤버 계정(또는 대상 계정)에 대해 이 설정을 지정하는 방식으로 적용할 수 있습니다.
C. SCP 생성 후 루트 OU에 연결, ec2:Encrypted가 false일 때 ec2:CreateVolume 거부
서비스 제어 정책(SCP) 에서 ec2:CreateVolume 호출 시 ec2:Encrypted 조건이 false인 경우(즉, 암호화 없이 볼륨 생성)를 명시적으로 거부합니다. 루트 OU에 이 SCP를 붙이면, 해당 OU 아래 모든 계정의 모든 주체(IAM 사용자, 루트, 역할)가 암호화되지 않은 EBS 볼륨 생성을 할 수 없습니다. “모든 IAM 사용자 또는 루트”가 암호화된 EBS만 쓰게 하려는 요구를 정책으로 강제하는 단계입니다.
조합: E로 기본 암호화를 켜서 대부분의 생성이 자동으로 암호화되고, C로 암호화 없이 CreateVolume 시도를 차단해 예외를 막습니다. 직원은 기존처럼 인스턴스/볼륨을 생성해도 되고, 정책 위반 시에만 거부되므로 최소 영향으로 요구사항을 충족합니다.
Answer: D
요구사항
Amazon RDS for PostgreSQL DB 클러스터로 프로덕션 DB 워크로드
고가용성 확보
대부분의 시나리오에서 40초 이내 자동 장애 조치
기본(primary)에서 읽기 오프로드
비용을 가능한 한 낮게 유지
D. RDS 다중 AZ DB 클러스터 + 읽기 워크로드는 리더 엔드포인트로
Amazon RDS 다중 AZ DB 클러스터 배포를 사용하고, 읽기 워크로드는 리더 엔드포인트(reader endpoint) 로 보내는 구성입니다.
40초 이내 장애 조치: RDS Multi-AZ DB 클러스터는 클러스터 스토리지와 리더 인스턴스 구조로, Multi-AZ DB 인스턴스(기본+대기)보다 장애 조치가 짧습니다. 대부분의 시나리오에서 약 40초 이내 자동 장애 조치가 가능해 “40초 이내” 요구를 충족합니다.
읽기 오프로드: DB 클러스터에는 리더 인스턴스(reader) 가 있고, 리더 엔드포인트로 트래픽을 보내면 기본(writer)에서 읽기를 분리할 수 있습니다. 읽기 워크로드를 리더 엔드포인트로 지정하면 “기본에서 읽기 오프로드” 요구를 만족합니다.
고가용성: 다중 AZ DB 클러스터는 자동 장애 조치와 고가용성을 제공합니다.
비용: 리더 1대로 리더 엔드포인트를 쓰는 구성은 리더를 여러 대 두는 것보다 비용이 적게 들어 “비용을 가능한 한 낮게”에 맞습니다.
Answer: B
요구사항
고가용성 SFTP 서비스: EC2 2대 + Elastic IP, 신뢰할 수 있는 IP만 허용, 공유 스토리지, Linux 사용자로 계정 관리
목표: 서버리스 SFTP, 높은 IOPS, 구성 가능한 보안, 사용자 권한 제어 유지
위를 만족하는 솔루션 선택
B. 암호화된 EFS + Transfer Family SFTP(VPC 엔드포인트, 신뢰 IP만) + 사용자 권한 부여
암호화된 Amazon EFS 파일 시스템을 만들고, Elastic IP·인터넷 접근이 있는 VPC 엔드포인트로 AWS Transfer Family SFTP 서비스를 생성한 뒤, 신뢰할 수 있는 IP만 허용하는 보안 그룹을 엔드포인트에 연결하고, EFS를 SFTP 서비스의 백엔드 스토리지로 연결한 다음, 사용자별로 SFTP 접근 권한을 부여하는 구성입니다.
서버리스: AWS Transfer Family SFTP는 관리형 서비스로, SFTP 서버용 EC2를 직접 운영할 필요가 없어 서버리스 요구를 충족합니다.
높은 IOPS: EFS는 파일 시스템 워크로드에 맞춰 IOPS·처리량이 스케일하고, 공유 스토리지처럼 여러 클라이언트가 동시에 사용할 수 있어 “높은 IOPS” 요구에 적합합니다. Transfer Family는 EFS를 백엔드로 사용할 수 있습니다.
구성 가능한 보안: VPC 엔드포인트에 보안 그룹을 붙여 신뢰할 수 있는 IP만 허용할 수 있습니다.
Elastic IP·인터넷 연결로 외부 클라이언트 접속을 유지하면서, 보안 그룹으로 소스 제한을 세밀하게 할 수 있어 구성 가능한 보안을 만족합니다.
사용자 권한 제어: Transfer Family에서 사용자별 스코프 다운 정책·역할을 설정하고, EFS는 POSIX(Linux) 권한을 지원하므로, 기존처럼 “사용자 권한에 대한 제어”를 유지할 수 있습니다.
A. AWS Transfer Family SFTP의 백엔드 스토리지는 S3 또는 EFS만 지원합니다. EBS 볼륨을 SFTP 서비스 엔드포인트에 “연결”하는 구성은 지원되지 않으므로 A는 잘못된 설명입니다.
C. S3를 백엔드로 쓰는 Transfer Family는 가능하지만, 파일 시스템 형태의 높은 IOPS와 Linux 사용자·POSIX 권한 모델을 쓰려면 EFS(B) 가 더 적합합니다. “높은 IOPS”와 “사용자 권한 제어 유지”를 함께 만족하는 것은 B입니다.
D. 프라이빗 서브넷·내부 전용 액세스 VPC 엔드포인트로 두면, 인터넷에 있는 SFTP 클라이언트(신뢰할 수 있는 IP)가 접속할 수 없습니다. 문제는 “인터넷의 신뢰할 수 있는 IP에서 접속”이므로, 인터넷 접근이 가능한 엔드포인트(B) 가 맞고 D는 오답입니다.
Answer: D
요구사항
ML 모델을 독립 마이크로서비스로 구현: 시작 시 S3에서 약 1GB 모델 데이터를 읽어 메모리에 로드
비동기 API: 사용자가 요청 또는 요청 배치 전송, 결과를 보낼 위치 지정
수백 명에게 모델 제공
불규칙한 사용: 어떤 모델은 며칠·몇 주 미사용, 어떤 모델은 한 번에 수천 개 요청 배치 수신
위를 만족하는 설계 선택
D. SQS로 요청 수신 + SQS에서 읽는 ECS 서비스로 모델 배포 + 대기열 크기 기반 ECS·클러스터 Auto Scaling
API 요청을 Amazon SQS 대기열로 보내고, 그 대기열에서 메시지를 읽는 Amazon ECS 서비스로 모델을 배포한 뒤, 대기열 크기(메시지 수)에 따라 ECS 서비스의 복제본 수(태스크 수)와 클러스터 용량을 Auto Scaling으로 조정하는 구성입니다.
1GB 모델·메모리: ECS 태스크(컨테이너)는 시작 시 한 번 S3에서 모델을 내려받아 메모리에 유지할 수 있습니다. Lambda는 콜드 스타트마다 1GB를 다시 로드해야 해서 지연이 크고, 1GB 수준에는 ECS(컨테이너) 가 적합합니다.
불규칙 사용: 대기열이 비면 서비스 desired count를 줄여(또는 0으로) 비용을 줄이고, 요청 배치가 쌓이면 대기열 크기에 따라 태스크 수와 클러스터 용량을 늘려 처리할 수 있어 “며칠 미사용”과 “한 번에 수천 요청” 모두에 맞습니다.
비동기 API: 사용자가 요청을 API에 보내면 SQS에 메시지로 넣고, ECS 서비스가 SQS에서 메시지를 소비해 모델로 처리한 뒤, 사용자가 지정한 위치로 결과를 보내는 흐름으로 비동기 요구를 충족합니다.
Auto Scaling: “대기열 크기에 따라 서비스의 클러스터와 복사본 모두에 대해 ECS에서 Auto Scaling 활성화”는, Application Auto Scaling으로 SQS 대기열 깊이를 메트릭으로 해 ECS 서비스 desired count와 필요 시 클러스터 노드 수를 조정하는 구성을 의미합니다. D가 이에 해당합니다.
A. NLB는 Lambda를 대상(target) 으로 지정할 수 없습니다. NLB 대상은 EC2, IP, ALB 등이므로, “NLB에서 Lambda로 모델 배포”라는 구성은 지원되지 않습니다.
B. App Mesh는 서비스 메시(트래픽 제어·가시성) 용도이며, SQS 대기열 크기에 따라 ECS를 스케일링하는 기능은 Application Auto Scaling + SQS 메트릭으로 구현합니다. “App Mesh로 SQS 크기에 따라 ECS 스케일”이라는 설명은 잘못되었고, B는 부적절합니다.
C. Lambda로 1GB 모델을 매 콜드 스타트마다 S3에서 로드하면 시작 지연이 매우 커지고, 불규칙 사용 시 콜드 스타트가 자주 발생해 사용자 경험이 나빠집니다. Lambda는 “vCPU 수를 Auto Scaling”하는 대상이 아니며, 동시 실행 수만 자동으로 늘어납니다. 1GB 모델·불규칙 트래픽에는 ECS + SQS + 큐 기반 스케일링(D) 이 적합합니다.
요약
Answer: A, B
요구사항
자격 증명 기반 정책(Identity-based policy) 으로 SSM 관련 권한을 부여하는 JSON 정책
이 정책을 붙일 수 있는 IAM 보안 주체 2개 선택
A. 역할(Role)
IAM 역할에는 자격 증명 기반 정책을 연결할 수 있습니다. 역할은 IAM 주체(identity)이고, 인라인 정책이나 관리형 정책을 역할에 붙여 해당 역할을 쓰는 주체에게 권한을 줄 수 있습니다.
B. 그룹(Group)
IAM 그룹에도 자격 증명 기반 정책을 연결할 수 있습니다. 그룹은 IAM 주체이며, 그룹에 붙인 정책은 그 그룹에 속한 IAM 사용자에게 적용됩니다.
정리: “자격 증명 기반 정책”은 IAM identity(사용자, 그룹, 역할) 에 붙이는 정책이므로, 보기 중에서는 역할(A) 과 그룹(B) 에만 이 정책을 붙일 수 있습니다.
ssm:ListDocuments – 계정에 있는 SSM 문서 목록 조회
ssm:GetDocument – 특정 SSM 문서 내용 조회
Answer: B
요구사항
프런트엔드 노드: 24시간·주 7일 항상 실행(항상 켜 둠)
백엔드 노드: 워크로드에 따라 짧은 시간만 실행, 하루 동안 개수 변동
워크로드에 따라 인스턴스 확장·축소 필요
가장 비용 효율적인 구성 선택
B. 프런트엔드 = 예약 인스턴스, 백엔드 = 스팟 인스턴스
프런트엔드 노드에는 예약 인스턴스(Reserved Instances) 를 쓰고, 백엔드 노드에는 스팟 인스턴스(Spot Instances) 를 쓰는 구성입니다.
프런트엔드(24/7): 항상 켜 두는 워크로드라 용량이 예측 가능합니다. 예약 인스턴스로 1년/3년 약정을 걸면 온디맨드 대비 할인이 커서, 같은 24/7 부하에 대해 가장 비용 효율적입니다.
백엔드(변동·짧은 실행): 하루 동안 개수가 들쭉날쭉하고 짧은 시간만 돌아가는 워크로드입니다. 스팟 인스턴스는 온디맨드 대비 최대 약 90% 할인이 가능하고, Auto Scaling으로 필요할 때만 늘렸다 줄일 수 있어 변동·단기 워크로드에 비용 효율적입니다. 중단되면 Auto Scaling이 다른 스팟/온디맨드로 대체할 수 있어, 백엔드처럼 단기·재시도 가능한 워크로드에 적합합니다.
조합: 프런트엔드는 예약으로 고정 비용 절감, 백엔드는 스팟 + 스케일 인/아웃으로 사용량만큼만 지불하는 구성이 가장 비용 효율적입니다.
A. 프런트엔드에 예약은 맞지만, 백엔드에 Fargate를 쓰면 사용한 만큼만 내는 장점은 있으나, 동일 컴퓨트 기준으로는 스팟 인스턴스가 보통 더 저렴합니다. “가장 비용 효율적”에는 B(백엔드 스팟) 가 더 적합합니다.
C. 프런트엔드에 스팟을 쓰면, 스팟 중단 시 프런트엔드가 내려갈 수 있어 “24시간·주 7일 실행” 요구를 안정적으로 만족하기 어렵습니다. 백엔드에 예약을 쓰면 변동 워크로드에 맞지 않고 비용도 비효율적입니다.
D. 프런트엔드에 스팟을 쓰는 것은 C와 같은 이유로 부적절합니다. “24/7 필수”에는 예약 또는 온디맨드가 맞습니다.
Answer: C
요구사항
온프레미스에서 높은 블록 스토리지 용량 사용 중
일일 최대·초당 IOPS가 15,000 IOPS를 넘지 않음
EC2로 마이그레이션 예정
스토리지 용량과 무관하게 디스크 성능(IOPS 등) 을 따로 프로비저닝하고 싶음
위를 만족하는 가장 비용 효율적인 EBS 볼륨 유형 선택
C. gp3 볼륨 유형
Amazon EBS gp3(범용 SSD 3세대) 는 용량(GB)과 관계없이 IOPS와 처리량(MB/s) 을 별도로 지정할 수 있는 볼륨 유형입니다.
성능을 용량과 분리: gp3는 기본 3,000 IOPS, 125 MB/s이고, 최대 16,000 IOPS, 1,000 MB/s까지 볼륨 크기와 상관없이 설정할 수 있습니다. 15,000 IOPS가 16,000 이하이므로 요구 IOPS를 충족하면서, “스토리지 용량과 독립적으로 디스크 성능 프로비저닝” 요구도 만족합니다.
비용 효율: 동일 IOPS 기준으로 gp3가 io1/io2보다 저렴합니다. 15,000 IOPS만 필요하고 최저 지연·특수 내구성 요구가 없다면 gp3가 가장 비용 효율적입니다.
범용·비용 효율: gp3 → 성능을 용량과 분리해 설정 가능, 15,000 IOPS 이하면 gp3가 보통 가장 저렴.
범용·레거시: gp2 → 성능이 용량에 묶여 있음. GB당 3 IOPS, 최대 3,000 IOPS까지
고성능·보장 IOPS: io1 (레거시), io2 (권장) → 용량과 무관하게 IOPS 지정, 비용은 더 높음.
“용량과 독립적으로 디스크 성능을 프로비저닝 + 비용 효율”이 목표면 gp3(C) 가 적합합니다.
Answer: A
요구사항
의료 애플리케이션 데이터 저장
데이터 자주 변경
새 규정: 저장된 데이터의 모든 수준에서 감사 액세스(audit access) 필요
온프레미스 스토리지 용량 부족 → AWS로 이전 필요
기존 데이터를 안전하게 AWS로 마이그레이션하면서 새 규정 충족
A. AWS DataSync로 S3 이전 + CloudTrail 데이터 이벤트 기록
AWS DataSync로 온프레미스 기존 데이터를 Amazon S3로 옮기고, AWS CloudTrail에서 데이터 이벤트(Data events) 를 활성화해 기록하는 구성입니다.
안전한 마이그레이션: DataSync는 온프레미스(NFS, SMB) → S3 전송에 맞춰져 있고, 전송 중 암호화, 검증을 지원해 기존 데이터를 안전하게 AWS로 옮기기에 적합합니다.
저장된 데이터의 모든 수준에서 감사: 규정이 요구하는 “저장된 데이터에 대한 감사 액세스”는 객체(데이터) 단위 접근 이력이 필요합니다. CloudTrail 데이터 이벤트를 켜면 S3에 대한 GetObject, PutObject, DeleteObject 등 데이터 접근·변경이 모두 로그에 남아, “저장된 데이터의 모든 수준”에서 누가, 언제, 어떤 데이터에 접근했는지 감사할 수 있습니다.
자주 변경되는 데이터: 마이그레이션 후에도 S3 객체에 대한 읽기·쓰기·삭제는 데이터 이벤트로 계속 기록되므로, 자주 변경되는 의료 데이터에 대한 감사 요구를 충족합니다.
Answer: B
요구사항
MySQL 기반 복잡한 Java 애플리케이션
Apache Tomcat에 배포해야 함
고가용성(HA) 필요
위를 만족하는 설계 선택
B. AWS Elastic Beanstalk + 부하 분산 환경 + 롤링 배포
AWS Elastic Beanstalk으로 애플리케이션을 배포하고, 부하 분산 환경(여러 인스턴스 + ELB)과 롤링 배포 정책을 구성하는 방식입니다.
Tomcat 배포: Elastic Beanstalk은 Java + Tomcat 플랫폼을 지원합니다. WAR나 소스 코드를 배포하면 Beanstalk이 Tomcat 환경을 구성해 주므로, “Tomcat에 배포” 요구를 충족합니다.
고가용성: 부하 분산 환경을 선택하면 여러 EC2 인스턴스가 ELB(ALB) 뒤에 배치되고, 다중 AZ로 분산할 수 있어 단일 인스턴스/단일 AZ 장애에 대비한 고가용성을 만족합니다.
롤링 배포: 롤링 배포 정책을 사용하면 새 버전을 한 번에 전부 끊지 않고 순차적으로 배포할 수 있어, 가용성을 유지하면서 배포할 수 있습니다.
관리형: Beanstalk이 인스턴스·로드밸런서·플랫폼을 관리해 주므로, “Tomcat + 고가용성”을 운영 부담을 줄이면서 구현할 수 있습니다.
Answer: B
요구사항
API Gateway, Lambda, DynamoDB를 쓰는 서버리스 앱
Lambda가 DynamoDB 테이블을 읽고 쓸 수 있어야 함
그 접근을 가장 안전하게 제공할 방법 선택
B. Lambd를 신뢰할 수 있는 서비스로 포함하는 IAM 역할 생성
Lambda에 권한을 주는 권장·표준 방식은 IAM 실행 역할(Execution Role) 이다.
Lambda를 신뢰 주체(Principal) 로 하는 IAM 역할을 만들고, 그 역할에 DynamoDB 읽기/쓰기 정책을 붙인 뒤, Lambda 함수 설정에서 이 역할을 실행 역할로 지정하면 된다.
Lambda가 실행될 때 이 역할을 Assume 해서 임시 자격 증명을 받기 때문에, access key/secret key를 코드나 환경 변수에 넣을 필요가 없어 가장 안전하다.
A. IAM 사용자의 access_key_id, secret_access_key를 Lambda 환경 변수에 넣는 방식이다. 장기 자격 증명이 노출·유출되기 쉬우며, “가장 안전하게”라는 조건에 맞지 않는다.
C. 자격 증명을 Parameter Store 보안 문자열로 두고 Lambda에서 조회하는 방식이다. A보다는 나으나, 여전히 IAM 사용자 장기 자격 증명을 쓰는 비권장 패턴이다. Lambda는 실행 역할로 임시 자격 증명을 쓰는 것이 더 안전하다.
D. 역할의 신뢰 정책(Trust Policy) 에 “DynamoDB를 신뢰할 수 있는 서비스”로 넣는다고 되어 있다. Lambda가 역할을 맡으려면 신뢰 주체는 Lambda 서비스(lambda.amazonaws.com) 여야 하고, DynamoDB는 역할을 Assume 하는 주체가 아니라 Lambda가 접근할 리소스이므로 잘못된 설명이다.
Answer: D
요구사항
IAM 그룹에 연결된 정책 하나만 적용됨
Statement 1: Allow, resource *, Condition ec2:region = us-east-1 (첫 번째 문에 Action이 없지만, 일반적으로 us-east-1에서 EC2 권한 허용으로 해석)
Statement 2: Deny ec2:StopInstances, ec2:TerminateInstances, Condition BoolIfExists: aws:MultifactorAuthPresent = false
그룹 구성원에게 실제로 적용되는 권한이 무엇인지 선택
Statement 1: us-east-1 리전에 대해서만 허용(조건 ec2:region = us-east-1). 따라서 us-east-1에서만 EC2 작업이 허용되고, 다른 리전은 허용되지 않음.
Statement 2: MFA가 없을 때(aws:MultifactorAuthPresent = false) ec2:StopInstances, ec2:TerminateInstances를 명시적 Deny. Deny가 Allow보다 우선하므로, Stop/Terminate는 “MFA가 있을 때만” 허용됨.
결과: us-east-1에서 “그 외 EC2 작업”은 항상 허용, StopInstances / TerminateInstances만 MFA 로그인한 경우에만 허용 → D 설명과 일치.
Answer: B, C
요구사항
기계 센서가 S3에 .csv 업로드 → 이미지로 변환 후 그래픽 보고서용으로 가능한 한 빨리 사용
이미지는 1개월 지나면 불필요 → 삭제 가능
.csv는 1년에 두 번 ML 학습·감사용으로 보관, 몇 주 전에 계획된 접근
위를 가장 비용 효율적으로 만족하는 단계 2개 선택
B. Lambda 함수 설계, 파일이 업로드되면 Lambda 함수 호출
.csv 업로드 시 Lambda가 바로 호출되어 이미지로 변환 후 S3에 저장 → 이벤트 기반이라 가능한 한 빨리 처리됨
서버리스라 EC2 상시 운영 없이, 호출당 과금으로 비용 효율적
스팟/온디맨드 EC2로 매시간 배치하는 것보다 운영 부담 적고, 처리 지연도 적음
C. S3 수명주기 규칙 생성 1일 후 S3 Glacier로 전환, 30일 후 만료
.csv: 1일 후 S3 Standard → S3 Glacier 전환 → ML은 1년에 두 번, 미리 계획되므로 Glacier 저렴한 보관 + 필요 시 복구가 적합함
이미지: 30일 후 만료(삭제) → “1개월 지나면 관련 없음” 요구사항과 일치
Glacier는 장기·저접근 보관에 Standard-IA·One Zone-IA보다 저렴해 비용 효율적
틀린 이유
A. 매시간 EC2 스팟으로 다운로드·변환·업로드하는 방식은 즉시 처리가 아니라 최대 1시간 지연이 있고, 스팟 중단·관리 부담이 있으며, 이벤트 기반 Lambda보다 비용·운영 측면에서 불리함.
D. .csv를 S3 One Zone-IA로 전환하는 것은 Glacier보다 단가가 높고, 1년에 두 번만 쓰는 보관에는 Glacier가 더 비용 효율적임. 30일 후 이미지 만료는 C와 같지만, .csv 저장 비용 측면에서 C가 더 적합함.
E. .csv를 S3 Standard-IA로 전환하는 것은 Glacier보다 비쌈. RRS(Reduced Redundancy Storage) 는 구식/비권장이며, 이미지를 “보관”한다고 한 것은 “30일 후 만료” 요구와 맞지 않고, 비용 효율성도 B+C 조합보다 떨어짐.
Answer: B
요구사항
VPC 3계층 아키텍처, 데이터베이스는 MySQL용 Amazon RDS
여러 플레이어가 동시에 온라인으로 경쟁
거의 실시간으로 상위 10개 점수판 표시
현재 점수 유지 + 게임 중지/복원 기능
B. Redis용 Amazon ElastiCache 설정, 웹 앱이 표시할 점수를 계산·캐시
Redis는 Sorted Set(ZADD, ZRANGE) 으로 리더보드(상위 N명) 구현에 적합하고, 메모리 기반이라 지연이 적어 거의 실시간 요구에 맞음.
ElastiCache for Redis는 점수 갱신·조회를 빠르게 처리하고, 웹 앱이 여기서 계산·캐시한 결과를 바로 표시할 수 있음.
RDS는 장기 저장용으로 두고, 실시간 점수/리더보드는 Redis가 담당하는 구성이 적절함.
틀린 이유
A. Memcached는 단순 키-값 캐시라 Sorted Set 같은 구조가 없어, “상위 10명”을 효율적으로 유지·조회하기 어렵고, 리더보드용으로는 Redis가 적합함.
C. CloudFront는 엣지 캐시로, 자주 바뀌는 점수판을 캐시하면 실시간이 아니라 오래된 데이터가 보일 수 있어 “거의 실시간” 요구와 맞지 않음.
D. RDS 읽기 전용 복제본은 읽기 부하 분산에는 유리하지만, 매 요청마다 DB 쿼리로 상위 10명을 계산하면 지연이 커져 거의 실시간에는 Redis 같은 인메모리 캐시보다 불리함.
Answer: B
요구사항
ML 알고리즘으로 모델 구축·훈련
복잡한 시나리오 시각화, 고객 데이터 추세 감지
ML 모델을 플랫폼과 연동해 증강 데이터 분석, BI 대시보드에서 직접 사용
최소한의 운영 오버헤드로 위 요구 충족
B. Amazon SageMaker로 모델 구축·훈련, Amazon QuickSight로 시각화
SageMaker는 관리형 ML 서비스로, 모델 구축·훈련·배포를 인프라 관리 없이 할 수 있어 “모델 구축·훈련”과 “최소 운영 오버헤드”에 맞음.
QuickSight는 관리형 BI 서비스로, 대시보드·시각화와 다양한 데이터 소스 연동을 지원해 “비즈니스 인텔리전스 대시보드에서 직접 데이터 사용” 및 “시각화·추세 감지”에 적합함.
SageMaker로 만든 모델/결과를 플랫폼·데이터 파이프라인과 연동하고, QuickSight에서 해당 데이터를 사용하는 구성이 요구사항을 충족함.
틀린 이유
A. AWS Glue는 ETL·데이터 준비용이며, “ML 변환”은 특정 용도(예: FindMatches)에 가깝고 일반적인 ML 모델 구축·훈련 플랫폼이 아님. OpenSearch는 검색·분석용이라, BI 대시보드·시각화에는 QuickSight가 더 적합함.
C. Marketplace ML AMI는 EC2 위에서 직접 운영해야 해서 인스턴스·패치·스케일링 등 운영 부담이 커지며, “최소한의 운영 오버헤드” 조건과 맞지 않음.
D. QuickSight의 “계산된 필드”는 대시보드용 단순 연산이지, ML 모델을 구축·훈련하는 기능이 아님. 모델 구축·훈련 요구는 SageMaker 등 ML 전용 서비스로 충족해야 함.
Answer: C
요구사항
AWS Organizations로 묶인 여러 AWS 계정에서 프로덕션/비프로덕션 워크로드 운영
비용 사용 태그(비용 할당 태그) 수정을 막는 솔루션 필요
C. 서비스 제어 정책(SCP) 생성, 인증된 주체만 태그 수정 가능하도록 제한
SCP는 조직/OU에 연결된 모든 계정에 적용되는 권한 상한을 정하는 정책으로, “여러 계정”에서 일관되게 태그 수정을 제한할 수 있음.
SCP로 tag:TagResources, tag:UntagResources 등 태그 수정 관련 API를 거부(Deny) 하면, 해당 조직/OU 내에서는 태그 수정이 실행 단계에서 차단됨(방지).
특정 IAM 주체만 태그 수정이 필요하다면, SCP로 전반적으로 막고 해당 주체에게만 IAM으로 태그 권한을 부여하는 방식으로 “인증된 주체 외에는 수정 방지”를 구현할 수 있음.
A. AWS Config 사용자 지정 규칙은 설정 상태를 평가·감지하는 용도라, 태그가 바뀐 뒤에 비준수로 판단할 수 있을 뿐 API 호출 자체를 막지 못함. “수정 방지”가 아니라 “수정 감지”에 가깝다.
B. CloudTrail 사용자 지정 추적은 API 호출을 기록하는 기능만 제공하며, 어떤 동작도 차단하지 않음. 방지 요구와 무관하다.
D. CloudWatch 로그는 로그 저장만 하며, 권한 정책이 아니어서 태그 수정을 방지할 수 없다.
Answer: A
요구사항
ELB 뒤의 Auto Scaling 그룹 + EC2에서 앱 실행, Amazon DynamoDB 사용
다른 AWS 리전에서도 앱을 사용할 수 있어야 함
가동 중지 시간을 최소화하면서 위를 만족할 방법 선택
A. 재해 복구 리전에 ASG·로드 밸런서 생성, DynamoDB 전역 테이블, DNS 장애 조치 구성
DynamoDB 전역 테이블로 두 리전에 데이터가 계속 복제되므로, 장애 시 DR 리전으로 전환해도 데이터 복구/이전 없이 바로 읽기·쓰기 가능해 다운타임이 짧아짐.
재해 복구 리전에 미리 ASG와 로드 밸런서를 두고, DNS 장애 조치(예: Route 53 장애 조치 라우팅 + 상태 확인)로 주 리전 장애 시 DR 리전 ELB로 트래픽이 넘어가게 하면, 인프라가 이미 준비된 상태에서 전환할 수 있음.
“다른 리전에서 사용 가능” + “다운타임 최소화”를 동시에 만족하는 일반적인 멀티 리전 DR 패턴에 맞는 구성임.
틀린 이유
B. DR 리전의 DynamoDB를 “필요할 때 생성”하면, 장애 시점에 빈 테이블만 생기고 데이터는 없음. 데이터 복구·이전에 시간이 걸려 다운타임 최소화 요구를 충족하지 못함. 전역 테이블로 사전 복제가 필요함.
C. EC2·로드 밸런서를 “필요할 때” CloudFormation으로만 띄우면, 장애 발생 후 스택 실행·인스턴스 기동까지 지연이 생김. DR 리전에 미리 ASG·로드 밸런서를 두는 A보다 다운타임이 길어질 수 있음.
D. CloudWatch 알람 → Lambda → Route 53 업데이트 방식은 알람 평가·Lambda 실행·레코드 변경까지 추가 지연이 있고, 구성도 복잡함. Route 53 장애 조치 라우팅(상태 확인 기반 자동 전환)만으로 처리하는 A가 더 단순하고 전환도 빠름.
Answer: A
요구사항
2주 이내 온프레미스 → AWS 마이그레이션
MySQL 데이터베이스 20TB
다운타임 최소화
가장 비용 효율적인 DB 마이그레이션 방법 선택
A. Snowball Edge Storage Optimized 주문, SCT·DMS로 진행 중 복제 후 Snowball 반송으로 마이그레이션 완료
Snowball Edge Storage Optimized는 대용량 데이터 이전용(약 80TB 사용 가능)이라 20TB에 적합하고, 2주 일정에 맞춰 초기 대량 로드 → 디바이스 반송 → AWS에서 적재 후 DMS 전환으로 마이그레이션을 끝낼 수 있음.
DMS로 원본 DB 변경 사항을 지속 복제하면, Snowball으로 초기 데이터를 옮긴 뒤에도 변경분만 동기화해 다운타임을 짧게 가져갈 수 있음.
20TB 수준의 1회성 대량 이전에는 전용선 설치·월 비용이 드는 Direct Connect보다 Snowball 일회 비용이 비용 효율적인 경우가 많음.
틀린 이유
B. Snowmobile은 수십 PB 이상 규모용이다. 20TB에는 과한 선택이고, 비용·운영 측면에서 20TB 마이그레이션에는 비용 효율적이지 않음.
C. Snowball Edge Compute Optimized는 엣지에서의 연산·GPU용이며, 대용량 스토리지 이전에는 Storage Optimized가 맞다. 20TB DB 마이그레이션에는 A의 Storage Optimized가 적합함.
D. 1Gbps Direct Connect는 물리 회선·크로스커넥트로 보통 수 주~수 개월 걸려, “2주 이내 마이그레이션” 전제를 맞추기 어렵다. 1회성 20TB 이전만을 위해 전용선을 쓰는 것은 Snowball 대비 비용 효율이 떨어지는 경우가 많음.
Answer: A
요구사항
온프레미스 PostgreSQL → Amazon RDS for PostgreSQL 마이그레이션 완료
신제품 출시로 DB 워크로드 증가
인프라를 추가하지 않고 더 큰 워크로드를 수용
가장 비용 효율적인 방법 선택
A. 전체 워크로드에 예약 DB 인스턴스 구매, RDS for PostgreSQL 인스턴스를 더 크게 구성
“인프라를 추가하지 않고”는 인스턴스 개수를 늘리지 않고 처리 용량을 키우는 것을 의미하므로, 같은 DB 인스턴스를 더 큰 사양(vertical scaling) 으로 올리는 방식이 맞음.
예약 인스턴스(Reserved) 를 쓰면 온디맨드 대비 할인으로, 같은/더 큰 사양을 가장 비용 효율적으로 운영할 수 있음.
따라서 “더 큰 워크로드 수용” + “인프라 추가 없음” + “비용 효율”을 동시에 만족하는 답은 A임.
틀린 이유
B. 다중 AZ는 고가용성(HA) 용이지, 읽기/쓰기 용량 확장이 아님. 스탠바이 복제본이 추가되므로 “인프라를 추가하지 않고”라는 조건에도 맞지 않음.
C. 마이그레이션은 이미 끝난 상태이고, Snowball·DMS는 이전 단계용이라 현재 요구사항과 무관함. 워크로드 증가 대응·비용 효율과도 맞지 않음.
D. 온디맨드 DB 인스턴스로만 구성하면 예약 인스턴스보다 단가가 높아 “가장 비용 효율적으로” 충족하지 못함. 지속적인 프로덕션 워크로드에는 예약(A)이 더 저렴함.
Answer: B
요구사항
ALB 뒤 Auto Scaling 그룹의 EC2에서 전자상거래 웹사이트 운영
IP가 자주 바뀌는 불법 외부 시스템의 높은 요청 비율로 성능 문제 발생
DDoS 가능성에 대한 우려
불법 요청만 차단하고 합법 사용자 영향은 최소화
B. AWS WAF를 ALB에 연결하고 속도 기반 규칙 구성
속도 기반 규칙(Rate-based rule) 으로 IP별(또는 전달된 IP별) 일정 시간당 요청 수를 제한하면, 과도한 요청 비율을 보이는 소스를 차단할 수 있음.
정상 사용자는 보통 임계값에 도달하지 않으므로 합법 사용자 영향이 적고, 불법·봇·DDoS 성격의 트래픽만 제한됨.
ALB(애플리케이션 계층)에 WAF를 연결해 HTTP 요청 단위로 제어하는 구성이 “불법 요청 차단 + 합법 사용자 최소 영향”에 맞음.
틀린 이유
A. Amazon Inspector는 취약점 스캔용이라, 들어오는 트래픽을 차단하거나 속도 제한하지 않음. 요청 차단·DDoS 완화 요구와 맞지 않음.
C. NACL은 IP·포트 기준 허용/거부만 가능하고 요청 속도(rate) 제한은 할 수 없음. 특정 IP 대역을 막으면 그 대역의 합법 사용자까지 차단되어 “합법 사용자 최소 영향”을 만족하기 어렵음.
D. GuardDuty는 위협 탐지 서비스이며, 요청 경로에서 트래픽을 차단하지 않음. GuardDuty 설정에 “속도 제한 보호 활성화” 같은 옵션도 없고, 속도 제한·차단은 WAF 등에서 해야 함.
Answer: D
요구사항
외부 감사인과 회계 데이터 공유
데이터는 프라이빗 서브넷의 Amazon RDS DB 인스턴스에 저장
감사인은 자체 AWS 계정 보유, 자체 DB 사본 필요
가장 안전한 공유 방법 선택
D. 암호화된 DB 스냅샷 생성 후 감사인 계정과 공유, KMS 키 접근 허용
RDS 스냅샷을 다른 AWS 계정과 공유하면 감사인은 자기 계정에서 복원해 자체 DB 인스턴스를 갖게 되므로, 회사 RDS에 대한 지속적 접근이 필요 없음.
암호화된 스냅샷으로 전송·보관 중 데이터가 보호되고, 감사인 계정에 KMS 키 사용 권한만 부여하면 복호화·복원 가능해, 자격 증명(액세스 키 등)을 공유할 필요가 없음.
“자체 계정 + 자체 DB 사본” + “암호화 + 크로스 계정 공유” 조합이 가장 안전한 방식에 해당함.
틀린 이유
A. 읽기 전용 복제본은 회사 계정의 RDS에 남고, 감사인이 접근하려면 회사 VPC/DB에 대한 네트워크·DB 접근이 필요함. “자체 데이터베이스 사본”이 아니라 회사 인프라에 대한 접근이 되고, 경계가 분리되지 않아 가장 안전한 방법이라고 보기 어렵다.
B. 텍스트로 내보내면 데이터 형태·처리 과정에서 노출 위험이 있고, 회사 계정의 S3에 두고 IAM 사용자로 접근하게 하면 감사인 자체 계정이 아닌 회사 계정 안에서 권한을 주는 구조라, D보다 보안·경계 측면에서 불리하다.
C. “사용자의 키를 감사자와 공유”는 IAM 액세스 키 공유를 의미하며, 장기 자격 증명 유출·재사용 위험이 있어 가장 안전한 방법이 아니다. D는 스냅샷 공유와 KMS 권한만으로 처리해 자격 증명 공유가 필요 없다.
Answer: A
요구사항
IP 주소 범위가 작은 VPC로 구성됨
VPC 내 EC2 수 증가로 IP 주소 부족, 향후 워크로드 대비 필요
최소한의 운영 오버헤드로 해결할 방법 선택
A. 추가 IPv4 CIDR 블록을 VPC에 연결하고, 새 CIDR로 서브넷을 만들어 리소스 배치
VPC는 보조 IPv4 CIDR를 추가할 수 있어(최대 5개), 같은 VPC 안에서 IP 공간만 늘리면 됨.
새 CIDR로 추가 서브넷만 만들고, 새 리소스를 그 서브넷에 두면 되므로 새 VPC·피어링·Transit Gateway·VPN 없이 처리 가능함.
“IP 부족”을 VPC 확장으로 해결하고, 구성 변경이 적어 최소한의 운영 오버헤드로 맞는 방법임.
틀린 이유
B. 두 번째 VPC를 만들고 피어링하면, VPC 2개 관리·피어링 연결·양쪽 라우팅 등 운영 부담이 커짐. 같은 목적이면 기존 VPC에 CIDR 추가(A)가 더 단순함.
C. Transit Gateway는 여러 VPC·온프레미스 연결용 허브이고, “VPC IP 부족”만 해결하려면 과한 구성이라 TGW·첨부·라우팅 관리 등 운영 오버헤드가 큼.
D. 두 번째 VPC + 사이트 간 VPN은 VPC 간 연결용으로도 복잡하고, IP 부족 해결만 보면 가장 복잡한 방식이라 운영 오버헤드가 가장 큼. VPN은 보통 온프레미스–VPC 연결용임.
Answer: A, C
요구사항
테스트용 RDS for MySQL 사용, 테스트 종료 전 백업 2종 생성
1차: mysqldump로 DB 덤프
2차: RDS 종료 시 최종 DB 스냅샷 생성
새 테스트를 위해 가장 최근 백업에서 새 DB 인스턴스를 만들어야 함
대상은 Amazon Aurora MySQL 호환 에디션
위를 만족하는 새 DB 인스턴스 생성 방법 2개 선택
A. RDS 스냅샷을 Aurora로 직접 복원
RDS for MySQL 스냅샷은 Aurora MySQL로 직접 복원할 수 있음(같은 MySQL 호환 엔진).
두 번째 백업(최종 DB 스냅샷)을 선택한 뒤, 콘솔/CLI에서 “Aurora로 복원”하면 새 Aurora 클러스터가 생성됨.
스냅샷을 S3에 올릴 필요 없이, RDS 스냅샷 → Aurora 복원 한 단계로 새 DB 인스턴스(클러스터) 생성 가능.
C. DB 덤프를 S3에 올린 뒤 Aurora로 가져오기
첫 번째 백업(mysqldump 덤프)을 쓰려면, 덤프 파일을 S3에 업로드한 다음 Aurora에 임포트하면 됨(mysql 클라이언트, Aurora의 S3 로드 등).
덤프 → S3 → Aurora 임포트 흐름으로 새 Aurora 인스턴스(클러스터) 에 데이터를 채워 새 DB를 만드는 방식이 됨.
틀린 이유
B. RDS 스냅샷은 “사용자가 S3에 업로드”하는 객체가 아님. 스냅샷은 RDS가 관리하며, 스냅샷 → Aurora 복원은 A처럼 직접 복원으로 처리함. “스냅샷을 S3에 업로드한 뒤 Aurora로 가져온다”는 단계는 필요 없고, 오히려 잘못된 절차임.
D. DMS는 실행 중인 DB를 소스로 한 연속 복제/마이그레이션용이라, 스냅샷 파일을 DMS로 Aurora에 가져오는 용도가 아님. 스냅샷으로 새 인스턴스를 만드는 올바른 방법은 A(스냅샷 → Aurora 직접 복원)임.
E. mysqldump 덤프(.sql)를 Aurora에 넣는 일반적인 방법은 S3 업로드 후 mysql/Aurora 임포트(C) 이지, DMS로 덤프를 가져오는 표준 방식이 아님. DMS는 주로 라이브 DB나 특정 파일 포맷(Parquet 등) 풀 로드에 쓰임.
Answer: C
요구사항
ALB 뒤 Auto Scaling 그룹의 Amazon Linux EC2에서 다중 계층 웹 앱 호스팅
정적 웹 콘텐츠에 대한 접근이 많을 때 ASG가 온디맨드 인스턴스를 더 띄움 → 비용 증가
비용 최적화를 위해 가장 비용 효율적으로 재설계할 방법 선택
C. 정적 웹 콘텐츠를 S3에 두고 CloudFront 배포로 제공
비용 증가 원인은 정적 콘텐츠(이미지, CSS, JS 등) 를 EC2가 처리해 트래픽이 늘고 ASG가 계속 스케일 아웃하는 것임.
정적 콘텐츠를 S3 + CloudFront 로 옮기면, 해당 트래픽이 EC2로 가지 않아 인스턴스 수·스케일 아웃이 줄고, 정적 제공은 S3·CloudFront 비용으로 처리해 전체 비용이 더 낮아짐.
“재설계” 요구에 맞게 아키텍처를 바꿔 정적/동적을 분리하고, 정적은 CDN+오브젝트 스토리지로 처리하는 것이 가장 비용 효율적인 방법임.
틀린 이유
A. 예약 인스턴스는 인스턴스당 단가만 낮출 뿐, 정적 트래픽이 EC2를 타는 구조는 그대로라 인스턴스 수·스케일 아웃은 줄지 않음. “가장 비용 효율적인 재설계”가 아니라 단가 절감에 그침.
B. 스팟 인스턴스도 인스턴스당 비용만 줄어들고, 정적 콘텐츠가 EC2를 치는 한 스케일 아웃 자체는 그대로라 인스턴스 수가 줄지 않음. 정적을 EC2에서 빼는 C가 더 비용 효율적임.
D. Lambda로 정적 콘텐츠를 제공할 수는 있으나, 대량·고요청 정적 콘텐츠에는 요청·실행 시간 과금이 쌓여 S3 + CloudFront보다 비용이 훨씬 높음. 정적 호스팅의 표준·비용 효율은 C임.
Answer: D
요구사항
여러 AWS 계정에 몇 PB 규모 데이터 저장
AWS Lake Formation으로 데이터 레이크 관리
데이터 과학 팀이 엔지니어링 팀과 선택한 데이터를 안전하게 공유해 분석에 사용
최소한의 운영 오버헤드로 위를 만족할 방법 선택
D. Lake Formation 태그 기반 액세스 제어로 엔지니어링 팀 계정에 교차 계정 권한 부여
이미 Lake Formation을 쓰고 있으므로, Lake Formation의 교차 계정 공유를 쓰면 별도 서비스·데이터 복제 없이 운영 오버헤드를 최소화할 수 있음.
태그 기반 액세스 제어(TBAC) 로 “선택한 데이터”를 태그로 구분하고, 해당 태그에 대한 교차 계정 권한을 엔지니어링 팀 계정에 부여하면, 데이터 복사 없이 필요한 데이터만 안전하게 공유할 수 있음.
여러 계정에 흩어진 데이터를 한 곳(Lake Formation + 태그) 에서 정책으로 관리할 수 있어, 계정별로 반복 권한 부여하는 것보다 오버헤드가 적음.
틀린 이유
A. 필요한 데이터를 공통 계정으로 복사하면 몇 PB 규모의 이전·중복 저장·동기화가 필요해 비용·운영 부담이 매우 큼. “최소한의 운영 오버헤드”와 맞지 않음.
B. 데이터가 있는 계정마다 Lake Formation 권한 부여를 반복하면, 계정·사용자 수가 많을 때 관리 작업이 크게 늘어남. Lake Formation의 태그 기반 + 교차 계정(D)으로 한 번에 정책을 쓰는 편이 운영 오버헤드가 적음.
C. AWS Data Exchange는 데이터 제품 발행·구독용이라, 같은 회사 내 팀 간 선택 데이터 공유에는 Lake Formation 교차 계정 공유(D)가 더 적합하고, 이미 Lake Formation을 쓰는 경우 추가 서비스·워크플로 없이 D가 더 단순함.
Answer: A
요구사항
AWS에서 확장 가능한 웹 애플리케이션 호스팅
전 세계 여러 지역 사용자가 접근
사용자가 최대 기가바이트 크기의 고유한 데이터를 업로드·다운로드
업로드·다운로드 지연 최소화, 성능 최대화, 비용 효율이 목표
A. Amazon S3와 Transfer Acceleration으로 애플리케이션 호스팅
기가바이트 단위 고유 데이터 업로드·다운로드는 대용량 객체 저장·전송에 맞는 S3가 적합함.
S3 Transfer Acceleration은 CloudFront 엣지까지 먼저 전송한 뒤 최적 경로로 S3와 주고받아, 전 세계 사용자의 업로드·다운로드 지연을 줄여 “지연 최소화·성능 최대화”에 맞음.
S3는 자동 확장되고, Transfer Acceleration 비용은 전 세계에 EC2를 두는 것보다 비용 효율적임.
틀린 이유
B. CacheControl 헤더는 캐시 제어용이라, 사용자별 고유 데이터 업로드·다운로드에는 캐시 이득이 없고, 전송 가속도 되지 않아 “지연 최소화”를 달성하지 못함.
C. EC2 + CloudFront는 다운로드(캐시) 에는 유리할 수 있으나, 업로드는 주로 오리진(EC2)으로 가서 글로벌 사용자 기준 업로드 지연이 큼. GB급 양방향 업로드·다운로드를 전 세계에서 하려면 S3 + Transfer Acceleration(A)이 더 적합함.
D. ElastiCache는 캐시용이라 GB급 사용자별 대용량 객체 저장·전송에는 쓰이지 않음. EC2만으로는 글로벌 사용자의 업로드·다운로드 지연을 줄이기 어렵고, “지연 최소화”를 만족하지 못함.
Answer: B
요구사항
웹 서버 EC2 2대(수동 프로비저닝), RDS DB 1대
EC2는 단일 가용 영역에만 존재
직원이 DB 인스턴스를 삭제해 24시간 장애 발생
전반적인 안정성을 높이고, 인프라 안정성을 극대화할 방법 선택
B. RDS를 다중 AZ로 전환·삭제 방지 활성화, EC2는 ALB 뒤 Multi-AZ Auto Scaling 그룹으로 구성
RDS 삭제 방지를 켜면 실수로 DB를 지우는 것을 막아, “DB 삭제로 인한 24시간 장애” 같은 상황을 방지할 수 있음.
RDS 다중 AZ로 하면 한 AZ 장애 시 자동 장애 조치로 DB 가용성이 높아져 전체 안정성에 기여함.
ALB + 여러 AZ에 걸친 Auto Scaling 그룹으로 웹 서버를 두면, 한 AZ 장애 시에도 다른 AZ의 EC2가 트래픽을 받아 EC2 계층 안정성이 높아짐.
“DB 실수 삭제 방지 + DB·웹 계층 모두 고가용성”으로 안정성 극대화에 맞는 표준 구성임.
틀린 이유
A. EC2를 1대만 남기고 종료 방지만 켜는 구성은 단일 인스턴스가 되어, 해당 인스턴스나 AZ에 문제가 나면 전체 서비스가 중단됨. 안정성 극대화가 아니라 오히려 약해짐.
C. API Gateway·Lambda·DB 2대로 앱을 바꾸는 것은 아키텍처 전면 변경이고, “기존 앱 인프라의 안정성 극대화”를 위한 일반적인 방법이 아님. RDS 다중 AZ + 삭제 방지, EC2 Multi-AZ + ALB·ASG(B)가 더 단순하고 표준적임.
D. 스팟 인스턴스는 중단될 수 있어 가용성·안정성보다 비용 절감용임. “안정성 극대화”가 목표일 때 스팟으로 웹 서버를 구성하는 것은 맞지 않음.
Answer: A
요구사항
데이터 센터 대규모 NAS에 700TB 데이터 저장
10Gbps Direct Connect 하이브리드 환경
90일 이내 데이터를 클라우드로 이전
중단 없이 효율적으로 이전
이전 기간 동안에도 데이터 접근·업데이트 가능해야 함
A. 회사 데이터 센터에 DataSync 에이전트 생성, S3로 전송하는 데이터 전송 작업 생성 후 전송 시작
DataSync는 온프레미스(NAS 등) → S3로 지속·증분 동기화가 가능해, 이전이 진행되는 동안에도 NAS에서 접근·업데이트할 수 있고, 변경분만 다시 전송할 수 있음 → 중단 없이 이전 + 이전 중 접근·업데이트 요구 충족.
온프레미스에 DataSync 에이전트를 두어 NAS(NFS/SMB)를 소스로 지정하고, Direct Connect로 S3에 전송하는 작업을 만들면 700TB를 90일 일정에 맞춰 전송·동기화할 수 있음.
10Gbps Direct Connect가 있으므로 네트워크 이전이 가능하고, DataSync의 증분·압축·검증으로 효율적 이전이 가능함.
틀린 이유
B. Snowball으로 700TB를 옮기면 디바이스에 복사 → 물리 반송 → S3 적재까지 일괄 이전 구조라, 이전 기간 동안 NAS에서 계속 접근·업데이트한 내용을 지속적으로 클라우드에 반영하기 어렵다. “이전 기간 동안 접근·업데이트”를 만족하려면 DataSync 같은 지속 동기화(A)가 맞음.
C. DataSync로 Direct Connect 경유해 로컬 스토리지 → S3 복사는 개념적으로 A와 같지만, 온프레미스 → S3 전송을 하려면 반드시 DataSync 에이전트가 온프레미스에 있어야 함. C는 에이전트 생성 단계가 없어 필수 절차가 빠진 설명이라 A가 정답에 가깝다.
D. 테이프 백업 후 AWS로 반송하는 방식은 일회성 대량 이전에 가깝고, 이전 기간 동안 NAS에서 접근·업데이트한 내용을 계속 클라우드에 반영하는 지속 동기화가 아니다. “중단 없이” 및 “이전 기간 동안 접근·업데이트” 요구를 DataSync(A)만큼 잘 충족하지 못함.
Answer: D
요구사항
S3 버킷에 PDF로 데이터 저장
법적 요구: 신규·기존 데이터 모두 S3에 7년 보관
최소한의 운영 오버헤드로 위 요구 충족
D. S3 객체 잠금을 규정 준수 보존 모드로 활성화, 7년 만료 보존 기간 설정, S3 배치 작업으로 기존 데이터 규정 준수 적용
S3 Object Lock 규정 준수(compliance) 모드는 보존 기간 동안 어떤 사용자도(루트 포함) 객체 삭제·덮어쓰기 불가라 법적 보관(WORM) 에 적합함.
보존 기간을 7년 후 만료로 두면 “7년 보관” 요구를 만족함.
기존 객체는 Object Lock 활성화만으로는 보존이 적용되지 않으므로, S3 Batch Operations로 기존 객체에 보존을 일괄 적용하면 스크립트·수동 복사 없이 최소 운영 오버헤드로 기존 데이터까지 규정 준수할 수 있음.
틀린 이유
A. 버전 관리 + 수명 주기(7년 후 삭제) + MFA 삭제는 객체 잠금이 아니라 권한이 있는 사용자가 7년 이내에 삭제할 수 있어, 법적 불변 보관(WORM) 을 보장하지 못함. “기존 데이터”에 7년 보관을 적용하는 방법도 제시되지 않음.
B. 거버넌스(governance) 모드는 s3:BypassGovernanceRetention 권한으로 보존을 우회할 수 있어 법적 요구에는 규정 준수(compliance) 모드가 맞음. “모든 기존 개체를 다시 복사”는 수동/스크립트 작업으로 운영 오버헤드가 큼.
C. 규정 준수 모드 + 7년 보존은 맞지만, “모든 기존 개체를 다시 복사하여 준수”는 일괄 재복사에 의존해 운영 부담이 큼. D는 S3 Batch Operations로 기존 데이터를 규정 준수하도록 가져오므로 최소 운영 오버헤드 조건을 더 잘 충족함.
Answer: A
요구사항
API Gateway로 호출하는 Lambda에서 동작하는 상태 비저장 웹 앱
여러 AWS 리전에 배포해 지역 장애 조치 제공
여러 리전으로 트래픽 라우팅할 방법 선택
A. 리전별 Route 53 상태 확인 생성, 활성-활성 장애 조치 구성
여러 리전으로 트래픽을 나누고 장애 시 전환하려면 DNS 단에서 라우팅하는 Route 53이 적합함.
리전별 상태 확인으로 각 리전 엔드포인트(예: 리전별 API Gateway) 상태를 보고, 비정상 리전으로는 트래픽을 보내지 않도록 할 수 있음.
활성-활성 구성으로 지연 기반 라우팅·가중치 등으로 여러 리전에 동시에 트래픽을 보내고, 한 리전 장애 시 나머지 리전만 사용할 수 있음.
틀린 이유
B. CloudFront는 엣지 캐시·단일 배포의 오리진 그룹으로 리전 장애 조치를 할 수는 있으나, 여러 리전으로 트래픽 라우팅의 표준은 Route 53이다. API Gateway + Lambda처럼 리전별 엔드포인트가 있는 경우, DNS 단에서 리전별로 라우팅·장애 조치하는 A가 더 직접적임.
C. Transit Gateway는 VPC·온프레미스 간 네트워크(L3) 연결용이다. 사용자 트래픽을 여러 리전의 API Gateway로 라우팅하는 용도가 아니며, 퍼블릭 API Gateway 트래픽 라우팅에는 사용하지 않음.
D. ALB는 한 리전에만 두어지며, 대상 그룹에 다른 리전의 API Gateway를 대상으로 두는 구성은 지원되지 않는다. 여러 리전으로 트래픽을 나누는 것은 Route 53(DNS) 으로 해야 함.
Answer: C
요구사항
Management VPC: 데이터 센터 단일 디바이스 하나에 VPN(고객 게이트웨이)으로만 연결
Production VPC: 가상 프라이빗 게이트웨이 + Direct Connect 2개 (이미 이중화)
두 VPC는 VPC 피어링 1개로 애플리케이션 간 통신
이 아키텍처에서 단일 실패 지점(SPOF)을 완화할 방법 선택
C. 두 번째 고객 게이트웨이 디바이스에서 관리 VPC로 두 번째 VPN 세트 추가
현재 단일 실패 지점은 관리 VPC ↔ 데이터 센터 구간의 고객 게이트웨이 1대 + VPN 1개이다. 이 디바이스나 VPN 한 개만 나가도 데이터 센터 연결이 끊김.
두 번째 고객 게이트웨이 디바이스를 두고, 그 디바이스에서 관리 VPC로 두 번째 VPN(터널) 세트를 만들면, 디바이스·VPN 모두 이중화되어 SPOF가 완화됨.
프로덕션은 이미 Direct Connect 2개로 이중화되어 있으므로, 관리 VPC 측 SPOF만 해소하면 됨 → C가 요구사항에 맞음.
틀린 이유
A. 관리 VPC와 프로덕션 VPC 사이에 VPN을 추가하는 것은, 이미 VPC 피어링으로 연결된 두 VPC 사이를 또 연결하는 것이고, 데이터 센터와 관리 VPC 사이의 단일 디바이스·단일 VPN이라는 SPOF를 해결하지 못함.
B. 관리 VPC에 가상 프라이빗 게이트웨이를 하나 더 붙이는 것만으로는, 데이터 센터 쪽 고객 게이트웨이 디바이스가 여전히 1대라 SPOF가 그대로다. 완화하려면 고객 게이트웨이(디바이스)와 VPN을 둘로 만들어야 함 → C가 맞음.
D. 같은 두 VPC 간에는 피어링 연결을 하나만 가질 수 있어 “두 번째 VPC 피어링”은 성립하지 않는다. 그리고 SPOF는 관리 VPC ↔ 데이터 센터(단일 디바이스·단일 VPN)이지, VPC 피어링이 아니다. D는 SPOF 완화와 무관함.
Answer: B
요구사항
Oracle DB에서 애플리케이션 실행
DB·백업·데이터센터 유지보수 리소스 부족으로 빠르게 AWS 이전 예정
권한 있는 액세스가 필요한 타사 DB 기능 사용
비용 효율적으로 AWS로 DB를 가장 잘 마이그레이션할 방법 선택 (문항상 “MOST”는 “가장 비용 효율적으로”로 해석)
B. Amazon RDS Custom for Oracle로 이전, 타사 기능 지원하도록 DB 설정 사용자 지정
RDS Custom for Oracle은 OS·DB 수준 사용자 지정·권한 있는 액세스가 필요한 워크로드를 위한 관리형 서비스로, “권한 있는 액세스가 필요한 타사 데이터베이스 기능”을 설정 사용자 지정으로 수용할 수 있음.
백업·패치 등은 AWS가 관리해 주므로 리소스가 제한된 상황에서 EC2에서 Oracle 직접 운영하는 것보다 운영 부담·TCO 측면에서 비용 효율적임.
Oracle 엔진을 유지하면서 타사 기능을 클라우드 서비스로 대체하거나 앱을 대대적으로 바꿀 필요 없이 이전할 수 있어, 빠르고 비용 효율적인 마이그레이션에 맞음.
틀린 이유
A. Oracle용 일반 RDS는 권한 있는 액세스·커스텀 설치가 제한되어, 타사 기능을 그대로 쓰기 어렵다. “타사 기능을 클라우드 서비스로 대체”는 대체 가능 여부·비용·시간이 불확실하고, 제한된 리소스로 빠르게 이전하기에는 부담이 큼.
C. EC2 + Oracle AMI는 완전 자체 관리라 백업·패치·유지보수를 모두 직접 해야 해 운영 부담이 커지고, “백업·데이터센터 유지보수를 위한 제한된 리소스” 조건과 맞지 않음. RDS Custom(B)이 더 비용·운영 측면에서 유리함.
D. Oracle APEX 등 의존성을 제거하고 앱을 다시 작성해 PostgreSQL RDS로 옮기는 것은 대규모 개발이 필요해 “빠른 마이그레이션”·“제한된 리소스”와 맞지 않고, 비용·기간 모두 부담이 큼.
Answer: C, E, F
요구사항
단일 서버에 있는 3계층 웹 애플리케이션을 AWS로 마이그레이션
Well-Architected 및 보안·확장성·복원력 모범 사례에 맞는 솔루션 조합 3개 선택
C. 두 AZ에 걸친 VPC, 웹/앱/DB 계층으로 리팩터링, 계층별 ASG·전용 프라이빗 서브넷
웹·애플리케이션·데이터베이스 계층을 분리하고, 계층별 Auto Scaling 그룹과 계층별 프라이빗 서브넷으로 구성하면 독립 확장과 네트워크 격리로 확장성·보안을 만족함.
두 가용 영역에 걸쳐 구성하면 가용성·복원력에 유리함.
E. 웹 티어 앞에 Elastic Load Balancer, 보안 그룹 참조로 계층 간 액세스 제어
ELB로 웹 티어 트래픽을 분산해 확장성·복원력을 높이고, 보안 그룹으로 “웹은 ELB/앱만, DB는 앱만”처럼 최소 권한 접근 제어를 할 수 있어 Well-Architected 보안·운영 모범 사례에 맞음.
F. 프라이빗 서브넷에 RDS 다중 AZ(또는 다중 AZ 클러스터), 앱 계층 보안 그룹에서만 DB 접근 허용
RDS 다중 AZ(또는 다중 AZ 클러스터) 로 DB 계층 고가용성·복원력을 확보하고, 프라이빗 서브넷 + 앱 계층 SG만 허용으로 DB 접근을 제한해 보안 요구를 충족함.
틀린 이유
A. “기존 아키텍처를 사용”해 계층 분리·리팩터링 없이 구성하고, ELB도 언급되지 않아 웹/앱 계층 확장성·복원력 모범 사례를 완전히 충족하지 못함. C처럼 계층 분리·ASG와 E의 ELB가 함께 있어야 함.
B. 단일 RDS만 두는 구성은 DB 계층 고가용성(다중 AZ) 이 없어 복원력 모범 사례에 맞지 않음. F의 다중 AZ RDS가 맞음.
D. 단일 RDS로만 구성되어 DB 계층 복원력이 부족함. “앱 계층 SG에서만 DB 접근”은 맞지만, 다중 AZ가 없어 F가 정답에 해당함.
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 501-550 (0) | 2026.02.02 |
|---|---|
| AWS SAA-C03 Dump 451-500 (0) | 2026.02.02 |
| AWS SAA-C03 Dump 351-400 (0) | 2026.02.01 |
| AWS SAA-C03 Dump 301-350 (1) | 2026.02.01 |
| AWS SAA-C03 Dump 251-300 (0) | 2026.01.30 |
