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

Practice Test #1

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

글로벌 스트리밍 미디어 회사가 여러 리전에서 250개 이상의 비디오 스트리밍 플랫폼을 운영하고 있습니다. 이 회사는 콘텐츠 추천 및 사용자 경험을 최적화하기 위해 매일 약 25TB의 사용자 시청 행동 및 상호 작용 데이터를 처리해야 합니다. 솔루션은 대용량 실시간 데이터 수집(ingestion)을 처리하고, 안정적인 데이터 전송을 제공하며, 대규모 스트리밍 데이터에 대한 효율적인 분석 처리를 가능하게 해야 합니다. 솔루션 아키텍트는 스트리밍 행동 데이터를 수집하고 처리하기 위해 무엇을 권장해야 합니까?

AWS Data Pipeline은 주로 예약된/배치 데이터 이동 및 오케스트레이션을 위한 것이며 대용량 실시간 스트리밍 수집을 위한 것이 아닙니다. S3 + EMR이 대규모 데이터 세트를 분석할 수 있지만, 여기서 수집 계층이 약점입니다. Data Pipeline은 Kinesis와 동일한 실시간 버퍼링, 확장 및 재생 의미 체계를 제공하지 않습니다. 이 옵션은 또한 거의 실시간 요구 사항에 대한 운영 복잡성을 증가시킵니다.

스트리밍 이벤트를 캡처하고 전달하기 위한 EC2 인스턴스의 Auto Scaling 그룹은 안정적으로 확장하고 운영하기(용량 계획, 백프레셔 처리, 재시도, 순서 지정 및 장애 복구) 더 어려운 DIY 수집 접근 방식입니다. 작동할 수는 있지만 하루 25TB의 실시간 원격 측정에 가장 적합한 관리형 패턴은 아닙니다. Kinesis는 더 적은 운영 오버헤드로 이러한 기능을 기본적으로 제공합니다.

Amazon CloudFront는 짧은 지연 시간으로 콘텐츠를 캐시하고 전송하도록 설계되었습니다. 기본 데이터 수집 메커니즘으로 사용자 상호 작용 원격 측정을 저장하거나 수집하기 위한 것이 아닙니다. S3 객체 생성에서 Lambda를 트리거하는 것은 연속 스트리밍이 아닌 배치/객체 기반 수집을 의미하며, 매우 높은 볼륨에서는 확장 및 지연 시간 문제를 일으킬 수 있습니다. 이는 실시간 행동 분석을 위한 아키텍처 불일치입니다.

Kinesis Data Streams는 많은 소스에서 발생하는 대용량 이벤트 데이터에 대해 확장 가능하고 내구성 있는 실시간 수집을 제공합니다. 그런 다음 Kinesis Data Firehose는 자동 확장, 버퍼링, 재시도 및 선택적 변환을 통해 스트림을 S3 데이터 레이크로 안정적으로 전송합니다. S3에서 Amazon Redshift로 로드하면 효율적인 대규모 분석을 지원합니다. 이는 실시간 수집, 안정적인 전송 및 확장 가능한 분석에 대한 요구 사항과 직접적으로 일치합니다.

문제 분석

핵심 개념: 이 질문은 처리량이 높고 안정적인 스트리밍 수집 및 분석 파이프라인 설계에 대해 테스트합니다. 주요 AWS 서비스는 Amazon Kinesis Data Streams(실시간 수집 및 버퍼링), Amazon Kinesis Data Firehose(스토리지/분석 대상으로의 관리형 전송), Amazon S3(내구성 있는 데이터 레이크), Amazon Redshift(분석/데이터 웨어하우스)입니다. 정답인 이유: 250개 이상의 플랫폼에서 매일 약 25TB의 데이터를 처리해야 하므로, 회사는 내구성 있는 버퍼링과 안정적인 전송을 갖춘 확장 가능한 거의 실시간 수집이 필요합니다. Kinesis Data Streams는 샤드당 정렬된 레코드, 재생을 위한 보존, 샤드(또는 온디맨드 모드)를 통한 수평 확장을 제공하여 대용량 이벤트 수집을 위해 특별히 구축되었습니다. 그런 다음 Kinesis Data Firehose는 배치 처리, 재시도 및 선택적 변환을 통해 데이터를 S3 데이터 레이크에 저장하는 완전 관리형의 안정적인 전송 계층을 제공하여 운영 오버헤드를 최소화합니다. S3에서 대규모 행동 분석 및 추천 기능 생성을 위해 데이터를 Redshift로 로드(예: S3에서 COPY)할 수 있습니다. 주요 AWS 기능: - Kinesis Data Streams: 샤드 기반 확장(또는 온디맨드), 다중 소비자, 향상된 팬아웃(enhanced fan-out), 재처리를 위한 보존, IAM/KMS와의 통합. - Kinesis Data Firehose: 자동 배치/압축/암호화, 재시도 로직, S3 전송, 선택적 Lambda 기반 변환. - S3 데이터 레이크: 높은 내구성, 수명 주기 정책, 효율적인 다운스트림 쿼리를 위한 파티셔닝된 스토리지. - Redshift: 빠른 집계를 위한 열 기반 스토리지 및 MPP; 처리량이 높은 로드를 위한 S3에서 COPY. 일반적인 오해: Data Pipeline 및 DIY EC2 수집은 실행 가능해 보일 수 있지만, 이 규모의 실시간 스트리밍에 최적화되어 있지 않으며 상당한 운영 부담을 추가합니다. CloudFront는 콘텐츠 전송/캐시 서비스이지 이벤트 수집 시스템이 아닙니다. 행동 원격 측정에 이를 사용하는 것은 아키텍처상 맞지 않습니다. 시험 팁: "대용량 실시간 수집(high-volume real-time ingestion)"과 "안정적인 전송(reliable transmission)" 및 "분석(analytics)"이 보이면 Kinesis(수집/버퍼링을 위한 Streams, 관리형 전송을 위한 Firehose) + 랜딩 존으로서의 S3를 생각하십시오. 분석 요구 사항에 따라 Redshift/EMR/Athena와 페어링하십시오. Redshift는 대규모 구조화된 행동 분석을 위한 일반적인 선택입니다.

2
문제 2

한 회사가 매일 EBS 스냅샷을 생성하며 EC2에서 SQL Server를 실행합니다. 정리 스크립트가 실수로 모든 스냅샷을 삭제했습니다. 이 회사는 스냅샷을 영구적으로 보관하지 않으면서 데이터 손실을 방지해야 합니다. 최소한의 개발로 우발적인 삭제에 대한 안전망을 제공해야 합니다. 최소한의 개발 노력으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

IAM에서 ec2:DeleteSnapshot을 거부하면 특정 보안 주체에 대한 우발적인 삭제를 줄일 수 있지만 신뢰할 수 있는 안전망은 아닙니다. 스크립트가 다른 역할로 실행될 수 있고, 관리자가 여전히 삭제할 수 있으며, 삭제가 발생할 경우 복구를 제공하지 않습니다. 또한 예외 및 더 많은 정책 관리가 필요하기 때문에 삭제를 허용해야 하는(스냅샷을 영구적으로 보관하지 않음) 요구 사항과 충돌합니다.

스냅샷을 다른 리전으로 복사하는 것은 주로 리전 중단에 대한 재해 복구 전략이지 우발적인 삭제에 대한 안전망이 아닙니다. 동일한 자동화 또는 운영자가 두 리전 모두에서 스냅샷을 삭제하는 경우(또는 권한이 허용하는 경우) 여전히 스냅샷을 잃을 수 있습니다. 또한 단순한 휴지통 규칙에 비해 지속적인 비용과 운영 복잡성(복사 일정, 모니터링, 보존 관리)이 추가됩니다.

