AWS Certified Developer - Associate (DVA-C02) #15 풀스케일 모의고사: 50문항 + 해설
#1부터 #14까지의 정리가 머릿속에 들어 있는지 확인하는 단계입니다. 실제 시험과 같은 도메인 비중으로 50문항을 풀어 봅니다.
풀이 방법 #
- 90~100분 안에 풀어 봅니다(실제 시험은 65문항/130분이지만, 이 모의고사는 50문항 기준입니다).
- 한 문항씩 즉시 해설을 보지 말고 끝까지 푼 뒤 채점합니다.
- 36문항(72%) 이상 맞히면 합격권으로 볼 수 있습니다.
- 부족한 도메인이 보이면 해당 글로 돌아가 다시 정리합니다.
도메인 분포 #
| 도메인 | 문항 수 | 범위 |
|---|---|---|
| Domain 1: 개발 (32%) | 16 | Q1 ~ Q16 |
| Domain 2: 보안 (26%) | 13 | Q17 ~ Q29 |
| Domain 3: 배포 (24%) | 12 | Q30 ~ Q41 |
| Domain 4: 트러블슈팅과 최적화 (18%) | 9 | Q42 ~ Q50 |
Domain 1: AWS 서비스로 개발 #
Q1. API Gateway가 Lambda를 직접 호출했는데 오류가 발생했다. Lambda의 재시도 동작은?
해설
이처럼 직접 호출되는 경우에는 Lambda가 재시도하지 않습니다. 재시도 여부는 호출자(API Gateway/클라이언트)가 결정합니다. 자동 2회 재시도와 DLQ는 비동기 호출의 동작입니다.
Q2. S3 이벤트로 비동기 호출된 Lambda가 모든 재시도 후에도 실패했다. 이벤트를 잃지 않으려면?
해설
비동기 호출의 실패 이벤트는 DLQ(Dead Letter Queue) 또는 Destination으로 보관합니다. Destination은 성공,실패를 모두 라우팅할 수 있어 권장됩니다. 동시성,메모리,프로비저닝 동시성은 처리 성능 옵션일 뿐 실패 이벤트를 보존하지 못합니다.
Q3. Lambda 함수의 첫 호출 응답이 느리다(콜드 스타트). 지연을 줄이는 가장 적절한 방법은?
해설
콜드 스타트를 줄이려면 프로비저닝 동시성을 사용합니다. 예약 동시성은 용량 확보와 제한을 위한 기능이지, 콜드 스타트 제거용은 아닙니다.
Q4. 한 Lambda 함수가 계정 전체 동시성을 잡아먹어 다른 함수가 스로틀링된다. 격리하려면?
해설
예약 동시성은 특정 함수에 동시성 몫을 확보하고 상한도 정해, 한 함수의 폭주로부터 다른 함수를 보호합니다.
Q5. 비용과 지연이 가장 중요하고 단순한 Lambda 프록시 백엔드만 필요하다. 적절한 API Gateway는?
해설
HTTP API는 REST API보다 약 70% 저렴하고 지연이 낮습니다. API 키,캐싱,요청 검증이 필요 없다면 HTTP API가 적합합니다. REST API는 사용량 계획,캐싱 같은 고급 기능용이고, WebSocket API는 양방향 실시간 통신용입니다. Private REST API는 VPC 내부 전용입니다.
Q6. 고객 등급별로 월 API 호출 할당량을 두려고 한다. 적절한 것은?
해설
사용량 계획 + API 키는 REST API 전용 기능으로 고객별 호출 한도,할당량을 적용합니다. API 키는 인증이 아니라 식별,계량 수단입니다. Lambda 오서라이저와 JWT(JSON Web Token) 오서라이저는 인증,인가를 처리할 뿐, 호출 할당량을 제공하지는 않습니다.
Q7. 프록시 통합된 Lambda를 호출하면 API Gateway가 502 Bad Gateway를 반환한다. 원인은?
해설
프록시 통합에서 Lambda가
statusCode,body 형식을 지키지 않으면 502가 발생합니다. 형식을 맞추면 해결됩니다. 동시성 초과는 429를 반환하고, CORS(Cross-Origin Resource Sharing) 미설정은 브라우저 측 차단일 뿐 502의 원인은 아닙니다.Q8. DynamoDB 테이블에서 파티션 키가 아닌 속성으로 자주 조회해야 한다. 테이블은 이미 운영 중이다. 적절한 것은?
해설
키가 아닌 속성으로 조회하려면 인덱스가 필요하고, 운영 중인 테이블에는 LSI(Local Secondary Index)를 추가할 수 없으므로(생성 시에만 가능) GSI(Global Secondary Index)를 추가합니다. Scan은 전체 스캔이라 비효율적입니다.
Q9. 두 클라이언트가 동시에 같은 DynamoDB 항목을 수정해 덮어쓰기 충돌이 발생한다. 막으려면?
해설
낙관적 잠금은 version 속성과 조건부 쓰기로 구현합니다. “내가 읽은 버전과 같을 때만 갱신"이라는 조건으로 충돌 시 한쪽만 성공합니다. 강력한 일관성 읽기는 최신값을 읽을 뿐 동시 쓰기 충돌을 막지 못하고, 원자적 카운터는 증감 누적용이며, TTL(Time To Live)은 자동 만료 삭제용입니다.
Q10. 같은 주문 ID로 요청이 두 번 들어와도 항목을 한 번만 생성하려 한다. 적절한 것은?
해설
attribute_not_exists 조건부 쓰기는 항목이 없을 때만 생성하므로 멱등한 생성이 됩니다. 원자적 카운터는 증감용이고, Scan 후 분기는 경합 상태에 취약하며, 강력한 일관성 읽기는 중복 생성을 막지 못합니다.Q11. DynamoDB에 새 항목이 추가되면 자동으로 알림을 발송하는 후속 처리를 붙이려 한다. 적절한 것은?
해설
항목 변경에 반응하려면 DynamoDB Streams를 Lambda 이벤트 소스로 연결합니다. DAX는 읽기 캐시이고, TTL(Time To Live)은 자동 만료 삭제일 뿐 변경 이벤트를 발생시키지 않습니다.
Q12. 주문은 받은 순서대로, 중복 없이 정확히 한 번 처리되어야 한다. 적절한 것은?
해설
순서 보장과 중복 제거(정확히 한 번)는 SQS FIFO(First In First Out) 큐입니다. 표준 큐는 at-least-once이고 순서를 보장하지 않습니다. SNS는 발행,구독용이고, EventBridge는 이벤트 라우팅용이라 순서와 중복 제거를 보장하지 않습니다.
Q13. 하나의 주문 이벤트를 결제,알림,분석 시스템이 각각 독립적으로, 내구성 있게 처리해야 한다. 적절한 것은?
해설
SNS + SQS 팬아웃은 한 번 발행한 이벤트를 여러 큐로 전달해, 각 소비자가 자기 속도로 버퍼링,재시도하며 독립 처리합니다. SQS 하나에 소비자 셋을 두면 메시지를 나눠 가져 각자 전체를 받지 못하고, SNS만 쓰면 소비자 측 버퍼링,재시도 내구성이 부족합니다.
Q14. 매일 자정에 정리 작업을 실행하는 Lambda를 트리거하려 한다. 적절한 것은?
해설
정해진 시각,주기 실행은 EventBridge 스케줄 규칙(옛 CloudWatch Events)입니다. SQS 지연 큐는 메시지 전달을 잠시 미룰 뿐 정해진 시각의 cron 실행이 아니고, DynamoDB Streams는 항목 변경 이벤트용입니다.
Q15. 리스트 API를 호출했는데 결과가 일부만 반환된다. 가장 가능성 높은 원인은?
해설
AWS 리스트 API는 결과를 페이지로 나누고 토큰(NextToken 등)을 줍니다. 첫 페이지만 읽으면 일부만 반환됩니다. 권한 부족은 AccessDenied 오류로, 스로틀링은 호출 제한 오류로 나타나므로 부분 반환과는 다릅니다.
Q16. 브라우저에서 서버를 거치지 않고 S3에 직접 큰 파일을 업로드하게 하되, 클라이언트에 AWS 키를 배포하지 않으려 한다. 적절한 것은?
해설
presigned URL은 임시 서명 URL로, 클라이언트가 자격 증명 없이 정해진 시간 동안 S3에 직접 접근하게 합니다.
Domain 2: 보안 #
Q17. 모바일 앱 사용자가 로그인 후 S3에 직접 업로드하도록 임시 AWS 자격 증명을 발급해야 한다. 적절한 것은?
해설
임시 AWS 자격 증명 발급은 Identity Pool의 역할입니다. User Pool은 인증(로그인,JWT)까지만 담당합니다.
Q18. 웹 앱에 회원가입,로그인,JWT 발급이 필요하다. 적절한 것은?
해설
사용자 디렉터리와 인증(로그인,JWT(JSON Web Token))은 User Pool입니다. Identity Pool은 임시 AWS 자격 증명 발급용이고, STS(Security Token Service) GetSessionToken은 기존 IAM 주체용이어서 회원가입,로그인 기능이 없습니다.
Q19. EC2에서 도는 애플리케이션이 S3에 접근해야 한다. 가장 안전한 방법은?
해설
EC2에 IAM Role을 부여하면 STS(Security Token Service) 임시 자격 증명이 자동으로 공급되어 장기 키를 저장할 필요가 없습니다. 키 저장 방식은 모두 오답입니다.
Q20. RDS 데이터베이스 자격 증명을 주기적으로 자동 회전해야 한다. 적절한 것은?
해설
자동 회전(rotation)이 내장된 서비스는 Secrets Manager이며, RDS와 통합됩니다. Parameter Store는 자동 회전을 기본 제공하지 않습니다.
Q21. 비용 없이 애플리케이션 설정값을 계층적 경로로 저장,조회하려 한다. 적절한 것은?
해설
Parameter Store 표준 파라미터는 무료이며
/app/db/host 같은 계층 경로로 설정값을 관리합니다. Secrets Manager는 자동 회전을 제공하지만 비밀당 과금되므로, 비용 없이 설정값만 저장하려는 용도에는 과합니다.Q22. S3 객체를 누가 언제 복호화했는지 감사할 수 있어야 한다. 적절한 암호화는?
해설
SSE-KMS는 KMS(Key Management Service) 키 사용을 CloudTrail로 감사할 수 있어 “누가 복호화했는가"를 추적할 수 있습니다. SSE-S3는 AWS 관리 키로 자동 암호화하지만 키 사용 감사 로그가 없습니다.
Q23. 수 GB 크기의 데이터를 KMS 키로 암호화하려 한다. 올바른 방식은?
해설
KMS(Key Management Service) 직접 암호화는 4KB 한도입니다. 큰 데이터는 데이터 키를 받아 로컬에서 암호화하는 봉투 암호화를 씁니다. SSE-C는 사용자가 키를 직접 제공,관리하는 방식이라 KMS 키 사용 시나리오와는 다릅니다.
Q24. 다른 계정의 리소스를 코드에서 제어해야 한다. 적절한 방법은?
해설
교차 계정 접근의 정석은 STS(Security Token Service) AssumeRole입니다. 대상 계정에 Role을 만들고 신뢰 정책으로 호출 계정을 허용합니다.
Q25. Lambda 함수가 DynamoDB 테이블에 쓰기를 해야 한다. 권한을 주는 올바른 방법은?
해설
Lambda는 실행 역할의 권한으로 동작합니다. 역할에 필요한 DynamoDB 권한을 부여하면 됩니다.
Q26. 여러 정책이 적용되는데 그중 하나에 명시적 Deny가 있다. 최종 결과는?
해설
명시적 Deny는 어떤 Allow보다도 우선합니다. 하나라도 Deny가 있으면 최종 결과는 거부입니다.
Q27. API Gateway에서 서드파티 OAuth 토큰을 자체 로직으로 검증해 접근을 통제해야 한다. 적절한 것은?
해설
커스텀 토큰이나 서드파티 OIDC(OpenID Connect) 검증 로직은 Lambda 오서라이저로 구현합니다. 인증 함수가 IAM 정책을 반환해 허용,거부를 결정합니다. Cognito User Pool 오서라이저는 Cognito가 발급한 토큰 전용이고, IAM 인증은 SigV4 서명, API 키는 계량용이라 서드파티 토큰 검증에 맞지 않습니다.
Q28. Identity Pool로 받은 임시 자격 증명으로, 사용자가 자기 소유 S3 prefix에만 접근하게 하려 한다. 적절한 것은?
해설
정책 변수로 사용자 식별자를 리소스 경로에 넣으면, 하나의 정책으로 사용자별 prefix 격리를 구현할 수 있습니다.
Q29. 전송 중(in transit) 데이터를 보호할 TLS 인증서를 발급,관리하려 한다. 적절한 것은?
해설
전송 중 암호화에 쓰는 TLS/SSL 인증서의 발급,갱신,관리는 ACM이 담당합니다. KMS는 저장 데이터의 키를 관리합니다.
Domain 3: 배포 #
Q30. 소스를 컴파일,테스트해 배포 아티팩트를 만드는 단계를 담당하는 도구는?
해설
빌드,테스트로 아티팩트를 생성하는 것은 CodeBuild이며, 정의는
buildspec.yml에 둡니다. CodeDeploy는 배포를 실행하고, CodePipeline은 전체 단계의 오케스트레이션을 담당하며, CodeArtifact는 패키지 저장소입니다.Q31. 빌드 단계의 명령과 단계(install/pre_build/build/post_build)를 정의하는 파일은?
해설
CodeBuild의 빌드 정의는 소스 루트의
buildspec.yml입니다. 배포 훅 정의는 appspec.yml입니다.Q32. 프로덕션 배포 전에 사람이 검토하고 승인하도록 파이프라인을 멈추려 한다. 적절한 것은?
해설
파이프라인 스테이지 사이에 수동 승인(Manual Approval) 액션을 넣으면 사람이 승인할 때까지 진행이 멈춥니다.
appspec 훅은 배포 단계 내 스크립트 실행용이지, 사람 승인 게이트가 아닙니다.Q33. 서버리스 애플리케이션(Lambda + API Gateway + DynamoDB)을 적은 코드로 정의,배포하려 한다. 적절한 것은?
해설
SAM(Serverless Application Model)은 서버리스 전용 CloudFormation 확장으로, 단축 리소스 타입을 사용해 서버리스 앱을 간결하게 정의,배포합니다. Elastic Beanstalk는 EC2 기반 웹 앱용 PaaS(Platform as a Service)이고, OpsWorks는 Chef,Puppet 구성 관리용이며, CodeArtifact는 패키지 저장소입니다.
Q34. CloudFormation 스택을 갱신하기 전에 어떤 리소스가 어떻게 바뀌는지 미리 확인하려 한다. 적절한 것은?
해설
체인지셋은 스택 갱신 전에 변경 영향(생성,수정,교체,삭제)을 미리 보여줘 의도치 않은 교체를 방지합니다. 드리프트 감지는 콘솔 등 외부에서 수동 변경된 실제 상태와 템플릿의 차이를 확인하는 사후 기능이라, 갱신 전 미리보기와는 다릅니다.
Q35. CloudFormation 스택을 삭제해도 RDS 데이터베이스는 보존하고 싶다. 적절한 것은?
해설
DeletionPolicy: Retain은 스택 삭제 시 해당 리소스를 보존합니다. Snapshot은 삭제 전에 스냅샷을 남깁니다.Q36. Lambda를 로컬 환경에서 실행,디버깅하려 한다. 적절한 것은?
해설
sam local은 Docker로 Lambda,API를 로컬에서 실행,디버깅합니다. X-Ray는 배포된 환경의 분산 추적 도구이지, 로컬 실행 도구가 아닙니다.Q37. 인프라 관리에 신경 쓰지 않고 웹 애플리케이션을 빠르게 배포하려 한다(EC2,ELB,ASG 자동 구성). 적절한 것은?
해설
Elastic Beanstalk는 코드를 올리면 EC2,ELB,ASG(Auto Scaling Group),헬스 모니터링을 자동으로 구성하는 PaaS(Platform as a Service)입니다. SAM,Lambda는 서버리스용이고, Step Functions는 워크플로 오케스트레이션용이라 EC2 기반 웹 앱 자동 구성과는 목적이 다릅니다.
Q38. 배포 실패 시 즉시 이전 버전으로 되돌릴 수 있고 다운타임이 없어야 한다. 적절한 배포 방식은?
해설
Blue/Green은 새 환경에 배포한 뒤 트래픽을 전환하므로 무중단이며, 문제가 생기면 트래픽을 되돌려 즉시 롤백합니다.
Q39. Lambda 새 버전을 처음에 트래픽 10%에게만 보내고 문제없으면 전체로 확대하려 한다. 적절한 것은?
해설
Lambda 별칭은 두 버전에 트래픽을 비율로 분배할 수 있고, SAM(Serverless Application Model)의
DeploymentPreference(예: Canary10Percent5Minutes)로 이를 자동화할 수 있습니다.Q40. 새 버전 배포 후 에러율이 임계치를 넘으면 자동으로 이전 버전으로 되돌리려 한다. 적절한 것은?
해설
CodeDeploy는 배포 중 CloudWatch 알람이 울리면 자동 롤백합니다. 지표 기반 자동 롤백의 핵심은 알람 연계입니다.
Q41. 사내 npm,pip 의존성 패키지를 안전하게 호스팅,공유하고 외부 저장소를 캐시하려 한다. 적절한 것은?
해설
CodeArtifact는 npm,pip,Maven 등의 관리형 패키지 저장소로, 외부 저장소 프록시,캐시와 내부 패키지 공유를 제공합니다. ECR은 컨테이너 이미지 저장소이고, CodeCommit은 Git 소스 저장소라 의존성 패키지 호스팅 용도와는 다릅니다.
Domain 4: 트러블슈팅과 최적화 #
Q42. 여러 마이크로서비스를 거치는 요청이 어디서 느려지는지 병목 구간을 찾으려 한다. 적절한 것은?
해설
X-Ray는 세그먼트,서브세그먼트로 요청 경로를 추적하고 서비스 맵으로 지연,오류를 시각화해 병목을 찾습니다. CloudTrail은 API 호출 감사용이고, Config는 리소스 구성 변경 추적용이라 요청 경로 병목 분석에는 맞지 않습니다.
Q43. EC2 인스턴스의 메모리 사용률을 CloudWatch에서 모니터링하려 한다. 적절한 것은?
해설
CPU,네트워크는 기본 지표지만, 메모리,디스크는 기본 제공되지 않으므로 CloudWatch Agent를 설치해야 합니다.
Q44. 서버리스에서 API 호출 비용 없이 로그만으로 커스텀 지표를 생성하려 한다. 적절한 것은?
해설
EMF(Embedded Metric Format)는 구조화된 JSON 로그를 쓰면 CloudWatch가 자동으로 지표를 추출해, 별도 API 호출 없이 커스텀 지표를 만들 수 있습니다. PutMetricData를 매 요청 호출하면 API 비용과 스로틀링 위험이 커집니다.
Q45. 누가 특정 S3 버킷을 삭제했는지 추적해야 한다. 적절한 것은?
해설
API 호출 주체,시점 감사(“누가 무슨 API를 호출했나”)는 CloudTrail입니다. CloudWatch Metrics는 성능 지표용이고, X-Ray는 요청 경로용이며, Logs Insights는 로그 쿼리 도구라 행위자 감사에는 맞지 않습니다.
Q46. Lambda 함수가 CPU 바운드 작업에서 느리다. 직접 CPU를 설정할 수 없다면 적절한 조치는?
해설
Lambda는 메모리만 설정하지만 CPU,네트워크 성능도 비례해 늘어납니다. CPU가 부족하면 메모리를 올립니다.
Q47. API Gateway 뒤의 작업이 30초 넘게 걸려 504 Gateway Timeout이 발생한다. 적절한 해결은?
해설
API Gateway 통합 타임아웃은 최대 29초입니다. 더 긴 작업은 비동기 패턴으로 바꿔야 합니다.
Q48. DynamoDB 프로비저닝 테이블에서
ProvisionedThroughputExceededException이 자주 발생한다. 적절한 대응이 아닌 것은?해설
강력한 일관성 읽기는 비용이 2배라서 스로틀링을 악화시킵니다. 용량 상향,키 분산,지수 백오프가 올바른 대응입니다.
Q49. DynamoDB 읽기 응답을 마이크로초 수준으로 낮추려 한다. 적절한 것은?
해설
DynamoDB 전용 인메모리 캐시인 DAX가 읽기를 마이크로초 수준으로 낮춥니다. 범용 캐시인 ElastiCache는 별도 캐시 로직이 필요하고, CloudFront는 콘텐츠 전송 캐시(CDN, Content Delivery Network)이며, 읽기 복제본은 DynamoDB 개념이 아닙니다.
Q50. 스로틀링(429/ThrottlingException)에 대응하는 클라이언트의 올바른 재시도 방식은?
해설
스로틀링은 지수 백오프 + 지터로 재시도해야 하며, AWS SDK에 기본 내장되어 있습니다. 즉시,고정 간격 재시도는 부하를 키웁니다.
채점과 마무리 #
전체 점수
정답 0 / 0
답변 0 / 0
36문항(72%) 이상이면 합격권입니다. 틀린 문항은 단순히 정답을 외우지 말고, **“제약 키워드가 무엇이었고 왜 그 보기가 최적인가”**를 #14의 기준으로 설명할 수 있을 때까지 복습하세요. 특히 자주 헷갈리는 쌍(User Pool vs Identity Pool, Secrets Manager vs Parameter Store, SQS vs SNS vs EventBridge, 502 vs 504)은 마지막까지 확실히 정리합니다.
시리즈를 마치며 #
#1 시험 소개에서 시작해 개발(32%) → 보안(26%) → 배포(24%) → 트러블슈팅과 최적화(18%)의 네 도메인을 한 바퀴 돌고, 시험 전략과 모의고사로 마무리했습니다. DVA-C02는 단순 암기가 아니라 AWS 서비스를 코드로 어떻게 다루고, 배포하고, 디버깅하는가를 묻는 시험이라는 점을 기억하면, 처음 보는 시나리오에도 흔들리지 않습니다.
DVA-C02에 합격한 뒤에는 운영 관점의 SysOps Administrator Associate(SOA-C02), 또는 설계를 더 깊이 다루는 Solutions Architect Associate(SAA-C03)로 이어집니다. 실무 감각이 더 필요하다면 AWS 실무 트랙 27편으로 돌아가 콘솔과 코드 위에서 직접 다뤄 보는 것도 좋은 복습입니다. 합격을 응원합니다.