연습 문제

문제 1

한 금융 서비스 회사가 일일 트랜잭션 조정 보고서를 처리하는 레거시 배치 처리 시스템을 현대화하고 있습니다. 현재 시스템은 조정 작업을 여러 처리 워커에 분배하는 중앙 코디네이터 서버를 사용합니다. 워크로드는 크게 변동합니다. 월말 기간에는 처리량이 300% 증가할 수 있는 반면, 주말에는 활동이 최소화됩니다. 이 회사는 운영 오버헤드를 최소화하면서 가변적인 워크로드를 효율적으로 처리하기 위해 최대의 복원력과 자동 조정 기능을 갖춘 AWS로 이 시스템을 마이그레이션해야 합니다. 솔루션 아키텍트는 이러한 요구 사항을 충족하기 위해 아키텍처를 어떻게 설계해야 합니까?

문제 분석

핵심 개념: 이 질문은 대기열 기반 워커 패턴과 이벤트 기반 조정을 사용하여 AWS에서 분리되고 복원력 있는 배치 처리를 테스트합니다. 핵심 서비스는 내구성 있는 작업 버퍼링을 위한 Amazon SQS와 탄력적인 워커 플릿을 위한 EC2 Auto Scaling입니다. 정답인 이유: 옵션 B는 확장 및 가용성 병목 현상인 단일 "중앙 코디네이터"를 제거하고 고가용성, 내구성 있는 메시지 스토리지 및 자연스러운 백프레셔를 제공하는 SQS로 대체하기 때문에 최상의 설계입니다. 워커는 SQS를 폴링하고 작업을 독립적으로 처리합니다. SQS 대기열 깊이(예: ApproximateNumberOfMessagesVisible 및/또는 ApproximateNumberOfMessagesNotVisible)를 기반으로 워커 Auto Scaling 그룹을 조정하면 용량이 미해결 작업에 직접 맞춰집니다. 이는 예측할 수 없는 급증(예: 월말 +300%)에 대한 자동 조정을 제공하고 활동이 적은 기간(주말)에는 축소하여 운영 오버헤드를 최소화합니다. 주요 AWS 기능: - SQS standard queue: 다중 AZ, 확장성이 뛰어난 버퍼링; 최소 한 번 전송(at-least-once delivery) 지원. - Visibility timeout: 여러 워커가 동일한 작업을 동시에 처리하는 것을 방지; 최대 처리 시간에 맞춰 조정. - Dead-letter queue (DLQ): maxReceiveCount 이후 포이즌 메시지 격리. - SQS 지표에 대한 target tracking/step scaling이 있는 EC2 Auto Scaling(종종 CloudWatch alarms를 통해): 배치 작업의 처리량과 더 직접적으로 연결된 CPU가 아닌 백로그를 기반으로 조정. - 복원력 모범 사례: 여러 AZ에 걸친 상태 비저장(stateless) 워커; 간헐적인 중복 전송을 처리하기 위한 멱등성(idempotent) 처리. 일반적인 오해: Scheduled scaling(옵션 A)은 회사에 알려진 월말 피크가 있기 때문에 매력적으로 보일 수 있지만, 계획되지 않은 급증에는 실패하고 조용한 기간에는 과도하게 프로비저닝될 수 있습니다. CPU 기반 조정(옵션 C/D)은 간접적이며 지연될 수 있습니다. 백로그가 증가하는 동안(I/O 바운드 작업) CPU가 낮거나 시끄러운 이웃(noisy neighbors)으로 인해 CPU가 높아 불안정한 조정으로 이어질 수 있습니다. CloudTrail은 작업 분배 메커니즘이 아닙니다. 시험 팁: 가변적인 배치/워커 워크로드의 경우 "SQS + Auto Scaling 워커"를 선호하고 코디네이터 CPU가 아닌 대기열 깊이/백로그를 기반으로 조정하십시오. 단일 장애점을 제거하고 분리 및 복원력을 위해 관리형 서비스를 사용하는 설계를 찾으십시오(AWS Well-Architected Reliability 원칙).

문제 2