EBS 스냅샷 휴지통 보존 규칙은 우발적인 스냅샷 삭제로부터 보호하도록 특별히 설계되었습니다. 모든 스냅샷에 대해 7일 보존 규칙을 사용하면 삭제된 스냅샷은 해당 기간 동안 복구 가능한 상태로 유지된 다음 영구적으로 제거되어 "영구 보관 안 함" 요구 사항을 충족합니다. 이는 최소한의 개발입니다. 규칙을 한 번 구성하고 필요할 때 복원을 사용합니다.

EBS 스냅샷은 S3 버킷으로 직접 복사한 다음 S3 Standard-IA를 선택할 수 있는 객체가 아닙니다. 스냅샷은 EBS 스냅샷 서비스에 의해 저장되고 관리됩니다. 일부 AWS 서비스는 특정 데이터를 S3로 내보낼 수 있지만, "스냅샷을 S3 Standard-IA로 복사"는 이 컨텍스트에서 EBS 스냅샷 보존 및 복구를 위한 유효한 기본 메커니즘이 아닙니다.

문제 분석

핵심 개념 - 이 질문은 우발적인 삭제에 대한 복원력을 제공하는 AWS Backup/Amazon EBS 데이터 보호 제어, 특히 EBS 스냅샷 휴지통(Recycle Bin) 기능(EBS 스냅샷 관리의 일부) 및 보존 기반 복구를 테스트합니다. 이는 복구 가능성, 제어된 보존 및 운영 위험 최소화와 같은 복원력 있는 아키텍처 원칙과 일치합니다. 정답인 이유 - 7일 EBS 스냅샷 휴지통 보존 규칙은 "안전망"을 생성하여 스냅샷이 (스크립트나 사용자에 의해) 실수로 삭제되더라도 휴지통에 보존되고 보존 기간 동안 복원될 수 있도록 합니다. 이는 스냅샷을 영구적으로 보관하지 않아야 한다는 요구 사항을 충족하면서 인시던트(모든 스냅샷의 우발적 삭제)를 직접적으로 해결합니다. 또한 최소한의 개발이 필요합니다. 백업 워크플로를 재설계하는 대신 보존 규칙을 한 번만 구성하면 됩니다. 주요 AWS 기능 - EBS 스냅샷 휴지통을 사용하면 보존 규칙(태그별 또는 계정/리전의 모든 스냅샷에 대해)을 설정하여 삭제된 스냅샷을 보존 기간이 만료될 때까지 복구할 수 있습니다. 이는 우발적인 삭제를 위해 특별히 구축되었으며 일반적인 스냅샷 수명 주기 정책을 보완(대체하지 않음)합니다. 이는 계정/리전 수준의 제어이며 교차 리전 복사 파이프라인을 구축하는 것에 비해 운영상 간단합니다. 일반적인 오해 - IAM에서 스냅샷 삭제를 거부하는 것(옵션 A)은 삭제를 방지하는 것처럼 보이지만 불안정합니다. 정리 스크립트가 다른 역할로 실행될 수 있고, 관리자가 여전히 삭제할 수 있으며, 삭제가 이미 발생했거나 합법적인 삭제가 필요한 경우에는 도움이 되지 않습니다. 교차 리전 복사(옵션 B)는 재해 복구를 개선하지만 별도의 제어로 복사본을 보호하지 않는 한 본질적으로 우발적인 삭제로부터 보호하지 못합니다. 또한 비용과 운영 오버헤드가 추가됩니다. "스냅샷을 S3 Standard-IA로 복사"(옵션 D)는 EBS 스냅샷이 작동하는 방식이 아닙니다. 스냅샷은 EBS에서 관리하며 S3 스토리지 클래스로 직접 계층화할 수 없습니다. 시험 팁 - "우발적 삭제(accidental deletion)" + "영구 보관 안 함(don't keep forever)" + "최소한의 개발(least development)"이 보이면 관리형 보존/복구 기능인 EBS 스냅샷 휴지통, AWS Backup Vault Lock(백업용) 및 수명 주기 정책을 찾으십시오. 시간 제한 보존 및 최소한의 사용자 지정 자동화를 통해 삭제 후 복구 가능성을 직접 제공하는 옵션을 선택하십시오.

3
문제 3

금융 서비스 회사가 50개 이상의 파트너 은행에서 매일 트랜잭션 보고서를 처리하기 위한 중요한 파일 교환 시스템을 운영합니다. 이 시스템은 현재 공유 스토리지로 지원되는 FTP 서비스를 실행하는 탄력적 IP 주소(Elastic IP)가 있는 두 개의 Amazon EC2 인스턴스를 사용합니다. 시스템은 매일 약 10,000개의 파일을 처리하며 각 파일의 크기는 100MB에서 2GB 사이입니다. 회사는 영업 시간(오전 9시 - 오후 5시 EST) 동안 15,000 IOPS의 최대 로드를 처리하고 엔터프라이즈급 보안 제어를 제공할 수 있는 서버리스 아키텍처로 마이그레이션해야 합니다. 솔루션은 특정 파트너 은행 IP 범위에서의 파일 전송을 지원하고 규정 준수 감사를 위해 세분화된 사용자 액세스 제어를 유지해야 합니다. 이러한 고성능 및 보안 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?

오답입니다. AWS Transfer Family는 Amazon EBS를 스토리지 backend로 사용하지 않으므로, io2 EBS volume을 Transfer Family endpoint에 연결하는 것은 지원되는 아키텍처가 아닙니다. EBS는 EC2 및 유사한 compute 연결 사용 사례를 위한 block 스토리지이지, managed Transfer Family 스토리지 통합용이 아닙니다. 또한 이 옵션은 SFTP가 아니라 FTP를 지정하고 있는데, 명시적으로 요구되지 않는 한 이는 금융 서비스 워크로드에 대해 암시되는 enterprise-grade 보안 기대치를 충족하지 못합니다.

오답입니다. AWS Transfer Family는 backend로 Amazon EFS를 사용할 수 있으므로, 이 옵션은 A나 D보다는 더 가깝지만 serverless 고확장성 파트너 파일 교환 워크로드에 대한 최선의 답은 아닙니다. EFS는 파일 시스템 성능 설계 고려 사항을 도입하며, 일반적으로 대규모 외부 파일 교환에는 S3보다 덜 단순합니다. 또한 문제는 EFS를 정당화할 만한 POSIX semantics를 요구하지 않습니다. elastic IP address에 대한 표현도 문제가 있는데, Transfer Family endpoint 네트워킹은 다른 방식으로 관리되며, 이 옵션은 S3 기반 Transfer Family보다 덜 깔끔하고 가장 단순한 확장 가능한 serverless 설계와도 덜 부합합니다.

정답입니다. AWS Transfer Family with SFTP는 fully managed, serverless 파일 전송 endpoint를 제공하므로 회사는 더 이상 EC2 기반 FTP 서버를 운영할 필요가 없습니다. backend로 Amazon S3를 사용하는 것은 대규모 일일 파일 볼륨과 가변적인 처리량에 이상적입니다. S3는 자동으로 확장되고 성능을 위해 IOPS나 용량을 프로비저닝할 필요가 없기 때문입니다. 세분화된 사용자 액세스는 사용자를 특정 bucket 또는 prefix로 제한하는 IAM role 및 policy를 통해 구현할 수 있으며, 암호화와 서비스 로깅은 규정 준수 및 감사 요구 사항을 지원합니다. 유일한 주의점은 엄격한 source-IP 필터링은 VPC-hosted endpoint와 security group으로 가장 직접적으로 구현된다는 점이지만, 선택지들 중에서는 여전히 이것이 전반적으로 가장 좋은 아키텍처입니다.

