연습 문제

문제 1

개발자가 Amazon API Gateway 뒤에서 AWS Lambda 기반의 serverless 이미지 처리 API를 구축하고 있습니다. 이 API는 조정 가능한 두 가지 runtime 파라미터—최대 병렬 변환 수(초기값 300)와 분당 처리 가능한 최대 이미지 수(초기값 900)—를 읽어야 하며, 운영팀이 이를 매주 업데이트할 수 있습니다. 또한 이러한 업데이트는 canary release(예: 20분 동안 10%)로 자동 롤아웃되어야 하고, 빠른 rollback을 허용해야 하며, function 코드를 재배포하거나 downtime을 유발하지 않고 모든 function 인스턴스에 걸쳐 적용되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 serverless 워크로드를 위한 동적 configuration 관리와, 코드 재배포 없이 configuration 변경을 안전하게 롤아웃/rollback하는 방법을 평가합니다. 핵심 서비스는 AWS AppConfig(AWS Systems Manager의 일부)와 AWS AppConfig Lambda extension입니다. 정답이 맞는 이유: 요구 사항은 두 개의 runtime 파라미터를 매주 업데이트하고, 이를 canary(20분 동안 10%)로 자동 롤아웃하며, 빠른 rollback을 지원하고, function 코드를 재배포하거나 downtime을 유발하지 않으면서 모든 Lambda 인스턴스에 변경이 적용되도록 하는 것입니다. AWS AppConfig는 이를 위해 설계된 서비스입니다. 제한 값을 hosted configuration으로 저장한 뒤 Canary10Percent20Minutes 같은 deployment strategy로 configuration 변경을 배포할 수 있습니다. AppConfig Lambda extension을 사용하면 function이 runtime에 configuration을 가져올 수 있으며(extension이 로컬에 캐시), 따라서 Lambda 코드 패키지를 변경하거나 새 version을 publish하거나 environment variables를 업데이트하지 않고도 업데이트가 전파됩니다. 주요 AWS 기능: 1) AWS AppConfig hosted configuration: 중앙 집중식, versioned configuration store. 2) Deployment strategies: bake time과 자동 진행을 포함한 내장 canary/linear strategy. 3) Rollback: Lambda deployment를 건드리지 않고도 이전의 known-good configuration version을 빠르게 재배포(또는 deployment 중지)할 수 있습니다. 4) Lambda extension caching: execution environment별로 configuration을 로컬에 캐시하면서도 정의된 interval로 refresh하여 latency와 throttling 위험을 줄입니다. 5) 코드와 config 분리: 통제된 변경을 가능하게 하고 blast radius를 줄여 AWS Well-Architected best practices(operational excellence 및 reliability)에 부합합니다. 흔한 오해: 많은 사람이 runtime 파라미터를 Lambda environment variables에 두는 것이 적절하다고 생각합니다. 하지만 environment variables 변경은 function configuration 업데이트가 필요하며, 이는 새로운 function version/config 업데이트를 유발하고, deployment 없이 invocation 전반에 걸쳐 “config만”을 native canary로 롤아웃하는 기능을 제공하지 않습니다. 또한 CDK/CloudFormation 재배포를 사용하면 config 변경이 infrastructure deployment와 결합되어 위험과 운영 오버헤드가 증가합니다. 시험 팁: “runtime parameters”, “frequent updates”, “no redeploy”, “canary/rollback”이 보이면 AWS AppConfig(또는 더 단순한 경우 Parameter Store/Secrets Manager)를 떠올리세요. 문제가 progressive rollout(10%/20분)과 빠른 rollback을 명시적으로 요구한다면, AppConfig deployment strategies가 가장 강력한 선택이며, 특히 Lambda에서는 AppConfig extension과 함께 사용할 때 최적입니다.

문제 2

(2개 선택)

한 물류 회사는 AWS CodeDeploy를 사용하여 Application Load Balancer 뒤에 있는 Auto Scaling group의 120개 Amazon EC2 인스턴스에 버전 2.3.7을 in-place 배포하고 있으며, MinimumHealthyHosts는 95%로 설정되어 있고 전체 배포 타임아웃은 15분이다. 6분에 중단된 롤아웃 동안 CodeDeploy 콘솔에는 'HEALTH_CONSTRAINTS: The overall deployment failed because too many individual instances failed or too few healthy instances were available,' 오류가 표시되었는데, 이 실패를 설명할 수 있는 두 가지 이슈는 무엇인가?

