CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
AWS Certified Solutions Architecture - Associate (SAA-C03)
AWS Certified Solutions Architecture - Associate (SAA-C03)

Practice Test #5

65개 문제와 130분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

65문제130분720/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

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

정답입니다. AWS Secrets Manager는 보안 암호를 저장하고 관리하도록 설계되었으며 관리형 교체 Lambda 템플릿을 사용하여 Amazon RDS MySQL에 대한 자동 교체를 지원합니다. EC2 인스턴스는 IAM 역할을 사용하여 런타임에 보안 암호를 검색하므로 하드코딩된 자격 증명을 제거하고 운영 오버헤드를 줄입니다. 보안 암호는 KMS로 암호화되고 액세스는 CloudTrail을 통해 감사 가능하므로 HIPAA 보안 기대치와 잘 맞습니다.

오답입니다. Systems Manager Parameter Store SecureString은 암호화된 스토리지 및 IAM 제어 액세스를 제공하지만 Secrets Manager에 비해 대규모 자동화된 데이터베이스 자격 증명 교체에는 가장 적합하지 않습니다. 사용자 지정 자동화로 교체를 엔지니어링할 수 있지만 운영 부담과 복잡성이 증가합니다. RDS 자격 증명 교체 및 규정 준수와 관련된 시험 시나리오의 경우 일반적으로 Secrets Manager가 의도된 서비스입니다.

오답입니다. 암호화된 자격 증명 파일을 S3에 저장하는 것은 여전히 자격 증명 아티팩트를 배포하고 관리하는 데 의존하며 RDS와 강력하고 통합된 교체 메커니즘을 제공하지 않습니다. 또한 잘못된 구성(버킷 정책, 객체 ACL)의 위험을 증가시키고 최소 권한 액세스 패턴을 복잡하게 만듭니다. S3 암호화는 보안 암호 수명 주기 관리 및 교체가 아니라 저장 데이터를 다룹니다.

오답입니다. EBS 볼륨을 암호화하면 각 인스턴스의 저장된 자격 증명을 보호하지만 자격 증명은 로컬에 저장된 상태로 유지되며 15개 인스턴스 전체에서 교체해야 하므로 관리 부담과 불일치 위험이 증가합니다. 사용자 지정 Lambda 교체 스크립트는 복잡성을 더하며 RDS와의 원자적 교체 및 모든 인스턴스로의 즉각적인 전파를 본질적으로 보장하지 않습니다. 이는 권장되는 AWS 기본 접근 방식이 아닙니다.

문제 분석

