연습 문제

문제 1

한 미디어 회사는 Windows Server 2019에서 실행 중인 온프레미스 Microsoft SQL Server 인스턴스의 결제 처리 데이터베이스를 AWS로 마이그레이션해야 하며, 보안 정책에 따라 데이터베이스 자격 증명은 90일마다 로테이션되어야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 가장 낮은 운영 부담의 관리형 데이터베이스 마이그레이션 대상 선택과, AWS 네이티브 관리형 기능을 사용한 필수 자격 증명 로테이션 구현을 평가합니다. 핵심 서비스는 Amazon RDS for SQL Server(관리형 관계형 데이터베이스)와 AWS Secrets Manager(내장 로테이션을 제공하는 관리형 시크릿 스토리지)입니다. 정답이 맞는 이유: 온프레미스 Microsoft SQL Server 데이터베이스를 Amazon RDS for SQL Server로 마이그레이션하면 운영 오버헤드가 최소화됩니다. 이는 AWS가 데이터베이스 프로비저닝, 패치(엔진 및 RDS의 OS), 백업, point-in-time recovery, 모니터링 통합, 고가용성 옵션(Multi-AZ)을 관리하기 때문입니다. 90일마다 데이터베이스 자격 증명을 로테이션해야 한다는 보안 요구 사항은 자격 증명을 AWS Secrets Manager에 저장하고 90일 스케줄로 자동 로테이션을 활성화하는 방식으로 가장 잘 충족됩니다. Secrets Manager는 네이티브 로테이션 워크플로( AWS Lambda 기반)를 제공하고 RDS와 깔끔하게 통합되어, 사용자 정의 코드와 지속적인 유지보수를 줄입니다. 주요 AWS 기능: - Amazon RDS for SQL Server: 자동 백업, maintenance windows, Multi-AZ, CloudWatch metrics, 그리고 간소화된 확장/운영을 제공하는 관리형 SQL Server. - AWS Secrets Manager: 암호화된 시크릿 스토리지(KMS), 자동 로테이션 스케줄링(예: 90일마다), 지원되는 엔진용 로테이션 Lambda 템플릿, 버저닝(AWSCURRENT/AWSPREVIOUS), 그리고 CloudTrail을 통한 감사 가능성. - 모범 사례: 애플리케이션은 하드코딩 대신 Secrets Manager에서 런타임에 자격 증명을 조회(또는 캐싱 라이브러리 사용)합니다. 일반적인 오해: Systems Manager Parameter Store와 사용자 정의 Lambda 로테이션을 제안하는 옵션은 더 저렴하거나 단순해 보일 수 있지만 운영 오버헤드를 증가시킵니다. 로테이션 로직을 구축하고, SQL 로그인 변경을 안전하게 처리하며, 애플리케이션 업데이트를 조율하고, 실패/롤백을 관리하며, Lambda와 스케줄을 유지보수해야 합니다. AWS SCT를 통해 DynamoDB 또는 Neptune을 제안하는 옵션은 대규모 재설계가 필요하고 결제 처리용 관계형 SQL Server 워크로드의 직접적인 대상이 아니므로 부적절합니다. 시험 팁: 상용 데이터베이스 엔진에서 “least operational overhead”가 보이면, 자체 관리형 EC2보다 관리형 서비스(RDS)를 우선합니다. “매 X일마다 자격 증명 로테이션”이 보이면, 사용자 정의 로테이션 메커니즘보다 AWS Secrets Manager 자동 로테이션을 우선합니다. 또한 문제에서 명시적으로 요구하지 않는 한 불필요한 현대화(예: DynamoDB/Neptune)는 피하십시오.

문제 2