문제 분석

핵심 개념: 이 문제는 health constraints가 있는 AWS CodeDeploy in-place 배포를 테스트한다. Application Load Balancer(ALB) 뒤의 Auto Scaling group에서 CodeDeploy는 배포를 수행하는 동안 최소 비율의 인스턴스를 healthy 상태로 유지해야 한다. HEALTH_CONSTRAINTS 오류는 구성된 최소 healthy hosts를 유지할 수 없었거나 너무 많은 인스턴스가 배포 실패를 보고했기 때문에 CodeDeploy가 중단되었음을 의미한다. 정답이 맞는 이유: 120개 인스턴스에서 MinimumHealthyHosts가 95%로 설정되어 있으므로 CodeDeploy는 배포 중 최소 114개의 인스턴스를 healthy 상태로 유지해야 한다. 즉, 동시에 unhealthy/out of service/failed 상태가 될 수 있는 인스턴스는(배포 구성에서 health를 평가하는 방식에 따라) 최대 6개뿐이다. 의미 있는 수의 인스턴스에서 CodeDeploy agent가 실행 중이 아니면(A), 해당 인스턴스는 lifecycle hooks(예: DownloadBundle, Install, AfterInstall)를 실행할 수 없고 빠르게 failed로 표시되거나 성공 상태로 전환되지 못해 healthy 수가 임계값 아래로 떨어진다. 마찬가지로 EC2 인스턴스의 IAM instance profile에 필요한 권한이 없으면(D)—일반적으로 revision bundle에 대한 s3:GetObject, 암호화된 경우 KMS decrypt, 그리고 상태 통신을 위한 권한—인스턴스는 애플리케이션 revision을 가져오거나 진행 상황을 보고하려는 초기 단계에서 실패한다. 여러 인스턴스의 초기 실패는 95% healthy 제약을 빠르게 위반하여(관찰된 것처럼) 15분 전체 타임아웃보다 훨씬 이른 6분 내 중단을 유발할 수 있다. 주요 AWS 기능: CodeDeploy는 각 인스턴스의 CodeDeploy agent와 적절한 권한을 가진 instance profile에 의존한다. Health constraints는 deployment configuration(예: minimum healthy hosts)으로 강제되며, load balancer를 사용하는 경우 인스턴스 deregistration/registration을 조정하고 인스턴스 health를 관찰한다. In-place 배포는 인스턴스를 배치 단위로 업데이트하므로 특히 민감하며, 한 배치에서 너무 많은 실패가 발생하면 minimum healthy 임계값이 위반된다. 흔한 오해: CloudWatch agent(B)는 CodeDeploy가 배포를 수행하는 능력과 무관하다. 배포 생성 권한(C)은 배포 시작 자체를 막을 것이며, 중간에 HEALTH_CONSTRAINTS로 실패하게 만들지는 않는다. 모든 그룹에 대해 반드시 구성해야 하는 “전용 CodeDeploy health checks” 기능(E)은 존재하지 않으며, health constraints는 deployment config 및(선택적으로) load balancer 통합을 통해 구성된다. 시험 팁: HEALTH_CONSTRAINTS를 보면 “인스턴스 수준 실패가 너무 많거나 계속 진행하기에 healthy 용량이 부족하다”를 떠올려라. 즉시 CodeDeploy agent 상태, instance profile 권한, 그리고 fleet 크기 대비 minimum healthy host 비율을 확인하라. 95% 같은 높은 minimum healthy 비율은 대규모 fleet에서도 실패 허용 폭이 매우 작다.

문제 3

