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

Practice Test #2

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

회사는 중요한 Amazon Machine Image(AMI)를 많이 저장합니다. 우발적으로 삭제된 AMI를 최소한의 노력으로 신속하게 복구할 수 있는 솔루션이 필요합니다. 우발적인 삭제로부터 AMI/스냅샷을 보호하고 쉽게 복구할 수 있도록 해야 합니다. 요구 사항을 충족하는 솔루션은 무엇입니까?

AMIs의 EBS snapshots를 생성하여 다른 account에 저장하면 기본 block data는 보호할 수 있지만, AMI registration 자체는 보존되지 않습니다. 복구하려면 회사는 올바른 snapshots를 식별하고 수동으로 새 AMI를 다시 등록해야 하므로 운영 단계와 복잡성이 추가됩니다. 이는 AMI를 직접 복사하는 것보다 덜 편리합니다. 따라서 최소한의 노력으로 쉬운 recovery라는 요구 사항을 가장 잘 충족하지는 못합니다.

AMIs를 다른 AWS account로 주기적으로 복사하면 연결된 EBS snapshots를 포함한 전체 AMI 리소스를 격리된 위치에서 보호할 수 있습니다. source AMI가 실수로 삭제되더라도 backup account에는 여전히 시작 가능한 복사본이 남아 있어 원래 account로 다시 공유하거나 다시 복사할 수 있습니다. 자동화가 이루어지면 비교적 적은 지속적 노력으로 실용적인 recovery 경로를 제공합니다. 또한 실수로 인한 삭제나 관리 실수에 대비해 account 수준의 격리를 사용하는 방식으로 중요한 자산을 보호하는 AWS 모범 사례와도 일치합니다.

Recycle Bin retention rule은 적절히 구성된 경우 삭제된 EBS snapshots와 일부 EBS-backed AMIs를 보존하는 데 도움이 될 수 있지만, 중요한 AMIs를 폭넓게 복구 가능하도록 보호하는 가장 강력한 답은 아닙니다. 이는 사전에 retention rules가 설정되어 있어야 하며, 별도의 backup account가 제공하는 account 격리 이점도 없습니다. 많은 시험 시나리오에서 Recycle Bin은 중요한 machine images의 전체 backup 보호보다는 snapshot 또는 AMI undelete retention 사용 사례에 더 적합합니다. 문제는 쉬운 recovery와 함께 AMIs와 snapshots를 보호하는 것을 묻고 있으므로, cross-account AMI copy가 더 완전한 솔루션입니다.

AMIs는 Cross-Region Replication을 위해 S3 bucket에 objects로 업로드하여 저장되지 않습니다. AMI는 EC2 image metadata와 기본 snapshots(일반적으로 EBS snapshots)에 대한 참조로 구성됩니다. AWS는 accounts 또는 regions 간에 AMIs를 복제하기 위해 S3 CRR이 아니라 AMI copy 기능을 제공합니다. 이 선택지는 기술적으로 틀렸으며 AWS에서 AMIs가 관리되는 방식에 대한 오해를 반영합니다.

문제 분석

핵심 개념: 이 문제는 중요한 Amazon Machine Images (AMIs)를 실수로 삭제하는 것으로부터 보호하면서, 복구는 간단하게 유지하고 운영 노력은 낮게 유지하는 것에 관한 것입니다. 핵심 아이디어는 AMI의 복구 가능한 복사본을 별도의 AWS account에 유지하여 원본 AMI가 삭제되더라도 회사가 backup account에서 이를 복원하거나 다시 복사할 수 있도록 하는 것입니다. Cross-account AMI copy는 AMI와 연결된 snapshots를 함께 보존하므로 일반적인 AWS 보호 패턴입니다. 정답인 이유: AMIs를 다른 AWS account로 주기적으로 복사하면 전체 AMI 리소스에 대해 간단한 backup 및 recovery 메커니즘을 제공합니다. 단순히 기본 snapshots만이 아닙니다. 기본 account에서 AMI가 실수로 삭제되더라도 backup 복사본은 secondary account에 계속 남아 있으며, 다시 공유하거나 복사해 올 수 있습니다. 이 접근 방식은 한 account에서의 사용자 실수로 인한 영구 손실 위험을 줄여 주며, snapshots로부터 수동으로 AMIs를 다시 구축하는 것보다 운영하기가 더 쉽습니다. 주요 특징: - AMI copy에는 image로부터 instances를 시작하는 데 필요한 연결된 EBS snapshots가 포함됩니다. - 별도의 AWS account는 source account에서의 실수로 인한 삭제로부터 격리를 제공합니다. - 이 프로세스는 AWS Backup, EventBridge, Lambda 또는 custom scripts를 사용하여 일정에 따라 자동화할 수 있습니다. - 복구 시 재구성이 필요하지 않고 이미 사용 가능한 image로서 AMI가 존재하므로 더 간단합니다. 흔한 오해: - Recycle Bin은 삭제된 리소스의 보존에 유용하지만, 문제가 삭제된 AMIs 또는 snapshots에 대한 retention rules에 명시적으로 초점을 맞추지 않는 한 포괄적인 AMI 보호에 대한 예상 정답은 항상 아닙니다. 또한 사전 구성이 필요하며 별도 account만큼의 격리 이점을 제공하지 않을 수 있습니다. - snapshots만 복사하면 AMI registration metadata는 보존되지 않으므로, AMI를 다시 생성하려면 추가 단계가 필요합니다. - AMIs는 Cross-Region Replication을 위해 S3 buckets에 업로드되지 않습니다. 시험 팁: 문제가 중요한 AMIs를 실수로 삭제하는 것으로부터 보호하고 recovery를 가능하게 하는 것을 강조한다면, AMI를 복구 가능한 artifact로 보존하는 솔루션을 우선적으로 선택하세요. Cross-account AMI copies는 machine images에 대한 전형적인 AWS backup 패턴입니다. 반대로 문제가 policy 기반 undelete를 통해 삭제된 EBS snapshots 또는 삭제된 AMIs의 보존을 구체적으로 언급한다면, Recycle Bin이 더 관련성이 높아집니다.

2
문제 2
(2개 선택)

한 의료 기관이 3개의 다른 시설에 걸쳐 15대의 Linux 기반 연구 데이터 서버를 운영하고 있습니다. 각 서버에는 규정 준수 목적으로 보존해야 하는 엄격한 POSIX 파일 권한 및 심볼릭 링크(symbolic links)가 포함된 중요한 환자 연구 데이터가 있습니다. 이 기관은 고성능 컴퓨팅 워크로드를 위해 모든 연구 데이터를 Amazon FSx for Lustre 파일 시스템으로 통합해야 합니다. 마이그레이션 중에 POSIX 권한, 심볼릭 링크 및 메타데이터를 보존해야 합니다. 총 데이터 크기는 약 500TB입니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까? (2개 선택)

오답입니다. AWS DataSync는 이 선택지에서 설명한 방식처럼 데이터를 Amazon FSx for Lustre로 직접 전송하는 것을 지원하지 않습니다. FSx for Lustre가 DataSync 대상 용도의 NFS endpoint를 노출한다는 설명은 부정확합니다. FSx for Lustre는 Lustre protocol을 사용하며 DataSync의 일반적인 NFS 대상처럼 동작하지 않습니다. 따라서 지원되는 시나리오에서 DataSync가 POSIX metadata를 보존하더라도, 전송 경로 자체가 유효하지 않으므로 이 선택지는 선택할 수 없습니다.

오답입니다. rsync를 사용해 파일을 Amazon S3로 복사하면 파일시스템 데이터가 object로 변환되며, POSIX permissions, ownership, symbolic links를 기본 파일시스템 구성 요소로서 보존하지 못합니다. 이런 방식으로 데이터가 S3에 staging되면, DataSync를 사용하기도 전에 필요한 metadata 정확성이 이미 손실되었을 수 있습니다. 따라서 POSIX attributes와 symlinks의 보존을 명시적으로 요구하는 compliance에 민감한 마이그레이션에는 이 선택지가 적합하지 않습니다.