한 피트니스 교육 플랫폼은 Application Load Balancer 뒤에서 Auto Scaling group과 함께 Amazon EC2로 웹 계층을 운영하고, 모든 정적 자산을 Amazon EFS (General Purpose)에 저장하고 있습니다. 그런데 1080p 트레이닝 비디오 라이브러리(평균 파일 크기 200 MB)를 출시한 이후 트래픽이 12배 급증하여 피크 시 약 20,000명의 동시 사용자가 발생했고, 사용자들은 이제 5–10초 버퍼링과 간헐적인 HTTP 504 오류를 겪고 있습니다. 그렇다면 컴퓨팅 계층을 replatforming하지 않으면서 이러한 문제를 해결하기 위한 가장 비용 효율적이고 확장 가능한 배포 변경은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 대용량 정적 미디어에 대해 Amazon S3와 Amazon CloudFront를 사용하여 확장 가능하고 비용 효율적인 콘텐츠 전송을 설계하는 능력, 그리고 높은 fan-out의 대용량 객체 배포에 Amazon EFS가 부적절한 백엔드가 될 수 있음을 식별하는 능력을 평가합니다. 정답이 맞는 이유: 1080p 비디오(평균 200 MB)를 약 20,000명의 동시 사용자에게 제공하면 매우 높은 총 처리량과 다수의 동시 읽기가 발생합니다. EFS General Purpose에서는 성능이 throughput mode(bursting 또는 provisioned)에 의해 좌우되며 병목이 생길 수 있고, 이로 인해 지연 시간이 증가하며 ALB에서 HTTP 504로 나타나는 업스트림 타임아웃이 발생할 수 있습니다. 비디오 라이브러리를 Amazon S3로 마이그레이션하고 CloudFront를 앞단에 두면 origin 부하를 오프로딩하고, 동시 시청자에 대해 사실상 제한 없이 확장되며, edge caching과 최적화된 전송을 통해 지연 시간을 크게 줄입니다. 이는 EC2/ALB 컴퓨팅 계층을 변경하지 않고도 버퍼링과 504를 해결합니다. 주요 AWS 기능: S3는 매우 높은 요청률과 처리량을 제공하는 고내구성 object storage입니다. CloudFront는 edge location에서 콘텐츠를 캐시하고, 대용량 파일 전송을 지원하며, HTTP range requests(비디오 탐색 및 adaptive player에 중요), origin shielding, 그리고 접근 제어가 필요할 경우 signed URLs/cookies를 지원합니다. 또한 S3를 origin으로 사용하면 lifecycle policy(예: 오래된 비디오를 S3 Intelligent-Tiering로 전환)를 단순화할 수 있고, 피크에 맞춰 EFS throughput을 확장하는 것보다 비용을 줄일 수 있습니다. 흔한 오해: EFS performance mode(Max I/O)를 높이면 고도로 병렬적인 워크로드에서 확장성에 도움이 될 수 있지만, 대규모 스트리밍에 필요한 처리량 경제성을 본질적으로 해결하지는 못합니다. 또한 지연 시간이 증가할 수 있으며, 여전히 충분한 throughput 구성이 필요합니다. 비디오를 EFS에 둔 채로 ALB 앞에 CloudFront를 두는 방식은 비디오가 사실상 캐시 불가능(접근 패턴, range requests, cache miss)하거나 origin이 계속 제약을 받는 경우 핵심 문제를 해결하지 못합니다. 시험 팁: 대용량 정적 자산(이미지, 다운로드, 비디오)에는 기본적으로 S3 + CloudFront를 선택하세요. EFS는 애플리케이션을 위한 공유 POSIX 파일 시스템에 적합하며, 대규모 미디어 배포를 위한 CDN origin으로는 적합하지 않습니다. 부하 상황에서 버퍼링 + 504가 보이면 origin 포화(saturation)를 의심하고, 무거운 정적 전송을 컴퓨팅/파일 계층에서 edge/object storage로 분리하세요.

문제 3

한 게임 분석 회사가 Amazon API Gateway 뒤에 매치메이킹 REST API를 배포하고 있으며, 이 API는 Java 17로 작성된 여러 AWS Lambda 함수를 호출합니다. 이 함수들은 핸들러 외부에서 무거운 정적 초기화를 수행하고(서드파티 라이브러리 로드, Spring context 빌드, 고유 ID/암호화 seed 생성), 현재 부하 테스트에서 cold start가 800–1200 ms가 걸립니다. 서비스 수준 목표(SLO)는 cold initialization의 95%가 200 ms 미만에 완료되어야 하며, 트래픽은 몇 초 내에 0에서 동시 요청 60까지 급증합니다. 또한 팀은 항상 켜져 있는(always-on) 용량 비용을 지불하지 않으면서 시작 지연을 최소화하는 가장 비용 효율적인 방법을 원합니다. 팀은 어떤 솔루션을 선택해야 합니까?

문제 분석

