연습 문제

문제 1

한 의료 기술 회사가 Amazon RDS for PostgreSQL 데이터베이스에 의료 기록과 영상 데이터를 저장하는 환자 관리 시스템을 운영하고 있습니다. 이 데이터베이스에는 관련 메타데이터와 함께 1,500만 개 이상의 환자 기록이 포함되어 있습니다. 데이터베이스는 3TB의 General Purpose SSD 스토리지를 사용하며, 환자 데이터 업데이트, 예약 일정 관리, 의료 기록 삽입을 위해 병원과 클리닉에서 발생하는 매일 수백만 건의 트랜잭션을 처리합니다. 최근 성능 모니터링에 따르면 신규 환자 등록 작업이 완료되는 데 12~15초가 걸려 사용자 경험에 큰 영향을 미치고 있습니다. 분석 결과 데이터베이스 스토리지 I/O 성능이 병목 현상의 원인으로 확인되었습니다. 이 스토리지 성능 문제를 가장 효과적으로 해결할 수 있는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 Amazon RDS 스토리지 성능 튜닝, 특히 EBS 기반 RDS 스토리지 유형(General Purpose SSD 대 Provisioned IOPS SSD)이 쓰기 작업이 많은 OLTP 워크로드의 I/O 지연 시간 및 처리량에 미치는 영향을 테스트합니다. 정답인 이유: 모니터링 및 분석에서 스토리지 I/O가 병목 현상임을 명시적으로 식별했으며, 워크로드에는 느린 삽입/등록 작업(쓰기 경로)이 포함된 매일 수백만 건의 트랜잭션이 포함됩니다. 3TB의 General Purpose SSD(gp2/gp3)를 사용하면 스토리지의 IOPS/처리량 특성에 의해 성능이 제한됩니다. Provisioned IOPS SSD(io1/io2)는 I/O 집약적이고 지연 시간에 민감한 데이터베이스를 위해 설계되었으며, 더 예측 가능한 성능으로 높은 IOPS를 프로비저닝하고 유지할 수 있게 해줍니다. io1/io2로 직접 이동하는 것은 확인된 병목 현상을 타겟팅하며 I/O 대기 시간을 줄이고 트랜잭션 지연 시간을 개선하는 가장 효과적인 단일 변경 사항입니다. 주요 AWS 기능: - RDS 스토리지 유형: General Purpose SSD는 비용 효율적이지만 크고 바쁜 OLTP 시스템에 충분한 지속적 IOPS를 제공하지 못할 수 있습니다. Provisioned IOPS SSD는 일관되고 높은 IOPS를 제공합니다. - io2(및 지원되는 경우 io2 Block Express)는 대규모에서 io1보다 더 높은 내구성과 더 나은 가격/성능을 제공하며, 중요한 프로덕션 데이터베이스에 일반적으로 권장됩니다. - 스토리지 확장 및 성능 튜닝: 워크로드 수요에 맞게 RDS 스토리지 유형 및 프로비저닝된 IOPS(엔진/인스턴스 제한 내)를 수정할 수 있습니다. 일반적인 오해: 쿼리가 느릴 때 DB instance를 "스케일 업"(더 많은 RAM/CPU)하고 싶을 수 있지만, 병목 현상이 스토리지 I/O인 경우 추가 메모리/CPU는 종종 제한적인 개선만 가져옵니다. 마찬가지로 Multi-AZ/read replica는 가용성과 읽기 확장을 개선하지만, 스토리지 제약으로 인한 기본 쓰기 지연 시간은 개선하지 않습니다. 시험 팁: 질문에서 병목 현상이 스토리지 I/O라고 명시하는 경우, instance class 변경보다 스토리지 유형 변경(Provisioned IOPS, 처리량/IOPS 프로비저닝)을 우선시하십시오. RDS에서 쓰기 작업이 많은 OLTP의 경우, io1/io2는 예측 가능하고 지연 시간이 짧은 I/O를 위한 정답입니다. 또한 기억하십시오: Multi-AZ는 HA/장애 조치를 위한 것이고, read replica는 읽기 확장을 위한 것입니다. 둘 다 EBS I/O 제한으로 인한 primary의 느린 쓰기를 수정하지 않습니다.

문제 2

(2개 선택)