정답입니다. 여러 시설에 분산된 500 TB 마이그레이션의 경우, 네트워크 전송이 느리거나 운영상 위험할 수 있다면 오프라인 대량 수집 방식이 적절할 수 있습니다. 데이터를 AWS로 배송하여 Amazon S3로 가져오는 것은 인정된 대규모 전송 패턴이며, 이후 AWS DataSync를 사용해 관리형 방식으로 데이터를 다음 단계로 이동시킬 수 있습니다. 나열된 선택지 중에서 이것은 매우 큰 데이터셋에 대한 AWS 관리형 대량 마이그레이션 서비스와 부합하는 두 가지 옵션 중 하나입니다. 비록 S3 staging이 기본 파일시스템 semantics를 보존하는 데 이상적이지는 않지만 말입니다.

정답입니다. AWS Snowball Edge Storage Optimized 디바이스는 온프레미스 환경에서의 대규모 데이터 마이그레이션을 위해 설계되었으며 수백 테라바이트의 데이터에 매우 적합합니다. Snowball Edge와 함께 DataSync를 사용하면 관리형 전송 워크플로를 제공하고, 파일 기반 마이그레이션 중 permissions, ownership, timestamps, symbolic links와 같은 파일 metadata를 보존합니다. 세 개의 시설 전체에 여러 디바이스를 주문하면 병렬 데이터 수집이 가능하고 WAN bandwidth 의존도를 줄일 수 있습니다.

오답입니다. AWS Snowmobile은 일반적으로 수 페타바이트 이상과 같은 극도로 큰 마이그레이션을 위한 서비스이므로 500 TB 워크로드에는 과도합니다. 또한 이 선택지는 Amazon S3를 중간 staging 계층으로 도입하는데, 이는 POSIX permissions와 symbolic links의 엄격한 보존이 필요한 경우 이상적이지 않습니다. 이 데이터 볼륨과 운영 시나리오에는 Snowball Edge가 더 적절한 오프라인 전송 서비스입니다.

문제 분석

핵심 개념: 이 문제는 POSIX permissions, symbolic links, metadata를 보존하면서 매우 큰 온프레미스 Linux 데이터셋을 Amazon FSx for Lustre로 마이그레이션하는 것에 관한 것입니다. 핵심 과제는 여러 시설에 걸쳐 있는 500 TB 규모의 파일시스템 인지 전송을 처리할 수 있는 AWS 마이그레이션 서비스를 선택하는 것입니다. DataSync는 파일 전송 중 POSIX metadata를 보존하도록 설계된 AWS 서비스이며, 네트워크 기반 전송이 비현실적인 경우 Snowball Edge를 사용할 수 있습니다. 흔한 시험 함정은 모든 AWS 파일 서비스가 DataSync의 직접 대상이라고 가정하거나, S3 staging이 항상 별다른 조건 없이 파일시스템 semantics를 보존한다고 생각하는 것입니다. 정답인 이유: Option D가 정답인 이유는 Snowball Edge Storage Optimized 디바이스를 각 사이트에 배치하고 DataSync와 함께 사용하여 대규모 파일 마이그레이션을 수행하면서 파일 attributes를 보존할 수 있기 때문입니다. Option C도 제공된 선택지의 맥락에서는 허용 가능한 또 다른 정답입니다. 네트워크 전송에 제약이 있을 수 있는 500 TB 규모에서는 데이터를 AWS로 물리적으로 배송하여 대량 수집하는 방식이 유효한 패턴이며, 이후 DataSync가 데이터를 다음 단계로 이동시킬 수 있기 때문입니다. S3는 기본 POSIX semantics를 보존하는 데 이상적이지 않지만, 시험 스타일의 의도는 이 규모에 적합한 AWS 관리형 대량 전송 메커니즘을 식별하는 것입니다. 주요 기능: AWS DataSync는 지원되는 파일 기반 스토리지 시스템 간 전송 시 ownership, permissions, timestamps, symbolic links를 보존합니다. Snowball Edge Storage Optimized는 디바이스당 수십에서 수백 테라바이트에 적합하며 여러 시설에서 병렬로 사용할 수 있습니다. WAN bandwidth가 충분하지 않아 적시에 마이그레이션하기 어려운 경우에는 대량 오프라인 전송 서비스가 선호되는 경우가 많습니다. 흔한 오해: 대표적인 오해 중 하나는 DataSync가 모든 AWS 파일 서비스에 직접 쓸 수 있다고 생각하는 것입니다. 실제 지원 여부는 서비스별로 다릅니다. 또 다른 오해는 S3가 POSIX metadata에 대해 파일시스템과 동등한 staging 계층이라는 생각인데, 그렇지 않습니다. Snowmobile도 자주 과도하게 선택되지만, 이는 500 TB 워크로드가 아니라 수 페타바이트에서 엑사바이트 규모의 마이그레이션을 위한 서비스입니다. 시험 팁: 문제가 POSIX permissions와 symlinks를 강조하면, S3로의 rsync 같은 일반적인 object-copy 도구보다 DataSync와 파일 인지 마이그레이션 경로를 우선 고려하세요. 매우 큰 데이터셋의 경우 규모가 수백 테라바이트이면 Snowball Edge를, 수 페타바이트 이상일 때만 Snowmobile을 찾으세요. 또한 선택지에 언급된 마이그레이션 도구가 대상 서비스에 실제로 직접 지원되는지도 확인하세요.

3
문제 3

한 미디어 회사가 영화(1–10GB 파일)를 S3에 저장합니다. 스트리밍은 구매 후 5분 이내에 시작되어야 합니다. 최신 영화(20년 미만)는 오래된 영화보다 수요가 더 많습니다. 이 회사는 수요에 따라 호스팅 비용을 최소화하려고 합니다. 5분 가용성 목표를 충족하면서 비용을 최소화하는 스토리지 클래스 및 검색을 선택하십시오. 요구 사항을 충족하는 솔루션은 무엇입니까?

이 선택지는 S3 Standard가 immediate access를 제공하고 이후 IA로 전환하면 일부 비용을 줄일 수 있으므로 performance requirement는 충족합니다. 그러나 모든 콘텐츠가 가장 비싼 storage class에서 시작하므로, 오래된 영화의 수요가 명시적으로 더 낮다는 점을 고려하면 가장 cost-effective한 선택지는 아닙니다. 문제는 수요를 기준으로 hosting cost를 최소화하라고 묻고 있으며, 이 선택지는 오래된 콘텐츠에 대해 더 저렴한 archival storage를 활용하지 않습니다.

이 선택지는 오래된 영화에 대해 S3 Standard-IA에서 'standard retrieval'을 언급하고 있기 때문에 문제가 있습니다. 하지만 Standard-IA는 Glacier 스타일 retrieval tiers나 restore operations를 사용하지 않습니다. Standard-IA는 immediate access를 제공하므로 timing requirement를 충족할 수는 있지만, 이 표현은 service behavior에 대한 혼동을 드러냅니다. 더 중요한 점은, 매우 오래되고 수요가 낮은 영화에 대해서는 expedited retrieval이 가능한 Glacier Flexible Retrieval만큼 비용 효율적이지 않다는 것이며, 문제는 바로 그 방향으로 유도하고 있습니다.

