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

Practice Test #4

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

한 물류 회사가 Lambda proxy integration을 사용하여 AWS Lambda 함수를 호출하는 Regional Amazon API Gateway REST API (GET /shipments/{trackingId})를 노출하고 있습니다. 2024-11-03 14:25:33 UTC에 한 개발자가 curl -i https://api.company.example/prod/shipments/42 를 실행했더니 HTTP 502를 받았습니다. API Gateway execution logs에는 'Method completed with status: 502'가 표시되고, Lambda의 CloudWatch Logs에는 핸들러가 성공적으로 완료되었으며 스택 트레이스 없이 일반 문자열 'OK'(2 bytes)를 반환했다고 나옵니다. 오류를 해결하고 API가 200을 반환하게 하려면 개발자가 무엇을 변경해야 합니까?

Regional에서 Edge-Optimized로 변경하면 클라이언트가 API Gateway에 도달하는 방식(앞단에 CloudFront distribution)과 전 세계 사용자에 대한 지연 시간에 영향을 줄 수 있지만, 필요한 Lambda proxy 응답 형식은 바뀌지 않습니다. endpoint type 불일치나 CloudFront 문제는 보통 다른 증상(DNS/403/edge에서의 5xx)을 보이며, Lambda가 성공한 뒤 잘못된 integration response로 인해 일관되게 502가 나는 경우와는 다릅니다.

GET /shipments/{trackingId}에서는 일반적으로 request body가 없습니다. 또한 Lambda logs로 보아 요청이 API Gateway에 도달해 Lambda 함수를 호출한 것이 명확합니다. 잘못된 클라이언트 payload라면 보통 400(bad request) 또는 invocation 이전의 mapping/template 오류를 유발하지, Lambda가 반환한 뒤 502가 발생하는 형태는 아닙니다. 핵심 문제는 요청이 아니라 응답 형식입니다.

Lambda proxy integration에서는 Lambda가 최소한 statusCode와 body(string)를 포함하고, 선택적으로 headers와 isBase64Encoded를 포함하는 JSON 객체를 반환해야 합니다. "OK" 같은 일반 문자열을 반환하는 것은 유효한 proxy 응답이 아니므로, API Gateway가 이를 HTTP 응답으로 변환할 수 없어 502를 반환합니다. Lambda가 {"statusCode":200,"body":"OK"}를 반환하도록 변경하면 문제가 해결되어 HTTP 200이 됩니다.

Authorization 문제(자격 증명 누락/무효)는 Lambda를 호출하기 전에 API Gateway에서 처리되며 보통 401 Unauthorized 또는 403 Forbidden을 반환하고, 502를 반환하지 않습니다. 증거상 Lambda가 호출되어 성공적으로 완료되었으므로 요청은 integration까지 도달할 권한이 있었습니다. 문제는 호출자 인증이 아니라 API Gateway가 Lambda 출력값을 해석하는 과정에서 발생합니다.

문제 분석

핵심 개념: 이 문제는 Amazon API Gateway REST API + AWS Lambda proxy integration(일명 Lambda proxy)을 테스트합니다. proxy integration에서는 API Gateway가 Lambda 함수가 특정 JSON 구조를 반환하기를 기대하며, 이를 HTTP 응답으로 변환합니다. 정답이 맞는 이유: Lambda 핸들러는 “성공적으로 완료”되었지만 일반 문자열 "OK"를 반환했습니다. Lambda proxy integration에서 API Gateway는 {"statusCode": 200, "headers": {...}, "body": "..."} (그리고 선택적으로 "isBase64Encoded") 같은 응답 객체를 요구합니다. Lambda가 raw string(또는 그 외 잘못된 proxy 응답)을 반환하면 API Gateway는 이를 HTTP 응답으로 파싱할 수 없고, 보통 execution logs에 “Method completed with status: 502”가 찍히면서 502 Bad Gateway를 반환합니다. 이는 전형적인 증상으로, Lambda는 성공했지만 API Gateway가 integration response를 변환하지 못한 경우입니다. 주요 AWS 기능 / 구성: - REST API에서 Lambda proxy integration은 다음을 요구합니다: - statusCode (integer) - body (string; JSON은 stringified 되어야 함) - optional headers 및 isBase64Encoded - 이 맥락에서 API Gateway 502는 종종 “Malformed Lambda proxy response”(때로는 execution logs에서 확인 가능)를 의미합니다. - 올바른 해결책: Lambda가 proxy 응답 형식을 반환하도록 업데이트(예: statusCode 200 및 body "OK"). 흔한 오해: - 502를 네트워크/endpoint-type 문제(Edge vs Regional) 또는 Lambda runtime 크래시로 오해하는 경우가 많습니다. 여기서는 Lambda logs에 스택 트레이스가 없고 성공적으로 완료되었으므로 runtime 실패 가능성이 낮습니다. - Authorization 문제는 보통 API Gateway에서 401/403(또는 IAM auth에서 403)을 반환하며, Lambda 호출 이후 502가 나오는 형태가 아닙니다. - GET의 경우 “request payload format”이 문제인 경우는 드뭅니다. 요청은 API Gateway에 도달했고 Lambda를 호출했습니다. 시험 팁: API Gateway + Lambda proxy integration + HTTP 502인데 Lambda logs가 성공을 보여주면, 즉시 Lambda proxy 응답 형태를 확인하세요. body는 반드시 string이어야 하며, statusCode/body 누락 또는 필드 오류가 502의 흔한 원인입니다. 또한 401/403(auth)와 502(integration/response mapping/parsing)를 구분하세요.

2
문제 2

한 팀이 이미지를 리사이즈하는 기존 AWS Lambda 함수에 OpenCV와 SciPy를 추가했다. 업데이트 후 압축 해제된 .zip 배포 패키지 크기가 420 MB로, .zip 기반 Lambda 패키지의 250 MB 할당량을 초과한다. 또한 이 함수는 x86_64 instruction set architecture를 사용하며 이는 변경할 수 없다. 개발자는 비즈니스 로직을 변경하지 않고 새 종속성을 포함해 함수를 배포해야 한다. 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

오답. AWS Lambda는 EC2가 EBS snapshots를 사용하는 방식처럼 임의의 “snapshots”를 파일시스템으로 mount하는 것을 지원하지 않는다. Lambda는 /tmp ephemeral storage와 선택적 Amazon EFS mounting을 제공하지만 snapshot mounting은 제공하지 않는다. 이 선택지는 존재하지 않는 Lambda 기능을 설명하며, 대용량 종속성에 대한 유효한 배포 접근 방식이 아니다.

오답. arm64는 때때로 더 나은 가격/성능을 제공하고 종속성 footprint를 바꿀 수 있지만, 문제에서 함수가 x86_64를 사용하며 이를 변경할 수 없다고 명시한다. 따라서 architecture 전환은 필수 요구 사항을 위반한다. 또한 architecture 변경은 OpenCV/SciPy 같은 native 라이브러리에 호환성 문제를 유발할 수 있다.

