CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
AWS Certified Developer - Associate (DVA-C02)
AWS Certified Developer - Associate (DVA-C02)

Practice Test #5

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

한 핀테크 스타트업이 두 개의 AWS 계정(prod 및 audit)에서 Amazon ECS with AWS Fargate로 규칙 엔진을 실행하며 분당 최대 3,000개의 이벤트를 처리한다. 이벤트가 검증에 실패하면 컨테이너는 런타임에 bearer access token을 조회해야 하는 서드파티 incident REST API를 호출해야 한다. 또한 token은 저장 시(at rest)와 전송 시(in transit) 모두 암호화되어야 하며, 관리 오버헤드를 최소화하면서 두 계정의 워크로드에서 모두 접근 가능해야 한다. 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

Systems Manager Parameter Store SecureString은 민감한 값을 저장할 수 있으며, 일부 시나리오에서는 advanced parameter에 대한 resource policy를 사용하여 계정 간 공유할 수 있습니다. 그러나 이 보기에서는 AWS managed KMS key를 지정하고 있으며, 암호화된 값을 cross-account로 사용하려면 AWS managed key로는 적절하게 제어할 수 없는 KMS permissions가 필요합니다. 두 계정의 workloads가 동일한 token을 검색하고 복호화해야 하므로, customer managed KMS key가 올바른 패턴입니다. 이를 제외하더라도, Secrets Manager가 더 낮은 운영 오버헤드로 런타임 secret retrieval에 더 특화된 서비스입니다.

DynamoDB와 KMS 조합은 암호화된 데이터를 안전하게 저장할 수 있지만, 관리형 secrets 솔루션이 아니다. 조회, caching, rotation 전략과 DynamoDB 읽기 및 KMS decrypt에 대한 세심한 IAM 범위 지정을 직접 구현해야 한다. 이는 운영 및 개발 오버헤드를 증가시키고(예: plaintext 로깅, 부적절한 key policy) 실수 가능성을 높인다. 암호화 요구 사항은 충족하지만 “least management overhead”는 충족하지 못한다.

Secrets Manager는 token과 credential을 저장하기 위해 목적에 맞게 설계되었고, KMS(customer managed key 포함)로 secret을 at rest 암호화하며, 조회 시 TLS를 사용한다. resource-based policy로 cross-account access를 지원하므로 하나의 secret을 prod 및 audit 계정의 워크로드와 공유할 수 있다. ECS task role에는 최소 권한의 secretsmanager:GetSecretValue(필요 시 KMS decrypt)를 부여할 수 있어 운영 오버헤드를 최소화한다.

S3에서 SSE-KMS를 사용하면 객체를 at rest 암호화할 수 있고 TLS가 in transit을 보호하며, bucket policy로 cross-account access를 부여할 수 있다. 그러나 S3는 secret store가 아니므로 객체 포맷, 조회 로직, caching, 그리고 잠재적 노출 위험(예: 실수로 더 넓은 bucket 권한 부여)을 관리해야 한다. 또한 AWS managed KMS key를 사용하면 제어가 줄어든다. Secrets Manager보다 오버헤드가 크고 모범 사례에도 덜 부합한다.

문제 분석

핵심 개념: 민감한 런타임 자격 증명을 저장하도록 특별히 설계되었고, 저장 시와 전송 시 암호화를 지원하며, 최소한의 운영 노력으로 AWS 계정 간 공유할 수 있는 AWS 서비스를 선택해야 합니다. 가장 적합한 것은 customer managed KMS key와 cross-account access를 위한 resource-based policy를 사용하는 AWS Secrets Manager입니다. 정답인 이유: Secrets Manager는 bearer token 및 API credentials와 같은 secret를 위해 특별히 설계되었습니다. secret는 저장 시 KMS로 암호화되고, 전송 시에는 TLS를 통해 반환되며, resource-based policy를 통해 cross-account access를 지원합니다. customer managed KMS key를 사용하는 것이 중요한 이유는 cross-account decryption에 명시적인 key policy 제어가 필요하기 때문이며, AWS managed key는 동일한 방식으로 이를 제공하지 않기 때문입니다. 주요 기능: Secrets Manager는 기본 secret 저장, 세분화된 IAM permissions, 선택적 rotation 지원, 그리고 ECS workloads를 위한 직접적인 integration pattern을 제공합니다. secret에 대한 resource policy를 사용하면 prod 및 audit 계정의 task role이 동일한 secret를 검색하도록 허용할 수 있습니다. customer managed KMS key는 이러한 cross-account principal에 대해 명시적인 decrypt permissions를 허용합니다. 일반적인 오해: Parameter Store는 SecureString 값을 저장할 수 있고, 일부 경우에는 parameter sharing도 지원할 수 있습니다. 하지만 이 보기에서는 AWS managed KMS key를 지정하고 있으므로 여기서는 최선의 답이 아닙니다. 이는 필요한 cross-account decrypt model에 적합하지 않습니다. DynamoDB와 S3도 암호화된 데이터를 저장할 수 있지만, 범용 스토리지 서비스이므로 managed secrets service보다 더 많은 custom code와 운영 처리가 필요합니다. 시험 팁: 요구 사항에 token, credentials, 런타임 검색, 암호화, 그리고 최소 관리 오버헤드가 언급되면, 문제가 더 단순한 configuration store를 명확히 가리키지 않는 한 Secrets Manager를 우선 고려하세요. cross-account encrypted secret access의 경우, 항상 resource policy와 KMS key type 및 policy model을 모두 확인하세요.

2
문제 2

실시간 음식 배달 플랫폼은 Amazon DynamoDB 테이블에 배달원 GPS ping을 저장하며, 하루에 수천만 개의 item을 ingest합니다(각 ping은 단일 item). 애플리케이션은 가장 최근 24시간의 ping만 필요하므로 24시간보다 오래된 모든 item은 제거되어야 합니다. 24시간보다 오래된 item을 삭제하는 가장 비용 효율적인 방법은 무엇입니까?

오답입니다. 이 규모에서 스케줄된 table scan은 매우 비싸고 비효율적입니다. Scan은 테이블의 큰 부분을 반복적으로 읽어 상당한 read capacity(또는 on-demand read 요금)를 소비하며, 지속적인 EC2 비용과 운영이 필요합니다. BatchWriteItem은 API 호출 수를 줄이는 데 도움은 되지만, scan과 명시적 delete라는 근본 비용을 제거하지 못합니다. 이는 가장 비용 효율적인 접근이 아닙니다.

오답입니다. 스케줄된 ECS/Fargate task 실행은 compute 비용과 운영 오버헤드를 추가하며, 만료 item을 찾기 위해 여전히 테이블을 scan해야 합니다. 자주 실행하더라도 상당한 DynamoDB read 트래픽과 명시적 delete를 유발합니다. Fargate는 편리하지만, DynamoDB TTL이 네이티브로 만료를 처리할 수 있을 때 단순한 지속 정리 작업에 대해 비용 최적이 아닙니다.