핵심 개념: 이 문제는 Java runtime에서 Lambda SnapStart와 Provisioned Concurrency를 사용한 AWS Lambda cold-start 완화, 그리고 실행 환경마다 고유해야 하는 초기화 코드(예: cryptographic seeds/unique IDs)를 어떻게 처리하는지를 평가합니다. 또한 Amazon API Gateway 뒤에서 bursty 트래픽을 처리할 때 versioning/aliases 요구사항과 비용 트레이드오프도 간접적으로 테스트합니다. 정답이 맞는 이유: (Java용) Lambda SnapStart는 init 단계 이후 초기화된 실행 환경의 snapshot을 생성하고 필요 시 on-demand로 복원하여 cold start를 줄입니다. 이는 라이브러리 로드나 Spring context 빌드 같은 무거운 정적 초기화에 이상적입니다. 하지만 런타임에서 고유해야 하는 항목(랜덤 seed, 고유 ID, 특정 crypto material, timestamp)은 snapshot에 “고정(frozen)”되면 안 됩니다. 그렇지 않으면 복원된 환경들 간에 값이 중복될 위험이 있습니다. 올바른 접근은 pre-snapshot hook을 사용해 runtime을 snapshotting에 적합하게 준비하고, 고유성에 민감한 초기화는 핸들러(또는 post-restore 로직)로 옮겨 환경/호출마다 적절히 생성되도록 하는 것입니다. SnapStart는 버전을 publish한 뒤 해당 버전에서 SnapStart를 활성화해야 하며($LATEST에서는 불가), 이는 항상 켜져 있는 용량 비용 없이 <200 ms cold init SLO를 충족하는 데 도움이 됩니다. 주요 AWS 기능: - Lambda SnapStart: 초기화된 Java 실행 환경을 snapshot하여 cold start를 크게 줄입니다. - Published versions: SnapStart는 version에서 활성화되며, 안정성을 위해 API Gateway는 alias/version을 호출해야 합니다. - Runtime hooks (pre-snapshot/post-restore): snapshotting 시 정확성을 보장합니다(예: RNG re-seeding, ephemeral state refresh). - Best practice: 무겁고 결정적인(deterministic) init은 핸들러 밖에 두고, 호출/환경별 고유성이 필요한 부분은 핸들러 또는 post-restore에 둡니다. 흔한 오해: Provisioned Concurrency도 cold start를 줄일 수 있지만, 사전 워밍된 용량에 대해 비용이 청구되므로 트래픽이 자주 0이고 갑작스런 burst가 있는 경우 비용 효율성이 떨어집니다. 또 다른 함정은 $LATEST에 SnapStart를 활성화하려는 것(지원되지 않음) 또는 고유 ID/seed를 snapshot에 포함시키는 것으로, 이는 중복 식별자 또는 약화된 randomness를 초래할 수 있습니다. 시험 팁: - 무거운 framework를 사용하는 Java cold start라면, on-demand 비용 동작을 원할 때는 SnapStart를 먼저 떠올리세요. - SnapStart는 $LATEST가 아니라 published version에서 동작한다는 점을 기억하세요. - 문제에 unique IDs/crypto seeds 또는 “고유해야 함”이 언급되면, 해당 상태가 snapshot에 포함되지 않도록 hook/handler 변경을 예상하세요. - 보장된 warm capacity가 필요하고 지속 비용을 정당화할 수 있으면 Provisioned Concurrency를, 항상 켜짐 비용 없이 cold start를 낮추려면 SnapStart를 선택하세요.

문제 4

한 디자인 스튜디오는 1,200명의 직원이 원격으로 근무할 수 있도록 지원하고 있으며, 최대 300명의 동시 사용자가 4개의 AWS account에 걸쳐 6개의 VPC에 배포된 내부 워크로드에 안전하게 액세스할 수 있도록 확장 가능하고 비용 효율적인 AWS Client VPN 솔루션이 필요합니다. 공유 네트워킹(hub) account에는 이미 5개의 spoke VPC와 피어링되어 있고 CIDR 블록이 서로 겹치지 않는 hub VPC가 호스팅되어 있으며, 현재 기업 네트워크는 단일 AWS Site-to-Site VPN을 통해 hub VPC에 연결됩니다. 또한 이 솔루션은 원격 사용자가 모든 VPC의 애플리케이션에 도달할 수 있도록 하면서 월별 비용을 최소화해야 합니다.

문제 분석

