연습 문제

문제 1

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

문제 2

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

문제 분석

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

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

문제 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초까지 걸릴 수 있음), 두 번째 예약이 해당 슬롯을 가져야 하며 그 결제가 처리되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

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

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

문제 분석

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

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해 두었습니다. 요구 사항을 충족하기 위해 개발자가 다음으로 해야 할 일은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 특정 로그 패턴을 거의 실시간으로 탐지하고 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

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

문제 분석

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

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

문제 분석

핵심 개념: 이 문제는 신뢰할 수 없는 클라이언트(모바일 앱)에서 정적 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

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

문제 분석

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

개발자가 스테이징 환경의 Amazon CloudWatch Evidently 프로젝트에서 새로운 "smart coupon" 기능에 대해 50/50 A/B 테스트를 실행하고 있습니다. 이 기능에는 두 가지 변형(Variation A 및 Variation B)이 있으며 요청은 userId 속성을 사용하여 평가됩니다. 개발자는 테스트 사용자 ID qa-7788을 사용하여 애플리케이션의 GET /v2/coupons 엔드포인트를 호출할 때 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와 정확히 일치해야 하며, 단일 테스터에 대해 결정적 동작을 보장하는 가장 빠르고 영향이 적은 방법입니다.

Practice Test #5

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(8)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #6

지금 학습 시작하기