오답입니다. NAT gateway 뒤의 private subnet에 배치된 Transfer Family endpoint는 인터넷상의 외부 파트너 은행에서 inbound로 접근할 수 없습니다. NAT gateway는 private 리소스의 outbound internet 액세스에 사용되며, inbound 파트너 연결을 수락하거나 source-IP allow list를 적용하는 용도가 아닙니다. S3와 custom identity provider가 스토리지 및 인증 요구 사항을 충족할 수는 있지만, 설명된 네트워킹 설계는 외부 액세스 요구 사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 serverless이고, 대량의 파일 볼륨에 대해 높은 확장성을 제공하며, 금융 서비스 파트너 통합에 충분할 만큼 안전한 fully managed 파일 전송 서비스를 선택하는지를 평가합니다. 가장 적합한 선택은 backend로 Amazon S3를 사용하는 SFTP 기반의 AWS Transfer Family입니다. 그 이유는 S3가 스토리지 성능을 프로비저닝할 필요 없이 사실상 무제한에 가까운 확장성을 제공하고, Transfer Family가 managed 사용자 액세스 제어와 로깅을 제공하기 때문입니다. 정답인 이유: 옵션 C가 최선의 답인 이유는 AWS Transfer Family with SFTP를 사용하기 때문이며, 이는 EC2 기반 FTP 서버를 운영할 필요를 없애는 managed 서비스입니다. Amazon S3는 많은 대용량 파일을 처리하는 serverless 아키텍처에 가장 적절한 backend이며, block 또는 file 스토리지처럼 IOPS를 산정하거나 프로비저닝할 필요가 없습니다. 세분화된 액세스 제어는 특정 bucket 또는 prefix 범위로 제한된 IAM role 및 policy를 통해 적용할 수 있고, 암호화와 로깅은 규정 준수 요구 사항을 지원합니다. 주요 기능: - AWS Transfer Family는 서버를 관리하지 않고도 managed SFTP endpoint를 지원합니다. - Amazon S3는 대용량 파일 교환 워크로드를 위한 내구성이 높고 대규모로 확장 가능한 object 스토리지를 제공합니다. - IAM policy는 최소 권한 액세스를 위해 각 사용자를 특정 S3 prefix로 제한할 수 있습니다. - S3 기본 암호화와 AWS Transfer Family 로깅은 보안 및 감사 요구 사항을 지원합니다. - 엄격한 source-IP 필터링이 필요한 경우 VPC-hosted endpoint와 security group을 사용해 IP 기반 제한을 구현할 수 있습니다. 흔한 오해: - EBS는 Transfer Family backend로 사용할 수 없습니다. - NAT gateway는 파트너 연결에 대한 inbound internet 액세스 제어를 제공하지 않습니다. - CloudTrail은 API 활동을 기록하지만, 자세한 전송/세션 가시성은 일반적으로 Transfer Family 로깅 및 관련 서비스 로그에서 제공합니다. - S3 Transfer Acceleration은 직접적인 S3 액세스에 적용되며, AWS Transfer Family를 통해 연결하는 클라이언트에는 적용되지 않습니다. 시험 팁: 문제에서 serverless managed 파일 전송, 외부 파트너 액세스, 대량 파일 볼륨, 세분화된 권한을 강조한다면, 명확하게 타당한 EFS 전용 요구 사항이 없는 한 AWS Transfer Family with S3를 떠올리세요. 지원되지 않는 스토리지 backend나 잘못된 네트워킹 패턴을 제안하는 답은 제거하세요. 프로토콜 요구 사항이 명시적으로 달리 말하지 않는 한, 민감한 금융 워크로드에는 FTP보다 SFTP를 우선하세요.

4
문제 4

의료 회사가 X-ray 및 MRI 스캔을 처리하는 의료 영상 분석 애플리케이션을 운영합니다. 이 애플리케이션은 동일한 AWS 리전 내의 Amazon S3 버킷에서 대용량 의료 이미지 파일을 자주 저장하고 검색합니다. IT 팀은 지난 분기 동안 월별 데이터 전송 요금이 40% 증가한 것을 관찰했습니다. 솔루션 아키텍트는 의료 영상 처리를 위해 S3 버킷에 대한 안전한 액세스를 유지하면서 데이터 전송 요금을 최소화하는 비용 효율적인 솔루션을 구현해야 합니다. 솔루션 아키텍트는 이 요구 사항을 어떻게 충족할 수 있습니까?

API Gateway는 API를 구축하고 관리하기 위한 것이지, 데이터 전송 요금을 줄이기 위해 워크로드에서 S3로 일반 S3 API 호출을 라우팅하기 위한 것이 아닙니다. 서브넷에 API Gateway를 배치하는 것도 개념적으로 잘못되었습니다(API Gateway는 프라이빗 통합을 사용하지 않는 한 VPC에 배포되지 않는 관리형 리전 서비스입니다). 요청 기반 비용과 복잡성을 추가하며 게이트웨이 엔드포인트의 직접적인 프라이빗 S3 라우팅 이점을 제공하지 않습니다.

퍼블릭 서브넷의 NAT 게이트웨이는 프라이빗 서브넷이 S3를 포함한 인터넷/AWS 퍼블릭 엔드포인트에 도달할 수 있도록 허용하지만 NAT 게이트웨이 시간당 요금 및 GB당 데이터 처리 요금을 발생시킵니다. 대용량 의료 이미지의 경우 NAT 처리 비용이 상당할 수 있으며 종종 청구서 증가의 근본 원인이 됩니다. 또한 NAT 게이트웨이에 "엔드포인트 정책"을 연결하지 않습니다. 엔드포인트 정책은 VPC 엔드포인트에 적용됩니다.

애플리케이션을 퍼블릭 서브넷에 배치하고 인터넷 게이트웨이를 사용하면 퍼블릭 IP 라우팅 경로를 통해 S3 트래픽이 전송됩니다. 이는 비용을 최소화하지 않으며 공격 표면을 확장하여 보안 위험을 증가시킬 수 있습니다. 또한 VPC 엔드포인트 정책 및 특정 VPC 엔드포인트가 필요한 버킷 정책과 같은 세분화된 네트워크 수준 제어를 제공하지 않습니다. 이는 일반적으로 의료 워크로드에 대한 모범 사례와 반대됩니다.

S3 VPC 게이트웨이 엔드포인트는 NAT 또는 IGW 없이 VPC에서 S3로의 프라이빗 연결을 제공하여 일반적으로 NAT 게이트웨이 데이터 처리 요금을 피함으로써 비용을 줄이고 트래픽을 AWS 네트워크에 유지하여 보안을 개선합니다. 엔드포인트 정책을 연결하여 필요한 의료 영상 버킷 및 작업으로만 액세스를 제한하고 aws:SourceVpce가 필요한 S3 버킷 정책으로 이를 강화할 수 있습니다.

문제 분석