오답입니다. GSI를 query하는 것은 기본 테이블 scan보다 낫지만, index에 대한 지속적인 read 비용과 Lambda invocation 비용, 그리고 명시적 delete write operation이 여전히 발생합니다. 또한 DynamoDB에는 네이티브 “Date” attribute 타입이 없으며, 날짜는 String 또는 Number로 저장합니다. 이 설계는 필요 이상으로 복잡하고 TTL만큼 비용 효율적이지 않습니다.

정답입니다. DynamoDB TTL은 item을 자동으로 만료시키기 위해 목적에 맞게 설계되었습니다. Unix epoch timestamp(초)를 Number attribute에 저장하고 TTL이 이를 사용하도록 구성하면, scan, 스케줄된 compute, 명시적 delete operation 없이 DynamoDB가 비동기적으로 item을 삭제할 수 있습니다. 이는 비용과 운영 부담을 최소화하며, 보존 기간을 초과한 item을 제거하는 표준 best practice입니다.

문제 분석

핵심 개념: 이 문제는 Amazon DynamoDB의 데이터 라이프사이클 관리와 비용 최적화, 특히 item 자동 만료를 위한 Time to Live (TTL) feature를 평가합니다. 정답이 맞는 이유: 하루에 수천만 건의 GPS ping이 발생하고 최근 24시간만 유지해야 하는 엄격한 요구사항이 있으므로, 가장 비용 효율적인 접근은 DynamoDB가 TTL을 사용해 item을 자동으로 만료시키도록 하는 것입니다. item별로 만료 timestamp(생성 후 24시간)를 저장하고 TTL이 해당 attribute를 참조하도록 구성하면, DynamoDB가 백그라운드에서 비동기적으로 만료 item을 표시하고 삭제합니다. 이 방식은 scan/query로 인한 지속적인 read capacity 소모를 피하고, compute 비용(EC2/Fargate/Lambda)을 피하며, 운영 복잡성도 줄입니다. 주요 AWS 기능: DynamoDB TTL은 초 단위 Unix epoch timestamp를 담은 Number 타입 attribute를 요구합니다. 현재 시간이 해당 값보다 커지면 item은 삭제 대상이 됩니다. 삭제는 best-effort이며 즉시 수행되지 않습니다. DynamoDB는 일반적으로 몇 시간 내에 만료 item을 제거하는데, 이는 보통 “최근 24시간만 필요” 같은 보존 요구사항에 충분합니다. TTL 삭제는 애플리케이션 주도 삭제와 동일한 방식으로 provisioned write capacity를 소비하지 않으며, 필요하다면 DynamoDB Streams를 사용해 삭제에 반응하여 다운스트림 정리를 수행할 수도 있습니다. 흔한 오해: 흔한 함정은 스케줄된 scan/query로 오래된 item을 능동적으로 삭제해야 한다고 생각하는 것입니다. 이 접근은 규모가 커질수록 비용이 많이 듭니다. scan은 테이블 전체(또는 큰 부분)를 반복적으로 읽어야 하며, GSI 기반 접근도 read와 명시적 delete가 필요합니다. 또 다른 오해는 “Date” 타입을 사용하는 것입니다. DynamoDB에는 String, Number, Binary, Boolean, Null, List, Map, Set 타입이 있으며, TTL은 특히 Number epoch timestamp를 기대합니다. 시험 팁: DynamoDB에서 “X보다 오래된 item 삭제”를 보면 기본적으로 비용 효율적인 만료 방법으로 TTL을 즉시 고려하십시오. 기억할 점: TTL은 epoch seconds(Number)를 사용하고, 비동기(실시간 아님)이며, GPS ping, session, log 같은 ephemeral/time-series 데이터에 이상적입니다. 즉시 삭제가 엄격히 필요하다면 애플리케이션 삭제를 고려하겠지만, 이는 드물게 “MOST 비용 효율적”입니다.

3
문제 3

한 핀테크 스타트업이 레거시 결제 원장을 1개의 writer와 2개의 reader를 갖춘 Amazon Aurora PostgreSQL-Compatible cluster로 이전하고 있으며, 애플리케이션 코드 추가나 커스텀 rotation 로직 없이 데이터베이스 자격 증명을 안전하게 저장하고 30일마다 자동으로 rotation해야 합니다. 어떤 솔루션이 이러한 요구 사항을 가장 잘 충족합니까?

오답입니다. AWS Systems Manager Parameter Store는 SecureString을 사용해 암호화된 값을 안전하게 저장할 수 있지만, managed database credential rotation을 위한 주요 AWS service는 아닙니다. 'turn on rotation'이라는 표현은 정기적인 secret rotation과 database integration을 위해 특별히 설계된 AWS Secrets Manager와 더 잘 맞습니다. 30일마다 자동으로 rotation되어야 하는 Aurora PostgreSQL credentials의 경우, Secrets Manager가 더 적절하고 기대되는 선택입니다.

정답입니다. AWS Secrets Manager는 database usernames 및 passwords와 같은 민감한 credentials를 저장하고 정의된 일정에 따라 자동으로 rotation하도록 특별히 설계되었습니다. Amazon Aurora PostgreSQL-Compatible clusters와 통합되므로, 30일마다 database credentials를 rotation하는 데 가장 적합합니다. 이 접근 방식은 credentials를 code에 내장하는 것을 피하게 해주며, 애플리케이션이 자체 credential rotation 로직을 구현할 필요도 없습니다.

오답입니다. 이 선택지는 workload가 Amazon DynamoDB가 아니라 Amazon Aurora PostgreSQL-Compatible cluster로 마이그레이션되고 있으므로 핵심 database 요구 사항을 충족하지 못합니다. 또한 잘못된 database 선택에 더해, managed automatic database credential rotation에 가장 적합한 service가 아닌 Parameter Store를 함께 사용하고 있습니다. 따라서 database platform과 secret-management 요구 사항 모두에서 틀렸습니다.

오답입니다. AWS Secrets Manager는 credentials를 안전하게 저장하고 rotation하는 올바른 service이지만, DynamoDB는 이 시나리오에서 지정된 database가 아닙니다. 문제는 writer 1개와 reader 2개를 갖는 Aurora PostgreSQL-Compatible cluster를 명시적으로 요구하며, 이는 DynamoDB가 아니라 Aurora architecture를 설명합니다. database service가 잘못되었기 때문에 이 선택지는 최선의 정답이 될 수 없습니다.

문제 분석