미디어 분석 스타트업은 파트너 팀이 지금 바로 통합할 수 있도록 2주 내에 Amazon API Gateway에서 7개의 엔드포인트를 가진 공개 REST API를 게시해야 합니다. 백엔드 마이크로서비스는 다음 스프린트까지 준비되지 않으며, 회사는 백엔드 통합 없이 컴퓨팅/VPC 비용도 발생하지 않도록 요청 파라미터에 따라 HTTP 200 또는 404를 반환하는 정적 JSON 페이로드(<=2 KB)를 반환해야 합니다. 개발자는 어떤 솔루션을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 MOCK 통합과 매핑 템플릿을 사용해 백엔드 없이 API를 게시하고 정적 응답을 생성하는 Amazon API Gateway의 기능을 테스트합니다. 또한 비용/운영 제약(컴퓨팅/VPC 없음)과 파트너 통합을 위한 신속한 제공도 다룹니다. 정답이 맞는 이유: 옵션 A는 통합 유형이 MOCK인 API Gateway REST API 리소스/메서드를 사용하며, 이를 통해 API Gateway는 어떤 백엔드 서비스도 호출하지 않고 응답을 반환할 수 있습니다. 메서드 응답(200 및 404 선언)과 통합 응답(매핑 템플릿으로 JSON 본문 생성 및 상태 코드 선택)을 구성하면 팀은 7개 엔드포인트를 빠르고 결정적으로 제공할 수 있습니다. 이는 모든 제약을 충족합니다: 정적 JSON 페이로드 <=2 KB, 요청 파라미터에 따른 조건부 200 vs 404, 백엔드 통합 없음, 컴퓨팅 또는 VPC 비용 없음. 주요 AWS 기능: - REST API(HTTP API가 아님)는 MOCK 통합을 지원합니다. - Method Request는 필수/선택 쿼리/경로 파라미터를 정의할 수 있습니다. - Integration Response 선택은 매핑 템플릿(Velocity Template Language) 및/또는 selection pattern으로 구동되어 서로 다른 상태 코드로 라우팅할 수 있습니다. - Method Response는 각 상태 코드와 응답 모델/헤더를 명시적으로 선언해야 합니다. - 스테이지(예: beta)와 배포는 파트너를 위한 안정적인 URL을 제공하며, stage variables는 버전 관리를 돕습니다. 흔한 오해: 많은 사람이 Lambda가 모의 구현에 가장 간단하다고 생각하지만, Lambda는 컴퓨팅 비용(Lambda 호출), 운영 오버헤드(코드 패키징, IAM, 로깅), 그리고(나중에 연결될 경우) 잠재적인 VPC 고려사항을 도입합니다. 또 다른 사람들은 외부 모의 엔드포인트로 HTTP 프록시하는 것이 “백엔드 없음”이라고 생각하지만, 이는 여전히 백엔드 의존성이며 네트워크 신뢰성/보안 우려를 추가합니다. EC2/ALB는 명백히 과도하며 컴퓨팅 비용 없음 요구사항을 위반합니다. 시험 팁: “백엔드 없음”, “정적 응답”, “API Gateway”가 보이면 MOCK 통합(REST API) + 매핑 템플릿 + 명시적 메서드/통합 응답을 떠올리십시오. 또한 API Gateway는 반환하려는 각 상태 코드에 대해 메서드 응답을 정의해야 하며, 그렇지 않으면 테스트 중 예기치 않은 기본 동작이 발생할 수 있음을 기억하십시오.

문제 4

한 스포츠 분석 스타트업이 Amazon API Gateway를 통해 예측 API를 노출하고 있으며, 이 API는 AWS Lambda 함수를 호출한다. 팀은 두 개의 Lambda 함수 버전을 유지한다: PROD용 version 18과 DEV용 version 17이며, alias는 prod -> v18, dev -> v17로 설정되어 있다. 현재 prod라는 단일 API Gateway stage가 있으며 prod alias로 라우팅한다. 회사는 API를 복제하지 않고, 동일한 API 아래에서 별도의 stage를 사용해 클라이언트가 PROD와 DEV Lambda 버전에 동시에 그리고 명확히 접근할 수 있어야 하며, 각 stage의 트래픽 100%가 해당 stage에 매칭되는 alias로 가도록 해야 한다. 회사는 무엇을 해야 하는가?

문제 분석

