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

Practice Test #3

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

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

Lambda environment variables는 function configuration에 대해 정적이며, 이를 업데이트하려면 function configuration 업데이트가 필요합니다(대개 새 version publish/alias 업데이트와 함께 수행). CodeDeploy AllAtOnce는 canary의 반대이며 blast radius를 증가시킵니다. 또한 이는 config 변경을 Lambda deployment와 결합시키며, configuration-only 변경에 대해 20분 동안 10% 롤아웃을 통제된 방식으로 제공하지 못합니다.

CDK/CloudFormation으로 파라미터를 관리하고 변경마다 재배포하는 방식은 운영 파라미터 업데이트를 infrastructure deployment에 묶어버립니다. CodeDeployDefault.LambdaCanary10Percent15Minutes가 Lambda version 트래픽 shifting에 대한 canary를 제공하긴 하지만, 여전히 새 version publish와 alias 업데이트가 필요하므로 function 코드 재배포 없이 변경을 적용해야 한다는 요구 사항을 위반하며, 단순한 runtime 제한 값에 불필요한 deployment 복잡성을 추가합니다.

AWS AppConfig는 통제된 deployment로 동적 application configuration을 제공하도록 설계되었습니다. 제한 값을 hosted configuration으로 저장하고 AppConfig Lambda extension을 사용하면 function이 runtime에(로컬 caching 포함) 업데이트된 값을 읽을 수 있으며, 코드 재배포나 environment variables 변경이 필요 없습니다. AppConfig deployment strategies(예: Canary10Percent20Minutes)는 점진적 롤아웃을 제공하고, 이전 configuration version을 재배포하여 쉽게 rollback할 수 있습니다.

S3를 5분마다 polling하고 programmatically Lambda environment variables를 업데이트하는 방식은 지연, 복잡성, 그리고 실패 가능성(업데이트 누락, race condition)을 초래합니다. Environment variables 업데이트는 function configuration 변경을 트리거하며, 일반적으로 새 version/CodeDeploy 작업이 필요해 사실상 재배포 경로입니다. 또한 AppConfig deployment strategies에 필적하는, invocation 전반에 걸친 configuration 변경의 native하고 신뢰할 수 있는 canary 롤아웃을 제공하지 못합니다.

문제 분석

