연습 문제

문제 1

한 회사가 Amazon ECS에서 AWS Fargate로 결제-승인 microservice를 실행하고 있으며, 각 승인은 2초 이내에 완료되어야 합니다. 단일 승인이라도 2초 이상 걸리면 개발 팀에 알림이 가야 합니다. 개발자는 운영 오버헤드를 최소화하면서 타이밍 측정과 알림을 어떻게 구현할 수 있습니까?

문제 분석

핵심 개념: 이 문제는 ECS on Fargate 마이크로서비스에 대해 오버헤드가 낮은 지연 시간 모니터링 및 알림을 구현하는 방법을 테스트합니다. 가장 적합한 AWS 네이티브 접근 방식은 authorization 지연 시간을 CloudWatch custom metric으로 게시하고 CloudWatch alarm을 사용해 Amazon SNS를 통해 알림을 보내는 것입니다. 정답인 이유: 요구 사항은 단 한 번의 authorization이라도 2초 이상 걸리면 팀에 알리는 것입니다. 각 authorization의 처리 시간을 custom metric datapoint로 게시하면, 개발자는 Maximum statistic에 대해 임계값을 2000 ms로 설정한 CloudWatch alarm을 구성할 수 있습니다. 그러면 평가 기간 내 어떤 datapoint라도 2000 ms 이상이면 alarm이 트리거됩니다. SNS는 CloudWatch alarm의 표준 관리형 알림 대상이므로 운영 오버헤드를 낮게 유지할 수 있습니다. 주요 AWS 기능: - CloudWatch custom metrics: authorization별 지연 시간 값을 밀리초 단위로 게시하며, 필요에 따라 service name 또는 environment 같은 dimensions를 포함할 수 있습니다. - CloudWatch alarms: 짧은 period를 구성하고 Maximum statistic을 평가하여, 해당 기간 내 단 한 번의 느린 authorization만으로도 임계값 초과가 발생하도록 할 수 있습니다. high-resolution metrics를 사용하면 응답성을 높일 수 있습니다. - Amazon SNS: email, SMS, HTTPS endpoint 또는 incident-management integration으로 관리형 fan-out 알림을 제공합니다. 흔한 오해: 흔한 실수 중 하나는 평균 지연 시간 alarm이 개별적으로 느린 요청을 잡아낼 것이라고 가정하는 것입니다. 평균값은 이상치를 숨길 수 있습니다. 또 다른 오해는 단순한 임계값 감지를 위해 SQS 또는 Kinesis 같은 서비스가 필요하다고 생각하는 것이지만, 이런 서비스는 불필요한 consumer와 운영 복잡성을 추가합니다. 또한 CloudWatch alarms는 기간별 metric statistic을 기준으로 동작하므로, Maximum 같은 올바른 statistic을 사용하는 것이 중요합니다. 시험 팁: 요구 사항이 '단일 요청 하나라도 임계값을 초과하면 알림'이고 운영 오버헤드를 최소화해야 한다면, custom CloudWatch metric + Maximum 기준 alarm + SNS를 떠올리세요. 문제가 명시적으로 custom processing, replay 또는 downstream analytics를 요구하지 않는 한 queue 또는 stream consumer를 구축해야 하는 솔루션은 피하세요. 'any single event'와 'average over time' 같은 표현 차이에 특히 주의하세요.

문제 2