한 글로벌 게임 회사가 AWS에서 멀티플레이어 온라인 게임 플랫폼을 운영하고 있습니다. 이 플랫폼은 다양한 시간대의 게임 피크 시간 동안 수백만 명의 동시 플레이어를 처리합니다. 회사는 수백만 개의 플레이어 활동 이벤트(점수, 업적, 아이템 구매)를 여러 내부 분석 애플리케이션과 공유할 수 있는 확장 가능한 거의 실시간 솔루션이 필요합니다. 리더보드 서비스의 빠른 쿼리 성능을 위해 NoSQL 데이터베이스에 저장되기 전에 개인 식별 정보(PII)를 마스킹하도록 플레이어 이벤트를 처리해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 스트리밍 서비스를 사용하여 확장 가능한 거의 실시간 이벤트 수집 및 팬아웃 아키텍처를 설계하고, 지연 시간이 짧은 NoSQL 스토어에 지속하기 전에 안전한 데이터 처리(PII 마스킹)를 테스트합니다. 핵심 서비스는 Amazon Kinesis Data Streams(실시간 스트리밍 및 다중 소비자), AWS Lambda(스트림 처리/변환) 및 Amazon DynamoDB(리더보드를 위한 빠른 키-값/NoSQL 쿼리)입니다. 정답인 이유: 옵션 C가 모든 요구 사항을 가장 잘 충족합니다: (1) 탄력적인 처리량으로 수백만 개의 동시 플레이어 이벤트를 수집하고, (2) 거의 실시간으로 여러 내부 분석 애플리케이션과 동일한 이벤트 스트림을 공유하며, (3) 빠른 리더보드 쿼리를 위해 DynamoDB에 저장하기 전에 PII가 마스킹되도록 보장합니다. Kinesis Data Streams는 처리량이 높고 지연 시간이 짧은 스트리밍을 위해 특별히 구축되었으며 사용자 지정 배포를 구축하지 않고도 동일한 데이터를 읽는 여러 독립 소비자(팬아웃)를 지원합니다. Kinesis에서 Lambda를 호출하여 각 레코드를 변환(PII 마스킹/제거)한 다음 삭제된 이벤트를 DynamoDB에 쓸 수 있습니다. 주요 AWS 기능 / 모범 사례: - Kinesis Data Streams: 쓰기/읽기 처리량을 위한 샤드 기반 확장; 재생을 위한 보존; 전용 소비자별 처리량 및 짧은 지연 시간을 위한 향상된 팬아웃. - Lambda + Kinesis 통합: 일괄 처리, 재시도 및 체크포인팅이 포함된 이벤트 소스 매핑; 재시도를 안전하게 처리하기 위해 DynamoDB에 멱등성 쓰기 사용. - DynamoDB: 가변적인 피크 부하를 처리하기 위한 온디맨드 용량 또는 Auto Scaling; 리더보드 접근 패턴을 위한 파티션 키 설계; 다운스트림 변경 캡처를 위한 선택적 DynamoDB Streams(여기서는 필요하지 않음). - 보안: 데이터베이스 싱크 전 스트림 처리 계층에서 PII 마스킹; 최소 권한 IAM 적용 및 Kinesis 및 DynamoDB에 대한 미사용 암호화(KMS) 고려. 일반적인 오해: A는 DynamoDB Streams가 변경 사항을 게시할 수 있기 때문에 매력적으로 보이지만, 처리량이 높은 기본 수집 및 다중 소비자 이벤트 버스로 설계되지 않았으며 "쓰기 시 PII를 제거하는 DynamoDB의 규칙"은 네이티브 DynamoDB 기능이 아닙니다. B는 Firehose를 언급하지만 Firehose는 주로 S3/Redshift/OpenSearch와 같은 대상으로의 전송 서비스입니다. 다중 소비자 거의 실시간 버스가 아니며 DynamoDB는 표준 Firehose 대상이 아닙니다. D는 S3 배치 파일에 의존하므로 지연 시간이 늘어나고 거의 실시간이 아닙니다. 시험 팁: "수백만 개의 이벤트", "거의 실시간" 및 "여러 애플리케이션이 동일한 이벤트를 소비함"을 보면 S3 일괄 처리 또는 DynamoDB Streams보다 Kinesis Data Streams(또는 MSK)를 생각하십시오. 요구 사항에 "저장 전 PII 마스킹"이 명시된 경우 데이터베이스 싱크 앞에 변환(Lambda/Kinesis Data Analytics)을 배치하십시오. 또한 서비스 기능을 확인하십시오: DynamoDB에는 쓰기 시간 변환 규칙이 없으며 Firehose는 Kinesis Data Streams에 비해 대상/소비자 패턴이 제한적입니다.

문제 3

한 미디어 제작 회사가 Linux 기반 워크스테이션을 사용하여 AWS에서 비디오 편집 워크플로를 운영하고 있습니다. 현재 이 회사는 프로젝트 파일, 원본 영상 및 렌더링된 비디오를 저장하기 위해 NFS 서버를 실행하는 두 개의 Amazon EC2 인스턴스를 사용합니다. NFS 서버는 중복성을 보장하기 위해 서로 데이터를 복제합니다. 크리에이티브 팀은 현재 워크플로를 변경하지 않고 여러 편집 워크스테이션에서 공유 스토리지에 원활하게 액세스해야 합니다. 회사는 편집 워크스테이션에서 사용하는 현재 파일 액세스 패턴을 유지하는 고가용성 및 내구성 있는 스토리지 솔루션이 필요합니다. 이러한 요구 사항을 충족하기 위해 solutions architect는 무엇을 권장해야 합니까?

문제 분석