핵심 개념: 이 문제는 AWS Client VPN을 multi-account, multi-VPC 원격 액세스를 위해 중앙 집중화할 수 있는지와, 확장 가능한 라우팅을 위해 어떤 네트워크 구성이 필요한지를 테스트합니다. 핵심 포인트는 VPC peering이 non-transitive라는 점이므로, hub VPC와 연결된 Client VPN endpoint의 트래픽이 peering connection을 통해 spoke VPC들로 단순히 전달될 수 없다는 것입니다. 단일 Client VPN endpoint에서 여러 VPC와 account 전반의 workload에 원격 사용자 액세스를 제공하려면 AWS Transit Gateway와 같은 transit routing service가 필요합니다. 정답인 이유: shared networking account에 단일 Client VPN endpoint를 두고 AWS Transit Gateway를 함께 사용하는 설계가 올바른 설계입니다. Transit Gateway는 여러 VPC와 account 전반에서 중앙 집중식의 transitive routing을 지원하기 때문입니다. Client VPN endpoint는 hub VPC의 subnet들과 연결되고, 해당 VPC는 Transit Gateway에 attach되며, 다른 account의 각 spoke VPC도 Transit Gateway에 attach됩니다. 적절한 route propagation과 authorization rule을 구성하면 원격 사용자는 하나의 VPN endpoint를 통해 6개의 모든 VPC에 있는 애플리케이션에 액세스할 수 있습니다. Transit Gateway는 비용이 추가되지만, 제시된 선택지 중 단일의 확장 가능한 endpoint로 연결 요구 사항을 충족하는 유일한 옵션입니다. 주요 AWS 기능 / 구성: - shared networking account의 subnet들과 연결된 AWS Client VPN endpoint. - account 전반의 hub VPC와 각 spoke VPC에 대한 AWS Transit Gateway attachment. - Client VPN client CIDR와 모든 VPC CIDR가 상호 도달 가능하도록 구성된 Transit Gateway route table. - 필요한 대상 CIDR에 대한 Client VPN authorization rule. - Client VPN client CIDR의 트래픽을 허용하도록 업데이트된 security group과 network ACL. 흔한 오해: - VPC peering이 중앙 집중식 Client VPN endpoint에서 peered VPC들로의 액세스를 허용한다고 가정하는 것. 그렇지 않습니다. peering은 transitive routing을 지원하지 않기 때문입니다. - 기존 Site-to-Site VPN을 원격 사용자가 모든 AWS VPC에 도달하는 경로로 재사용할 수 있다고 생각하는 것. 이는 핵심 라우팅 제한을 해결하지 못하며, 이 사용 사례를 위해 Client VPN이 설계된 방식도 아닙니다. - 가장 저렴해 보이는 옵션이 자동으로 정답이라고 가정하는 것. 라우팅 요구 사항을 충족하지 못하면 유효한 솔루션이 아닙니다. 시험 팁: 여러 account에 걸친 많은 VPC에 대한 중앙 집중식 원격 액세스가 보이면, 기존 네트워크가 peering 기반인지 Transit Gateway 기반인지 즉시 확인하세요. 하나의 VPN endpoint를 사용하는 hub-and-spoke 원격 액세스에서는 Transit Gateway가 보통 필요한 서비스입니다. transitive routing을 지원하기 때문입니다. 시험에서는 VPN client와 다른 VPC 사이의 transit에 VPC peering을 의존하는 답안을 제거하세요.

문제 5

한 회사는 두 개의 OU에 걸쳐 12개의 AWS 계정에서 AWS Organizations를 사용하고 있습니다. Commerce 계정(ID 111122223333)은 us-east-1에 Orders라는 이름의 Amazon DynamoDB 테이블(약 60 GB, 50,000개 항목)에 기밀 데이터를 저장하는 주문 처리 애플리케이션을 실행합니다. Insights 계정(ID 444455556666)의 analytics 팀은 Query 및 GetItem 작업에 대해 읽기 전용 액세스가 필요하며, order_id, total_amount, order_date 속성에만 액세스할 수 있어야 합니다. 또한 email, card_token, address 속성은 볼 수도 없고 쓸 수도 없어야 합니다. 이 솔루션은 cross-account로 동작해야 하고, least privilege를 강제해야 하며, 데이터 복제를 요구해서는 안 됩니다. 솔루션 아키텍트는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 AWS Organizations에서 least privilege를 적용하는 cross-account 액세스 설계를 평가하며, 특히 IAM role assumption과 DynamoDB fine-grained access control을 사용합니다. 또한 DynamoDB 항목/속성에 대해 IAM 계층에서 무엇을 제한할 수 있고(또는 제한할 수 없는지) 이해하고 있는지도 테스트합니다. 정답이 맞는 이유: 옵션 B는 데이터 복제 없이 cross-account 액세스를 구현하는 올바른 아키텍처 패턴입니다. 리소스를 소유한 계정(Commerce)에서 소비 계정(Insights)이 assume할 수 있는 IAM role을 생성합니다. 이렇게 하면 데이터 소유자가 제어권을 유지할 수 있고, 특정 Orders 테이블에 대해 dynamodb:Query 및 dynamodb:GetItem으로 작업을 제한하여 least privilege를 지원합니다. role의 trust policy는 Insights 계정(그리고 이상적으로는 해당 계정의 특정 principal/role)에서만 sts:AssumeRole을 허용합니다. 주요 AWS 기능: 1) Cross-account IAM role assumption: Insights에 대한 trust policy가 있는 Commerce의 role은 표준적이며 감사 가능한 접근 방식입니다. 2) DynamoDB 작업/리소스에 대한 least privilege: 권한을 테이블 ARN(및 필요 시 indexes)과 필요한 read API로만 범위를 제한합니다. 3) 중요한 제한 사항: DynamoDB에 대한 IAM “fine-grained access control”은 leading keys(dynamodb:LeadingKeys)로 액세스를 제한하고 작업을 제한할 수 있지만, IAM은 Query/GetItem 결과에 대해 속성별 redaction을 안정적으로 강제하지 못합니다. 동일한 항목을 조회하면서 email/card_token/address를 보지 못하게 하려면 일반적으로 애플리케이션 계층 제어(예: 속성을 projection하는 proxy/API) 또는 별도의 테이블/뷰가 필요합니다. 그러나 제시된 옵션 중에서는 B만이 복제 없이 데이터 소유 계정에서 cross-account 액세스 제어를 올바르게 구현하며 AWS 모범 사례에 부합합니다. 흔한 오해: - SCP를 권한 부여로 혼동: SCP는 최대 권한만 설정하며 권한을 부여하지 않습니다. - DynamoDB가 S3처럼 테이블에 연결하는 resource policy를 지원한다고 가정: DynamoDB는 S3와 같은 방식으로 IAM 권한 부여를 위한 일반적인 resource-based policy를 테이블에 지원하지 않습니다. - permissions boundary로 cross-account에서 least privilege를 “강제”할 수 있다고 생각: boundary는 role이 할 수 있는 일을 제한하지만, 그 자체로 cross-account trust/authorization 문제를 해결하지는 못합니다. 시험 팁: 한 계정의 데이터 스토어에 대한 cross-account 액세스가 필요하면, 시험에서의 기본 정답은 보통 “데이터 소유 계정에 role을 만들고 다른 계정이 이를 assume하도록 허용한 다음, 해당 role에 least-privilege 권한을 적용한다”입니다. SCP는 제한(restrict)이지 부여(grant)가 아니며, 모든 서비스가 resource-based policy를 지원하는 것은 아닙니다. 속성 수준의 비밀 유지가 요구될 때는 주의해야 합니다. DynamoDB IAM 제어는 진정한 column-level masking보다는 item-level/key 기반 제한에 더 강합니다.

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

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