핵심 개념: 이 질문은 Amazon S3 데이터 전송 비용을 줄이고 VPC에서 S3로의 프라이빗 연결에 대한 보안을 개선하는 방법을 테스트합니다. 주요 서비스는 Amazon S3 VPC 게이트웨이 엔드포인트입니다(S3용 AWS PrivateLink는 인터페이스 엔드포인트가 아닌 게이트웨이 엔드포인트를 사용함). 정답인 이유: S3 VPC 게이트웨이 엔드포인트는 퍼블릭 인터넷을 통과하지 않고, 인터넷 게이트웨이(IGW)를 사용하지 않고, NAT 게이트웨이를 사용하지 않고 VPC의 리소스(VPC의 EC2, ECS, EKS, Lambda)와 Amazon S3 간의 프라이빗 직접 연결을 제공합니다. 이렇게 하면 NAT 게이트웨이 데이터 처리 요금이 제거되고 인터넷 경로에 대한 노출이 줄어듭니다. "대용량 파일을 자주 저장하고 검색"하는 워크로드의 경우 NAT 게이트웨이 GB당 처리 요금을 피하는 것이 종종 가장 큰 비용 절감 효과를 가져옵니다. 엔드포인트는 리전별로 고가용성을 제공하며 트래픽은 AWS 네트워크에 유지됩니다. 주요 AWS 기능: 1) 게이트웨이 엔드포인트 라우팅 테이블 항목: S3 접두사로 향하는 트래픽이 엔드포인트로 라우팅되도록 엔드포인트를 VPC 라우팅 테이블과 연결합니다. 2) 엔드포인트 정책: 필요한 의료 영상 버킷 및 작업(예: s3:GetObject, s3:PutObject)으로만 액세스를 제한하고 조건(aws:PrincipalArn, s3:prefix 등)을 적용할 수도 있습니다. 3) 심층 방어: 엔드포인트 정책을 VPC 엔드포인트(aws:SourceVpce) 및 IAM 최소 권한을 통한 액세스가 필요한 S3 버킷 정책과 결합합니다. 이는 AWS Well-Architected(비용 최적화 + 보안 원칙)와 일치합니다. 일반적인 오해: 많은 사람들이 "동일한 리전 S3 액세스"가 항상 무료라고 가정합니다. S3 요청 비용 및 리전 내 데이터 전송 패턴은 다양하지만 요금 증가의 일반적인 원인은 NAT 게이트웨이(GB당 NAT 데이터 처리 발생) 또는 기타 이그레스 경로를 통해 S3 트래픽을 라우팅하는 것입니다. 또 다른 오해는 API Gateway 또는 퍼블릭 서브넷/IGW가 비용을 줄인다는 것입니다. 이들은 일반적으로 비용을 추가하고 프라이빗 라우팅 이점을 제공하지 않습니다. 시험 팁: "VPC 내에서 S3로의 데이터 전송 요금 절감" 및 "안전한/프라이빗 액세스 유지"가 보이면 "S3 게이트웨이 엔드포인트"를 생각하십시오. 옵션에 S3 액세스를 위한 NAT 게이트웨이가 언급되어 있으면 일반적으로 비용에 대한 위험 신호입니다. 또한 안전한 패턴으로 "엔드포인트 정책" 및 "aws:SourceVpce가 있는 버킷 정책"을 찾으십시오.

5
문제 5

한 이러닝 플랫폼이 Network Load Balancer 뒤에 있는 Amazon Linux EC2 인스턴스를 사용하여 다중 계층 교육 콘텐츠 전송 시스템을 운영하고 있습니다. 인프라는 3개의 가용 영역에 분산된 Auto Scaling 그룹에서 실행됩니다. 이 플랫폼은 피크 학습 시간(오후 6시~10시)에 학생들이 대용량 비디오 강의와 PDF 자료를 다운로드할 때 상당한 확장 이벤트를 겪으며, 이로 인해 시스템은 증가된 로드를 처리하기 위해 추가 온디맨드(On-Demand) 인스턴스를 프로비저닝합니다. 이 플랫폼은 약 15,000명의 동시 접속 학생에게 서비스를 제공하며 콘텐츠 전송에 대한 짧은 지연 시간을 유지하면서 인프라 비용을 줄여야 합니다. 정적 교육 콘텐츠(비디오, PDF, 이미지)가 전체 대역폭 사용량의 80%를 차지합니다. 플랫폼을 가장 비용 효율적으로 재설계하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

Savings Plans는 안정적이고 예측 가능한 EC2 사용에 대한 컴퓨팅 비용을 줄일 수 있지만, 스케일 아웃 이벤트를 주도하는 무거운 정적 콘텐츠 대역폭이라는 근본 원인을 해결하지는 못합니다. 피크 수요(오후 6시~10시)는 급증하며 초과 약정 없이는 약정으로 완전히 커버되지 않을 수 있습니다. 또한 Savings Plans는 지연 시간을 줄이거나 인스턴스에서 트래픽을 오프로드하지 않으며 적격 컴퓨팅 사용량만 할인합니다.

혼합 인스턴스 정책이 있는 스팟 인스턴스는 버스트 용량에 대한 비용을 낮출 수 있지만 중단 위험을 도입하고 정적 콘텐츠 전송을 여전히 EC2에 유지합니다. 대용량 비디오/PDF 다운로드의 경우 주요 비용 동인은 인스턴스 시간만이 아니라 데이터 전송 및 오리진 로드입니다. 스팟이 도움이 될 수는 있지만 정적 전송을 CloudFront/S3로 이동하는 것에 비해 가장 비용 효율적인 재설계는 아닙니다.

S3 앞의 CloudFront는 EC2에서 80%의 정적 대역폭을 오프로드하고, Auto Scaling 이벤트를 줄이며, 엣지 캐싱을 통해 지연 시간을 개선하므로 최고의 재설계입니다. S3는 비디오 및 PDF를 위한 저비용의 내구성 높은 스토리지를 제공하는 반면, CloudFront는 오리진 송신 및 요청 로드를 줄입니다. OAC를 사용하여 버킷을 보호하고, 캐싱 정책/TTL을 사용하며, 선택적으로 보호된 교육 콘텐츠에 대해 서명된 URL/쿠키를 사용하십시오.

API Gateway + Lambda는 대규모로 비디오 및 PDF와 같은 대용량 정적 자산을 제공하는 데 적합하지 않습니다. Lambda는 페이로드/스트리밍 제약이 있으며 고대역폭 전송에 비용 효율적이지 않습니다. API Gateway는 또한 요청당 비용을 추가하며 CDN이 아닙니다. 이 옵션은 복잡성과 비용을 증가시키면서 CloudFront가 제공하는 엣지 캐싱 및 최적화된 전송을 제공하지 않습니다.

문제 분석

개요: 핵심 개념: 이 질문은 대규모로 주로 정적인 콘텐츠를 비용 최적화하여 전송하는 방법을 테스트합니다. 주요 서비스는 Amazon S3 오리진이 있는 Amazon CloudFront(CDN)로, EC2/Auto Scaling에서 대역폭 및 요청 로드를 오프로드하는 동시에 엣지 캐싱을 통해 지연 시간을 개선합니다. 정답인 이유: 대역폭의 80%가 정적(비디오, PDF, 이미지)이므로 가장 비용 효율적인 재설계는 해당 콘텐츠를 EC2 플릿에서 이동하여 S3가 지원하는 CloudFront를 통해 제공하는 것입니다. CloudFront는 학생들과 가까운 엣지 로케이션에 콘텐츠를 캐시하여 오리진 가져오기를 줄이고 오후 6시~10시 급증 동안 필요한 EC2 데이터 전송 및 컴퓨팅을 극적으로 낮춥니다. 이는 확장 이벤트(온디맨드 인스턴스 감소)를 줄이고 15,000명의 동시 사용자에 대해 짧은 지연 시간을 유지하거나 개선합니다. S3는 내구성이 뛰어나고 저렴한 스토리지를 제공하며, CloudFront는 글로벌 배포 및 최적화된 전송을 제공합니다. 주요 AWS 기능 / 모범 사례: 적절한 스토리지 클래스(예: 핫 콘텐츠의 경우 S3 Standard, 가변 액세스 패턴의 경우 S3 Intelligent-Tiering 고려)가 있는 S3 버킷을 오리진으로 사용합니다. 적절한 TTL, 캐시 정책 및 압축을 사용하여 CloudFront 캐싱을 활성화합니다. 원본 액세스 제어(OAC)를 사용하여 직접적인 S3 액세스를 제한하고 CloudFront를 통해서만 콘텐츠를 제공합니다. 선택적으로 보호된 코스 자료에 대해 서명된 URL/쿠키를 사용하고 성능을 위해 HTTP/2/HTTP/3을 활성화합니다. 이는 AWS Well-Architected 비용 최적화(수요 감소, 관리형 서비스 사용) 및 성능 효율성(엣지 캐싱)과 일치합니다. 일반적인 오해: 확장이 눈에 띄기 때문에 인스턴스 구매(Savings Plans/Spot)에 집중하기 쉽지만, 이는 주요 동인(정적 대역폭)이 아닌 증상(컴퓨팅 비용)을 치료하는 것입니다. 또한 Lambda/API Gateway는 대규모 정적 파일 전송을 위한 것이 아니며 비용이 많이 들고 운영상 어색할 것입니다. 시험 팁: 워크로드가 정적 콘텐츠와 대역폭에 의해 지배될 때 가장 먼저 "S3 + CloudFront"를 생각하십시오. 질문에서 글로벌 또는 대규모 다운로드에 대한 짧은 지연 시간을 언급하는 경우 CDN이 일반적으로 최고의 아키텍처 레버입니다. 구매 모델(Savings Plans/Spot)은 컴퓨팅 로드를 줄이고 목적에 맞게 구축된 관리형 서비스로 전환한 후의 2차 최적화입니다.

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

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