한 물류 회사가 8,000대의 배송 밴에서 텔레매틱스 이벤트를 수신하며, 피크 시 초당 1,200개의 이벤트가 발생하고 이벤트당 평균 1.5 KB입니다. EC2 기반 처리 애플리케이션 3개(이상 징후 탐지, 과금, 실시간 대시보드)가 동일한 이벤트 스트림을 거의 실시간으로 서브초(sub-second) 지연으로 동시에 소비해야 합니다. 각 프로세서는 배포 또는 크래시 동안 일시 중지할 수 있어야 하며, 데이터 손실 없이 마지막 체크포인트에서 재개할 수 있어야 합니다. 팀은 다음 달에 프로세서 2개를 추가할 계획이며, 각 소비자마다 데이터 파이프라인을 중복하는 것을 피하고자 합니다. 이러한 요구 사항을 충족하기 위해 스트림을 수집하고 팬아웃(fan out)하는 데 개발자가 사용해야 하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 여러 동시 소비자, 낮은 지연 시간, 그리고 파이프라인을 중복하지 않으면서도 소비자별로 독립적인 재생/체크포인팅이 가능한 실시간 스트리밍 수집을 평가합니다. 이를 위해 설계된 AWS 서비스는 Amazon Kinesis Data Streams (KDS)이며, 내구성 있는 스트림 저장과 동일 데이터를 읽는 여러 소비자 애플리케이션을 지원합니다. 정답이 맞는 이유: Kinesis Data Streams는 높은 처리량(초당 1,200 이벤트 × ~1.5 KB는 ~1.8 MB/s)으로 이벤트를 수집하고, 거의 실시간 처리를 위한 서브초 읽기 지연을 제공합니다. 무엇보다도 여러 처리 애플리케이션이 동일한 스트림을 동시에 소비할 수 있습니다. 각 애플리케이션은 자체 체크포인트(일반적으로 DynamoDB의 KCL lease/체크포인팅 또는 커스텀 체크포인팅)를 유지할 수 있으므로, 프로세서가 배포 중 일시 중지되거나 크래시가 발생해도 스트림 보존(retention) 기간 내에서 데이터 손실 없이 마지막으로 처리한 시퀀스 번호부터 재개할 수 있습니다. 다음 달에 새 프로세서를 추가하는 것도 간단합니다. 동일한 스트림에 추가 소비자로 연결하면 되며, 수집을 중복할 필요가 없습니다. 주요 AWS 기능: - 다중 소비자: 표준 폴링 소비자 또는 소비자별 전용 처리량과 낮은 지연을 위한 Enhanced Fan-Out (EFO) - 재생 가능성: 구성 가능한 retention(24시간~365일)로 재처리 및 복구 가능 - 순서 및 내구성: 샤드(shard)별 레코드 순서 보장 및 여러 AZ에 걸친 복제 - 확장: 샤드 수 증가(또는 on-demand 모드 사용)로 처리량 증가 대응 - 체크포인팅: Kinesis Client Library (KCL)가 일반적으로 DynamoDB에 체크포인트를 저장하여 장애 후 재개 의미론을 제공 흔한 오해: SQS는 디커플링에 자주 선택되지만, 여러 앱이 독립적으로 재생할 수 있는 스트림이 아니라 큐(경쟁 소비자)입니다. Firehose는 목적지(S3/Redshift/OpenSearch)로의 전달을 위한 서비스이며, 재생 기능을 갖춘 여러 거의 실시간 소비자를 위한 용도가 아닙니다. EventBridge는 라우팅/통합을 위한 이벤트 버스이며, 소비자별 체크포인트와 서브초 스트리밍 의미론을 갖춘 스트림 방식의 retention을 제공하지 않습니다. 시험 팁: “여러 애플리케이션이 동일 이벤트를 읽어야 함”, “거의 실시간/서브초”, “마지막 체크포인트에서 재개”를 보면 Kinesis Data Streams(또는 Kafka/MSK)를 떠올리십시오. “파이프라인을 중복하지 않고 많은 소비자에게 팬아웃” 요구가 있으면, KDS + Enhanced Fan-Out 및 소비자별 체크포인팅이 AWS 네이티브 정답 패턴입니다.

문제 3

