연습 문제

문제 1

한 의료 기관이 Amazon RDS MySQL 데이터베이스와 함께 Amazon EC2 인스턴스에서 환자 관리 시스템을 실행하고 있습니다. 애플리케이션은 현재 각 EC2 인스턴스의 구성 파일에 저장된 하드코딩된 자격 증명을 사용하여 데이터베이스에 연결합니다. 이 기관은 여러 가용 영역에 걸쳐 15개의 EC2 인스턴스를 보유하고 있으며 HIPAA 보안 요구 사항을 준수해야 합니다. 보안 팀은 하드코딩된 데이터베이스 자격 증명을 제거하고 자격 증명 관리의 관리 부담을 줄이는 동시에 민감한 환자 데이터에 대한 안전한 액세스를 보장하고자 합니다. 솔루션 아키텍트는 이러한 보안 및 운영 요구 사항을 충족하기 위해 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 특히 규제 대상 워크로드(HIPAA)에 대한 데이터베이스 자격 증명의 안전한 보안 암호 저장 및 수명 주기 관리를 테스트합니다. 핵심 AWS 서비스는 보안 암호를 저장하고 자동으로 교체하도록 특별히 제작된 AWS Secrets Manager입니다. 정답인 이유: AWS Secrets Manager는 보안 암호를 중앙 집중화하고 애플리케이션(또는 부트스트랩 스크립트/사이드카)이 IAM 권한을 사용하여 런타임에 자격 증명을 검색할 수 있도록 함으로써 15개의 EC2 인스턴스에서 하드코딩된 자격 증명을 제거합니다. Amazon RDS MySQL 데이터베이스의 경우 Secrets Manager는 AWS 관리형 교체 Lambda 템플릿을 사용하여 기본 통합 및 자동 교체를 지원합니다. 이는 관리 부담(인스턴스 전반에 걸친 수동 암호 변경 없음)을 줄이고 주기적인 교체를 강제하며 자격 증명 스프롤을 최소화하여 보안 태세를 개선합니다. 이는 HIPAA의 액세스 제어 및 감사 기대치에 중요합니다. 주요 AWS 기능 / 모범 사례: - 자동 교체: RDS 암호와 저장된 보안 암호를 원자적으로 업데이트하는 교체 Lambda를 사용하여 교체(예: 30일마다)를 구성합니다. - 세분화된 액세스 제어: EC2 인스턴스에서 IAM 역할을 사용하여 특정 보안 암호에 대해서만 secretsmanager:GetSecretValue를 허용합니다. 파일을 통해 자격 증명을 배포하지 마십시오. - 암호화 및 감사: 보안 암호는 AWS KMS로 암호화되며 액세스는 AWS CloudTrail에 기록되어 규정 준수 증거를 지원합니다. - 다중 AZ EC2 플릿: 모든 인스턴스는 AZ 간에 파일을 복사하지 않고도 동일한 보안 암호를 안전하게 검색할 수 있습니다. 일반적인 오해: Parameter Store(SecureString)는 암호화된 값을 저장할 수 있지만 Secrets Manager만큼 RDS 자격 증명에 대한 최고 수준의 관리형 보안 암호 교체 워크플로를 제공하지는 않습니다. S3/EBS 암호화는 저장 데이터를 보호하지만 보안 암호 배포, 교체 조정 또는 최소 권한 런타임 검색을 해결하지는 않습니다. 시험 팁: "하드코딩된 자격 증명 제거"와 "관리 부담 감소" 및 "교체"가 보이면 기본적으로 Secrets Manager(특히 RDS의 경우)를 선택하십시오. 교체가 주요 요구 사항이 아닐 때 구성 값과 더 간단한 보안 암호에는 Parameter Store를 사용하십시오. 규정 준수 시나리오의 경우 IAM 최소 권한, KMS 암호화 및 CloudTrail 감사를 지원 제어로 고려하십시오.

문제 2