6
문제 6

한 의료 기관이 민감한 환자 의료 기록과 규정 준수 문서를 저장하기 위해 Amazon S3를 사용하고 있습니다. S3 bucket은 최소 권한 원칙에 따라 특정 의료 규정 준수 팀 IAM user에게만 액세스를 제한하는 bucket policy를 구현합니다. 이 의료 기관의 관리자들은 S3 bucket에 있는 중요한 환자 기록이 우발적으로 삭제될 것을 우려하고 있으며, 의도치 않은 삭제로부터 이러한 문서를 보호하기 위해 더 안전한 솔루션을 구현해야 합니다. 환자 의료 기록을 보호하기 위해 solutions architect는 무엇을 권장해야 합니까?

정답입니다. S3 Versioning은 이전 버전을 보존하고 삭제를 delete marker로 변환하여 우발적으로 삭제된 환자 기록을 복구할 수 있게 해줍니다. MFA Delete는 object 버전을 영구적으로 삭제하거나 versioning을 일시 중지하기 위해 MFA를 요구하는 추가 제어를 제공하여, 인적 오류나 손상된 자격 증명으로 인한 돌이킬 수 없는 삭제 위험을 줄입니다. 이는 '우발적 삭제' 및 '의도치 않은 제거' 문제를 직접적으로 해결합니다.

오답입니다. IAM user 로그인에 MFA를 활성화하면 인증 보안이 향상되지만, 본질적으로 object 삭제를 방지하거나 복구 메커니즘을 제공하지는 않습니다. policy에서 허용하는 경우 user(또는 애플리케이션)는 여전히 object를 삭제할 수 있으며, 삭제가 발생하면 versioning이 활성화되어 있지 않은 한 데이터는 사라집니다. 또한 user에 대한 MFA는 S3의 삭제 작업에 대해 MFA를 구체적으로 강제하지 않습니다.

오답입니다. S3 Lifecycle policy는 IAM user 계정이 아닌 bucket(또는 접두사/태그)에 구성되며, IAM 스타일의 거부 제어 역할을 하기보다는 전환/만료를 관리합니다. s3:DeleteObject를 거부하는 것은 IAM/bucket policy를 통해 수행해야 하지만, 이는 합법적인 삭제를 차단하며 우발적인 덮어쓰기로부터 복구하는 데 여전히 도움이 되지 않습니다. 또한 강력한 복구 경로를 제공하지 않습니다.

오답입니다. SSE-KMS 암호화는 데이터 기밀성을 보호하고 object를 해독/읽을 수 있는 사람을 제한할 수 있지만, object 삭제를 방지하지는 않습니다. 삭제에는 해독이 필요하지 않으므로 s3:DeleteObject 권한이 있는 user는 KMS 권한에 관계없이 암호화된 object를 여전히 삭제할 수 있습니다. 이 옵션은 콘텐츠에 대한 액세스를 다루며, 의도치 않은 제거로부터의 보호를 다루지 않습니다.

문제 분석

핵심 개념: 이 질문은 우발적이거나 의도치 않은 삭제에 대비한 Amazon S3 데이터 보호 제어를 테스트합니다. 주요 S3 기능은 Versioning(이전 object 버전을 유지하기 위함)과 MFA Delete(버전을 영구적으로 삭제하거나 versioning을 일시 중지하기 위해 multi-factor authentication을 요구하기 위함)입니다. 정답인 이유: S3 Versioning을 활성화하면 object가 삭제될 때 S3가 데이터를 즉시 제거하지 않고 delete marker를 추가하여 이전 버전을 보존합니다. 이를 통해 관리자는 delete marker를 제거하거나 이전 버전을 복원하여 환자 기록을 복구할 수 있습니다. MFA Delete를 추가하면 버전이 지정된 object 삭제 및 versioning 상태 변경 시 MFA를 요구하여 삭제 보호를 더욱 강화하며, 손상된 자격 증명이나 운영자의 실수로 인해 중요한 기록이 영구적으로 제거될 위험을 줄입니다. 이는 보존 및 복구 가능성이 필수적인 의료 기록에 특히 적합합니다. 주요 AWS 기능: 1) S3 Versioning: 동일한 bucket에 object의 여러 변형을 유지하여 우발적인 삭제/덮어쓰기로부터 롤백 및 복구를 가능하게 합니다. 2) MFA Delete: object 버전을 영구적으로 삭제하거나 versioning을 일시 중지하려면 MFA가 필요합니다(bucket 수준에서 구성되며, 일반적으로 root user 또는 승인된 프로세스를 통해 수행됨). 3) 최소 권한 bucket policy는 여전히 유용하지만, 삭제가 허용된 후에는 본질적으로 복구 가능성을 제공하지 않습니다. 일반적인 오해: 'IAM user에 MFA 활성화'로 충분하다고 생각하기 쉽지만, 로그인 시의 MFA는 자격 증명이 오용될 경우 프로그래밍 방식의 삭제를 방지하지 못하며 복구 기능도 제공하지 않습니다. 또 다른 오해는 암호화(SSE-KMS)가 삭제를 방지한다는 것입니다. 암호화는 기밀성을 보호할 뿐 가용성이나 복구 가능성을 보호하지는 않습니다. 또한 Lifecycle policy는 IAM user에게 연결할 수 없으며 액세스 제어 메커니즘으로 설계되지 않았습니다. 시험 팁: S3의 '우발적 삭제(accidental deletion)'에 대해서는 먼저 Versioning을 찾으십시오. 질문에서 영구 삭제를 방지하거나 삭제에 대한 추가 보증이 필요하다고 강조하는 경우 MFA Delete를 추가하십시오. 규정 준수/불변성 요구 사항의 경우 다른 질문에서는 S3 Object Lock(WORM)도 고려해야 하지만, 여기서는 옵션 중 가장 적합한 것이 Versioning + MFA Delete입니다. 참조: Amazon S3 Versioning 및 MFA Delete 설명서; AWS Well-Architected Framework (Security 및 Reliability 원칙: 데이터 보호, 복구 활성화).

7
문제 7

한 게임 회사가 AWS Fargate를 사용하는 Amazon ECS에서 리소스 집약적인 멀티플레이어 게임을 실행합니다. 이 게임은 짧은 트래픽 폭증(bursts)과 함께 연중무휴(24/7)로 사용 가능해야 합니다. 솔루션은 고가용성을 보장하고 트래픽 폭증을 비용 효율적으로 처리해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

로드 테스트 및 CloudWatch 크기 조정과 함께 Fargate만 사용하면 성능을 개선하고 일부 초과 프로비저닝을 줄일 수 있지만 더 저렴한 폭증 용량 계층을 도입하지는 않습니다. 기준선과 스파이크 모두에 대해 여전히 온디맨드 Fargate 요금을 지불합니다. 또한 "타사 로드 테스트"는 지속적이고 비용 효율적인 폭증 처리를 위한 아키텍처 레버가 아닙니다. 이는 확장/비용 전략이 아니라 일회성 검증 활동입니다.