핵심 개념: 이 질문은 Linux 워크스테이션에 대한 기존 POSIX/NFS 파일 액세스 패턴을 보존하는 관리형 고가용성 공유 파일 시스템을 선택하는 것을 테스트합니다. 핵심 요구 사항은 워크플로 변경 없는 "공유 스토리지에 대한 원활한 액세스"와 고가용성 및 내구성입니다. 정답인 이유: Amazon EFS는 여러 Linux 클라이언트가 동시에 마운트할 수 있도록 설계된 완전 관리형 NFS 파일 시스템입니다. EC2에서 자체 관리되는 NFS 서버의 운영 부담과 취약성(패치 적용, 확장, 장애 조치, 복제 논리)을 제거합니다. EFS는 Region 내의 여러 Availability Zones에 데이터를 중복 저장하여 설계상 높은 내구성과 가용성을 제공합니다. 클라이언트가 NFS(v4.x)를 통해 EFS를 마운트하기 때문에 편집 워크스테이션은 동일한 공유 파일 워크플로 및 파일 의미 체계를 계속 사용할 수 있습니다. 주요 AWS 기능: EFS는 VPC의 많은 EC2 인스턴스 및 워크스테이션에서의 NFS 마운트, 탄력적 용량(사전 프로비저닝 없음) 및 리전 서비스로서의 Multi-AZ 복원력을 지원합니다. 고가용성 및 짧은 지연 시간 액세스를 위해 각 AZ의 mount targets를 사용하십시오. 자주 액세스하는 미디어의 경우 EFS Standard 스토리지 클래스를 선택하고, 선택적으로 수명 주기 관리를 활성화하여 더 차가운 콘텐츠를 EFS Infrequent Access로 전환하십시오. 보안을 위해 security groups, EFS에 대한 IAM 권한 부여, 미사용/전송 중 암호화를 사용하십시오. 일반적인 오해: S3는 내구성이 매우 뛰어나지만 POSIX/NFS 파일 시스템이 아닌 객체 스토리지입니다. S3로 이동하려면 일반적으로 애플리케이션/워크플로 변경(다른 API, 의미 체계 및 도구)이 필요합니다. Storage Gateway File Gateway는 주로 하이브리드/온프레미스 캐싱을 위한 것이며 그 자체로 EC2 호스팅 NFS 서버를 "고가용성"으로 만들지 않습니다. 또한 추가 계층을 도입하며 AWS 내 공유 스토리지에 가장 적합한 것은 아닙니다. FSx for Lustre는 고성능 병렬 파일 시스템이지만 추가 복잡성 없이 "NFS 워크플로 유지" 및 "고가용성/내구성"을 위한 기본 선택은 아닙니다. 또한 "cross-AZ replication"은 암시된 방식의 표준 구성 노브가 아닙니다. 시험 팁: "Linux 공유 파일 스토리지", "NFS", "다중 클라이언트" 및 "워크플로 변경 없음"이 보이면 기본적으로 EFS를 선택하십시오. 질문에서 HPC/처리량/병렬 I/O 및 스크래치 또는 컴퓨팅 집약적 파이프라인을 위한 S3와의 긴밀한 통합을 강조할 때 FSx for Lustre를 사용하십시오. 객체 스토리지 의미 체계가 허용되는 경우 S3를 사용하십시오. 온프레미스 환경에서 AWS 스토리지로의 하이브리드 연결을 위해 주로 Storage Gateway를 사용하십시오.

문제 4

헬스케어 기술 스타트업이 민감한 환자 의료 기록 및 처방전 데이터를 처리하는 원격 의료 플랫폼을 개발하고 있습니다. 이 플랫폼을 통해 환자는 진료를 예약하고, 의료 문서를 업로드하며, 면허가 있는 의사로부터 전자 처방전을 받을 수 있습니다. 회사는 HIPAA 규정을 준수해야 하며 시스템 관리자 및 데이터베이스 운영자로부터도 민감한 환자 데이터가 보호되도록 보장해야 합니다. 플랫폼은 엄격한 데이터 기밀성을 유지하면서 99.9%의 가동 시간으로 실시간 환자 상담을 지원해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 HIPAA 규제 워크로드에서 "권한 있는 사용자(시스템 관리자/DB 운영자 포함)로부터의 데이터 기밀성"을 테스트합니다. 핵심 개념은 서버 측 암호화(미사용/전송 중)가 미디어 손실 및 일부 인프라 위협으로부터 보호하지만, 서비스/계정의 승인된 관리자가 일반 텍스트에 액세스하는 것을 본질적으로 방지하지는 않는다는 것입니다. 운영자로부터도 데이터를 기밀로 유지하려면 일반적으로 엄격한 키 액세스 제어가 있는 애플리케이션/클라이언트 측 암호화(종종 필드 수준)가 필요합니다. 정답인 이유: 옵션 B는 관계형 의료 기록/처방전 시스템에 Amazon RDS for PostgreSQL을 사용하고 민감한 필드가 저장되기 전에 AWS KMS 지원 클라이언트 측 암호화를 적용합니다. 암호화가 애플리케이션(또는 신뢰할 수 있는 클라이언트)에서 발생하기 때문에 데이터베이스는 보호된 열에 대해 암호문만 보게 됩니다. 이 설계는 DBA, RDS 관리자 또는 SQL 수준 액세스 권한이 있는 사람이 민감한 PHI를 읽을 수 있는 위험을 의미 있게 줄여주며, 시스템 관리자 및 데이터베이스 운영자로부터도 데이터가 보호되어야 한다는 요구 사항과 일치합니다. 주요 AWS 기능: - 클라이언트 측/필드 수준 암호화: 앱 계층에서 PHI를 암호화하고 암호문을 RDS에 저장합니다. - AWS KMS CMK: 중앙 집중식 키 관리, 교체, AWS CloudTrail을 통한 감사 및 세분화된 키 정책. - RDS Multi-AZ: 데이터베이스 계층에 대한 99.9% 가동 시간 요구 사항을 지원합니다(HA에 대한 일반적인 시험 단서). - HIPAA 조정: HIPAA 적격 서비스(RDS는 적격함)를 사용하고 AWS와 BAA를 체결합니다. IAM 및 데이터베이스 역할을 통해 최소 권한을 적용합니다. 일반적인 오해: 많은 사람들이 "KMS를 사용한 서버 측 암호화"(예: DynamoDB SSE-KMS)가 관리자를 차단한다고 생각하여 선택합니다. 일반적으로 그렇지 않습니다. 승인된 읽기를 위해 데이터가 해독됩니다. 네트워크 제어(보안 그룹)도 누군가 합법적인 액세스 경로를 확보하면 내부자/권한 있는 액세스를 해결하지 못합니다. 시험 팁: 질문에서 "관리자/운영자로부터도 데이터 보호"라고 명시하는 경우 클라이언트 측 암호화, 봉투 암호화(envelope encryption), 필드 수준 암호화 또는 서비스가 일반 텍스트를 절대 수신하지 않는 패턴을 찾으십시오. 이를 HA 요구 사항(예: Multi-AZ) 및 규정 준수 기본 사항(BAA, 로깅, 최소 권한)과 짝을 지으십시오.