문제 6

한 디지털 미디어 대기업이 모든 기능이 활성화된 AWS Organizations를 사용하고 있으며 세 개의 OU(Studio, Gaming, Analytics)를 보유하고 있다. 각 OU에는 중앙 벤더 매니저가 사용하는 공유 서비스 계정이 있다. 경영진은 12개의 제품 계정에 걸친 약 120명의 개발자가 AWS Marketplace Private Marketplace를 통해 사전 승인된 third-party 소프트웨어만 구매할 수 있어야 하며, Private Marketplace 관리는 공유 서비스 계정의 벤더 매니저만이 Assume하는 vendor-admin-role이라는 이름의 역할로만 엄격히 제한되어야 한다고 요구한다. 또한 조직 전체에서 그 외 모든 IAM users, groups, roles, account administrators 및 root users는 Private Marketplace 관리 권한이 거부되어야 한다. 이러한 통제를 중앙에서 가장 효율적으로 강제하고, 동시에 스푸핑된 admin 역할 생성도 방지하는 아키텍처는 무엇인가?

문제 분석

핵심 개념: 이 문제는 중앙에서 예방적 guardrail을 적용하기 위해 AWS Organizations SCP를 사용하고, AWS Marketplace Private Marketplace 관리를 위해 범위가 엄격히 제한된 IAM role 설계를 결합하는 것에 관한 것입니다. 요구 사항에서는 account administrator와 root user를 포함한 다른 모든 principal에게 administrative permission이 거부되어야 한다고 명시하고 있으므로, account-local IAM control이 아니라 SCP를 사용해야 함을 시사합니다. 정답인 이유: 옵션 C가 가장 효율적인 설계인 이유는 privileged vendor-admin-role을 shared services account에만 유지하고, root-level SCP를 사용하여 해당 account의 신뢰된 role을 제외한 모든 대상에 대해 organization 전체에서 Private Marketplace administrative action을 거부하도록 강제하기 때문입니다. SCP는 모든 member account에 적용되며 사용 가능한 최대 permission을 제한하므로, product account의 매우 높은 권한을 가진 IAM principal조차 이를 우회할 수 없습니다. 두 번째 SCP는 신뢰된 shared services account 외부에서 vendor-admin-role이라는 이름의 IAM role 생성을 거부할 수 있으며, 이를 통해 role-name-based exception을 만족시키기 위해 동일한 role 이름을 악용하는 spoofing을 방지할 수 있습니다. 주요 AWS 기능: 1) SCP: SCP는 administrator를 포함하여 account 전반에 걸쳐 action을 중앙에서 거부해야 하는 요구 사항에 적합한 control입니다. 이는 organization의 member account에 대한 permission ceiling을 정의합니다. 2) Principal-based exception: deny SCP는 aws:PrincipalArn과 같은 condition을 사용하여 shared services account의 특정 vendor-admin-role ARN만 예외로 둘 수 있습니다. 이를 통해 least privilege를 유지하면서 vendor manager가 Private Marketplace를 관리할 수 있도록 합니다. 3) Anti-spoofing guardrail: 별도의 SCP는 신뢰되지 않은 account 또는 OU에서 요청된 role 이름이 vendor-admin-role인 경우 iam:CreateRole을 거부할 수 있습니다. 이를 통해 product account가 exception logic을 악용하기 위해 동일한 이름의 role을 생성하는 것을 방지합니다. 흔한 오해: 흔한 실수 중 하나는 IAM policy 또는 permission boundary가 organization 전체의 모든 사용자를 중앙에서 차단할 수 있다고 가정하는 것입니다. 이러한 방식은 root-level organizational guardrail을 재정의할 수 없으며, 개별 account 또는 연결된 principal 범위로 제한됩니다. 또 다른 오해는 admin role을 모든 account에 복제하는 것이 더 단순하다는 생각인데, 실제로는 blast radius를 증가시키고 중앙 governance를 약화시킵니다. 시험 팁: 문제에서 여러 account에 걸쳐 특정 신뢰된 role을 제외한 모든 대상의 permission을 거부하라고 하면, 먼저 SCP를 떠올리세요. 예외가 role identity를 기준으로 한다면, 다른 account에서 유사한 role이 생성되는 것을 어떻게 방지할지도 함께 고려해야 합니다. 요구 사항이 모든 OU와 account에 걸쳐 있다면 organization root의 중앙 control을 우선하세요.