한 팀이 프로덕션을 위해 Amazon S3 오리진을 사용하는 Amazon CloudFront를 통해 제공되는 single-page application(SPA)을 출시하고 있습니다. 이 SPA는 Amazon API Gateway REST API를 호출하며, 이 API는 Amazon Aurora MySQL DB cluster에 연결하는 AWS Lambda function을 호출합니다. 프로덕션 트래픽은 특정 published function version을 가리키는 prod라는 Lambda alias를 사용합니다. 회사 정책은 데이터베이스 credentials를 14일마다 rotation할 것을 요구하며, alias가 참조할 수 있는 이전에 published된 모든 Lambda version은 코드를 republish하지 않고도 항상 최신 credentials를 사용해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Lambda versioning/aliases를 사용하면서 데이터베이스 credentials를 안전하게 저장하고 rotation하는 것을 테스트합니다. 핵심 제약은 prod alias가 이전에 published된 Lambda versions 사이에서 이동할 수 있지만, 모든 version이 코드를 republish하지 않고도 항상 최신 데이터베이스 credentials를 사용해야 한다는 점입니다. 정답이 맞는 이유: AWS Secrets Manager는 데이터베이스 credentials를 저장하고 일정에 따라 rotation하도록 설계되었습니다. Lambda function이 runtime에 secret 값을 가져오도록(코드, 구성 또는 특정 version에 포함시키지 않고) 하면, 이전이든 최신이든 어떤 published Lambda version이라도 항상 현재 credentials를 가져오게 됩니다. 이는 14일마다 credential rotation이 이루어져야 하고, prod alias가 해당 versions로 전환되더라도 이전에 published된 versions가 계속 동작해야 한다는 요구 사항을 충족합니다. 주요 AWS 기능: Secrets Manager는 AWS 제공 rotation Lambda blueprint를 사용하여 Amazon Aurora MySQL credentials에 대한 managed rotation을 지원합니다. Rotation은 secret과 데이터베이스 user password를 조정된 방식으로 업데이트합니다. Lambda는 특정 secret ARN으로 범위가 제한된 IAM policy를 사용하여 Secrets Manager API(GetSecretValue)를 통해 secret을 읽을 수 있습니다. 모범 사례는 지연 시간과 API 호출을 줄이기 위해 짧은 TTL 동안 secret을 메모리에 캐시하되, rotation 이후에는 반드시 refresh되도록 하는 것입니다. 이는 AWS Well-Architected Security pillar 가이드(centralized secret 저장, 자동 rotation, 장기 고정 credentials 회피)와 일치합니다. 흔한 오해: Lambda environment variables(옵션 C)를 업데이트하면 모든 versions가 업데이트될 것처럼 보일 수 있지만, environment variables는 Lambda version 구성의 일부입니다. Published versions는 immutable이므로 environment variables 업데이트는 $LATEST(및 새로 published되는 version)에만 영향을 주며, alias가 참조할 수 있는 이전 versions에는 영향을 주지 않습니다. 마찬가지로 credentials를 코드에 포함(옵션 B)하면 redeploy가 필요해져 “코드를 republish하지 않음” 요구 사항을 위반합니다. 시험 팁: “credentials rotation”과 “redeploy 없이 Lambda versions/aliases 전반에서 동작해야 함”을 보면 Secrets Manager + runtime retrieval을 떠올리십시오. 또한 Lambda versions는 코드와 구성(environment variables 포함)의 immutable snapshot임을 기억하십시오. 데이터베이스 credentials의 경우, rotation이 명시적으로 요구되고 특히 RDS/Aurora 통합에서는 일반적으로 Parameter Store보다 Secrets Manager가 선호됩니다.

문제 4

한 개발 팀이 서버리스 사진 검사 포털을 구축했습니다. 웹 UI는 AWS Step Functions 워크플로와 AWS Lambda를 사용하여 600–1,800 MB 위성 이미지 번들의 처리를 트리거하며, UI는 Lambda를 호출하는 Amazon API Gateway의 REST API로 백업됩니다. start-processing 요청은 작업이 4–10분 걸리기 때문에 API Gateway의 29초 제한으로 인해 자주 타임아웃이 발생합니다. 하지만 UI는 “processing started” 메시지를 표시할 수 있도록 즉시 응답을 받아야 하며, API에서 호출되는 백엔드는 처리가 완료되면 이메일을 보내야 합니다. 이러한 요구 사항을 충족하도록 개발자는 API를 어떻게 구성해야 합니까?

문제 분석

핵심 개념: 이 문제는 장시간 실행되는 서버리스 백엔드를 위해 API Gateway + Lambda 통합을 설계하는 방법을 테스트합니다. 핵심 제약은 API Gateway의 하드 통합 타임아웃(REST API의 경우 29초)이며, 백엔드 작업이 몇 분 걸리는 경우 동기식 요청/응답 패턴과 호환되지 않습니다. 올바른 패턴은 Lambda를 비동기적으로(파이어-앤-포겟) 호출하여 클라이언트 요청을 장시간 처리로부터 분리하고 즉시 반환하는 것입니다. 정답이 맞는 이유: 옵션 A는 InvocationType을 Event(비동기 호출)로 설정하여 API Gateway가 Lambda를 호출하도록 구성합니다. 비동기 호출을 사용하면 API Gateway는 Step Functions 워크플로가 완료될 때까지 기다리지 않고 즉시 202 스타일 응답(또는 사용자 지정 성공 페이로드)을 반환할 수 있습니다. 그런 다음 Lambda 함수는 Step Functions state machine 실행(StartExecution)을 시작하고 빠르게 종료할 수 있습니다. 워크플로가 끝나면 백엔드는 최종 Step Functions task state 또는 완료 Lambda에서 이메일을 보낼 수 있습니다(일반적으로 Amazon SNS 또는 Amazon SES 사용). 주요 AWS 기능: - API Gateway REST API 타임아웃은 29초를 초과하도록 구성할 수 없으므로 동기식 대기를 피해야 합니다. - Lambda는 동기(RequestResponse) 및 비동기(Event) 호출을 지원합니다. API Gateway는 X-Amz-Invocation-Type 헤더를 전달하여 이를 제어할 수 있습니다. - Step Functions는 수 분짜리 워크플로를 위해 설계되었으며, 오케스트레이션에 사용하고 완료 시 알림을 트리거합니다. - 신뢰할 수 있는 완료 알림: Step Functions는 service integration을 통해 SNS/SES에 직접 게시하거나 Lambda를 호출하여 이메일을 보낼 수 있습니다. 흔한 오해: 많은 사람들이 “API Gateway 타임아웃을 Lambda와 맞추기 위해 늘릴 수 있다”고 생각하지만(불가능), 또 다른 사람들은 Lambda의 비동기 재시도 제어(Maximum event age)를 호출을 비동기로 만드는 것과 혼동합니다. 이러한 설정은 이미 비동기 호출을 하고 있는 경우에만 적용됩니다. 시험 팁: “API Gateway timeout”과 “처리가 몇 분 걸림”을 보면, 기대되는 해결책은 비동기 호출 또는 비동기 워크플로 패턴(즉시 job ID 반환, callbacks/webhooks, polling, 또는 notifications)입니다. 기억하세요: REST API Gateway 타임아웃은 고정되어 있으므로 분리(async Lambda, SQS, EventBridge, Step Functions)와 완료 이벤트(SNS/SES/EventBridge)를 사용해 설계해야 합니다.