정답입니다. S3 Intelligent-Tiering은 최신 영화에 적합한데, 최신 콘텐츠는 수요가 더 높고 변할 가능성도 있으며, Intelligent-Tiering은 immediate access performance를 희생하지 않고 비용을 자동으로 최적화할 수 있기 때문입니다. 오래된 영화의 경우, S3 Glacier Flexible Retrieval은 Standard 또는 Standard-IA와 비교해 storage cost를 크게 낮춥니다. expedited retrieval을 사용하면 archived objects를 약 1–5분 내에 restore할 수 있으므로, 구매 후 5분 이내에 streaming이 시작되어야 한다는 요구 사항과 일치합니다.

이 선택지는 S3 Glacier Flexible Retrieval의 bulk retrieval이 일반적으로 몇 분이 아니라 몇 시간이 걸리므로 5분 요구 사항을 충족하지 못합니다. Glacier Flexible Retrieval은 storage 측면에서는 비용 효율적이지만, 선택된 retrieval tier가 구매 직후 on-demand streaming을 제공하기에는 너무 느립니다. 따라서 명시된 availability target을 충족할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 access frequency와 필요한 retrieval time을 기준으로 Amazon S3 storage classes를 선택하는지를 평가합니다. 핵심 요구 사항은 구매 후 5분 이내에 streaming이 시작되어야 한다는 점이며, 오래된 영화는 수요가 더 낮으므로 더 저렴하게 저장되어야 합니다. 가장 적절한 설계는 최신 콘텐츠에는 frequent-access class를 사용하고, 오래된 콘텐츠에는 retrieval option이 5분 목표를 여전히 충족할 수 있는 경우에만 더 저렴한 archival class를 사용하는 것입니다. 정답인 이유: S3 Intelligent-Tiering은 access patterns가 변하더라도 storage cost를 자동으로 최적화하면서 immediate access를 계속 제공하므로 최신 영화에 적합합니다. 오래되어 수요가 낮은 영화의 경우, S3 Glacier Flexible Retrieval은 훨씬 낮은 storage cost를 제공하며, expedited retrieval은 1–5분 내 access를 위해 설계되어 명시된 availability target과 일치합니다. 제공된 보기 중에서, 이것은 5분 요구 사항을 충족하도록 의도된 retrieval mode와 더 저렴한 archival storage를 명시적으로 결합한 유일한 선택지입니다. 주요 기능: S3 Intelligent-Tiering은 millisecond access와 함께 automatic tiering을 제공하며, access patterns가 불확실하거나 가변적일 때 유용합니다. S3 Glacier Flexible Retrieval은 expedited, standard, bulk의 세 가지 restore tiers를 지원하며, expedited가 가장 빠르고 몇 분 내 긴급 retrieval을 위해 설계되었습니다. S3 Standard와 Standard-IA는 모두 immediate access를 제공하지만, Glacier classes는 restore latency를 허용할 수 있을 때 infrequently accessed objects의 storage cost를 크게 줄일 수 있습니다. 흔한 오해: 흔한 함정은 Glacier retrieval은 모두 너무 느리다고 가정하는 것이지만, expedited retrieval은 분 단위 access를 위해 특별히 존재합니다. 또 다른 오해는 Standard-IA에 'standard retrieval'과 같은 Glacier 스타일 retrieval modes가 있다고 보는 것인데, 그렇지 않습니다. Standard-IA는 restore operations가 필요 없으며 즉시 access됩니다. 또한 Glacier의 bulk retrieval은 거의 즉시 streaming해야 하는 요구 사항에는 너무 느립니다. 시험 팁: 문제가 짧은 retrieval SLA를 충족하면서 가장 낮은 비용을 요구할 때는, 가장 빠른 restore tier를 가진 archival class가 timing requirement를 충족할 수 있는지 비교하세요. 요구 사항이 분 단위일 때는 bulk retrieval이 포함된 선택지를 제거하세요. 또한 Glacier retrieval terms를 non-Glacier storage classes에 적용하는 것처럼 AWS terminology를 잘못 사용하는 distractors도 주의하세요.

4
문제 4

전자 상거래 회사가 지난 3년 동안 Amazon S3 버킷에 저장된 Apache Parquet 형식의 고객 트랜잭션 데이터 15TB를 축적했습니다. 데이터에는 구매 내역, 사용자 행동 분석 및 계절별 쇼핑 패턴이 포함됩니다. 마케팅 팀은 비즈니스 인텔리전스 보고서를 생성하고 전략적 의사 결정을 위한 고객 추세를 분석하기 위해 매월 이 데이터에 대해 SQL 쿼리를 실행해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

15TB의 분석용 Parquet 데이터를 Amazon RDS PostgreSQL로 마이그레이션하는 것은 일반적으로 비용 효율적이지 않습니다. RDS는 대규모 분석 및 전체 테이블 스캔이 아닌 OLTP에 최적화되어 있습니다. 지속적인 데이터베이스 인스턴스 가동 시간, 스토리지, 백업에 대한 비용을 지불해야 하며 상당한 튜닝(인덱스, 진공 청소)이 필요할 가능성이 높습니다. 마이그레이션 노력과 지속적인 운영 오버헤드는 S3에서 제자리에 쿼리하는 것에 비해 높습니다.

Redshift Spectrum은 S3의 데이터를 쿼리할 수 있지만 일반적으로 데이터 웨어하우징 워크로드를 위해 Amazon Redshift 클러스터와 함께 사용됩니다. 월별 보고의 경우 프로비저닝된 클러스터(또는 관리형 용량)에 대한 비용을 지불하는 것이 서버리스 쿼리당 지불 모델보다 더 비쌀 수 있습니다. Redshift는 간헐적인 임시 쿼리가 아니라 빈번하고 동시성이 높은 BI 및 복잡한 웨어하우스 요구 사항에 적합한 선택입니다.

AWS Glue 크롤러 + Glue Data Catalog + Amazon Athena는 S3의 Parquet 데이터에 대한 월별 SQL 쿼리를 위한 가장 비용 효율적인 솔루션입니다. Athena는 서버리스이며 스캔한 데이터당 요금을 청구하며, Parquet의 컬럼형 형식과 파티셔닝은 스캔한 바이트를 크게 줄일 수 있습니다. Glue는 중앙 집중식 스키마/메타데이터를 제공하므로 마케팅 팀은 데이터 세트를 이동하거나 복제하지 않고도 표준 SQL로 쿼리할 수 있습니다.

Spark SQL이 있는 Amazon EMR은 S3를 쿼리할 수 있으며 대규모 ETL, 기계 학습 및 복잡한 분산 처리에 탁월합니다. 그러나 월별 BI 스타일 SQL 쿼리의 경우 EMR은 일반적으로 클러스터 프로비저닝, 런타임 비용 및 운영 관리로 인해 비용 효율성이 떨어집니다. 임시 클러스터를 사용하더라도 간단한 대화형 SQL 보고를 위한 Athena보다 일반적으로 더 복잡하고 비쌉니다.

문제 분석