핵심 개념: 이 문제는 API Gateway의 stage 기반 배포와, API를 복제하지 않고 각 stage를 서로 다른 AWS Lambda alias/version으로 라우팅하는 방법을 테스트한다. 핵심 메커니즘은 API Gateway stage variables와 해당 변수를 참조할 수 있는 Lambda integration URI/ARN의 조합이다. 정답이 맞는 이유: 동일한 API에서 PROD와 DEV를 동시에 접근 가능하게 하려면 두 번째 API Gateway stage(dev)를 만들고, 각 stage가 서로 다른 Lambda alias(prod -> v18, dev -> v17)를 호출하도록 구성해야 한다. API Gateway stage variables는 단일 API 정의를 유지하면서 stage별 구성(예: 백엔드 엔드포인트, Lambda alias 또는 기타 파라미터)을 가능하게 하도록 설계되었다. 각 stage에 lambdaAlias 같은 stage variable을 정의하고 이를 integration ARN에서 참조하면, 각 stage는 의도한 alias로 트래픽 100%를 결정적으로 라우팅한다. 주요 AWS 기능: - Lambda versions 및 aliases: version은 불변(immutable)이며, alias는 version을 가리키는 안정적인 포인터로서 integration에서 “prod” vs “dev”를 참조하는 권장 방식이다. - API Gateway stages: 동일한 REST API 아래에서 분리된 배포 환경(예: /prod 및 /dev)이다. - Stage variables: stage 런타임에 사용 가능한 key/value 쌍으로, integration 엔드포인트를 파라미터화하는 데 흔히 사용된다. - Lambda integration ARN 형식은 alias qualification(끝이 :alias로 끝나는 function ARN)을 지원한다. alias 부분을 stage variable로 파라미터화하면 method/resource를 복제하지 않아도 된다. 흔한 오해: “API Gateway의 environment variables”를 언급하는 선택지는 틀리다. API Gateway에는 Lambda의 의미에서 environment variables가 없으며, 올바른 구성 요소는 stage variables이다. Gateway responses와 Lambda authorizers는 어떤 Lambda alias를 백엔드 integration이 호출할지 선택하는 것과 무관하다. 이들은 오류 처리와 요청 인증/인가를 다루며, 백엔드 라우팅을 다루지 않는다. 시험 팁: “같은 API, 여러 stage, 서로 다른 백엔드”를 보면 “API Gateway stage variables”를 떠올려라. “Lambda versions/aliases”를 보면 API Gateway가 qualified Lambda ARN(alias/version)을 호출할 수 있음을 기억하라. 이를 결합하면 API를 복제하거나 별도의 custom domain을 사용하지 않고(명시적으로 요구되지 않는 한) 깔끔한 멀티 환경 배포를 달성할 수 있다.

문제 5

한 미디어 스타트업이 서드파티 transcription API에서 원시 오디오 세그먼트를 가져와 이를 하나의 MP3 파일과 별도의 JSON transcript 아카이브로 컴파일하는 microservice를 구축하고 있습니다. 각 결과 파일의 크기는 2 MB에서 25 MB 사이일 수 있습니다. 이 서비스는 AWS Key Management Service (AWS KMS)에서 symmetric customer managed key를 사용하여 디스크에 저장된 상태(at rest)에서 이러한 파일을 암호화해야 하며, 사용자가 다운로드를 요청할 때 파일을 복호화해야 합니다. 가져오기 및 포맷팅 코드는 완료되었습니다. 개발자는 이제 GenerateDataKey API를 사용하여 파일을 암호화하고, 나중에 복호화할 수 있도록 해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

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

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

문제 6