이것이 가장 적합합니다. 고가용성을 위해 일반 Fargate에서 항상 켜져 있는 기준선을 실행하고, 스파이크 동안 비용을 줄이기 위해 Fargate Spot에서 폭증 용량을 스케일 아웃합니다. ECS capacity provider는 base/weight 전략을 지원하므로 서비스가 보장된 기준선을 유지하면서 추가 작업에 대해 Spot을 선호합니다. Spot이 중단되거나 사용할 수 없는 경우 기준선은 Fargate에 유지되며 ECS는 교체를 위해 Fargate로 대체(fall back)할 수 있습니다.

Fargate Spot에서 정상 상태를 실행하는 것은 Spot 작업이 짧은 예고와 함께 중단될 수 있고 Spot 용량을 사용할 수 없게 될 수 있기 때문에 연중무휴 게임에 위험합니다. 폭증에 온디맨드 Fargate를 사용하더라도 항상 켜져 있는 핵심 용량은 여전히 중단될 수 있으며 이는 가용성 요구 사항과 충돌합니다. 이 옵션은 비용을 최적화하지만 가장 중요한 안정성을 희생합니다.

Compute Optimizer는 낭비를 줄이기 위해 CPU/메모리 설정을 권장하는 데 도움이 될 수 있지만 비용 효율적인 폭증 처리라는 주요 요구 사항을 해결하지는 못합니다. Fargate만 사용하면 폭증 트래픽에 여전히 전체 온디맨드 요금이 부과됩니다. 또한 ECS/Fargate에 대한 Compute Optimizer 지원 및 권장 사항 품질은 다를 수 있습니다. 어쨌든 크기 조정만으로는 폭발적인 워크로드에서 오버플로 용량으로 Spot을 사용하는 것보다 일반적으로 영향이 적습니다.

문제 분석

Core Concept: 이 질문은 ECS capacity provider를 사용하여 Amazon ECS 및 AWS Fargate에서 비용 최적화되고 가용성이 높은 확장을 테스트하며, Fargate(온디맨드)와 Fargate Spot(중단 위험이 있는 예비 용량) 간의 장단점을 다룹니다. Why the Answer is Correct: 게임은 연중무휴로 사용 가능해야 하며(안정적인 기본 용량은 신뢰할 수 있어야 함) 짧고 폭발적인 스파이크를 비용 효율적으로 처리해야 합니다. 가장 비용 효율적인 패턴은 가용성과 예측 가능한 용량을 보장하기 위해 일반 Fargate에서 정상 상태 서비스를 실행한 다음, 훨씬 저렴한 Fargate Spot을 폭증 용량으로 사용하는 것입니다. Spot 용량이 중단되거나 사용할 수 없게 되더라도 기본 서비스는 온디맨드 Fargate에서 정상 상태를 유지하여 연중무휴 가용성을 보존합니다. Key AWS Features: ECS capacity provider를 사용하면 Fargate 및 Fargate Spot 전반에 걸쳐 전략(base 및 weight)을 정의할 수 있습니다. 일반적인 접근 방식은 다음과 같습니다. - Base: Fargate의 N개 작업(보장된 기준선) - Weight: 스케일 아웃 시 Fargate Spot에 우선적으로 추가 작업 할당 이는 ECS Service Auto Scaling(CPU/메모리 또는 ALB 요청 수에 대한 대상 추적)과 통합됩니다. 복원력을 위해 여러 AZ에 걸쳐 여러 서브넷을 사용하고 서비스에 적절한 상태 확인 및 배포 설정이 있는지 확인합니다. Spot 중단 처리는 내재되어 있습니다. ECS는 중단된 Spot 작업을 중지하고 원하는 수에 따라 교체합니다. 혼합 전략을 사용하면 Spot이 제한될 경우 교체 작업이 Fargate에 배치될 수 있습니다. Common Misconceptions: "적절한 크기 조정(rightsizing)"(CloudWatch/Compute Optimizer)에 초점을 맞춘 옵션은 낭비를 줄일 수 있지만 폭증 비용 최적화를 직접적으로 해결하지는 않습니다. 또 다른 일반적인 함정은 정상 상태를 Spot에 두는 것입니다. 비용은 저렴하지만 Spot은 예고 없이 중단될 수 있으므로 연중무휴 가용성 요구 사항을 위반합니다. Exam Tips: "steady state + bursts" 및 "most cost-effective"를 보면 특히 상태 비저장 또는 수평 확장 가능한 워크로드의 경우 "온디맨드의 기준선, Spot의 폭증"을 생각하십시오. ECS/Fargate의 경우 시험에 친숙한 메커니즘은 Fargate 및 Fargate Spot을 Auto Scaling과 결합하는 ECS capacity provider 전략입니다. 질문에서 중단을 명시적으로 허용하지 않는 한 항상 Spot 사용을 중요하지 않거나 오버플로 용량에 매핑하십시오.

8
문제 8
(2개 선택)

한 금융 서비스 회사가 여러 Linux 서버에서 실행되는 컨테이너화된 마이크로서비스로 구성된 실시간 거래 플랫폼을 온프레미스에서 운영하고 있습니다. 이 플랫폼은 트랜잭션 데이터와 사용자 포트폴리오를 저장하는 MySQL 데이터베이스 클러스터에 연결됩니다. 현재 인프라는 거래 피크 시간대(시장 개장/폐장)에 확장을 위해 상당한 수동 개입이 필요하며, IT 팀은 기능 개발보다 인프라 유지 관리에 시간의 60%를 소비하고 있습니다. 이 회사는 운영 오버헤드를 줄이고, 용량 계획에 대한 우려를 없애며, 거래 피크 시 자동 확장을 활성화하고자 합니다. 솔루션은 고가용성을 유지하고 인프라 관리 부담을 줄이면서 컨테이너화된 애플리케이션을 지원해야 합니다. 솔루션 아키텍트가 이를 달성하기 위해 취해야 할 작업의 조합은 무엇입니까? (2개 선택)

정답입니다. Multi-AZ가 적용된 Amazon RDS for MySQL은 다른 AZ의 대기 인스턴스로의 동기식 복제 및 자동 장애 조치 기능을 갖춘 관리형 데이터베이스를 제공합니다. 서버에서 자체 관리하는 MySQL 클러스터에 비해 운영 오버헤드(패치, 백업, 모니터링 통합)를 줄여줍니다. 이는 상태 저장 트랜잭션 데이터 스토어에 대한 고가용성 및 인프라 관리 감소 요구 사항을 직접적으로 지원합니다.

오답입니다. Amazon EC2 Auto Scaling 그룹에서 컨테이너를 실행하면 용량을 확장할 수 있지만 용량 계획이나 인프라 관리가 제거되지는 않습니다. 팀은 여전히 EC2 인스턴스, AMI, OS 패치, 컨테이너 런타임/에이전트 업데이트 및 클러스터 크기 조정을 관리해야 합니다. 이는 운영 부담을 줄이고 거래 피크 기간 동안 수동 개입을 제거하려는 목표와 상충됩니다.

오답입니다. Amazon ElastiCache for Redis는 데이터베이스 로드를 줄이고 지연 시간을 개선하여 거래 플랫폼에 도움이 될 수 있지만, 용량 계획 제거 및 인프라 관리 감소라는 주요 요구 사항을 해결하지는 못합니다. 또한 캐시 일관성/무효화 고려 사항과 추가적인 아키텍처 복잡성을 도입합니다. 문제에서는 캐싱이 필요한 읽기 중심의 병목 현상을 나타내지 않습니다.

오답입니다. Amazon CloudWatch 모니터링 및 경보는 가시성을 위해 중요하지만, 그 자체로는 자동 확장을 제공하거나 인프라 유지 관리를 줄이지 않습니다. 경보는 작업(예: 확장 정책)을 트리거할 수 있지만, 이 옵션에는 해당 확장 메커니즘을 구현하는 내용이 포함되어 있지 않습니다. 모니터링은 보완적인 것이지 명시된 운영 및 확장 요구 사항에 대한 핵심 솔루션이 아닙니다.