문제 7

한 대학의 유전체학 부서는 NFSv3 공유를 내보내는 온프레미스 NAS를 운영하고 있으며, NFS 액세스를 유지하면서 매주 8 TB의 실험실 데이터를 Amazon S3로 백업하려고 합니다. 또한 5일 후 객체를 자동으로 아카이브하고, 재해 복구 시 최대 72시간의 검색 시간을 허용하는 솔루션을 원합니다. 어떤 접근 방식이 가장 비용 효율적입니까?

문제 분석

핵심 개념: 이 문제는 온프레미스 NFS 액세스를 유지하면서 Amazon S3를 내구성 있는 백업 스토리지로 사용하기 위한 올바른 AWS Storage Gateway 모드를 선택하고, 검색 시간 요구 사항과 비용을 기준으로 적절한 S3 storage class를 매칭하는지를 평가합니다. 정답이 맞는 이유: 부서는 백업을 위해 NFSv3 액세스를 유지해야 하므로, 온프레미스에서 NFS(및 SMB) file share를 제공하면서 S3에 객체로 저장하는 AWS Storage Gateway File Gateway가 올바른 gateway 유형입니다. 데이터는 5일 후 자동으로 아카이브되어야 하며, 재해 복구에서는 최대 72시간의 검색 시간을 허용합니다. S3 Glacier Deep Archive는 가장 저렴한 아카이브 스토리지 클래스이며, 검색 시간은 시간 단위가 될 수 있습니다(standard retrieval은 일반적으로 12시간 이내, bulk는 더 길 수 있음). 이는 데이터 복구를 위한 72시간 RTO 내에 들어옵니다. 따라서 File Gateway + 5일 후 Glacier Deep Archive로 전환하는 S3 Lifecycle이, 액세스 및 검색 제약을 충족하면서 가장 비용 효율적인 솔루션입니다. 주요 AWS 기능: - AWS Storage Gateway File Gateway: 온프레미스 시스템을 위한 NFSv3 호환 mount point; 파일을 S3 object로 저장; 자주 액세스되는 데이터에 대한 local cache 지원. - Amazon S3 Lifecycle rules: object age(예: 5일)에 따라 아카이브 클래스 등으로의 전환을 자동화. - S3 Glacier Deep Archive: 장기 보관을 위한 최저 스토리지 비용; 검색은 비동기이며 시작(요청)해야 함(72시간 허용 조건에서 수용 가능). 일반적인 오해: 흔한 함정은 S3 Standard-IA가 “Standard보다 저렴하다”는 이유로 선택하는 것이지만, 이는 아카이브 티어가 아니며 장기 보관되는 주간 8 TB 백업에는 Deep Archive보다 일반적으로 훨씬 비쌉니다. 또 다른 함정은 Volume Gateway 또는 Tape Gateway를 고르는 것입니다. 이들은 block 또는 VTL 워크플로에는 유효할 수 있지만, 요구 사항인 NFS file-share 액세스를 유지하지 못합니다. 시험 팁: “preserve NFS/SMB access”를 보면 Storage Gateway File Gateway를 떠올리십시오. “X일 후 아카이브”와 “시간~일 단위의 검색 지연 허용”을 보면 Lifecycle 전환과 함께 Glacier/Glacier Deep Archive를 떠올리십시오. 검색 시간 허용 범위를 아카이브 티어와 매칭하십시오: Deep Archive는 비즈니스가 몇 시간을 기다릴 수 있고 최저 비용을 원할 때 최적입니다.

문제 8

(2개 선택)