한 의료 기관이 여러 부서에 걸쳐 다수의 Amazon S3 버킷에 환자 의료 기록과 진단 이미지를 저장합니다. 이 기관은 HIPAA 규정을 준수하고 엄격한 감사 추적을 유지해야 합니다. 규정 준수 팀은 버킷 정책, ACL, 암호화 설정 및 퍼블릭 액세스 구성에 대한 변경을 포함하여 S3 버킷 구성에 대한 무단 수정을 감지하기 위해 지속적인 모니터링을 요구합니다. 솔루션은 자동화된 규정 준수 확인 및 과거 구성 추적을 제공해야 합니다. S3 버킷 구성 변경을 지속적으로 모니터링하고 규정 준수를 보장하기 위해 솔루션 아키텍트는 무엇을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 지속적인 구성 모니터링, compliance 평가, 그리고 리소스 구성의 이력 추적을 위한 AWS Config를 다룹니다. 특히 Amazon S3 bucket의 보안 상태(policies, ACLs, encryption, public access settings)에 초점을 맞춥니다. 이러한 기능은 HIPAA의 auditability 요구 사항 및 AWS Well-Architected Security Pillar의 governance, detective controls, traceability와 강하게 부합합니다. 정답인 이유: AWS Config는 지원되는 리소스(예: S3 buckets)의 구성 변경 사항을 지속적으로 기록하고 configuration history를 유지합니다. 또한 이러한 구성을 compliance rules(AWS managed rules 및 custom rules)와 비교하여 평가하고 noncompliance를 보고할 수 있습니다. “unauthorized modifications를 탐지하기 위한 continuous monitoring”과 “automated compliance checking 및 historical configuration tracking” 요구 사항에 대해 AWS Config는 이러한 목적에 맞게 설계된 서비스입니다. 구성 drift를 탐지하고, 변경 시각을 기록하며, 무엇이/누가 변경했는지(API activity context를 위한 CloudTrail integration을 통해) 보여주고, 감사용으로 configuration states의 timeline을 제공합니다. 주요 AWS 기능: 1) Configuration recorder + delivery channel: S3 bucket configuration items를 기록하고 snapshots/history를 S3 bucket으로 전달합니다. 2) AWS Config Rules: S3 bucket public read/write 금지, server-side encryption 활성화, public access block settings 확인과 같은 managed rules를 사용할 수 있습니다. 또한 조직별 HIPAA controls를 위해 custom rules(Lambda 또는 Guard)를 추가할 수 있습니다. 3) Conformance Packs: 여러 rules와 remediation guidance를 패키징하여 부서/계정 전반에서 일관된 compliance를 제공합니다. 4) Aggregators (optional): 여러 accounts/regions 전반의 compliance 가시성을 중앙 집중화합니다. 5) Remediation (optional): Systems Manager Automation을 사용하여 noncompliant buckets를 자동 remediation할 수 있습니다. 흔한 오해: Trusted Advisor는 best-practice checks를 제공하지만, 특정 bucket configuration changes에 대한 지속적인 configuration history/audit trail 시스템은 아닙니다. Amazon Inspector는 vulnerability management(EC2, ECR, Lambda)에 초점을 맞추며 S3 bucket configuration drift를 평가하지 않습니다. S3 server access logging과 EventBridge는 data-plane access 및 일부 events 탐지에 도움을 줄 수 있지만, 여러 configuration dimensions에 걸친 포괄적이고 queryable한 configuration history와 compliance evaluation을 제공하지는 않습니다. 시험 팁: AWS 리소스 설정에 대해 “continuous compliance”, “configuration drift”, “historical configuration tracking”, “audit trails”가 보이면 AWS Config를 떠올리세요(대개 CloudTrail과 함께 사용). S3 security posture(public access, encryption, policies/ACLs)의 경우 AWS Config Rules와 Conformance Packs가 대표적인 시험 정답입니다.

문제 3

한 의료 분석 회사가 API를 통해 15개의 서로 다른 Electronic Health Record (EHR) 시스템에서 환자 데이터를 수집합니다. 현재 이 회사는 단일 Amazon EC2 인스턴스(m5.large)를 사용하여 30분마다 각 EHR 시스템에서 데이터를 가져오고, 데이터를 처리하며, 규정 준수 보고를 위해 Amazon S3 버킷에 저장하고, 업로드가 완료되면 규정 준수 팀에 이메일 알림을 보냅니다. 이 회사는 피크 시간대에 시간당 약 2GB의 데이터를 처리하며, 현재 EC2 인스턴스의 CPU 사용률이 85-90%에 달해 데이터 처리 및 알림 전송에 지연이 발생하고 있습니다. 회사는 운영 복잡성과 관리 오버헤드를 최소화하면서 성능을 향상시키고자 합니다. 최소한의 운영 오버헤드(가장 적은 operational overhead)로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 운영 오버헤드를 최소화하면서 처리량과 안정성을 향상시키기 위해 관리형 통합 및 이벤트 서비스를 선택하는 것을 테스트합니다. 주요 서비스는 Amazon AppFlow(서버 없는 SaaS/API 데이터 수집) 및 Amazon SNS와 결합된 Amazon S3 event notifications(분리된 관리형 알림)입니다. 정답인 이유: 병목 현상은 15개의 API 폴링, 처리 및 알림이라는 세 가지 작업을 수행하는 단일 EC2 인스턴스입니다. 컴퓨팅 확장(Auto Scaling/ECS)은 성능을 향상시킬 수 있지만 운영 책임(용량 계획, 패치 적용, 조정 정책, 컨테이너 수명 주기)을 증가시킵니다. Amazon AppFlow는 각 EHR API 소스에서 Amazon S3로 관리형 flows를 생성하여 EC2에서 데이터 추출/전송을 완전히 오프로드합니다. 이는 CPU 바운드 폴링 워크로드를 제거하고 움직이는 부분을 줄입니다. 객체가 S3에 도착하면 S3 event notifications가 SNS topic에 게시하여 (SNS 이메일 구독을 통해) 규정 준수 팀에 이메일을 보낼 수 있으므로 사용자 지정 코드 없이 거의 실시간으로 완료 알림을 제공합니다. 주요 AWS 기능: - Amazon AppFlow: 완전 관리형 flows, 일정 예약, 증분 전송(지원되는 경우), 전송 중/미사용 시 암호화, S3로의 직접 전송. - Amazon S3 event notifications: ObjectCreated 이벤트에서 트리거하고 SNS에 게시. - Amazon SNS: 구독을 통한 팬아웃 및 이메일 전송; S3 이벤트와 깔끔하게 통합됨. 이 설계는 관리형 서비스를 사용하고 차별화되지 않은 과중한 작업(undifferentiated heavy lifting)을 줄임으로써 Well-Architected Framework(운영 우수성 및 성능 효율성)와 일치합니다. 일반적인 오해: CPU가 높기 때문에 Auto Scaling(A)을 선택하기 쉽지만, 이는 회사가 서버를 실행하고 확장하는 비즈니스를 계속 유지하게 하며 여전히 인스턴스 간의 폴링 조정이 필요합니다. EventBridge(C)는 이벤트 라우팅에 탁월하지만 사용자 지정 생산자(custom producers) 없이 임의의 외부 EHR API에서 "데이터 이벤트를 캡처"하지 않습니다. API를 호출하려면 여전히 컴퓨팅/통합이 필요합니다. ECS(D)는 확장성을 향상시키지만 컨테이너 운영을 추가하고 폴링/수집 복잡성을 제거하지 않습니다. 시험 팁: 질문에서 "최소한의 운영 오버헤드(LEAST operational overhead)"를 강조할 때 EC2/ECS보다 완전 관리형 수집/통합 서비스(AppFlow, Step Functions, Lambda, SQS)를 선호하십시오. 또한 "S3 업로드 시 알림"의 경우 표준 패턴은 사용자 지정 폴링이나 모니터링이 아닌 S3 Event Notifications -> SNS (또는 SQS/Lambda)입니다.