정답입니다. 컨테이너를 AWS Fargate의 Amazon ECS로 마이그레이션하면 서버 및 클러스터 용량을 관리할 필요가 없어집니다. ECS Service Auto Scaling은 CPU/메모리 또는 사용자 지정 지표를 기반으로 작업을 자동으로 확장하여 예측 가능한 시장 개장/폐장 스파이크를 처리할 수 있습니다. 이는 컨테이너화된 마이크로서비스를 계속 실행하면서 자동 확장, 운영 오버헤드 감소 및 용량 계획 제거에 대한 요구 사항을 충족합니다.

문제 분석

핵심 개념: 이 질문은 온프레미스의 컨테이너 기반 피크 중심 워크로드를 최소한의 운영으로 고가용성 및 자동 확장을 제공하는 관리형 AWS 서비스로 마이그레이션하는 것을 테스트합니다. 핵심 서비스는 마이크로서비스를 위한 Amazon ECS와 함께 사용하는 AWS Fargate(서버리스 컨테이너)와 관리형 고가용성 관계형 데이터베이스를 위한 Multi-AZ가 적용된 Amazon RDS for MySQL입니다. 정답인 이유: 옵션 E(Fargate의 ECS)는 EC2 호스트 관리, OS 패치 또는 클러스터 용량 계획을 수행할 필요성을 제거합니다. 작업 CPU/메모리를 정의하고 ECS Service Auto Scaling(CPU/메모리에 대한 대상 추적 또는 사용자 지정 CloudWatch 지표)을 사용하여 시장 개장/폐장 시 스케일 아웃하고 이후에 스케일 인합니다. 이는 컨테이너를 지원하면서 "용량 계획에 대한 우려 제거" 및 "인프라 관리 부담 감소"를 직접적으로 해결합니다. 옵션 A(RDS for MySQL Multi-AZ)는 데이터베이스 관리 작업(백업, 패치, 모니터링 통합)을 오프로드하고 자동 장애 조치와 함께 다른 AZ의 대기 인스턴스로의 동기식 복제를 통해 고가용성을 제공합니다. 이는 운영 오버헤드를 줄이고 트랜잭션 및 포트폴리오 데이터에 대한 복원력을 향상시킵니다. 주요 AWS 기능: - AWS Fargate: 컨테이너를 위한 서버리스 컴퓨팅; EC2 관리 불필요; ECS 서비스, 작업용 IAM 역할 및 ALB와 통합. - ECS Service Auto Scaling: 대상 추적 정책; 예약된 확장은 예측 가능한 시장 이벤트와 일치시킬 수도 있습니다. - Amazon RDS for MySQL Multi-AZ: 자동 장애 조치, 관리형 백업, 유지 관리 기간 및 CloudWatch 지표. - 복원력 모범 사례: 상태 저장 구성 요소(데이터베이스) 및 수평 확장 가능한 상태 비저장 서비스(마이크로서비스)를 위한 Multi-AZ 설계. 일반적인 오해: EC2 Auto Scaling 그룹(옵션 B)은 확장이 가능하지만 여전히 AMI 수명 주기 관리, 패치 적용, 클러스터 크기 조정 및 용량 계획이 필요하므로 인프라 관리를 최소화하려는 목표에 어긋납니다. ElastiCache(옵션 C)는 성능을 향상시킬 수 있지만 그 자체로 확장/운영 부담을 없애지는 못하며 캐시 무효화의 복잡성을 추가합니다. 문제에서 요구하지도 않습니다. CloudWatch 경보(옵션 D)는 가시성을 향상시키지만 확장 작업과 결합하지 않는 한 본질적으로 자동 확장을 제공하거나 유지 관리를 줄이지는 않습니다. 시험 팁: 요구 사항이 "운영 오버헤드 감소", "용량 계획 없음" 및 "컨테이너"를 강조하는 경우 EC2 기반 컨테이너 호스팅보다 Fargate의 ECS(또는 Fargate의 EKS)를 기본으로 선택하십시오. 최소한의 관리로 고가용성이 필요한 MySQL의 경우 RDS Multi-AZ를 선택하십시오. 각 요구 사항을 명시적으로 매핑하십시오: 컴퓨팅 운영 감소를 위한 서버리스 컨테이너; 복원력 있는 상태를 위한 관리형 Multi-AZ 데이터베이스.

9
문제 9

글로벌 전자 상거래 플랫폼이 5개의 새로운 리전에서 동시에 운영을 시작합니다. 이 플랫폼은 현재 200만 명의 고객에게 서비스를 제공하고 있으며 6개월 이내에 800만 명의 고객에 도달할 것으로 예상합니다. 솔루션 아키텍트는 다양한 팀(Development, Operations, Marketing, Finance, Customer Support)에 걸쳐 150명 이상의 신규 직원을 위한 액세스 관리를 설정해야 합니다. 아키텍트는 팀 기능별로 사용자를 IAM 그룹으로 구성할 계획입니다. 신규 사용자에게 권한을 부여하는 가장 안전한 추가 작업은 무엇입니까?

SCP는 멤버 계정 또는 OU에 대한 계정 수준 가드레일(최대 권한)을 정의하는 데 사용되는 AWS Organizations 기능입니다. 사용자에게 권한을 부여하지 않으며 IAM 정책이 허용할 수 있는 범위를 제한할 뿐입니다. SCP는 안전한 다중 계정 전략의 일부가 될 수 있지만, 새로운 IAM 사용자에게 팀 기반 권한을 부여하는 올바른 메커니즘은 아닙니다.

IAM 역할은 IAM 그룹에 연결할 수 없습니다. 역할은 사용자, 서비스 또는 페더레이션 자격 증명에 의해 STS를 통해 수임되며, 정책에서 sts:AssumeRole을 부여하여 사용자가 역할을 수임하도록 허용할 수 있습니다. 역할 수임은 유효한 패턴이지만 "해당 IAM 그룹에 역할을 연결"한다는 설명은 IAM의 기능이 아니므로 이 옵션은 오답입니다.

최소 권한 IAM 정책을 생성하고 이를 IAM 그룹에 연결하는 것은 직무별로 많은 직원에게 권한을 부여하는 표준적이고 안전하며 확장 가능한 방법입니다. 사용자는 그룹 멤버십을 통해 권한을 상속받으므로 온보딩/오프보딩이 간소화되고 구성 오류가 줄어듭니다. 이는 최소 권한을 직접적으로 구현하며 사람의 액세스를 관리하기 위한 IAM 모범 사례와 일치합니다.

권한 경계는 역할(또는 사용자)이 받을 수 있는 최대 권한을 설정하며, 이는 위임된 관리 및 권한 에스컬레이션 방지에 유용합니다. 그러나 경계 자체는 권한을 부여하지 않으므로 여전히 자격 증명 기반 정책이 필요합니다. 이 시나리오의 주요 요구 사항은 그룹을 통해 팀 권한을 안전하게 부여하는 것이므로, 최소 권한 정책을 그룹에 연결하는 것에 비해 경계는 가장 적합한 "추가 작업"이 아닙니다.

문제 분석