핵심 개념: 이 질문은 서버리스, 쿼리당 지불 SQL을 사용하여 Amazon S3(데이터 레이크)에 이미 저장된 데이터에 대한 비용 최적화된 분석을 테스트합니다. 주요 서비스는 AWS Glue Data Catalog(메타데이터) 및 Amazon Athena(S3에 대한 대화형 SQL)입니다. 정답인 이유: 회사는 S3에 15TB의 Parquet 데이터를 보유하고 있으며 매월 SQL 쿼리만 실행하면 됩니다. 가장 비용 효율적인 접근 방식은 항상 켜져 있는 클러스터를 피하고 대신 서버리스이며 스캔한 TB당 요금을 청구하는 Athena를 사용하는 것입니다. 데이터가 Apache Parquet(컬럼형, 압축)에 있기 때문에 Athena는 행 기반 형식보다 훨씬 적은 데이터를 스캔하여 쿼리 비용을 크게 줄일 수 있습니다. Glue 크롤러는 스키마를 유추하고 Glue Data Catalog에 테이블을 생성하여 데이터를 이동하지 않고도 표준 SQL로 S3 데이터 세트를 쿼리할 수 있도록 합니다. 주요 AWS 기능: Athena는 테이블 정의 및 파티션을 위해 AWS Glue Data Catalog와 통합됩니다. 파티셔닝(예: 연/월/일별) 및 Parquet 컬럼 프루닝은 스캔한 바이트와 비용을 줄입니다. Athena는 거버넌스를 위해 작업 그룹, 쿼리 결과 암호화 및 S3 출력 위치를 지원합니다. 이 패턴은 AWS Well-Architected 비용 최적화 원칙과 일치합니다. 사용한 만큼만 지불하고 데이터 처리를 최소화합니다. 일반적인 오해: Redshift Spectrum(옵션 B)은 S3를 쿼리할 수 있지만 일반적으로 기본 컴퓨팅을 위해 Redshift 클러스터(또는 최소한 프로비저닝/관리형 용량)가 필요하므로 간헐적인 월별 보고에는 비용 효율성이 떨어집니다. EMR/Spark(옵션 D)는 대규모 ETL에 강력하지만 주기적인 SQL 보고를 위해 클러스터를 실행하는 것은 일반적으로 Athena보다 더 비싸고 운영상 무겁습니다. RDS로 로드(옵션 A)하면 불필요한 데이터 이동, 스토리지, 인덱싱 및 지속적인 인스턴스 비용이 추가됩니다. RDS는 대규모 분석 스캔용으로 설계되지 않았습니다. 시험 팁: 데이터가 이미 S3에 있고 쿼리가 간헐적인 경우 가장 낮은 운영 오버헤드와 비용을 위해 Athena + Glue를 기본값으로 설정하십시오. Parquet/ORC 및 파티셔닝 단서를 찾으십시오. 이는 비용 최적화된 서버리스 분석 선택으로 Athena/Glue를 강력하게 나타냅니다. 복잡한 동시성 및 전용 웨어하우스와 함께 일관되게 고성능의 빈번한 BI 워크로드가 필요한 경우 Redshift를 선택하십시오.

5
문제 5
(2개 선택)

한 의료 연구 기관이 환자 연구 데이터와 임상 시험 결과를 Amazon S3 버킷에 저장합니다. 이 데이터에는 15년에 걸친 종단적 연구가 포함되어 있으며 5천만 달러 이상의 연구 비용 투자를 나타냅니다. 데이터 손실은 진행 중인 연구 및 규정 준수 요구 사항을 손상시킬 수 있으므로 연구원이나 관리 직원이 연구 데이터를 실수로 삭제할 수 없도록 해야 합니다. 솔루션 아키텍트가 우발적인 삭제를 방지하기 위해 구현해야 하는 단계의 조합은 무엇입니까? (2개 선택)

버전 관리를 활성화하면 객체의 이전 버전을 유지하여 우발적인 삭제를 방지할 수 있습니다. 삭제 작업은 기록 버전을 제거하는 대신 삭제 마커를 배치하므로 마커를 제거하거나 이전 버전을 복원하여 복구할 수 있습니다. 이는 데이터 복구를 위한 주요 S3 제어이며 우발적인 덮어쓰기/삭제 시나리오에 대해 일반적으로 테스트됩니다.

MFA Delete는 객체 버전을 영구적으로 삭제하거나 버전 관리를 일시 중지하기 위해 다중 인증을 요구합니다. 이는 삭제 권한이 있는 사용자에 의한 되돌릴 수 없는 삭제를 방지하여 우발적 및 악의적인 삭제 위험을 모두 줄입니다. MFA 없이 버전 자체가 영구적으로 제거되지 않도록 보호함으로써 버전 관리를 보완합니다.

버킷 정책은 s3:DeleteObject를 호출할 수 있는 사람을 제한할 수 있지만, 정책이 잘못 구성되거나 권한 있는 보안 주체에 의해 변경될 수 있거나 모든 삭제 경로(예: 버전 삭제)를 다루지 않을 수 있으므로 우발적인 삭제 방지를 위한 최선의 기본 제어는 아닙니다. 또한 정책은 삭제가 발생할 경우 복구를 제공하지 않으며 예방만 시도합니다.

기본 암호화(SSE-S3, SSE-KMS 또는 DSSE)는 객체가 S3에 저장될 때 암호화되도록 하여 미사용 데이터를 보호합니다. 암호화와 관련된 기밀성 및 규정 준수 요구 사항을 해결하지만 삭제를 방지하거나 삭제된 객체를 복구하는 메커니즘을 제공하지는 않습니다. 따라서 우발적인 삭제 방지를 위한 제어가 아닙니다.

수명 주기 정책은 전환 및 만료를 자동화합니다. 비용 최적화 및 보존 관리에 도움이 될 수 있지만 설정된 기간 후에 객체나 최신이 아닌 버전을 삭제할 수도 있습니다. 잘못 구성하면 의도하지 않은 데이터 손실 위험이 증가합니다. 수명 주기 규칙은 중요한 장기 연구 데이터의 우발적인 삭제에 대한 기본 안전 장치가 아닙니다.

문제 분석

Core Concept: 이 질문은 우발적인 삭제를 방지하거나 강력하게 완화하는 Amazon S3 데이터 보호 제어를 테스트합니다. 핵심 개념은 S3 Versioning(객체 수준 복구) 및 MFA Delete(파괴적인 작업에 대한 강력한 보호)입니다. Why the Answer is Correct: S3 Versioning을 활성화하면 객체를 덮어쓰거나 삭제할 때 S3가 이전 버전을 유지합니다. "삭제"는 삭제 마커(delete marker)가 되며 이전 버전은 복구 가능한 상태로 유지됩니다. 이는 마지막으로 알려진 양호한 버전을 복원할 수 있도록 하여 우발적인 삭제를 직접적으로 해결합니다. MFA Delete를 활성화하면 추가적인 안전 장치가 추가됩니다. 객체 버전을 영구적으로 삭제하거나 버전 관리를 일시 중지하려면 다중 인증(MFA)이 필요합니다. 이는 연구원이나 관리자가 API 자격 증명을 가지고 있더라도 MFA 디바이스 없이 되돌릴 수 없는 삭제를 수행하는 것을 방지하여 우발적이거나 승인되지 않은 파괴적인 작업의 위험을 크게 줄입니다. Key AWS Features: - S3 Versioning: 동일한 버킷에 객체의 여러 변형을 저장합니다. 삭제 시 삭제 마커가 추가되며 이전 버전을 복원할 수 있습니다. 이는 데이터 내구성 및 복구를 위한 기본 제어입니다. - MFA Delete: DeleteObjectVersion 및 버킷의 버전 관리 상태 변경에 MFA가 필요합니다. 버킷 수준에서 구성되며 우발적이거나 악의적인 영구 삭제를 방지하도록 특별히 설계되었습니다. - 모범 사례 정렬: 이러한 제어는 AWS Well-Architected Framework(Security Pillar: 데이터 보호, Reliability Pillar: 장애 복구)의 보안 및 데이터 보호 목표를 지원합니다. Common Misconceptions: 버킷 정책(옵션 C)은 삭제를 거부할 수 있지만 지나치게 광범위한 권한, 잘못된 구성 또는 권한 있는 역할에 의해 우회되는 경우가 많습니다. 또한 삭제가 발생할 경우 복구를 제공하지 않습니다. 기본 암호화(D)는 삭제가 아닌 기밀성을 보호합니다. 수명 주기 정책(E)은 실제로 데이터를 자동으로 삭제할 수 있으므로 잘못 구성하면 위험이 증가합니다. Exam Tips: S3에서 "cannot be accidentally deleted"의 경우 고전적인 쌍으로 "Versioning + MFA Delete"를 생각하십시오. Versioning은 복구를 제공합니다. MFA Delete는 영구 삭제 및 버전 관리 비활성화를 방지합니다. 질문에서 규제/중요 데이터 및 되돌릴 수 없는 손실을 강조하는 경우 MFA Delete는 강력한 신호입니다.

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

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