문제 4

한 생명공학 연구 회사가 AWS Cloud에서 게놈 시퀀싱 분석을 위한 고성능 컴퓨팅(HPC) 솔루션을 개발하고 있습니다. 연구 팀은 높은 처리량(throughput)과 짧은 지연 시간(low latency)으로 대규모 컴퓨팅 워크로드를 처리할 수 있는 병렬 파일 시스템(parallel file system)이 필요합니다. 회사는 HPC 워크로드를 위해 POSIX 호환 병렬 파일 시스템 클라이언트를 사용할 수 있는 기능이 필요합니다. 이 솔루션은 완전 관리형이어야 하며 최대 100TB의 데이터 세트를 처리하는 컴퓨팅 집약적 애플리케이션에 최적화되어야 합니다. 이러한 요구 사항을 충족하는 솔 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 POSIX 호환 병렬 파일 시스템 클라이언트가 필요한 고성능 컴퓨팅(HPC)을 위해 올바른 완전 관리형 공유 스토리지를 선택하는 것을 테스트합니다. AWS에서 목적에 맞게 구축된 관리형 병렬 파일 시스템은 Amazon FSx for Lustre입니다. 정답인 이유: Amazon FSx for Lustre는 많은 컴퓨팅 노드에서 병렬 액세스를 통해 매우 높은 처리량과 짧은 지연 시간이 필요한 컴퓨팅 집약적 워크로드(게놈, 시뮬레이션, 렌더링, ML 기능 생성)를 위해 설계되었습니다. POSIX 호환 파일 시스템을 제공하고 기본 Lustre 클라이언트를 사용하여 마운트되므로 클러스터 전체에서 진정한 병렬 I/O가 가능합니다. AWS에서 완전히 관리하며(프로비저닝, 패치 적용, 모니터링, 실패한 구성 요소 교체) 명시된 ~100TB 범위를 포함하여 대규모 데이터 세트로의 확장을 지원합니다. 주요 AWS 기능: FSx for Lustre는 짧은 지연 시간, 높은 IOPS 워크로드 및 파일 시스템 크기에 따라 확장되는 높은 총 처리량을 위해 SSD 스토리지를 제공합니다. 내구성 있는 데이터 레이크를 위해 Amazon S3(가져오기/내보내기)와 통합되는 동시에 Lustre를 고성능 스크래치/작업 계층으로 사용합니다. 동일한 파일 시스템을 마운트하는 많은 EC2 인스턴스(또는 AWS Batch / ParallelCluster), 높은 메타데이터 성능 및 병렬 읽기/쓰기와 같은 일반적인 HPC 패턴을 지원합니다. 이는 AWS Well-Architected 성능 효율성 원칙과 일치합니다: 워크로드에 최적화된 관리형 목적별 서비스를 사용하십시오. 일반적인 오해: EFS는 POSIX이고 공유되지만 병렬 파일 시스템이 아닌 NFS 파일 시스템입니다. 일반적으로 대규모 HPC 병렬 I/O에 대한 Lustre의 처리량/지연 시간 특성과 일치하지 않습니다. S3는 객체 스토리지이며 POSIX가 아닙니다. s3fs를 통한 마운트는 의미론적 및 성능적 한계가 있는 해결 방법입니다. Storage Gateway Volume Gateway는 하이브리드 온프레미스 통합 및 iSCSI 블록 볼륨을 위한 것이지 많은 컴퓨팅 노드를 위한 병렬 공유 파일 시스템이 아닙니다. 시험 팁: "HPC", "병렬 파일 시스템(parallel file system)", "Lustre 클라이언트", "높은 처리량/짧은 지연 시간" 또는 "게놈 시퀀싱 분석"이 보이면 기본적으로 FSx for Lustre를 선택하십시오. 일반적인 공유 POSIX NFS 사용 사례(웹 서비스, 홈 디렉터리)에는 EFS를 선택하고 객체 스토리지/데이터 레이크에는 S3를 선택하십시오. S3를 기본 POSIX 병렬 파일 시스템으로 사용하지 마십시오.