문제 5

서버리스 작업이 Amazon EventBridge 스케줄에 의해 트리거되는 AWS Lambda function을 사용하여 15분마다 서드파티 통화 환율 API를 호출하며, function은 x-api-key를 포함해야 하고 키가 저장 시(at rest) 암호화되도록 보장해야 한다. 개발자는 어떤 솔루션을 구현해야 하는가?

문제 분석

핵심 개념: 이 문제는 서버리스 워크로드에서의 안전한 secret 처리, 특히 AWS Lambda가 민감한 구성 데이터(API 키)를 저장하고 보호하는 방식과 AWS Key Management Service (AWS KMS)가 저장 시(at rest) 암호화를 제공하는 방식을 테스트한다. 정답이 맞는 이유: x-api-key를 Lambda environment variable로 저장하고 customer managed KMS key (CMK)로 암호화하면 키가 저장 시(at rest) 암호화되어야 한다는 요구 사항을 충족한다. Lambda는 environment variable을 저장 시 암호화하고 invocation 시 복호화한다. 기본 AWS managed key 대신 CMK를 지정하면 개발자는 key policy, rotation, auditing, access boundary에 대해 더 강력한 제어를 얻는다. 이는 흔한 시험 패턴이다: “secret은 저장 시 암호화되어야 함” + “Lambda”는 보통 KMS를 통한 environment variable 암호화(또는 Secrets Manager/Parameter Store이지만 여기서는 선택지에 없음)를 가리킨다. 주요 AWS 기능: - Lambda environment variables: 코드를 분리하여 구성을 저장하는 데 사용. - Encryption helpers: Lambda는 AWS KMS와 통합되어 environment variables를 저장 시 암호화. - Customer managed KMS key: 세밀한 key policy, CloudTrail을 통한 decrypt 사용 감사, 선택적 automatic rotation을 가능하게 함. - IAM permissions: Lambda execution role은 CMK에 대한 kms:Decrypt 권한이 있어야 하며(그리고 key policy가 이를 허용해야 함). 흔한 오해: - “HTTPS-only”는 전송 중(in transit) 데이터 보호이며, 저장 시(at rest) 보호가 아니다. VPC 배치는 본질적으로 secret을 암호화하지 않으며 복잡성(NAT, endpoints)을 추가할 수 있다. - secret을 코드에 포함하는 것은 중대한 보안 안티패턴이며 rotation을 복잡하게 만든다. - 운영자에게 입력을 요청하는 방식은 무인 스케줄 실행과 양립할 수 없고 안전한 저장을 보장하지 않는다. 시험 팁: Lambda에서 구성/자격 증명에 대해 “저장 시 암호화되어야 함”을 보면 KMS 기반 저장소(environment variables 또는 외부 secret store)를 찾는다. 선택지에 Lambda environment variables에 대한 CMK가 명시되어 있다면, 이는 저장 시 암호화와 access control 요구 사항을 직접 충족하므로 보통 최적의 선택이다. 또한 런타임에서 복호화가 성공하려면 IAM + KMS key policy 정렬을 고려해야 한다는 점을 기억하라.

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

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

문제 6