오답. Lambda는 Amazon EBS volume을 attach할 수 없다. EBS는 EC2 block storage 서비스이며 attach하려면 EC2 instance가 필요하다. Lambda에서 지원되는 network filesystem 옵션은 Amazon EFS(그리고 VPC 내에서만)지만, 이 경우에도 대용량 종속성 패키징에는 container images가 더 적합하다.

정답. Lambda container images는 최대 10 GB를 지원하므로 420 MB 종속성 세트를 충분히 수용한다. 개발자는 (AWS Lambda base image를 사용해) image를 빌드하고 OpenCV와 SciPy를 설치한 뒤 Amazon ECR에 push하고, Lambda 함수가 해당 image를 사용하도록 업데이트하여 동일한 코드 로직과 x86_64 architecture를 유지할 수 있다. 이는 크기가 초과된 Lambda 패키지에 대한 표준 솔루션이다.

문제 분석

핵심 개념: 이 문제는 AWS Lambda 배포 패키징 제한과 대체 패키징 모델인 Lambda container images를 테스트한다. 또한 architecture 제약(x86_64)과 대용량 native 종속성(OpenCV, SciPy)을 애플리케이션 로직 변경 없이 포함하는 방법을 다룬다. 정답인 이유: .zip 기반 Lambda 배포 패키지는 압축 해제 시 250 MB(직접 업로드의 경우 압축 시 50 MB)라는 하드 제한이 있다. 업데이트된 함수의 압축 해제 크기는 420 MB이므로 .zip으로는 배포할 수 없다. Lambda container images는 함수 코드와 모든 종속성을 OCI 호환 image로 최대 10 GB까지 패키징할 수 있다. 개발자는 런타임(예: python)에 대한 AWS 제공 Lambda base image를 기반으로 image를 빌드하고, OpenCV/SciPy 및 필요한 native 라이브러리를 설치한 뒤, image를 Amazon ECR에 push하고, Lambda 함수가 해당 image를 사용하도록 지정할 수 있다. 이는 모든 요구 사항(새 종속성으로 배포, 비즈니스 로직 변경 없음, x86_64 architecture 유지)을 충족한다(Lambda는 x86_64에서 container images를 지원). 주요 AWS 기능: - Amazon ECR에 저장되는 Lambda container image 지원(최대 10 GB). - Lambda Runtime Interface Client가 포함된 AWS Lambda base images로 호환성 단순화. - 함수 생성/업데이트 시 function architecture(x86_64) 지정 가능. - 운영 측면에서 ECR은 IAM과 통합되며 image scanning 및 lifecycle policies를 지원. 흔한 오해: - Lambda layers는 종속성에 도움이 될 수 있지만, 결합된 압축 해제 크기가 여전히 제한을 초과하면 이 사례를 해결하지 못한다(또한 layers 자체에도 크기 제한이 있음). 문제는 .zip 할당량 초과를 명시적으로 지적하므로 container images로 유도한다. - “snapshot을 mount”하거나 EBS를 attach하는 것은 Lambda에서 지원되는 패턴이 아니다. - arm64로 전환하면 경우에 따라 크기가 줄 수 있지만, architecture는 x86_64로 유지해야 한다. 시험 팁: OpenCV, SciPy, TensorFlow 같은 대용량 ML/과학 라이브러리와 패키지 크기 제한 문제가 보이면 즉시 Lambda container images(또는 제한 내라면 layers로 분리)를 고려하라. 또한 “x86_64를 유지해야 함” 같은 제약을 확인해, 유리해 보이더라도 architecture 변경 옵션을 배제해야 한다.

3
문제 3

한 핀테크 팀이 AWS CloudFormation을 사용하여 EventBridge로 트리거되는 AWS Lambda 함수를 배포하고 있으며, 해당 코드가 Amazon S3에 저장된 ZIP 아티팩트(버킷 artifacts-567890-us-east-1, versioning 활성화, 키 builds/processor.zip, 마지막 version ID 3Lg8xZ2)인데, 동일한 S3 object key를 유지한 채로 스택 업데이트를 실행할 때마다 Lambda 함수 코드가 변경되지 않습니다. 업데이트 중 CloudFormation이 새 코드를 적용하도록 하려면 무엇을 해야 합니까?

새 Lambda alias를 생성해도 함수의 코드 패키지는 업데이트되지 않습니다. Alias는 게시된 version을 가리키는 포인터이며 트래픽 전환, 안정적인 ARN, 배포 전략(예: CodeDeploy를 사용한 blue/green)에 사용됩니다. 기본 함수 코드가 업데이트되지 않았거나 새 version이 게시되지 않았다면, 새 alias를 만들어도 CloudFormation이 S3에서 새 ZIP을 가져오게 되지 않습니다.

CloudFormation이 Lambda Code 속성에 대한 코드 업데이트를 트리거하려면 템플릿에서 감지 가능한 변경이 필요하므로 이것이 정답입니다. S3 versioning이 활성화된 경우 최신 S3ObjectVersion(예: 새 version ID)을 지정하면 CloudFormation이 정확히 그 아티팩트를 가져오게 됩니다. 또는 S3Key를 변경(빌드마다 고유)하는 것도 업데이트를 강제하며 일반적인 CI/CD 모범 사례입니다.

다른 버킷에 업로드하는 것은 불필요하며, 템플릿도 함께 업데이트하여 해당 새 버킷/key/version을 참조하지 않는 한 문제를 본질적으로 해결하지 못합니다. 핵심 문제는 CloudFormation이 Lambda Code 정의의 변경을 보지 못한다는 점입니다. 버킷을 바꾸면 운영 복잡성만 증가하며 결정적 배포를 위한 권장 메커니즘이 아닙니다.

code-signing configuration은 Lambda가 신뢰할 수 있는 게시자가 서명한 코드만 배포하도록 강제하여 공급망 보안을 개선합니다. 하지만 S3 key가 동일하게 유지될 때 CloudFormation이 코드를 재배포하도록 강제하지는 않습니다. code signing이 있더라도 CloudFormation은 업데이트를 트리거하기 위해 S3Key 또는 S3ObjectVersion(또는 동등한 변경)이 필요합니다.

문제 분석