문제 5

한 의료 회사가 중요한 환자 기록과 병력 데이터를 저장하기 위해 Amazon DynamoDB를 사용하는 환자 관리 시스템을 운영하고 있습니다. 이 시스템은 해당 지역의 여러 의료 시설에서 실시간 업데이트되는 약 50,000개의 환자 기록을 처리합니다. 엄격한 의료 규정 준수 요구 사항과 환자 데이터의 중요한 특성으로 인해, 솔루션 아키텍트는 최대 데이터 손실 15분(RPO) 및 1시간 이내의 시스템 복원(RTO)으로 데이터 손상 시나리오를 처리할 수 있는 재해 복구 솔루션을 설계해야 합니다. 이러한 엄격한 백업 및 복구 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

개요: 핵심 개념: 이 질문은 실패 모드가 논리적 손상(잘못된 쓰기, 우발적인 삭제, 애플리케이션 버그)이고 요구 사항이 RPO 15분 및 RTO 1시간일 때 재해 복구를 위한 DynamoDB 백업/복원 전략을 테스트합니다. 정답인 이유: DynamoDB 특정 시점 복구(PITR)는 변경 사항을 지속적으로 기록하고 지난 35일 이내의 어느 초로든 테이블을 복원할 수 있게 해줍니다. 손상 시나리오에서 아키텍트는 손상이 발생하기 직전의 타임스탬프로 테이블을 복원하여 15분의 RPO를 충족할 수 있습니다(PITR은 초 단위이므로 일반적으로 훨씬 더 우수함). 복원 시 새 테이블이 생성되며, 애플리케이션 구성을 업데이트(또는 블루/그린 접근 방식 사용)하여 이를 교체함으로써 50,000개 항목 테이블에 대해 1시간의 RTO 내에 복원할 수 있습니다. 주요 AWS 기능: - DynamoDB PITR: 지속적인 백업, 보존 기간(최대 35일) 내의 어느 초로든 복원. - 복원 동작: PITR은 새 테이블로 복원합니다. 그런 다음 읽기/쓰기를 복원된 테이블로 리디렉션합니다. - 운영 모범 사례: 컷오버를 자동화하고(예: 코드형 인프라 및 구성 관리를 통해) 주기적인 DR 테스트로 검증합니다. - 보완 통제: IAM 최소 권한 및 조건부 쓰기를 사용하여 손상 위험을 줄이지만, 복구 메커니즘은 PITR입니다. 일반적인 오해: 글로벌 테이블(옵션 A)은 가용성과 리전 복원력을 향상시키지만, 손상도 복제합니다(잘못된 데이터가 모든 리전에 빠르게 복사됨). 따라서 글로벌 테이블 자체만으로는 논리적 손상 복구를 해결할 수 없습니다. Glacier Deep Archive 내보내기(옵션 C)는 너무 빈도가 낮고 검색 속도가 느려 1시간 RTO를 충족할 수 없습니다. EBS 스냅샷(옵션 D)은 DynamoDB가 관리형 서비스이므로 기본 스토리지 볼륨을 스냅샷할 수 없기 때문에 적용할 수 없습니다. 시험 팁: DynamoDB와 함께 "데이터 손상" 또는 "우발적 삭제"를 보면 가장 먼저 PITR을 생각하십시오. "리전 중단"을 보면 글로벌 테이블이나 다중 리전 전략을 생각하십시오. 항상 요구 사항을 명시적으로 매핑하십시오: 엄격한 RPO 및 빠른 논리적 복원을 위해서는 PITR을 사용하고, Glacier Deep Archive와 같은 아카이브 계층은 빠른 복구가 아닌 장기 보존을 위한 것입니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