한 fintech startup이 AWS Lambda에서 Node.js microservice를 실행하며 client_id와 client_secret을 사용해 third-party payment gateway의 REST API를 호출합니다. 현재 해당 자격 증명은 Lambda function의 plaintext environment variables로 저장되어 있으며, security team은 코드 redeployment 없이 90일마다 자동 rotation을 의무화합니다. 개발자는 API 자격 증명을 안전하게 보호하고 분기별 rotation을 강제하면서, function이 IAM을 사용해 runtime에 자격 증명을 가져올 수 있도록 해야 합니다. 가장 안전한 접근 방식을 제공하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 IAM 기반 runtime access를 사용하여 AWS Lambda용 third-party application secrets를 안전하게 저장하고 자동 rotation을 수행하는지를 평가합니다. 주요 서비스는 자격 증명 관리, rotation, 통제된 retrieval을 위해 목적에 맞게 설계된 AWS Secrets Manager입니다. 정답인 이유: Option C가 가장 안전하고 운영 측면에서도 올바른 접근 방식인 이유는 Secrets Manager가 payment gateway client_id/client_secret을 저장하고 KMS로 at rest 암호화하며, (핵심적으로) Lambda code redeployment 없이 90일 일정으로 automatic rotation을 수행할 수 있기 때문입니다. Lambda function은 IAM role policy(least privilege)를 사용해 Secrets Manager API로 runtime에 secret을 가져옵니다. Rotation은 저장된 secret value를 중앙에서 업데이트하며, function은 각 invocation마다 최신 version을 읽기만 하면 됩니다(또는 short-lived caching 사용). 이는 “no redeployments” 요구 사항을 충족합니다. 주요 AWS 기능: Secrets Manager는 built-in rotation scheduling과 rotation workflows(일반적으로 rotation Lambda를 통해)를 지원합니다. third-party API의 경우에도, credential regeneration을 지원한다면 새 secret을 생성하고 third-party system을 업데이트하는 custom rotation Lambda를 구현할 수 있습니다. Secrets는 KMS로 암호화되며, access는 IAM policies 및 optional resource policies로 제어되고, retrieval은 AWS CloudTrail로 감사(audit)할 수 있습니다. 이는 AWS Well-Architected Security Pillar의 모범 사례(데이터 보호, 강력한 identity 기반 구현, 보안 모범 사례 자동화)와 일치합니다. 흔한 오해: KMS key rotation(Option A)은 encryption key material을 rotation하는 것이지, underlying plaintext secret value를 rotation하는 것이 아니므로 “90일마다 자격 증명 rotation” 요구 사항을 충족하지 못합니다. STS(Option B)는 AWS API용 AWS credentials를 발급하는 것이지 third-party payment gateway용이 아닙니다. Parameter Store SecureString(Option D)은 값을 암호화하고 access control을 지원하지만, Secrets Manager와 동등한 native, managed automatic rotation workflow를 제공하지 않습니다. Rotation은 수동이거나 custom automation이 필요하며, first-class rotation 기능 측면에서 부족합니다. 시험 팁: “automatic rotation”, “secrets”, “no redeployments”가 보이면 기본적으로 Secrets Manager를 선택하십시오. KMS의 encryption key rotation과 secret 자체의 rotation을 구분하십시오. 또한 STS는 외부 API secrets가 아니라 AWS temporary credentials를 위한 것임을 기억하십시오. 민감한 데이터는 environment variables보다 IAM role 기반 runtime retrieval을 선호하십시오.

문제 7