핵심 개념: 이 문제는 Amazon Aurora PostgreSQL-Compatible cluster에 대해 최소한의 운영 노력으로, 그리고 애플리케이션 측의 credential rotation 로직 없이, database credentials를 안전하게 저장하고 자동으로 정기 rotation을 지원하는 AWS service가 무엇인지 묻습니다. 정답 조합은 Aurora PostgreSQL과 AWS Secrets Manager입니다. 정답인 이유: AWS Secrets Manager는 database usernames 및 passwords와 같은 secrets를 저장하고 30일마다와 같은 일정에 따라 자동으로 rotation하도록 설계된 AWS service입니다. Amazon RDS 및 Aurora와 직접 통합되며, Aurora PostgreSQL-Compatible clusters를 포함해 database credentials에 대한 managed rotation workflows를 지원합니다. 이는 credentials를 안전하게 저장하고, 애플리케이션에 custom rotation 처리를 추가하지 않고도 자동으로 rotation해야 한다는 요구 사항을 충족합니다. 주요 AWS 기능: 1) 안전한 secret 저장: Secrets Manager는 AWS KMS로 secrets를 암호화하고 IAM policies를 통해 access를 제어합니다. 2) 기본 제공 RDS/Aurora 통합: Aurora PostgreSQL에 대한 credential rotation을 지원하며 rotation workflow의 일부로 secret value를 업데이트합니다. 3) 정기 rotation: 30일마다와 같은 자동 rotation interval을 구성할 수 있습니다. 4) 애플리케이션 영향 감소: 애플리케이션은 credentials를 내장하는 대신 Secrets Manager에서 현재 secret를 읽으므로, 애플리케이션 측 rotation 로직이 필요하지 않습니다. 흔한 오해: Systems Manager Parameter Store는 암호화된 값을 저장할 수 있지만, managed database credential rotation을 위한 표준 AWS service는 아닙니다. 또 다른 흔한 실수는 단지 database service라는 이유로 DynamoDB를 선택하는 것이지만, 요구 사항에는 Aurora PostgreSQL-Compatible cluster가 명시되어 있습니다. 시험 팁: 문제에서 database credentials, 안전한 저장, 그리고 일정에 따른 자동 rotation이 언급되면 AWS Secrets Manager가 보통 가장 적절한 정답입니다. database가 명시적으로 Aurora 또는 RDS라면, 해당 database 선택을 유지하면서 Parameter Store가 아니라 Secrets Manager와 짝지은 선택지를 찾으세요.

4
문제 4

개발자가 운전자가 도시 네트워크의 12개 스테이션(스테이션당 커넥터 8개)에서 전기차(EV) 충전 커넥터를 예약할 수 있는 serverless 애플리케이션을 구축하고 있습니다. 운전자는 Amazon API Gateway API로 예약 요청을 보내며, 이 API는 300ms 이내에 요청을 확인(acknowledge)하고 예약 ID를 생성하는 AWS Lambda 함수로 백엔드가 구성되어 있습니다. 애플리케이션에는 두 개의 추가 Lambda 함수(할당 관리용 1개, 결제 처리용 1개)가 포함되어 있으며, 이 두 함수는 병렬로 실행되고 예약 레코드를 Amazon DynamoDB 테이블에 기록합니다. 동일한 커넥터와 30분 timeslot에 대한 동시 요청이 서로 10ms 이내에 도착할 수 있습니다. 애플리케이션은 다음에 따라 커넥터를 할당해야 합니다. 커넥터 timeslot이 실수로 이중 예약되는 경우, 애플리케이션이 수신한 첫 번째 예약 요청이 해당 슬롯을 가져야 하며 그 예약에 대해서만 결제가 처리되어야 합니다. 그러나 첫 번째 예약이 결제 단계에서 거절되는 경우(결제 응답은 최대 30초까지 걸릴 수 있음), 두 번째 예약이 해당 슬롯을 가져야 하며 그 결제가 처리되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

정답입니다. SNS FIFO는 MessageGroupId별 순서를 보존하고 중복 제거를 제공하면서 여러 SQS FIFO queue로 fan-out할 수 있습니다. connectorId+timeslot 같은 group 키를 사용하면 동일 슬롯에 대한 경쟁 예약이 직렬화되어 첫 번째 요청이 먼저 처리되도록 보장합니다. 첫 번째 결제가 실패하면 동일 group에 큐잉된 다음 예약이 진행될 수 있어 “결제가 거절되지 않는 한 첫 번째가 승리” 요구 사항을 충족합니다.

오답입니다. 초기 Lambda에서 할당을 직접 호출한 다음 결제를 호출하면 결합도가 높아지고 병렬성이 감소합니다(문제에서는 할당과 결제가 병렬로 실행된다고 명시). 또한 동시 요청, 재시도, 부분 장애 전반에 걸친 내구성 있는 순서 보장을 제공하지 못합니다. 거의 동시에 도착한 두 요청이 여전히 서로 끼어들 수 있으며, FIFO 의미론 또는 분산 락/conditional write 없이 “먼저 수신된 요청이 승리”를 신뢰성 있게 강제할 수 없습니다.

오답입니다. SNS standard topic은 순서 보장 없이 at-least-once 전달을 제공하며 중복이 발생할 수 있습니다. 밀리초 단위로 동시 요청이 도착하면 두 번째 요청이 첫 번째보다 먼저 전달/처리되어 “애플리케이션이 수신한 첫 요청이 슬롯을 가져야 함” 규칙을 위반할 수 있습니다. 또한 중복 전달로 인해, 이 옵션만으로는 추가적인 idempotency 및 조정 로직 없이 여러 번 결제가 시도될 수 있습니다.

오답입니다. 단일 SQS standard queue는 순서를 보장하지 않으며 메시지를 한 번 이상 전달할 수 있습니다. FIFO라고 하더라도, 두 Lambda consumer가 하나의 queue를 공유하면 각 메시지는 한 consumer에 의해서만 처리되므로 동일 예약에 대해 할당과 결제를 병렬로 안정적으로 실행할 수 없습니다. Fan-out에는 별도 queue 또는 pub/sub 메커니즘이 필요합니다.

문제 분석

핵심 개념: 이 문제는 serverless 아키텍처에서 이벤트 순서 보장, 동시성 제어, 그리고 exactly-once/first-wins 처리 패턴을 테스트합니다. 핵심 AWS 개념은 FIFO 메시징(순서 보장 + 중복 제거), 병렬 소비자를 위한 fan-out, 그리고 올바른 예약만 과금되도록 할당과 결제 작업을 조정하는 것입니다. 정답인 이유: 옵션 A는 SNS FIFO topic을 사용해 예약 이벤트를 두 개의 SQS FIFO queue(다운스트림 워크플로당 1개)로 fan-out합니다. FIFO는 message group 내에서 엄격한 순서 보장과 중복 제거를 제공하며, 이는 동일한 커넥터/timeslot에 대한 두 요청이 밀리초 단위로 도착할 수 있을 때 매우 중요합니다. (stationId, connectorId, timeslot)에서 파생된 MessageGroupId를 사용하면 동일 슬롯에 대해 경쟁하는 모든 예약이 순서대로 처리됩니다. 첫 번째 요청은 할당 및 결제 파이프라인 모두에서 먼저 처리됩니다. 첫 번째 예약의 결제가 실패하면(최대 30초), 동일 group의 다음 메시지가 처리될 수 있어 두 번째 예약이 슬롯을 획득하고 과금될 수 있습니다. 주요 AWS 기능: - SNS FIFO topic: message group별 순서를 보존하고 content-based deduplication을 지원합니다. - SQS FIFO queues: MessageGroupId별로(중복 제거 window 포함) 순서 보장 및 exactly-once 처리 의미론을 제공합니다. - Fan-out 패턴: 별도 queue가 할당과 결제를 분리(decouple)하여, 슬롯별 순서를 유지하면서 병렬 확장을 가능하게 합니다. - Best practice: connector+timeslot처럼 경합 리소스에 대해 결정적(deterministic) MessageGroupId를 사용하여, 직렬화가 필요한 부분만 직렬화하고 다른 커넥터/timeslot은 동시에 처리되도록 합니다. 흔한 오해: 많은 사람이 standard SNS topic만으로 fan-out이 충분하다고 생각하지만, standard SNS/SQS는 순서를 보장하지 않으며 중복 전달이 가능해 레이스 컨디션에서 “첫 요청이 승리” 규칙이 깨집니다. 또 다른 접근으로 Lambda 호출을 직접 순차화하려 하지만, 이는 병렬성을 줄이고 재시도 및 장애 전반에 걸친 내구성 있는 순서 보장/락킹을 제공하지 못합니다. 시험 팁: “요청이 10ms 이내 도착”, “먼저 수신된 요청이 승리”, “첫 번째가 실패할 때만 두 번째가 진행”을 보면, 경합 리소스에 대해 FIFO + message group을 떠올리십시오. 순서를 유지하면서 병렬 다운스트림 처리가 필요하면 SNS FIFO -> 여러 SQS FIFO queue를 선호합니다. 또한 DynamoDB conditional write/transaction으로 유일성을 강제할 수도 있지만, 이 문제의 선택지는 메시징/오케스트레이션에 초점이 있으므로 엔드투엔드로 순서 및 중복 제거 보장을 제공하는 옵션을 선택하십시오.