한 차량 공유 회사가 Application Load Balancer 뒤에서 3개의 Availability Zone에 걸친 Auto Scaling group의 Amazon EC2 instances에서 실시간 가격 책정 서비스를 운영하고 있으며, 각 instance는 부팅 중에 여러 애플리케이션 secrets(예: third-party 결제 API key 및 database password)를 조회하여 environment variables로 내보내야 합니다. 또한 secrets는 at rest에서 암호화되어야 하고 30일마다 rotation되어야 합니다. 개발 노력이 가장 적게 들면서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 EC2 Auto Scaling에서 실행되는 애플리케이션을 위한 AWS-managed secret 저장 및 rotation을 테스트하며, at rest 암호화, 자동 rotation, 그리고 개발 노력 최소화에 초점을 둡니다. 주요 서비스는 AWS KMS를 사용한 암호화를 포함하여 secrets 용도로 설계된 AWS Secrets Manager입니다. 정답이 맞는 이유: Option D는 개발 노력이 가장 적으면서 모든 요구 사항을 가장 잘 충족합니다. 여러 secrets를 중앙에서 저장하고, customer managed KMS key(CMK)로 at rest에서 암호화하며, 30일 일정으로 내장된 automatic rotation을 활성화할 수 있습니다. EC2 instances는 부팅 중(user data를 통해) AWS SDK/CLI를 사용하여 secrets를 조회하고 environment variables로 내보낼 수 있습니다. 이는 secrets가 AMI나 config에 baked-in되면 안 되는, ephemeral하고 수평 확장되는 instances에 적합합니다. 주요 AWS 기능: 1) Secrets Manager의 KMS CMKs를 사용한 at rest 암호화, 그리고 IAM policies 및 KMS key policies를 통한 세분화된 access control. 2) Automatic rotation: Secrets Manager는 Lambda rotation functions와 통합되며 rotation schedules(예: 30일마다)를 지원합니다. 지원되는 engines(예: RDS)의 경우 AWS가 templates를 제공하며, third-party API keys의 경우 Lambda에서 rotation logic을 한 번 구현합니다. 3) Retrieval patterns: instances는 IAM role(instance profile)을 사용하여 부팅 시 GetSecretValue를 호출합니다. caching은 나중에 추가할 수 있지만(Secrets Manager caching library) 필수는 아닙니다. 4) 운영상의 이점: versioning/staging labels(AWSCURRENT/AWSPREVIOUS), CloudTrail을 통한 auditability, 그리고 중앙 집중식 관리. 일반적인 오해: Parameter Store SecureString은 암호화된 값을 저장할 수 있지만, rotation은 native managed feature가 아닙니다. rotation workflows를 직접 구축/유지하고 versioning/rollback을 스스로 처리해야 합니다. S3는 secrets manager가 아니며 불필요한 복잡성과 위험(배포, access patterns, rotation semantics)을 추가합니다. Base64 encoding은 암호화가 아니므로 보안 요구 사항을 충족하지 못합니다. 시험 팁: “secrets”, “rotation”, “least development effort”가 보이면, rotation이 명시적으로 필요 없거나 비용 제약이 지배적이지 않은 한 Parameter Store보다 Secrets Manager를 우선 고려하십시오. 또한 “default KMS key”와 “customer managed KMS key” 요구 사항의 차이를 유의하십시오. CMK 요구 사항은 일반적으로 Secrets Manager(또는 CMK를 사용하는 Parameter Store)를 가리키지만, rotation 요구 사항은 Secrets Manager 쪽으로 강하게 기웁니다. 참고: AWS Secrets Manager User Guide(rotation 및 encryption), AWS Well-Architected Framework Security Pillar(secrets를 중앙에서 관리, rotation 자동화, least privilege).

문제 7

(2개 선택)