한 온라인 교육 플랫폼이 Amazon EC2에서 학습 관리 시스템(LMS)을 운영하고 있습니다. LMS는 단일 EC2 instance에서 실행되며 코스 데이터 및 학생 기록을 저장하기 위해 Amazon Aurora PostgreSQL Multi-AZ DB instance를 사용합니다. 코스 비디오 및 교육 자료는 EC2 instance 내부에 마운트된 Amazon Elastic Block Store(Amazon EBS) 볼륨에 저장됩니다. 이 플랫폼은 5,000명 이상의 동시 접속 학생이 코스 자료에 접근하는 등록 피크 기간 동안 성능 병목 현상을 겪습니다. 회사는 트래픽 급증을 처리하기 위해 시스템 성능을 개선하고 고가용성을 보장해야 합니다. 학습 플랫폼의 성능과 복원력을 개선하기 위해 솔루션 아키텍트가 취해야 할 작업 조합은 무엇입니까? (2개 선택)

문제 분석

핵심 개념: 이 질문은 EC2에서 확장 가능하고 가용성이 높은 웹 애플리케이션 계층을 설계하고 단일 instance에서 공유 콘텐츠 스토리지를 분리하는 것을 테스트합니다. 또한 트래픽 급증 시 오리진 부하를 줄이기 위해 엣지 캐싱을 사용하는 것을 테스트합니다. 정답인 이유: LMS는 연결된 EBS 볼륨에 코스 자료가 있는 단일 EC2 instance입니다. EBS는 하나의 instance(및 하나의 AZ)에 연결된 블록 스토리지이므로 정적 콘텐츠에 대한 성능 병목 현상이자 단일 장애 점이 됩니다. 웹 계층을 수평으로 확장하려면 여러 EC2 instance가 동일한 공유 콘텐츠에 접근해야 합니다. Amazon EFS는 많은 EC2 instance가 동시에 마운트할 수 있는 관리형, 탄력적, 다중 AZ NFS 파일 시스템을 제공하여 복원력을 향상시키면서 비디오/자료에 대한 공유 접근을 가능하게 합니다. 다음으로 플랫폼은 5,000명 이상의 동시 학생을 처리해야 합니다. AMI를 생성하고 최소 2개의 instance가 있는 Auto Scaling group(ASG)의 Application Load Balancer(ALB) 뒤에 instance를 배치하면 여러 AZ에 걸쳐 고가용성을 제공하고 피크 시 스케일 아웃됩니다. 플랫폼 앞에 Amazon CloudFront를 추가하면 엣지 로케이션에서 자주 접근하는 코스 콘텐츠를 캐시하고 제공하여 학생들의 지연 시간을 줄이고 ALB/EC2 및 공유 파일 시스템의 요청을 오프로드합니다. 주요 AWS 기능: - Amazon EFS: 다중 AZ 내구성/가용성, 탄력적 처리량, 동시 마운트, POSIX 권한; ASG 전반의 공유 웹 콘텐츠에 이상적입니다. - ALB + ASG: 다중 AZ 로드 밸런싱, 상태 검사, 자동 교체, 스케일 아웃/인 정책; 최소 용량 2는 가용성을 향상시킵니다. - CloudFront: 엣지 캐싱, 오리진 장애 조치 패턴, 오리진 부하 감소, 글로벌 성능 향상; 아키텍처에 따라 ALB(동적) 및/또는 S3/EFS 기반 오리진을 사용할 수 있습니다. 일반적인 오해: - "모든 instance에 S3 마운트"는 프로덕션 워크로드를 위한 표준적이고 지원되는 POSIX 파일 시스템 접근 방식이 아닙니다. S3는 NFS가 아니라 API를 통해 접근하는 객체 스토리지입니다. - 기본 EC2 instance에서 NFS 공유를 사용하면 단일 장애 점이 유지되며 고가용성 목표를 충족하지 못합니다. - Global Accelerator는 리전 endpoint로의 TCP/UDP 라우팅을 최적화하지만 캐싱을 제공하지는 않습니다. 무거운 정적 콘텐츠 접근의 경우 일반적으로 CloudFront가 더 적합합니다. 시험 팁: "단일 EC2 instance 내부에 마운트된 EBS"와 "여러 instance 및 HA 필요"를 보면 EFS(공유 POSIX) 또는 S3(객체)를 생각하십시오. "많은 동시 사용자가 정적 자료에 접근"을 보면 ALB 뒤의 Auto Scaling 웹 계층과 CloudFront 캐싱을 생각하십시오.