문제 5

한 컨설팅 회사가 AWS Organizations를 사용하여 고객을 위한 여러 AWS 계정을 관리합니다. 이 회사는 과도한 권한을 가진 사용자를 식별하기 위해 IAM 사용자 권한을 감사해야 합니다. 솔루션은 관리 오버헤드를 최소화하면서 모든 IAM 권한을 검토해야 합니다. 관리 오버헤드를 최소화하면서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 최소한의 운영 노력으로 AWS Organizations 환경의 여러 AWS accounts 전반에서 IAM permissions를 감사하고 지속적으로 검토하는 방법을 테스트합니다. 핵심 서비스는 IAM Access Analyzer(IAM의 일부)이며, 이는 policies와 access paths를 분석하여 의도하지 않았거나 지나치게 광범위한 access를 식별하는 데 도움을 줍니다. 정답인 이유: AWS IAM Access Analyzer는 누가 무엇에 access할 수 있는지 이해하고, 과도하게 허용적인 access를 식별하도록 설계되었습니다. 과도한 권한을 가진 IAM users를 감사할 때 가장 관련 있는 기능은 Access Analyzer의 policy analysis와 findings 기능(광범위한 principals, external access에 대한 검사, policy refinement를 위한 가이드 포함) 및 AWS Organizations와의 통합을 통한 multi-account 가시성입니다. 이는 custom scripts를 구축하거나, logs를 수동으로 집계하거나, 맞춤형 tooling을 유지할 필요를 줄여주는 managed capability이므로 “LEAST administrative overhead” 요구 사항을 충족합니다. 주요 AWS 기능: - Organization-wide analyzers: 전체 organization(또는 특정 accounts)을 포괄하는 analyzer를 생성하여 findings를 중앙 집중화할 수 있습니다. - Policy validation and analysis: Access Analyzer는 IAM policies(identity-based 및 resource-based)를 분석하여 위험한 패턴을 강조하고 permissions를 정교화하는 데 도움을 줄 수 있습니다. - Continuous monitoring: policies가 변경되면 findings가 업데이트되어 일회성 검토가 아닌 지속적인 감사를 지원합니다. - Security best practice alignment: 광범위한 access를 식별하고 policies를 더 엄격하게 조정하도록 도와 least privilege를 지원합니다. 일반적인 오해: 흔한 함정은 Network Access Analyzer를 IAM permission auditing과 혼동하는 것입니다. Network Access Analyzer는 IAM authorization이 아니라 network reachability(VPC routing, security groups, NACLs)에 초점을 맞춥니다. 또 다른 오해는 activity에 대한 CloudWatch alarms가 permission audits와 동일하다고 생각하는 것입니다. activity monitoring은 permissions가 과도한지 여부를 보여주지 않습니다. Amazon Inspector는 vulnerability management(EC2, ECR, Lambda용)를 위한 서비스이며 IAM privilege scope를 감사하지 않습니다. 시험 팁: “audit IAM permissions”, “over-privileged users”, “minimal overhead”를 보면 managed IAM governance tools를 떠올리세요: IAM Access Analyzer(그리고 더 넓은 맥락에서는 IAM Access Advisor/last accessed info, IAM Identity Center, 또는 AWS Config rules). identity authorization(IAM)과 network reachability(VPC/network analyzers)를 구분하세요. multi-account 규모를 위해 AWS Organizations를 기본적으로 지원하는 서비스를 선택하세요.

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

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

문제 6