한 음식 배달 스타트업은 두 개의 private subnet에 있는 24개의 Amazon EC2 인스턴스에서 Orders, Payments, Courier, Notifications의 네 가지 microservice를 실행하고 있습니다. 피크 트래픽(분당 약 1,500건 요청) 동안 팀은 로그 라인을 단일 고객 checkout에 연관 지을 수 없으며, 메시지 흐름을 분석하고 간헐적인 502 오류를 디버깅하기 위해 서비스 전반에 걸친 end-to-end request tracing이 필요합니다. 개발자가 microservice 전반에서 트랜잭션별 tracing을 활성화하기 위해 수행해야 하는 단계 조합은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념 - 이 문제는 AWS X-Ray를 사용한 microservice의 distributed tracing을 테스트합니다. X-Ray는 서비스 경계를 넘어 trace context를 전파하고 segment/subsegment를 수집하여 service map과 요청별 타임라인을 구성함으로써 end-to-end 가시성을 제공합니다. 정답인 이유 - EC2에서 호스팅되는 4개의 microservice에 대해 트랜잭션별 tracing을 얻으려면 (1) trace ID를 생성/전파하고 downstream 호출을 기록하는 애플리케이션 instrumentation과 (2) trace 데이터를 수신해 X-Ray service로 전달하는 로컬 X-Ray daemon/agent가 필요합니다. 옵션 D는 각 microservice에 AWS X-Ray SDK를 추가하고 inbound/outbound 요청을 instrument하여 단일 checkout 요청을 Orders, Payments, Courier, Notifications 전반에서 연관 지을 수 있게 합니다. 옵션 A는 각 EC2 인스턴스에 X-Ray daemon을 설치/실행하고, 애플리케이션에서 daemon으로 가는 표준 로컬 UDP 2000 경로와 daemon에서 X-Ray service로 가는 outbound HTTPS 443을 보장하는데, 이는 trace 제출에 필수입니다. 주요 AWS 기능 - X-Ray SDK는 일반적인 프레임워크(HTTP 서버/클라이언트, AWS SDK 호출)에 대한 자동 instrumentation과 커스텀 로직을 위한 수동 subsegment를 지원합니다. X-Ray daemon은 로컬에서 UDP 2000으로 수신하고, trace 데이터를 배치 처리하여 443에서 TLS로 regional X-Ray API endpoint로 전송합니다. private subnet에서는 outbound 연결을 NAT gateway/instance로 제공하거나, X-Ray API에 대해 AWS PrivateLink(interface VPC endpoint)를 사용할 수 있습니다(“global daemon”이 아님). IAM instance role에는 xray:PutTraceSegments 및 xray:PutTelemetryRecords 권한이 있어야 합니다. 흔한 오해 - CloudWatch Logs는 tracing을 만들기 위해 로그를 “X-Ray로 push”하지 않습니다. 로그와 trace는 상호 보완적이지만 서로 다른 telemetry 유형입니다. metric streams는 거의 실시간 metrics 내보내기를 제공할 뿐, 요청 수준의 correlation을 제공하지 않습니다. 또한 daemon은 TCP 2000으로 연결하는 managed global endpoint가 아니며, UDP 2000은 애플리케이션과 daemon 사이의 로컬 통신에 사용됩니다. 시험 팁 - EC2/ECS에서 X-Ray는 “SDK + daemon”을 떠올리십시오. 문제에서 단일 요청을 microservice 전반에서 연관 짓는다고 언급하면 trace header를 전파하고 outbound 호출을 instrument해야 합니다. 인스턴스가 private subnet에 있다면 daemon이 X-Ray service endpoint로 나갈 경로(NAT 또는 interface endpoint)와 instance role 권한을 기억하십시오.

문제 8

여행 예약 플랫폼이 취소 이벤트를 Amazon Simple Queue Service (Amazon SQS) standard queue에 넣고 있으며, 규정 준수를 위해 각 메시지가 도착한 후 AWS Lambda function을 호출하여 취소를 처리하기 전에 정확히 15분(900초)을 기다려야 합니다. 피크 부하가 분당 2,000개 메시지인 경우에도 마찬가지입니다. 가장 운영 효율적인 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 운영 효율적인 방식으로 SQS 메시지를 AWS Lambda로 처리하기 전에 메시지별로 고정된 지연을 구현하는 방법을 테스트합니다. 핵심 개념은 SQS delivery delay(DelaySeconds), SQS에 대한 Lambda event source mapping, 그리고 메시지 가용성을 지연시키는 것과 visibility timeout으로 in-flight 처리를 제어하는 것의 차이입니다. 정답이 맞는 이유: SQS queue의 DelaySeconds를 900(15분)으로 설정하면, 새로 전송된 모든 메시지는 큐에 적재된 후 정확히 900초가 지나기 전까지 소비자에게 보이거나 수신될 수 없습니다. 이후 큐에 대해 Lambda event source mapping을 구성하면, Lambda는 메시지가 visible 상태가 된 뒤에만 폴링 및 수신할 수 있으므로 Lambda invocation은 요구되는 15분 규정 준수 지연 이후에 자연스럽게 발생합니다. 이는 SQS와 Lambda polling이 수평 확장되므로 피크 부하(분당 2,000개 메시지)에도 자동으로 확장됩니다. batch size와 concurrency를 추가로 튜닝할 수 있지만, 지연 동작은 메시지별로 일관되게 유지됩니다. 주요 AWS 기능: - SQS DelaySeconds(queue-level default delay)는 새로 전송된 메시지의 delivery/visibility를 지연합니다. - SQS에 대한 Lambda event source mapping은 custom scheduler 없이 polling, batching, scaling을 처리합니다. - Standard queue는 높은 처리량을 지원합니다. ordering은 보장되지 않지만, 요구 사항은 ordering이 아니라 시간 기반 지연입니다. 흔한 오해: 자주 빠지는 함정은 DelaySeconds와 Visibility Timeout을 혼동하는 것입니다. Visibility Timeout은 메시지가 수신된 후(in-flight) 중복 처리를 방지하기 위해 메시지가 숨겨져 있는 시간을 제어하며, 초기 수신을 지연시키지 않습니다. 또 다른 오해는 지연을 구현하기 위해 Step Functions 또는 custom “requeue until time” 로직이 필요하다고 생각하는 것입니다. SQS는 이미 더 단순하고 운영 효율적인 native delivery delay를 제공합니다. 시험 팁: - 요구 사항이 “어떤 소비자도 메시지를 수신하기 전에 기다려야 한다”라면 SQS DelaySeconds(또는 per-message delay)를 떠올리십시오. - 요구 사항이 “처리 중인 메시지를 다른 소비자가 보지 못하게 해야 한다”라면 Visibility Timeout을 떠올리십시오. - 운영 효율성을 위해, 복잡한 orchestration이 필요하지 않다면 custom polling, scheduler, state machine보다 managed integration(Lambda event source mapping)을 선호하십시오.