핵심 개념: 이 질문은 AWS IAM 자격 증명 기반 액세스 관리 모범 사례를 테스트합니다. 즉, IAM 그룹에 연결된 IAM 정책을 사용하여 권한을 할당하고, 최소 권한을 따르며, 많은 사용자를 위한 액세스 제어를 확장하는 방법을 묻습니다. 또한 IAM 그룹이 할 수 있는 것과 할 수 없는 것(그룹에는 역할을 "연결"할 수 없음)에 대한 이해를 암시적으로 테스트합니다. 정답인 이유: 직무별로 구성된 많은 신규 직원에게 권한을 부여하는 가장 안전하고 표준적인 접근 방식은 최소 권한 IAM 정책을 생성하고 해당 정책을 해당 IAM 그룹(예: Dev, Ops, Finance)에 연결하는 것입니다. 사용자는 그룹 멤버십을 통해 권한을 상속받으므로 관리가 중앙 집중화되고, 드리프트가 감소하며, 신속한 온보딩/오프보딩이 지원됩니다. 이는 AWS 보안 모범 사례 및 AWS Well-Architected 보안 원칙(최소 권한 구현 및 대규모 자격 증명 관리)과 일치합니다. 주요 AWS 기능: - IAM 그룹: 그룹에 정책을 연결하고 사용자를 추가/제거하여 대규모로 권한을 관리합니다. - 고객 관리형 IAM 정책: 각 팀의 직무에 맞게 조정된 재사용 가능하고 버전 제어가 가능한 정책입니다. - 최소 권한 기법: 최소한의 작업/리소스로 시작하고, 가능한 경우 리소스 수준 권한을 사용하며, 조건(예: aws:RequestedRegion, MFA 조건, 소스 IP, 태그 기반 액세스 제어)을 추가합니다. - 직무 분리: 팀별로 고유한 정책을 사용하여 광범위한 공유 권한을 방지합니다. 일반적인 오해: - SCP(옵션 A)는 AWS Organizations에서 계정/OU에 대한 가드레일을 설정하기 위한 것이며, IAM 사용자에게 권한을 부여하기 위한 것이 아닙니다. SCP는 권한을 부여하지 않으며, 자격 증명 정책이 허용할 수 있는 범위를 제한할 뿐입니다. - "그룹에 역할 연결"(옵션 B)은 IAM의 작동 방식이 아닙니다. 그룹은 역할을 자동으로 수임할 수 없습니다. 역할은 sts:AssumeRole을 통해 보안 주체(사용자, 서비스, 페더레이션 자격 증명)가 수임합니다. - 권한 경계(옵션 D)는 강력하지만 주로 관리를 위임하고 역할/사용자의 최대 권한을 제한하기 위한 것입니다. 자격 증명 정책을 통해 권한을 부여해야 하는 필요성을 대체하지 않으며, 주어진 시나리오에서 가장 중요한 "가장 안전한" 다음 단계가 아닙니다. 시험 팁: - 기억하세요: IAM 정책은 권한을 부여하고, SCP 및 권한 경계는 최대 한도를 설정합니다. - 직원 액세스의 경우 실제 설계에서는 IAM Identity Center(SSO)를 선호하지만, 시험에서 그룹이 명시적으로 언급된 경우 "IAM 그룹 + 최소 권한 정책"이 표준 정답입니다. - 옵션에서 그룹에 역할을 연결할 것을 제안한다면 이를 오답의 신호로 간주하세요. 그룹에는 역할이 아닌 정책을 연결합니다.

10
문제 10

회사는 Amazon CloudFront distribution이 SSL/TLS certificate를 사용하도록 구성하려고 합니다. 회사는 도메인 이름(예: 'www.example.com')을 소유하고 있으며 기본 CloudFront 도메인 이름 대신 이를 사용하려고 합니다. 회사는 custom domain에 대한 certificate를 배포해야 하며 추가 비용을 피하고자 합니다. 추가 비용 발생 없이 certificate를 배포할 수 있는 솔루션은 무엇입니까? 추가 비용 발생 없이 certificate를 배포할 수 있는 솔루션은 무엇입니까?

정답입니다. CloudFront는 ACM certificate가 us-east-1(N. Virginia)에 있어야 합니다. ACM의 Amazon 발급 public certificate는 추가 비용(certificate 요금 없음) 없이 제공되며 CloudFront와 직접 통합됩니다. DNS 또는 이메일 validation 후 certificate를 distribution에 연결하여 추가 certificate 비용 없이 www.example.com에 대한 HTTPS를 활성화할 수 있습니다.

오답입니다. Amazon 발급 private certificate는 ACM Private CA를 사용함을 의미합니다. ACM Private CA는 추가 비용(월별 CA 요금 및 certificate당 요금)을 발생시킵니다. 또한 private certificate는 내부 PKI 용도로 사용되며 기본적으로 퍼블릭 인터넷 신뢰에는 적합하지 않습니다. us-east-1이 CloudFront에 올바른 리전이더라도 이 옵션은 “추가 비용 방지” 요구 사항을 충족하지 못합니다.

오답입니다. ACM public certificate는 무료이지만 CloudFront는 us-east-1에서 요청/가져온 ACM certificate만 사용할 수 있습니다. us-west-1의 certificate는 CloudFront distribution에서 선택 가능한 certificate로 표시되지 않습니다. 이는 일반적인 시험 함정입니다. 서비스는 글로벌이지만 certificate는 특정 리전에 있어야 합니다.

오답입니다. 이 옵션은 두 가지 이유로 틀렸습니다. (1) ACM Private CA private certificate는 추가 비용이 발생하여 “추가 비용 방지” 요구 사항을 위반하며, (2) 어쨌든 CloudFront는 us-west-1의 ACM certificate를 사용할 수 없습니다. 비용을 무시하더라도 리전 제약으로 인해 이 certificate를 CloudFront와 함께 사용할 수 없습니다.

문제 분석

핵심 개념: 이 질문은 Amazon CloudFront custom domain 이름(alternate domain names/CNAMEs)과 함께 SSL/TLS certificate를 사용하는 방법과 CloudFront에 대한 AWS Certificate Manager (ACM) 요금 및 리전 요구 사항이 어떻게 작동하는지 테스트합니다. 정답인 이유: CloudFront distribution에서 www.example.com과 같은 custom domain에 대해 HTTPS를 제공하려면 ACM certificate(또는 가져온 certificate)를 distribution에 연결해야 합니다. CloudFront의 경우 ACM certificate는 US East (N. Virginia) Region(us-east-1)에서 요청(또는 가져오기)해야 합니다. Public ACM certificate는 추가 비용 없이 발급됩니다. 따라서 us-east-1에서 Amazon 발급 public certificate를 요청하면 추가 certificate 비용 없이 CloudFront용 certificate가 배포됩니다. 주요 AWS 기능: - CloudFront Alternate Domain Names (CNAMEs): CloudFront가 기본 *.cloudfront.net 도메인 대신 www.example.com에 대한 요청에 응답하도록 합니다. - ACM Public Certificates: CloudFront와 같은 AWS 서비스와 함께 사용할 때 발급 및 갱신이 무료입니다. - CloudFront의 리전 요구 사항: CloudFront는 글로벌 서비스이지만 us-east-1에서만 ACM certificate를 가져옵니다. - Validation: 일반적으로 Route 53(또는 DNS 공급자)의 DNS validation을 통해 도메인 소유권을 검증하며, 이는 운영상 더 간단하고 자동 갱신을 지원합니다. 일반적인 오해: - “CloudFront certificate는 어느 리전에서나 작동한다”: 오답입니다. us-west-1(또는 us-east-1 이외의 리전)의 certificate는 CloudFront distribution용으로 선택할 수 없습니다. - “Private certificate도 무료이다”: 오답입니다. ACM Private CA(private certificate 발급에 사용됨)에는 지속적인 비용(월별 CA 요금 및 certificate당 요금)이 발생합니다. 또한 private certificate는 일반적으로 퍼블릭 인터넷 연결 CloudFront 엔드포인트가 아닌 내부/프라이빗 PKI 용도로 사용됩니다. 시험 팁: - 암기: CloudFront + ACM certificate는 반드시 us-east-1에 있어야 합니다. - 비용과 복잡성을 피하기 위해 인터넷 연결 도메인에는 public ACM certificate를 선호하십시오. - “추가 비용 방지(avoid additional costs)”라는 문구가 보이면 ACM Private CA 옵션을 제외하십시오. - custom domain을 사용할 때 CloudFront distribution을 가리키는 DNS(예: Route 53 ALIAS/AAAA)도 필요하다는 점을 기억하십시오. 하지만 여기서는 certificate 선택이 핵심 테스트 포인트입니다.

합격 후기(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 #2

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

Practice Test #3

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

Practice Test #4

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

Practice Test #5

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.