글로벌 미디어 회사인 'WorldNews'는 전 세계에 위치한 기자들이 us-east-1 Region의 AWS에서 호스팅되는 브로드캐스트 시스템으로 라이브 방송을 전송해야 합니다. 기자들은 휴대폰의 소프트웨어를 사용하여 RTMP(Real-Time Messaging Protocol)를 통해 라이브 스트림을 전송합니다. 다양한 지리적 위치에서 발생하는 네트워크 지연 및 혼잡으로 인해 스트림 품질이 일관되지 않습니다. 솔루션 아키텍트는 위치에 관계없이 브로드캐스트 시스템으로 돌아가는 TCP 연결을 가속화하여 기자들이 최고 품질의 스트림을 전송할 수 있는 솔루션을 설계해야 합니다. 이러한 요구 사항을 충족하기 위해 솔루션 아키텍트는 무엇을 사용해야 합니까?

문제 분석

핵심 개념: 이 질문은 단일 AWS Region으로의 지연 시간에 민감한 TCP 기반 수집(RTMP)을 위한 글로벌 네트워크 성능 최적화를 테스트합니다. 핵심 서비스는 트래픽을 AWS 글로벌 네트워크로 최대한 빠르게 라우팅하여 최종 사용자부터 AWS 애플리케이션까지의 성능을 향상시키는 AWS Global Accelerator입니다. 정답인 이유: 기자들은 전 세계에 분산되어 있으며 us-east-1의 브로드캐스트 시스템으로 라이브 RTMP 스트림을 푸시합니다. RTMP는 일반적으로 TCP를 통해 실행되며, 장거리 인터넷 경로는 지연 시간, 지터 및 패킷 손실을 유발하여 처리량과 스트림 품질을 저하시킬 수 있습니다. AWS Global Accelerator는 가장 가까운 AWS 엣지 로케이션에서 TCP/UDP 트래픽을 수락한 다음 AWS 백본을 통해 최적의 리전 엔드포인트(예: NLB/ALB/EC2/EIP)로 전달하는 정적 애니캐스트 IP 주소를 제공합니다. 이러한 AWS로의 "빠른 진입"과 혼잡을 우회하는 지능형 라우팅은 인터넷 변동성으로 인한 일관되지 않은 품질 문제를 직접적으로 해결합니다. 주요 AWS 기능: Global Accelerator는 애니캐스트 IP, 상태 확인 및 트래픽 다이얼을 사용하여 정상적인 엔드포인트로 라우팅하며, 설계에 따라 엔드포인트/Region 간에 장애 조치(failover)를 수행할 수 있습니다. TCP 가속의 경우 트래픽이 퍼블릭 인터넷에서 이동하는 거리를 줄이고 AWS의 관리형 엣지 네트워크를 활용합니다. Network Load Balancer(TCP 패스스루에 일반적), Application Load Balancer, EC2 인스턴스 및 Elastic IP를 엔드포인트로 지원합니다. 이는 지연 시간을 최소화하고 관리형 글로벌 네트워킹을 사용한다는 AWS Well-Architected 성능 효율성 원칙과 일치합니다. 일반적인 오해: CloudFront는 종종 "엣지 성능"을 위해 선택되지만, 주로 HTTP(S) 및 캐시 가능한 콘텐츠를 위한 CDN입니다. RTMP와 같은 임의의 TCP 수집을 오리진으로 가속하도록 설계되지 않았습니다. Client VPN은 글로벌 미디어 기여 워크플로를 최적화하기 위한 것이 아니라 VPC 리소스에 대한 프라이빗 액세스를 위한 것입니다. Elastic IP와 함께 EC2를 사용하는 것만으로는 글로벌 애니캐스트 수신 또는 백본 라우팅 최적화가 제공되지 않으며, 여전히 표준 인터넷 경로에 의존합니다. 시험 팁: "글로벌 사용자에서 AWS 엔드포인트로의 TCP/UDP 연결 가속화" 및 "위치에 관계없이"라는 문구를 보면 AWS Global Accelerator를 생각하십시오. "엣지에서 정적/동적 웹 콘텐츠 캐시"를 보면 CloudFront를 생각하십시오. 일관된 글로벌 수신 성능이 필요한 TCP(RTMP) 기반 라이브 비디오 기여 프로토콜의 경우, NLB 앞에 Global Accelerator를 배치하는 것이 일반적인 패턴입니다.

문제 7

(3개 선택)

한 의료 기술 회사가 Amazon Elastic Kubernetes Service (Amazon EKS) 클러스터와 Amazon Aurora 데이터베이스를 사용하여 의료 영상 데이터를 처리해야 합니다. 엄격한 HIPAA 규정 준수 요구 사항으로 인해 처리는 회사의 프라이빗 의료 시설 내에서 이루어져야 합니다. 이 회사는 AWS 서비스를 활용하면서 규정 준수를 유지하기 위해 AWS Outposts를 구현할 계획입니다. 솔루션 아키텍트는 의료 영상 솔루션을 배포하기 위해 회사의 IT 인프라 팀과 협력하고 있습니다. 팀은 AWS Outposts 배포에 대한 운영 책임을 이해해야 합니다. AWS Outposts 구현을 위해 회사의 IT 인프라 팀에 속하는 운영 책임은 무엇입니까? (3개 선택)

문제 분석