금융 서비스 회사가 트랜잭션 데이터를 처리하기 위해 4시간마다 AWS Batch를 사용하여 자동화된 사기 탐지 분석을 실행합니다. 이 회사는 사기 탐지 작업이 성공적으로 완료되면 외부 규정 준수 모니터링 시스템에 자동으로 알림을 보내는 serverless 솔루션이 필요합니다. 외부 규정 준수 시스템에는 Bearer token 형식의 API key 인증이 필요한 REST API 엔드포인트가 있습니다. 이 솔루션은 완전한 serverless여야 하며 비용 효율적이어야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 AWS의 이벤트 기반 serverless 통합 패턴을 테스트합니다. 특히 Amazon EventBridge를 사용하여 서버를 관리하지 않고 AWS Batch 상태 변경에 반응하고 외부 REST 엔드포인트를 호출하는 방법을 다룹니다. 또한 관리형 인증 및 비용 최적화 아키텍처를 사용한 안전한 아웃바운드 API 호출에 대해서도 다룹니다. 정답인 이유: AWS Batch는 작업 상태 변경 이벤트(SUCCEEDED 포함)를 Amazon EventBridge로 내보냅니다. EventBridge rule은 특정 작업 대기열/작업 정의에 대한 SUCCEEDED 이벤트와 일치시켜 target으로 라우팅할 수 있습니다. EventBridge API Destinations는 API key 기반 인증 지원 및 Connection을 통한 Bearer token 형식의 Authorization 헤더 추가를 포함하여 EventBridge에서 직접 외부 HTTP 엔드포인트를 호출할 수 있는 완전 관리형 방법을 제공합니다. 이를 통해 Lambda 또는 API Gateway가 필요하지 않으므로 솔루션을 완전한 serverless로 유지하고 일반적으로 비용과 운영 오버헤드를 낮출 수 있습니다. 주요 AWS 기능: 1) AWS Batch 작업 상태 변경(detail.status = "SUCCEEDED")에 대한 이벤트 패턴 매칭이 있는 EventBridge Rule. 2) 자격 증명(API key)을 안전하게 저장하고 아웃바운드 요청에 적용하는 EventBridge Connection. 3) EventBridge에서 관리하는 스로틀링 제어 및 재시도 동작이 있는 target으로서의 API Destination. 4) 최소 권한 IAM: EventBridge는 API destination을 호출하기 위해 role을 수임합니다. secret은 코드에 포함되지 않습니다. 일반적인 오해: 많은 응시자가 "무언가 발생할 때 API 호출"을 위해 기본적으로 Lambda를 선택합니다. 유효한 방법이긴 하지만 코드, 런타임 관리 및 호출/기간당 추가 비용이 발생합니다. 또 다른 오해는 아웃바운드 호출의 중개자로 API Gateway를 사용하는 것입니다. API Gateway는 주로 클라이언트에게 API를 노출하기 위한 것이지, AWS Batch 이벤트를 직접 수신하거나 알림 메커니즘으로 아웃바운드 호출을 프록시하기 위한 것이 아닙니다. 시험 팁: "AWS 이벤트 발생 시 외부 SaaS/REST 엔드포인트에 알림" 및 "완전한 serverless/비용 효율적"이라는 문구를 보면 먼저 EventBridge + API Destinations를 고려하십시오. 변환, 복잡한 로직 또는 사용자 지정 서명이 필요한 경우에만 Lambda를 사용하십시오. 또한 EventBridge는 Batch 작업 수명 주기 이벤트를 포함하여 많은 AWS 서비스 상태 변경을 위한 기본 event bus라는 점을 기억하십시오.

문제 7