문제 3

한 금융 서비스 회사가 단일 VPC 내의 Amazon EC2 instance에서 분산 문서 처리 시스템을 운영하고 있습니다. EC2 instance는 내결함성을 위해 서로 다른 Availability Zone의 여러 서브넷에 배포됩니다. 이러한 instance는 instance 간 통신 없이 독립적으로 작동하지만 단일 NAT gateway를 통해 Amazon S3에서 재무 보고서를 자주 다운로드하고 처리된 문서를 S3에 다시 업로드합니다. 회사는 매일 약 500GB의 문서를 처리하며 상당한 데이터 전송 비용을 겪고 있습니다. 현재 아키텍처를 유지하면서 리전 데이터 전송 요금을 없애기 위한 가장 비용 효율적인 솔루션을 찾아야 합니다. 회사가 리전 데이터 전송 요금을 피할 수 있는 가장 비용 효율적인 방법은 무엇입니까?

문제 분석

핵심 개념: 이 질문은 Amazon S3에 접근하는 private subnet을 위한 비용 최적화된 VPC 이그레스 설계를 테스트합니다. 핵심 개념은 S3 접근에 NAT gateway를 사용하면 트래픽이 AZ 범위의 NAT를 통과하도록 강제되어 리전 데이터 전송 요금이 발생할 수 있는 반면(특히 여러 AZ의 서브넷이 한 AZ의 단일 NAT를 사용하는 경우), Amazon S3 gateway VPC endpoint는 NAT 없이 AWS 네트워크에 S3 트래픽을 유지한다는 것입니다. 정답인 이유: Amazon S3용 gateway VPC endpoint는 인터넷 게이트웨이, 퍼블릭 IP 또는 NAT 디바이스 없이 VPC에서 S3로의 프라이빗 직접 연결을 제공합니다. 이는 S3 바운드 트래픽에 대한 NAT gateway 데이터 처리 요금을 제거하고 AZ-B/C의 instance가 AZ-A에 있는 NAT gateway로 라우팅될 때 발생하는 교차 AZ 데이터 전송을 방지합니다. 매일 약 500GB의 S3 다운로드/업로드가 있는 경우 NAT 처리 및 교차 AZ 라우팅을 제거하는 것이 일반적으로 private subnet의 EC2 아키텍처를 동일하게 유지하면서 이러한 리전 데이터 전송 요금을 줄이거나 없애는 가장 비용 효율적인 방법입니다. 주요 AWS 기능: - Gateway VPC endpoint(S3/DynamoDB): private subnet의 라우팅 테이블에 추가됩니다. - Endpoint 정책: 허용되는 S3 버킷/작업을 제한합니다(최소 권한 지원). - aws:SourceVpce를 사용하는 S3 버킷 정책과 함께 작동하여 endpoint를 통해서만 접근을 강제합니다. - Gateway endpoint에 대한 시간당 요금은 없습니다. NAT 처리가 아니라 S3에 적용되는 S3 요청 및 데이터 전송에 대해서만 비용을 지불합니다. 일반적인 오해: "더 많은 NAT gateway"(AZ당 하나)가 해결책이라고 생각하기 쉽습니다. 교차 AZ 데이터 전송은 줄어들지만 NAT 시간당 비용이 증가하고 모든 S3 트래픽에 대해 여전히 NAT 데이터 처리 요금이 발생합니다. 또 다른 오해는 NAT instance가 더 저렴하다는 것입니다. 시간당 비용은 줄일 수 있지만 운영 오버헤드, 확장 제한이 발생하며 S3로의 목적에 맞게 구축된 프라이빗 경로를 사용하는 대신 트래픽이 여전히 NAT를 통해 흐르도록 유지합니다. 시험 팁: Private subnet이 대규모로 S3/DynamoDB에 접근해야 하는 경우 비용과 보안을 위해 기본적으로 gateway VPC endpoint를 사용하십시오. NAT gateway는 주로 일반 인터넷 이그레스(예: OS 업데이트, 외부 API)에 사용하십시오. "단일 NAT gateway" + "여러 AZ" + "높은 데이터 볼륨"이 표시되면 교차 AZ 요금을 생각하고 AWS 서비스 트래픽에 대해 먼저 endpoint를 고려하십시오.