한 미디어 스타트업은 모든 Amazon S3 bucket이 AWS CloudFormation stack을 통해서만 프로비저닝되도록 의무화하고 있으며, 개발자는 이미 Amazon Simple Notification Service (Amazon SNS) topic을 생성하고 security-ops@example.com을 구독시켰습니다. 이제 보안 팀은 CloudFormation에 의해 시작되지 않은 CreateBucket action이 발생할 때마다 즉시(60초 이내) 알림을 요구합니다. 이 요구 사항을 충족하는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon EventBridge(이전 CloudWatch Events)와 통합된 AWS CloudTrail을 사용하여 승인되지 않은 API 활동을 거의 실시간으로 탐지하는지를 평가합니다. 목표는 승인된 프로비저닝 경로(AWS CloudFormation) 밖에서 Amazon S3 CreateBucket API call이 발생할 때 60초 이내에 알림을 보내는 것입니다. 정답이 맞는 이유: Option D가 정답인 이유는 EventBridge가 s3.amazonaws.com CreateBucket에 대한 CloudTrail management event를 직접 매칭하고, 매칭된 event를 Amazon SNS topic으로 즉시(일반적으로 수 초, 60초 이내) 라우팅할 수 있기 때문입니다. detail.eventSource = "s3.amazonaws.com" 및 detail.eventName = "CreateBucket" 같은 필드를 기준으로 필터링하고, CloudFormation에서 기원한 call을 제외(예: detail.userIdentity.invokedBy에 "anything-but" 매칭을 사용하거나 CloudFormation을 나타내는 다른 identity attribute 사용)하면, CloudFormation에 의해 시작되지 않은 bucket 생성일 때만 rule이 트리거됩니다. 이는 이벤트 기반, 저지연이며 폴링 인프라가 필요하지 않습니다. 주요 AWS 기능: 1) CloudTrail management events: CreateBucket은 management event이며 CloudTrail이 활성화되어 있으면 EventBridge로 전달될 수 있습니다. 2) EventBridge event pattern: 알려진 source를 제외하기 위한 "anything-but"를 포함해 고급 매칭을 지원합니다. 3) SNS를 target으로 사용: EventBridge는 기존 topic/subscription을 활용하여 SNS로 직접 게시할 수 있습니다. 4) 보안 모범 사례: 서버 없이 중앙집중식 탐지/알림을 구현하는 것은 AWS Well-Architected의 Security 및 Operational Excellence pillar에 부합합니다. 흔한 오해: CloudTrail log를 폴링(Lambda/ECS/EC2를 schedule로 실행)하는 방식은 단순해 보이지만, 탐지 지연(선택지에서는 15분)과 운영 오버헤드를 유발합니다. 또한 S3로 전달되는 log file을 파싱하는 것은 전달 지연과 배치 처리 때문에 60초 SLA를 보장하기 어렵습니다. EventBridge는 API call에 거의 실시간으로 반응하도록 설계되었습니다. 시험 팁: API 활동에 대해 “X초 이내 알림”이 보이면 이벤트 기반 패턴(CloudTrail + EventBridge rule + SNS/Lambda target)을 우선 고려하십시오. 요구 사항이 분 단위 지연을 명시적으로 허용하지 않는 한 schedule 기반 폴링은 피하십시오. 또한 CloudFormation에서 기원한 action은 userIdentity field(invokedBy/arn/session context)로 식별할 수 있으므로, EventBridge event pattern에서 제외 필터를 구성할 수 있음을 기억하십시오.

문제 8

한 핀테크 스타트업이 Amazon API Gateway에서 AWS Lambda 프록시 통합을 사용해 12개의 내부 마이크로서비스 API에 대한 서버리스 API 계층을 운영하고 있으며, 팀은 어떤 Lambda도 호출하지 않고 API Gateway에서 직접 제공되는 경량 HTML API Directory 페이지(약 6KB)를 노출하려고 합니다. 한 개발자가 새 /directory 리소스와 mock 통합을 사용하는 GET 메서드를 생성했습니다. 응답은 HTTP 200과 Content-Type: text/html을 반환해야 합니다. 이러한 요구 사항을 충족하기 위해 개발자가 다음으로 수행해야 할 작업은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon API Gateway REST API의 “Mock” 통합 동작과, 백엔드(Lambda/HTTP)를 호출하지 않고 정적 응답을 반환하기 위해 매핑 템플릿을 사용하는 방법을 테스트합니다. mock 통합에서는 API Gateway가 요청 매핑 템플릿을 기반으로 통합 응답을 생성한 다음, 통합 응답 설정을 사용해 이를 메서드 응답으로 변환합니다. 정답이 맞는 이유: mock 통합의 경우, API Gateway가 올바른 통합 응답을 선택할 수 있도록 status code를 포함하는 페이로드(일반적으로 {"statusCode": 200})를 생성하는 요청 매핑 템플릿이 필요합니다. 그런 다음 클라이언트에 반환할 정적 본문을 통합 응답 매핑 템플릿에 넣습니다. 요구 사항은 HTTP 200과 Content-Type: text/html로 HTML을 반환하는 것이므로, 통합 응답을 200 메서드 응답에 매핑하고 응답 헤더 Content-Type을 text/html로 설정하며, 본문 매핑 템플릿에는 HTML 디렉터리 페이지를 포함하도록 통합 응답을 구성합니다. 옵션 C는 이 패턴과 일치합니다. 요청 템플릿이 {"statusCode": 200}을 설정하고, 응답 템플릿이 text/html로 HTML을 반환합니다. 주요 AWS 기능: - Mock 통합: API Gateway가 어떤 백엔드도 호출하지 않고 응답을 반환합니다. - 매핑 템플릿(Velocity Template Language): - 통합 요청 템플릿: 응답 선택에 사용되는 합성 페이로드(statusCode 포함)를 생성합니다. - 통합 응답 템플릿: 응답 본문(HTML 콘텐츠)을 정의합니다. - 메서드/통합 응답 헤더: 메서드 응답이 Content-Type(또는 Content-Type 같은 헤더)을 선언하도록 하고, 통합 응답이 이를 text/html로 매핑/재정의하도록 해야 합니다. 일반적인 오해: 자주 하는 실수는 HTML을 통합 요청 템플릿에 넣는 것입니다. 요청 템플릿은 클라이언트가 받는 것이 아니라, API Gateway가 내부적으로 통합 응답 선택을 구동하기 위해 사용하는 것입니다. 또 다른 오해는 요청 템플릿의 “Content-Type”이 나가는 응답을 제어한다고 생각하는 것입니다. 응답 헤더는 메서드/통합 응답 구성에서 제어됩니다. 시험 팁: - Mock 통합을 사용하는 REST API의 경우: 요청 템플릿은 종종 {"statusCode": 200}을 반환합니다. - 정적 페이로드는 통합 응답 매핑 템플릿에 있어야 합니다. - 항상 정렬: 메서드 응답(상태 코드/헤더 선언) + 통합 응답(상태 코드/헤더/본문 매핑). 문제가 Content-Type을 강조한다면, 요청 경로가 아니라 응답 경로에서 설정되었는지 확인하십시오.