5
문제 5

한 모바일 게임 회사가 리더보드 서비스를 배포하고 있으며 AWS CloudFormation 템플릿을 사용하여 Amazon DynamoDB 테이블을 생성할 예정입니다. 컴플라이언스 요구 사항에 따라 KMS 키 관리 작업을 피하기 위해 AWS owned key로 저장 시 서버 측 암호화(at rest)가 필요하며, 테이블은 us-east-1에서 100 write capacity units와 250 read capacity units로 시작되어야 합니다. 이 요구 사항을 충족하도록 엔지니어는 테이블을 어떻게 정의해야 합니까?

오답입니다. customer managed KMS key는 키 생성, key policy 관리, 그리고 잠재적으로 로테이션/권한 관리가 필요합니다. 이는 KMS 키 관리 작업을 피하라는 요구 사항을 정면으로 위반합니다. 저장 시 암호화는 충족하겠지만 운영 부담이 가장 큰 옵션이며 “AWS owned key”와도 부합하지 않습니다.

오답입니다. alias/aws/dynamodb는 AWS managed KMS key이며 AWS owned key가 아닙니다. AWS managed key는 일부 오버헤드를 줄여주지만(AWS가 로테이션 처리), 여전히 고객 계정 내의 KMS 구성 요소를 포함하며 AWS owned key와 동일하지 않습니다. 요구 사항은 KMS 키 관리 작업을 피하기 위해 AWS owned key를 명시적으로 요구합니다.

오답입니다. 고객은 AWS owned key를 생성하거나 해당 ARN을 제공할 수 없습니다. AWS owned key는 AWS가 완전히 통제하며 고객 계정에서 보이거나 관리할 수 없으므로 SSESpecification.KMSMasterKeyId에서 참조할 ARN이 존재하지 않습니다. 이 선택지는 기술적으로 불가능합니다.

정답입니다. DynamoDB는 특정 KMS 키가 구성되지 않은 경우 기본적으로 AWS owned key를 사용하여 테이블을 저장 시 암호화합니다. CloudFormation 템플릿에서 SSESpecification을 생략하면 기본 동작을 활용하게 되어, KMS 키 관리 작업 없이 AWS owned key 암호화라는 컴플라이언스 요구 사항을 충족합니다. Provisioned throughput은 별도로 100 WCU와 250 RCU로 설정할 수 있으며, us-east-1에서 스택을 배포하면 리전 요구 사항도 충족됩니다.

문제 분석

핵심 개념: 이 문제는 AWS CloudFormation을 통한 Amazon DynamoDB server-side encryption(SSE) 구성과 AWS owned key, AWS managed KMS key, customer managed KMS key 간의 차이를 테스트합니다. 또한 provisioned capacity 설정(RCU/WCU)과 리전 배포(us-east-1은 스택의 리전으로 결정됨)도 다룹니다. 정답이 맞는 이유: 요구 사항은 “AWS owned key로 저장 시 server-side encryption”과 “KMS 키 관리 작업을 피할 것”입니다. DynamoDB는 기본적으로 저장 시 데이터를 암호화합니다. CloudFormation의 DynamoDB 테이블 리소스에서 SSESpecification을 생략하면 DynamoDB는 기본 암호화 동작을 사용하며, 이는 AWS owned key를 사용하여 SSE가 활성화된 상태입니다(AWS owned key는 계정에서 보이지 않으며 구성, 로테이션, 정책 관리가 필요하지 않음). 따라서 기본 암호화 설정으로 테이블을 정의하는 것이 컴플라이언스 요구 사항에 가장 부합하고 KMS 관리 작업을 제거합니다. 주요 AWS 기능: - DynamoDB 저장 시 암호화는 모든 테이블에서 기본적으로 활성화되어 있습니다. - AWS owned keys: AWS가 완전 관리하며 고객 계정에 존재하지 않고 key policy/rotation을 관리할 필요가 없습니다. - AWS managed KMS keys(예: alias/aws/dynamodb): 고객 계정에 존재하며 AWS가 관리하지만, 여전히 KMS 사용 제어/감사와 참조가 가능하며 “AWS owned keys”는 아닙니다. - Provisioned throughput: 템플릿에서 ProvisionedThroughput을 ReadCapacityUnits=250, WriteCapacityUnits=100으로 설정합니다. 리전은 us-east-1에서 CloudFormation 스택을 배포하여 제어합니다. 흔한 오해: 자주 있는 함정은 “AWS managed KMS key”가 “AWS owned key”와 같다고 가정하는 것입니다. 둘은 다릅니다. AWS managed key는 고객 계정 내의 KMS 키(AWS가 로테이션 관리)인 반면, AWS owned key는 고객이 접근할 수 없고 KMS 구성이 필요 없습니다. 또 다른 오해는 암호화를 활성화하려면 SSESpecification을 명시적으로 설정해야 한다는 생각인데, DynamoDB는 기본적으로 암호화가 켜져 있습니다. 시험 팁: - 문제가 명시적으로 “AWS owned key”와 “KMS 관리 작업 없음”을 요구하면, 기본 암호화(SSESpecification 미지정)가 보통 의도된 정답입니다. - alias/aws/service가 보이면 이는 AWS managed KMS key를 의미하며 AWS owned key가 아닙니다. - CloudFormation에서 리전 요구 사항은 리소스 속성이 아니라 스택을 실행하는 리전에 의해 결정된다는 점을 기억하세요.

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

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

6
문제 6

IoT 분석 팀은 AWS IoT Core rule을 통해 애플리케이션 로그를 /prod/gateway라는 단일 Amazon CloudWatch Logs log group으로 전송하는 200개의 edge gateway를 운영하고 있습니다. 대기 중인 엔지니어는 어떤 로그 라인에든 정확히 "FATAL"이라는 단어가 포함되면 60초 이내에 이메일을 받아야 합니다. 개발자는 이미 Amazon Simple Notification Service (Amazon SNS) topic을 생성하고 대기 중 이메일 목록을 해당 topic에 subscribe해 두었습니다. 요구 사항을 충족하기 위해 개발자가 다음으로 해야 할 일은 무엇입니까?