핵심 개념: 이 문제는 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
(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,' 오류가 표시되었는데, 이 실패를 설명할 수 있는 두 가지 이슈는 무엇인가?

정답. In-place 배포를 위해서는 대상 EC2 인스턴스마다 CodeDeploy agent가 설치되어 실행 중이어야 한다. 여러 인스턴스에서 agent가 중지되어 있거나 누락되어 있으면 해당 인스턴스는 lifecycle events를 실행하거나 성공/실패를 보고할 수 없다. CodeDeploy는 이를 failed로 표시하거나 상태를 기다리다 타임아웃 처리하며, healthy 인스턴스 수가 빠르게 감소해 minimum healthy hosts 임계값을 위반하면 HEALTH_CONSTRAINTS가 트리거된다.

오답. CloudWatch agent는 OS/애플리케이션 메트릭과 로그를 Amazon CloudWatch로 게시하는 데 사용된다. CodeDeploy는 배포를 수행하거나 배포 성공을 평가하기 위해 CloudWatch agent를 필요로 하지 않는다. CloudWatch는 롤아웃 중 로그/메트릭 확인 등 트러블슈팅에는 도움이 될 수 있지만, agent 부재가 직접적으로 HEALTH_CONSTRAINTS를 유발하지는 않는다.

오답. 개발자의 IAM user에 codedeploy:CreateDeployment가 없으면 배포는 시작조차 되지 않고 IAM에 의해 즉시 거부된다. 시나리오는 롤아웃이 시작된 뒤 6분에 health constraints로 중단되었다고 설명하므로, 호출자 권한 문제가 아니라 인스턴스 수준의 배포 실행/health 문제를 나타낸다.

정답. EC2 인스턴스에는 애플리케이션 revision을 가져오고(일반적으로 Amazon S3에서, 필요 시 KMS decrypt 포함) 필요한 방식으로 CodeDeploy와 상호작용할 수 있는 권한을 가진 IAM instance profile이 필요하다. 이러한 권한이 없으면 인스턴스는 DownloadBundle 또는 관련 단계에서 초기에 실패한다. 여러 인스턴스 실패로 healthy host 수가 95% 아래로 떨어지면 CodeDeploy는 HEALTH_CONSTRAINTS로 중단한다.

오답. 모든 deployment group에 대해 특별한 “CodeDeploy health checks” 기능을 반드시 활성화해야 한다는 보편적 요구사항은 없다. CodeDeploy의 health 동작은 deployment configuration(minimum healthy hosts, batch size)과 load balancer 및 alarms 같은 선택적 통합에 의해 결정된다. HEALTH_CONSTRAINTS는 일반적으로 실제 인스턴스 실패 또는 healthy 용량 부족 때문에 발생하며, 필수 기능 토글 누락 때문에 발생하는 것이 아니다.

문제 분석

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

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

정답입니다. MOCK 통합을 사용하는 API Gateway REST API는 어떤 백엔드도 호출하지 않고 응답을 반환할 수 있습니다. 200 및 404에 대한 메서드 응답을 정의하고 매핑 템플릿이 있는 통합 응답을 사용하면 개발자는 정적 JSON 본문을 생성하고 요청 파라미터에 따라 상태 코드를 선택할 수 있습니다. 스테이지에 배포하면 파트너를 위한 안정적인 엔드포인트가 제공되어 2주 일정에 맞추면서 컴퓨팅/VPC 비용을 피할 수 있습니다.

오답입니다. Lambda는 모의 JSON과 다양한 HTTP 상태 코드를 반환할 수 있지만, 컴퓨팅 비용(Lambda 호출), 운영 오버헤드(코드 패키징, IAM, 로깅), 그리고 나중에 잠재적인 VPC 구성까지 도입합니다. 요구사항은 “백엔드 통합 없음 및 컴퓨팅/VPC 비용 없음”을 명시하며, 이는 Lambda 프록시 통합보다 MOCK 통합이 더 직접적으로 충족합니다.

오답입니다. ALB 뒤의 EC2는 불필요한 인프라, 비용, 패치/유지보수, 확장 고려사항, 더 긴 설정 시간을 추가합니다. 컴퓨팅 비용이 없어야 한다는 요구사항을 위반하며, 최소 운영 부담으로 정적 응답을 빠르게 게시하려는 목표와도 맞지 않습니다. API Gateway는 서버를 구축하지 않고도 이를 네이티브로 수행할 수 있습니다.

오답입니다. HTTP_PROXY는 실제 업스트림 엔드포인트가 필요하며, 외부 모의 엔드포인트를 가리키는 것은 여전히 백엔드 의존성과 잠재적인 지연/가용성/보안 이슈를 만듭니다. 또한 “AWS Lambda layer를 API에 연결”하는 것은 유효한 API Gateway 구성 요소가 아닙니다—Lambda layer는 API Gateway에 직접이 아니라 Lambda 함수에 연결됩니다. 이 옵션은 호환되지 않는 개념을 섞고 있으며 백엔드 없음 요구사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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로 가도록 해야 한다. 회사는 무엇을 해야 하는가?

오답. Lambda authorizers는 인증/인가 결정을 제어할 뿐, API method integration이 호출하는 백엔드 Lambda alias를 선택하지 않는다. alias별로 별도의 authorizer를 만든다고 해서 메인 integration 트래픽이 서로 다른 Lambda version으로 라우팅되지는 않는다. Stage variables를 authorizer와 함께 사용할 수는 있지만, 이는 auth에만 영향을 주며 각 stage의 요청을 매칭되는 Lambda alias로 라우팅한다는 핵심 요구사항을 충족하지 못한다.

오답. API Gateway의 gateway responses는 오류(예: 4XX/5XX)에 대한 응답을 커스터마이즈하고 헤더나 템플릿을 추가하는 기능이다. 이는 integration 대상 선택이나 Lambda alias 라우팅에 영향을 주지 않는다. 서로 다른 alias에 대한 gateway response를 만든다는 개념은 유효하지 않으며, gateway responses는 Lambda aliases에 연결되지도 않고 PROD/DEV 버전을 별도로 접근 가능하게 만들지도 못한다.

오답. API Gateway는 Lambda처럼 “environment variables”를 제공하지 않는다. Stage별 구성 메커니즘은 stage variables이다. Lambda 함수 내부에서 Lambda environment variables를 사용할 수는 있지만, 이는 API Gateway가 alias를 선택하는 데 도움이 되지 않는다. 요구사항은 하나의 alias 내에서 동작을 바꾸는 것이 아니라, stage별로 서로 다른 Lambda versions/aliases로 라우팅하는 것이다.

정답. 새 API Gateway stage(dev)를 생성하고 stage variables(예: prod stage에서는 lambdaAlias=prod, dev stage에서는 lambdaAlias=dev)를 사용한다. Lambda integration ARN에서 stage variable을 참조하도록 하여 각 stage가 qualified Lambda alias ARN을 호출하게 한다. 이렇게 하면 하나의 API 정의를 유지하면서, 서로 구분되는 stage URL(/prod 및 /dev)을 제공하고, 각 stage의 트래픽 100%가 의도한 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
문제 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를 사용하여 파일을 암호화하고, 나중에 복호화할 수 있도록 해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

정답입니다. 이는 표준 KMS envelope encryption 워크플로입니다. GenerateDataKey가 반환한 plaintext data key를 사용하여 symmetric algorithm(예: AES-GCM)으로 파일을 로컬에서 암호화한 다음 plaintext key는 폐기합니다. 이후 디스크에 encrypted data key(CiphertextBlob)를 저장(대개 ciphertext와 함께 저장)하여, 나중에 KMS Decrypt를 호출해 plaintext key를 가져오고 파일을 복호화할 수 있습니다.

오답입니다. plaintext data key를 디스크에 저장하는 것은 보안상 안티패턴이며, KMS를 사용해 key material을 보호하려는 의도에 위배됩니다. 또한 encrypted data key(CiphertextBlob)는 데이터 암호화에 직접 사용되지 않으며, 먼저 KMS로 복호화하여 plaintext data key를 얻어야 합니다. 이 선택지는 두 출력의 역할을 반대로 이해하고 있습니다.

오답입니다. encrypted data key를 저장하는 부분은 맞지만, KMS Encrypt로 파일을 암호화하는 점이 잘못되었습니다. KMS Encrypt는 작은 페이로드를 위해 설계되었으며, 2–25 MB의 파일을 암호화하는 데 적합하지 않습니다. 올바른 접근은 plaintext data key로 파일을 로컬에서 암호화하고, KMS는 data key를 랩핑/언랩핑하는 데만 사용하는 것입니다.

오답입니다. plaintext data key를 저장하는 것은 안전하지 않으며, 또한 KMS Encrypt로 encrypted data key를 사용해 파일을 암호화하려는 시도는 개념적으로 잘못되었습니다. encrypted data key는 저장해 두었다가 나중에 KMS Decrypt로 복호화하는 용도이며, KMS Encrypt의 암호화 키로 사용하는 것이 아니고 plaintext key를 영구 저장해서도 안 됩니다.

문제 분석

핵심 개념: 이 문제는 GenerateDataKey API를 사용하는 AWS KMS의 envelope encryption을 테스트합니다. KMS customer managed key(CMK)는 큰 페이로드를 직접 암호화하는 데 사용되지 않습니다. 대신 KMS는 로컬 암호화를 위한 일회성 symmetric data key를 생성하고, KMS가 나중에 복호화할 수 있도록 해당 data key를 보호(랩핑)합니다. 정답이 맞는 이유: GenerateDataKey를 사용하면 KMS는 동일한 data key의 두 가지 버전을 반환합니다. 즉, 즉시 사용하기 위한 plaintext key와 지정된 symmetric CMK로 암호화된 encrypted key(CiphertextBlob)입니다. 올바른 패턴은 애플리케이션에서 plaintext data key를 symmetric algorithm(예: AES-GCM)과 함께 사용하여 2–25 MB 파일을 로컬에서 암호화한 다음, plaintext key는 메모리에서 폐기하는 것입니다. 그리고 encrypted data key(CiphertextBlob)를 암호화된 파일과 함께(예: metadata 또는 별도의 header로) 저장합니다. 사용자가 파일을 다운로드할 때는 저장된 CiphertextBlob에 대해 KMS Decrypt를 호출하여 plaintext data key를 복구하고 파일을 복호화합니다. 주요 AWS 기능: - envelope encryption을 위한 GenerateDataKey(Plaintext + CiphertextBlob 반환). - data key를 랩핑/언랩핑하기 위한 symmetric customer managed KMS key. - 나중에 data key를 복구하기 위한 KMS Decrypt. - 모범 사례: plaintext key를 영구 저장하지 말고, encrypted data key와 ciphertext만 저장. 일반적인 오해: 자주 있는 함정은 나중에 복호화를 위해 plaintext data key를 저장해야 한다고 생각하는 것입니다(보안상 안전하지 않으며 KMS 사용 목적을 무력화). 또 다른 오해는 KMS Encrypt로 파일 자체를 암호화하려는 것입니다. KMS Encrypt는 작은 데이터(KB 규모)를 대상으로 하며, 수 MB 객체에는 비효율적이고 비용이 많이 듭니다. 시험 팁: “GenerateDataKey”와 “encrypt files at rest”가 보이면 envelope encryption을 떠올리십시오. plaintext data key로 로컬에서 데이터를 암호화하고, encrypted data key(CiphertextBlob)를 저장한 뒤, 필요 시 KMS Decrypt를 사용합니다. 또한 KMS Encrypt/Decrypt는 작은 blob에 적합하며, 큰 파일은 data key로 client-side에서 암호화해야 한다는 점을 기억하십시오.

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

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

6
문제 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되어야 합니다. 개발 노력이 가장 적게 들면서 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

S3에 secrets를 저장하는 방식은(CMK로 암호화하더라도) best-practice secrets 솔루션이 아닙니다. secure retrieval, parsing, rotation semantics를 직접 구축해야 합니다. “S3 Object Lambda로 rotation”은 rotation 메커니즘이 아니며, retrieval 시 objects를 변환할 뿐 secret lifecycle, versioning, 또는 external systems와의 coordinated updates를 관리하지 않습니다. Secrets Manager에 비해 개발/운영 노력과 위험이 증가합니다.

Systems Manager Parameter Store SecureString은(KMS 포함) at rest 암호화를 제공하며, user data로 부팅 시 parameters를 가져올 수 있습니다. 그러나 rotation은 native managed capability가 아니므로 scheduled Lambda rotation을 구현하고, external systems(DB password/API key)을 업데이트하며, versioning을 처리하고, 안전한 cutover/rollback을 보장해야 합니다. 또한 default KMS key 사용은 정책상 CMK 요구 사항이 암시되어 있다면 이를 충족하지 못합니다.

Base64 encoding은 암호화가 아니므로 “encrypted at rest”를 충족하지 못합니다. configuration files(또는 AMIs)에 secrets를 embedding하는 것은 안전하지 않고, Auto Scaling fleet 전반에서 rotation하기 어렵고, instance나 artifact가 compromise될 경우 blast radius를 키웁니다. 매월 rotation을 위한 custom script는 개발 및 운영 노력이 크고, managed secret rotation services에 비해 오류가 발생하기 쉽습니다.

Secrets Manager는 애플리케이션 secrets를 저장하고, customer managed KMS key로 at rest에서 암호화하며, 일정(30일)에 따라 자동으로 rotation하도록 설계되었습니다. Auto Scaling group의 EC2 instances는 instance profile을 사용하여 부팅 시 여러 secrets를 조회하고 environment variables로 내보낼 수 있습니다. 이는 부팅 시 retrieval과(필요한 경우) non-AWS services를 위한 one-time rotation Lambda 정도만 커스텀하면 되므로 개발 노력을 최소화합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 7
(2개 선택)

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

정답입니다. X-Ray daemon(또는 agent)은 SDK로부터 UDP 포트 2000을 통해 segment/subsegment를 수신하기 위해 애플리케이션 가까이(일반적으로 각 EC2 인스턴스)에서 실행되어야 합니다. 그런 다음 daemon은 HTTPS(443)로 X-Ray service에 데이터를 전송합니다. private subnet에서는 NAT 또는 X-Ray API용 VPC endpoint를 통해 outbound 443을 보장하십시오. 이는 EC2 기반 tracing에 필요한 표준 구성 요소입니다.

오답입니다. TCP 2000을 통해 “global AWS X-Ray daemon”에 연결하지 않습니다. 포트 2000은 애플리케이션과 사용자가 실행하는 daemon 사이에서 로컬로(일반적으로 UDP) 사용됩니다. interface VPC endpoint는 X-Ray service API에 대한 private 연결에 사용할 수 있지만, 이는 managed daemon으로의 TCP 2000이 아니라 regional endpoint로의 HTTPS(443) 연결입니다.

오답입니다. CloudWatch Logs는 raw 애플리케이션 로그를 X-Ray로 직접 push하여 distributed trace를 생성하도록 구성할 수 없습니다. X-Ray trace는 요청 context와 타이밍 데이터를 캡처하는 SDK/agent에 의해 생성됩니다. 로그에 X-Ray trace ID를 기록하고 CloudWatch Logs Insights를 사용하는 등 trace ID로 로그를 연관 지을 수는 있지만, 로그 수집은 X-Ray instrumentation을 대체하지 못합니다.

정답입니다. AWS X-Ray SDK는 segment를 생성하고 서비스 경계를 넘어 trace context를 전파하기 위해 각 microservice에 추가되어야 합니다(incoming 요청, outgoing HTTP 호출, AWS SDK 호출, messaging). SDK instrumentation이 없으면 X-Ray는 단일 checkout 트랜잭션에 대한 end-to-end trace를 구성할 수 없고, 의존성과 지연/오류 핫스팟을 보여주는 service map도 얻을 수 없습니다.

오답입니다. CloudWatch metric streams는 metrics를(일반적으로 Kinesis Data Firehose 대상으로) 거의 실시간 분석을 위해 내보내는 기능이지, 요청별 tracing이 아닙니다. metrics는 집계되며 microservice 전반에서 개별 고객 checkout을 연관 지을 수 없습니다. 간헐적인 502 디버깅과 메시지 흐름 분석에는 metric streaming이 아니라 distributed tracing(X-Ray)과 trace ID가 포함된 structured logging이 적절한 도구입니다.

문제 분석

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

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

Step Functions는 900초 Wait를 구현할 수 있지만, 분당 2,000개 메시지에서 메시지당 execution을 시작하면 매우 높은 execution churn과 비용/제한 고려 사항이 발생합니다. 또한 EventBridge로 5분마다 호출하는 방식은 “각 메시지가 도착한 후 정확히 15분”을 보장하지 못합니다. 메시지가 orchestration을 위해 선택되기 전까지 최대 약 5분 정도 더 대기할 수 있기 때문입니다. 이는 native SQS delivery delay에 비해 불필요하게 복잡합니다.

Custom polling과 미래 timestamp로 메시지를 재게시하는 방식은 운영 부담이 크고 오류가 발생하기 쉽습니다. polling fleet/concurrency를 관리하고, clock/time 비교를 처리하며, 중복 및 message attribute 로직을 다뤄야 합니다. 또한 SQS 트래픽(receive + send again)을 증가시키고 실패 처리도 복잡하게 만듭니다. SQS가 이미 native로 delivery delay를 지원하는데 “가장 운영 효율적”이라는 목표에 어긋납니다.

정답입니다. DelaySeconds를 900으로 설정하면 각 메시지의 초기 visibility가 정확히 15분 지연되므로, Lambda(SQS event source mapping을 통해)는 지연이 만료될 때까지 메시지를 수신하고 처리할 수 없습니다. 이는 최소한의 코드와 운영으로 가능한 native managed capability이며, 피크 처리량에서도 SQS/Lambda와 함께 확장됩니다. 메시지 도착 후 대기해야 한다는 규정 준수 요구 사항과 직접적으로 일치합니다.

Visibility Timeout은 초기 처리를 지연시키지 않으며, 메시지가 수신된 이후에만 숨깁니다. Lambda event source mapping을 사용하면 Lambda는 메시지를 즉시 수신하고 function을 즉시 호출하므로, 메시지 도착 후 정확히 15분을 기다려야 한다는 요구 사항을 위반합니다. 900초 visibility timeout은 중복 없이 긴 처리를 허용하는 데는 유용하지만, scheduling/delay 메커니즘은 아닙니다.

문제 분석

핵심 개념: 이 문제는 운영 효율적인 방식으로 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
문제 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로 범위를 제한하면서 이러한 요구 사항을 가장 잘 충족하는 접근 방식은 무엇입니까?

틀렸습니다. Lambda@Edge function이 KMS와 같은 AWS service를 호출할 수는 있지만, edge에서 custom per-field encryption을 구축하는 것은 이 요구 사항에 대한 최선의 해결책이 아닙니다. JSON parsing, 필드 선택, encryption logic 처리, 그리고 모든 request에 대한 성능 관리까지 포함되어 불필요한 복잡성이 추가됩니다. CloudFront Field-Level Encryption은 선택된 request 필드를 암호화하도록 특별히 설계된 native 기능이므로, 이 시나리오에서는 더 나은 아키텍처 선택입니다.

오답입니다. AWS WAF는 일반적인 웹 공격으로부터 보호하고 request를 검사/허용/차단할 수 있지만 request field를 암호화하지는 않습니다. self-managed key를 사용하는 Lambda function으로 암호화/복호화를 수행하면 key 관리 오버헤드, rotation 어려움, 관리형 service 대비 더 높은 위험이 발생합니다. 또한 완전한 custom key distribution system을 구축하지 않는 한 “오직 하나의 microservice만 복호화”를 본질적으로 보장하지 못합니다.

정답입니다. CloudFront Field-Level Encryption은 request가 ALB에 도달하기 전에 RSA public key를 사용해 지정된 민감 JSON field만 암호화합니다. private key를 Secrets Manager에 저장하고 billing microservice의 IAM role만 접근하도록 제한하면 최소 권한을 강제하여 해당 component만 복호화할 수 있습니다. 이는 모든 transaction에서 암호화해야 한다는 요구 사항과 복호화를 단일 service로 범위 제한해야 한다는 요구 사항을 충족합니다.

오답입니다. HTTPS를 요구하고 signed URL/cookie를 사용하면 전송 구간 보안과 CloudFront content에 대한 접근 제어는 개선되지만, request payload 내의 특정 JSON field를 암호화하지는 않습니다. ALB/edge에서 복호화된 이후에는 ALB 뒤의 다른 service가 여전히 민감 field를 plaintext로 볼 수 있습니다. 따라서 “billing만 복호화” 요구 사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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일마다 자동으로 로테이션되기를 요구하며, 커스텀 코드를 최소화하고 향후 엔진도 지원하기를 원합니다. 다음 중 이러한 요구 사항을 가장 안전하게 충족하는 솔루션은 무엇입니까?

IAM database authentication은 일부 엔진(특히 Amazon RDS for MySQL 및 Amazon Redshift)에서 비밀번호 사용을 줄일 수 있지만, 나열된 모든 데이터베이스에 대한 범용 솔루션은 아닙니다. Amazon DocumentDB는 네이티브 MongoDB 스타일 사용자/비밀번호에 대해 동일한 방식으로 IAM database authentication을 사용하지 않으므로, 해당 자격 증명을 중앙에서 관리/로테이션할 수 없습니다. 또한 토큰 생성은 운영 부담을 클라이언트로 전가하며, 저장된 DB 사용자의 “30일마다 로테이션” 요구 사항을 충족하지 못합니다.

Systems Manager Parameter Store SecureString은 저장 시 KMS 암호화를 지원하지만, Secrets Manager에 필적하는 데이터베이스 자격 증명에 대한 내장형 엔드투엔드 자동 로테이션 메커니즘을 제공하지 않습니다. 실제 데이터베이스 사용자/비밀번호를 로테이션하고 파라미터를 업데이트하려면 커스텀 자동화(예: Lambda/Step Functions)를 구축 및 운영해야 합니다. 이는 “수동 단계 없음” 및 “커스텀 코드 최소화”에 위배되며, DB 자격 증명 로테이션에 목적 적합하게 설계된 서비스도 아닙니다.

S3에 자격 증명을 저장하는 방식은(SSE-KMS 및 퍼블릭 액세스 차단을 하더라도) 보안 또는 운영 측면에서 적절한 시크릿 관리 패턴이 아닙니다. S3는 네이티브 시크릿 로테이션, 로테이션 워크플로를 위한 버전 스테이징, 데이터베이스 자격 증명 업데이트와의 긴밀한 통합을 제공하지 않습니다. KMS 키 로테이션은 암호화 키 소재만 로테이션할 뿐 데이터베이스 비밀번호 자체를 변경하지 않습니다. 이 옵션은 30일 자동 자격 증명 로테이션 요구 사항을 충족하지 못하며, 우발적 노출 위험을 증가시킵니다.

AWS Secrets Manager는 AWS KMS로 암호화된 시크릿을 중앙에서 저장 및 관리하고, 스케줄(예: 30일) 기반으로 로테이션하도록 설계되었습니다. SecretsManagerRotationTemplate Lambda 블루프린트를 사용하면 표준 로테이션 라이프사이클(대기 시크릿 생성, DB에 설정, 테스트, 승격)을 구현하면서 커스텀 코드를 최소화할 수 있습니다. RDS for MySQL을 지원하며 Redshift 및 DocumentDB 자격 증명 로테이션 패턴에도 사용할 수 있고, 확장 가능하며 향후 엔진 지원 측면에서 가장 안전한 AWS 권장 접근 방식입니다.

문제 분석

핵심 개념: 이 문제는 중앙 집중식 시크릿 관리, 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 및 로테이션 템플릿에 대해 항상 엔진 호환성을 확인하십시오.

합격 후기(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 #4

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

Practice Test #5

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