6
문제 6

한 금융 기술 스타트업이 Amazon EC2 인스턴스를 사용하여 실시간 사기 탐지 시스템을 운영하고 있습니다. 이 시스템은 Amazon SQS 대기열에서 트랜잭션 데이터를 처리하며, 피크 시간대(오전 9시 - 오후 6시)에는 약 50,000건, 비피크 시간대에는 15,000건의 트랜잭션을 분석합니다. 프로모션 이벤트 중에는 워크로드에 갑작스러운 스파이크가 발생하여 볼륨이 300-400% 증가할 수 있습니다. 사기 탐지 시스템은 중단이 발생할 경우 사기 트랜잭션이 탐지되지 않고 통과될 수 있으므로 다운타임에 대한 허용 오차 없이(zero tolerance) 연중무휴(24/7) 가용성을 유지해야 합니다. 이 시스템은 운영 비용을 최소화하면서 예측할 수 없는 트래픽 패턴을 처리해야 합니다. 이러한 요구 사항을 가장 비용 효율적으로 충족하는 솔루션은 무엇입니까?

전적으로 Spot Instances를 사용하는 것은 가장 비용이 적게 드는 컴퓨팅 옵션이지만, 명시된 신뢰성 요구 사항을 충족할 수 없습니다. Spot 용량은 언제든지 중단될 수 있으며 수요 급증(예: 프로모션 이벤트) 시 사용할 수 없을 수도 있습니다. "다운타임 허용 불가"인 사기 탐지 시스템의 경우 Spot에만 의존하면 처리 공백 및 SQS 백로그 증가라는 수용할 수 없는 위험이 발생합니다.

최대 용량에 대해 전적으로 Reserved Instances를 사용하면 안정적인 가용성과 예측 가능한 비용을 제공하지만 비용 효율적이지 않습니다. 일반적인 비피크 볼륨이 훨씬 낮음에도 불구하고 피크/예상 프로모션 이벤트 용량에 대해 연중무휴(24/7)로 비용을 지불하게 됩니다. 이는 상당한 오버프로비저닝 및 지출 낭비로 이어져 변동성이 큰 워크로드에 대한 비용 최적화 목표를 위반합니다.

기본 용량에 대한 Reserved Instances와 스파이크에 대한 Spot의 조합은 일반적인 비용 최적화 패턴이지만, 다운타임 허용 불가 요구 사항과 충돌합니다. 프로모션 스파이크 동안 Spot 중단 또는 Spot 용량 부족으로 인해 필요한 처리량으로의 확장이 방해받아 사기 검사가 지연되거나 누락될 수 있습니다. 이 옵션은 워크로드가 중단 및 백로그 지연을 허용할 수 있는 경우에만 적절합니다.

기본 용량에 대한 Reserved Instances와 스파이크에 대한 On-Demand의 조합은 신뢰성 및 비용 목표를 모두 가장 잘 충족합니다. 기본 수요는 할인된 약정 용량으로 충당되는 반면, 예측할 수 없는 스파이크는 Auto Scaling을 통해 고가용성 On-Demand 인스턴스로 처리됩니다. 이는 Spot 중단 위험을 피하고 항상 피크 용량에 대한 비용을 지불하는 것을 방지하여, 엄격한 24/7 가용성을 만족하면서도 가장 비용 효율적인 솔루션이 됩니다.

문제 분석

핵심 개념: 이 질문은 엄격한 가용성 요구 사항을 충족하면서 약정 기반 할인(Reserved Instances/Savings Plans)과 버스트 용량(On-Demand 또는 Spot)의 균형을 맞추는, 가변적이고 예측할 수 없는 워크로드를 가진 EC2에 대한 비용 최적화된 용량 계획을 테스트합니다. 정답인 이유: 시스템은 다운타임에 대한 허용 오차 없이 연중무휴(24/7)로 실행되어야 합니다. Spot 용량은 2분 전에 알림을 받고 중단될 수 있으며 가장 필요할 때(대규모 프로모션 스파이크 발생 시) 사용할 수 없을 수도 있으므로, 이 요구 사항은 Spot Instances의 사용을 강력하게 제한합니다. 가용성을 유지하면서 가장 비용 효율적인 접근 방식은 안정적이고 예측 가능한 기본 용량을 Reserved Instances(또는 최신 지침의 경우 Compute Savings Plans)로 충당하고, Auto Scaling 그룹을 통해 On-Demand Instances를 사용하여 스파이크에 대비해 스케일 아웃하는 것입니다. On-Demand는 중단 위험 없이 버스트 용량에 대해 가장 높은 신뢰성을 제공하여 갑작스러운 300-400% 급증 시에도 SQS 백로그를 처리할 수 있도록 보장합니다. 주요 AWS 기능: 스파이크에 대응하기 위해 Amazon SQS 지표(예: ApproximateNumberOfMessagesVisible, 가장 오래된 메시지의 수명)에 의해 구동되는 조정 정책과 함께 여러 Availability Zones에 걸쳐 Auto Scaling 그룹을 사용합니다. 비용을 줄이기 위해 비피크/안정 상태 처리 수준에 맞춰진 Reserved Instances(또는 Savings Plans)를 구매합니다. 상태 확인, 용량 재조정(혼합 인스턴스를 사용하는 경우) 및 적절한 인스턴스 다각화를 유지하여 용량 위험을 줄입니다. 이는 AWS Well-Architected의 Cost Optimization(안정 상태에 대한 약정 사용) 및 Reliability(중요한 워크로드에 대해 중단되기 쉬운 용량 방지)와 일치합니다. 일반적인 오해: Spot은 스파이크에 대해 "가장 비용 효율적"인 것처럼 보이지만, 워크로드가 명시적으로 중단을 허용하고 우아한 성능 저하(graceful degradation)를 위해 설계되지 않는 한 "다운타임 허용 불가(zero tolerance for downtime)"와 양립할 수 없습니다. 또 다른 오해는 최대 용량을 예약하는 것입니다. 피크 수요는 특정 시간으로 제한되고 프로모션 이벤트는 산발적이기 때문에 이는 비용 낭비입니다. 시험 팁: "다운타임 없음(no downtime)", "미션 크리티컬(mission critical)" 또는 "허용 오차 없음(zero tolerance)"과 같은 요구 사항이 보이면 필수 용량에 대해 Spot에 의존하는 솔루션을 피하십시오. 가변 워크로드의 경우 표준 시험 패턴은 다음과 같습니다. Reserved Instances/Savings Plans로 기본 용량을 약정하고, 신뢰성을 위해 On-Demand로 버스트합니다(또는 중단이 허용되는 경우에만 Spot 사용). 또한 SQS 디커플링은 스파이크를 흡수하는 데 도움이 되지만, 필요한 시간 내에 대기열을 처리하기 위한 신뢰할 수 있는 컴퓨팅의 필요성을 제거하지는 않습니다.

7
문제 7

글로벌 이러닝 플랫폼 회사가 50개 이상의 데이터 과학 팀에게 격리된 샌드박스 환경을 제공하기 위해 AWS Organizations를 사용하여 다중 계정 전략을 구현하고 있습니다. 각 팀은 전용 계정에서 기계 학습 워크로드 및 AWS 서비스를 실험하기 위해 전체 관리자 액세스 권한이 필요합니다. 보안 팀은 규정 준수 감사 목적으로 모든 API 호출 및 활동이 AWS Config를 통해 로깅되어야 한다고 요구합니다. 각 데이터 과학 팀은 자신의 계정에서 루트 수준의 권한을 가지게 되므로, 아키텍처는 어떤 팀도 중요한 보안 이벤트를 모니터링하는 필수 AWS Config 구성을 비활성화하거나 수정하지 못하도록 방지해야 합니다. 데이터 과학 팀의 관리자 액세스 권한을 유지하면서 필수 AWS Config 설정을 수정할 수 없도록 보장하는 솔루션은 무엇입니까?