정답. /prod/gateway에 대한 CloudWatch Logs metric filter는 정확한 용어 "FATAL"의 발생 횟수를 카운트하고 custom metric을 publish합니다. 1-minute period와 threshold >= 1인 CloudWatch alarm은 해당 1분 동안 최소 1개의 일치 로그 이벤트가 발생하면 ALARM 상태가 되며, alarm action으로 기존 SNS topic에 알림을 보낼 수 있습니다. 이는 로그 패턴 기반 알림을 위한 정석적인 AWS 접근 방식입니다.

오답. CloudWatch Logs Insights는 임시(ad hoc) 분석과 scheduled queries에 적합하며, 60초 이내에 들어오는 모든 로그 라인에 대해 거의 실시간으로 알림을 제공하는 주된 방식이 아닙니다. CloudWatch가 일부 맥락에서 query 기반 metric 등에 대한 alarm을 지원하더라도, Logs Insights 쿼리에 지속적 탐지를 의존하는 것은 일반적으로 지연이 더 크며, 시험에서는 metric filters가 표준 정답입니다.

오답. “subscription filter” 개념은 CloudWatch Logs에 존재하지만, 일치하는 로그 이벤트를 Amazon Kinesis Data Streams, Kinesis Data Firehose 또는 AWS Lambda 같은 destination으로 전달합니다. Amazon SNS로 직접 전달하지 않습니다. SNS subscriptions는 message attributes를 기반으로 SNS 내부에서 메시지를 필터링하는 filter policies를 사용하지만, CloudWatch Logs는 SNS subscription filter를 통해 로그 이벤트를 SNS로 publish하지 않습니다.

오답. CloudWatch alarms는 metrics를 평가하며, alarm 정의에 CloudWatch Logs filter pattern을 직접 포함하는 것을 지원하지 않습니다. /prod/gateway에 대한 log group dimension과 log filter pattern을 지정해 알림을 트리거하는 native alarm 구성은 없습니다. 먼저 로그 매치를 metric(metric filter)으로 변환하거나 subscription(예: Lambda)으로 로그를 처리해 metric/event를 내보내야 합니다.

문제 분석

핵심 개념: 이 문제는 특정 로그 패턴을 거의 실시간으로 탐지하고 Amazon SNS를 통해 알림을 전달하기 위해 Amazon CloudWatch Logs metric filter와 CloudWatch alarm을 사용하는지를 평가합니다. CloudWatch Logs는 “일치하는 로그 라인에 대해 직접 이메일 전송”을 제공하지 않습니다. 대신 일치하는 로그 이벤트를 metric으로 변환한 다음 해당 metric에 대해 alarm을 설정해야 합니다. 정답이 맞는 이유: 옵션 A는 표준적이며 AWS에서 의도한 패턴입니다. /prod/gateway log group에 대해 정확한 단어 "FATAL"과 일치하는 filter pattern으로 CloudWatch Logs metric filter를 생성합니다. metric filter는 일치하는 로그 이벤트가 도착할 때마다 custom CloudWatch metric을 증가시킵니다. 그런 다음 1-minute period와 >= 1 threshold로 CloudWatch alarm을 생성하고, alarm action이 기존 SNS topic으로 publish하도록 구성합니다. 1-minute evaluation period를 사용하면 첫 번째 일치 이벤트 이후 60초 이내에 엔지니어가 알림을 받을 수 있습니다(일반적인 CloudWatch ingestion/processing latency는 고려). 주요 AWS 기능 / 구성: - CloudWatch Logs Metric Filter: 로그 이벤트를 수치 metric으로 변환합니다. 정확한 용어와 일치하는 filter pattern을 사용합니다(예: "FATAL"; 실제로 substring 매칭이 문제가 된다면 그에 맞게 패턴을 조정). - Custom Metric Namespace/Name: GatewayLogs 같은 명확한 namespace와 FatalCount 같은 metric name을 선택합니다. - CloudWatch Alarm: Period = 60 seconds, Statistic = Sum, Threshold = 1, Alarm action = SNS topic으로 설정합니다. - SNS Topic: 이미 생성 및 subscribe가 완료되었으므로, 남은 단계는 alarm을 SNS에 연결하는 것입니다. 흔한 오해: - Logs Insights는 대화형 쿼리와 대시보드용이며, 들어오는 모든 로그 라인에 대해 낮은 지연으로 지속적인 알림을 제공하는 주된 메커니즘이 아닙니다. - SNS는 “subscription filter”로 CloudWatch Logs에 직접 subscribe하지 않습니다(그것은 CloudWatch Logs subscription filter로 Kinesis/Lambda/Firehose로 전달하는 기능이며, SNS가 아님). SNS subscriptions는 message attributes를 기반으로 SNS 내부에서 메시지를 필터링하는 filter policies를 사용하지만, CloudWatch Logs는 SNS로 로그 이벤트를 SNS subscription filter를 통해 publish하지 않습니다. - CloudWatch alarms는 log filter pattern을 기본적으로 포함할 수 없습니다. alarms는 raw log stream이 아니라 metrics를 평가합니다. 시험 팁: “로그에 X가 포함되면 N초/분 이내 알림”을 보면 다음을 떠올리세요: CloudWatch Logs metric filter -> CloudWatch metric -> CloudWatch alarm -> SNS. 기억할 점: alarms는 metric 기반이며, 로그 패턴 매칭에는 metric filters가 필요합니다(또는 Lambda subscription pipeline이 가능하지만 여기서는 불필요하게 복잡).

7
문제 7

백엔드 팀은 레거시 주문 서비스를 6주 내에 AWS로 마이그레이션할 계획이지만, 모바일 앱 팀은 주문 조회 및 주문 생성 UI 플로우를 빌드하고 테스트하기 위해 안정적인 API 엔드포인트에 즉시 접근해야 합니다. 개발자는 아직 백엔드가 없는 상태에서 Amazon API Gateway REST API의 /orders 리소스에 GET 메서드를 생성합니다. 엔드포인트는 사전 정의된 HTTP 상태 코드(200, 404, 429)와 모바일 팀이 사용할 수 있는 정적 JSON 페이로드를 반환해야 하며, 어떤 compute 서비스도 배포하지 않아야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

Lambda를 사용하는 AWS_PROXY는 하드코딩된 JSON과 상태 코드를 쉽게 반환할 수 있지만, compute 서비스(Lambda)를 프로비저닝하고 배포해야 합니다. 문제는 어떤 compute 서비스도 배포하는 것을 명시적으로 금지합니다. 또한 proxy 통합은 Lambda 함수가 전체 응답 형식을 책임지므로 API Gateway에서의 세밀한 제어가 줄어들며, 단순한 정적 스텁에는 불필요합니다.

MOCK 통합은 백엔드 없이 응답을 반환하기 위해 목적에 맞게 설계되었습니다. 200/404/429에 대한 Method Responses를 구성한 다음, 각 상태 코드로 매핑하고 매핑 템플릿을 통해 정적 JSON을 반환하도록 Integration Responses를 구성합니다. 이는 모바일 팀을 위해 즉시 안정적인 엔드포인트를 제공하며 compute 배포가 없다는 요구 사항을 충족합니다.