핵심 개념: 이 질문은 AWS Outposts의 공동 책임 모델을 테스트합니다. Outposts는 AWS 인프라 및 서비스를 온프레미스로 확장하지만 운영 소유권은 분할됩니다. AWS는 Outposts 랙 하드웨어 및 AWS 관리형 서비스 제어 플레인 구성 요소를 소유하고 운영하는 반면, 고객은 온프레미스 시설 요구 사항(전력, 공간, 냉각, 물리적 보안)을 소유하고 사용 가능한 Outposts 용량 내에서 복원력을 갖춘 워크로드를 설계해야 합니다. 정답인 이유: A가 정답인 이유는 고객이 Outposts 랙에 적절하고 안정적인 전원 및 네트워크 연결(업링크)을 제공하고 유지 관리해야 하기 때문입니다. 안정적인 전원과 네트워크가 없으면 Outpost가 작동하거나 서비스 관리를 위해 AWS Region에 연결할 수 없습니다. C가 정답인 이유는 시설의 물리적 보안(액세스 제어, 감시, 제한 구역)이 고객의 책임이기 때문입니다. 이는 ePHI를 처리하는 시스템을 보호하는 데 인프라에 대한 물리적 액세스 제어가 포함되는 HIPAA 워크로드에 특히 중요합니다. F가 정답인 이유는 고객이 Outposts에서 워크로드 수준의 복원력에 대한 책임이 있기 때문입니다. Outposts의 Amazon EKS의 경우, Outposts는 유한한 온프레미스 풀이며 AWS가 존재하지 않는 로컬 하드웨어로 자동으로 "버스트"할 수 없으므로 고객은 장애 및 유지 관리 이벤트(예: N+1 용량)를 견딜 수 있도록 용량 여유 공간 및 노드 그룹 크기 조정을 계획해야 합니다. 주요 AWS 기능 / 모범 사례: Outposts는 고객이 제공하는 전력, 냉각, 랙 공간 및 Region으로의 네트워크 백홀을 요구합니다. AWS는 Outposts 하드웨어를 모니터링하고 유지 관리하지만, 고객은 제한된 온프레미스 공간에 적합한 Kubernetes 클러스터 용량, 포드 중단 예산(pod disruption budgets), 다중 노드 그룹 전략 및 조정 정책을 설계해야 합니다. 규정 준수를 위해 고객은 AWS 서비스 제어 및 로깅을 활용하면서 시설 제어를 HIPAA 관리적/물리적 보호 장치와 일치시킵니다. 일반적인 오해: 많은 사람들이 AWS가 "Region처럼" 모든 것을 관리한다고 가정합니다. 실제로 AWS는 Outposts 랙 하드웨어 및 기본 인프라를 관리하지만 고객의 시설이나 고객의 애플리케이션 용량 계획은 관리하지 않습니다. 또 다른 함정은 고객이 고장난 구성 요소를 교체한다고 생각하는 것입니다. AWS는 Outposts에 대한 하드웨어 수리/교체(break/fix)를 수행합니다. 시험 팁: Outposts 책임 질문의 경우 다음을 기억하십시오. 고객 = 사이트 준비(전력/네트워크/공간/냉각), 물리적 보안 및 워크로드 아키텍처/용량 계획. AWS = 배송/설치, 하드웨어 소유권, 하드웨어 유지 관리, Outposts 인프라 계층 및 지원되는 AWS 서비스 구성 요소 관리.

문제 8

비디오 스트리밍 플랫폼이 비디오 트랜스코딩 워크로드를 처리하기 위해 여러 Availability Zone에 분산된 Amazon EC2 인스턴스 플릿을 운영하고 있습니다. 이 인스턴스들은 Amazon EC2 Auto Scaling 그룹에 의해 관리되며 Network Load Balancer를 통해 트래픽을 수신합니다. 성능 테스트 결과, EC2 인스턴스가 35-45%의 CPU utilization을 유지할 때 비디오 트랜스코딩 품질과 처리 속도가 최적이며, 42%가 이상적인 목표인 것으로 나타났습니다. Auto Scaling 그룹의 모든 인스턴스에서 최적의 CPU utilization을 자동으로 유지하기 위해 solutions architect는 무엇을 권장해야 합니까?

문제 분석