한 소매 기업이 공유 결제 모델 하에서 9개의 AWS account를 운영하고 있다. 컴플라이언스 검토 결과 120개의 Amazon RDS DB instance(MySQL 및 PostgreSQL) 중 37개가 암호화되지 않은 스토리지를 사용하고 있는 것으로 확인되었다. Solutions Architect는 각 instance당 다운타임을 10분 이내로 유지하면서 이러한 DB instance를 customer managed AWS KMS key를 사용하도록 마이그레이션해야 하며, 또한 어떤 account에서든 새로 생성되는 암호화되지 않은 RDS instance가 15분 이내에 자동으로 탐지되도록 보장해야 하고, 중앙집중식 멀티-account 거버넌스가 보안 및 컴플라이언스를 강조하도록 해야 한다. 이 요구 사항을 충족하기 위해 Solutions Architect가 수행해야 하는 단계 조합은 무엇인가? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 두 가지 작업을 결합합니다. 즉, 기존의 암호화되지 않은 Amazon RDS 인스턴스를 수정하고, 여러 AWS 계정 전반에서 향후 비준수 RDS 생성도 탐지하는 것입니다. 기존 RDS 인스턴스의 경우, 암호화되지 않은 DB 인스턴스에서 스토리지 암호화를 제자리에서 활성화할 수 없으므로, 교체 기반 마이그레이션이 필요합니다. 새 인스턴스의 경우, 요구 사항은 15분 이내 자동 탐지를 명시하고 있으므로, 계정 전반의 RDS 생성 활동에 대한 event-driven 모니터링으로 가장 잘 충족됩니다. 정답인 이유: 옵션 C는 암호화되지 않은 RDS DB 인스턴스를 customer managed AWS KMS key를 사용한 암호화된 스토리지로 마이그레이션하는 표준적이고 지원되는 방법입니다. 소스의 snapshot을 생성하고, 암호화를 활성화하여 snapshot을 복사한 다음, 새 DB 인스턴스를 복원하고 마지막에 cutover를 수행하면, 대부분의 작업이 원래 데이터베이스가 계속 사용 가능한 상태에서 진행되므로 다운타임은 최종 switchover로 제한됩니다. 옵션 E는 CloudTrail management events와 EventBridge rules를 사용하여 새로 생성된 암호화되지 않은 RDS 인스턴스를 near-real-time으로 탐지하며, 15분 이내에 notifications 또는 remediation workflows를 트리거할 수 있습니다. 주요 기능: - Amazon RDS 암호화는 DB 인스턴스 생성 후 변경할 수 없습니다. remediation에는 snapshot/copy/restore 또는 이에 준하는 교체가 필요합니다. - Snapshot copy는 customer managed KMS key로 암호화를 활성화하는 것을 지원합니다. - AWS CloudTrail은 계정 전반에서 CreateDBInstance 및 관련 API 호출을 기록합니다. - Amazon EventBridge는 이러한 이벤트를 매칭하고 automation을 빠르게 호출하여 중앙 집중식 compliance 탐지 및 대응을 수행할 수 있습니다. 흔한 오해: - 기존의 암호화되지 않은 RDS 인스턴스를 수정하여 암호화를 켤 수는 없습니다. - Control Tower guardrails는 거버넌스를 개선하지만, 요구 사항에 설명된 특정 event-driven 탐지 동작을 그 자체만으로 보장하지는 않습니다. - EventBridge는 이미 생성된 암호화되지 않은 DB 인스턴스를 제자리에서 소급하여 암호화할 수 없습니다. 탐지하고 후속 작업을 트리거할 수만 있습니다. 시험 팁: 문제에서 기존 RDS 암호화 격차의 remediation과 향후 위반 사항의 빠른 탐지를 모두 묻는다면, 하나는 RDS 암호화의 immutable한 특성을 처리하는 옵션을, 다른 하나는 near-real-time 이벤트 탐지를 제공하는 옵션을 찾으세요. 요구 사항이 구체적인 탐지 메커니즘과 시간 목표를 명시적으로 요구할 때는 governance frameworks를 과대평가하지 않도록 주의하세요.

문제 9

