Answer: A
요구사항
데이터: 재무 앱 보고서, 평균 50KB, Amazon S3 저장
접근: 생산 첫 주에는 자주 접근, 몇 년 동안 보관
검색: 6시간 이내에 검색 가능해야 함
목표: 위를 가장 비용 효율적으로 만족
A. S3 Standard 사용, 7일 후 S3 수명 주기 규칙으로 S3 Glacier(Flexible Retrieval) 전환
첫 주: S3 Standard로 저장해 자주 접근 시 짧은 지연·저장 비용으로 처리.
7일 후: 수명 주기 규칙으로 S3 Glacier Flexible Retrieval로 전환해 장기 보관 비용을 줄임.
6시간 이내 검색: Glacier Flexible Retrieval의 Standard 검색은 보통 3~5시간이라 “6시간 이내” 요구를 충족함.
비용 효율: 첫 주는 Standard, 이후는 Glacier로 두는 구성이 “몇 년 보관 + 거의 미접근”에 맞고, Standard-IA만 쓰는 것보다 저렴함.
틀린 이유
B. 7일 후 S3 Standard-IA로만 전환하면 검색 지연은 없지만, 몇 년 동안 거의 안 쓰는 데이터에는 Glacier가 스토리지 단가가 더 낮아 A가 더 비용 효율적임.
C. S3 Intelligent-Tiering은 자동 계층 이동·모니터링 비용이 있고, “첫 주만 자주, 이후 장기 보관”처럼 패턴이 뚜렷할 때는 수명 주기 + Glacier(A) 가 더 단순하고 비용 효율적임.
D. S3 Glacier Deep Archive의 Standard 검색은 12~48시간이라 6시간 이내 검색 요구를 충족하지 못함.
Answer: B
요구사항
목표: EC2 인스턴스 비용 최적화
제약: 2~3개월마다 EC2 인스턴스 유형·제품군 변경 필요
질문: 위를 모두 만족하기 위해 회사가 해야 할 것
B. 1년 기간, 선결제 없는 컴퓨팅 절감 플랜(Compute Savings Plan) 구매
Compute Savings Plan: 시간당 컴퓨팅 사용량(달러)에 대한 약정으로 할인을 받되, 인스턴스 유형·제품군·리전을 바꿔도 할인이 적용됨.
유연성: 2~3개월마다 M5 → C5, 온디맨드 → Fargate 등으로 바꿔도 같은 Compute SP로 할인을 받을 수 있어 “유형·제품군 변경” 요구에 맞음.
비용 최적화: 온디맨드 대비 할인으로 비용을 줄이면서, 선결제 없음이라 초기 부담이 적고 1년이라 3년 RI보다 유연함.
정리: 비용 절감 + 인스턴스 유형·제품군 주기적 변경을 동시에 만족하는 선택.
틀린 이유
A. 3년 부분 선결제 예약 인스턴스(RI) 는 특정 인스턴스 유형(또는 제품군) 에 묶여 있어, 2~3개월마다 유형·제품군을 바꾸면 새 유형에는 RI가 적용되지 않아 비효율적이거나 교환(Convertible) 절차가 필요함. 3년은 변경 주기에 비해 길어 유연성이 떨어짐.
C. 1년 전액 선결제 RI도 특정 유형/제품군에 고정되어, 주기적으로 유형·제품군을 바꾸는 패턴에는 맞지 않음.
D. 1년 전액 선결제 EC2 Instance Savings Plan 은 특정 인스턴스 제품군·리전 내에서만 할인이 적용됨. 같은 제품군 내 크기 변경(m5.large → m5.xlarge)은 가능하지만, 제품군 변경(M5 → C5 등)이 2~3개월마다라면 새 제품군에는 적용되지 않아 Compute Savings Plan(B) 보다 유연성이 떨어짐.
Answer: A
요구사항
목적: 회사 Amazon S3 버킷을 검토해 개인 식별 정보(PII) 를 검색
범위: us-east-1, us-west-2 리전에 PII 데이터 저장
목표: 최소한의 운영 오버헤드로 위를 만족
A. 리전별 Amazon Macie 구성 후, S3 데이터 분석 작업 생성
Macie = PII·민감 데이터 탐지: Amazon Macie는 S3 객체 내용을 스캔해 PII·금융 정보 등 민감 데이터를 탐지하는 관리형 서비스임.
리전별 구성: Macie는 리전 서비스이므로 us-east-1·us-west-2 각 리전에서 Macie를 활성화하고, 해당 리전 S3 버킷에 대한 분석 작업(데이터 검색 작업) 을 생성하면 됨.
최소 운영: 관리형 식별자·ML 기반 탐지로, S3 객체 내용을 PII 기준으로 분석할 수 있으며 커스텀 스크립트·Config 규칙 작성 없이 설정만으로 가능함.
틀린 이유
B. Security Hub는 보안 발견 집계용이고, AWS Config 규칙은 리소스 설정(버킷 정책, 암호화 등) 평가용이라 객체 내용을 스캔해 PII를 찾는 용도가 아님.
C. Amazon Inspector는 취약점 분석(EC2, 컨테이너, Lambda 등)용이며, S3 객체 내용의 PII 검색 기능을 제공하지 않음.
D. GuardDuty는 위협 탐지(API·트래픽·S3 이벤트 이상 징후)용이며, S3 객체 내용에서 PII를 찾는 서비스는 Macie임.
Answer: C
요구사항
환경: SAP 애플리케이션 + 온프레미스 SQL Server 백엔드 DB
목표: 온프레미스 앱·DB 서버를 AWS로 마이그레이션
조건: SAP DB의 높은 요구사항을 만족하는 인스턴스 필요
온프레미스 성능: SAP 애플리케이션과 데이터베이스 둘 다 메모리 사용률이 높음
C. 애플리케이션과 데이터베이스 모두 메모리 최적화 인스턴스 제품군 사용
메모리 사용률이 높음: 온프레미스 데이터상 앱·DB 모두 메모리 사용이 높다고 했으므로, 메모리 최적화 인스턴스(R 시리즈 등)가 적합함.
SAP + SQL Server: SAP 앱과 SQL Server DB 모두 대용량 메모리·캐시에 유리한 워크로드이므로, 메모리 최적화 제품군을 앱·DB 모두에 쓰는 것이 요구사항에 맞음.
SAP DB 요구사항: SAP 인증 인스턴스 가이드에서도 메모리·IO 요구가 큰 DB에는 메모리 최적화 인스턴스를 권장함.
틀린 이유
A. 애플리케이션에 컴퓨팅 최적화를 쓰는 것은 CPU 중심 워크로드용임. 문제에서는 앱도 메모리 사용률이 높다고 했으므로, 앱도 메모리 최적화가 맞음.
B. 스토리지 최적화는 대용량 로컬 스토리지·순차 IO용이며, “메모리 사용률이 높다”는 조건과 맞지 않음.
D. HPC 최적화는 네트워크·클러스터 컴퓨팅용이며, SAP 앱의 높은 메모리 사용에는 메모리 최적화 인스턴스가 더 적합함.
Answer: A
요구사항
환경: 퍼블릭·프라이빗 서브넷, 다중 AZ VPC
앱: 프라이빗 서브넷의 EC2에서 실행, Amazon SQS 사용
목표: EC2와 SQS 간 보안 연결 구성
A. SQS용 인터페이스 VPC 엔드포인트를 프라이빗 서브넷에 두고, EC2 트래픽을 허용하는 인바운드 규칙이 있는 보안 그룹 연결
인터페이스 VPC 엔드포인트: SQS는 게이트웨이 엔드포인트가 아니라 인터페이스 엔드포인트(PrivateLink) 만 지원함. 프라이빗 서브넷에 인터페이스 엔드포인트를 두면 EC2 → SQS 트래픽이 인터넷 없이 VPC 내부·AWS 네트워크로만 전달됨.
프라이빗 서브넷: EC2가 프라이빗 서브넷에 있으므로, 엔드포인트도 같은 VPC의 프라이빗 서브넷에 두는 것이 자연스럽고, 경로도 짧음.
보안 그룹: 엔드포인트에 붙이는 보안 그룹에서 인바운드로 프라이빗 서브넷의 EC2(예: EC2 보안 그룹 ID)에서 오는 트래픽만 허용하면, 해당 EC2만 SQS 엔드포인트를 사용할 수 있어 보안이 강화됨.
틀린 이유
B. SQS용 인터페이스 엔드포인트를 퍼블릭 서브넷에 두는 구성은, 클라이언트가 프라이빗 서브넷 EC2일 때 일반적으로 쓰지 않음. 엔드포인트는 EC2와 같은 프라이빗 서브넷에 두는 것이 적절함.
C. 엔드포인트를 퍼블릭 서브넷에 두는 점은 B와 동일한 이유로 부적절함. “지정된 VPC 엔드포인트만 허용하는 SQS 정책”은 엔드포인트 정책 문맥이지, EC2–SQS 보안 연결의 핵심 답은 아님.
D. SQS는 게이트웨이 엔드포인트를 지원하지 않고 인터페이스 엔드포인트만 사용함. NAT 게이트웨이는 인터넷 경유 시 필요하지만, 인터페이스 엔드포인트를 쓰면 NAT 없이도 프라이빗 서브넷에서 SQS 접근이 가능함.
Answer: B
요구사항
환경: CloudFormation으로 3계층 웹 앱 배포, 웹·앱 계층은 EC2, DB 계층은 DynamoDB(공개 미접근)
기능: 앱 계층 EC2가 DynamoDB에 사용자 데이터 저장·검색
제약: 템플릿에서 API 자격 증명(액세스 키/비밀 키)을 노출하지 않음
목표: 위를 만족하는 구성
B. DynamoDB 읽기·쓰기 권한이 있는 IAM 역할 생성 → EC2 인스턴스 프로필에 역할 추가 → 앱 인스턴스에 인스턴스 프로필 연결
역할 기반 접근: EC2에는 IAM 역할을 부여하고, 역할에 DynamoDB 읽기·쓰기 권한만 넣으면, 인스턴스가 임시 자격 증명으로 DynamoDB에 접근함. 액세스 키/비밀 키를 템플릿이나 파라미터에 넣을 필요가 없음.
인스턴스 프로필: EC2에 역할을 붙일 때는 인스턴스 프로필에 역할을 넣고, 해당 인스턴스 프로필을 앱 EC2와 연결함. CloudFormation에서는 AWS::EC2::Instance의 IamInstanceProfile로 지정하면 됨.
자격 증명 미노출: 템플릿에는 역할·정책·인스턴스 프로필만 정의하고, 키를 파라미터나 User Data로 넘기지 않으므로 “API 자격 증명을 노출하지 않음” 요구를 충족함.
최소 권한: 해당 역할에는 DynamoDB 테이블에 대한 읽기·쓰기만 부여하면 됨.
틀린 이유
A. DynamoDB를 읽기만 할 수 있는 역할로는 “사용자 데이터를 저장하고 검색”하는 요구를 충족하지 못함. 읽기·쓰기 모두 필요하므로 B(읽기·쓰기 권한 역할)가 맞음.
C. 파라미터로 사전 생성된 IAM 사용자의 액세스 키·비밀 키를 입력하게 하면 장기 자격 증명이 템플릿/파라미터에 노출되어 “API 자격 증명을 노출하지 않음”에 위배됨.
D. 템플릿에서 IAM 사용자를 만들고 GetAtt로 액세스 키·비밀 키를 가져와 인스턴스에 전달하면, 비밀 키가 출력·User Data 등에 노출되어 요구사항을 위반함. EC2는 인스턴스 프로필 역할(B) 로 접근해야 함.
Answer: B
요구사항
데이터: Amazon S3에 대량의 반구조화 데이터 저장
목표 1: 병렬 데이터 처리로 더 빠르게 처리
목표 2: Amazon Redshift에 있는 정보로 데이터 보강(enrich)
B. Amazon EMR로 S3 데이터 처리 및 Redshift 데이터로 보강
병렬 처리: EMR(Spark/Hadoop)은 클러스터에서 S3 데이터를 분산·병렬로 처리해 대용량 반구조화 데이터를 빠르게 처리할 수 있음.
Redshift로 보강: EMR Spark에서 Redshift 커넥터(JDBC/Spark Redshift) 로 Redshift를 읽어, S3 데이터와 조인·보강하는 파이프라인을 같은 잡에서 실행할 수 있음.
단일 플랫폼: S3 처리와 Redshift 보강을 EMR 하나로 구성해 운영이 단순함.
틀린 이유
A. Athena로 S3 쿼리 + Glue로 Redshift 보강은 역할이 나뉘고, 대용량 반구조화 데이터의 병렬 처리와 S3–Redshift 조인을 한 파이프라인으로 쓰기엔 EMR(B)이 더 적합함.
C. Kinesis Data Streams는 실시간 스트리밍용이며, S3 데이터를 Redshift로 옮기는 것은 “S3 데이터를 Redshift 정보로 보강”하는 패턴이 아님. 보강은 처리 중에 S3와 Redshift를 조인하는 방식이 맞음.
D. Lake Formation은 권한·거버넌스용이고, S3 데이터를 Redshift로 처리·보강하는 엔진이 아님. 병렬 처리·보강에는 EMR(B)이 맞음.
Answer: C
요구사항
환경: 동일 AWS 계정, us-west-2 리전 내 두 개의 VPC
필요: 두 VPC 간 네트워크 트래픽 허용
트래픽: 월 약 500GB VPC 간 데이터 전송
목표: 위를 가장 비용 효율적으로 만족하는 연결 방식
C. 두 VPC 간 VPC 피어링 구성, 각 VPC 경로 테이블에서 피어링 연결로 트래픽 전달
동일 리전 VPC 피어링: 같은 리전·같은 계정의 두 VPC를 피어링하면, 피어링을 통한 트래픽에 데이터 전송 요금이 부과되지 않음(리전 내 피어링 트래픽 무료).
500GB/월: 해당 트래픽이 모두 us-west-2 내 피어링 경로로만 흐르면 추가 데이터 전송 비용 없이 처리 가능해 가장 비용 효율적임.
구성 단순: 피어링 연결 1개 + 각 VPC의 경로 테이블에 상대 VPC CIDR에 대한 경로만 추가하면 됨.
2개 VPC 전용: VPC가 2개뿐이고 리전이 같을 때는 Transit Gateway보다 피어링이 적합함.
틀린 이유
A. Transit Gateway는 시간당 요금·데이터 처리 요금이 있어, 동일 리전 두 VPC만 연결할 때는 VPC 피어링(C)보다 비용이 큼. 2-VPC·동일 리전에는 피어링이 더 저렴함.
B. Site-to-Site VPN은 온프레미스–VPC 또는 특수한 VPC 간 시나리오용이며, 동일 계정·동일 리전 두 VPC 연결에는 사용하지 않음. 터널 요금·데이터 전송 비용으로 피어링보다 비쌈.
D. Direct Connect는 온프레미스–AWS 전용이며, VPC 간 연결에는 사용하지 않음. 두 VPC를 Direct Connect로 잇는 구성이 아님.
Answer: B, E
요구사항
환경: 여러 제품군용 앱, EC2·ALB 등 다양한 컴퓨팅 리소스
조직: 동일 조직 내 여러 AWS 계정, 여러 리전
태그: 각 제품군 팀이 자체 계정의 컴퓨팅 리소스에 태그 부여
목표: 조직 통합 청구에서 제품군별 비용을 자세히 보고 싶음
B. AWS 결제 콘솔에서 사용할 사용자 정의 태그 선택(활성화)
비용 할당 태그: 통합 청구에서 “태그별 비용”을 보려면, 비용 할당 태그로 쓸 태그를 결제 콘솔에서 선택·활성화해야 함.
사용자 정의 태그: 팀이 리소스에 붙인 태그(예: 제품군)는 사용자 정의 태그이므로, 결제 콘솔에서 해당 사용자 정의 태그를 선택해 비용 할당에 사용하도록 설정함.
결과: 활성화된 태그 기준으로 비용·사용량 보고서와 Cost Explorer에서 제품군별 비용을 볼 수 있음.
E. 조직 마스터(관리) 계정에서 선택한 태그 활성화
조직 전체 적용: 통합 청구는 관리 계정(마스터 계정) 에서 이루어지므로, 마스터 계정 결제 콘솔에서 비용 할당 태그를 활성화하면 모든 링크된 계정에 적용됨.
한 곳에서 관리: 각 계정(D)에서 따로 활성화할 필요 없이, 마스터 계정에서 한 번만 설정하면 조직 전체 제품군별 비용을 통합해 볼 수 있음.
통합 청구와 정합: “조직의 통합 청구 기능에서 각 제품군의 비용” 요구를 충족하려면 마스터 계정에서 태그 활성화(E)가 필요함.
틀린 이유
A. AWS 생성 태그(예: aws:createdBy)를 선택하는 것만으로는, 팀이 부여한 제품군용 사용자 정의 태그로 비용을 나누는 요구를 충족하지 못함. 제품군 구분에는 사용자 정의 태그(B) 를 활성화해야 함.
C. 리소스 그룹 콘솔은 태그로 리소스 그룹을 만드는 용도이며, 비용 할당 태그 활성화는 결제 콘솔에서 해야 함. 제품군별 비용 상세를 위한 “단계”로는 맞지 않음.
D. 각 계정에서 태그를 활성화해도 동작은 하지만, 조직 통합 청구에서 한 번에 제품군별 비용을 보려면 마스터 계정에서 활성화(E) 하는 것이 권장되고, “단계 조합”으로는 B+E가 적절함.
Answer: A
요구사항
환경: AWS Organizations, 계정을 OU(조직 단위) 로 구성
목표: OU 계층 구조에 대한 모든 변경을 식별하고, 운영 팀에 알림
제약: 최소한의 운영 오버헤드로 위를 충족
A. AWS Control Tower로 계정 프로비저닝, 계정 드리프트 알림으로 OU 계층 변경 식별
Control Tower: 다중 계정·OU 구조를 기준(baseline)으로 관리하고, 계정 드리프트로 계정/OU 구성이 기준에서 벗어난 경우를 감지함.
OU 계층 변경 식별: 계정이 다른 OU로 이동하거나, OU 구조가 변경되면 드리프트로 잡히므로, OU 계층에 대한 변경을 식별할 수 있음.
운영 팀 알림: Control Tower의 계정 드리프트 알림(예: SNS, 이메일)을 사용해 드리프트 발생 시 운영 팀에 자동 알림 가능.
최소 운영: Control Tower가 드리프트 감지·알림을 제공하므로, CloudTrail 로그 파싱·Lambda·EventBridge 등 별도 구축 없이 설정만으로 요구사항 충족 가능.
틀린 이유
B. Control Tower + AWS Config 집계 규칙은 계정별 리소스 규정 준수 집계에 가깝고, OU 계층 구조 변경을 직접적으로 “식별·알림”하는 기능은 아님. OU 변경 감지·알림에는 Control Tower 드리프트 알림(A)이 더 적합함.
C. Service Catalog는 제품 프로비저닝용이며, Organizations에서 계정 생성·OU 관리의 표준 수단이 아님. CloudTrail 조직 트레일로 OU 변경 API는 볼 수 있으나, “변경 식별 + 운영 팀 알림”까지 하려면 EventBridge·Lambda·SNS 등을 추가로 구성해야 해 운영 오버헤드가 커짐.
D. CloudFormation으로 계정을 만들 수는 있으나, OU 계층 구조는 보통 Organizations API로 관리되며 스택 리소스가 아님. 스택 드리프트 감지는 스택으로 관리되는 리소스에만 적용되므로, OU 계층 변경 감지에는 사용할 수 없음.
Answer: A
요구사항
환경: 웹사이트가 매일 수백만 건 처리, 요청 수 증가
목표: 웹 애플리케이션 응답 시간 개선
초점: DynamoDB에서 제품 세부 정보를 조회할 때 지연 시간 감소
제약: 최소한의 운영 오버헤드로 해결
A. DynamoDB Accelerator(DAX) 클러스터 구성, 모든 읽기 요청을 DAX 경유로 라우팅
DAX: DynamoDB 전용 인메모리 캐시로, 앱 → DAX → DynamoDB 구조. DAX를 통해 읽으면 캐시 적중 시 마이크로초 단위 지연으로 제품 조회 지연을 줄일 수 있음.
캐시 관리: 캐시 미스 시 DAX가 DynamoDB에서 조회해 캐시에 넣고, 캐시 무효화·동기화는 DAX가 처리하므로 앱에서 별도 캐시 로직을 만들 필요가 없음.
최소 운영: DAX 클러스터 생성 후 앱의 DynamoDB 엔드포인트만 DAX 엔드포인트로 바꾸면 되고, ElastiCache·Lambda·스트림 등 추가 구성 없이 관리형 서비스만으로 해결됨.
DynamoDB 최적화: DynamoDB 읽기 패턴에 맞춰 설계된 서비스라, “DynamoDB 조회 지연 감소” 요구에 가장 잘 맞음.
틀린 이유
B. Redis용 ElastiCache를 DynamoDB 앞에 두면 캐시 채우기·미스 처리·무효화를 앱 또는 별도 구성에서 직접 구현해야 해서 운영 부담이 커짐. DynamoDB 전용 캐시인 DAX보다 운영 오버헤드가 큼.
C. Memcached용 ElastiCache도 B와 같이 캐시 레이어를 직접 관리해야 하므로 “최소한의 운영 오버헤드”를 만족하기 어려움.
D. DynamoDB 스트림 + Lambda로 ElastiCache를 채우고 읽기를 ElastiCache로 보내는 방식은 스트림·Lambda·캐시를 함께 운영해야 해서 구성이 복잡하고, DAX 한 번 구성하는 것보다 운영 부담이 큼.
Answer: A, B
요구사항
환경: VPC 내 Amazon EC2 인스턴스에서 Amazon DynamoDB API 호출
목표: 해당 API 호출이 인터넷을 거치지 않도록 구성
질문: 위를 만족하기 위해 수행할 2가지 단계 선택
A. 엔드포인트를 사용하도록 라우팅 테이블에 경로 추가
DynamoDB용 게이트웨이 엔드포인트를 만들면, 해당 엔드포인트와 연결할 라우팅 테이블을 지정해야 함.
해당 라우팅 테이블에 DynamoDB 플렉시블리스트(prefix list) 에 대한 경로를 두고, 대상으로 VPC 엔드포인트 ID를 지정하면, 트래픽이 인터넷이 아니라 엔드포인트로만 나감.
서브넷의 라우팅 테이블에 이 경로가 있어야 EC2 → DynamoDB 트래픽이 게이트웨이 엔드포인트를 타서 AWS 네트워크 내부로만 전달됨.
B. DynamoDB용 게이트웨이 VPC 엔드포인트 생성
DynamoDB는 인터페이스 엔드포인트가 아니라 게이트웨이 VPC 엔드포인트만 지원함.
VPC에서 DynamoDB 서비스용 게이트웨이 엔드포인트를 생성하고, 사용할 라우팅 테이블과 연결하면, 해당 경로의 DynamoDB API 트래픽이 퍼블릭 인터넷으로 나가지 않음.
게이트웨이 엔드포인트는 ENI·보안 그룹 없이 라우팅만으로 동작함.
틀린 이유
C. “Amazon EC2용 인터페이스 엔드포인트”는 EC2 API 호출용이며, 여기서 요구하는 것은 EC2에서 DynamoDB API를 호출할 때 인터넷 미경유이므로 해당 없음. DynamoDB는 게이트웨이 엔드포인트(B)로 해결함.
D. “각 서브넷에서 엔드포인트용 ENI 생성”은 인터페이스 엔드포인트에서 쓰는 방식임. DynamoDB는 게이트웨이 엔드포인트라 ENI를 만들지 않음.
E. 엔드포인트 보안 그룹에 규칙 추가는 인터페이스 엔드포인트에만 해당함. 게이트웨이 엔드포인트는 보안 그룹을 사용하지 않으며, 엔드포인트 정책으로만 제어함.
Answer: B
요구사항
환경: Amazon EKS 클러스터와 온프레미스 Kubernetes 클러스터에서 애플리케이션 실행
목표: 한 곳에서 모든 클러스터와 워크로드를 보고, 최소한의 운영 오버헤드로 구현
B. Amazon EKS Connector로 모든 Kubernetes 클러스터 등록·연결
EKS Connector: 외부 Kubernetes 클러스터(온프레미스 포함)를 AWS에 등록해, EKS 콘솔에서 EKS 클러스터와 함께 한 화면에 표시할 수 있음.
중앙 가시성: EKS 클라우드 클러스터와 온프레미스 K8s 클러스터를 등록하면, EKS 콘솔에서 클러스터 목록·워크로드를 통합해 볼 수 있음.
최소 운영: Connector 에이전트 설치·등록만 하면 되고, 별도 대시보드·수집 파이프라인을 구축할 필요가 없음.
틀린 이유
A. CloudWatch Container Insights는 EKS(및 EC2 기반 컨테이너) 메트릭·로그 수집용이며, 온프레미스 K8s를 등록해 한 화면에 보는 기능은 없어 “모든 클러스터를 중앙에서 보기”에는 EKS Connector(B)가 맞음.
C. Systems Manager는 관리형 인스턴스(EC2, 온프레미스 서버) 용이며, Kubernetes 클러스터를 등록·통합 조회하는 용도가 아님.
D. EKS Anywhere는 온프레미스에서 EKS를 운영하는 용도이며, 여러 클러스터를 한 곳에서 조회하는 “중앙 보기” 솔루션이 아님. kubectl 컨텍스트 전환은 수동이라 “최소 운영”에도 맞지 않음.
Answer: B
요구사항
기능: 전자상거래 앱, 웹에서 구매 거래 완료 가능해야 함
데이터: 중요·민감한 고객 정보 저장
보안: 데이터베이스 관리자(DBAs)가 민감 데이터를 볼 수 없어야 함
B. Amazon RDS for MySQL에 민감 데이터 저장, AWS KMS로 클라이언트 측 암호화 적용
RDS MySQL: 주문·결제 등 거래 완료에 필요한 트랜잭션·ACID를 지원하는 관계형 DB로, 구매 완료 기능에 적합함.
클라이언트 측 암호화: 앱이 DB에 넣기 전에 KMS 키로 암호화하면, DB에는 암호문만 저장됨. DB 관리자는 DB 접근만으로는 복호화할 수 없어 “DB 관리자로부터 보호” 요구를 충족함.
KMS: 키 관리·감사는 AWS KMS가 담당하고, 앱만 필요한 권한으로 암·복호화하도록 구성 가능함.
틀린 이유
A. EBS 볼륨 + EBS 암호화는 서버 측 암호화이며, DB/앱이 돌아가는 인스턴스에 접근하면 복호화 가능. “DB 관리자로부터 보호”를 명시적으로 만족하지 않고, 구매 거래용 DB 구성도 아님.
C. S3는 객체 스토리지로, 주문·결제 같은 트랜잭션 처리에는 적합하지 않음. 서버 측 암호화만으로는 DB 관리자가 아닌 “S3 접근자” 관점의 제어라, “DB 관리자로부터 보호” 맥락과도 다름.
D. FSx for Windows는 파일 공유용이며, 구매 거래를 위한 트랜잭션 DB가 아님. Windows 파일 권한은 “DB 관리자로부터 보호”가 아니라 파일 접근 제어에 가깝음.
Answer: C
요구사항
현재: 온프레미스 MySQL DB, 트랜잭션 데이터
목표: AWS로 DB 마이그레이션
조건:
마이그레이션된 DB가 기존 애플리케이션과 호환
수요 증가 시 자동 확장
C. AWS DMS로 Amazon Aurora로 마이그레이션, Aurora Auto Scaling 활성화
호환성: Amazon Aurora는 MySQL 호환이므로, 기존 MySQL용 앱이 변경 최소화로 Aurora에 연결 가능.
자동 확장: Aurora Auto Scaling으로 읽기 복제본을 부하에 따라 자동 추가·제거해, 수요 증가 구간에서 자동 확장 요구를 충족.
마이그레이션: AWS DMS로 온프레미스 MySQL → Aurora 전환·동기화가 표준 방식이며, 다운타임을 줄이면서 마이그레이션 가능.
틀린 이유
A. RDS for MySQL + 탄력적 스토리지 확장은 스토리지(디스크) 자동 확장만 해당. “수요 증가 시 자동 확장”을 컴퓨팅/읽기 측면에서 충족하려면 Aurora Auto Scaling(C)이 더 적합함.
B. Redshift는 데이터 워허우스(OLAP) 로, 트랜잭션용 MySQL 앱과 호환되지 않음. 마이그레이션 후 앱 호환성 유지 요구를 만족하지 못함.
D. DynamoDB는 NoSQL이라 MySQL(관계형·SQL) 앱과 스키마·쿼리 모델이 다름. 호환성 유지 없이 대규모 앱 변경이 필요함.
Answer: B
요구사항
환경: VPC 내 2개 가용 영역에 걸친 여러 Amazon EC2 Linux 인스턴스
앱: 계층적 디렉터리 구조 사용
필요: 공유 스토리지에서 동시에 빠르게 읽기·쓰기
목표: 위를 만족하는 구성
B. Amazon EFS 파일 시스템 생성 후, 각 EC2 인스턴스에서 EFS 마운트
공유 파일 시스템: EFS는 NFS 기반 관리형 파일 시스템으로, 여러 EC2 인스턴스가 동일한 파일 시스템을 동시에 마운트해 사용할 수 있음.
동시 읽기/쓰기: NFS 프로토콜로 동시 접근을 지원하며, 계층적 디렉터리(POSIX) 구조를 그대로 사용 가능함.
다중 AZ: EFS는 리전 내 여러 가용 영역에 걸쳐 생성되므로, 2개 AZ의 EC2가 모두 같은 EFS에 붙을 수 있음.
빠른 접근: 로컬 네트워크 지연으로 낮은 지연 접근이 가능하며, 용량·처리량이 자동으로 확장됨.
틀린 이유
A. S3는 객체 스토리지이며, POSIX 파일 시스템처럼 마운트해 계층 디렉터리·동시 읽기/쓰기로 쓰는 용도가 아님. 공유 파일 시스템 요구에는 EFS가 적합함.
C. EBS 볼륨은 한 번에 한 EC2 인스턴스에만 연결 가능하고, 동일 AZ에만 붙을 수 있어 여러 인스턴스가 동시에 쓰는 공유 스토리지로 사용할 수 없음.
D. 인스턴스마다 EBS를 두고 동기화하는 방식은 단일 공유 네임스페이스가 아니라 복제/동기화 구조이며, 진정한 동시 공유 접근과는 다름. EFS(B)가 요구사항에 맞음.
Answer: A
요구사항
워크로드: 건물 내 비즈니스 테넌트의 시간당 에너지 소비량 저장
수집: 센서가 HTTP 요청으로 사용량을 합산해 DB에 전송
원칙: 가능하면 관리형 서비스 사용, 독립 컴포넌트 추가로 기능 확장
목표: 최소한의 운영 오버헤드로 위를 만족
A. API Gateway + Lambda로 센서 데이터 수신·처리 후 DynamoDB에 저장
API Gateway: HTTP 요청을 받는 관리형 API로, 센서의 HTTP 전송을 그대로 수신 가능.
Lambda: 수신·가공·저장 로직을 서버리스로 실행해 EC2·OS 관리 없이 처리 가능.
DynamoDB: 테넌트·시간·사용량 같은 시계열·키-값 저장과 조회에 적합한 관리형 DB.
관리형·최소 운영: API Gateway·Lambda·DynamoDB 모두 관리형이라 서버·DB 운영 부담이 적음.
확장성: 새 리소스(예: 추가 Lambda, DynamoDB 스트림·Lambda)를 붙여 기능을 늘리기 쉬움.
틀린 이유
B. ELB + EC2 Auto Scaling은 EC2·OS·패치를 직접 관리해야 해 운영 부담이 큼. S3는 객체 저장용이라 “테넌트별 시간당 소비” 조회·집계에는 DynamoDB 같은 DB가 더 적합함.
C. API Gateway + Lambda는 좋지만, EC2의 SQL Server Express는 인스턴스·DB 관리가 필요해 관리형 서비스 원칙과 “최소 운영”에 맞지 않음.
D. ELB + EC2 Auto Scaling은 서버 관리 부담이 있고, EFS는 파일 공유용이라 시간당·테넌트별 소비 데이터의 저장·조회에는 DynamoDB가 더 적합함.
Answer: A
요구사항
용도: 엔지니어링 도면 저장·조회 웹 애플리케이션, 모든 구성요소 AWS 배포
캐싱: 도면 로드 시 대기 시간 최소화를 위한 캐싱 필요
용량: 페타바이트 규모 저장 가능해야 함
질문: 위를 만족하는 스토리지 + 캐싱 조합
A. Amazon S3 + Amazon CloudFront
S3: 객체 스토리지로 페타바이트 규모 저장에 적합하고, 도면 파일을 객체로 저장·조회하기에 맞음.
CloudFront: CDN으로 도면을 엣지에서 캐싱해, 동일/인접 사용자 재요청 시 오리진(S3) 대신 캐시에서 전달해 로드 대기 시간을 줄임.
조합: 오리진을 S3로 두고 CloudFront 배포를 연결하면, “캐싱으로 로드 시간 최소화”와 “페타바이트급 저장”을 동시에 만족함.
관리형: S3·CloudFront 모두 관리형 서비스라 운영 부담이 적음.
틀린 이유
B. S3 Glacier는 아카이브 스토리지로, 검색에 수 분~수 시간이 걸려 “도면 로드 대기 시간 최소화”에 맞지 않음. 페타바이트 용량은 맞아도 접근 속도 요구를 충족하지 못함.
C. EBS는 EC2에 붙는 블록 스토리지로, 페타바이트를 단일/소수 볼륨으로 쓰기엔 부적절하고, CloudFront 오리진으로 쓰는 일반 패턴도 아님. 페타바이트 + 웹 캐싱에는 S3 + CloudFront가 적합함.
D. Storage Gateway는 온프레미스–AWS 연동용에 가깝고, 전부 AWS에 둔 웹앱의 주 스토리지로 쓰기엔 부적합함. 페타바이트 웹 객체 저장·캐싱에는 S3 + CloudFront(A)가 맞음.
Answer: A
요구사항
상황: EventBridge 규칙의 타깃이 타사 API
문제: 타사 API가 수신 트래픽을 받지 못함
목표: 규칙 조건 충족 여부와 규칙의 타깃 호출 여부를 확인할 수 있는 방법
A. AWS/Events 네임스페이스의 Amazon CloudWatch 지표 확인
AWS/Events 지표: EventBridge(CloudWatch Events)는 AWS/Events 네임스페이스에 규칙 실행·타깃 호출 관련 지표를 남김.
규칙 조건 충족: Invocations 등으로 규칙이 몇 번 실행됐는지(이벤트가 조건에 맞아 규칙이 트리거됐는지) 확인 가능.
타깃 호출 여부: InvocationsFailed 등으로 타깃 호출 실패 횟수를 볼 수 있어, 타사 API가 호출되지 않는 원인이 규칙 미실행인지, 타깃 호출 실패인지 구분하는 데 활용 가능.
운영 검증: 별도 로그/트레일 설정 없이 콘솔에서 지표만으로 “규칙이 돌았는지, 타깃이 호출됐는지”를 빠르게 확인할 수 있음.
틀린 이유
B. SQS 데드 레터 큐(DLQ)는 타깃 호출이 실패했을 때 전달된 이벤트만 보여 줌. “규칙이 실행됐는지”, “타깃이 호출됐는지”를 먼저 보려면 AWS/Events 지표(A)가 적합하고, DLQ는 실패 사례 분석용으로 보조적임.
C. EventBridge는 기본적으로 이벤트 내용을 CloudWatch Logs에 남기지 않음. Logs를 쓰려면 타깃으로 로그 그룹 등이 필요하므로, 규칙·타깃 동작 검증의 기본 수단은 AWS/Events 지표(A)가 맞음.
D. CloudTrail은 EventBridge에 대한 API 호출(PutRule, DeleteRule 등)을 기록할 뿐, 규칙이 매번 실행됐는지, 타깃이 호출됐는지를 보는 용도가 아님. 규칙/타깃 동작 확인에는 AWS/Events 지표(A)를 사용해야 함.
Answer: B
요구사항
워크로드: 매주 금요일 저녁에 실행되는 대규모 워크로드
환경: us-east-1 2개 AZ의 Amazon EC2 인스턴스
평상시: 2개 이하 인스턴스만 유지
금요일: 최대 6개 인스턴스로 확장해 반복 워크로드 처리
목표: 위를 최소한의 운영 오버헤드로 만족
B. 예약된 작업(Scheduled Action)이 있는 Auto Scaling 그룹 생성
예약된 확장/축소: Auto Scaling 예약 작업(Scheduled Action) 으로 “매주 금요일 X시에 desired capacity를 6으로”, “매주 토요일 Y시에 2로”처럼 일정 기반으로 용량을 바꿀 수 있음.
운영 부담 최소: 한 번 예약만 설정하면 매주 자동으로 확장·축소되므로, 금요일마다 수동 조정(C) 이나 EventBridge + Lambda(A) 같은 추가 구성 없이 요구사항을 충족함.
2 AZ 유지: ASG를 2개 AZ에 두고 min/max/desired만 예약으로 바꾸면, 평소 2개·금요일 6개 구간을 그대로 반영할 수 있음.
틀린 이유
A. EventBridge로 “미리 알림”을 보내는 것은 알림일 뿐, 인스턴스를 직접 늘리지는 않음. 확장하려면 EventBridge → Lambda 등으로 ASG API를 호출하는 추가 설계·운영이 필요해 “최소 운영”에는 B(예약 작업)가 더 적합함.
C. 수동 조정은 매주 금요일 사람이 직접 desired capacity를 바꿔야 하므로 운영 부담이 크고, “최소한의 운영 오버헤드”를 만족하지 못함.
D. CPU 등 메트릭 기반 자동 조정은 부하에 반응하는 방식이라, “매주 금요일 저녁”처럼 일정이 정해진 확장에는 예약 작업(B)이 더 정확하고 운영이 단순함.
Answer: B
요구사항
환경: REST API 구축
TLS: API 엔드포인트에 TLSv1.3 사용
인증서: 특정 공개 타사 CA가 서명한 TLS 인증서 사용
목표: 위 조건을 만족하는 구성
B. 타사 CA가 서명한 인증서를 ACM에 등록(가져오기), API Gateway HTTP API에 사용자 지정 도메인·해당 인증서 적용
타사 CA 인증서: 타사 CA가 서명한 인증서를 AWS Certificate Manager(ACM)에 가져오기(import) 하면, API Gateway 사용자 지정 도메인에서 그 인증서를 선택해 사용할 수 있음.
TLS 1.3: Amazon API Gateway는 TLS 1.3을 지원하므로, 해당 사용자 지정 도메인으로 TLS 1.3 협상이 가능함.
HTTP API + 사용자 지정 도메인: API Gateway HTTP API에 사용자 지정 도메인을 만들고, 위 ACM 인증서를 연결하면 “타사 CA 서명 + TLS 1.3” 요구를 충족함.
운영: 인증서 갱신·배포는 ACM(가져온 인증서의 갱신은 수동)과 API Gateway가 처리하므로, 서버에 직접 인증서를 올리는 방식보다 관리가 단순함.
틀린 이유
A. 로컬에서 인증서를 만들고 ACM으로 가져온 뒤 API Gateway에 쓰는 흐름은 기술적으로 가능하지만, 문제에서 요구하는 “타사 CA가 서명한 인증서를 ACM에서 사용”하는 정답 표현은 B(ACM에서 해당 인증서를 등록·사용)에 더 가깝고, A는 “로컬 시스템으로 생성”에 초점이 있어 B가 더 적합함.
C. Lambda 함수 URL은 사용자 지정 도메인·타사 CA 인증서를 직접 붙이는 방식이 아니며, 사용자 지정 도메인과 타사 CA 인증서는 API Gateway(또는 CloudFront)와 함께 쓰는 구성이 맞음.
D. Lambda 함수 URL에 “타사 CA가 서명한 ACM 인증서를 사용”하도록 구성하는 것은 지원 방식이 제한적이며, “TLS 1.3 + 특정 타사 CA” 요구는 API Gateway 사용자 지정 도메인 + ACM(B)으로 충족하는 것이 맞음.
Answer: C
요구사항
환경: AWS에서 앱 실행, AWS Direct Connect로 온프레미스 MySQL 호환 DB 연결
DB: 지속적으로 최소 2GiB 메모리 사용
트래픽: 일관되지 않은(변동) 사용량
목표: 온프레미스 DB를 관리형 AWS 서비스로 이전, 자동 확장으로 예기치 않은 부하 증가 대응, 최소한의 관리
C. 최소 1 ACU인 Amazon Aurora Serverless v2 프로비저닝
MySQL 호환: Aurora Serverless v2는 MySQL/PostgreSQL 호환이라 기존 MySQL 앱·Direct Connect 대체용으로 적합함.
자동 확장: ACU가 부하에 따라 자동 증가·감소하므로, 일관되지 않은 사용량과 예기치 않은 부하 증가를 별도 인스턴스 리사이징 없이 처리할 수 있음.
최소 관리: 인스턴스 크기 선택·수동 스케일링이 필요 없고, 최소 ACU(예: 1 ACU)만 설정하면 유휴 시 비용을 줄이면서 필요 시 자동으로 확장됨.
관리형 서비스: 패치·백업·고가용성은 AWS가 담당해 운영 부담이 적음.
틀린 이유
A. DynamoDB는 NoSQL이라 MySQL 호환이 아니며, 기존 MySQL 앱을 그대로 쓰려면 대규모 변경이 필요함. “MySQL 호환 관리형 DB” 요구를 충족하지 못함.
B. Aurora(프로비저닝)는 인스턴스 크기를 지정하는 방식이라, 부하 변동에 맞춰 컴퓨트 자동 확장이 되지 않음. 예기치 않은 부하에는 수동 스케일링이나 읽기 복제본이 필요해 “자동 확장·최소 관리”에는 불리함.
D. RDS for MySQL 2GiB는 고정 인스턴스라, 부하 증가 시 컴퓨트 자동 확장이 없음. 예기치 않은 부하 대응과 최소 관리 요구를 충족하기 어려움.
Answer: D
요구사항
환경: AWS Lambda, Java 11 실행
목표: Lambda 함수 시작 지연 시간 감소
제약: 애플리케이션에 엄격한 지연 시간 요구사항 없음
추가 목표: 함수 확장 시 콜드 스타트·이상치 대기 시간 감소, 가장 비용 효율적인 방법
D. Lambda SnapStart 구성
SnapStart 동작: Java용 Lambda SnapStart는 초기화된 실행 환경(메모리 스냅샷) 을 저장해, 새 실행 환경이 필요할 때 JVM을 처음부터 띄우지 않고 스냅샷에서 복원함.
콜드 스타트·이상치 감소: Java는 JVM 기동이 무거워 콜드 스타트가 큰데, SnapStart로 복원 시간만 걸리므로 콜드 스타트와 이상치 지연이 크게 줄어듦.
비용 효율: 프로비저닝된 동시성(A) 은 미리 웜 인스턴스를 유지해 추가 비용이 들지만, SnapStart는 스냅샷 복원만 사용해 별도 유지 비용 없음. “가장 비용 효율적으로” 만족함.
Java 11 지원: SnapStart는 Java(11 등) 런타임에서 지원되는 기능임.
틀린 이유
A. 프로비저닝된 동시성은 콜드 스타트를 줄이지만 예약 용량에 대한 비용이 계속 발생해 “가장 비용 효율적인” 방법이 아님.
B. 함수 제한 시간을 늘리는 것은 실행 시간 상한만 바꿀 뿐, 시작 지연(콜드 스타트) 를 줄이지 않음.
C. 메모리를 늘리면 CPU가 같이 늘어 JVM 기동이 조금 빨라질 수 있으나, Java 콜드 스타트의 주된 원인(JVM 초기화)을 근본적으로 해결하지 못하고, 호출당 비용은 올라감. SnapStart보다 비용·효과 면에서 불리함.
Answer: A
요구사항
환경: Amazon RDS for MySQL 기반 주식 시장 추적 애플리케이션
사용 패턴: 매주 말 2시간만 데이터베이스가 필요
목표: 위 조건에서 가장 비용 효율적인 DB 구성
A. 기존 RDS for MySQL을 Aurora Serverless v2 MySQL 클러스터로 마이그레이션
Aurora Serverless v2: 부하에 따라 용량(ACU)이 자동으로 늘었다 줄었다 하므로, 사용하지 않는 구간에는 최소 ACU로 과금되어 24시간 풀가동 대비 비용이 적음.
주 2시간 사용에 유리: 나머지 시간에는 최소 용량만 유지하고, 주말 2시간 구간에서만 스케일 업하면 되므로 “주 2시간만 실행 비용 최적화” 요구에 맞음.
관리형 서비스: EC2/ECS에서 MySQL을 직접 운영할 필요 없고, 시작/중지 스크립트 없이 자동 확장만으로 처리 가능함.
MySQL 호환: Aurora MySQL 호환이므로 애플리케이션 변경을 최소화할 수 있음.
틀린 이유
B. 일반 Aurora MySQL 클러스터는 24시간 풀가동 구조라, 주 2시간만 써도 나머지 시간 비용이 발생해 “가장 비용 효율적”이 되기 어렵음.
C. EC2 + MySQL + 예약 인스턴스는 예약으로 단가는 낮아질 수 있으나, 주 2시간만 쓰는 패턴에는 Aurora Serverless v2처럼 유휴 시 최소 과금되는 방식이 더 비용 효율적임. EC2는 스케줄로 시작/중지해도 운영 부담이 큼.
D. ECS + MySQL 컨테이너는 작업 시작/중지로 사용 시간만 돌릴 수는 있으나, DB를 직접 관리해야 하고 “관리형 DB + 자동 확장” 요구에는 Aurora Serverless v2(A)가 더 적합함.
Answer: C
요구사항
환경: 한 AWS 리전의 ALB 뒤 Amazon EKS에 앱 배포
DB: PostgreSQL 호환 엔진에 데이터 저장
목표: DB 고가용성 + 읽기 워크로드용 용량 확대, 가장 효율적인 구성
C. 다중 AZ DB 클러스터 배포로 Amazon RDS(PostgreSQL) 생성
고가용성: RDS 다중 AZ DB 클러스터는 Writer·Standby·Reader를 여러 AZ에 두어 장애 시 자동 장애 조치와 고가용성을 제공함.
읽기 확장: 클러스터 내 Reader 인스턴스를 두면 읽기 트래픽을 Reader로 분산해, “읽기 워크로드용 증가된 용량”을 같은 리전 안에서 효율적으로 만족함.
PostgreSQL: RDS for PostgreSQL 다중 AZ DB 클러스터를 쓰면 PostgreSQL 엔진 요구사항을 유지할 수 있음.
단일 리전 효율: 같은 리전 EKS → DB 읽기에는 크로스 리전 복제본(D)보다 같은 리전의 DB 클러스터 + Reader(C) 가 지연·비용·운영 측면에서 더 효율적임.
틀린 이유
A. DynamoDB + 전역 테이블은 NoSQL이며, 요구사항의 “PostgreSQL 데이터베이스 엔진”과 맞지 않음.
B. RDS 다중 AZ 인스턴스 배포(기존 Multi-AZ)는 Standby가 장애 조치용이라 읽기 트래픽을 분산하지 않음. 읽기 용량 확대에는 Reader가 있는 DB 클러스터(C) 가 적합함.
D. 리전 간 읽기 전용 복제본은 읽기 확장은 가능하지만, 같은 리전 EKS 기준으로는 같은 리전 DB 클러스터 + Reader(C) 가 더 효율적이고, 고가용성·읽기 확장을 한 구성으로 충족하는 점에서 C가 더 적합함.
Answer: D
요구사항
환경: Amazon API Gateway + AWS Lambda 기반 RESTful 서버리스 웹 애플리케이션
사용자: 지리적으로 분산
목표: 이 사용자들의 API 요청 대기 시간 감소
질문: 위를 만족하기 위해 사용해야 할 엔드포인트 유형
D. 엣지 최적화(Edge-Optimized) 엔드포인트
CloudFront 엣지 배포: 엣지 최적화 엔드포인트는 API Gateway가 CloudFront 엣지 로케이션에 배포된 형태로, 요청이 가장 가까운 엣지로 라우팅됨.
지연 시간 감소: 지리적으로 분산된 사용자는 각자 가까운 엣지에서 API를 호출하므로, 왕복 지연이 줄어듦.
Regional 대비: Regional 엔드포인트는 한 리전에만 있으므로, 리전에서 먼 사용자는 지연이 커짐. 글로벌 사용자에는 엣지 최적화가 유리함.
Private과 구분: Private 엔드포인트는 VPC 내부 전용이라, 공개 웹 앱의 글로벌 사용자 지연 감소와는 무관함.
틀린 이유
A. 프라이빗 엔드포인트는 VPC 내부에서만 API 접근용이며, 지리적으로 분산된 공개 사용자의 API 지연을 줄이는 용도가 아님.
B. 지역(Regional) 엔드포인트는 단일 리전에만 배포되어, 해당 리전에서 먼 사용자의 지연이 커져 “지리적 분산 사용자 대기 시간 감소”에는 엣지 최적화(D)가 더 적합함.
C. 인터페이스 VPC 엔드포인트는 VPC에서 AWS 서비스 접근용(PrivateLink)이며, API Gateway 엔드포인트 유형(Edge / Regional / Private)을 묻는 문제와는 다름.
Answer: C
요구사항
환경: Amazon CloudFront로 웹사이트 콘텐츠 페이지 제공
필요: 고객 접속 시 TLS 인증서 사용
목표: TLS 인증서 생성·갱신을 자동화하고, 가장 효율적인 방식으로 구현
C. AWS Certificate Manager(ACM)로 인증서 생성, 도메인에 DNS 검증 사용
ACM: TLS 인증서 발급·자동 갱신을 AWS가 담당. CloudFront는 ACM 인증서(us-east-1 리전)를 사용할 수 있음.
DNS 검증: 도메인 소유 확인을 DNS CNAME 레코드로 수행. Route 53 사용 시 레코드 생성·검증을 자동화하기 쉽고, 사람이 이메일 링크를 클릭할 필요가 없음.
자동화: 인증서 생성 후 CloudFront에 연결만 하면, 갱신은 ACM이 자동으로 처리하므로 “가장 효율적”인 선택에 해당함.
틀린 이유
A. CloudFront 보안 정책은 TLS 버전(예: 1.2 이상) 설정용이며, 인증서를 생성·갱신하는 기능이 아님.
B. CloudFront OAC(원본 액세스 제어)는 오리진(S3 등) 접근 제어용이며, TLS 인증서 발급·갱신과 무관함.
D. ACM + 이메일 검증도 가능하지만, 검증 시 이메일 링크 클릭이 필요해 DNS 검증(C)보다 자동화·운영 효율이 떨어짐.
Answer: A
요구사항
환경: Amazon DynamoDB를 DB 계층으로 쓰는 서버리스 앱, 사용자 급증
목표: DB 응답 시간을 밀리초 → 마이크로초로 줄이고, DB 요청을 캐시
제약: 최소한의 운영 오버헤드로 위를 만족
A. DynamoDB Accelerator(DAX) 사용
DAX: DynamoDB 전용 인메모리 캐시. 앱 → DAX → DynamoDB 구조로, 캐시 적중 시 마이크로초 수준 지연으로 응답함.
캐시: 읽기 요청을 DAX가 먼저 처리하고, 미스 시에만 DynamoDB를 호출해 “DB 요청 캐시” 요구를 충족함.
동일 API: DynamoDB SDK 그대로 사용하고 엔드포인트만 DAX로 바꾸면 되어, 캐시 무효화·이중 쓰기 등 추가 로직·운영이 거의 없음.
관리형: DAX 클러스터 생성·엔드포인트 연결만 하면 되므로 운영 부담이 적음.
틀린 이유
B. Redshift는 분석용 데이터 워하우스이며, DynamoDB처럼 키 기반 마이크로초 지연·캐시 용도가 아님. 마이그레이션 시 데이터 모델·앱 변경이 크고 요구사항과 맞지 않음.
C. RDS는 관계형 DB로, DynamoDB NoSQL과 모델이 달라 마이그레이션·앱 변경이 크고, “마이크로초 + 캐시”를 위한 전용 캐시(DAX)가 아님.
D. ElastiCache(Redis)로 DynamoDB 앞에 캐시를 두면 캐시 무효화·이중 쓰기·앱 로직을 직접 구현해야 해서 운영 부담이 커지고, DynamoDB 전용 캐시인 DAX(A) 가 “최소 운영”에 더 적합함.
Answer: A
요구사항
환경: PostgreSQL용 Amazon RDS 사용 애플리케이션
사용 패턴: 평일 업무 시간에만 트래픽 수신
목표: 위 사용 패턴 기준으로 비용 최적화 + 운영 오버헤드 감소
A. AWS 인스턴스 스케줄러로 시작·중지 일정 구성
일정 기반 자동 제어: Instance Scheduler(또는 동일 목적 솔루션)로 RDS 시작·중지 일정을 설정하면, 업무 시간에는 DB를 켜고 그 외에는 중지할 수 있음.
비용 절감: RDS 인스턴스를 중지하면 해당 시간에는 컴퓨팅 비용이 발생하지 않아, 24시간 풀가동 대비 비용이 줄어듦.
운영 부담 최소: 수동으로 DB를 켜고 끌 필요 없이 스케줄만 설정하면 되므로 운영 오버헤드가 적음.
RDS 중지 지원: Single-AZ RDS는 수동/스케줄 기반으로 중지·시작이 가능함.
틀린 이유
B. 자동 백업 끄고 주간 수동 스냅샷만 사용하면, “업무 시간 외에는 DB 중지”가 아니라 백업 방식만 바뀌어 비용 절감 효과가 제한적이고, 수동 스냅샷은 운영 부담을 늘림.
C. CPU 사용률 기반으로 Lambda에서 시작·중지하는 커스텀 Lambda는 개발·유지보수가 필요해 “운영 오버헤드 감소”보다는 증가에 가깝고, 스케줄 기반(A)이 더 단순함.
D. All Upfront 예약 인스턴스는 24시간 풀가동을 전제로 할인을 받는 방식이라, 평일 업무 시간만 쓰는 패턴에서는 스케줄로 중지하는 A가 비용·요구사항에 더 잘 맞음.
Answer: D
요구사항
환경: 온프레미스에서 로컬 연결 스토리지로 지연에 민감한 애플리케이션 운영
마이그레이션: 리프트 앤 시프트로 AWS 이전, 아키텍처 변경 없음
목표: 위를 가장 비용 효율적으로 만족
D. EC2에서 앱 호스팅, Amazon EBS GP3 볼륨으로 스토리지 구성
EBS = 로컬 디스크 대체: 로컬 연결 스토리지를 EBS 블록 스토리지로 대체하면, 앱이 디스크를 쓰는 방식만 유지하면 되어 리프트 앤 시프트에 맞음.
GP3 = 비용·성능 균형: GP3는 GP2 대비 기본 단가가 낮고, IOPS·처리량을 필요에 맞게 조정 가능해, 지연에 민감한 워크로드를 비용 효율적으로 수용할 수 있음.
아키텍처 변경 최소: EC2 + EBS만 추가하면 되고, FSx·Auto Scaling 등 새 구조를 넣지 않아 “가장 비용 효율적”이고 변경 범위도 작음.
틀린 이유
A. FSx for Lustre는 HPC·대용량 처리용 병렬 파일 시스템이라, 일반적인 “로컬 디스크 대체” 리프트 앤 시프트에는 과하고 비용·복잡도가 큼.
B. EBS GP2는 GP3보다 비용이 높은 구형 옵션이라, “가장 비용 효율적”이라는 조건에는 GP3(D) 가 맞음.
C. FSx for OpenZFS는 NFS 파일 시스템용이며, 로컬 블록 디스크를 그대로 대체하는 구성이 아니고, 리프트 앤 시프트·비용 측면에서 EBS GP3(D)가 더 적합함.
Answer: B
요구사항
환경: Amazon EC2에서 상태 저장(stateful) 프로덕션 애플리케이션 실행
조건: 앱이 항상 동작하려면 최소 2개의 EC2 인스턴스 필요
목표: 고가용성(HA) 및 내결함성 아키텍처 설계
현재: EC2용 Auto Scaling 그룹 생성 완료
질문: 위 요구사항을 충족하기 위해 추가로 수행할 단계
B. Auto Scaling 그룹 최소 용량 4, 한 AZ에 온디맨드 2대·다른 AZ에 온디맨드 2대 배포
최소 용량 4: “최소 2대”를 넘어 4대로 두어, 한 대 장애나 한 AZ 장애 시에도 나머지 인스턴스로 서비스 유지 가능(내결함성 강화).
2개 AZ 분산: 한 AZ에 2대, 다른 AZ에 2대 두어 다중 가용 영역 구성 → 한 AZ 장애 시에도 다른 AZ 인스턴스가 트래픽 처리(고가용성).
온디맨드 사용: 상태 저장 프로덕션은 중단 없이 항상 실행이 중요하므로, 스팟이 아닌 온디맨드로 배치하는 것이 적절함.
AZ당 2대: AZ당 2대씩 두어, 한 인스턴스만 실패해도 같은 AZ 내 다른 인스턴스가 받쳐 주도록 함.
틀린 이유
A. 최소 2대, AZ당 1대씩이면 “최소 2대”와 “2 AZ”는 만족하지만, AZ당 1대라 한 인스턴스나 한 AZ만 문제여도 용량이 절반으로 줄어들어, “고가용성·내결함성” 관점에서는 B(4대, AZ당 2대) 가 더 적합함.
C. 한 가용 영역에만 4대 배치하면, 해당 AZ 장애 시 전부 불가해 다중 AZ 내결함성을 만족하지 못하고, 스팟은 프로덕션 상태 저장 앱의 “항상 실행” 요구에 맞지 않음.
D. 한 AZ는 온디맨드 2대, 다른 AZ는 스팟 2대면, 스팟 회수 시 해당 AZ 용량이 줄어들어 상태 저장 프로덕션의 “항상 2대 이상” 및 고가용성 요구를 안정적으로 충족하기 어려움.
Answer: A
요구사항
환경: Amazon Route 53 사용, 웹사이트 온프레미스 + AWS eu-central-1 호스팅
위치: 온프레미스 데이터 센터는 us-west-1 인근, AWS는 eu-central-1
목표: 웹사이트 로딩 시간을 최대한 짧게
A. 지리적 위치(Geolocation) 라우팅 정책 설정 – us-west-1 인근은 온프레미스, eu-central-1 인근은 eu-central-1로 전송
지리적 위치 라우팅: 사용자 지리적 위치(대륙/국가)에 따라 레코드를 나누어, us-west-1 인근(예: 북미) 트래픽은 온프레미스, eu-central-1 인근(예: 유럽) 트래픽은 eu-central-1로 보냄.
지연 최소화: 사용자를 가까운 엔드포인트로 보내서 왕복 지연을 줄이고, 그에 따라 로딩 시간을 줄일 수 있음.
명시적 분리: “us-west-1 근처 → 온프레미스, eu-central-1 근처 → eu-central-1”처럼 지역별로 목적지를 명확히 나누는 구성과 맞음.
틀린 이유
B. Simple 라우팅은 사용자 위치를 기준으로 라우팅하지 않음. “근처 트래픽을 각각 온프레미스/eu-central-1로 보낸다”는 동작을 구현하려면 Geolocation(A) 또는 Latency 정책이 필요함.
C. Latency(지연 시간) 라우팅도 로딩 시간 최소화에 적합하지만, 지문에서는 “정책을 us-west-1과만 연결”한다고 해서 eu-central-1이 정책에 포함된다고 보기 어렵고, 두 지역을 모두 명시적으로 다루는 것은 A(Geolocation)가 더 분명함.
D. 가중치 기반은 비율(예: 50:50)로만 나누므로, 사용자 위치와 무관하게 먼 쪽으로 갈 사용자가 생겨 로딩 시간 최소화 목표에는 맞지 않음.
Answer: C
요구사항
데이터: 물리 테이프에 5PB 아카이브
규정: 테이프 데이터 10년 추가 보존 필요
일정: 6개월 이내 AWS로 마이그레이션
네트워크: 데이터 센터 1Gbps 업링크만 존재
목표: 위를 가장 비용 효율적으로 만족
C. 테이프 게이트웨이 탑재 Snowball 다수 주문 → 물리 테이프를 Snowball 가상 테이프로 복사 → AWS 반송 → 수명 주기로 S3 Glacier Deep Archive 전환
5PB + 6개월: 5PB를 1Gbps로 올리면 이론상 1년 이상 걸려 6개월 내 전송 불가. Snowball으로 오프라인 이전하면 디바이스 수만 늘리면 6개월 내 완료 가능.
테이프 → Snowball: Snowball 테이프 게이트웨이로 물리 테이프를 Snowball 가상 테이프에 복사한 뒤, 디바이스를 AWS로 배송해 일괄 적재.
10년 보존·비용: 적재 후 수명 주기 정책으로 S3 Glacier Deep Archive로 이동하면 장기 아카이브 비용이 가장 낮아 비용 효율과 10년 보존을 동시에 만족함.
인터넷 미사용: 대용량이 네트워크를 타지 않아 1Gbps 제약을 받지 않음.
틀린 이유
A. DataSync는 인터넷으로 전송하므로 5PB를 1Gbps로 6개월 안에 올리는 것은 불가능에 가깝고, “6개월 내 마이그레이션” 요구를 충족하지 못함.
B. 온프레미스에서 S3 Glacier Deep Archive로 직접 쓰기도 인터넷 경유라 5PB를 6개월 안에 끝내기 어렵고, 동일한 제약이 있음.
D. 온프레미스 테이프 게이트웨이 + AWS 가상 테이프 구성은 데이터가 인터넷을 통해 전송되므로 5PB·6개월 조건을 만족하기 어렵고, 오프라인 이전인 C(Snowball) 가 맞음.
Answer: A
요구사항
환경: 대량 데이터를 병렬로 처리하는 애플리케이션, Amazon EC2 사용 예정
제약: 노드 그룹이 동일한 기본 하드웨어를 공유하지 않도록 네트워크(배치) 아키텍처 구성 필요
목표: 위를 만족하는 네트워킹(배치) 솔루션
A. EC2 인스턴스를 분산 배치 그룹(Spread Placement Group)에서 실행
Spread 배치 그룹: 그룹 내 각 인스턴스를 서로 다른 물리 하드웨어(서로 다른 랙, 필요 시 서로 다른 가용 영역)에 배치함.
동일 하드웨어 미공유: “노드 그룹이 동일한 기본 하드웨어를 공유하지 못하도록”이라는 요구를 배치 수준에서 충족함.
고장 분리: 한 랙/호스트 장애가 동시에 여러 노드에 영향을 주지 않아, 병렬 워크로드의 가용성·내결함성에 유리함.
네트워크·배치: 같은 VPC/서브넷을 쓰면서, 어디 물리 호스트에 올릴지를 제어하는 것은 배치 그룹(A)이 담당함.
틀린 이유
B. EC2를 별도 계정으로 나눠도, 어느 물리 호스트/랙에 배치되는지는 제어하지 않음. “동일 기본 하드웨어 미공유”는 Spread 배치 그룹(A) 으로 해결하는 영역임.
C. 전용 테넌시(Dedicated) 는 “다른 고객과 하드웨어를 공유하지 않음”을 의미하며, 우리 인스턴스끼리 서로 다른 하드웨어에 흩어지게 하는 기능은 아님. “노드 그룹이 동일 하드웨어를 공유하지 못하게”는 Spread 배치 그룹(A) 이 맞음.
D. 공유 테넌시(Shared) 는 기본값으로, “동일 하드웨어 미공유”를 보장하지 않으며, 배치 분산을 제어하지 않음.
Answer: D
요구사항
상황: 장애 조치(DR) 리전에서 Amazon EC2 용량을 확보하는 재해 복구(DR) 전략 설계
비즈니스 요구: DR 전략이 장애 조치 리전의 용량을 충족해야 함(필요 시 인스턴스를 반드시 띄울 수 있어야 함)
목표: 위를 만족하는 솔루션
D. 장애 조치 리전에서 용량 예약(Capacity Reservation) 구매
용량 예약: 특정 인스턴스 유형·AZ(또는 리전)에 대해 EC2 용량을 미리 예약해 두는 기능. 예약한 용량은 해당 계정이 사용할 때까지 보장됨.
DR 시 용량 보장: 재해 발생 시 장애 조치 리전에서 인스턴스를 띄울 때, “용량 부족” 으로 실행이 실패하지 않도록 필요 용량을 미리 확보할 수 있음.
비즈니스 요구 충족: “장애 조치 지역의 용량을 충족해야 한다”는 요구를 용량 보장으로 직접 만족함.
온디맨드와 연동: 용량 예약은 온디맨드 인스턴스 실행에 적용되며, 예약이 있으면 해당 용량에서 실행이 보장됨.
틀린 이유
A. 온디맨드만 사용하면, 재해 시 여러 고객이 동시에 장애 조치할 때 해당 리전에 용량이 없을 수 있음. “장애 조치 리전의 용량을 충족”한다는 보장을 주지 못함.
B. EC2 Savings Plan은 요금 할인을 위한 약정이며, 특정 용량을 예약하는 기능이 아님. 장애 조치 시 인스턴스 실행 가능 여부는 보장하지 않음.
C. 지역 예약 인스턴스(Regional RI) 는 요금 할인 + 리전 내 용량 우선권을 주지만, 특정 AZ/용량을 고객 전용으로 잡아 두는 것은 용량 예약(D) 이 담당함. DR에서 “용량을 반드시 충족”하려면 Capacity Reservation(D) 이 적합함.
Answer: B
요구사항
환경: AWS Organizations 조직에 OU 5개(비즈니스 5개, R&D 포함)
변경: R&D 사업이 분리되어 자체 조직 필요
진행: 이 목적으로 별도 새 관리(마스터) 계정 생성 완료
질문: 새 마스터 계정에서 다음에 수행할 작업
B. R&D AWS 계정이 기존 조직을 나온 뒤, 새 조직의 일원이 되도록 R&D AWS 계정을 초대
계정은 한 조직만 소속: AWS 계정은 동시에 두 조직에 속할 수 없음. R&D 계정을 새 조직으로 옮기려면 먼저 기존 조직을 나와야 함.
올바른 순서: 1) R&D 계정이 기존 조직을 떠남(기존 조직 마스터 또는 해당 계정에서 요청). 2) 새 마스터 계정에서 Organizations로 R&D 계정을 새 조직에 초대.
새 마스터에서 할 일: 새 마스터 계정에서 해야 할 “다음” 작업은, R&D 계정이 이전 조직을 나온 후에 해당 계정을 새 조직에 초대하는 것임.
리소스 유지: 기존 R&D 계정을 그대로 새 조직으로 옮기므로, 새 계정 생성·리소스 마이그레이션 없이 정리 가능함.
틀린 이유
A. 한 계정이 두 조직에 동시에 소속되는 것은 AWS Organizations에서 지원되지 않음. “전환 중 두 조직의 일부”로 두는 것은 불가능함.
C. 새 조직에 새 R&D 계정을 만들고 이전 계정의 리소스를 옮기는 방식은, 기존 R&D 계정을 그대로 새 조직으로 초대(B) 하는 것보다 단계가 많고 복잡함. “다음에 수행해야 할 것”은 기존 R&D 계정을 새 조직에 초대하는 B가 맞음.
D. 새 마스터 계정을 이전 조직의 구성원으로 두라는 것은 잘못된 방향임. 새 마스터는 새 조직의 루트이므로 이전 조직에 넣으면 안 되고, R&D 멤버 계정만 이전 조직을 나온 뒤 새 조직에 가입시키는 것이 맞음.
Answer: C
요구사항
목적: 여러 웹 애플리케이션에서 고객 활동을 수집해 분석·예측에 사용
트래픽: 고객 활동은 예측 어렵고 급증 가능
통합: 다양한 웹 애플리케이션과 연동 가능해야 함
보안: 인증(권한 부여) 단계 포함 필요
목표: 위를 모두 만족하는 솔루션
C. API Gateway 앞단 + Kinesis Data Firehose로 S3 저장, API Gateway Lambda 권한 부여자로 인증
다양한 웹 앱 연동: 여러 웹 앱이 동일 API Gateway 엔드포인트로 이벤트를 보내면 되므로, “다른 웹 애플리케이션과 통합” 요구를 충족함.
예측 불가·급증 대응: API Gateway와 Kinesis Data Firehose는 자동 확장되므로, 트래픽이 갑자기 늘어나도 수집·저장이 가능함.
수집·저장: Firehose가 스트리밍 데이터를 받아 버퍼링·배치 후 Amazon S3에 저장해, 이후 분석·예측 파이프라인에 사용하기 적합함.
인증: API Gateway Lambda 권한 부여자로 요청 시 토큰·헤더를 검증해 보안 목적의 인증 단계를 구현함.
틀린 이유
A. GWLB는 가상 어플라이언스로 트래픽을 보내는 용도이며, 웹 앱에서 “고객 활동 이벤트 수집” API로 쓰기엔 맞지 않음. “승인은 GWLB에서”도 API 수준 인증과는 다르고, EFS에 활동 저장하는 구조는 스트리밍 수집·분석 패턴과 맞지 않음.
B. Kinesis Data Streams는 실시간 스트림 처리용이며, “수신 정보를 S3에 저장”하는 관리형 전달에는 Kinesis Data Firehose(C) 가 더 적합함. 인증은 Lambda로 가능하지만, 수집·저장 아키텍처는 C(Firehose → S3) 가 요구사항에 더 잘 맞음.
D. GWLB + ECS + EFS는 API 기반 고객 활동 수집이 아니라 네트워크/파일 공유용 구조에 가깝고, “다양한 웹 앱과 통합·예측 불가 트래픽·S3 저장” 요구를 충족하기엔 C(API Gateway + Firehose → S3) 가 맞음.
Answer: D
요구사항
환경: Amazon RDS에서 Microsoft SQL Server Enterprise Edition 실행
목표: 재해 복구(DR) 솔루션
RPO·RTO: 24시간
제약: 위를 가장 비용 효율적으로 만족
D. 24시간마다 자동 스냅샷을 다른 리전으로 복사
RPO 24시간 충족: 24시간마다 자동 스냅샷을 다른 리전으로 복사하면, 최악의 경우 데이터 손실이 최근 복사 시점까지(최대 24시간)로 제한됨.
RTO 24시간 충족: 재해 시 DR 리전에서 복사된 스냅샷으로 RDS 인스턴스를 복원하면, 24시간 이내 복구 가능한 수준으로 설계 가능함.
비용 효율: RDS 자동 스냅샷은 기본 기능이고, 교차 리전 스냅샷 복사만 추가 비용(스냅샷 저장·복사). DMS·크로스 리전 읽기 복제본 없이 가장 비용 효율적임.
SQL Server RDS: RDS SQL Server는 크로스 리전 읽기 복제본을 지원하지 않으므로, DR은 스냅샷 복사(D) 가 표준 방식임.
틀린 이유
A. RDS SQL Server는 크로스 리전 읽기 전용 복제본을 지원하지 않음. “지역 간 읽기 전용 복제본 생성”은 MySQL/PostgreSQL 등에 해당하므로 이 요구사항에는 적용 불가함.
B. AWS DMS로 크로스 리전 복제를 하면 연속 복제로 RPO를 더 짧게 가져갈 수 있지만, RPO/RTO 24시간이면 DMS 비용(복제 인스턴스 등)이 과할 수 있음. 24시간 수준이면 스냅샷 복사(D) 가 더 비용 효율적임.
C. RDS 기본 백업을 S3로 복사하는 것은 RDS의 기본 DR 패턴이 아니고, “24시간마다 자동 스냅샷을 다른 리전으로 복사”(D)가 RDS DR의 표준·비용 효율적 방식임.
Answer: B
요구사항
환경: 고정 세션이 켜진 Application Load Balancer 뒤 Auto Scaling 그룹의 EC2에서 웹 앱 실행
현재: 웹 서버(EC2)가 사용자 세션 상태를 호스팅
목표: 웹 서버 중단 시에도 고가용성 확보 및 사용자 세션 상태 손실 방지
B. Amazon ElastiCache for Redis로 세션 상태 저장, 앱을 Redis 사용으로 변경
세션 외부화: 세션을 Redis에 두면, 어떤 EC2 인스턴스에서든 동일한 세션에 접근 가능. 인스턴스 교체·장애 시에도 세션 상태가 유지되어 손실을 방지할 수 있음.
고가용성: ElastiCache Redis는 복제(Replica) 구성으로 Primary 장애 시 Replica 승격이 가능하고, 다중 AZ로 배치하면 가용성이 높아짐.
저지연: Redis는 인메모리라 RDS보다 세션 읽기/쓰기 지연이 작아, 웹 앱 세션 저장에 적합함.
표준 패턴: ALB + ASG 환경에서 세션을 ElastiCache Redis로 옮기는 구성이 AWS에서 권장하는 방식임.
틀린 이유
A. Memcached는 지속성(Replication) 이 없어, 노드 장애 시 해당 노드의 세션 데이터가 사실상 손실됨. “세션 상태 손실 방지”와 “고가용성”에는 Redis(B) 의 복제 기반 HA가 맞음.
C. Storage Gateway 캐싱 볼륨은 온프레미스–클라우드 하이브리드 파일 스토리지용이며, 웹 앱 세션 상태 저장·고가용성 용도가 아님.
D. RDS로 세션을 저장할 수는 있으나, 지연 시간과 세션 I/O 처리량 측면에서 인메모리 Redis(B) 가 더 적합하고, 세션 저장에는 ElastiCache Redis가 일반적으로 권장됨.
Answer: A
요구사항
환경: 온프레미스 MySQL → Amazon RDS for MySQL 마이그레이션 완료
현재: 일일 평균 워크로드에 맞춰 RDS 인스턴스 크기 조정
문제: 한 달에 한 번 보고용 쿼리 실행 시 DB 성능 저하
목표: 보고서 실행과 일일 운영 워크로드 성능 유지를 동시에 만족
A. 읽기 전용 복제본 생성 후, 보고 쿼리를 읽기 전용 복제본으로 보냄
워크로드 분리: Primary = 일일 OLTP(쓰기·일반 읽기), 읽기 전용 복제본 = 보고용 쿼리만 처리. 보고 쿼리가 Primary를 덜 사용해 일일 작업 성능을 유지할 수 있음.
보고 실행 가능: 보고 쿼리를 복제본 엔드포인트로 보내면, 복제본에서만 무거운 쿼리가 돌아 보고서 실행 요구를 충족함.
데이터 일치: 복제본은 Primary와 비동기 복제로 최신에 가까운 데이터를 가지므로, 월간 보고에 적합한 수준의 최신성 확보 가능.
표준 패턴: RDS에서 “보고·분석은 복제본, OLTP는 Primary”로 나누는 일반적인 방식임.
틀린 이유
B. 백업을 다른 DB 인스턴스로 복원해 쿼리하면, 그 인스턴스는 특정 시점 스냅샷이라 실시간에 가까운 데이터가 아니고, 정기 복원·관리 부담이 큼. “보고 실행 + 일일 성능 유지”에는 읽기 전용 복제본(A) 이 더 적합함.
C. S3로 내보내고 Athena로 쿼리하는 방식은 정기 내보내기·스키마 관리가 필요하고, RDS와 실시간에 가까운 보고를 하려면 읽기 전용 복제본(A) 이 더 단순하고 적합함.
D. 인스턴스만 키우면 보고 쿼리와 일일 워크로드가 같은 인스턴스를 쓰므로, 보고 실행 시 리소스 경합으로 일일 성능 저하는 완전히 피하기 어렵고, 월 1회 부하를 위해 24시간 큰 인스턴스를 쓰는 것은 비효율적임. 복제본(A) 으로 보고 부하를 분리하는 것이 맞음.
Answer: D
요구사항
환경: Amazon EKS에서 컨테이너 애플리케이션 실행
구성: 고객 관리·주문 등 마이크로서비스 포함
필요: 들어오는 요청을 적절한 마이크로서비스로 라우팅
목표: 위를 가장 비용 효율적으로 만족
D. Amazon API Gateway로 요청을 받아 Amazon EKS로 연결
경로·메서드 기반 라우팅: API Gateway에서 경로(예: /customers, /orders)나 메서드별로 다른 백엔드를 지정할 수 있어, 요청을 해당 마이크로서비스로 보낼 수 있음.
EKS 연동: VPC Link + EKS 앞단 NLB(또는 ALB)로 Private 통합을 만들면, API Gateway가 EKS 내 마이크로서비스로 요청을 전달함.
비용 효율: 요청당 과금이고, 라우팅·스로틀링·인증을 API Gateway가 담당해, 별도 프록시/라우터를 두는 것보다 관리형 단일 진입점으로 비용·운영을 줄일 수 있음.
관리형: 인증, 캐싱, 스테이지 등 API 관리 기능을 그대로 활용 가능함.
틀린 이유
A. Network Load Balancer는 4계층이라 경로·호스트 기반 라우팅을 하지 않음. “어떤 요청을 어떤 마이크로서비스로 보낼지”를 NLB만으로 구분할 수 없어, “적절한 마이크로서비스로 라우팅” 요구를 충족하지 못함.
B. ALB + Load Balancer Controller로 Ingress에서 경로별 라우팅은 가능하지만, 외부 API 진입점·라우팅 정책을 API Gateway(D) 로 두는 편이 관리·과금 측면에서 “가장 비용 효율적”인 선택으로 볼 수 있음. 문제에서 정답은 D(API Gateway).
C. Lambda를 앞단에 두고 EKS로 프록시하면 Lambda 콜드 스타트·추가 구성이 생기고, “들어오는 요청을 적절한 마이크로서비스로 라우팅”을 가장 비용 효율적으로 하려면 API Gateway(D) 가 더 적합함.
Answer: D
요구사항
환경: AWS로 저작권 이미지에 대한 접근 권한 판매
성능: 글로벌 고객이 이미지에 빠르게 접근해야 함
제한: 특정 국가 사용자 접근 차단 필요
목표: 위를 가능한 한 비용 최소로 만족
D. S3에 이미지 저장, CloudFront로 배포·지리적 제한 적용, 고객에게 서명된 URL 제공
빠른 글로벌 접근: CloudFront가 엣지에서 이미지를 제공해, 전 세계 고객이 짧은 지연으로 접근할 수 있음.
특정 국가 차단: CloudFront 지리적 제한(Geo Restriction) 으로 허용 목록 또는 차단 목록을 설정해, 특정 국가 사용자 접근을 거부할 수 있음.
접근 제어: 서명된 URL을 구매 고객에게만 발급해, 저작권 이미지에 대한 유료 접근을 제어할 수 있음.
비용 최소: S3 저장 + CloudFront 전송만 사용하고, EC2·ALB를 두지 않아 관리형·비용 효율 구조임.
틀린 이유
A. 퍼블릭 버킷 + MFA는 “특정 국가 차단”을 구현하지 않고, 링크를 가진 누구나 접근할 수 있어 유료 접근 제어와 국가 제한 요구를 충족하지 못함.
B. 고객당 IAM 사용자는 계정당 사용자 수 제한·관리 부담이 커서 확장·비용 측면에서 불리하고, 글로벌 빠른 접근(CDN) 과 국가별 제한도 이 방식만으로는 해결하기 어려움.
C. EC2 + ALB를 국가별로 두면 인스턴스·리전 비용이 커서 “비용 최소”에 맞지 않고, 글로벌 배포·국가 제한은 CloudFront(D) 가 더 적합함.
Answer: A
요구사항
환경: Amazon ElastiCache for Redis 기반 고가용 솔루션 설계
제약: 장애로 인해 로컬 및 리전 내에서 성능 저하·데이터 손실이 없어야 함
목표: 노드 수준과 리전(가용 영역) 수준 모두에서 고가용성 제공
A. 여러 노드가 포함된 샤드가 있는 다중 AZ Redis 복제 그룹 사용
다중 AZ: 복제 그룹을 다중 AZ로 구성하면 Primary는 한 AZ, Replica는 다른 AZ에 두어, 한 AZ 장애 시에도 다른 AZ의 Replica로 장애 조치 가능 → 리전(가용 영역) 수준 고가용성.
샤드당 여러 노드: 각 샤드에 Primary + Replica 등 여러 노드를 두면, 노드 장애 시 해당 샤드 내 Replica로 장애 조치되어 노드 수준 고가용성과 데이터 손실·성능 저하 완화 가능.
복제 그룹: Redis 복제로 데이터가 Replica에 유지되므로, 노드/AZ 장애 시에도 데이터 손실을 줄일 수 있음.
요구사항 정합: “노드 수준 + 리전 수준 고가용성”과 “로컬·리전 내 장애 시 성능 저하·데이터 손실 방지”를 다중 AZ + 샤드당 복제로 충족함.
틀린 이유
B. AOF(Append Only File) 는 영속성(디스크 복구) 용도이며, 노드 장애 시 즉시 장애 조치를 주는 것은 복제(Replica). “다중 AZ”도 언급되지 않아 리전 수준 고가용성을 명시적으로 만족하지 못함.
C. 다중 AZ Redis 클러스터에 읽기 전용 복제본 2개 이상을 두는 구성도 노드·리전 수준 HA를 줄 수 있으나, 문제에서 정답은 A(여러 노드가 포함된 샤드가 있는 다중 AZ 복제 그룹)로, 샤드 구조 + 다중 AZ를 강조한 A가 정답으로 제시됨.
D. Auto Scaling 은 노드/샤드 수 조정용이며, 장애 시 장애 조치·데이터 보호를 보장하는 것은 복제 + 다중 AZ(A). 노드·리전 수준 고가용성 요구를 충족하지 못함.
Answer: C
요구사항
환경: AWS 마이그레이션, 애플리케이션은 Amazon EC2 온디맨드 사용 예정
문제: 마이그레이션 테스트에서 애플리케이션이 메모리에 올라가고 준비되기까지 시간이 오래 걸림
목표: 다음 테스트 단계에서 애플리케이션 실행 시간을 줄이는 솔루션
C. 최대 절전 모드(Hibernation)를 켠 EC2 온디맨드 인스턴스로 시작, 다음 테스트를 위해 EC2 Auto Scaling 웜 풀 구성
최대 절전 모드(Hibernation): 인스턴스를 중지할 때 메모리 상태를 EBS에 저장하고, 다시 시작할 때 그 상태에서 재개함. 따라서 애플리케이션이 이미 메모리에 올라가 있던 상태에서 재개되어, 실행·로딩 시간이 짧아짐.
웜 풀(Warm Pool): Auto Scaling 웜 풀에 미리 준비된 인스턴스(Stopped 또는 Running)를 두면, 다음 테스트 시 새 인스턴스를 냉기동하는 대신 웜 풀 인스턴스를 사용해 시작·준비 시간이 줄어듦.
다음 테스트 단계: 웜 풀 인스턴스를 최대 절전 모드로 중지해 두었다가 테스트 전에 재개하면, 애플리케이션이 이미 로드된 상태에 가깝게 실행 시간이 단축됨.
온디맨드 유지: 온디맨드 인스턴스를 그대로 사용하면서, 준비·실행 시간만 줄이는 구성임.
틀린 이유
A. 온디맨드 인스턴스를 더 두고 Auto Scaling만 켜도, 새로 기동되는 인스턴스는 여전히 냉기동 + 앱 로딩이 필요해 “실행 시간 단축”을 직접 해결하지 못함.
B. 스팟 인스턴스는 중단 가능성이 있어 “다음 테스트 단계에서 사용할 수 있도록” 유지하기에 불안정하고, 앱 로딩 시간 단축도 스팟 자체로는 해결되지 않음.
D. 용량 예약은 인스턴스 기동 가능 용량만 보장할 뿐, 인스턴스·애플리케이션을 미리 준비하는 기능이 아니라, “실행 시간 단축”에는 최대 절전 모드 + 웜 풀(C) 이 맞음.
Answer: C
요구사항
환경: Auto Scaling 그룹의 Amazon EC2에서 애플리케이션 실행
트래픽: 일주일 중 임의의 요일에 갑작스런 트래픽 증가 발생
목표: 갑작스런 트래픽 증가 시에도 애플리케이션 성능 유지
제약: 위를 가장 비용 효율적으로 만족
C. 동적 스케일링(Dynamic Scaling)으로 Auto Scaling 그룹 크기 조정
동적 스케일링: 실시간 메트릭(CPU 사용률, 요청 수 등)에 따라 Auto Scaling이 인스턴스를 늘리거나 줄임. 트래픽이 갑자기 늘면 메트릭이 올라가 자동으로 인스턴스가 추가되어 성능을 유지할 수 있음.
예측 불가·임의의 요일: “어느 요일에 증가할지”를 알 수 없으므로 일정 기반 스케일링(D) 은 맞지 않고, 실제 부하에 반응하는 동적 스케일링(C) 이 적합함.
비용 효율: 트래픽이 실제로 늘어날 때만 인스턴스를 늘리므로, 스파이크가 없는 날에는 용량을 덜 두어 비용을 줄일 수 있음.
예측 조정 대비: 예측 조정(B)은 패턴이 있을 때 유리하고, “임의의 요일”에는 예측이 어려우며 과다 프로비저닝 가능성이 있어, 동적 스케일링(C) 이 더 비용 효율적임.
틀린 이유
A. 수동 스케일링은 사람이 직접 용량을 바꾸는 방식이라, 갑작스런 트래픽에 즉시 대응하기 어렵고, “가장 비용 효율적”인 자동 대응이 아님.
B. 예측 조정은 과거 패턴으로 미리 스케일하는 방식인데, 임의의 요일에 발생하는 트래픽에는 패턴이 불명확해 예측이 어렵고, 잘못 예측하면 과다·과소 프로비저닝으로 비용·성능이 나빠질 수 있어 동적 스케일링(C) 이 더 적합함.
D. 일정 조정은 고정된 시간에만 스케일하므로, 어느 요일에 올지 모르는 갑작스런 트래픽에는 맞지 않고, “임의의 요일” 요구를 충족하지 못함.
Answer: A
요구사항
환경: 전자상거래 앱, Amazon EC2에서 PostgreSQL DB 운영
문제: 월간 판매 이벤트 시 DB 사용량 증가 → DB 연결 문제 발생
트래픽: 이후 월간 이벤트 트래픽은 예측 불가
목표: 예측 불가한 트래픽 증가 시에도 성능 유지
제약: 위를 가장 비용 효율적으로 해결
A. PostgreSQL DB를 Amazon Aurora Serverless v2로 마이그레이션
자동 용량 조정: Aurora Serverless v2는 ACU(용량 단위) 가 부하에 따라 자동으로 늘었다 줄었다 하므로, 월간 이벤트 시 트래픽 증가에 맞춰 용량이 늘어 연결·성능을 유지할 수 있음.
예측 불가 트래픽 대응: “어느 달·어느 정도로 늘어날지”를 몰라도 실제 부하에 반응해 스케일하므로, 고정 용량 대비 성능 유지에 유리함.
비용 효율: 이벤트가 없는 기간에는 자동으로 축소되어, 24시간 큰 인스턴스를 두는 것보다 비용 효율적임.
PostgreSQL 호환: Aurora PostgreSQL 호환이므로 애플리케이션 변경을 최소화한 채 마이그레이션 가능함.
틀린 이유
B. EC2 위 PostgreSQL에 대한 “자동 크기 조정”은 AWS 기본 기능이 아니고, 인스턴스 리사이즈는 보통 재시작이 필요해 실시간 스케일이 어렵고, “가장 비용 효과적”인 관리형 자동 스케일에는 Aurora Serverless v2(A) 가 맞음.
C. 더 큰 인스턴스 유형으로 RDS를 쓰면 고정 용량이라, 예측 불가한 트래픽에는 과다 프로비저닝(비용 증가) 또는 과소 프로비저닝(이벤트 시 연결·성능 문제 지속)이 되기 쉽고, “가장 비용 효과적”이 아님.
D. Amazon Redshift는 데이터 워허우스(분석·OLAP) 용이며, 전자상거래 트랜잭션(OLTP) 용 PostgreSQL 대체가 아님. 이 문제 해결 방법이 아님.
Answer: B
요구사항
환경: Amazon API Gateway + AWS Lambda로 내부 서버리스 애플리케이션 호스팅
문제: 직원이 매일 앱을 사용하기 시작할 때 대기 시간이 길다고 보고
목표: 대기 시간을 줄이는 솔루션
B. 직원이 매일 앱을 사용하기 전에 Lambda 프로비저닝된 동시성을 높이도록 예약된 조정(스케줄 스케일링) 설정
원인: 매일 처음 사용할 때 Lambda가 콜드 상태라 콜드 스타트로 첫 요청이 느려짐.
프로비저닝된 동시성: 미리 실행 환경을 준비해 두면, 요청 시 콜드 스타트 없이 실행되어 대기 시간이 짧아짐.
예약된 조정: 출근 전 시간(예: 오전 8시)에 프로비저닝된 동시성을 늘리는 스케줄을 두면, 직원이 앱을 켤 때 이미 웜 상태라 대기 시간이 줄어듦.
비용: 사용 시작 전에만 늘리고, 사용이 줄는 시간에 다시 낮추는 스케줄을 두면 비용을 줄일 수 있음.
틀린 이유
A. API Gateway 스로틀 한도를 올려도 요청 허용 개수만 늘어날 뿐, 첫 요청의 지연(콜드 스타트) 는 해결되지 않음.
C. CloudWatch 알람은 조건 충족 시 알림·액션을 트리거하는 용도이며, “매일 시작 시 Lambda를 미리 웜업”하는 프로비저닝된 동시성 예약 조정(B) 과는 다름. 콜드 스타트 감소에는 B가 맞음.
D. Lambda 메모리를 늘리면 실행 중 처리 속도는 빨라질 수 있으나, 콜드 스타트(실행 환경 초기화) 시간은 그대로라, “매일 시작할 때 느리다”는 문제를 직접 해결하지 못함. 프로비저닝된 동시성(B) 이 적합함.
Answer: A, C, F
요구사항
환경: 연구 회사, 온프레미스 장치가 분석용 데이터 생성
데이터: .csv 생성, SMB 파일 공유에 쓰기
목표: AWS에서 데이터 분석, 분석가는 SQL로 쿼리
사용: 분석가가 하루 종일 주기적으로 쿼리 실행
제약: 위를 가장 비용 효율적으로 만족하는 3단계 조합
A. 온프레미스에 Amazon S3용 File Gateway 모드로 AWS Storage Gateway 배포
SMB → S3: Storage Gateway File Gateway는 NFS/SMB 공유를 제공하고, 여기에 쓰인 파일을 Amazon S3에 저장함.
온프레미스 연동: 장치가 .csv를 SMB 공유에 쓰면, File Gateway가 해당 파일을 S3로 전달해, 온프레미스 데이터가 S3에 쌓이도록 함.
비용 효율: 전용 ETL·스크립트 없이 관리형 게이트웨이만으로 SMB → S3를 구성할 수 있음.
C. S3 데이터로 테이블을 만들도록 AWS Glue 크롤러 설정
메타데이터·테이블: Glue Crawler가 S3의 .csv 등을 스캔해 스키마를 추론하고 Glue Data Catalog에 테이블을 생성함.
SQL 연동: Athena(및 Redshift Spectrum 등)가 이 카탈로그 테이블을 사용해 S3 데이터를 SQL로 쿼리할 수 있음.
비용 효율: 크롤러만 설정하면 되고, 별도 ETL·수동 DDL 없이 테이블 정의를 자동화할 수 있음.
F. S3 데이터를 SQL로 쿼리하도록 Amazon Athena 설정, 분석가에게 접근 제공
SQL on S3: Athena는 S3에 있는 데이터를 표준 SQL로 쿼리하는 서버리스 서비스로, 쿼리당 과금(스캔한 데이터량 기준)임.
주기적 쿼리에 적합: “하루 종일 주기적으로 쿼리”하는 패턴에 맞고, 클러스터 상시 운영이 필요 없어 비용 효율적임.
Glue 연동: C에서 만든 Glue Data Catalog 테이블을 Athena가 사용하므로, A → S3, C → 카탈로그, F → 쿼리 조합이 됨.
틀린 이유
B. “Amazon FSx File Gateway”는 AWS 제품명이 아님. SMB 쓰기를 받아 S3로 보내는 것은 Storage Gateway File Gateway(A) 이고, FSx는 별도 파일 시스템 서비스임.
D. EMR + EMRFS로 S3를 쿼리할 수는 있으나, 클러스터를 띄우거나 유지해야 해서 “주기적 SQL 쿼리”만 할 때는 Athena(F) 보다 비용·운영 부담이 큼.
E. Redshift로 S3 데이터를 쿼리하려면 Redshift Spectrum을 쓰게 되고, 클러스터(또는 서버리스) 비용이 발생함. S3 중심·주기적 쿼리만 필요할 때는 Athena(F) 가 더 비용 효율적임.
Answer: A, C, D (E)
요구사항
환경: Amazon ECS + Amazon RDS로 결제 처리 애플리케이션, 규정 준수로 온프레미스에서 실행
구성: AWS Outposts를 솔루션의 일부로 사용, 운영 팀과 협력하여 구축
질문: 회사 운영팀이 담당하는 활동 3개 선택
A. Outposts 랙에 탄력적인 전원 및 네트워크 연결 제공
공유 책임: Outposts 랙은 고객 데이터 센터에 설치되며, 전원·네트워크는 고객(회사) 이 제공합니다.
운영팀 역할: 이중 전원·이중 링크 등 탄력적인 전원 및 네트워크 연결을 설계·유지·점검하는 것은 회사 운영팀 책임입니다.
C. 데이터 센터 환경의 물리적 보안 및 액세스 제어
공유 책임: Outposts가 놓인 데이터 센터의 물리적 보안(출입 통제, CCTV, 구역 제한 등)과 액세스 제어는 고객(회사) 책임입니다.
운영팀 역할: 출입 정책, 권한 관리, 보안 점검 등 물리적 보안 및 액세스 제어를 수행하는 것은 회사 운영팀 역할입니다.
D. 전원 공급 장치·서버·네트워킹 장비를 포함한 Outposts 인프라의 가용성
공유 책임: 랙 내부 하드웨어(전원 공급 장치, 서버, 네트워킹 장비)가 동작할 수 있는 환경(전원·냉각·공간·연결)을 만드는 것은 고객 책임입니다.
운영팀 역할: 전원·냉각·배선·랙 공간 등 인프라 가용성을 보장하는 설비·운영은 회사 운영팀이 담당합니다. (랙 내부 장비 교체·수리는 AWS 측 책임인 경우가 많음.)
틀린 이유
B. Outposts에서 동작하는 가상화 하이퍼바이저, 스토리지 시스템, AWS 서비스는 AWS가 관리합니다. 회사 운영팀이 “관리”하는 활동이 아닙니다.
E. Outposts 구성 요소의 물리적 유지 보수(예: 고장 난 서버/디스크 교체)는 보통 AWS가 수행하고, 고객은 시설 유지(전원·냉각·출입 지원) 정도를 담당합니다. “구성 요소 물리적 유지 보수”만 보면 AWS 책임에 가깝습니다.
F. “서버 오류 및 유지 보수 이벤트를 완화하기 위해 ECS 클러스터에 추가 용량 제공”은 애플리케이션/용량 설계(Auto Scaling, 태스크 수 조정 등)에 가깝고, Outposts 공유 책임에서 말하는 “회사 운영팀이 담당하는 활동”과는 보통 구분됩니다. 그래서 3개 선택에서는 제외하는 경우가 많습니다.
정리:
A(전원·네트워크), C(물리적 보안·액세스 제어), D(인프라 가용성) 는 AWS 문서에서 고객(운영팀) 책임으로 자주 나오는 항목입니다.
시험 정답이 A, C, E 로 되어 있다면, 그 시험에서는 “물리적 유지 보수(E)”를 고객 책임으로 본 것이므로, 그에 맞춰 A, C, E 로 외우시면 됩니다.
Answer: A
요구사항
환경: TCP 기반 애플리케이션을 회사 VPC로 마이그레이션 예정
현재: 데이터 센터 하드웨어 어플라이언스를 통해 비표준 TCP 포트로 퍼블릭 접근
성능: 짧은 대기 시간, 초당 최대 300만 요청 처리
목표: AWS의 새 퍼블릭 엔드포인트가 동일한 수준의 성능을 제공하도록 함
A. NLB(Network Load Balancer) 배포, 애플리케이션에 필요한 TCP 포트로 퍼블릭 액세스 구성
4계층(TCP): NLB는 Layer 4(TCP/UDP) 로, 비표준 TCP 포트를 그대로 사용할 수 있어 TCP 기반 앱에 적합함.
고성능: NLB는 초당 수백만 연결·저지연에 맞게 설계되어, “초당 최대 300만 요청·짧은 대기 시간” 요구를 충족할 수 있음.
퍼블릭 엔드포인트: NLB를 퍼블릭 서브넷에 두고 퍼블릭 IP를 부여하면, 온프레미스와 같은 형태의 퍼블릭 TCP 엔드포인트를 제공할 수 있음.
표준 패턴: TCP·고성능·퍼블릭 엔드포인트에는 NLB가 AWS에서 권장하는 선택임.
틀린 이유
B. ALB는 7계층(HTTP/HTTPS) 용이라, 임의의 TCP 포트나 비 HTTP TCP 트래픽에는 맞지 않음. TCP 기반·비표준 포트 요구를 충족하지 못함.
C. CloudFront는 HTTP/HTTPS(80, 443) 용 CDN이라, 임의의 TCP 포트를 리스닝하는 구성이 아니며, TCP 기반 퍼블릭 엔드포인트에는 NLB(A) 가 맞음.
D. API Gateway는 HTTP API용이라 원시 TCP나 비표준 TCP 포트를 지원하지 않음. TCP 기반 앱의 퍼블릭 엔드포인트에는 NLB(A) 가 적합함.
'자격증' 카테고리의 다른 글
| AWS SAA-C03 Dump 601-650 (0) | 2026.02.03 |
|---|---|
| AWS SAA-C03 Dump 501-550 (0) | 2026.02.02 |
| 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 |