핵심 개념: 이 문제는 배포 패키지가 Amazon S3에 저장되어 있을 때 AWS CloudFormation이 AWS::Lambda::Function 코드 업데이트를 어떻게 감지하고 적용하는지 테스트합니다. CloudFormation은 템플릿(또는 파라미터)의 변경을 기반으로 리소스를 업데이트하며, Lambda 코드의 경우 코드 업데이트를 트리거하려면 Code 속성(S3Key 및/또는 S3ObjectVersion)에서 감지 가능한 변경이 필요합니다. 정답이 맞는 이유: 팀이 동일한 S3 key(builds/processor.zip)에 새 ZIP을 업로드한 뒤 템플릿을 변경하지 않고 스택 업데이트를 실행하면, CloudFormation은 Lambda 함수의 Code 정의에 변경이 없다고 판단하는 경우가 많습니다. S3 versioning이 활성화되어 있으므로 CloudFormation이 새 아티팩트를 가져오도록 강제하는 올바른 방법은 (1) S3 object key를 변경(예: builds/processor-<buildId>.zip)하거나 (2) 템플릿에서 새 S3ObjectVersion 값(예: 3Lg8xZ2 또는 최신 version ID)을 지정하는 것입니다. 어느 방법이든 템플릿의 Code 속성이 변경되므로 CloudFormation이 Lambda 함수 코드를 업데이트하게 됩니다. 주요 AWS 기능: CloudFormation은 Code: { S3Bucket, S3Key, S3ObjectVersion }를 통해 S3의 Lambda 코드를 지원합니다. S3 versioning은 특정 아티팩트에 대한 변경 불가능한 참조를 제공하여 반복 가능한 배포와 안전한 롤백을 가능하게 합니다. 모범 사례는 고유한 content-addressed key(또는 CI/CD가 주입하는 version ID)를 사용하여 배포가 결정적이고 감사 가능하도록 만드는 것입니다. 흔한 오해: 같은 key의 객체를 단순히 덮어쓰면 자동으로 감지될 것이라고 생각하기 쉽습니다. 하지만 CloudFormation은 템플릿 기반이므로 템플릿이 바뀌지 않으면 코드를 재배포하지 않을 수 있습니다. 또 다른 오해는 alias나 code signing 같은 운영 기능이 강제로 새로고침을 유도한다는 것인데, 이는 트래픽 전환과 무결성을 다루는 기능이지 변경 감지를 위한 기능이 아닙니다. 시험 팁: Lambda + CloudFormation에서 기억할 점: S3에서 코드를 업데이트하려면 S3Key 또는 S3ObjectVersion을 변경해야 합니다(또는 SAM/CDK 같은 패키징 도구를 사용해 자동으로 고유 key를 생성). “same S3 key”와 “code doesn’t change”가 보이면 해결책은 거의 항상 “템플릿에서 key 또는 version을 업데이트”입니다.

4
문제 4

한 핀테크 스타트업이 us-west-2에서 340개의 AWS Lambda 함수를 운영하고 있으며, 이 함수들은 Lambda function URLs을 통해 테스트되어야 합니다. 내부 검증 팀은 QA-Reviewers라는 이름의 IAM group으로 구성되어 있고, 익명 액세스는 차단하면서 public URLs을 사용해 모든 엔드포인트를 호출해야 합니다. 개발자로서 이러한 요구 사항을 충족하기 위해 대규모로 authentication과 permissions를 어떻게 구성해야 합니까?

정답입니다. 각 function URL을 AWS_IAM으로 설정하면 URL이 공개적으로 도달 가능하더라도 SigV4 authentication이 강제되어 익명 액세스가 차단됩니다. 340개 함수에 대해 lambda:InvokeFunctionUrl을 부여하는 단일 identity-based policy를 QA-Reviewers group에 연결하면 깔끔하게 확장됩니다. 이는 AWS best practices에 부합합니다. 즉, IAM identities에 권한을 중앙화하고 CLI/IaC로 반복 구성을 자동화합니다.

오답입니다. AuthType=NONE은 익명 invocation을 허용하므로 익명 액세스를 차단해야 한다는 요구 사항을 직접 위반합니다. 또한 resource-based policy를 생성해 IAM group에 연결한다고 제안하는데, 이는 resource policies의 동작 방식이 아닙니다. resource-based policies는 리소스(Lambda function)에 연결되며 principals를 지정합니다. IAM groups에 연결되지 않습니다.

오답입니다. AWS_IAM은 올바른 auth type이지만, 340개의 개별 identity-based policies를 만드는 것은 불필요한 운영 오버헤드이며 확장 가능한 best-practice 접근이 아닙니다. 또한 identity-based policies는 제시된 방식처럼 “group ARN에서(from a group ARN)” 액세스를 부여하지 않습니다. policy를 group(또는 users/roles)에 연결하는 것이지, group을 principal로 참조하는 것이 아닙니다.

오답입니다. AuthType=NONE은 익명 액세스를 허용하므로 핵심 보안 요구 사항을 충족하지 못합니다. 또한 함수별로 QA-Reviewers group ARN을 principal로 하는 resource-based policy를 추가하자고 하는데, IAM groups는 resource-based policies에서 유효한 principals가 아닙니다. users/roles/accounts를 지정해야 합니다. 이 옵션은 보안적으로도 부적절하고 기술적으로도 잘못되었습니다.

문제 분석

핵심 개념: 이 문제는 AWS Lambda Function URLs의 authentication과 IAM authorization을 대규모로 적용하는 방법을 평가합니다. Function URLs는 auth type NONE(공개/익명) 또는 AWS_IAM(SigV4 서명 요청)으로 구성할 수 있습니다. AWS_IAM을 사용하면 액세스는 주로 IAM identity-based policies(그리고 선택적으로 resource-based permissions)를 통해 제어되며, 익명 호출을 방지합니다. 정답이 맞는 이유: 요구 사항은 “public URLs을 사용해 모든 엔드포인트를 호출하되 익명 액세스는 차단”하는 것입니다. 올바른 방법은 각 function URL을 AWS_IAM으로 구성하여 요청이 AWS credentials로 서명되도록 강제하는 것입니다. 그런 다음 관련 함수 전반에 대해 lambda:InvokeFunctionUrl을 허용하는 단일 identity-based policy로 QA-Reviewers group에 권한을 부여합니다. 이는 340개 함수에 대해 확장성이 좋습니다. group에 policy 하나만 연결하면 되고, CLI/script로 function URLs 생성/업데이트를 자동화할 수 있습니다. 주요 AWS 기능: - AuthType=AWS_IAM인 Lambda Function URLs는 IAM authentication(SigV4)을 강제합니다. 익명 호출자는 invoke할 수 없습니다. - IAM identity-based policy action: lambda:InvokeFunctionUrl. Resource를 function ARNs로 범위 지정할 수 있으며(그리고 tag-based access control을 사용한다면 aws:RequestedRegion, lambda:FunctionUrlAuthType 또는 tags 같은 conditions를 선택적으로 사용할 수 있습니다). - policy를 IAM group에 연결하는 것은 팀 단위로 확장 가능한 표준 패턴입니다. - 많은 함수에 대한 일괄 구성에는 automation(CLI/script/IaC)이 적절합니다. 흔한 오해: 자주 있는 함정은 “public URL”이 곧 unauthenticated여야 한다고 생각하는 것입니다. Function URLs는 인터넷에서 도달 가능한 엔드포인트이지만, AWS_IAM은 여전히 signed requests를 요구하므로 익명으로 접근할 수 없습니다. 또 다른 오해는 “resource-based policy를 group에 연결”하려 하거나(지원되지 않음) resource policies에서 group ARN을 principal로 사용하려는 것입니다(IAM groups는 유효한 principals가 아님). 시험 팁: - 요구 사항에 “익명 차단(block anonymous)”이 있으면 AuthType=NONE을 피하십시오. - 대규모 환경에서는 함수별 policy보다 재사용 가능한 identity policy 하나(필요 시 tag로 범위 지정)를 선호하십시오. - 기억할 점: identity-based policies는 users/groups/roles에 연결됩니다. resource-based policies는 리소스에 연결되며 principals(users/roles/accounts/services)를 지정하는데, groups는 아닙니다.