한 물류 스타트업은 공개 Amazon API Gateway HTTP API가 서로 다른 라우트에 대해 여러 AWS Lambda 함수를 호출하는 서버리스 주문 추적 백엔드를 운영하고 있으며, 회사의 FinOps 팀은 각 API Lambda 함수에 대해 권장 구성 메모리, 해당 권장 사항을 기반으로 한 예상 월간 비용, 그리고 현재 설정 대비 가격 차이를 나열하는 자동화된 격주(매 14일마다 00:30 UTC) CSV 보고서가 필요합니다. 각 보고서는 이전 14일 기간을 포함해야 하며 Amazon S3 버킷(예: s3://finops-reports/serverless/biweekly/)에 저장되어야 합니다. 또한 회사는 개발 시간이 가장 적게 드는 솔루션을 원합니다. 어떤 접근 방식을 사용해야 합니까?

문제 10

다국적 fintech 기업이 Q4 말까지 결제 및 analytics 워크로드의 80%를 AWS로 replatforming하고 있지만, 12개 관할권의 모든 cardholder-processing 서비스는 data residency를 충족하고 on-prem HSMs에 대한 왕복 latency를 5 ms 미만으로 유지하기 위해 반드시 해당 국가 내 또는 기업의 Frankfurt colocation에 남아 있어야 합니다. 또한 140개의 농촌 retail kiosks는 5–10 Mbps backhaul만 가능하고 매일 30–60분의 outage가 발생하며, 기업은 개발자가 동일한 AWS APIs, IAM, CI/CD tools를 사용해 한 번 build하고 on-premises, AWS Region, 또는 hybrid topology 전반에 걸쳐 변경 없이 배포할 것을 요구합니다. 이러한 제약 조건에서 일관된 hybrid 경험을 제공하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 세 가지 제약 조건을 동시에 가장 잘 충족하는 AWS hybrid 및 edge 서비스를 묻습니다: 국가 내/온프레미스 데이터 상주 요구사항과 로컬 HSM에 대한 매우 낮은 지연 시간, 키오스크에서의 간헐적이고 낮은 대역폭의 edge 운영, 그리고 일관된 AWS 개발 및 운영 모델입니다. 핵심 차이점은 AWS Outposts가 동일한 APIs, IAM, 및 tooling을 갖춘 진정한 온프레미스 AWS 경험을 제공하는 반면, Snowball Edge는 원격 또는 연결이 끊긴 환경을 위해 설계된 edge compute 디바이스라는 점입니다. 정답인 이유: 옵션 C가 전체적으로 가장 적합한 솔루션입니다. AWS Outposts racks는 Frankfurt colocation 또는 기타 국가 내 시설에 설치할 수 있으므로, 규제 대상 cardholder-processing 워크로드를 로컬에 유지하면서 로컬 네트워크 경로를 통해 온프레미스 HSM과 매우 낮은 지연 시간으로 통신할 수 있습니다. Outposts는 AWS infrastructure 및 services를 온프레미스로 확장하며, 동일한 AWS APIs, IAM, CloudFormation, 및 operational tooling을 사용하므로 온프레미스와 AWS Regions 전반에서 한 번 빌드하고 일관된 모델로 배포해야 한다는 요구사항을 직접적으로 지원합니다. 농촌 키오스크의 경우, Snowball Edge Compute Optimized가 제시된 서비스 중 가장 적합합니다. WAN 연결이 불안정하거나 일시적으로 사용할 수 없을 때에도 EC2 instances 및 container-based workloads와 같은 로컬 compute를 실행할 수 있기 때문입니다. 주요 기능: - AWS Outposts racks는 native AWS APIs, IAM integration, 및 익숙한 deployment tooling을 갖춘 AWS-managed infrastructure를 온프레미스에 제공합니다. - Outposts는 온프레미스 시스템에 대한 low-latency 액세스와 특정 물리적 위치에 반드시 남아 있어야 하는 워크로드를 위해 설계되었습니다. - Snowball Edge Compute Optimized는 연결이 제한적이거나 간헐적인 edge 사이트를 위해 ruggedized 로컬 compute를 제공합니다. - Snowball Edge는 키오스크에서 로컬 처리를 지원할 수 있지만, AWS로의 데이터 이동이나 재조정은 투명한 내장 동기화로 가정해서는 안 되며 application 또는 transfer workflow가 설계해야 합니다. 흔한 오해: 흔한 실수는 지연 시간을 줄여준다는 이유만으로 Direct Connect, Local Zones, 또는 Wavelength를 선택하는 것입니다. 이러한 서비스는 Outposts처럼 워크로드를 고객 시설 내부에 배치하지 않으며, 농촌 키오스크에서의 연결 끊김 edge 운영도 해결하지 못합니다. 또 다른 오해는 Snowball Edge를 일관된 AWS APIs 및 control-plane 동작 측면에서 Outposts와 동등하다고 보는 것입니다. Snowball Edge는 edge compute를 지원하지만, 완전한 온프레미스 AWS 일관성을 위한 주된 서비스는 아닙니다. 시험 팁: 문제에서 온프레미스에서 동일한 AWS APIs, IAM, 및 deployment tooling을 강조하면, 보통 Outposts가 가장 강력한 신호입니다. 원격 사이트의 열악한 연결성이나 일시적 연결 끊김을 강조하면, Outposts가 비현실적인 경우 Snowball Edge가 흔히 edge-device 정답입니다. 제약 조건이 혼합된 문제에서는, 한 구성 요소의 운영 모델이 주 플랫폼과 완전히 동일하지 않더라도 각 요구사항을 가장 적절한 AWS 서비스에 가장 잘 매핑하는 선택지를 고르세요.

Practice Test #3

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(9)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #4

Practice Test #5

지금 학습 시작하기