핵심 개념 - 이 질문은 Amazon EC2 Auto Scaling의 dynamic scaling, 특히 step scaling과 target tracking scaling의 차이점을 테스트합니다. 또한 Amazon CloudWatch metric(CPUUtilization)을 사용하여 플릿을 원하는 운영 지점으로 유지하는 방법도 다룹니다. 정답인 이유 - target tracking scaling policy는 온도 조절기처럼 지정된 목표 값으로 metric을 유지하도록 설계되었습니다. 성능 테스트에서 이상적인 CPU utilization 목표(42%)와 허용 범위(35-45%)를 확인했으므로, target tracking이 가장 직접적이고 AWS에서 권장하는 접근 방식입니다. Auto Scaling은 인스턴스 전반의 평균 ASG CPUUtilization을 42%에 가깝게 유지하기 위해 desired capacity를 지속적으로 조정하며, utilization이 상승하면 자동으로 scale-out하고 하락하면 scale-in합니다. 주요 AWS 기능 - Target tracking scaling은 사전 정의되거나 사용자 지정된 metric을 사용합니다. 여기서는 사전 정의된 ASG metric인 Average CPU utilization이 적합합니다. 이는 기본 CloudWatch alarm을 자동으로 생성하고 관리하여 운영 오버헤드와 구성 오류 위험을 줄입니다. 또한 thrashing을 방지하기 위해 scale-in 동작 제어(예: scale-in cooldown/instance warmup)를 지원하며, 이는 용량을 제공하기 전에 시작 시간이 필요할 수 있는 트랜스코딩 워크로드에 중요합니다. 이는 성능 목표를 유지하기 위해 관리형 서비스와 자동화를 사용한다는 AWS Well-Architected Performance Efficiency 원칙과 일치합니다. 일반적인 오해 - Step scaling(옵션 A)은 여러 alarm과 step을 사용하여 범위를 근사화할 수 있지만, 단일 이상적인 목표를 유지하는 데는 더 복잡하고 덜 정확합니다. 지속적으로 42%를 향해 조정하기보다는 임계값에 반응합니다. Lambda 기반 컨트롤러(옵션 C)는 내장된 Auto Scaling 기능을 사용자 지정으로 재창조한 것이며 지연 시간, 장애 모드 및 유지 관리 부담을 초래합니다. Scheduled scaling(옵션 D)은 예측 가능한 수요 패턴에 유용하지만, 부하가 가변적일 때 실시간으로 특정 CPU 목표를 유지할 수는 없습니다. 시험 팁 - 질문에 특정 원하는 metric 값(예: "CPU를 42%로 유지")이 명시되어 있으면 target tracking scaling을 선택하세요. 개별 임계값과 다른 scaling 증분(예: "CPU > 70%인 경우 인스턴스 2개 추가")을 설명하는 경우 step scaling일 가능성이 높습니다. 내장 policy가 충족할 수 없는 명확한 요구 사항이 없는 한 사용자 지정 Lambda 컨트롤러보다 기본 Auto Scaling policy를 선호하세요.

문제 9

한 생명공학 연구소가 유전체 염기서열 분석을 위해 AWS에 high performance computing (HPC) 인프라를 구현해야 합니다. 이 연구소의 HPC 워크로드는 Linux 기반 시스템에서 작동합니다. 각 유전체 분석 워크플로는 수백 개의 Amazon EC2 Spot Instances를 활용하고, 2~6시간 내에 완료되며, 10년 이상 공동 연구 및 규정 준수를 위해 영구 스토리지에 저장해야 하는 수천 개의 시퀀스 데이터 파일을 생성합니다. 연구소는 기존 유전체 데이터 세트를 on-premises 스토리지에서 장기 영구 클라우드 스토리지로 전송할 수 있게 하여 모든 EC2 인스턴스가 처리를 위해 데이터에 액세스할 수 있도록 하는 클라우드 스토리지 솔루션이 필요합니다. 이 솔루션은 참조 유전체를 읽고 분석 출력 파일을 low latency로 쓰기 위해 영구 스토리지와 통합된 고성능 파일 시스템을 제공해야 합니다. 이러한 요구 사항을 충족하는 AWS 서비스 조합은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 대규모 데이터 세트에 대해 내구성 있는 장기 영구성을 제공하는 동시에 Linux 컴퓨팅 플릿을 위한 HPC 최적화 공유 파일 시스템을 선택하는 것을 테스트합니다. AWS에서 일반적인 패턴은 내구성 있고 비용 효율적인 보존을 위해 객체 스토어와 통합된 고성능 병렬 파일 시스템(low-latency, high-throughput POSIX 액세스용)입니다. 정답인 이유: Amazon FSx for Lustre는 Linux 환경의 HPC를 위해 특별히 구축되었으며, 수백 개의 EC2 인스턴스를 동시에 처리할 수 있도록 처리량을 확장할 수 있는 병렬 파일 시스템을 지원합니다. 이는 많은 Spot Instances에 분산되는 유전체 워크플로에 이상적입니다. FSx for Lustre는 Amazon S3와 기본적으로 통합됩니다. 빠른 처리를 위해 S3에서 기존 데이터 세트를 파일 시스템 네임스페이스로 가져오고(예: 참조 유전체), 영구 스토리지를 위해 결과를 S3로 다시 내보낼 수 있습니다. 이는 2~6시간의 작업 동안 읽기/쓰기를 위한 고성능 공유 파일 시스템을 제공하면서 on-prem 데이터 세트를 장기 클라우드 스토리지(S3)로 전송해야 하는 요구 사항과 일치합니다. 주요 AWS 기능: - FSx for Lustre는 병렬 워크로드를 위해 POSIX 시맨틱, low latency 및 매우 높은 총 처리량/IOPS를 제공합니다. - S3 통합은 데이터 리포지토리 연결(S3 버킷/접두사를 FSx 파일 시스템에 연결)을 지원하여 가져오기/내보내기 워크플로를 활성화하고 S3를 내구성 있는 기록 시스템으로 유지합니다. - S3는 10년 이상의 보존 및 규정 준수를 위해 데이터를 S3 Glacier/Deep Archive로 전환하는 수명 주기 정책(lifecycle policies)을 지원하는 동시에 메타데이터 및 액세스 제어를 중앙 집중화합니다. - 이 아키텍처는 임시 컴퓨팅(Spot Instances) + 영구 스토리지 모범 사례와 일치합니다. 컴퓨팅은 중단될 수 있지만 데이터는 S3에서 내구성을 유지합니다. 일반적인 오해: 자주 등장하는 함정은 공유 스토리지로 EBS를 선택하는 것입니다. EBS는 단일 인스턴스에 연결된 블록 스토리지(제한적인 다중 연결 시나리오 포함)이며 수백 개의 노드를 위한 확장 가능한 공유 파일 시스템이 아닙니다. 또 다른 함정은 활성 처리를 위한 고성능 POSIX 파일 시스템을 제공하지 않고 아카이브(Glacier)에만 집중하는 것입니다. 시험 팁: 'HPC', 'Linux', '수백 개의 인스턴스', 'low-latency 공유 파일 시스템'이 보이면 FSx for Lustre를 생각하십시오. 또한 '장기 보존' 및 '데이터 레이크/객체 스토리지'가 보이면 S3(및 선택적으로 Glacier 클래스로의 수명 주기)와 페어링하십시오. Windows FSx는 Linux HPC 병렬 I/O가 아닌 SMB/Windows 워크로드용입니다.