성장 중인 온라인 게임 플랫폼 'GameHub'는 단일 Amazon EC2 인스턴스에서 실행되는 애플리케이션과 동일한 인스턴스에 MySQL 데이터베이스를 보유하고 있습니다. 이 플랫폼은 빠른 트래픽 성장을 겪고 있으며 증가된 사용자 로드를 처리할 솔루션이 필요합니다. 회사는 고가용성을 갖추고 애플리케이션 및 데이터베이스 계층 모두에서 증가된 트래픽을 처리하기 위해 자동으로 확장(scale)할 수 있는 솔루션이 필요합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 애플리케이션 계층을 데이터베이스 계층에서 분리하고 관리형 서비스를 사용하여 고가용성 및 자동 확장 아키텍처를 설계하는 것을 테스트합니다. 주요 서비스: 상태 비저장 웹/앱 확장을 위한 EC2 Auto Scaling + Application Load Balancer(ALB), 데이터베이스 고가용성 및 용량 확장을 위한 Aurora Serverless v2(MySQL 호환). 정답인 이유: 옵션 A는 두 계층 모두에 대해 자동 확장을 제공합니다. 애플리케이션 계층은 ALB 뒤의 Auto Scaling 그룹에 여러 EC2 인스턴스를 배치하여 수평으로 확장 가능해집니다. 이는 빠른 트래픽 성장을 지원하고 여러 가용 영역(Availability Zones)에 걸쳐 가용성을 향상시킵니다. 데이터베이스의 경우 Aurora Serverless(MySQL)는 로드에 따라 데이터베이스 용량을 자동으로 조정하도록 설계되어 인스턴스 크기 조정의 운영 부담을 줄입니다. Aurora는 또한 분산형 내결함성 스토리지를 통해 Multi-AZ 복원력을 제공하고 빠른 장애 조치를 지원하여 "고가용성" 요구 사항을 충족합니다. 주요 AWS 기능 / 모범 사례: - ALB + Auto Scaling 그룹: 상태 확인, 교차 AZ 로드 밸런싱, 조정 정책(CPU/RequestCount에 대한 대상 추적) 및 비정상 인스턴스 교체를 통한 자가 치유. - Aurora Serverless(v2): 세분화된 증분으로 용량을 확장하고, Multi-AZ를 지원하며, MySQL 드라이버와 호환됩니다. 확장 이벤트 중 연결 풀링을 관리하기 위해 RDS Proxy(종종 짝을 이룸)를 사용합니다. - 아키텍처 모범 사례: 인스턴스가 안전하게 확장/축소될 수 있도록 앱 계층을 상태 비저장으로 유지합니다(ElastiCache/DynamoDB의 세션, S3/EFS의 공유 자산). 일반적인 오해: 일반적인 함정은 "다중 인스턴스가 있는 RDS"가 쓰기를 위한 확장 가능한 클러스터를 자동으로 의미한다고 가정하는 것입니다(일반적으로 읽기 전용 복제본을 의미함). 또 다른 오해는 ElastiCache를 데이터베이스 대체품으로 취급하는 것입니다. 이는 캐시일 뿐 내구성 있는 기록 시스템이 아닙니다. Redshift는 OLTP가 아닌 분석용입니다. 시험 팁: 요구 사항에 데이터베이스에 대해 "자동으로 확장"이라고 명시되어 있으면 표준 RDS Multi-AZ보다는 Aurora Serverless(또는 기타 자동 확장 데이터베이스 패턴)를 찾으십시오. 또한 "고가용성 + 확장 가능한 애플리케이션"의 경우 기본 시험 패턴은 여러 AZ에 걸친 ALB + Auto Scaling입니다. 선택한 데이터베이스가 캐싱(ElastiCache)이나 웨어하우징(Redshift)이 아닌 트랜잭션 MySQL 워크로드(Aurora/RDS)에 적합한지 확인하십시오.

문제 8

한 핀테크 스타트업이 50,000명의 활성 사용자를 보유한 모바일 뱅킹 애플리케이션을 AWS에서 운영하고 있습니다. 이 애플리케이션은 고객 인증 및 자격 증명 관리를 위해 Amazon Cognito를 사용합니다. 고객이 계정 정보에 액세스할 때 모바일 앱은 Amazon API Gateway에서 호스팅되는 REST API를 호출하여 Amazon DynamoDB에서 트랜잭션 데이터를 검색합니다. 이 스타트업은 매월 20%의 빠른 사용자 증가를 경험하고 있습니다. 이 회사는 증가하는 사용자 기반을 효율적으로 처리하면서 개발 복잡성과 운영 부담을 최소화하는 안전한 API 액세스 제어를 위한 AWS 관리형 솔루션이 필요합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 Amazon Cognito와 통합된 Amazon API Gateway를 사용한 관리형 API 액세스 제어를 테스트합니다. 핵심 아이디어는 인증 토큰 검증 및 요청 권한 부여를 AWS 관리형 서비스(Cognito user pools + API Gateway 권한 부여자)로 오프로드하여 사용자 지정 코드와 운영 오버헤드를 최소화하는 것입니다. 정답인 이유: API Gateway에 Amazon Cognito user pool 권한 부여자를 구성(D)하면 API Gateway가 각 요청에 대해 Cognito user pool에서 발급한 JSON Web Tokens(JWT)를 자동으로 검증할 수 있습니다. 이는 사용자 지정 Lambda 권한 부여자 코드를 제거하고, 구성 요소를 줄이며, 사용자 증가(매월 20%)에 맞춰 기본적으로 확장되므로 운영 부담이 가장 적은 접근 방식입니다. 50,000명의 활성 사용자와 빠른 성장이 있는 상황에서 권한 부여를 위한 요청당 Lambda 호출을 피하면 운영 부담, 지연 시간 변동성 및 확장 문제를 줄일 수 있습니다. 주요 AWS 기능: API Gateway Cognito user pool 권한 부여자는 JWT 서명, 발급자, 대상(client ID) 및 토큰 만료를 검증합니다. JWT의 OAuth 범위 및 클레임을 사용하여 세분화된 액세스 제어(예: 라우팅/메서드 수준 권한 부여)를 적용할 수 있습니다. API Gateway는 권한 부여자 결과를 캐시(해당하는 경우)하여 반복적인 검증 오버헤드를 줄일 수 있습니다. 이는 관리형 자격 증명 서비스 사용, 최소 권한 구현, 인증 중앙 집중화라는 AWS Well-Architected 보안 원칙 지침과 일치합니다. 일반적인 오해: 사용자 지정 Lambda 권한 부여자(A)는 유연해 보일 수 있지만 코드 유지 관리, 모니터링, 콜드 스타트, 동시성 계획 및 성장 시 잠재적인 스로틀링을 추가합니다. API key(B)는 최종 사용자를 위한 인증 메커니즘이 아닙니다. 주로 측정/스로틀링을 위한 것이며 모바일 앱에서 잘못 처리되기 쉽습니다. 헤더에 계좌 번호를 전달하는 것(C)은 안전한 인증/권한 부여가 아닙니다. 이는 사용자가 제공한 데이터이며 강력한 토큰 기반 검증 없이는 스푸핑될 수 있습니다. 시험 팁: "인증을 위한 Cognito" + "API Gateway" + "최소한의 운영 오버헤드"를 볼 때 기본적으로 가장 좋은 답은 일반적으로 Cognito user pool 권한 부여자(또는 기계 간 통신을 위한 IAM 인증)입니다. 비 JWT 자격 증명 공급자, 복잡한 외부 정책 확인 또는 사용자 지정 토큰 형식이 필요한 경우에만 Lambda 권한 부여자를 선택하십시오. 또한 API key는 고객 자격 증명이 아니라 사용량 계획(usage plans)을 위한 것임을 기억하십시오.