문제 9

한 개발자가 Amazon EventBridge 규칙을 사용해 AWS Step Functions state machine을 트리거하고, 이 state machine이 여러 AWS Lambda 함수를 호출하는 AWS 기반 이벤트 기반 주문 처리 시스템을 테스트하고 있습니다. 분당 1,500개의 이벤트로 20분간 부하 테스트를 수행하는 동안 간헐적인 5xx 오류가 발생하지만, 개발자는 어떤 구성 요소가 실패하는지 빠르게 파악할 수 없습니다. 오류를 정확히 찾아내기 위해 개발자는 최소한의 설정과 지속적인 유지 관리로, 최근 24시간 내의 모든 구성 요소(EventBridge, Step Functions, Lambda) 전반에서 로그를 검색하고 상관관계 분석할 수 있어야 합니다. 가장 적은 운영 오버헤드로 이러한 요구 사항을 충족하려면 개발자는 무엇을 해야 합니까?

문제 분석

핵심 개념 - 이 문제는 최소한의 운영 오버헤드로 serverless/이벤트 기반 아키텍처에 대한 중앙 집중식 관측 가능성(observability)과 로그 분석을 테스트합니다. 핵심 서비스는 Amazon CloudWatch Logs(Lambda와 Step Functions의 기본 로그 저장소)와 CloudWatch Logs Insights(시간 범위 내에서 여러 log group에 걸친 임시 검색, 필터링, 집계, 상관관계 분석)입니다. 정답이 맞는 이유 - 요구 사항은 부하 테스트 중 발생하는 간헐적인 5xx 오류를 빠르게 특정하기 위해, 최근 24시간 동안 EventBridge, Step Functions, Lambda 전반의 로그를 검색하고 상관관계 분석할 수 있어야 하며, 설정과 유지 관리는 최소여야 합니다. Step Functions 실행 로깅을 CloudWatch Logs에 ALL 수준으로(선택적으로 실행 데이터 포함) 활성화하면 state 전환과 오류 컨텍스트에 대한 상세 정보를 제공합니다. Lambda는 기본적으로 CloudWatch Logs에 기록하므로, 구조화된 JSON 로깅을 사용하면 쿼리 가능성과 상관관계 분석이 향상됩니다. CloudWatch Logs Insights는 여러 log group을 한 번에 쿼리하고, request/order ID, 오류 코드, execution ARN으로 필터링하며, 어떤 Lambda invocation 또는 Step Functions state가 실패했는지 빠르게 식별할 수 있습니다. 주요 AWS 기능 - Step Functions는 CloudWatch Logs 통합을 지원하며 로그 수준(ERROR/ALL)과 실행 데이터 포함 여부를 구성할 수 있습니다(디버깅에 유용하지만 민감 데이터는 고려 필요). Lambda 로그는 함수별 log group으로 전송되며, JSON에 상관관계 식별자(예: orderId, eventId, executionArn)를 추가하면 Logs Insights 쿼리를 효율적으로 수행할 수 있습니다. CloudWatch Logs Insights는 log group 간 교차 쿼리, 시간 범위 제한 검색(예: 최근 24시간), 집계(함수/state별 오류 수)를 지원합니다. EventBridge의 경우 기본적으로 모든 이벤트를 “로깅”하지는 않지만, 규칙 metric과 DLQ를 통해 실패를 캡처할 수 있으며, 실제로는 Step Functions 시작과 이후 다운스트림 실패를 상관관계 분석하는 것만으로도 보통 실패 구성 요소를 격리하기에 충분합니다. 흔한 오해 - 많은 팀이 “검색”을 위해 OpenSearch 또는 ELK 스타일 파이프라인으로 바로 가지만, 이는 ingestion, indexing, scaling, 비용 관리를 추가로 요구합니다. CloudTrail도 애플리케이션 트러블슈팅 도구로 자주 오해되는데, CloudTrail은 데이터 플레인 이벤트별 처리 실패가 아니라 컨트롤 플레인 API 활동을 기록합니다. 시험 팁 - Lambda/Step Functions에 대해 최소 운영으로 로그 검색을 하려면 CloudWatch Logs + Logs Insights를 기본 선택으로 고려하십시오. 규모가 큰 장기 분석/검색 요구 사항이 명시되지 않는 한, 파이프라인(Firehose/OpenSearch) 구축보다 관리형 네이티브 통합을 선택하십시오. 또한 Step Functions 실행 로깅은 opt-in이며 분산 워크플로 디버깅 시 흔히 빠지는 요소라는 점을 기억하십시오.