5
문제 5

소규모 팀이 AWS에서 10개의 AWS Lambda 함수, Amazon API Gateway, 그리고 단일 Amazon DynamoDB 테이블을 사용하여 이벤트 기반 사진 태깅 서비스를 프로토타이핑하고 있습니다. 이 팀은 가속화된 inner-loop 워크플로가 필요하며, 매 커밋마다 전체 스택을 재배포하지 않고도 QA 테스트를 위해 20초 이내에 하나의 Lambda 함수에 대한 코드만 변경된 내용을 dev 스택으로 푸시할 수 있어야 합니다. 팀은 배포의 백본으로 AWS CloudFormation을 유지하고, 워크스테이션에서 하나의 CLI 명령으로 업데이트된 코드와 사소한 템플릿 변경(예: environment variables)을 클라우드에 점진적으로 동기화(sync)하고자 합니다. 이 요구 사항을 충족하기 위해 팀은 무엇을 해야 합니까?

정답입니다. AWS SAM은 프로비저닝에 CloudFormation 스택을 사용하며 sam sync로 빠른 점진적 업데이트를 지원합니다. 이 명령은 inner-loop 개발을 위해 설계되었으며, 매번 전체 CloudFormation 재배포를 실행하지 않고도 기존 dev 스택에 업데이트된 Lambda 코드(그리고 environment variables 같은 일부 소규모 구성 변경)를 푸시할 수 있습니다. 단일 CLI 명령과 코드만 변경된 경우 20초 미만 반복이라는 요구 사항에 부합합니다.

오답입니다. sam init은 시작용 SAM 애플리케이션 구조와 샘플 템플릿을 생성하는 프로젝트 스캐폴딩 명령입니다. 리소스를 배포하거나, Lambda 코드를 업데이트하거나, 기존 스택에 대한 점진적 동기화를 수행하지 않습니다. SAM은 올바른 프레임워크이지만, 빠른 점진적 업데이트에 필요한 명령은 sam init이 아니라 sam sync(또는 전체 배포를 위한 sam deploy)입니다.

오답입니다. cdk synth는 CDK 코드로부터 CloudFormation 템플릿을 합성(생성)할 뿐, AWS에 어떤 것도 배포하지 않습니다. CDK가 궁극적으로 CloudFormation을 사용하더라도 synth는 로컬 빌드 단계이며 dev 스택으로 점진적 Lambda 코드 변경을 푸시할 수 없습니다. CDK에서 배포 명령은 cdk deploy(보기에는 없음)입니다.

오답입니다. cdk bootstrap은 CDK 배포에 필요한 사전 요구 리소스(예: S3 bucket 및 roles 같은 CDK toolkit stack)를 계정/리전에 프로비저닝합니다. 이는 일회성 또는 드물게 수행하는 환경 설정 단계이지, 점진적 배포 메커니즘이 아닙니다. 업데이트된 Lambda 코드를 sync하거나 기존 애플리케이션 스택에 템플릿 조정을 적용하지 않습니다.

문제 분석

핵심 개념: 이 문제는 AWS CloudFormation을 배포 엔진으로 유지하면서 서버리스 앱에 대해 빠르고 점진적인 배포를 수행하는 것을 평가합니다. 핵심 기능은 전체 CloudFormation 재배포 없이 기존 스택에 코드와 소규모 구성 변경을 “sync”하는 능력입니다. 정답이 맞는 이유: AWS SAM은 서버리스 리소스(AWS::Serverless::Function, API 등)를 위한 CloudFormation 확장입니다. sam sync 명령은 inner loop를 가속화하기 위해 배포된 dev 스택에 Lambda 함수 코드와 특정 구성 변경(예: environment variables)을 점진적으로 업데이트하도록 특별히 설계되었습니다. 이를 통해 매 커밋마다 패키징하고 전체 CloudFormation change set을 실행하는 시간 비용을 피할 수 있어, 거의 실시간에 가까운 QA 검증이 가능합니다. 또한 SAM은 궁극적으로 CloudFormation으로 변환되어 CloudFormation을 통해 배포되므로, “워크스테이션에서 하나의 CLI 명령”과 “CloudFormation을 배포 백본으로 사용”이라는 요구 사항도 충족합니다. 주요 AWS 기능: - sam sync: 로컬 변경 사항을 감시하거나 푸시하고, 클라우드에 대해 타깃 업데이트(일반적으로 Lambda 코드 업데이트)를 수행합니다. - CloudFormation 기반 배포: SAM 템플릿은 CloudFormation과 호환되며, SAM은 프로비저닝에 CloudFormation 스택을 사용합니다. - 서버리스 가속 패턴: 점진적 코드 sync는 여러 Lambda 함수 중 하나만 자주 변경되는 경우에 이상적입니다. - 사소한 템플릿 변경: SAM은 일부 구성 업데이트를 빠르게 적용할 수 있으며, 더 큰 인프라 변경은 여전히 전체 sam deploy가 필요합니다. 흔한 오해: - sam init을 배포로 혼동: sam init은 프로젝트 스캐폴딩만 수행하며, 변경 사항을 배포하거나 sync하지 않습니다. - CDK synth 또는 bootstrap이 변경 사항을 배포한다고 가정: synth는 CloudFormation 템플릿만 생성하고, bootstrap은 환경(toolkit stack)을 준비하지만 애플리케이션 리소스를 업데이트하지 않습니다. - “어떤 IaC 도구든” 20초 미만의 점진적 업데이트가 가능하다고 생각: 이 문제는 서버리스 inner-loop 속도를 위한 SAM의 명시적인 sync 워크플로를 가리킵니다. 시험 팁: “serverless + CloudFormation 백본 + 코드만 점진적 업데이트 + 한 번의 명령 + 빠른 inner loop”가 보이면 AWS SAM과 sam sync를 찾으십시오. CDK의 경우 유사한 배포 명령은 cdk deploy(보기에는 없음)입니다. 또한 init/synth/bootstrap은 설정/빌드 단계이지, 점진적 배포 메커니즘이 아님을 기억하십시오.

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

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

6
문제 6

한 피트니스 스타트업이 AWS에서 매일 걸음 수 챌린지를 운영한다. 참가자 제출은 Amazon DynamoDB 테이블에 기록되며, 다음 날 09:00 UTC에 집계 우승자가 발표되고, 그 이후에는 원본 제출 데이터가 더 이상 필요하지 않다. 한 개발자가 각 item에 expires_on 속성(초 단위 Unix epoch time으로, submission_time + 86,400으로 설정)을 추가했으며, 개발 노력 최소로 오래된 제출이 자동으로 제거되기를 원한다. 어떤 솔루션이 이러한 요구 사항을 충족하는가?