문제 9

한 미디어 스트리밍 회사가 machine learning 파이프라인에서 생성된 비디오 분석 보고서를 저장해야 합니다. 이 보고서는 매일 두 번 자동으로 생성되며 마케팅, 콘텐츠 전략 및 임원진을 포함한 여러 부서에서 액세스할 수 있도록 Amazon S3에 업로드됩니다. 각 보고서 파일의 크기는 1.5 GB에서 4 GB 사이입니다. 여러 부서에서 하루나 일주일 중 다양한 시간에 보고서를 필요로 할 수 있으므로 액세스 패턴은 매우 예측 불가능합니다. 모든 보고서는 검색 지연 없이 즉시 액세스할 수 있어야 하며, 규정 준수 목적으로 정확히 90일 동안 보존되어야 합니다. 이 회사는 즉각적인 액세스 기능을 유지하면서 가장 비용 효율적인 스토리지 솔루션을 필요로 합니다. 이러한 요구 사항을 충족하기 위해 회사는 어떤 S3 스토리지 클래스를 구현해야 합니까?

문제 분석

핵심 개념: 이 질문은 엄격한 보존 요구 사항과 즉각적인(밀리초) 액세스라는 강력한 제약 조건 하에서 예측 불가능한 액세스 패턴에 대한 비용 최적화를 위한 Amazon S3 스토리지 클래스 선택을 테스트합니다. 또한 최소 스토리지 기간 요금 및 검색(retrieval) 요금에 대한 이해도 암시적으로 테스트합니다. 정답인 이유: S3 Intelligent-Tiering은 즉각적인 액세스가 필요하면서도 액세스 패턴을 알 수 없거나 변경되는 데이터를 위해 설계되었습니다. 객체는 관찰된 액세스를 기반으로 성능 저하나 비 아카이브 계층에 대한 검색 지연 없이 액세스 계층(Frequent Access 및 Infrequent Access, 선택적으로 Archive Instant/Archive/Deep Archive 계층) 간에 자동으로 이동됩니다. 부서에서 보고서에 예측 불가능하게 액세스할 수 있으므로, Intelligent-Tiering은 자주 액세스하는 객체를 해당 패턴에 최적화된 계층에 유지하면서 거의 액세스하지 않는 객체에 대해 불필요한 S3 Standard 요금을 지불할 위험을 방지합니다. 주요 AWS 기능: Intelligent-Tiering은 S3의 모니터링 및 자동화를 사용하여 자동 계층화를 제공하며, 객체당 소액의 모니터링 요금을 청구합니다. Frequent 및 Infrequent 계층(활성화된 경우 Archive Instant Access 포함)에 대해 밀리초 단위의 액세스를 제공하며, 액세스를 예측하기 어려울 때 수명 주기(lifecycle) 튜닝의 운영 오버헤드를 방지합니다. 90일 규정 준수 요구 사항의 경우, S3 Lifecycle 만료 규칙을 사용하여 정확히 90일째에 객체를 삭제할 수 있으며, '정확히 90일'이 불변성(immutability)을 의미하는 경우 선택적으로 S3 Object Lock(governance/compliance 모드)을 사용할 수 있습니다. 일반적인 오해: S3 Standard-IA와 Glacier Instant Retrieval은 모두 즉각적인 액세스를 제공하므로 정답처럼 보일 수 있습니다. 그러나 Standard-IA는 액세스가 드물다는 것을 알고 있을 때 가장 적합합니다. 예측 불가능한 액세스는 더 높은 검색 요금과 GB당 검색 요금을 초래할 수 있습니다. Glacier Instant Retrieval은 거의 액세스하지 않는 아카이브 데이터를 위한 것이며 최소 스토리지 기간 요금(일반적으로 90일)과 검색 비용이 있습니다. 액세스 빈도가 불확실하고 중간 정도일 수 있는 경우에는 이상적이지 않습니다. 시험 팁: '예측 불가능한 액세스(unpredictable access)' + '즉시 액세스 가능해야 함(must be immediately accessible)'을 보면 Intelligent-Tiering이 주요 후보입니다. 빈번한 액세스가 예상될 때만 Standard를 선택하십시오. 액세스가 드물다고 확신하고 검색 요금을 감수할 수 있을 때 Standard-IA를 선택하십시오. Glacier 클래스는 아카이브 패턴을 위한 것입니다. 검색 지연이 허용되는지 확인하고 최소 스토리지 기간 제약 조건을 주의하십시오.