HTTP_PROXY는 요청을 기존 HTTP 엔드포인트로 전달합니다. 이는 “아직 백엔드가 없음”이라는 의도에 어긋나며, 어딘가에 구축/호스팅해야 하는 외부 placeholder API에 대한 의존성을 도입합니다. 또한 API Gateway만으로 업스트림 서비스 없이 정적 응답을 제공하지도 못합니다.

이 선택지는 상태 코드와 페이로드가 구성되는 위치를 잘못 설명합니다. Method Request는 요청 파라미터, 검증, 인가를 위한 것이지 응답 상태 코드를 정의하는 것이 아닙니다. API Gateway REST API에서 상태 코드는 Method Response에서 선언되고 Integration Response에서 생성/매핑됩니다. 따라서 이 구성은 요구되는 200/404/429 정적 응답을 올바르게 구현하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Amazon API Gateway REST API 통합—특히 백엔드 compute 없이 정적 응답을 반환하는 데 사용되는 MOCK 통합—을 테스트합니다. 또한 API Gateway가 Method Response와 Integration Response를 사용해 특정 HTTP 상태 코드와 페이로드를 생성하도록 응답을 매핑하는 방식도 테스트합니다. 정답이 맞는 이유: MOCK 통합은 API Gateway 자체가 응답을 생성하도록 하고자 할 때 사용하도록 설계되었습니다. 백엔드가 없는 상황에서 개발자는 Integration type = MOCK으로 GET /orders 메서드를 구성한 다음, 여러 Method Response(예: 200, 404, 429)와 각 상태 코드에 매핑되는 Integration Response를 정의하여 정적 JSON 본문을 반환할 수 있습니다. 이는 안정적인 엔드포인트를 즉시 제공하고, 사전 정의된 상태 코드와 정적 페이로드를 제공해야 한다는 요구 사항을 충족하며, 어떤 compute 서비스도 배포하지 않게 해줍니다(Lambda 없음, 컨테이너 없음, EC2 없음). 주요 AWS 기능: 1) MOCK Integration: 백엔드를 호출하는 대신 템플릿을 기반으로 API Gateway가 응답을 반환합니다. 2) Method Response vs Integration Response: Method Response는 가능한 상태 코드/헤더를 선언하고, Integration Response는 백엔드(또는 mock) 출력을 해당 method response로 매핑하며 본문에 대한 매핑 템플릿을 정의합니다. 3) Mapping Templates (Velocity Template Language): 정적 JSON 페이로드를 생성하고 응답을 선택(보통 selection pattern 또는 request parameter를 통해)하는 데 사용됩니다. MOCK의 경우 일반적으로 Integration Request 매핑 템플릿을 사용해 더미 페이로드를 생성한 뒤, Integration Responses를 구성하여 원하는 본문/상태를 반환합니다. 흔한 오해: 흔한 함정은 하드코딩된 JSON을 반환하기 위해 Lambda(AWS_PROXY)를 반드시 사용해야 한다고 생각하는 것입니다. 이는 동작하긴 하지만 “어떤 compute 서비스도 배포하지 않고”라는 제약을 위반합니다. 또 다른 오해는 상태 코드가 Method Request에서 정의된다는 것인데, 그렇지 않습니다—상태 코드는 Method Response에서 구성되며 Integration Response 매핑을 통해 생성됩니다. 시험 팁: “아직 백엔드 없음”, “정적 페이로드”, “사전 정의된 응답 반환”, “mock/stub 엔드포인트”를 보면 API Gateway REST API + MOCK 통합을 떠올리십시오. 기억할 점: Method Request = 검증/인가/파라미터, Method Response = 클라이언트가 받을 수 있는 것, Integration Request/Response = API Gateway가 응답을 생성/변환하는 방식. 이 패턴은 contract-first API 개발과 병렬 팀 워크플로에서 흔히 사용됩니다.

8
문제 8

소규모 미디어 스타트업이 백엔드 서버 없이 클라이언트 디바이스에서만 전적으로 실행되는 React Native 모바일 앱을 출시하려고 합니다. 이 앱은 HTTP 헤더(x-api-key)에 회사의 API key를 전달하여 HTTP API로 노출된 서드파티 카탈로그 서비스를 호출해야 하지만, 사용자가 key를 볼 수 없도록 해야 합니다. 또한 월 약 3,000,000건의 요청이 예상되며 페이로드는 10 KB 미만입니다. 다음 중 모바일 앱이 서드파티 API를 안전하게 호출할 수 있도록 하면서 가장 비용 효율적인 방식의 AWS 솔루션은 무엇입니까?

오답입니다. API Gateway의 private REST API는 interface VPC endpoint(AWS PrivateLink)를 통해 VPC 내부에서만 접근할 수 있습니다. 공용 인터넷을 통해 클라이언트 디바이스에서 실행되는 React Native 앱은 private API 엔드포인트에 직접 접근할 수 없습니다. HTTP integration의 헤더 주입 자체는 기술적으로 가능하지만, 연결 모델이 “백엔드 없는 모바일 앱” 요구사항을 충족하지 못합니다.

오답입니다. private REST API와 Lambda proxy integration을 사용합니다. A와 같은 이유로 실패합니다. private API는 공용 모바일 클라이언트에서 접근할 수 없습니다. 또한 Lambda를 추가하면 단순히 정적 x-api-key 헤더를 추가하고 소규모 요청을 proxy하는 데 불필요한 비용과 운영 복잡성(timeouts, concurrency, retries)이 증가합니다.

정답입니다. HTTP integration이 있는 public API Gateway REST API는 요청을 서드파티 카탈로그 서비스로 proxy하고, integration request 계층에서 필요한 x-api-key 헤더를 주입하여 모바일 앱에서 key가 노출되지 않게 할 수 있습니다. 이는 Lambda 비용을 피할 수 있으며, 추가적인 custom compute가 필요 없는 상황에서 월 수백만 건의 소규모 요청에 대해 일반적으로 가장 비용 효율적인 접근입니다.

오답입니다. Lambda proxy integration이 있는 public REST API는 서드파티 API key를 숨길 수는 있지만, 가장 비용 효율적이지는 않습니다. Lambda는 invocation당 과금과, 직접 HTTP integration 대비 잠재적인 데이터 전송/지연 오버헤드를 추가합니다. validation, aggregation, 동적 secrets, 복잡한 변환 등 단순 헤더 주입을 넘어서는 custom logic이 필요할 때만 Lambda를 선택하십시오.

문제 분석