스케줄된 Lambda로 item을 삭제할 수는 있지만, 만료된 item을 조회/scan하는 코드 작성 및 유지보수, pagination, 재시도, throttling 처리가 필요하다. 또한 DynamoDB read/write capacity를 소모하며 규모가 커지면 비용이 증가할 수 있다. DynamoDB TTL이 네이티브로 만료를 처리할 수 있는 상황에서 이는 불필요하게 더 많은 개발 및 운영 노력이 든다.

스케줄된 ECS Fargate task 실행은 운영 측면에서 Lambda보다 더 무겁다. container image, task definition, IAM role, networking, scheduling을 구축하고 유지해야 한다. 또한 만료된 item을 찾아 삭제하는 로직이 필요하며 DynamoDB capacity 사용량이 크게 늘 수 있다. TTL과 비교하면 “개발 노력 최소” 요구 사항을 충족하지 못한다.

AWS Glue는 ETL 및 데이터 처리 용도이며, DynamoDB item의 일상적인 운영 삭제에는 적합하지 않다. Glue job은 복잡하고 시작 시간이 더 느리며 추가 설정(job script, connection, scheduling)이 필요하다. scan 및 batch delete에 의존할 가능성이 높아 비용과 노력이 증가한다. 단순 item 만료에는 적절한 선택이 아니다.

DynamoDB TTL은 자동 item 만료를 위해 목적에 맞게 설계되었다. 테이블에서 TTL을 활성화하고 expires_on(초 단위 epoch)을 선택하면, DynamoDB가 스케줄된 job이나 커스텀 삭제 코드 없이 만료 후 item을 자동으로 삭제한다. 이는 개발 노력이 가장 적은 AWS 네이티브 솔루션이며, 오래된 제출을 자동으로 제거해야 한다는 요구 사항과 직접적으로 일치한다.

문제 분석

핵심 개념 - 이 문제는 지정된 만료 타임스탬프 이후 item을 자동으로 삭제하여 운영 및 개발 노력을 최소화하는 네이티브 기능인 Amazon DynamoDB Time to Live (TTL)을 테스트한다. 정답이 맞는 이유 - 개발자는 이미 expires_on 속성을 초 단위 Unix epoch timestamp(submission_time + 86,400)로 저장하고 있다. DynamoDB TTL은 정확히 이런 패턴을 위해 설계되었다. 각 item에 만료 시간을 표시해 두면 DynamoDB가 만료된 item을 자동으로 제거한다. 테이블에서 TTL을 활성화하고 expires_on을 지정하면, 커스텀 삭제 로직, 스케줄링, 또는 compute 인프라를 구축하지 않고도 오래된 제출을 제거한다는 요구 사항을 충족한다. 주요 AWS 기능 - DynamoDB TTL 요구 사항: 1) 테이블당 TTL attribute로 구성되는 단일 속성(여기서는 expires_on). 2) 초 단위 epoch time으로 저장된 값. 3) 애플리케이션 측 delete 호출 불필요; DynamoDB의 백그라운드 프로세스가 만료된 item을 삭제. 중요한 뉘앙스: TTL 삭제는 만료 시각에 정확히 수행되는 것이 보장되지 않으며, 일반적으로 수분에서 수시간 내에 수행된다. 하지만 이 시나리오에서는 다음 날 09:00 UTC에 우승자가 발표되고 그 이후 원본 제출이 “더 이상 필요하지 않다”는 것이지 “정확히 09:00:00에 반드시 삭제되어야 한다”는 의미가 아니므로 적합하다. TTL은 또한 주기적 scan 및 delete 작업을 피하므로 read/write capacity를 소모하지 않아 비용 효율적이다. 흔한 오해 - 많은 응시자가 Lambda/ECS/Glue job을 스케줄링하여 만료된 item을 scan으로 찾고 삭제해야 한다고 가정한다. 그러나 이 접근은 개발 노력 증가, 운영 오버헤드(스케줄링, 재시도, 오류 처리) 추가, 그리고 테이블 scan 및 delete throughput으로 인한 비용 증가를 초래한다. 또 다른 오해는 TTL을 정밀한 스케줄러로 기대하는 것인데, TTL은 실시간 삭제 보장이 아니라 eventual cleanup 메커니즘이다. 시험 팁 - DynamoDB item이 알려진 시간 이후 “자동으로 만료”되어야 한다는 요구가 보이면 TTL을 기본적인 최적 답으로 고려하라. 특히 item에 이미 epoch timestamp 속성이 존재한다면 더욱 그렇다. 엄격한 삭제 타이밍, 복잡한 선택 로직, 또는 TTL 범위를 넘어서는 다중 테이블 정리의 조정이 필요할 때만 커스텀 스케줄 삭제(Lambda/ECS/Glue)를 선택하라.

7
문제 7
(2개 선택)

한 스포츠 스트리밍 스타트업이 HLS 세그먼트와 정적 자산을 전송하기 위해 S3 origin 앞에 Amazon CloudFront를 배치합니다. 한 개발자가 각 edge location별 4xx/5xx 오류율과 이상 징후를 거의 실시간 업데이트(지연 ≤2초)로 시각화하는 대시보드가 필요합니다. 어떤 단계 조합이 이러한 요구 사항을 충족합니까? (두 개 선택)

S3로 전달되는 표준 CloudFront access logs는 거의 실시간이 아니며 전달이 일반적으로 지연됩니다(종종 수 분). 예약된 Athena 쿼리를 실행하면 지연이 더 늘어나고 배치 지향적입니다. 이 접근은 대시보드를 만들 수는 있지만, edge location별 4xx/5xx 시각화 및 이상 탐지를 ≤2초로 제공하는 요구 사항은 충족하지 못합니다.

CloudFront real-time logs는 저지연 모니터링을 위해 설계되었고 Amazon Kinesis Data Streams로 전달할 수 있습니다. 이는 ≤2초 요구 사항의 수집(ingestion) 측면을 충족하며, edge location/POP 및 status code를 포함한 필요한 필드를 제공하므로 edge location별 4xx/5xx 비율을 거의 실시간으로 계산할 수 있습니다.

AWS Lambda로 Kinesis stream을 소비하고 Amazon OpenSearch Service에 인덱싱하면 OpenSearch Dashboards에서 거의 실시간 검색/집계 및 대시보드 구성이 가능합니다. 이는 edge location별 오류율 시각화와 이상 탐지/알림 패턴 구현을 지원합니다. 옵션 B를 보완하여 대시보드에 필요한 분석 및 시각화 계층을 제공합니다.

“CloudFront logs를 Kinesis Data Firehose로 직접 스트리밍”이라는 진술은 문구 그대로는 최적의 선택이 아닙니다. CloudFront real-time logs는 기본적으로 Kinesis Data Streams와 통합되며, Firehose는 OpenSearch/S3로 전달할 수 있지만 일반적으로 데이터(크기/시간)를 버퍼링하므로 지연이 추가될 수 있고, 엄격한 ≤2초 요구 사항을 충족하지 못할 수 있습니다(소스 통합이 지원되고 버퍼를 매우 공격적으로 튜닝하지 않는 한).