문제 10

한 물류 회사는 Amazon API Gateway를 통해 단일 REST 엔드포인트 /shipments를 POST 메서드로 노출하고, 이는 CreateShipment라는 이름의 AWS Lambda 함수를 호출합니다. 개발자는 함수의 새로운 변경 불가능한(immutable) 버전 5를 게시했으며, 15분 동안 분당 최대 200개의 요청으로 통합 테스트를 실행해야 합니다. 현재 프로덕션 stage는 분당 약 3,000개의 요청을 처리하고 있으며, 테스트는 프로덕션 stage에 영향을 주면 안 됩니다. 운영 오버헤드를 최소화하면서, 개발자는 프로덕션에서 사용하기 전에 새 버전을 어떻게 테스트해야 합니까?

문제 분석

핵심 개념: 이 문제는 Lambda versions/aliases와 API Gateway stages/stage variables를 사용하여 Amazon API Gateway + AWS Lambda에 대한 안전한 배포 및 테스트 패턴을 평가합니다. 목표는 프로덕션 stage에 영향을 주지 않으면서 새로운 변경 불가능한 Lambda 버전에 대해 통합 테스트를 실행하는 것입니다. 정답이 맞는 이유: 별도의 API Gateway stage(예: “staging”)를 생성하면 동일한 REST API 구성(리소스, 메서드, auth, throttling, mapping templates)을 테스트하면서도, 백엔드 Lambda 대상은 다르게 지정할 수 있습니다. Lambda 통합 URI가 stage 변수(예: ${stageVariables.lambdaAlias})를 참조하도록 구성하면, staging stage는 Lambda 버전 5(또는 버전 5를 가리키는 alias)를 호출하고 prod stage는 현재 프로덕션 버전/alias를 계속 호출할 수 있습니다. 이렇게 하면 트래픽이 격리됩니다. 테스트는 staging invoke URL로 수행되므로 프로덕션 사용자와 metrics는 영향을 받지 않습니다. 주요 AWS 기능: 1) Lambda versions는 변경 불가능한 스냅샷이며, aliases는 안정적인 포인터(예: “prod”, “staging”)를 제공하고 이후 전환할 수 있습니다. 2) API Gateway stages는 서로 다른 invoke URL을 가진 별도의 배포 환경을 제공하며, stage variables, throttling, logging, canary 설정을 각각 다르게 가질 수 있습니다. 3) Stage variables는 통합 URI에서 사용되어 stage별로 Lambda alias/version을 동적으로 선택할 수 있으므로, 운영 오버헤드를 최소화하고 API 중복을 피할 수 있습니다. 흔한 오해: 프로덕션 통합을 일시적으로 버전 5로 업데이트하는 것이 가장 쉬워 보일 수 있지만, 이는 prod에 직접 영향을 줍니다. 또한 동일한 prod stage에 새 리소스를 추가하는 방식도 prod에 배포가 필요하고 위험을 초래할 수 있으며(그리고 throttling/usage plans를 공유할 수 있음), 전체적으로 테스트 트래픽을 깔끔하게 분리하지 못합니다. 완전히 새로운 REST API를 만드는 방법은 가능하지만 불필요한 오버헤드와 구성 드리프트를 유발합니다. 시험 팁: “프로덕션에 영향을 주지 않고 테스트” + “운영 오버헤드 최소” 조건에서는: 별도 stage + stage variables + Lambda alias/version 조합을 찾으십시오. 이는 프로덕션 적용 전 안전한 검증을 위한 표준 시험 패턴이며, blast radius를 줄이고 통제된 롤아웃을 가능하게 하여 Well-Architected 원칙(신뢰성 및 운영 우수성)에 부합합니다.

Practice Test #2

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(8)

다른 모의고사

Practice Test #1

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

지금 학습 시작하기