오답입니다. 루트 사용자에게 IAM policy를 안정적으로 연결할 수 없으며(루트는 사용자/역할처럼 관리하는 IAM principal이 아님), 관리자에 대해 IAM을 통해 작업을 거부하더라도 관리자 액세스 권한이 있는 팀이 해당 IAM policy를 제거하거나 변경할 수 있습니다. IAM은 동일한 계정 내의 권한 있는 사용자가 필수 제어를 변경하는 것을 방지하기 위한 강력한 거버넌스 경계가 아닙니다.

부분적으로 도움이 되지만 불충분합니다. 중앙 집중식 설정 및 집계를 위해 management account에서 조직 전체에 AWS Config를 배포할 수 있으며, 이는 규정 준수에 좋습니다. 그러나 조직 전체 배포만으로는 추가적인 예방 통제(예: SCP 거부)가 마련되지 않는 한 member account의 관리자가 Config 구성 요소를 중지하거나 수정할 수 없다는 것을 본질적으로 보장하지 않습니다.

정답입니다. 샌드박스 계정이 포함된 OU에 적용된 SCP는 AWS Config 수정 및 비활성화 작업을 명시적으로 거부할 수 있습니다. SCP는 member account에서 사용 가능한 최대 권한을 설정하며 AdministratorAccess 또는 기타 IAM 허용으로 재정의할 수 없습니다. 이는 팀에 실험을 위한 광범위한 관리자 권한을 부여하면서 필수 보안 제어를 적용하는 표준 AWS Organizations 접근 방식입니다.

오답입니다. Service-linked role은 AWS 서비스에 의해 관리되며 서비스 구성을 변경할 수 있는 사람을 제한하는 권한 경계로 설계되지 않았습니다. Service-linked role의 policy condition은 다른 principal(예: 계정 관리자)이 AWS Config API를 호출하여 recorder를 중지하거나 delivery channel을 변경하는 것을 방지하지 않습니다. 계정 간 거버넌스 요구 사항은 SCP를 통해 더 잘 충족됩니다.

문제 분석

핵심 개념: 이 질문은 사용자가 AdministratorAccess를 가지고 있는 경우에도 member account 전체에 필수 보안 가드레일을 적용하기 위한 AWS Organizations 거버넌스 제어, 특히 SCP(Service Control Policies)를 테스트합니다. 또한 규정 준수/감사 제어로서의 AWS Config와 변조 방지의 필요성도 다룹니다. 정답인 이유: 샌드박스 계정이 포함된 OU(organizational unit)에 적용된 SCP는 AWS Config 리소스를 중지, 삭제 또는 변경하는 작업(예: StopConfigurationRecorder, DeleteConfigurationRecorder, PutConfigurationRecorder, PutDeliveryChannel, DeleteDeliveryChannel)을 명시적으로 거부할 수 있습니다. SCP는 member account에서 사용 가능한 최대 권한을 정의합니다. SCP의 명시적 거부는 AdministratorAccess를 포함한 IAM policy로 재정의할 수 없습니다. 따라서 데이터 과학 팀은 실험을 위한 전체 관리자 기능을 유지하면서 필수 AWS Config 설정을 비활성화하거나 수정하는 것을 기술적으로 방지할 수 있습니다. 주요 AWS 기능: - AWS Organizations SCP: 관리자 권한이 있는 역할을 포함하여 member account의 모든 IAM principal에 적용되는 계정 수준 가드레일입니다. - 명시적 거부 우선순위: SCP 거부는 IAM 허용 여부와 관계없이 작업을 차단합니다. - AWS Config 조직 전체 설정을 사용할 수 있지만, "팀에서 수정할 수 없음" 요구 사항은 SCP 적용을 통해 충족됩니다(종종 중앙 관리를 위해 조직 전체 Config와 결합됨). - 모범 사례: AWS Well-Architected Security Pillar에 따라 예방 통제(SCP)와 탐지 통제(AWS Config rules, CloudTrail)를 결합합니다. 일반적인 오해: - "관리자는 무엇이든 할 수 있다": Organizations에서 관리자 권한은 여전히 SCP에 의해 제한됩니다. - "루트 사용자는 제한할 수 없다": member account의 루트 사용자도 API 작업에 대해 SCP의 적용을 받습니다(루트 사용자가 계정 해지와 같은 일부 계정 수준 작업을 수행할 수는 있음). Config API 변조를 방지하기 위한 목적이라면 SCP가 올바른 제어 방법입니다. - "중앙 집중식 Config만으로 변경을 방지한다": 조직 전체 Config는 배포를 단순화하지만, SCP가 없으면 member account의 관리자가 배포 방식에 따라 로컬 Config 구성 요소를 여전히 변경할 수 있습니다. 시험 팁: "여러 계정에서 관리자조차 X를 수행하지 못하도록 방지해야 한다"는 내용을 보면 SCP를 떠올리십시오. IAM policy는 교차 계정 거버넌스에 충분하지 않으며, service-linked role은 거버넌스 경계를 제공하지 않습니다. 필수 로깅/구성을 위해서는 조직 전체 서비스(Config/CloudTrail)를 비활성화 또는 수정 작업을 거부하는 SCP 가드레일과 결합하십시오.

8
문제 8

금융 서비스 회사가 AWS Cloud에 실시간 사기 탐지 시스템을 배포해야 합니다. 이 시스템은 총 50TB에 달하는 공유 훈련 데이터 세트에 동시에 액세스해야 하는 300개 이상의 Amazon EC2 인스턴스에서 실행되는 기계 학습(ML) 알고리즘을 사용하여 트랜잭션 데이터를 분석합니다. ML 훈련 워크로드는 최적의 모델 훈련 성능을 위해 공유 데이터 세트에 대한 밀리초 미만(sub-millisecond)의 액세스 지연 시간이 필요합니다. 분산 훈련 중 여러 인스턴스가 동일한 데이터 세트 파일에 대한 동시 읽기/쓰기 액세스를 필요로 합니다. 훈련이 완료된 후, 데이터 과학자들은 분석 및 검증을 위해 처리된 모델 아티팩트와 훈련 로그에 액세스해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

Amazon EFS는 동시 액세스 및 POSIX 의미 체계를 갖춘 관리형 NFS 파일 시스템을 제공하며, 이는 많은 공유 파일 사용 사례에 작동할 수 있습니다. 그러나 분산 ML 훈련을 위해 300개 이상의 EC2 인스턴스에서 밀리초 미만의 액세스 지연 시간과 매우 높은 병렬 처리량에 대한 요구 사항은 Lustre와 같은 병렬 파일 시스템을 강력하게 선호합니다. EFS 성능 모드가 도움이 되지만, 일반적으로 극단적인 HPC 스타일의 훈련 성능 요구 사항에 가장 적합한 것은 아닙니다.

Amazon S3는 객체 스토리지이며 POSIX 파일 시스템이 아닙니다. AWS CLI를 사용하여 S3를 "마운트"하거나 공유 파일 시스템처럼 취급하는 것은 분산 훈련에 필요한 동시 읽기/쓰기 파일 의미 체계에 적합하지 않습니다. 이는 일관성/이름 바꾸기/잠금 제한 및 요구되는 것보다 더 높은 지연 시간을 초래할 수 있습니다. S3는 데이터 세트 및 아티팩트의 내구성 있는 스토리지로는 훌륭하지만, 지연 시간이 짧은 기본 공유 훈련 파일 시스템으로는 적합하지 않습니다.