CloudTrail은 거버넌스와 감사를 위한 AWS API 활동을 기록하는 서비스이며 CloudFront viewer request/response logs가 아닙니다. CDN access logs를 CloudTrail로 보내는 것은 유효한 패턴이 아니고, CloudTrail 기반 알람/대시보드는 edge location별 4xx/5xx 요청 오류 분석을 거의 실시간 업데이트로 제공하지 못합니다.

문제 분석

핵심 개념: 이 문제는 거의 실시간 분석을 위한 CloudFront 관측 가능성(Observability)을 테스트합니다. 핵심 서비스는 CloudFront real-time logs(서브초~수 초 수준 전달), 저지연 수집을 위한 Kinesis Data Streams, 그리고 edge location별 4xx/5xx 비율과 이상 징후를 시각화하기 위한 거의 실시간 분석/대시보드 계층(일반적으로 OpenSearch)입니다. 정답이 맞는 이유: 엔드투엔드 지연을 ≤2초로 달성하려면 S3로 보내는 표준 CloudFront access logs는 너무 느립니다(분 단위 전달). CloudFront real-time logs는 거의 실시간 모니터링을 위해 설계되었고 Kinesis Data Streams로 전달할 수 있습니다. 그 다음에는 edge location(예: x-edge-location / POP) 같은 차원으로 빠른 집계와 대시보드를 지원하는 데이터 저장소로 스트리밍 레코드를 변환/인덱싱해야 합니다. Lambda로 스트림을 소비해 Amazon OpenSearch Service에 인덱싱하면 OpenSearch Dashboards에서 오류율을 시각화하고 거의 실시간 새로고침으로 이상 탐지/알림을 수행할 수 있습니다. 주요 AWS 기능: - CloudFront real-time logs: 구성 가능한 샘플링 비율, status code/URI/edge location 등의 필드 포함, Kinesis Data Streams로 매우 낮은 지연으로 전달. - Kinesis Data Streams: shard 기반 처리량, 여러 소비자가 있을 경우 enhanced fan-out, 저지연 처리. - Lambda 스트림 처리: Kinesis에서 event source mapping, 배치/윈도잉, 재시도, DLQ 패턴. - OpenSearch Service + Dashboards: 거의 실시간 인덱싱 및 집계; POP별 오류율 시각화 구성 가능, (활성화된 경우) anomaly detection 기능 또는 커스텀 탐지기 사용. 흔한 오해: A는 Athena로 로그 분석이 쉬워 보여 매력적이지만, S3 로그 전달과 예약 쿼리는 2초 SLA를 충족할 수 없습니다. D는 Firehose가 OpenSearch로 전달할 수 있어 그럴듯하지만, CloudFront real-time logs는 Kinesis Data Streams와 통합되며(“직접” Firehose로는 아님), Firehose 버퍼링은 버퍼 설정에 따라 수 초~수 분 지연을 유발할 수 있습니다. E는 CloudTrail이 CDN 요청 로그가 아니라 API 감사용이므로 틀립니다. 시험 팁: CloudFront 요청 분석에서 “near-real-time(초 단위)”가 보이면 “CloudFront real-time logs → Kinesis Data Streams → 스트리밍 처리 → 실시간 분석 저장소(OpenSearch)”를 떠올리세요. “분~시간”이면 표준 로그를 S3로 보내고 Athena/EMR을 사용하는 패턴입니다. 또한 대상 통합을 확인하세요: CloudFront real-time logs는 기본적으로 Kinesis Data Streams를 지원하며(일부 맥락에서는 Kinesis Data Firehose도 가능하지만 옵션 문구가 중요), CloudTrail은 CloudFront access 이벤트의 로그 분석 싱크가 아닙니다.

8
문제 8

Company X의 개발자는 cross-account role arn:aws:iam::444455556666:role/SQSWriter를 assume하여 파트너 AWS account(account ID 444455556666)의 Amazon SQS queue에 메시지를 게시해야 합니다. 또한 회사는 virtual device arn:aws:iam::111122223333:mfa/dev1를 사용한 multi-factor authentication(MFA)을(6자리 token 및 60분 session duration) 의무화합니다. 이 액세스를 위한 temporary credentials를 얻기 위해 개발자가 MFA 파라미터와 함께 호출해야 하는 AWS Security Token Service(AWS STS) API operation은 무엇입니까?

AssumeRoleWithWebIdentity는 호출자가 OIDC provider의 web identity token을 제시할 때(예: Amazon Cognito, Google, EKS IRSA) 사용됩니다. 이 시나리오와는 맞지 않습니다. 개발자는 OIDC token을 사용하지 않고, cross-account IAM role ARN을 명시적으로 assume하며 MFA device ARN과 6자리 token code를 제공합니다. MFA를 포함한 전형적인 IAM role assumption에는 AssumeRole이 올바른 API입니다.

GetFederationToken은 federated user를 위한 temporary credentials를 얻는 데 사용되며, 일반적으로 특정 role을 다른 account에서 assume하지 않고 AWS 리소스에 액세스할 때 사용됩니다. 파트너 account의 arn:aws:iam::444455556666:role/SQSWriter 같은 명명된 role ARN에 대한 cross-account role assumption의 표준 메커니즘이 아닙니다. 또한 이러한 파트너 role에 대한 cross-account 액세스 패턴은 GetFederationToken이 아니라 sts:AssumeRole을 중심으로 설계됩니다.

AssumeRoleWithSAML은 SAML 2.0 identity provider를 통해 인증이 수행되고, 호출자가 SAML assertion을 제시하여 role credentials를 얻을 때 사용됩니다. 문제에는 SAML, IdP, SAML assertion에 대한 언급이 없고 virtual device와 token code를 사용하는 MFA만 언급됩니다. 따라서 이 옵션은 요구되는 입력과 설명된 액세스 패턴에 맞지 않습니다.

AssumeRole은 IAM role( cross-account role 포함)을 assume하여 temporary credentials를 얻기 위한 올바른 STS operation입니다. SerialNumber(MFA device ARN)와 TokenCode(6자리 코드)를 포함하여 MFA를 지원하며, 60분 session을 위해 DurationSeconds를 3600으로 설정하는 것도 지원합니다(role의 MaxSessionDuration에 따름). 이는 MFA와 함께 arn:aws:iam::444455556666:role/SQSWriter를 assume해야 한다는 요구사항과 정확히 일치합니다.

문제 분석