문제 9

한 스타트업이 Application Load Balancer origin을 사용하는 Amazon CloudFront distribution 뒤에서 원격진료 API를 출시하고 있습니다. 각 viewer request에는 24개의 JSON field가 포함되어 있으며, 그중 8개는 민감 field(예: national ID, insurance number, 부분 결제 세부정보)로서 모든 transaction마다 반드시 암호화되어야 합니다. 또한 ALB 뒤의 billing microservice만 해당 특정 field를 복호화할 수 있어야 하며 다른 service는 복호화할 수 없어야 합니다. 그렇다면 복호화를 단일 component로 범위를 제한하면서 이러한 요구 사항을 가장 잘 충족하는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon CloudFront Field-Level Encryption (FLE)과 최소 권한 복호화 설계를 테스트합니다. FLE는 CloudFront edge에서 RSA public key를 사용해 viewer request의 선택된 민감한 필드만 암호화하도록 특별히 설계되었으므로, 해당 필드는 권한이 있는 origin 측 구성 요소가 일치하는 private key로 복호화할 때까지 읽을 수 없는 상태로 유지됩니다. 정답인 이유: 옵션 C가 가장 적합합니다. CloudFront FLE는 request를 ALB origin으로 전달하기 전에 8개의 민감한 JSON 필드와 같은 특정 request 필드를 암호화하는 기능을 기본적으로 지원합니다. 즉, 중간 구성 요소와 다른 backend service는 보호된 값을 읽을 수 없는 상태로 request를 처리할 수 있습니다. 해당 private key를 안전하게 저장하고 billing microservice의 IAM role에만 retrieval access를 부여하면, 복호화 범위가 정확히 하나의 구성 요소로 제한되어 최소 권한 요구 사항을 충족합니다. 주요 AWS 기능: - CloudFront Field-Level Encryption: 업로드된 RSA public key를 사용해 edge에서 선택된 request 필드를 암호화합니다. - Public/private key 분리: CloudFront는 암호화에 public key만 사용하며, private key 보유자만 복호화할 수 있습니다. - Secrets Manager + IAM: billing microservice 전용으로 private key를 안전하게 저장하고 retrieval를 엄격하게 제어합니다. - Defense in depth: TLS는 여전히 전송을 보호하고, FLE는 내부 홉 전반에 걸쳐 특정 application-layer 필드를 end-to-end로 보호합니다. 흔한 오해: A는 Lambda@Edge와 KMS를 사용한 custom encryption이 유연해 보이기 때문에 그럴듯해 보이지만, native CloudFront FLE와 비교하면 불필요하고 운영상 복잡합니다. B는 AWS WAF가 filtering 및 threat protection용이지 payload encryption용이 아니기 때문에 틀렸습니다. D는 transport security와 access control은 다루지만, 선택적 field encryption이나 하나의 backend service로만 복호화를 제한하는 요구 사항은 충족하지 못합니다. 시험 팁: 문제에서 CloudFront, 특정 request 필드만 암호화, 그리고 오직 하나의 backend 구성 요소만 이를 복호화할 수 있어야 한다는 내용이 언급되면, 가장 강력한 신호는 CloudFront Field-Level Encryption입니다. 문제가 FLE가 지원하지 않는 custom logic을 명시적으로 요구하지 않는 한, custom Lambda 기반 cryptography보다 관리형의 목적 특화 서비스를 우선 선택하세요.