핵심 개념: 이 문제는 신뢰할 수 없는 클라이언트(모바일 앱)에서 정적 API key가 필요한 서드파티 HTTP API로의 호출을, 해당 key를 노출하지 않으면서 안전하게 중개하고, 중간 규모 트래픽에서 비용 효율적으로 구현하는 방법을 평가합니다. 핵심 AWS 서비스 패턴은 Amazon API Gateway가 HTTP integration을 사용해 가벼운 “API key 보관소 + proxy” 역할을 하는 것입니다. 정답이 맞는 이유: HTTP integration이 있는 public API Gateway REST API(옵션 C)를 사용하면 모바일 앱은 AWS에서 관리되는 엔드포인트를 호출하고, API Gateway가 upstream 카탈로그 서비스로 보내는 integration request에 서드파티 x-api-key 헤더를 주입합니다. 모바일 앱은 서드파티 key를 받지 않습니다. 페이로드가 작고(<10 KB) 요구사항이 단순히 헤더를 추가해 요청을 전달하는 것이라면, 직접 HTTP integration은 Lambda 실행 비용과 운영 오버헤드를 피할 수 있습니다. 월 ~3,000,000건 요청 규모에서는 Lambda를 제거하는 것이 일반적으로 가장 비용 효율적입니다. 주요 AWS 기능: API Gateway REST API는 HTTP/HTTP_PROXY integrations 및 request parameter mapping을 지원합니다. integration request에 정적 헤더 값(예: integration.request.header.x-api-key)을 설정하여 upstream이 필요한 key를 받도록 할 수 있습니다. 또한 throttling/usage plans(자체 클라이언트용), 남용 방지를 위한 AWS WAF, 그리고 proxy 엔드포인트를 누가 호출할 수 있는지 제어하기 위한 IAM/authorizers(예: Cognito JWT authorizer)를 서드파티 API key와는 별개로 적용할 수 있습니다. 흔한 오해: “Private REST API”(옵션 A/B)가 더 안전해 보일 수 있지만, private API는 interface endpoint를 통해 VPC 내부에서만 접근 가능합니다. 공용 인터넷에 있는 React Native 앱은 일반적으로 이를 직접 호출할 수 없습니다. 또 다른 오해는 secret을 숨기려면 Lambda가 필요하다는 것인데, 단순한 헤더 주입과 proxying에는 API Gateway mapping만으로 충분하며 더 저렴합니다. 시험 팁: 요구사항이 “정적 credential을 클라이언트로부터 숨기기”이고 “HTTP를 그대로 전달”이라면, custom logic, 복잡한 변환, 또는 동적 secret 조회/rotation이 필요하지 않는 한 Lambda보다 API Gateway direct integrations를 우선 고려하십시오. 또한 엔드포인트 유형이 호출자와 맞는지 확인해야 합니다. 모바일/공용 클라이언트는 private API가 아니라 public(regional/edge-optimized) API가 필요합니다.

9
문제 9

한 미디어 회사는 중앙 집중식 계정인 Shared-Config의 us-east-1 리전에서 AWS Systems Manager Parameter Store의 /prod/img/ 경로 아래에 25개의 애플리케이션 구성 값(모두 String 타입)을 파라미터로 저장하고 있습니다. 새로운 이미지 스케일링 마이크로서비스는 별도의 계정인 Dev-Render에서 Amazon ECS로 실행되며, Dev-Render로 복사하지 않고 컨테이너 시작 시 이러한 파라미터를 환경 변수로 읽어야 합니다. Dev-Render 팀은 교차 계정 액세스를 위해 운영 오버헤드가 가장 적은 읽기 전용, 최소 권한(least-privilege) 솔루션을 원합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

오답입니다. IAM user에 대한 장기 access key는 AWS 보안 모범 사례에서 명시적으로 권장되지 않습니다(roles 및 임시 자격 증명 사용). 또한 운영 오버헤드(키 로테이션, ECS로의 secret 배포, 유출 위험)를 증가시킵니다. 기술적으로는 가능할 수 있지만, 실제로 최소 권한에 친화적이지 않고 ECS 워크로드의 교차 계정 패턴으로 권장되지 않습니다.

정답입니다. Shared-Config에 /prod/img/ 파라미터로 범위가 제한된 읽기 전용 SSM 권한을 가진 IAM role을 생성하고, Dev-Render ECS task role이 이를 assume할 수 있도록 trust policy를 구성합니다. task는 STS를 사용해 임시 자격 증명을 얻고 시작 시 us-east-1에서 파라미터를 직접 읽습니다. 이는 최소 권한을 만족하고, 복사를 피하며, 운영 오버헤드가 낮습니다.

이 옵션은 여기서 최선의 선택이 아닙니다. AWS RAM을 사용해 advanced Systems Manager 파라미터를 cross-account로 공유할 수는 있지만, 문제에서는 이 파라미터가 advanced tier인지 또는 팀이 RAM을 통해 공유를 관리하려는지 명시하지 않습니다. ECS task가 다른 account의 파라미터를 읽는 가장 표준적이고 폭넓게 적용 가능한 솔루션은 owning account의 role을 assume하고 SSM을 직접 호출하는 것입니다. AWS 시험에서는 일반적으로 문제에서 지원되는 리소스 공유 기능과 그 전제 조건을 명시적으로 가리키지 않는 한, STS 기반 cross-account access가 선호됩니다.

오답입니다. 파라미터를 S3로 내보내면 구성 데이터의 두 번째 복사본이 생겨 “Dev-Render로 복사하지 않고”라는 의도에 위배되며, 운영 오버헤드(예약 job, 동기화, 액세스 제어, 드리프트 가능성)를 추가합니다. 또한 공격 표면을 넓히고 SSM 외에 S3 액세스와 객체 라이프사이클까지 관리해야 하므로 최소 권한 구현이 더 복잡해집니다.

문제 분석

핵심 개념: 이 문제는 ECS task에서 AWS Systems Manager Parameter Store에 cross-account로 접근하는 상황에 관한 것이며, 파라미터는 centralized account에 유지하면서 read-only, least-privilege 모델을 사용하는 것입니다. 한 account의 workload가 다른 account의 리소스를 읽기 위한 가장 표준적인 AWS 패턴은 AWS STS를 사용하여 owning account의 IAM role을 assume하는 것입니다. 정답인 이유: 옵션 B가 가장 적절한 정답인 이유는 Dev-Render의 ECS task가 Shared-Config에 있는 범위가 엄격히 제한된 read-only role을 assume한 다음, 시작 시 us-east-1의 SSM을 호출하여 /prod/img/ 아래의 파라미터를 가져올 수 있기 때문입니다. 이 방식은 temporary credentials를 사용하고, consuming account로 구성을 복사할 필요가 없으며, compute workload에 대해 가장 폭넓게 적용 가능하고 운영적으로도 단순한 cross-account 패턴입니다. 주요 AWS 기능: - Shared-Config의 IAM role에 /prod/img/ 계층에 대해 ssm:GetParameter, ssm:GetParameters, 그리고 일반적으로 ssm:GetParametersByPath 같은 권한을 부여합니다. - 해당 role의 trust policy는 Dev-Render의 ECS task role이 sts:AssumeRole을 호출할 수 있도록 허용해야 합니다. - Dev-Render의 ECS task role에는 해당 특정 role만 assume할 수 있는 권한이 필요합니다. - 파라미터가 String 타입이므로 KMS decrypt 권한은 필요하지 않습니다. SecureString인 경우에는 추가 KMS 권한이 필요합니다. 흔한 오해: - AWS RAM은 일부 리소스 타입을 공유할 수 있고, advanced Parameter Store 파라미터도 cross-account로 공유할 수 있지만, 문제에서 advanced shared parameters 사용을 명시적으로 나타내지 않는 한 이것이 기본적이거나 가장 보편적으로 적용 가능한 정답은 아닙니다. - 장기 IAM user access key는 ECS task에 권장되는 패턴이 아닙니다. 보안 위험과 운영 부담을 증가시키기 때문입니다. - 값을 S3 또는 다른 저장소에 복사하면 중복과 동기화 오버헤드가 발생합니다. 시험 팁: AWS 시험에서 실행 중인 workload의 cross-account access를 묻는다면, 먼저 owning account에서 least-privilege 권한을 가진 STS AssumeRole을 떠올리세요. 또한 "least operational overhead" 및 "without copying" 같은 표현도 주의해서 보세요. 이런 표현은 일반적으로 복제나 static secrets보다 temporary credentials를 사용한 직접 접근을 선호한다는 의미입니다.