핵심 개념: 이 질문은 특히 규제 대상 워크로드(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
문제 2

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

AWS Config는 S3 bucket configuration changes를 지속적으로 기록하고 이를 compliance rules와 비교하여 평가하므로 올바른 서비스입니다. encryption, public access restrictions, bucket policy posture와 같은 controls에 대해 managed rules와 custom rules를 지원하므로 compliance 요구 사항과 직접적으로 일치합니다. 또한 historical configuration states를 유지하므로 audit trails 및 조사에 필수적입니다. 변경을 수행한 주체를 식별하기 위해 AWS Config는 일반적으로 CloudTrail과 함께 사용되지만, configuration monitoring 및 compliance를 위한 핵심 서비스는 AWS Config입니다.

AWS Trusted Advisor는 security, cost optimization, performance, fault tolerance, service limits와 같은 범주 전반에 걸쳐 best-practice recommendations를 제공합니다. 일부 위험한 S3 settings를 강조할 수는 있지만, 모든 bucket configuration change를 지속적으로 기록하거나 그러한 변경의 상세한 historical timeline을 유지하지는 않습니다. 또한 리소스 구성에 대한 rule-based compliance evaluation을 위한 주요 AWS 서비스도 아닙니다. 따라서 HIPAA 스타일 감사에 필요한 continuous monitoring 및 historical configuration tracking 요구 사항을 충족할 수 없습니다.

Amazon Inspector는 EC2 instances, Amazon ECR의 container images, 일부 Lambda functions와 같은 워크로드에 대해 software vulnerabilities 및 의도하지 않은 network exposure를 평가하는 vulnerability management 서비스입니다. bucket policies, ACLs, encryption configuration, public access block status와 같은 S3 bucket configuration settings는 모니터링하지 않습니다. 또한 S3 리소스에 대한 configuration history도 제공하지 않습니다. 따라서 S3 bucket configurations의 continuous compliance monitoring에는 적합하지 않습니다.

S3 server access logging은 S3 objects 및 buckets에 대해 이루어진 requests를 캡처하므로 access patterns 및 data-plane activity 분석에 유용합니다. EventBridge는 특정 API calls가 발생할 때 events를 라우팅하고 notifications 또는 automation을 트리거할 수 있지만, 그 자체로는 정규화된 configuration history를 유지하거나 리소스를 compliance rules와 비교하여 평가하지는 않습니다. 이 조합은 변경이 발생했다는 사실을 탐지하는 데는 도움이 될 수 있지만, 문제에서 요구하는 전체 compliance framework를 제공하지는 않습니다. automated compliance checking 및 historical configuration tracking 요구 사항은 AWS Config를 가리킵니다.

문제 분석

핵심 개념: 이 문제는 지속적인 구성 모니터링, 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
문제 3

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

Auto Scaling은 EC2 인스턴스를 추가하여 CPU 압박을 줄일 수 있으며, SNS로의 S3 event notifications는 견고한 알림 패턴입니다. 그러나 운영 오버헤드는 여전히 높습니다. AMI/패치 적용, 조정 정책, 중복 폴링을 방지하기 위한 인스턴스 조정, 30분마다 15개의 API 풀링을 위한 공유 상태를 관리해야 합니다. 성능은 향상되지만 관리형 수집 서비스에 비해 관리 오버헤드를 최소화하지는 못합니다.

Amazon AppFlow는 최소한의 코드와 인프라로 외부/SaaS 시스템에서 S3와 같은 AWS 대상으로 관리형 데이터 전송을 수행하도록 특별히 구축되었습니다. EHR 시스템별로 flows를 생성하면 EC2에서 폴링/수집 워크로드를 오프로드하여 최소한의 운영 부담으로 CPU 병목 현상을 직접 해결할 수 있습니다. 그런 다음 SNS로의 S3 event notifications는 업로드가 완료될 때 규정 준수 팀에 이메일을 보내는 이벤트 기반의 관리형 방법을 제공합니다.

EventBridge는 AWS 서비스 및 지원되는 SaaS 파트너의 이벤트를 라우팅하는 데 탁월하지만, 이벤트를 생성하는 무언가(사용자 지정 코드, 파트너 통합 또는 API 대상 패턴) 없이는 임의의 EHR API에서 본질적으로 "데이터 이벤트를 캡처"할 수 없습니다. 각 EHR API를 호출하고 S3에 데이터를 넣으려면 여전히 폴링/수집 구성 요소가 필요합니다. 이는 복잡성을 증가시키고 컴퓨팅 병목 현상을 직접 해결하지 못합니다.

auto-scaling이 있는 ECS는 단일 EC2 인스턴스보다 더 높은 처리량을 처리할 수 있으며 EC2의 펫(pets) 방식보다 더 나은 배포 기본 요소를 제공합니다. 그러나 컨테이너 빌드/배포 파이프라인, 작업 정의(task definitions), 조정 정책 및 지속적인 운영 관리를 도입합니다. 또한 사용자가 관리하는 컴퓨팅에서 실행되는 동일한 기본 접근 방식(폴링, 처리, 업로드, 알림)을 유지하므로 AppFlow와 같은 완전 관리형 수집 서비스보다 오버헤드가 높습니다.

문제 분석

핵심 개념: 이 질문은 운영 오버헤드를 최소화하면서 처리량과 안정성을 향상시키기 위해 관리형 통합 및 이벤트 서비스를 선택하는 것을 테스트합니다. 주요 서비스는 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
문제 4

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

DataSync 및 S3 Transfer Acceleration은 POSIX 호환 병렬 파일 시스템을 제공하는 것이 아니라 S3로의 데이터 이동을 처리합니다. s3fs로 S3를 마운트하는 것은 기본 POSIX 병렬 파일 시스템과 동일하지 않습니다(다른 일관성/잠금 의미 체계, 메타데이터 동작 및 일반적으로 HPC I/O 패턴에 대한 낮은 성능). 이 옵션은 컴퓨팅 노드를 위한 짧은 지연 시간의 병렬 공유 스토리지가 아니라 전송에 중점을 둡니다.

Storage Gateway Volume Gateway (stored volumes)는 온프레미스 애플리케이션이 iSCSI를 통해 클라우드 지원 블록 스토리지에 액세스하는 하이브리드 아키텍처를 위한 것입니다. 많은 EC2 인스턴스에 공유 POSIX 병렬 파일 시스템을 제공하지 않으며, iSCSI 볼륨은 클러스터형 파일 시스템 계층 없이 여러 클라이언트의 동시 병렬 액세스를 위해 설계되지 않았습니다. 또한 클라우드 네이티브 HPC 솔루션에 불필요한 하이브리드 복잡성을 추가합니다.

Amazon EFS는 NFS v4.1을 통해 액세스되는 완전 관리형 POSIX 호환 공유 파일 시스템이며 처리량을 확장할 수 있지만 Lustre와 같은 병렬 파일 시스템은 아닙니다. Max I/O 모드를 사용하더라도 EFS는 일반적으로 많은 컴퓨팅 노드에서 매우 높은 처리량과 짧은 지연 시간이 필요한 극단적인 HPC 병렬 I/O보다 공유 파일 워크로드(홈 디렉터리, 콘텐츠 관리, 웹 서비스)에 더 적합합니다.

Amazon FSx for Lustre는 높은 처리량, 짧은 지연 시간 및 많은 컴퓨팅 노드의 동시 액세스가 필요한 HPC 워크로드를 위해 설계된 완전 관리형 Lustre 병렬 파일 시스템입니다. 스토리지 서버 전반에 걸친 파일 스트라이핑을 통해 POSIX 의미 체계 및 병렬 I/O를 지원하여 매우 높은 총 성능을 가능하게 합니다. SSD 스토리지를 사용하면 1밀리초 미만의 지연 시간 요구 사항과 일치하며 실행당 5~50TB의 집약적인 게놈 시퀀싱 분석을 지원합니다.

문제 분석

핵심 개념: 이 질문은 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
문제 5

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

DynamoDB 글로벌 테이블은 다중 리전, 액티브-액티브 복제를 제공하며 고가용성 및 지연 시간이 짧은 글로벌 액세스에 탁월합니다. 그러나 쓰기(잘못되거나 손상된 업데이트 포함)가 모든 리전에 복제되므로 논리적 손상으로부터 보호하지 못합니다. PITR과 같은 추가 메커니즘 없이는 손상 이전 상태로 안정적으로 롤백할 수 없습니다. 이 옵션은 손상 복구보다는 리전 장애를 해결합니다.

손상 시나리오에 대해 DynamoDB 특정 시점 복구(PITR)를 활성화하는 것이 올바른 접근 방식입니다. PITR은 지속적인 백업을 제공하고 지난 35일 이내의 어느 초로든 테이블을 복원할 수 있게 하여 15분 RPO를 쉽게 충족합니다. 복원 시 새 테이블이 생성되며, 애플리케이션을 이 테이블로 리디렉션할 수 있어 적절히 운영될 경우 명시된 데이터 세트 크기에 대해 일반적으로 1시간 이내에 RTO를 달성할 수 있습니다.

Amazon S3 Glacier Deep Archive로의 일일 내보내기는 저비용의 장기 보존을 위해 설계되었으며 신속한 운영 복구를 위한 것이 아닙니다. 일일 주기로는 15분 RPO를 충족할 수 없으며, Deep Archive 검색 시간(몇 시간)은 일반적으로 1시간 RTO를 충족할 수 없습니다. 내보내기가 더 자주 이루어지더라도 복원 프로세스(검색, 다시 가져오기)는 PITR에 비해 운영 부담이 큽니다.

DynamoDB는 완전 관리형 서비스이므로 이는 불가능합니다. 고객은 기본 스토리지 볼륨을 관리하거나 액세스하지 않으므로 EBS 스냅샷을 사용하여 DynamoDB 테이블을 백업할 수 없습니다. DynamoDB의 경우 온디맨드 백업, PITR 또는 S3로의 내보내기를 통해 백업이 처리됩니다. 이 옵션은 관리형 서비스를 자체 관리형 데이터베이스처럼 취급하는 일반적인 오해를 반영합니다.

문제 분석

개요: 핵심 개념: 이 질문은 실패 모드가 논리적 손상(잘못된 쓰기, 우발적인 삭제, 애플리케이션 버그)이고 요구 사항이 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
문제 6

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

정답입니다. AWS Batch 작업 상태 변경은 Amazon EventBridge로 전달되며, 여기서 rule은 SUCCEEDED 이벤트와 일치할 수 있습니다. EventBridge API Destinations는 외부 REST 엔드포인트를 직접 호출할 수 있으며, EventBridge Connections는 API key 자격 증명을 관리하고 Bearer token 형식으로 Authorization 헤더를 설정할 수 있습니다. 이는 완전한 serverless이며, 구성 요소를 최소화하고, 일반적으로 가장 비용 효율적이고 운영상 간단한 접근 방식입니다.

오답입니다. EventBridge Scheduler는 시간 기반 호출(cron/rate)을 위한 것이며 AWS Batch SUCCEEDED 이벤트를 "캡처"하지 않습니다. EventBridge(rules)를 사용하여 Lambda를 트리거하는 것은 작동하지만, 이 옵션에서 Scheduler를 사용하는 것은 이벤트 캡처에 대해 개념적으로 잘못되었습니다. EventBridge rule로 수정하더라도 Lambda는 코드와 비용을 추가하며 단순한 HTTP 알림의 경우 API Destinations보다 비용 최적화가 덜 됩니다.

오답입니다. AWS Batch는 기본적으로 작업 SUCCEEDED 이벤트를 API Gateway에 게시하지 않습니다. API Gateway는 클라이언트를 위한 API의 프런트 역할을 하도록 설계되었으며, EventBridge와 같은 중개자 없이 Batch의 event target 역할을 하도록 설계되지 않았습니다. 또한 HTTP proxy integration은 인바운드 API 요청을 백엔드로 전달하기 위한 것입니다. 이는 Batch 완료 이벤트 시 외부 시스템에 대한 호출을 시작해야 하는 필요성을 해결하지 못합니다.

오답입니다. 옵션 C와 마찬가지로 AWS Batch는 작업 SUCCEEDED 이벤트를 API Gateway에 직접 게시할 수 없습니다. EventBridge를 삽입하여 API Gateway를 호출하더라도 EventBridge API Destinations에 비해 불필요한 구성 요소(API Gateway + Lambda)가 추가됩니다. Lambda proxy integration은 사용자 지정 로직을 실행하거나, 페이로드를 변환하거나, 복잡한 인증을 처리해야 할 때 유용하지만, 간단한 알림의 경우 가장 비용 효율적인 방법은 아닙니다.

문제 분석

핵심 개념: 이 질문은 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
문제 7

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

정답입니다. ALB 뒤의 EC2 Auto Scaling은 여러 AZ에 걸쳐 애플리케이션 계층에 대한 수평 확장 및 고가용성을 제공합니다. Aurora Serverless MySQL은 Aurora의 분산 스토리지 및 장애 조치 기능을 통해 고가용성을 유지하면서 수요에 따라 용량을 자동으로 확장할 수 있는 MySQL 호환 데이터베이스를 제공합니다. 이는 애플리케이션 및 데이터베이스 계층을 모두 자동 확장하라는 요구 사항과 가장 잘 일치합니다.

요구 사항을 부분적으로 충족하지만 최선은 아닙니다. ALB는 가용성을 향상시키지만, 이 옵션은 Auto Scaling 그룹을 명시적으로 사용하지 않으므로 애플리케이션 자동 확장이 보장되지 않습니다. 또한 "다중 인스턴스가 있는 RDS for MySQL 클러스터"는 모호합니다. RDS Multi-AZ는 가용성을 향상시키고 읽기 전용 복제본은 읽기를 확장하지만 쓰기 용량은 일반적으로 자동 확장되지 않습니다. 데이터베이스에 대한 "자동으로 확장"과 덜 일치합니다.

오답입니다. Auto Scaling + ALB는 애플리케이션 계층을 확장할 수 있지만, Amazon ElastiCache for Redis는 캐싱 계층이며 내구성 있는 MySQL 데이터베이스 대체품이 아닙니다. "MySQL 커넥터"가 Redis를 트랜잭션 데이터의 기록 시스템으로 만들지는 않습니다. 이는 내구성, 백업 및 관계형 기능을 갖춘 MySQL 워크로드를 위해 데이터베이스 계층을 확장하라는 요구 사항을 충족하지 못합니다.

오답입니다. 단일의 새로운 EC2 인스턴스로 이동하는 것은 고가용성이나 확장을 제공하지 않습니다. Amazon Redshift는 트랜잭션 MySQL 워크로드(OLTP)가 아닌 분석(OLAP)에 최적화된 열 기반 데이터 웨어하우스입니다. 통합을 통해 일부 호환성이 존재하더라도 Redshift는 드롭인 MySQL 데이터베이스가 아니며 자동 확장되고 고가용성을 갖춘 MySQL 데이터베이스 계층에 대한 요구 사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 질문은 애플리케이션 계층을 데이터베이스 계층에서 분리하고 관리형 서비스를 사용하여 고가용성 및 자동 확장 아키텍처를 설계하는 것을 테스트합니다. 주요 서비스: 상태 비저장 웹/앱 확장을 위한 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
문제 8

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

Lambda 사용자 지정 권한 부여자는 토큰을 검증하고 복잡한 권한 부여 로직을 구현할 수 있지만 추가적인 개발 및 운영 오버헤드(코드, 배포, 모니터링, 확장 및 잠재적인 콜드 스타트)를 발생시킵니다. 빠른 성장과 높은 요청 볼륨으로 인해 요청당 Lambda 호출은 지연 시간과 비용을 증가시킬 수 있습니다. Cognito user pool 권한 부여자가 관리형 JWT 검증을 제공하는 상황에서 이는 최소 운영 접근 방식이 아닙니다.

API key는 개별 모바일 뱅킹 고객을 인증하는 것이 아니라 API Gateway 사용량 계획(스로틀링/할당량) 및 호출 애플리케이션을 식별하기 위한 것입니다. DynamoDB에 고객별 API key를 저장하고 검증하는 것과 Lambda 검증 계층을 추가하면 복잡성이 증가하고 모바일 클라이언트에서 키 교체 및 유출 위험이 발생합니다. 또한 Cognito JWT가 이미 제공하는 기능을 중복합니다.

헤더는 클라이언트에서 조작할 수 있으므로 헤더에 계좌 번호를 포함하는 것은 안전한 액세스 제어 메커니즘이 아닙니다. 여전히 강력한 인증(예: JWT)과 자격 증명을 허용된 리소스에 매핑하는 서버 측 권한 부여 확인이 필요합니다. 이를 검증하기 위해 Lambda를 사용하면 사용자 지정 로직과 운영 부담이 증가하며, 완벽하게 구현되지 않을 경우 안전하지 않은 직접 객체 참조(IDOR) 문제의 위험이 있습니다.

Cognito user pool 권한 부여자가 있는 API Gateway는 Cognito에서 발급한 JWT(서명, 만료, 발급자, 대상)를 자동으로 검증하는 완전 관리형의 오버헤드가 적은 솔루션입니다. 사용자 지정 권한 부여 코드 없이 사용자 증가에 따라 확장되며 메서드 수준 액세스 제어를 위해 OAuth 범위/클레임과 깔끔하게 통합됩니다. 이는 API 액세스를 보호하면서 최소한의 운영 오버헤드에 대한 요구 사항을 가장 잘 충족합니다.

문제 분석

핵심 개념: 이 질문은 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
문제 9

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

S3 Intelligent-Tiering은 즉각적인 가용성 요구 사항과 예측 불가능한 액세스에 가장 적합합니다. 사용량에 따라 Frequent 및 Infrequent 액세스 계층(및 선택적 아카이브 계층) 간에 객체를 자동으로 이동하여 액세스 패턴을 예측할 필요 없이 비용을 최적화합니다. 활성 계층에서 밀리초 단위의 액세스를 유지하며 많은 객체에 정기적으로 액세스하지 않을 때 S3 Standard에 대해 초과 지불할 위험을 줄입니다.

S3 Glacier Instant Retrieval은 밀리초 단위의 액세스를 제공하지만 거의 액세스하지 않는 아카이브 데이터를 위한 것입니다. 일반적으로 최소 스토리지 기간 요금(보통 90일)과 검색 요금이 있으며, 액세스가 예상보다 빈번할 경우 비용이 많이 들 수 있습니다. 여러 부서에 걸쳐 회사의 액세스가 매우 예측 불가능하기 때문에 Glacier Instant Retrieval은 Intelligent-Tiering의 자동 최적화에 비해 불필요한 검색 비용을 발생시킬 수 있습니다.

S3 Standard는 검색 요금 없이 가장 높은 가용성과 밀리초 단위의 액세스를 제공하므로 즉각적인 액세스 요구 사항에 매력적입니다. 그러나 지속적으로 액세스하지 않는 데이터의 경우 일반적으로 가장 비싼 옵션입니다. 예측 불가능한 액세스 패턴과 90일 보존을 고려할 때 많은 보고서에 드물게 액세스할 수 있으므로 Standard는 Intelligent-Tiering에 비해 필요 이상으로 많은 비용이 들 가능성이 높습니다.

S3 Standard-IA는 Standard보다 저렴한 스토리지 가격으로 밀리초 단위의 액세스를 제공하지만 검색 요금을 청구하며 액세스 빈도가 낮다고 알려진 데이터에 최적화되어 있습니다. 액세스가 매우 예측 불가능한 경우 검색 요금이 누적되어 비용 절감 효과가 상쇄될 수 있습니다. 또한 최소 스토리지 기간 요금(일반적으로 30일)이 있는데, 이는 90일 보존에는 문제가 되지 않지만 Intelligent-Tiering만큼 불확실성을 잘 해결하지는 못합니다.

문제 분석

핵심 개념: 이 질문은 엄격한 보존 요구 사항과 즉각적인(밀리초) 액세스라는 강력한 제약 조건 하에서 예측 불가능한 액세스 패턴에 대한 비용 최적화를 위한 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
문제 10

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

수동 snapshot/restore는 운영상 간단하지만 일반적으로 상당한 다운타임을 유발하며 컷오버 시 거의 제로에 가까운 데이터 손실을 보장할 수 없습니다. snapshot 시간 이후의 진행 중인 쓰기를 중지하거나 손실을 감수해야 하며, 그런 다음 Aurora로 복원해야 하는데 대규모 데이터베이스의 경우 5분 이상 걸릴 수 있습니다. 이 접근 방식은 중요하지 않은 시스템이나 더 긴 유지 관리 기간이 허용되는 경우에 더 적합합니다.

이것이 가장 적합합니다. RDS for MySQL 인스턴스에서 Aurora read replica를 생성하고 지속적으로 복제되도록 한 다음, 컷오버 시 독립 실행형 Aurora cluster로 승격시킵니다. 짧은 쓰기 중지(write freeze)와 복제 지연(replication lag)이 0인지 확인하면 사실상 데이터 손실을 0으로 달성하고 다운타임을 몇 분 이내로 유지할 수 있습니다. 또한 AWS가 복제 및 승격 워크플로를 관리하므로 운영 오버헤드가 최소화됩니다.

mysqldump를 사용하여 S3로 내보내고 Aurora로 가져오는 것은 매우 수동적이며 크고 바쁜 데이터베이스의 경우 일반적으로 느립니다. 내보내기를 조정하고 일관성을 처리(종종 잠금 또는 트랜잭션 snapshot 필요)한 다음 가져와야 하므로 5분의 다운타임 요구 사항을 초과할 수 있습니다. 또한 인적 오류의 위험을 증가시키며 미션 크리티컬한 고트랜잭션 워크로드에는 이상적이지 않습니다.

AWS DMS는 전체 로드(full load) 및 지속적인 CDC 복제를 수행할 수 있으며 낮은 다운타임 및 낮은 데이터 손실 목표를 충족할 수 있습니다. 그러나 일반적으로 Aurora read replica 접근 방식보다 운영 오버헤드가 더 높습니다. replication instance를 프로비저닝 및 관리하고, task를 구성하고, 지연 시간을 모니터링하고, 오류를 처리하고, 성능을 튜닝해야 합니다. DMS는 기본 복제(native replication)를 사용할 수 없거나 복잡한 마이그레이션에 탁월하지만, 여기서는 최소 운영(least-ops) 옵션이 아닙니다.

문제 분석

핵심 개념: 이 질문은 최소한의 운영 노력으로 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를 목표로 합니다.

합격 후기(30)

C
C*********Mar 23, 2026

학습 기간: 1 week

요구사항 정확히 인지하기(이거 젤중요 이 훈련이 제일 중요한듯), 오답노트 갈겨서 200문제만 확실히 해서 갔어요 실제 시험 지문은 훨씬 간단한데 난이도는 앱이랑 비슷하거나 더 낮았던것같아요 느낌상 탈락이었는데 통과해서 기쁘네요 큰 도움 되었습니다 감사해요!

소
소**Feb 22, 2026

학습 기간: 1 week

그냥 문제 풀면서 개념들 GPT에 물어보면서 학습했어요 768점 턱걸이 합격,,

조
조**Jan 12, 2026

학습 기간: 3 months

그냥 꾸준히 공부하고 문제 풀고 합격했어요 saa 준비생분들 화이팅!!

김
김**Dec 9, 2025

학습 기간: 1 month

앱으로는 4일만에 몇 문제를 풀었는지 모르겠지만 1딜동안 aws 기본 개념부터 덤프로 시나리오 그려보고 하니까 합격했습니다. 시험은 생각보다 헷갈리게 나와서 당황했는데 30분 추가 테크로 flag한 지문들 다시 확인하니까 문제 없었습니다.

L
L*************Nov 26, 2025

학습 기간: 3 months

I passed the AWS SAA with a score of 850/1000. Honestly, the exam wasn’t easy, but solving the actual exam–style questions in Cloud Pass helped me understand the reasoning behind each service. The explanations were super helpful and made the concepts stick. I don’t think I could’ve scored this high without the practice here.

다른 모의고사

Practice Test #1

65 문제·130분·합격 720/1000

Practice Test #2

65 문제·130분·합격 720/1000

Practice Test #3

65 문제·130분·합격 720/1000

Practice Test #4

65 문제·130분·합격 720/1000

Practice Test #6

65 문제·130분·합격 720/1000

Practice Test #7

65 문제·130분·합격 720/1000

Practice Test #8

65 문제·130분·합격 720/1000

Practice Test #9

65 문제·130분·합격 720/1000

Practice Test #10

65 문제·130분·합격 720/1000
← 모든 AWS Certified Solutions Architecture - Associate (SAA-C03) 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 AWS Certified Solutions Architecture - Associate (SAA-C03) 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

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

앱 받기

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