문제 10

한 미디어 분석 회사는 us-east-1의 Amazon Redshift RA3 4xl 클러스터, Amazon RDS for MySQL 8.0 Multi-AZ DB 인스턴스, 그리고 4노드 Amazon DocumentDB (MongoDB compatibility) 클러스터에 대한 데이터베이스 연결 시크릿을 중앙에서 관리하고 보안 처리해야 합니다. 또한 보안 팀은 모든 데이터베이스 자격 증명이 AWS KMS로 저장 시 암호화되고, 수동 단계 없이 30일마다 자동으로 로테이션되기를 요구하며, 커스텀 코드를 최소화하고 향후 엔진도 지원하기를 원합니다. 다음 중 이러한 요구 사항을 가장 안전하게 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 중앙 집중식 시크릿 관리, AWS KMS를 사용한 저장 시 암호화, 그리고 여러 데이터베이스 엔진 전반에서의 자동 자격 증명 로테이션을 테스트합니다. 이를 위해 설계된 AWS 네이티브 서비스는 AWS Secrets Manager이며, KMS로 암호화된 시크릿을 저장하고 AWS Lambda를 통해 예약된 로테이션을 지원합니다. 정답인 이유: 옵션 D는 AWS Secrets Manager를 사용하여 Amazon Redshift, Amazon RDS for MySQL, Amazon DocumentDB의 자격 증명을 저장하고, 수동 단계 없이 30일마다 자동으로 로테이션합니다. Secrets Manager는 데이터베이스 자격 증명을 위해 목적에 맞게 설계되었습니다. KMS와 통합되어 저장 시 암호화를 제공하고, IAM 및 리소스 정책을 통한 세분화된 액세스 제어를 제공하며, 크로스 계정/중앙 거버넌스 패턴을 지원하고, 로테이션 스케줄링을 제공합니다. SecretsManagerRotationTemplate를 사용하면 AWS가 표준 로테이션 단계(새 시크릿 생성, DB에 설정, 테스트, 최종 반영)를 구현한 로테이션 블루프린트(AWS Lambda 템플릿)를 제공하므로 커스텀 코드를 최소화할 수 있습니다. 주요 AWS 기능: - 저장 시 KMS 암호화: 시크릿은 AWS KMS 키(AWS managed 또는 customer managed)로 암호화되어 “KMS로 저장 시 암호화” 요구 사항을 충족합니다. - 자동 로테이션: 네이티브 로테이션 스케줄(예: 30일마다)이 Lambda 로테이션 함수를 트리거합니다. - 엔진 지원 및 미래 대비: Secrets Manager는 다양한 엔진과 패턴을 지원하며, 일반적인 데이터베이스에 대한 로테이션 템플릿/솔루션이 존재하고 향후 엔진 추가 시 확장할 수 있습니다. - 운영 보안: 버저닝/스테이징 레이블(AWSCURRENT/AWSPENDING), CloudTrail을 통한 감사 가능성, 최소 권한 IAM 액세스. 흔한 오해: - “암호화하여 저장”과 “자동 로테이션”을 혼동: 많은 서비스가 값을 암호화할 수 있지만, Secrets Manager만이 데이터베이스 자격 증명을 엔드투엔드로 로테이션하도록 설계되었습니다. - IAM auth가 모든 곳에서 비밀번호를 대체한다고 가정: IAM database authentication은 나열된 모든 엔진에서 보편적으로 지원되지 않으며(특히 DocumentDB), 여전히 저장된 사용자 이름/비밀번호가 필요한 엔진에 대해 “자격 증명 로테이션” 요구 사항을 충족하지 못합니다. 시험 팁: “database credentials”, “automatic rotation”, “KMS encryption”, “minimize custom code”가 보이면 기본적으로 AWS Secrets Manager와 로테이션을 선택하십시오. Parameter Store SecureString은 구성/시크릿 저장용이지만 DB 자격 증명에 대한 네이티브 로테이션 워크플로가 부족합니다. S3는 시크릿 매니저가 아닙니다. IAM database authentication 및 로테이션 템플릿에 대해 항상 엔진 호환성을 확인하십시오.

Practice Test #3

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(8)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #4

Practice Test #5

Practice Test #6

지금 학습 시작하기