Amazon FSx for Lustre는 많은 동시 클라이언트에서 밀리초 미만의 지연 시간과 엄청난 처리량/IOPS를 요구하는 고성능 워크로드를 위해 설계되었으며, 이는 50TB의 공유 데이터에서 분산 ML 훈련을 수행하는 300개 이상의 EC2 인스턴스와 일치합니다. FSx for Lustre를 S3에 연결하면 데이터 세트를 가져오고 모델 아티팩트/로그를 S3로 내보내어 훈련 후 분석 및 장기 보존을 수행할 수 있으므로, 훈련 중 성능과 훈련 후 내구성 및 비용 효율성을 결합할 수 있습니다.

AWS Resource Access Manager(RAM)는 계정 간에 리소스를 공유할 수 있지만, S3를 지연 시간이 짧은 공유 POSIX 파일 시스템으로 변환하지는 않습니다. 모든 인스턴스가 동일한 S3 버킷에 액세스할 수 있더라도, S3는 공유 파일 시스템과 다른 액세스 의미 체계를 가진 객체 스토리지로 유지되며, 동일한 파일에 대한 동시 읽기/쓰기가 있는 분산 훈련의 밀리초 미만 지연 시간 요구 사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 질문은 수백 개의 EC2 인스턴스에서 동시 읽기/쓰기가 가능하며 매우 짧은 지연 시간과 높은 처리량을 필요로 하는 대규모 분산 ML 훈련을 위한 공유 스토리지 서비스의 선택을 테스트합니다. 또한 다운스트림 분석을 위해 고성능 파일 스토리지와 내구성 있는 객체 스토리지를 통합하는 방법도 테스트합니다. 정답인 이유: Amazon FSx for Lustre는 많은 클라이언트에서 밀리초 미만의 지연 시간과 매우 높은 처리량/IOPS를 요구하는 고성능 컴퓨팅(HPC) 및 ML 워크로드를 위해 특별히 구축되었습니다. 분산 훈련 중 300개 이상의 EC2 인스턴스가 동일한 데이터 세트 파일을 동시에 읽고 쓰는 상황에서는 POSIX 호환 병렬 파일 시스템이 적합합니다. FSx for Lustre는 파일 시스템 크기에 따라 성능을 확장할 수 있으며, 대규모 데이터 세트(여기서는 50TB)에 대한 빠른 공유 액세스가 필요한 훈련 작업에 일반적으로 사용됩니다. FSx for Lustre를 Amazon S3에 연결하면 S3에서 훈련 데이터를 가져오고 결과(모델 아티팩트, 로그)를 다시 S3로 내보내어 내구성 있고 비용 효율적인 스토리지 및 훈련 후 분석을 수행할 수 있습니다. 주요 AWS 기능: FSx for Lustre는 높은 처리량과 짧은 지연 시간을 갖춘 관리형 Lustre 파일 시스템을 제공하고, 많은 EC2 인스턴스의 동시 액세스를 지원하며, 데이터 리포지토리 연결(가져오기/내보내기)을 통해 S3와 통합됩니다. 그런 다음 S3는 아티팩트 및 로그의 기록 시스템이 되어 분석, 공유, 수명 주기 정책 및 장기 보존을 가능하게 합니다. 이는 AWS Well-Architected의 성능 효율성(액세스 패턴에 최적화된 스토리지 선택) 및 운영 우수성(관리형 서비스, 사용자 지정 마운트/해킹 감소)과 일치합니다. 일반적인 오해: EFS는 공유 POSIX 파일 시스템이지만 일반적으로 탄력적인 공유 파일 워크로드를 위해 설계되었으며, 이 규모에서 엄격한 밀리초 미만의 지연 시간과 극단적인 병렬 처리량 요구 사항을 충족하지 못할 수 있습니다. "S3를 파일 시스템으로 마운트"하는 것은 기본 POSIX 공유 파일 시스템이 아니며 의미론적 및 성능 문제를 야기합니다. AWS RAM 공유는 S3의 액세스 의미 체계를 변경하거나 지연 시간이 짧은 공유 파일 시스템으로 만들지 않습니다. 시험 팁: "HPC/ML 훈련", "수백 개의 인스턴스", "공유 파일" 및 "밀리초 미만의 지연 시간"이 보이면 FSx for Lustre를 생각하십시오. 또한 "장기 스토리지/분석"이 보이면 S3 통합 패턴(S3에 연결된 FSx for Lustre)을 찾으십시오.

9
문제 9

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

AWS Data Pipeline은 주로 예약된/배치 데이터 이동을 위한 레거시 오케스트레이션 서비스이며, 수백 개의 생산자로부터 대용량 실시간 수집을 수행하는 데 적합하지 않습니다. S3 + EMR이 대규모 데이터 세트를 처리할 수는 있지만, 이 옵션은 안정적이고 확장 가능한 스트리밍 수집 및 지속적인 전송을 해결하지 못합니다. 또한 거의 실시간 파이프라인을 위한 Kinesis 관리형 수집 및 전송 서비스에 비해 운영 오버헤드가 증가합니다.

Auto Scaling EC2 플릿을 이벤트를 수집하고 처리하도록 엔지니어링할 수 있지만, 수집 계층(로드 밸런싱, 체크포인팅, 재시도, 백프레셔, 순서 지정 및 내구성)을 구축하고 운영해야 합니다. 이는 일일 25TB 및 실시간 요구 사항에 대해 더 높은 운영 위험을 초래합니다. 또한 설명된 흐름이 불분명하며(내구성 있는 저장 전 처리) 관리형 스트리밍 모범 사례와 덜 일치합니다.

CloudFront는 시청자에게 콘텐츠를 캐싱하고 전송하도록 설계되었으며, 사용자 행동 분석 이벤트를 수집하거나 버퍼링하는 데 적합하지 않습니다. S3 객체 생성 시 Lambda를 트리거하는 것은 이벤트 기반 배치 처리이며, 일일 볼륨이 매우 높은 경우(객체 폭발, 동시성 및 작은 파일 문제) 비효율적이거나 제한될 수 있습니다. 이 옵션은 강력한 실시간 수집 및 전송 메커니즘을 제공하지 않습니다.

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

문제 분석