핵심 개념: 이 문제는 MFA를 포함한 cross-account 액세스를 위한 AWS STS role assumption을 테스트합니다. 개발자는 Amazon SQS로 메시지를 보내기 위해 파트너 account(444455556666)에서 role로 동작할 temporary credentials가 필요합니다. AWS에서 cross-account 액세스는 일반적으로 STS를 호출하여 대상 account의 role을 assume하고, temporary security credentials(AccessKeyId/SecretAccessKey/SessionToken)를 발급받는 방식으로 구현됩니다. 정답이 맞는 이유: 정답 API는 STS AssumeRole입니다. AssumeRole은 IAM role( cross-account role 포함)을 assume하기 위해 사용하는 표준 operation이며, MFA device ARN(SerialNumber)과 6자리 token(TokenCode)을 제공하여 MFA를 지원합니다. 또한 session duration(DurationSeconds) 지정도 지원하므로, 요구사항대로 3600초(60분)로 설정할 수 있습니다. 개발자는 AssumeRole을 RoleArn=arn:aws:iam::444455556666:role/SQSWriter, RoleSessionName, SerialNumber=arn:aws:iam::111122223333:mfa/dev1, TokenCode=<6-digit>, DurationSeconds=3600으로 호출합니다. 주요 AWS 기능 / 구성: 1) 파트너 account의 role trust policy는 source principal(111122223333의 user/role)이 sts:AssumeRole을 호출하도록 허용해야 합니다. 2) role(SQSWriter)에는 대상 queue에 대한 sqs:SendMessage 같은 권한이 있어야 합니다. 3) MFA 강제는 일반적으로 role trust policy에서 "aws:MultiFactorAuthPresent": "true"(및 선택적으로 "aws:MultiFactorAuthAge") 같은 condition으로 수행합니다. 그와 별개로 호출자는 STS에 SerialNumber와 TokenCode를 전달해야 합니다. 4) DurationSeconds는 role의 MaxSessionDuration 설정 범위 내여야 합니다(기본 1시간, 최대 12시간까지 구성 가능). 흔한 오해: 사람들은 AssumeRole을 federation API(GetFederationToken) 또는 identity-provider 기반 플로우(AssumeRoleWithSAML / AssumeRoleWithWebIdentity)와 혼동하곤 합니다. 하지만 이들은 호출자가 SAML/OIDC로 인증되었거나 federated user credentials가 필요한 경우에 사용되며, MFA와 함께 특정 IAM role ARN을 직접 assume하는 경우에는 해당하지 않습니다. 시험 팁: 문제에 RoleArn과 cross-account 액세스가 포함되어 있으면 기본적으로 AssumeRole을 선택합니다. SAML이 언급되면 AssumeRoleWithSAML, OIDC/web identity token(예: Cognito, EKS IRSA)이 언급되면 AssumeRoleWithWebIdentity를 선택합니다. MFA 파라미터(SerialNumber/TokenCode)는 전형적인 IAM role assumption 시나리오에서 AssumeRole을 강하게 시사합니다.

9
문제 9
(2개 선택)

한 개발자가 us-east-1에서 내부 API 서비스를 위한 AWS CloudFormation 템플릿을 작성하고 있으며, 별도의 CloudFormation 스택인 network-core에서 생성된 기존 interface VPC endpoint(서비스 이름 com.amazonaws.us-east-1.ssm)에 연결해야 합니다. 하지만 첫 실행에서 애플리케이션 스택이 다른 스택의 endpoint ID를 참조하려고 시도하면서 실패합니다. 어떤 템플릿 코딩 실수가 이 실패를 유발했을 수 있습니까? (두 개 선택)

반드시 그렇지는 않습니다. Ref는 동일 템플릿 내의 리소스 또는 parameter에 대한 값을 반환합니다(예: AWS::EC2::VPCEndpoint의 경우 Ref는 endpoint ID를 반환). 그러나 cross-stack 공유는 Ref만으로는 달성되지 않으며 export된 값을 import해야 합니다. 애플리케이션 스택은 ImportValue를 올바르게 사용하고 Ref를 직접 사용하지 않을 수도 있으므로, 이는 실패의 필수 원인이 아닙니다.

정답입니다. 다른 CloudFormation 스택이 생성한 값을 소비하려면 애플리케이션 템플릿이 export 이름을 참조하는 Fn::ImportValue(또는 !ImportValue)를 사용해야 합니다. ImportValue가 없으면 템플릿은 배포 시점에 network-core 스택의 endpoint ID를 해석할 수 없으며, 그 결과 미해결 참조, 누락된 parameter, 스택 간에 유효하지 않은 GetAtt/Ref 시도 등의 실패가 발생합니다.

오답입니다. Mappings 섹션은 정적 key/value lookup(예: region-to-AMI 매핑)을 위한 것이며, 런타임에 다른 스택에서 생성된 VPC endpoint ID를 동적으로 포함할 수 없습니다. Mappings에 endpoint ID를 포함하려면 hardcode해야 하며, 이는 목적에 어긋나고 취약합니다. cross-stack 리소스 공유는 Outputs/Export와 ImportValue를 사용해야 합니다.

정답입니다. 값을 제공하는 스택(network-core)은 Outputs 섹션에서 고유한 이름으로 Export를 사용해 VPC endpoint ID를 export해야 합니다. export 없이 단순히 output만 하거나 output 자체가 없으면 소비하는 스택이 이를 import할 수 없습니다. 이 경우 애플리케이션 스택 실행 시 “No export named X found”와 같은 CloudFormation 오류가 발생합니다.

오답입니다. CloudFormation은 Mappings 섹션에서 값을 export하는 것을 지원하지 않습니다. cross-stack reference를 위해 export할 수 있는 것은 Outputs뿐입니다. Mappings는 단일 템플릿 내에서 평가되며 다른 스택에서 참조할 수 없습니다. 따라서 Mappings에 export가 없다는 것은 의미 있는 개념이 아니며 근본 원인이 될 수 없습니다.

문제 분석

핵심 개념: 이 문제는 CloudFormation의 cross-stack reference를 테스트합니다. 한 스택(애플리케이션)이 다른 스택(network-core)에서 생성된 리소스 식별자가 필요할 때, 지원되는 패턴은 다음과 같습니다: 값을 제공하는 스택이 Outputs에서 Export로 값을 export하고, 값을 소비하는 스택이 Fn::ImportValue로 이를 import합니다. 이렇게 하면 명시적 dependency가 생성되고 CloudFormation이 배포 시점에 값을 해석할 수 있습니다. 정답이 맞는 이유: 첫 실행에서의 실패는 애플리케이션 스택이 유효한 cross-stack 메커니즘을 통해 제공되지 않는 endpoint ID를 참조하려고 시도하는 상황과 일치합니다. 애플리케이션 템플릿이 ImportValue(옵션 B)를 사용하지 않으면 다른 스택의 output을 합법적으로 가져올 수 없으며, hardcode, 로컬이 아닌 logical ID에 대한 GetAtt 사용, 제공되지 않은 parameter 참조 등의 시도는 실패합니다. 또한 network-core 스택이 Outputs에서 VPC endpoint ID를 export하지 않으면(옵션 D) ImportValue가 import할 대상이 없으므로 CloudFormation은 “Export not found” 유형의 메시지로 오류를 발생시킵니다. 주요 AWS 기능: CloudFormation Export는 Outputs 섹션에서만 Export: { Name: ... }로 정의됩니다. 소비자는 Fn::ImportValue(또는 !ImportValue)를 사용해 이를 가져옵니다. Export는 region 단위(두 스택 모두 us-east-1이어야 함)이며 account/region 내에서 이름이 고유해야 합니다. 이 패턴은 VPC ID, subnet ID, security group ID, VPC endpoint ID를 스택 간에 공유하는 데 흔히 사용됩니다. 흔한 오해: Ref(옵션 A)는 동일 템플릿 내 리소스의 physical ID를 얻는 데 필요하지만, 그 자체로는 스택 경계를 넘지 못합니다. Mappings(옵션 C 및 E)은 정적 lookup table이며 배포 시점에 생성되는 리소스 ID를 동적으로 공유하는 메커니즘이 아닙니다. 시험 팁: “스택 A가 스택 B의 리소스가 필요”한 경우, 스택 B의 Outputs+Export와 스택 A의 ImportValue를 찾으십시오. 어느 한쪽이라도 누락되면 배포가 실패합니다. 또한 export는 region 단위이고 이름이 고유해야 한다는 점을 기억하십시오. export 이름 불일치 또는 서로 다른 region에 배포하는 것은 유사한 오류의 흔한 실제 원인입니다.