10
문제 10

개발자가 스테이징 환경의 Amazon CloudWatch Evidently 프로젝트에서 새로운 "smart coupon" 기능에 대해 50/50 A/B 테스트를 실행하고 있습니다. 이 기능에는 두 가지 변형(Variation A 및 Variation B)이 있으며 요청은 userId 속성을 사용하여 평가됩니다. 개발자는 테스트 사용자 ID qa-7788을 사용하여 애플리케이션의 GET /v2/coupons 엔드포인트를 호출할 때 Variation A만 반환되도록 보장해야 합니다. 이 요구 사항을 충족하는 솔루션은 무엇입니까?

정답입니다. CloudWatch Evidently의 feature override는 특정 evaluation identifier(entity ID)에 대해 특정 variation을 강제로 적용하도록 설계되었습니다. 애플리케이션이 userId 속성을 사용하여 평가하므로, override identifier를 qa-7788로 설정하고 Variation A를 선택하면 50/50 A/B 할당과 무관하게 qa-7788은 항상 Variation A를 받게 됩니다.

오답입니다. override identifier는 variation 이름이 아니라 평가 중에 사용되는 entity ID 값(여기서는 qa-7788 같은 userId)이어야 합니다. 또한 “variation을 100%로 설정”하는 것은 단일 사용자에 대한 override 방식이 아닙니다. 이는 특정 identifier를 결정적으로 타깃팅하는 것이 아니라 더 넓은 범위의 할당을 변경하는 것을 의미합니다.

오답입니다. experiment를 생성하고 Variation B를 0%로 설정하면 특정 사용자 qa-7788에 대한 동작을 보장하는 것이 아니라 experiment의 트래픽 할당을 집단 수준에서 변경하게 됩니다. 또한 “experiment identifier”는 특정 userId를 타깃팅하는 데 사용되지 않으며, 평가 엔터티가 아니라 experiment 리소스를 식별합니다.

오답입니다. AWS account ID를 experiment identifier로 사용하는 것은 애플리케이션이 사용하는 userId 기반 평가와 매핑되지 않습니다. Experiment는 애플리케이션이 해당 identifier를 entity ID로 사용하고 override/targeting을 사용하지 않는 한 특정 userId를 타깃팅하지 않습니다. 이 옵션은 리소스 identifier와 evaluation identifier를 혼동하고 있으며 qa-7788이 Variation A를 받도록 보장하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Amazon CloudWatch Evidently feature flag 및 A/B 테스트 동작, 특히 기능이 50/50 분할로 구성되고 요청이 엔터티 identifier(여기서는 userId 속성)로 버킷팅될 때 평가가 어떻게 작동하는지를 테스트합니다. Evidently는 결정적 할당(동일 identifier에 대해 일관된 변형)과 feature override를 통한 타깃 동작도 지원합니다. 정답이 맞는 이유: 요구 사항은 특정 테스트 사용자(qa-7788)가 GET /v2/coupons를 호출할 때 항상 Variation A를 받도록 보장하는 것입니다. Evidently에서 feature override를 사용하면 특정 evaluation identifier에 대해 특정 variation을 강제로 적용할 수 있습니다. 애플리케이션이 userId 속성을 사용하여 기능을 평가하므로, override identifier를 qa-7788로 설정하고 Variation A를 선택하면 50/50 할당과 관계없이 해당 userId에 대한 모든 평가는 Variation A를 반환합니다. 이는 QA 검증, 데모, 특정 경로의 안전한 테스트를 위한 표준 접근 방식입니다. 주요 AWS 기능: Evidently feature flag는 “entity ID”(종종 userId, sessionId 또는 deviceId)를 사용하여 평가할 수 있습니다. 50/50 같은 allocation rule은 일반 사용자 집단에 적용되지만, override는 일치하는 identifier에 대해 우선 적용됩니다. Override는 feature 및 environment 범위로 적용되므로, 프로덕션 트래픽 할당을 변경하지 않고 스테이징에서만 결정적 동작을 보장하는 데 이상적입니다. 일반적인 오해: 흔한 실수는 분할 비율을 조작하거나 experiment를 만들어 한 사용자에 대해 결과를 강제하려는 것입니다. Experiment는 특정 userId별이 아니라 집단 수준에서 트래픽 할당을 제어합니다(외부에서 세그멘테이션 로직을 구현하지 않는 한). 또 다른 오해는 override identifier를 variation 이름과 혼동하는 것입니다. Identifier는 평가 중에 사용되는 entity ID와 일치해야 합니다. 시험 팁: “특정 사용자가 항상 특정 variation을 받도록 보장”이라는 문구가 보이면 “experiment”가 아니라 “feature override”(또는 “targeting”)를 찾으십시오. 또한 평가에 어떤 속성이 사용되는지(여기서는 userId) 확인하십시오. Override는 해당 identifier와 정확히 일치해야 하며, 단일 테스터에 대해 결정적 동작을 보장하는 가장 빠르고 영향이 적은 방법입니다.

합격 후기(8)

전
전**Nov 26, 2025

학습 기간: 1 month

점수는 793점으로 합격했어요! 하루에 최소 30문제는 풀었어요. 밖에서도 짬 날 때마다 풀 수 있으니 좋네요ㅎㅎ

김
김**Nov 24, 2025

학습 기간: 2 months

앱 문제가 시험이랑 굉장히 유사했어요. 그리고 해설들이 왜 틀렸는지 이해하는데 도움이 됐어요.

**********Nov 22, 2025

학습 기간: 1 month

Thank you very much, these questions are wonderful !!!

윤
윤**Nov 20, 2025

학습 기간: 2 months

1달 전에 합격했는데 지금 후기쓰네요. 시험하고 문제 구성이 비슷했어요

A
A******Nov 16, 2025

학습 기간: 2 months

I just passed the exam, and I can confidently say that this app was instrumental in helping me thoroughly review the exam material.

다른 모의고사

Practice Test #1

65 문제·130분·합격 720/1000

Practice Test #2

65 문제·130분·합격 720/1000

Practice Test #3

65 문제·130분·합격 720/1000

Practice Test #4

65 문제·130분·합격 720/1000

Practice Test #6

65 문제·130분·합격 720/1000
← 모든 AWS Certified Developer - Associate (DVA-C02) 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 AWS Certified Developer - Associate (DVA-C02) 기출 문제를 풀어보세요.

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