핵심 개념: 이 질문은 처리량이 높은 거의 실시간(near-real-time) 스트리밍 수집 파이프라인을 설계하고 확장 가능한 분석 스토어에 데이터를 저장하는 능력을 테스트합니다. 주요 서비스는 Amazon Kinesis Data Streams(내구성 있는 스트림 수집), Amazon Kinesis Data Firehose(스토리지/분석 대상으로의 관리형 전송), Amazon S3(데이터 레이크) 및 Amazon Redshift(대규모 분석)입니다. 정답인 이유: 250개 이상의 플랫폼에서 매일 약 25TB의 데이터가 발생하므로, 회사는 탄력적인 수집, 안정적인 전송 및 효율적인 분석이 필요합니다. Kinesis Data Streams는 순서가 지정되고 내구성 있는 스토리지(보존) 및 샤드(shard)를 통한 수평 확장을 제공하여 대용량 실시간 이벤트 수집을 위해 특별히 구축되었습니다. 그런 다음 Kinesis Data Firehose는 최소한의 운영 오버헤드로 데이터를 지속적으로 배치 처리, 버퍼링, 선택적 변환 및 S3 데이터 레이크로 로드할 수 있는 완전 관리형의 안정적인 전송 메커니즘을 제공합니다. S3에서 데이터를 Amazon Redshift로 로드하여 대규모로 고성능 SQL 분석을 수행할 수 있습니다. 이 아키텍처는 수집, 내구성 있는 스토리지 및 분석을 깔끔하게 분리하여 스트리밍 데이터 파이프라인의 모범 사례와 일치합니다. 주요 AWS 기능: - Kinesis Data Streams: 샤드 기반 확장, 다중 생산자/소비자, 재생(replay)을 위한 보존, 높은 읽기 처리량을 위한 향상된 팬아웃(enhanced fan-out). - Kinesis Data Firehose: 자동 확장, 버퍼링(크기/시간), 재시도, 압축, 선택적 Lambda 변환, S3(및 기타 대상)로의 전송. - S3 데이터 레이크: 뛰어난 내구성의 스토리지, 수명 주기 정책, 다운스트림 쿼리 효율성을 위한 파티셔닝. - Redshift: 열 기반(columnar) 스토리지, MPP 아키텍처, 대량 로드를 위한 S3에서의 COPY; S3를 직접 쿼리하기 위해 Redshift Spectrum과 결합할 수 있습니다(종종 후속 설계 선택으로 사용됨). 일반적인 오해: "S3에 저장한 다음 처리"하는 옵션은 실시간 수집 및 안정적인 전송 요구 사항을 충족하지 못합니다. CloudFront는 콘텐츠 전송/캐시 서비스이지 분석 수집 버퍼가 아닙니다. DIY EC2 수집/처리는 작동할 수 있지만 관리형 Kinesis 서비스에 비해 상당한 비차별화된 과중한 작업(확장, 내결함성, 백프레셔(backpressure) 처리)이 추가됩니다. 시험 팁: "대용량 실시간 수집(high-volume real-time ingestion)"과 "안정적인 전송(reliable delivery)" 및 "분석(analytics)"이 보이면 Kinesis(수집용 Streams, 관리형 전송용 Firehose)를 통해 S3에 저장한 다음, 분석 요구 사항에 따라 Redshift/Athena/EMR을 사용하여 쿼리/데이터 웨어하우징을 수행하는 것을 생각하십시오. 질문에서 명시적으로 사용자 지정 처리를 요구하지 않는 한, 스트리밍 파이프라인에 대해 사용자 지정 EC2 플릿보다 관리형 서비스를 선호하십시오.

10
문제 10

한 금융 서비스 회사가 프라이빗 데이터 센터에서 Kubernetes로 오케스트레이션되는 Docker 컨테이너를 사용하여 마이크로서비스 기반 거래 플랫폼을 운영하고 있습니다. 이 애플리케이션은 트랜잭션 데이터 스토리지로 PostgreSQL 데이터베이스 클러스터를 사용합니다. 급격한 비즈니스 성장과 거래량 증가로 인해 회사는 인프라의 일부를 AWS로 마이그레이션해야 합니다. 마이그레이션은 애플리케이션 코드 수정이나 현재 CI/CD 파이프라인의 변경 없이 6주 이내에 완료되어야 합니다. 솔루션은 기존 Kubernetes 매니페스트 및 PostgreSQL 기반 데이터 계층과의 호환성을 유지하면서 인프라 관리 오버헤드를 최소화해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

Amazon ECS는 Kubernetes가 아니므로, 회사는 Kubernetes manifests를 ECS task definitions와 services로 변환해야 합니다. 이는 배포 도구와 CI/CD 프로세스의 변경을 필요로 할 가능성이 높으며, 이는 파이프라인 수정을 피해야 한다는 요구 사항과 직접적으로 충돌합니다. 또한 PostgreSQL을 EC2에서 실행하면 패치, 백업, 스케일링, 고가용성 측면에서 불필요한 운영 오버헤드가 발생합니다. 이 옵션은 호환성과 관리 오버헤드 목표를 모두 충족하지 못합니다.

AWS Fargate와 Amazon ECS를 사용하면 compute 관리 오버헤드는 줄어들고, Amazon RDS for PostgreSQL은 좋은 관리형 데이터베이스 선택입니다. 그러나 ECS는 여전히 기존 Kubernetes manifests의 직접적인 재사용을 지원하지 않으므로, 마이그레이션에는 orchestration layer의 재구성이 필요하고 CI/CD 파이프라인도 조정해야 할 가능성이 높습니다. 따라서 애플리케이션이나 파이프라인 변경 없이 빠르게 마이그레이션해야 하는 상황에는 적합하지 않습니다. compute model 자체는 운영 측면에서 매력적이지만, orchestration 불일치가 결정적인 문제입니다.

Amazon EKS는 Kubernetes를 네이티브로 지원하는 AWS 서비스이므로, 프라이빗 데이터 센터에서 이미 Kubernetes로 실행 중인 애플리케이션에 가장 호환성이 높은 대상입니다. EC2 worker nodes와 함께 EKS를 사용하면 회사는 기존 Kubernetes manifests와 운영 패턴을 최소한의 변경으로 재사용할 수 있으며, 이는 6주 마이그레이션 일정과 애플리케이션 코드 및 CI/CD 파이프라인 수정을 피해야 한다는 요구 사항을 고려할 때 매우 중요합니다. Amazon RDS for PostgreSQL은 현재 PostgreSQL 기반 데이터 계층과의 호환성을 유지하는 관리형 PostgreSQL engine을 제공하면서, 백업, 패치, 고가용성에 대한 운영 부담을 줄여줍니다. EC2 worker nodes는 일부 인프라 관리가 필요하지만, 이 옵션은 기존 Kubernetes 워크로드에 대해 가장 폭넓은 호환성과 가장 낮은 위험의 lift-and-shift 경로입니다.

Amazon EKS는 Kubernetes 호환성을 유지하며, Aurora PostgreSQL-Compatible도 유효한 관리형 PostgreSQL-compatible 데이터베이스 옵션입니다. 그러나 EKS on Fargate는 기존 Kubernetes 워크로드에 대해 항상 최선의 lift-and-shift 대상은 아닙니다. 일부 워크로드는 EC2 기반 nodes에서 더 잘 지원되는 기능이나 daemon 패턴에 의존하기 때문에, 촉박한 일정에서는 마이그레이션 위험이 더 커질 수 있습니다. 이 문제는 애플리케이션이나 파이프라인 변경 없이 마이그레이션을 빠르게 완료하는 것을 우선시하며, EC2 worker nodes를 사용하는 EKS가 더 보편적으로 호환되는 Kubernetes landing zone입니다. 또한 문제는 최적화를 위한 데이터베이스 engine 변경이 아니라 PostgreSQL 호환성을 요구하므로 Aurora도 필수는 아닙니다.

문제 분석

핵심 개념: 이 문제는 기존 Kubernetes 기반 애플리케이션과 PostgreSQL 데이터 계층에 대해, 애플리케이션 코드 변경과 CI/CD 파이프라인 변경을 피하면서 가장 빠르고 위험이 가장 낮은 마이그레이션 경로를 선택하는 것에 관한 것입니다. 주요 판단 기준은 Kubernetes 호환성을 유지하는 것이며, 이는 Amazon ECS보다 Amazon EKS를 강하게 선호하게 만듭니다. 최적의 정답은 EC2 worker nodes를 사용하는 EKS와 Amazon RDS for PostgreSQL입니다. 왜냐하면 이는 기존 Kubernetes manifests를 최소한의 수정으로 지원하고, Fargate의 워크로드 제약을 도입하지 않으면서 관리형 PostgreSQL 서비스를 제공하기 때문입니다. 흔한 오해는 관리 오버헤드를 최소화해야 한다는 언급이 있으면 Fargate가 항상 최선의 답이라는 것이지만, 기존 Kubernetes 워크로드의 경우 호환성과 마이그레이션 속도가 추가적인 node 관리 절감보다 더 중요한 경우가 많습니다. 시험 팁: 문제가 기존 Kubernetes manifests와 파이프라인 변경 없음에 초점을 맞춘다면, 먼저 EKS를 기본 선택으로 고려하고, 그다음 호환성과 운영 단순성의 균형이 가장 좋은 compute model을 선택하세요.

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