10
문제 10

개발자가 비디오 스트리밍 플랫폼을 위한 구독 활성화 워크플로를 오케스트레이션하기 위해 AWS Step Functions state machine을 구축하고 있습니다. 새 구독 요청이 도착하면 state machine은 외부 결제 시스템이 결제를 확인할 때까지 일시 중지해야 합니다. 결제 시스템은 과금이 성공하면 partition key가 subscriptionId인 확인 항목을 BillingConfirmations라는 Amazon DynamoDB 테이블에 기록합니다. 개발자는 유휴 컴퓨팅을 최소화하고 장시간 실행되는 함수를 피하면서, 일치하는 확인 항목이 존재한 이후에만 워크플로가 재개되도록 워크플로를 완성해야 합니다. 이 요구 사항을 충족하는 솔루션은 무엇입니까?

정답입니다. 이는 AWS SDK integration을 통해 DynamoDB GetItem을 사용한 효율적인 Step Functions 폴링 루프를 구현하고, 이어서 Choice state를 사용합니다. 항목이 없으면 Wait state가 컴퓨팅을 소비하지 않고 워크플로를 일시 중지한 뒤 재시도합니다. 이는 장시간 실행되는 Lambda 함수를 피하면서 “일치하는 항목이 존재한 이후에만 재개” 요구 사항을 충족하고 유휴 컴퓨팅을 최소화합니다.

오답입니다. DynamoDB Streams는 Lambda를 트리거할 수 있지만, Step Functions는 현재 실행 중(대기 중)인 execution을 재개하기 위한 “redrive execution” 메커니즘을 제공하지 않습니다. redrive는 실패한 execution을 다시 시작하는 데 사용되며(그리고 특정 워크플로/구성에서만 가능), 외부 이벤트로부터 재개하려면 callback task token과 SendTaskSuccess/SendTaskFailure가 필요하지만 여기에는 설명되어 있지 않습니다.

오답입니다. 현재 execution을 중지하고 처음부터 새 execution을 시작하는 것은 전체 state machine이 안전한 재실행을 위해 설계되지 않는 한 워크플로의 정확성과 idempotency를 깨뜨립니다. 또한 중복 부작용(예: 활성화 단계 재전송) 위험이 있고 운영 복잡성을 증가시킵니다. 이는 일시 중지된 워크플로를 올바른 지점에서 단순히 “재개”해야 한다는 요구 사항을 충족하지 않습니다.

오답입니다. DynamoDB를 지속적으로 폴링하는 Lambda 함수는 문제에서 경고하는 “장시간 실행되는 함수” 안티패턴 그 자체입니다. 대기하는 동안 컴퓨팅을 소비하고 Lambda timeout 제한에 걸릴 수 있으며, 내구성 있는 Step Functions Wait state보다 신뢰성이 떨어집니다. 대기는 Step Functions가 처리해야 하며, Lambda를 busy-wait 루프로 사용해서는 안 됩니다.

문제 분석

핵심 개념: 이 문제는 컴퓨팅을 소비하지 않고 외부 이벤트를 기다리기 위한 AWS Step Functions 오케스트레이션 패턴을 테스트합니다. 핵심 개념은 Step Functions service integration(AWS SDK integration)과 Wait state를 사용하여, 네이티브 callback 패턴을 사용할 수 없을 때 효율적인 폴링을 구현하는 것입니다. 정답이 맞는 이유: 옵션 A는 Step Functions가 DynamoDB GetItem을 직접 호출(Lambda 없음)하고 확인 항목의 존재 여부에 따라 분기합니다. 항목이 존재하지 않으면 워크플로는 Wait state(예: 5분)로 들어간 다음 다시 확인합니다. Wait state 동안 Step Functions는 컴퓨팅을 실행하지 않고 상태만 저장하므로, 유휴 컴퓨팅을 최소화하고 장시간 실행되는 함수를 피할 수 있습니다. 이는 일치하는 항목이 존재한 이후에만 재개되어야 한다는 요구 사항을 충족하며 Lambda 함수를 계속 실행해 두지 않습니다. 주요 AWS 기능: - DynamoDB용 Step Functions AWS SDK service integration(예: dynamodb:GetItem)은 Lambda “glue code”를 제거하고 비용/운영 오버헤드를 줄입니다. - Wait state는 내구성 있는 저비용 일시 중지를 제공합니다. Choice state와 결합하면 표준 “backoff를 포함한 폴링” 패턴을 형성합니다. - partition key로 DynamoDB GetItem을 수행하는 것은 효율적이며, 필요 시 strongly consistent read를 활성화(더 높은 RCU 비용)하여 오래된 데이터를 읽을 가능성을 줄일 수 있습니다. - 이는 Well-Architected 원칙과 부합합니다: 비용 최적화(유휴 Lambda 없음), 신뢰성(내구성 있는 상태), 운영 우수성(구성 요소 감소). 흔한 오해: 많은 사람들이 DynamoDB Streams가 실행 중인 Step Functions execution을 “재개”할 수 있다고 가정합니다. 그러나 Step Functions는 stream 이벤트로부터 임의의 “execution 재개” API를 지원하지 않습니다. callback 패턴은 명시적인 task token(SendTaskSuccess/SendTaskFailure)과 그 token을 보유한 worker가 필요하지만, 이 문제의 선택지는 이를 올바르게 구현하지 않습니다. 또 다른 오해는 장시간 실행되는 Lambda 폴러를 사용하는 것인데, 이는 컴퓨팅을 낭비하고 time out 위험이 있습니다. 시험 팁: “외부 시스템이 확인할 때까지 일시 중지”와 “유휴 컴퓨팅 최소화”가 보이면 먼저 Step Functions Wait state와 callback 패턴을 떠올리십시오. task token/callback 옵션이 제공되지 않는다면, 시험에서 선호되는 솔루션은 종종 Lambda를 피하기 위해 AWS SDK integration을 사용한 “Wait + 재확인”입니다. 또한 “실행 중인 execution을 재개하기 위한 redrive” 같은 유효하지 않은 Step Functions 동작을 주의하십시오. redrive는 대기 중인 execution이 아니라 실패한 execution을 대상으로 합니다.

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

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