문제 10

한 금융 서비스 회사가 Amazon RDS for MySQL을 사용하여 미션 크리티컬 고객 트랜잭션 처리 시스템을 운영하고 있습니다. 이 데이터베이스는 피크 시간대에 분당 약 15,000건의 트랜잭션을 처리하며 20억 달러 이상의 자산 가치를 지닌 고객 계정 정보를 유지 관리합니다. 성능 요구 사항이 증가하고 더 나은 확장성이 필요해짐에 따라, 이 회사는 Amazon Aurora MySQL로 마이그레이션하고자 합니다. 마이그레이션은 데이터 손실이 전혀 없어야 하고, 다운타임을 5분 미만으로 최소화해야 하며, 데이터베이스 관리 팀의 운영 노력을 최소화해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 최소한의 운영 노력으로 Amazon RDS for MySQL에서 Amazon Aurora MySQL로 다운타임이 적은 마이그레이션을 수행하는 방법을 테스트합니다. 핵심 개념은 기존 RDS for MySQL 인스턴스에서 Aurora read replica를 생성하는 Aurora의 기능(MySQL binlog 기반 복제)을 사용한 다음 이를 승격시켜 컷오버(cutover)하는 것입니다. 정답인 이유: 기존 RDS for MySQL 인스턴스의 Aurora read replica를 생성하면 소스에서 Aurora로 거의 실시간 복제가 가능합니다. 복제 지연(replication lag)이 최소화되면 회사는 제어된 컷오버를 수행할 수 있습니다. 쓰기를 잠시 중지(또는 애플리케이션을 일시 중지)하고 복제본이 따라잡을 때까지 기다린 다음 Aurora replica를 기본 라이터(primary writer)로 승격시킵니다. 이 접근 방식은 거의 제로에 가까운 데이터 손실(완전히 따라잡았을 때 RPO ~ 0)을 달성할 수 있으며, 다운타임은 일반적으로 DNS/엔드포인트/애플리케이션 구성 변경으로 제한되어 종종 5분 미만의 요구 사항을 충족합니다. 운영 측면에서 이는 대부분 AWS에서 관리하며 별도의 마이그레이션 복제 스택을 구축하고 운영할 필요가 없습니다. 주요 AWS 기능: Aurora MySQL은 RDS for MySQL 소스에서 Aurora read replica 생성을 지원합니다(호환되는 MySQL 버전, binary logging 활성화 및 적절한 파라미터 설정 필요). 승격(Promotion)은 복제본을 독립 실행형 Aurora cluster로 변환하는 관리형 작업입니다. Aurora cluster endpoints(writer endpoint)를 사용하면 컷오버 후 연결이 간소화됩니다. 이는 수동 단계와 지속적인 관리를 줄임으로써 Well-Architected의 운영 우수성(operational excellence)과 일치합니다. 일반적인 오해: 많은 사람들이 AWS DMS가 최소 다운타임을 위해 항상 최선이라고 가정합니다. DMS는 강력하지만 추가 구성 요소(replication instance 크기 조정, task 튜닝, 모니터링, 오류 처리) 및 운영 오버헤드를 발생시킵니다. Snapshot 및 dump/import 접근 방식은 더 간단해 보일 수 있지만 일반적으로 다운타임을 증가시키고 마지막 순간의 쓰기를 놓칠 위험이 있습니다. 시험 팁: 엄격한 다운타임 및 최소 운영 요구 사항이 있는 RDS MySQL에서 Aurora MySQL로의 마이그레이션의 경우, 먼저 'RDS에서 Aurora read replica 생성' 및 '승격(promote)' 패턴을 찾으십시오. 이기종 마이그레이션, 복잡한 변환 또는 지원되지 않는 기본 복제 경로가 필요한 경우 DMS를 선택하십시오. 항상 요구 사항을 RPO/RTO에 매핑하십시오. 복제 + 승격은 DMS보다 적은 이동 요소로 낮은 RPO 및 낮은 RTO를 목표로 합니다.

Practice Test #5

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #6

Practice Test #7

Practice Test #8

Practice Test #9

Practice Test #10

지금 학습 시작하기