AWS Certified Developer - Associate (DVA-C02)

Practice Test #6

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

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

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 1

한 핀테크 스타트업은 Amazon S3 버킷(fintech-ui-prod)에서 단일 페이지 웹 앱(index.html, app.js, styles.css)을 제공하고 있으며, 기본 TTL이 86,400초(min TTL 0)인 Amazon CloudFront 배포 뒤에 있습니다. 또한 객체는 Cache-Control: max-age=86400 때문에 캐시됩니다. CI/CD 작업이 동일한 객체 키를 S3에서 덮어써서 build 2025.08.15를 배포한 후, 팀은 S3에서 새 아티팩트를 확인했지만 최종 사용자는 CloudFront를 통해 몇 시간 동안 여전히 이전 UI를 봅니다. 개발자는 CloudFront를 통해 업데이트된 자산이 즉시 전달되도록 어떻게 보장해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon S3 origin 앞의 Amazon CloudFront 캐싱 동작, 특히 TTL과 Cache-Control 헤더로 인해 origin 객체가 덮어써진 후에도 CloudFront edge location이 캐시된 객체를 계속 제공하는 상황을 테스트합니다. 정답이 맞는 이유: CloudFront는 cache key(일반적으로 경로 + behavior에 따라 query string/headers/cookies) 기준으로 edge location에 객체를 캐시하고, 만료(TTL)되거나 명시적으로 제거될 때까지 유지합니다. 여기서는 기본 TTL이 86,400초이고 객체에 Cache-Control: max-age=86400이 포함되어 있으므로, CloudFront가 최대 하루 동안 캐시된(이전) index.html/app.js/styles.css를 제공하는 것이 정상입니다. S3에서 동일한 키를 덮어써도 CloudFront 캐시가 자동으로 제거되지는 않습니다. 업데이트된 경로(예: /index.html, /app.js, /styles.css 또는 /*)에 대해 CloudFront invalidation을 생성하면 캐시된 객체가 강제로 제거되어, 다음 요청 시 CloudFront가 S3에서 즉시 새 버전을 가져오게 됩니다. 주요 AWS 기능 / 모범 사례: CloudFront invalidation은 TTL 만료 전에 캐시된 콘텐츠를 제거하는 표준 메커니즘입니다. SPA의 일반적인 배포 모범 사례는 “버전이 포함된 자산”(예: app.20250815.js)을 사용해 긴 TTL을 적용하고, index.html에는 더 짧은 TTL을 두는 것이지만, 이 문제는 동일 키를 덮어쓴 뒤 “즉시” 전달을 요구하므로 invalidation이 직접적인 해결책입니다. min TTL 0은 CloudFront가 더 낮은 TTL을 존중할 수 있게 하지만, 현재 Cache-Control이 여전히 1일 max-age를 설정하고 있습니다. 흔한 오해: 팀은 S3 객체를 업데이트하면 CloudFront도 자동으로 업데이트된다고 종종 가정하지만, 그렇지 않습니다—CloudFront는 별도의 캐시 계층입니다. 또 다른 오해는 이전 S3 버전을 삭제하거나 버킷 설정을 변경하면 CloudFront가 이미 캐시한 내용에 영향을 준다는 것인데, 캐시 항목이 만료되거나 invalidation되지 않는 한 그렇지 않습니다. 시험 팁: CloudFront + 긴 TTL/Cache-Control + “사용자가 몇 시간 동안 이전 콘텐츠를 받음” + “동일 객체 키 덮어쓰기”를 보면 시험 패턴은 (1) 경로 invalidation 또는 (2) 캐시 무효화를 위한 버전 파일명 사용입니다. 문제가 “즉시”를 요구하고 파일명 변경을 언급하지 않으면 invalidation을 선택하세요.

문제 2

한 미디어 분석 회사가 Application Load Balancer 뒤의 Auto Scaling group에 있는 Amazon EC2 인스턴스에서 Node.js API를 실행하고 있습니다. 트래픽은 야간에는 초당 1,000 요청에서 프로모션 기간에는 초당 12,000 요청까지 변동하며, 이로 인해 CPU 스파이크와 간헐적인 메모리 압박이 발생합니다. 엔지니어링 팀은 플릿을 적정 규모로 조정하기 위해 향후 2주 내에 인스턴스별 1분 단위 OS 수준 메트릭(메모리 사용률, swap 사용량, disk I/O, file system 사용률 포함)을 수집해야 합니다. 또한 팀은 큰 코드 변경 없이 서비스가 내보내는 cacheHitRate 및 queueDepth 같은 커스텀 애플리케이션 메트릭도 모니터링해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 EC2 기반 워크로드에 대한 Amazon CloudWatch 관측 가능성(observability)을 테스트합니다. 즉, 기본 EC2 메트릭을 넘어서는 OS 수준 메트릭을 수집하고, 큰 코드 변경 없이 커스텀 애플리케이션 메트릭을 수집하는 능력입니다. 정답이 맞는 이유: 기본적으로 EC2는 기본 CloudWatch 메트릭(CPUUtilization, NetworkIn/Out, 일부 인스턴스 타입/EBS에 대한 DiskRead/Write ops)을 게시하지만, 메모리 사용률, swap 사용량, file system 사용률, 또는 OS 수준의 상세 disk I/O는 게시하지 않습니다. Amazon CloudWatch agent는 인스턴스에서 실행되며 이러한 추가 시스템 수준 메트릭을 구성 가능한 간격(1분 포함)으로 CloudWatch에 푸시하도록 설계되었습니다. 또한 StatsD 및 collectd를 통해 커스텀 메트릭을 수집하는 것을 지원하므로, Node.js 서비스가 로컬 daemon/UDP 엔드포인트로 메트릭(예: cacheHitRate, queueDepth)을 내보내도록 하여 최소한의 또는 큰 변경 없는 코드 변경(대개 기존 메트릭 라이브러리의 구성만 변경)으로 구현할 수 있습니다. 주요 AWS 기능: CloudWatch agent는 메모리, swap, disk, filesystem을 위한 “metrics” 섹션을 지원하며 60초 수집으로 구성할 수 있습니다. user data, launch template, 또는 AWS Systems Manager를 사용해 Auto Scaling group 전반에 일관되게 배포할 수 있습니다. 커스텀 메트릭은 StatsD/collectd 통합을 통해 수집할 수 있어, 표준화된 메트릭 namespace, dimension(예: AutoScalingGroupName, InstanceId), 그리고 적정 규모 조정을 위한 CloudWatch Alarms/Dashboards를 사용할 수 있습니다. 흔한 오해: X-Ray는 분산 추적 및 요청 수준 성능 분석을 위한 것이지 OS 메트릭 수집을 위한 것이 아닙니다. CloudTrail은 API 감사(auditing)를 위한 것이지 성능 텔레메트리(telemetry)를 위한 것이 아닙니다. AWS SDK로 커스텀 코드를 작성하면 커스텀 메트릭을 게시할 수는 있지만, OS 수준 메모리/filesystem 메트릭 문제를 추가 호스트 계측 없이 해결하지 못하며, 2주라는 일정에서 불필요한 개발 노력과 리스크를 초래합니다. 시험 팁: EC2에서 메모리, swap, disk, filesystem 사용률 같은 요구 사항이 보이면 기대되는 답은 “CloudWatch agent”(또는 때로는 SSM + CloudWatch agent)입니다. 큰 코드 변경 없이 커스텀 메트릭이 필요하면 StatsD/collectd 지원 또는 embedded metric format 패턴을 찾고, 문제가 명시적으로 tracing 또는 auditing에 관한 것이 아니라면 X-Ray/CloudTrail은 피하십시오.

문제 3

원격의료 제공업체가 지연 시간에 민감한 예약 API를 AWS Elastic Beanstalk(Amazon Linux 2, Auto Scaling이 적용된 load balanced 환경)에서 호스팅하고 있습니다. 사용자에게 보이는 다운타임 없이 새 버전을 배포해야 하며, 승격 또는 롤백 전에 15분 평가 구간 동안 들어오는 요청의 정확히 25%를 새 버전으로, 75%를 현재 버전으로 라우팅해야 합니다. 이러한 요구 사항을 충족하는 Elastic Beanstalk 배포 정책은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 load-balanced, Auto Scaling 환경에서 제로 다운타임 릴리스와 함께 요청을 비율 기반으로 제어하여 전환(카나리 방식 평가)하는 AWS Elastic Beanstalk 배포 정책을 테스트합니다. 정답이 맞는 이유: Elastic Beanstalk의 traffic-splitting 배포 정책은 들어오는 요청의 정의된 비율을 새 애플리케이션 버전으로 라우팅하고, 나머지는 기존 버전으로 계속 보내도록 특별히 설계되었습니다. (여기서는 15분) 평가 기간을 지원하며, 이 기간 동안 메트릭(지연 시간, 5xx 오류, 커스텀 health check)을 모니터링한 뒤 새 버전을 100% 트래픽으로 승격하거나 롤백할 수 있습니다. 이는 두 가지 요구 사항을 모두 충족합니다: (1) 제로 사용자 가시 다운타임(두 버전이 load balancer 뒤에서 동시에 실행되기 때문) (2) 평가 구간 동안 정확한 25%/75% 트래픽 분배. 주요 AWS 기능 / 구성: Traffic-splitting 배포는 load-balanced Elastic Beanstalk 환경에서 동작하며 새 버전을 위한 병렬 인스턴스 세트를 생성합니다. 이후 환경의 load balancer가 구성된 비율에 따라 기존/신규 인스턴스 그룹 간 트래픽을 분할합니다. 평가 시간이 끝나면 Elastic Beanstalk가 배포를 완료(모든 트래픽 전환)할 수 있으며, 또는 중단/롤백할 수 있습니다. 이는 blast radius를 줄이고 더 안전한 릴리스를 가능하게 하여 Well-Architected의 reliability 및 operational excellence 원칙과도 부합합니다. 흔한 오해: 많은 수험자가 immutable 배포를 트래픽 시프팅과 혼동합니다. Immutable은 새 인스턴스를 띄운 뒤 교체하는 방식으로 더 안전한 배포를 제공하지만, 시간 제한이 있는 평가 구간 동안 정확히 25%/75% 요청 분할을 기본적으로 보장하지는 않습니다. Rolling과 in-place는 다운타임을 줄일 수는 있지만, 인스턴스를 순차적으로 또는 직접 업데이트하며, 정밀하게 제어된 카나리 트래픽 비율을 제공하지 않습니다. 시험 팁: “요청의 X%를 새 버전으로 라우팅” 및 “N분 동안 평가 후 승격/롤백”을 보면 canary/traffic shifting을 떠올리세요. Elastic Beanstalk에서는 키워드가 “traffic-splitting deployment”입니다. 반대로 “새 인스턴스를 먼저 띄운 다음 교체”를 강조하고 비율 라우팅이 없다면 immutable을 가리킵니다.

문제 4

개발자는 매일 두 번의 90분 시험 시간대 동안 동시 사용자 수가 5배 급증하는 상황에 대비하기 위해, 매우 중요한 온라인 시험 플랫폼을 AWS로 마이그레이션해야 합니다. 애플리케이션은 현재 온프레미스 서버 2대에서 실행 중입니다. 하나는 애플리케이션/API 서버이고, 다른 하나는 MySQL 데이터베이스 서버입니다. 애플리케이션 서버는 페이지를 렌더링하고 사용자 세션 객체를 프로세스 메모리에 저장합니다. 피크 시점(약 15,000명의 동시 사용자)에는 애플리케이션 서버의 16 GB RAM이 95% 사용률에 도달하고, 중앙값 응답 시간이 120 ms에서 1,200 ms 이상으로 증가합니다. 프로파일링 결과, 메모리 증가와 성능 저하의 대부분이 추가 사용자 세션을 관리하는 데서 발생하는 것으로 나타났습니다. 마이그레이션을 위해 개발자는 두 개의 Availability Zone에 걸쳐 Application Load Balancer 뒤의 Auto Scaling group에서 Amazon EC2 인스턴스를 사용할 예정입니다. 애플리케이션의 성능과 확장성을 개선하기 위해 개발자가 구현해야 할 추가 변경 사항의 조합은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 서버 로컬 세션 상태(“sticky state”)를 제거하고 캐시 및 데이터베이스에 관리형 서비스를 사용함으로써 수평 확장성과 성능 최적화를 평가합니다. 애플리케이션이 Application Load Balancer (ALB) 뒤에 배치되고 Auto Scaling group (ASG)으로 확장될 때, 세션을 프로세스 메모리에 저장하면 어떤 인스턴스든 어떤 요청이든 받을 수 있기 때문에 효과적인 확장이 불가능해집니다. 정답이 맞는 이유: 병목은 피크 동시성에서 세션 관리가 RAM을 소모하고 지연 시간을 증가시키는 것입니다. 세션을 애플리케이션 프로세스 밖의 공유되는 저지연 인메모리 저장소로 이동하면 EC2 인스턴스가 stateless로 유지되어 깔끔하게 scale out할 수 있습니다. Amazon ElastiCache for Memcached는 일시적(ephemeral)이며 고처리량 캐싱과 세션 저장을 위해 설계되었습니다. 한편 애플리케이션 데이터는 내구성 있게 관리형 관계형 데이터베이스에 저장해야 하며, Amazon RDS for MySQL은 EC2에서 자체 관리하는 MySQL에 비해 Multi-AZ 가용성, 자동 백업, 패치, 예측 가능한 성능을 제공합니다. 주요 AWS 기능: - ElastiCache for Memcached: sub-millisecond 지연 시간, 노드 추가를 통한 수평 확장, 세션에 이상적인 단순 key/value 접근 패턴, 인스턴스별 메모리 압박 회피. - RDS for MySQL: 자동 백업, 유지보수, 모니터링, 고가용성을 위한 Multi-AZ failover를 제공하는 관리형 MySQL. - 두 AZ에 걸친 ALB + ASG: stateless 애플리케이션 계층에서 가장 잘 동작하며, 세션 외부화는 표준 요구 사항입니다. 흔한 오해: - “세션을 MySQL에 넣기”는 단순해 보이지만, 변경이 잦고 QPS가 높은 워크로드를 관계형 데이터베이스로 옮겨 경합과 지연 시간을 증가시킬 수 있습니다. - “모든 것을 캐시에 저장”은 애플리케이션 데이터의 내구성과 일관성 요구 사항을 무시합니다. - “instance store 사용”은 빠르지만 인스턴스 간 공유되지 않고 stop/terminate 시 삭제되므로, 확장되고 로드 밸런싱되는 플릿에서 세션에 부적합합니다. 시험 팁: ALB + Auto Scaling과 함께 인메모리 세션이 메모리 압박을 유발하는 상황을 보면, 기대되는 해결책은 ElastiCache (Memcached/Redis)로 세션을 외부화하여 애플리케이션을 stateless로 만드는 것입니다. 내구성이 필요한 관계형 데이터에는 RDS(또는 Aurora)를 사용합니다. 특히 매우 중요하고 스파이크가 큰 워크로드에서는 HA와 운영 단순성을 위해 관리형 서비스를 선호합니다.

문제 5

헬스 분석 플랫폼은 파트너 웨어러블 디바이스에서 운동 세션 이벤트를 수집하기 위해 Amazon API Gateway HTTP API를 노출합니다. 이 API는 이벤트를 Amazon DynamoDB 테이블에 저장하는 AWS Lambda 함수를 호출합니다. 회사는 90일 이내에 15개의 추가 디바이스 파트너를 온보딩할 계획이며, 일부 파트너는 이벤트를 수신하기 위해 전용 Lambda 함수가 필요합니다. 회사는 us-east-1에 object versioning이 활성화된 athlete-events-archive라는 Amazon S3 bucket을 생성했으며, 향후 분석을 위해 모든 세션 레코드와 모든 업데이트를 이 bucket에 최소한의 개발 노력으로 영구 저장해야 합니다. 모든 이벤트와 업데이트가 최소한의 개발 작업으로 Amazon S3에 저장되도록 보장하기 위해 개발자는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 최소한의 애플리케이션 변경으로 AWS에서 이벤트 영구 저장과 change data capture (CDC) 패턴을 테스트합니다. 핵심 서비스는 Amazon DynamoDB Streams(삽입/업데이트 캡처)와 AWS Lambda(stream 레코드 처리)이며, 이를 통해 데이터를 Amazon S3로 아카이빙합니다. 정답이 맞는 이유: 시스템은 이미 모든 운동 세션 이벤트를 DynamoDB 테이블에 기록하고 있습니다. 요구사항은 15개 이상의 파트너가 추가되고 파트너별로 더 많은 ingest Lambda 함수가 생기더라도, 최소한의 개발 노력으로 모든 세션 레코드와 모든 업데이트를(버저닝이 활성화된) S3 bucket에 영구 저장하는 것입니다. DynamoDB Streams를 활성화하면 어떤 Lambda 함수(또는 파트너 전용 함수)가 write를 수행했는지와 무관하게 모든 item 수준 변경(INSERT, MODIFY, REMOVE)을 캡처합니다. 그런 다음 단일 stream 처리 Lambda가 각 stream 레코드를 변환하여 athlete-events-archive S3 bucket에 쓸 수 있습니다. 이는 ingest와 아카이빙을 분리하고, 현재/미래의 모든 ingest Lambda를 수정할 필요를 없앱니다. 주요 AWS 기능: DynamoDB Streams는 partition key별로 정렬된, 시간 순서의 item 변경 시퀀스를 제공하며, 업데이트 전/후의 전체 item 상태를 캡처하기 위해 NEW_IMAGE 및/또는 OLD_IMAGE를 포함할 수 있습니다. Lambda event source mapping은 polling, batching, retries, scaling을 처리합니다. S3 versioning은 업데이트가 발생할 때 아카이브된 object의 여러 버전을 유지함으로써 이를 보완합니다. 일반적인 구현은 변경 이벤트당 object 1개를 쓰거나(예: date/partner/table/PK로 prefix), “latest” key를 유지하면서 S3 versions에 의존하는 방식입니다. 흔한 오해: ingest Lambda에서 SNS 또는 Kinesis로 publish하는 것이 더 단순해 보일 수 있지만, 이는 각 ingest 함수(및 향후 파트너 함수)를 변경해야 하므로 개발 및 운영 오버헤드가 증가합니다. 또한 Kinesis-to-S3는 일반적으로 Kinesis Data Firehose가 필요하며(Data Streams만으로는 아님), SNS는 database에서의 durable replay/CDC 용도로 설계되지 않았습니다. 시험 팁: DynamoDB에서 “모든 레코드와 업데이트를 저장”하면서 코드 변경을 최소화하라는 요구가 보이면 DynamoDB Streams + Lambda를 떠올리십시오. “S3로 아카이브” 요구가 있으면 Streams는 전형적인 CDC 트리거입니다. 기억할 점: Data Streams는 추가 구성요소(대개 Firehose) 없이 S3에 네이티브로 쓰지 못하며, producer에서 이벤트를 푸시하는 방식은 producer가 늘어날수록 결합도와 유지보수 부담이 커집니다.

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

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

문제 7

한 리테일 분석 팀이 매일 밤 실행되던 Node.js 작업을 AWS Lambda 함수로 rehost했으며, 이 함수는 파트너의 인보이싱 REST API에 순차적으로 호출을 수행하여 지난달 데이터를 가져온 다음 청구 요약을 생성합니다. 파트너는 분당 75개 요청 및 하루 8,000개 요청이라는 엄격한 rate limit을 도입했으며, 둘 중 하나라도 초과하면 HTTP 429를 반환하고 응답 헤더에는 분당 및 일일 quota가 포함됩니다. 월간 pull에는 이제 약 11,500번의 API 호출이 필요하며 둘째 날로 넘어갈 수 있습니다. 이러한 제한을 준수하도록 serverless 설계를 리팩터링하는 가장 운영 효율적인 방법은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 엄격한 rate limit를 적용하는 외부 API에 대해 많은 양의 작업을 처리할 때, 운영 효율성이 가장 높은 serverless 패턴을 선택하는 것에 관한 것입니다. 가장 좋은 설계는 작업 생성과 작업 실행을 분리하여 요청을 시간에 걸쳐 분산할 수 있게 하고, 일일 quota에 도달했을 때도 다음 날까지 안전하게 계속할 수 있도록 하는 것입니다. 정답인 이유: Amazon SQS는 개별 API 작업 항목에 대해 내구성 있는 buffering을 제공하므로, 워크로드를 하나의 긴 Lambda 실행에서 처리하는 대신 점진적으로 처리할 수 있어 가장 적합합니다. 그런 다음 Lambda consumer를 낮은 concurrency와 작은 batch로 구성할 수 있으며, 애플리케이션은 partner의 quota header를 기반으로 간단한 pacing 또는 pause/resume 동작을 추가하여 시스템이 분당 및 일별 limit를 모두 준수하도록 할 수 있습니다. 이는 실패를 중심으로 reactive orchestration을 구축하는 것보다 운영 측면에서 더 효율적입니다. 주요 기능: SQS는 작업이 둘째 날까지 넘어가야 할 때 내구성 있는 queueing과 자연스러운 backlog 처리를 제공합니다. Lambda event source mapping, reserved concurrency, 그리고 작은 batch size는 병렬성을 제한하는 데 도움이 되며, consumption의 예약된 enable/disable 또는 가벼운 quota tracking은 일일 cap을 강제할 수 있습니다. 이 패턴은 복원력이 높고 확장 가능하며, 일반적인 AWS serverless integration 설계와도 잘 맞습니다. 흔한 오해: HTTP 429를 받은 후 Step Functions Wait state를 사용하는 것은 reactive 방식이며, 이는 시스템이 이미 partner의 limit를 위반했다는 뜻입니다. CloudWatch alarm은 진행 중인 Lambda 작업을 중지하기 위한 정밀한 runtime throttling 메커니즘이 아닙니다. Kinesis Data Firehose는 데이터 전달 파이프라인용이지, 제어된 outbound API 호출용이 아닙니다. 시험 팁: 외부 종속성에 엄격한 quota가 있고 워크로드가 여러 날에 걸쳐 이어질 수 있다면, 작업을 buffering하고 consumer가 제어된 속도로 처리하도록 하는 queue 기반 설계를 우선 고려하세요. AWS 시험에서는 정확한 quota 준수를 위해 일부 가벼운 애플리케이션 로직이 여전히 필요하더라도, 작업을 평준화하고 지연 처리하는 데 SQS와 Lambda 조합이 보통 가장 운영 효율적인 정답입니다.

문제 8

개발자가 Amazon DynamoDB Streams에 의해 트리거되는 AWS Lambda 함수를 가지고 있으며, 코드에 자격 증명을 지정하지 않고 AWS SDK Publish API를 사용해 동일한 계정과 Region의 Amazon SNS topic에 분당 약 200개의 감사 메시지를 게시해야 합니다. 그러나 배포 후 모든 게시 시도가 실패하고 CloudWatch Logs에 sns:Publish에 대한 AccessDeniedException(HTTP 403)이 표시됩니다. 개발자는 이 문제를 어떻게 해결해야 합니까?

문제 분석

핵심 개념: 이 문제는 코드에 자격 증명을 포함하지 않고 AWS SDK로 다른 AWS 서비스(Amazon SNS)를 호출할 때 AWS Lambda의 AWS IAM 권한 부여를 테스트합니다. Lambda에서는 SDK가 함수의 execution role(Lambda 서비스가 assume하는 IAM role)에서 임시 자격 증명을 자동으로 가져옵니다. 정답이 맞는 이유: SNS:Publish에 대한 AccessDeniedException(HTTP 403)은 호출자 ID(Lambda execution role session)가 인증되었지만 SNS topic에 대해 sns:Publish를 수행할 권한이 없음을 의미합니다. 코드에 자격 증명을 지정하지 않았으므로, 사용되는 ID는 Lambda execution role뿐입니다. 따라서 해결 방법은 Lambda execution role의 identity-based policy를 업데이트하여 특정 topic ARN에 대해 sns:Publish를 허용(최소 권한)하는 것입니다. 이를 추가하면 코드 변경 없이 SDK 호출이 성공합니다. 주요 AWS 기능: - Lambda execution role: AWS STS를 통해 임시 자격 증명을 제공하며, SDK가 이를 자동으로 사용합니다. - IAM identity-based policies: role에 권한을 부여합니다(예: Action: sns:Publish, Resource: topic ARN). - 최소 권한: “*” 대신 단일 topic으로 권한 범위를 제한합니다. - DynamoDB Streams trigger는 SNS 권한 부여와 무관하며, event source mapping과 stream 읽기에 필요한 권한만 정의합니다. 흔한 오해: - 네트워킹 vs 권한: VPC endpoint(옵션 A)는 VPC 내부에서 SNS로의 연결성을 다루지만, 403 AccessDenied는 네트워크 실패가 아니라 권한 부여 실패입니다. 네트워크 문제는 보통 timeout, DNS 오류, 연결 실패로 나타납니다. - “개발자 credentials 추가”(옵션 B): Lambda는 장기 개발자 자격 증명에 의존하면 안 되며, best practice는 execution role을 사용하는 것입니다. 또한 오류는 개발자 머신이 아니라 AWS의 런타임에서 발생합니다. - Lambda에 대한 resource-based policy(옵션 D): Lambda resource policy는 함수 호출(또는 function URL 접근)을 누가/무엇이 할 수 있는지 제어하며, 함수가 호출할 수 있는 대상 서비스 권한을 부여하지 않습니다. 아웃바운드 권한은 execution role이 제어합니다. 시험 팁: Lambda에서 AWS SDK 호출이 AccessDenied로 실패하면 먼저 principal을 식별해야 하며, 거의 항상 Lambda execution role입니다. 그다음 role에 대한 identity-based policy가 필요한지(가장 일반적) 또는 대상 서비스에 대한 resource-based policy가 필요한지(교차 계정 액세스 또는 이를 지원하는 특정 서비스에서 사용)를 판단합니다. 403은 VPC 라우팅이 아니라 IAM 권한 부여와 매칭됩니다.

문제 9

(2개 선택)

한 비영리 조직이 향후 4개월 동안 사용할 임시 자원봉사자 신청 마이크로사이트를 출시하며, 최대 10,000건의 제출을 예상하고 있습니다. 이 사이트는 HTTPS POST /signup 요청을 수락하고 제출된 휴대폰 번호를 VolunteerContacts라는 이름의 Amazon DynamoDB 테이블에 저장해야 합니다. 개발자는 데이터를 DynamoDB에 쓰는 AWS Lambda 함수를 구현했으며 AWS Serverless Application Model (AWS SAM)로 배포할 예정입니다. 개발자는 추가 구성이 최소가 되도록 이 Lambda 함수를 HTTP로 노출해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 서버리스 아키텍처에서 HTTP POST 엔드포인트를 위해 AWS Lambda 함수를 HTTPS로 노출하는 가장 단순한 방법을(특히 AWS SAM으로 배포할 때) 평가합니다. 핵심 서비스는 Lambda Function URLs와 Amazon API Gateway이며, 둘 다 최소한의 인프라로 Lambda 앞단에 배치할 수 있습니다. 정답이 맞는 이유: A (Lambda function URLs)는 Lambda 함수에 HTTPS 엔드포인트를 직접 연결합니다. 구성이 매우 적게 필요하며(별도의 API 서비스 불필요), POST 요청을 지원하고, 가볍고 임시적인 마이크로사이트에 적합합니다. IAM auth 또는 no auth를 사용할 수 있고, 리소스 기반 정책과 선택적 CORS 설정으로 추가 보호가 가능합니다. E (Amazon API Gateway)는 Lambda를 HTTP/HTTPS로 노출하는 전형적인 완전관리형 방식입니다. SAM을 사용하면 템플릿에서 API 이벤트 소스를 정의해 빠르게 배포할 수 있습니다. API Gateway는 강력한 요청 처리, throttling, validation, custom domain, WAF 통합, 상세 metrics를 제공하므로 임시 사이트에도 유용할 수 있습니다. 주요 AWS 기능: Lambda Function URLs: 내장 HTTPS 엔드포인트, 단순한 구성, (일부 모드에서) streaming responses 지원, CloudWatch logs/metrics와 통합, IAM/리소스 정책으로 제한 가능. API Gateway: REST API 또는 HTTP API. HTTP API는 보통 단순한 Lambda 프록시와 더 낮은 비용/지연을 위해 API Gateway 내에서 “추가 구성이 가장 적은” 변형입니다. 둘 다 TLS, stages, throttling을 지원하며 추가 보호를 위해 AWS WAF와 통합할 수 있습니다. DynamoDB 쓰기의 경우, Lambda 실행 역할은 VolunteerContacts 테이블에 대해 dynamodb:PutItem(또는 관련 쓰기 작업)을 허용해야 합니다. 흔한 오해: Load balancers (NLB/GWLB)와 Global Accelerator는 “앞단에 HTTPS를 붙이는” 일반적인 방법으로 오해되곤 하지만, Lambda에 대해 가장 단순하거나 직접적인 방식은 아닙니다. NLB는 Lambda와 통합할 수 있지만 주로 TCP/UDP/TLS 패스스루 패턴을 위한 것이며 HTTP API 관리 계층이 아닙니다. GWLB는 네트워크 어플라이언스를 삽입하기 위한 것이지 애플리케이션 엔드포인트를 노출하기 위한 것이 아닙니다. Global Accelerator는 기존 엔드포인트로의 글로벌 라우팅을 개선할 뿐, Lambda를 위한 HTTP 엔드포인트를 자체적으로 생성하지 않습니다. 시험 팁: “추가 구성이 최소가 되도록 Lambda를 HTTP/HTTPS로 노출”이라는 문구가 보이면, 먼저 Lambda Function URLs와 API Gateway(대개 HTTP API)를 떠올리십시오. API 관리 기능이 필요하면 API Gateway를, 가장 단순한 직접 HTTPS 엔드포인트가 필요하면 Function URLs를 선택하십시오. 질문에서 그런 요구가 명시되지 않는 한 네트워킹 가속기나 어플라이언스 삽입 도구 옵션은 제외하십시오.

문제 10

의료 영상 분석 스타트업이 압축된 DICOM 스터디 아카이브를 처리하고 파싱 후 폐기합니다. 아카이브는 Amazon S3 bucket에 저장되며 평균 1.3 GB이고, 1.9 GB를 초과하는 것은 없습니다. AWS Lambda function은 아카이브당 1회 호출되며, 파싱은 I/O bound 성격이 매우 강하고 동일한 파일을 3~5회 전체 읽기해야 합니다. 가장 성능 최적화된 접근 방식을 제공하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon S3에서 동일한 대용량 object를 반복해서 읽는 I/O bound workload에 대해 AWS Lambda 성능 최적화를 테스트합니다. 핵심은 Lambda의 구성 가능한 ephemeral storage(/tmp)를 사용해 데이터를 로컬에 스테이징하여 반복되는 network I/O를 최소화하는 것입니다. 정답이 맞는 이유: 파서가 동일한 1.3~1.9 GB 아카이브를 3~5회 전체 읽기하므로, S3에서 반복적으로 스트리밍하면 여러 번의 network 전송, 더 높은 latency, 그리고 변동적인 throughput이 발생합니다. 가장 성능 최적화된 접근은 아카이브를 한 번 로컬 storage로 다운로드한 뒤 이후의 모든 읽기를 로컬 disk에서 수행하는 것입니다. AWS Lambda는 ephemeral storage를 최대 10,240 MB까지 늘릴 수 있으므로, 2 GB(최대 1.9 GB보다 약간 큰 값)로 설정하면 function이 아카이브를 /tmp로 복사한 다음 로컬 속도로 여러 번 읽을 수 있습니다. 이는 S3 GET 트래픽을 줄이고 반복되는 network 병목을 피하며, I/O bound 반복 읽기 패턴에서 일반적으로 end-to-end runtime을 가장 크게 개선합니다. 주요 AWS 기능: - Lambda ephemeral storage(/tmp)는 실행 환경에 로컬로 존재하며 구성 가능(기본 512 MB, 최대 10 GB)합니다. - 동일한 실행 환경을 invocation 간 재사용하면(warm start) 추가로 도움이 될 수 있지만, 이 문제의 핵심 이점은 단일 invocation 내에서 ‘한 번 다운로드, 여러 번 읽기’입니다. - S3는 매우 확장성이 높지만, 전체 재읽기마다 여전히 전체 network 전송이 필요하므로, 반복 접근에 대해 로컬 스테이징은 표준 최적화입니다. 흔한 오해: - “매번 S3에서 직접 읽기”는 더 단순해 보이지만, network I/O가 배수로 증가하여 runtime을 지배할 수 있습니다. - “Lambda에 EBS 연결”은 표준 Lambda 기능이 아닙니다. EBS는 EC2에 연결됩니다. Lambda에서 유사한 persistent/shared storage는 EFS이지만, 이는 network file system latency를 유발하며 파싱 후 데이터를 폐기하는 경우에는 필요하지 않습니다. - ENA는 Lambda에 수동으로 연결하는 것이 아닙니다. Lambda networking은 관리형입니다. 시험 팁: Lambda function이 한 번의 invocation에서 동일한 대용량 데이터를 여러 번 접근해야 한다면, 크기가 맞는 경우 한 번 /tmp(ephemeral storage)로 다운로드하는 방식을 우선 고려하십시오. invocation 또는 function 간에 공유/영속 파일이 필요할 때만 EFS를 사용하십시오. 또한 Lambda ephemeral storage는 최대 10 GB까지 구성 가능하다는 점은 최적화 시나리오에서 자주 출제됩니다.

합격 후기(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******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.

다른 모의고사

지금 학습 시작하기

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

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

앱 받기

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

Cloud Pass

AWS Certified Developer - Associate (DVA-C02)

Practice Test #6

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

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

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 1

문제 분석

문제 2

문제 분석

문제 3

문제 분석

문제 4

문제 분석

문제 5

문제 분석

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

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

문제 7

문제 분석

문제 8

문제 분석

문제 9

(2개 선택)

문제 분석

문제 10

문제 분석

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

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

← 모든 AWS Certified Developer - Associate (DVA-C02) 문제 보기

지금 학습 시작하기

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

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

앱 받기

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