문제 4

한 의료 연구 기관이 의료 이미지 처리 시스템을 AWS로 마이그레이션해야 합니다. 이 기관은 다양한 병원과 클리닉에서 SFTP를 통해 매일 수백 개의 DICOM 의료 이미지를 수신합니다. 현재 온프레미스 시스템은 완료하는 데 몇 시간이 걸리는 일괄(batch) 처리를 사용하여 밤새 이 이미지들을 처리합니다. 이 기관은 병원에서 사용하는 SFTP 클라이언트에 대한 변경을 최소화하면서 수신되는 의료 이미지가 도착하는 즉시 처리하는 AWS 솔루션을 원합니다. 이 솔루션은 성공적인 분석 후 처리된 이미지를 자동으로 삭제해야 합니다. 각 이미지 처리 작업은 완료하는 데 4-10분이 소요됩니다. 운영상 가장 효율적인 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 5

글로벌 물류 회사가 Amazon S3 버킷에 JSON 파일로 저장된 일일 배송 매니페스트를 처리하기 위해 AWS Glue를 사용합니다. ETL 작업은 매일 아침 6시에 자동으로 실행되어 배송 데이터를 추출하고, 분석을 위해 변환한 후 데이터 웨어하우스에 로드합니다. 솔루션 아키텍트는 매일 실행될 때마다 지난 30일 동안 이전에 처리된 파일을 포함하여 약 500GB의 누적 데이터를 처리하는 것을 관찰했습니다. 이로 인해 작업 실행 시간이 초기 15분에서 현재 2시간 이상으로 증가하여 운영 비용에 큰 영향을 미치고 분석 보고가 지연되고 있습니다. AWS Glue가 매일 새로운 배송 데이터만 처리하도록 하려면 솔루션 아키텍트는 무엇을 구현해야 합니까?

문제 분석

