연습 문제

문제 1

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

문제 분석

핵심 개념: 이 문제는 중요한 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개 선택)

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

문제 분석

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

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

문제 분석

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

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

문제 분석

핵심 개념: 이 질문은 서버리스, 쿼리당 지불 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

(2개 선택)

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

문제 분석

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

한 금융 기술 스타트업이 Amazon EC2 인스턴스를 사용하여 실시간 사기 탐지 시스템을 운영하고 있습니다. 이 시스템은 Amazon SQS 대기열에서 트랜잭션 데이터를 처리하며, 피크 시간대(오전 9시 - 오후 6시)에는 약 50,000건, 비피크 시간대에는 15,000건의 트랜잭션을 분석합니다. 프로모션 이벤트 중에는 워크로드에 갑작스러운 스파이크가 발생하여 볼륨이 300-400% 증가할 수 있습니다. 사기 탐지 시스템은 중단이 발생할 경우 사기 트랜잭션이 탐지되지 않고 통과될 수 있으므로 다운타임에 대한 허용 오차 없이(zero tolerance) 연중무휴(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

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

문제 분석

핵심 개념: 이 질문은 사용자가 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

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

문제 분석

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

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

문제 분석

핵심 개념: 이 질문은 처리량이 높은 거의 실시간(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

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

Practice Test #2

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

Practice Test #7

Practice Test #8

Practice Test #9

Practice Test #10

지금 학습 시작하기