문제 10

게임 개발 스튜디오인 GameCraft는 개발용 'Sandbox' 계정과 라이브 게임용 'Production' 계정이라는 두 개의 AWS 계정을 사용합니다. 이 스튜디오는 Sandbox 계정에서 Production 계정으로 새로운 게임 업데이트를 배포해야 합니다. 초기에는 개발 팀의 소수 수석 엔지니어만 Production 계정에 대한 액세스 권한이 필요합니다. 시간이 지남에 따라 더 많은 엔지니어가 테스트를 위해 임시 액세스 권한을 필요로 하게 될 것입니다. 엔지니어에게 안전하고 확장 가능한 cross-account 액세스를 제공하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 AWS IAM role 및 STS(AssumeRole)를 사용한 안전한 cross-account 액세스를 테스트합니다. 모범 사례는 대상 계정에서 장기 자격 증명을 피하고 대신 role assumption을 통해 임시 자격 증명을 사용하는 것입니다. 정답인 이유: 옵션 C는 Production 계정(리소스 소유/대상 계정)에 IAM role을 생성하고 Sandbox 계정을 principal로 신뢰하도록 role trust policy를 구성합니다. 개발자는 Sandbox 계정에서 인증(이상적으로는 IAM Identity Center 또는 federated SSO를 통해)한 다음, Production role을 assume하여 수명이 짧은 자격 증명을 얻습니다. 이는 안전하고(공유 암호/키 없음), 확장 가능하며(Sandbox에서 role을 assume할 수 있는 사람을 변경하여 엔지니어 추가/제거), 세션 기간 및 권한을 제어하여 테스트를 위한 임시 액세스를 지원합니다. 주요 AWS 기능: 1) Role trust policy (Production 계정): Sandbox 계정에서 sts:AssumeRole을 허용합니다(선택적으로 특정 principal/role, external ID 또는 MFA와 같은 조건으로 제한). 2) Permission policy (Production role): 배포/테스트에 필요한 최소 권한(least-privilege)을 부여합니다. 3) Caller permissions (Sandbox 계정): 개발자(또는 Sandbox “Deployer” role/group)는 필요한 경우에만 iam:PassRole을 얻고 Production role ARN에 대한 sts:AssumeRole 권한을 얻습니다. 4) 임시 자격 증명: STS는 시간 제한이 있는 자격 증명을 발급합니다. CloudTrail은 감사 가능성을 위해 두 계정 모두에 AssumeRole 이벤트를 기록합니다. 일반적인 오해: 많은 사람들이 권한을 사용자/그룹에 직접 "cross-account로 부여"할 수 있거나(옵션 D) role이 소스 계정에 있어야 한다고(옵션 B) 가정합니다. AWS에서 다른 계정의 리소스에 대한 액세스는 일반적으로 그룹에 cross-account 권한을 연결하는 것이 아니라 소스 계정을 신뢰하는 대상 계정의 role에 의해 달성됩니다. 시험 팁: cross-account 사용자 액세스의 경우 "대상 계정의 IAM role + trust policy + sts:AssumeRole"을 찾으십시오. 여러 계정에 IAM user를 생성하는 것보다 role을 선호하십시오. 기억하세요: trust policy는 "누가 assume할 수 있는지"에 답하는 반면, permission policy는 "그들이 무엇을 할 수 있는지"에 답합니다. 더 강력한 보안과 확장 가능한 거버넌스를 위해 조건(MFA, session tags, source identity)을 추가하십시오. 도메인: 이것은 최소 권한, 임시 자격 증명 및 안전한 cross-account 액세스 패턴에 중점을 두기 때문에 Design Secure Architectures에 매핑됩니다.

Practice Test #8

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(29)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

Practice Test #7

Practice Test #9

Practice Test #10

지금 학습 시작하기