핵심 개념: 이 질문은 S3 기반 데이터 레이크를 위한 AWS Glue 증분 처리 패턴을 테스트합니다. AWS Glue ETL 작업이 동일한 S3 접두사를 반복적으로 스캔할 때, 이미 처리된 항목을 추적하는 메커니즘을 구현하지 않으면 과거 객체를 다시 읽게 됩니다. 핵심 기능은 작업 실행 간의 상태를 유지하는 AWS Glue job bookmarks입니다. 정답인 이유: job bookmarks를 활성화하면 마지막으로 성공한 실행 이후의 새 데이터(또는 변경된 데이터)만 Glue 작업이 처리하도록 보장합니다. S3 소스의 경우, bookmarks는 이전에 처리된 파일/파티션을 추적하여 후속 실행에서 이를 건너뛸 수 있게 합니다. 이는 관찰된 동작(작업이 약 30일치 파일(누적 500GB)을 재처리하여 실행 시간과 비용이 증가하는 문제)을 직접적으로 해결합니다. bookmarks를 사용하면 매일 오전 6시 실행 시 새로 도착한 일일 매니페스트에만 집중하여 실행 시간을 안정화하고 소비되는 DPU를 줄일 수 있습니다. 주요 AWS 기능: Job bookmarks는 작업 수준(Enable job bookmark)에서 구성되며 Glue DynamicFrames 및 지원되는 소스와 함께 작동합니다. AWS Glue Data Catalog/메타데이터에 상태를 유지하여 작업이 재개되고 재처리를 방지할 수 있습니다. 모범 사례는 bookmarks를 파티셔닝된 S3 레이아웃(예: s3://bucket/manifests/dt=YYYY-MM-DD/) 및 조건부 푸시다운(predicate pushdown)/파티션 프루닝(partition pruning)과 결합하여 읽기 속도를 더욱 높이는 것입니다. 이는 스캔되는 데이터 감소, 실행 시간 단축, 컴퓨팅 리소스 최적화라는 비용 최적화 원칙과 일치합니다. 일반적인 오해: 처리된 파일을 이동하는 것(옵션 B)은 운영상 작동할 수 있지만 복잡성, 추가적인 S3 복사/삭제 비용, 잠재적인 데이터 거버넌스 문제를 야기하며 데이터 계보(lineage)/감사를 손상시킬 수 있습니다. DPU를 줄이는 것(옵션 C)은 읽는 데이터 양을 줄이지 않으며, 일반적으로 실행 시간을 늘리고 비용을 악화시킬 수 있습니다. DataBrew 중복 제거(옵션 D)는 반복적인 파일 스캔이 아니라 중복 레코드를 처리하는 것이므로 Glue는 여전히 모든 과거 파일을 읽게 됩니다. 시험 팁: AWS Glue에서 "새 데이터만 처리"라는 문구를 보면 가장 먼저 "job bookmarks"를 떠올리십시오. S3 기반 ETL의 경우 파티셔닝 + bookmarks가 일반적인 시험 패턴이라는 점도 기억하십시오. 오래된 객체를 다시 읽어 실행 시간이 증가하는 문제라면, 해결책은 컴퓨팅 제한이나 레코드 수준의 중복 제거가 아니라 증분 처리/상태 추적입니다.

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

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

문제 6

의료 연구 기관이 의료 영상 데이터와 연구 데이터 세트를 저장하는 온프레미스 NFS 파일 서버를 운영하고 있습니다. 영상 파일은 생성 후 처음 10일 동안 연구원들이 분석 및 처리를 위해 집중적으로 액세스합니다. 10일이 지나면 규정 준수 및 아카이브 목적으로 파일에 드물게 액세스합니다. 전체 데이터 볼륨이 빠르게 증가하여 기관의 스토리지 용량 한계에 도달하고 있습니다. 솔루션 아키텍트는 최근에 생성된 파일에 대한 low-latency 액세스를 유지하고 자동화된 데이터 수명 주기 관리(lifecycle management)를 구현하면서 스토리지 용량을 확장해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 on-premises의 NFS 기반 파일 워크로드를 AWS로 확장하면서, 활성 파일에 대한 low-latency 액세스를 유지하고 오래된 데이터를 더 저렴한 스토리지로 자동 이동하는 방법에 관한 것입니다. 이 패턴의 핵심 AWS 서비스는 Amazon S3 File Gateway이며, on premises에서 NFS/SMB 인터페이스를 제공하고 자주 액세스되는 데이터를 위한 로컬 캐시와 함께 파일을 Amazon S3의 객체로 저장합니다. 정답인 이유: 이 연구소는 연구원들이 파일에 액세스하는 방식을 변경하지 않고 스토리지 용량을 확장해야 하며, 최근에 생성된 파일은 계속 빠르게 액세스할 수 있어야 합니다. Amazon S3 File Gateway는 S3를 기반으로 하는 file share 인터페이스를 제공하고 활성 데이터를 로컬에 캐시하여 low-latency 액세스를 지원하므로 이 요구를 충족합니다. 그런 다음 Lifecycle management를 사용해 10일 후 오래된 객체를 더 저렴한 아카이브 스토리지 클래스로 자동 전환할 수 있어, hot-to-cold 액세스 패턴을 만족합니다. 주요 AWS 기능: - Amazon S3 File Gateway는 on-premises 사용자와 애플리케이션에 NFS/SMB 액세스를 제공하면서 데이터를 내구성 있게 Amazon S3에 저장합니다. - 로컬 캐싱은 최근에 사용된 파일을 low latency로 사용할 수 있게 유지하므로, 처음 10일 동안의 집중적인 액세스에 이상적입니다. - S3 Lifecycle policies는 오래된 객체를 S3 Glacier Flexible Retrieval과 같은 아카이브 클래스로 자동 전환하여 더 저렴한 비용으로 장기 보관할 수 있게 합니다. 흔한 오해: - AWS DataSync는 전송 및 마이그레이션 서비스이지, 로컬 캐싱이 있는 투명한 하이브리드 파일 스토리지 확장 솔루션이 아닙니다. - Amazon FSx for Lustre는 고성능 컴퓨팅 워크로드에 최적화되어 있으며, 기존 on-prem NFS 환경을 lifecycle 기반 아카이빙과 함께 확장하는 용도가 아닙니다. - 워크스테이션에서 직접 S3에 액세스하려면 S3가 native NFS 파일 시스템이 아닌 object storage이기 때문에 애플리케이션과 워크플로 변경이 필요합니다. 시험 팁: 문제에서 on-premises NFS 또는 SMB 워크로드를 언급하면서, 최소한의 애플리케이션 변경으로 AWS로 자연스럽게 확장해야 한다고 하면 AWS Storage Gateway, 특히 S3 File Gateway를 떠올리세요. 또한 데이터의 자동 노후화와 더 저렴한 스토리지로의 이동을 언급하면, File Gateway와 S3 Lifecycle policies를 함께 생각해야 합니다. Glacier 스토리지 클래스는 retrieval 요구 사항에 따라 구분해야 합니다. Deep Archive는 매우 드물게 검색되는 데이터와 매우 긴 retrieval 시간에 적합하고, Flexible Retrieval은 가끔 retrieval이 예상될 때 더 적합합니다.

문제 7

엔터프라이즈 'TechCorp'는 온프레미스 Microsoft Active Directory에서 AWS로 애플리케이션을 마이그레이션하고 있습니다. 이 회사는 AWS Organizations를 사용하여 여러 AWS 계정을 중앙에서 관리합니다. 보안 팀은 모든 AWS 계정에 걸쳐 SSO(Single Sign-On) 솔루션을 요구합니다. 회사는 기존 온프레미스 Active Directory에서 사용자 및 그룹을 계속 관리해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 기존 on-premises Microsoft Active Directory를 권한 있는 identity store로 유지하면서, AWS Organizations의 여러 AWS accounts 전반에서 AWS IAM Identity Center(AWS SSO의 후속 서비스)를 사용해 federated identity와 centralized access management를 구현하는지를 테스트합니다. 정답인 이유: Option A는 표준 AWS 패턴과 일치합니다. management account(또는 delegated admin)에서 IAM Identity Center를 활성화하고, AWS Directory Service for Microsoft Active Directory(AWS Managed Microsoft AD)를 통해 Microsoft AD에 연결합니다. 그런 다음 AWS Managed Microsoft AD와 on-premises AD 사이에 trust relationship을 설정하여 사용자와 그룹을 계속 on-premises에서 관리할 수 있게 하면서, IAM Identity Center가 AD identities를 사용해 모든 member accounts에 SSO를 제공할 수 있습니다. IAM Identity Center는 Organizations와 기본적으로 통합되어 accounts 전반에 permission sets를 할당할 수 있으므로, “모든 AWS accounts에서 SSO” 요구 사항을 충족합니다. 주요 AWS 기능: - IAM Identity Center + AWS Organizations integration: 조직 전체에서 centralized user access, permission sets, account assignments 제공 - AWS Directory Service for Microsoft AD: on-prem AD와 trust를 설정할 수 있는 AWS의 managed AD로, 기존 users/groups를 사용할 수 있게 함 - Trust relationships: on-prem AD에 대한 authentication을 허용하면서 AWS 측 integrations를 가능하게 하는 데 일반적으로 사용됨 - Best practice: workforce access에는 account별 IAM users보다 IAM Identity Center를 사용하고, authorization은 permission sets와 groups를 통해 관리 흔한 오해: 자주 나오는 함정은 Directory Service와 trust를 생성하기만 하면 모든 곳에서 “자동으로 SSO가 활성화된다”고 생각하는 것입니다(그렇지 않습니다). 또 다른 오해는 사용자를 AWS Managed Microsoft AD로 반드시 마이그레이션해야 한다는 것인데, trust를 사용하면 users/groups를 on-prem에 그대로 유지할 수 있습니다. 또한 EC2에 custom IdP를 배포하는 것은 불필요하며, managed integrations에 비해 운영 및 보안 부담을 증가시킵니다. 시험 팁: “multiple accounts”, “AWS Organizations”, “SSO”가 보이면 IAM Identity Center를 떠올리세요. “users/groups를 on-prem AD에 유지해야 함”이 보이면 Directory Service + AD trust(또는 direct SAML을 기존 IdP(예: ADFS/Azure AD)에 연결하는 방식, 선택지에 있다면)를 떠올리세요. 요구 사항이 custom IdP deployment를 명시적으로 요구하지 않는 한, custom IdP deployment보다 managed services를 우선하세요.

문제 8

소셜 네트워킹 애플리케이션 'ConnectSphere'에는 5TB의 사용자 데이터가 있는 데이터베이스가 있습니다. 이 데이터는 100만 개의 사용자 프로필과 그 사이의 1,000만 개의 연결로 구성되어 복잡한 다대다(many-to-many) 관계를 나타냅니다. 애플리케이션은 고성능 방식으로 최대 5단계 깊이까지 사용자 간의 상호 연결을 자주 찾아야 합니다. 솔루션 아키텍트는 이러한 관계를 탐색하고 다단계 연결을 빠르게 찾는 데 매우 효율적인 데이터베이스 솔루션을 식별해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

Core Concept: 이 질문은 고도로 연결된 데이터 및 깊은 관계 탐색에 적합한 데이터베이스를 선택하는 것을 테스트합니다. 그래프 데이터베이스는 다대다 관계 및 다중 홉(multi-hop) 쿼리(예: 최대 N단계까지의 "친구의 친구")를 예측 가능한 성능으로 처리하도록 특별히 구축되었습니다. Why the Answer is Correct: Amazon Neptune은 그래프 쿼리 언어를 사용하여 관계를 탐색하는 데 최적화된 AWS의 관리형 그래프 데이터베이스입니다. 100만 개의 사용자 정점(vertices)과 1,000만 개의 연결 간선(edges)이 있는 상황에서 "최대 5단계 깊이의 상호 연결"과 같은 쿼리는 그래프 탐색에 직접 매핑됩니다. Neptune은 관계를 저장하고 인덱싱하므로 다중 홉 탐색 시 비용이 많이 드는 테이블 조인을 피할 수 있으며 그래프가 커져도 효율적으로 실행될 수 있습니다. 이것이 바로 Neptune이 설계된 소셜 네트워크 패턴입니다. Key AWS Features: Neptune은 Property Graph(Gremlin)와 RDF(SPARQL)를 모두 지원하여 표현력 있는 탐색 쿼리(예: 가변 길이 경로 탐색, 공통 이웃/상호 연결)를 가능하게 합니다. 관리형(자동 백업, 패치 적용)이며, 읽기 확장을 위한 읽기 전용 복제본(read replicas)을 지원하고, 여러 AZ에 걸쳐 고가용성을 제공합니다. 성능 측면에서 Neptune의 그래프 최적화 스토리지 및 인덱싱은 관계형 JOIN 중심 접근 방식의 전형적인 컴퓨팅 오버헤드를 줄여줍니다. 이는 액세스 패턴에 맞는 데이터 스토어를 선택하라는 AWS Well-Architected Performance Efficiency 원칙과 일치합니다. Common Misconceptions: 관계형 데이터베이스(RDS MySQL)는 관계를 모델링할 수 있지만, 깊은 재귀 조인(CTE)은 대규모에서 복잡해지고 종종 느려지며, 특히 다단계 탐색 및 상호 연결 계산의 경우 더욱 그렇습니다. DynamoDB는 인접 리스트(adjacency lists)를 저장할 수 있지만, 다중 홉 탐색에는 많은 왕복(GetItem/Query 체인)과 복잡한 애플리케이션 측 로직이 필요하며 지연 시간이 길어질 수 있습니다. S3 + Athena는 지연 시간이 짧고 대화형인 그래프 탐색이 아니라 파일에 대한 분석을 위한 것입니다. Exam Tips: "highly connected data", "many-to-many", "path finding", "mutual friends", "recommendations" 또는 "multi-level traversal"을 보면 그래프 데이터베이스를 떠올리십시오. AWS 시험에서 Amazon Neptune은 빠른 관계 탐색이 필요한 그래프 워크로드를 위한 기본 관리형 서비스입니다. 반대로 Athena는 임시 분석용, RDS는 트랜잭션 관계형 패턴용, DynamoDB는 예측 가능한 한 자리 수 밀리초 조회가 가능한 키-값/문서 액세스 패턴용이며 깊은 그래프 탐색용이 아닙니다.

문제 9

글로벌 건강 보험 회사는 매일 100,000건 이상의 보험 청구를 처리하고 3,000만 명 이상의 보험 가입자에게 서비스를 제공합니다. 이 회사는 청구 처리 데이터를 Amazon S3에 저장하고 보험 가입자 정보를 Amazon RDS에 유지 관리합니다. 회사는 분석 목적으로 모든 데이터를 여러 부서(계리, 사기 탐지, 고객 서비스)에서 사용할 수 있도록 하려고 합니다. 솔루션은 세분화된 액세스 제어(fine-grained access control) 기능을 제공하고 운영 오버헤드를 최소화해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

Core Concept: 이 질문은 세분화된 권한과 낮은 운영 오버헤드를 갖춘 관리형 분석 플랫폼(데이터 레이크) 구축을 테스트합니다. 주요 서비스는 AWS Lake Formation(중앙 집중식 데이터 레이크 거버넌스), AWS Glue Data Catalog(메타데이터) 및 S3(데이터 레이크 스토리지)이며 Glue를 통해 Amazon RDS에 연결합니다. Why the Answer is Correct: 옵션 C는 Lake Formation을 사용하여 데이터 레이크를 생성하고, S3 버킷을 등록하며, Glue JDBC 연결을 사용하여 RDS 데이터에 액세스/수집하여 레이크 거버넌스 모델로 가져옵니다. Lake Formation은 여러 분석 소비자 및 엔진(예: Athena, Redshift Spectrum, EMR, Glue) 전반에 걸쳐 중앙 집중식의 세분화된 액세스 제어(LF-Tags 및 권한 부여를 통한 데이터베이스/테이블/열/행 수준)를 제공합니다. 이는 사용자 지정 파이프라인과 분산된 IAM/S3 정책 대신 관리형 권한 모델을 통해 최소 권한을 적용하고 운영 오버헤드를 최소화하면서 여러 부서에서 모든 데이터를 사용할 수 있도록 하는 요구 사항과 직접적으로 일치합니다. Key AWS Features: - Lake Formation 권한: Data Catalog 리소스에 대한 세분화된 권한 부여; 확장 가능한 ABAC 스타일 거버넌스를 위한 LF-Tags; 필요한 경우 교차 계정 공유. - 중앙 집중식 거버넌스: 누가 어떤 테이블/열을 볼 수 있는지 관리하는 단일 장소(예: 고객 서비스는 제한된 PII를 보고, 사기 팀은 더 많은 속성을 봅니다). - Glue Data Catalog와의 통합: S3 데이터 세트에 대한 일관된 메타데이터; RDS 소스에 대한 Glue 연결. - 운영 단순성: 맞춤형 ETL 및 복잡한 정책 확산을 구축/유지 관리하지 않아도 됩니다. AWS Well-Architected Security Pillar(최소 권한, 중앙 집중식 제어) 및 Operational Excellence(관리형 서비스)와 일치합니다. Common Misconceptions: 팀은 종종 S3 버킷 정책만으로 "세분화된 액세스"를 해결하려고 합니다(옵션 B). S3 정책은 강력하지만 테이블/열 수준 거버넌스의 경우 복잡해지며 엔진 전반에 걸쳐 분석 수준 권한을 기본적으로 표현하지 않습니다. 다른 사람들은 혼합된 소스 전반에 걸쳐 최소한의 운영과 강력한 거버넌스를 갖춘 광범위한 부서별 분석이 요구 사항인 경우에도 웨어하우스(옵션 D)를 기본값으로 설정합니다. Exam Tips: "data lake", "multiple departments", "fine-grained access control" 및 "minimize operational overhead"를 보면 Lake Formation + Glue Data Catalog를 생각하십시오. 거버넌스(테이블/열/행 수준, 태그 기반 액세스, 중앙 집중식 권한)가 주요 요구 사항인 경우, 특히 S3를 레이크로 사용하고 여러 분석 페르소나가 데이터를 소비하는 경우 Lake Formation을 선택하십시오.

문제 10

한 의료 기관이 환자 관리 및 청구 정보를 저장하는 Microsoft SQL Server 데이터베이스를 on-premises에서 운영하고 있습니다. 이 기관은 AWS 클라우드 인프라로 마이그레이션할 계획이며, 마이그레이션 프로세스 중에 데이터베이스를 최신 SQL Server 버전으로 업그레이드하고자 합니다. 이 기관은 중요한 의료 데이터의 비즈니스 연속성을 보장하기 위해 여러 리전에 걸친 disaster recovery 솔루션이 필요합니다. 일상적인 운영과 DR 구현 모두에서 관리 오버헤드를 최소화해야 합니다. 또한, 의료 규정에서 요구하는 규정 준수 감사 및 사용자 지정 보안 구성을 위해 데이터베이스의 기본 Windows 운영 체제에 대한 전체 액세스 권한을 유지해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

Practice Test #9

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 #8

Practice Test #10

지금 학습 시작하기