연습 문제

문제 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을 반환하게 하려면 개발자가 무엇을 변경해야 합니까?

문제 2

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

문제 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이 새 코드를 적용하도록 하려면 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 배포 패키지가 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

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

문제 분석

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

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

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

문제 분석

핵심 개념 - 이 문제는 지정된 만료 타임스탬프 이후 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

(2개 선택)

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

문제 분석

핵심 개념: 이 문제는 거의 실시간 분석을 위한 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

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은 무엇입니까?

문제 분석

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

(2개 선택)

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

문제 10

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

문제 분석

핵심 개념: 이 문제는 컴퓨팅을 소비하지 않고 외부 이벤트를 기다리기 위한 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을 대상으로 합니다.

Practice Test #4

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(8)

다른 모의고사

Practice Test #1

Practice Test #2

Practice Test #3

Practice Test #5

Practice Test #6

지금 학습 시작하기