AWS
AWS Certified Developer - Associate (DVA-C02)
548+ 기출 문제 (AI 검증 답안 포함)
실제 시험
기출 문제
상세
해설
실제 시험과
가장 유사AI 기반
3중 AI 검증 답안 및 해설
모든 AWS Certified Developer - Associate (DVA-C02) 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
시험 도메인
실전 문제
한 원격의료 스타트업은 12개의 파트너 클리닉이 presigned URL을 사용하여 최대 5 GB의 DICOM 이미지를 Amazon S3 bucket에 업로드하는 웹 포털을 운영하고 있습니다. 회사는 모든 업로드/다운로드에 대해 전송 중 암호화를 강제해야 하며, 환자 식별자가 포함된 모든 object는 보안 팀이 필요 시 온디맨드로 rotation할 수 있는 AWS KMS key로 저장 시 암호화되도록 보장해야 합니다. 어떤 단계 조합이 이러한 요구 사항을 충족합니까? (두 개 선택)
오답. IAM permissions boundary는 IAM principal(user/role)에 연결되어 부여될 수 있는 최대 권한을 제한합니다. S3 요청에 대해 HTTPS/TLS를 강제하지 않으며 aws:SecureTransport 같은 condition으로 평가되지도 않습니다. S3의 전송 보안은 permissions boundary가 아니라 bucket policy(또는 CloudFront)로 강제합니다.
오답. S3 bucket policy는 “client-side encryption”을 활성화할 수 없습니다. Client-side encryption은 업로드 전에 클라이언트/애플리케이션(예: AWS Encryption SDK)이 수행하며, S3는 이를 policy로 강제할 메커니즘이 없습니다. Bucket policy는 SSE-KMS 같은 server-side encryption header를 요구할 수는 있지만, 업로드 payload가 업로드 전에 암호화되었는지는 보장할 수 없습니다.
정답입니다. patient identifiers를 포함하는 객체에만 KMS 기반 보호가 필요하므로, 애플리케이션 또는 업로드 워크플로는 파일이 Amazon S3에 저장되기 전에 어떤 파일이 그 조건을 충족하는지 판단해야 합니다. 그런 다음 워크플로는 customer managed key를 사용하는 AWS KMS 암호화로 해당 객체를 업로드할 수 있으며, 이를 통해 보안 팀이 key rotation과 key policy 관리를 제어할 수 있습니다. S3는 객체 내용을 검사하여 파일 내부 데이터에 따라 선택적으로 KMS 암호화를 적용할 수 없으므로, 이것이 사용 가능한 최선의 옵션입니다.
정답입니다. aws:SecureTransport 조건을 사용하는 bucket policy는 HTTP로 전송된 모든 요청을 거부하고 HTTPS 요청만 허용할 수 있습니다. 이는 presigned URLs를 통한 액세스를 포함하여 PUT 및 GET 작업 모두에 대해 전송 중 암호화를 강제합니다. 이것은 Amazon S3 액세스 시 TLS를 요구하기 위한 표준 AWS 메커니즘입니다.
오답. S3 Block Public Access는 public ACL 및 public bucket policy가 public access를 부여하는 것을 방지합니다. 이는 HTTPS-only 접근을 강제하지 않으며 전송 중 암호화를 보장하지도 않습니다. 모범 사례로 BPA를 활성화할 수는 있지만, 그것만으로는 명시된 전송 암호화 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념: 이 문제는 Amazon S3 업로드 및 다운로드에 대한 두 가지 별도 제어를 테스트합니다: 전송 중 암호화 강제와 민감한 객체가 저장 시 AWS KMS customer managed keys로 보호되도록 보장하는 것입니다. S3에서는 aws:SecureTransport 조건을 사용하는 bucket policy로 HTTPS 전용 액세스를 강제합니다. customer-controlled key rotation을 통한 저장 시 보호를 위해서는, S3가 객체 내용을 검사하여 어떤 객체에 patient identifiers가 포함되어 있는지 자동으로 판단할 수 없으므로, 업로드 프로세스가 해당 조건에 맞는 객체를 AWS KMS customer managed keys를 사용해 저장하도록 보장해야 합니다. 정답인 이유: 옵션 D가 정답인 이유는 S3 bucket policy가 aws:SecureTransport를 확인하여 TLS를 사용하지 않는 모든 요청을 거부할 수 있기 때문입니다. 이는 presigned URLs로 이루어지는 요청을 포함하여 업로드와 다운로드 모두에 적용됩니다. 옵션 C는 선택적 저장 시 암호화 요구 사항에 가장 잘 부합하는데, 애플리케이션 워크플로가 어떤 객체에 patient identifiers가 포함되어 있는지 식별한 다음, 해당 객체를 customer managed key를 사용하는 KMS 기반 암호화로 업로드해야 하기 때문입니다. 주요 AWS 기능: - HTTPS를 요구하기 위한 aws:SecureTransport 조건이 포함된 S3 bucket policy. - 보안 팀이 rotation을 제어해야 할 때 저장 시 암호화를 위한 AWS KMS customer managed keys. - S3는 객체 내용을 자동으로 분류하지 않으므로, 어떤 업로드에 KMS 보호가 필요한지 결정하는 애플리케이션 측 로직. 흔한 오해: - Bucket policies는 HTTPS를 강제하고 server-side encryption headers를 요구할 수는 있지만, 객체에 patient identifiers가 포함되어 있는지 판단하기 위해 DICOM 내용을 검사할 수는 없습니다. - S3 Block Public Access는 전송 암호화와 관련이 없으며 HTTPS를 강제하지 않습니다. - IAM permissions boundaries는 S3 요청이 TLS를 사용하는지 여부를 제어하지 않습니다. 시험 팁: 문제에서 S3로의 전송 중 암호화를 묻는다면, bucket policy의 aws:SecureTransport를 찾으세요. 일부 객체에만 더 강력한 저장 시 보호가 필요한 경우, 어떤 객체가 customer managed key를 사용하는 SSE-KMS를 사용해야 하는지 애플리케이션 또는 업로드 워크플로가 결정해야 한다고 예상하세요. 요구 사항에 보안 팀의 제어 하에 있는 key rotation이 언급되면, AWS managed keys보다 AWS KMS customer managed keys를 우선 선택하세요.
한 핀테크 스타트업은 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를 통해 업데이트된 자산이 즉시 전달되도록 어떻게 보장해야 합니까?
S3 Object Lock은 보존 기간 동안 객체의 삭제 또는 수정을 방지하는 데이터 보호/컴플라이언스 기능(WORM)입니다. CloudFront 캐싱을 제어하거나 edge location이 업데이트된 객체를 다시 가져오도록 강제하지 않습니다. 오히려 보존 설정에 따라 객체 덮어쓰기를 방해할 수 있어, 이 배포 시나리오와 무관하며 잠재적으로 해로울 수 있습니다.
이전 버전(또는 noncurrent version)을 삭제하는 S3 lifecycle policy는 스토리지 관리와 비용에 영향을 줄 뿐, CloudFront edge cache에는 영향을 주지 않습니다. S3에서 이전 버전이 제거되더라도 CloudFront는 TTL이 만료되거나 invalidation이 발생할 때까지 이전에 캐시된 객체를 계속 제공할 수 있습니다. 또한 lifecycle policy는 일정에 따라 동작하며, 배포 직후 즉시 캐시를 갱신하는 메커니즘이 아닙니다.
CloudFront invalidation은 TTL 만료 전에 edge location에서 캐시된 객체를 명시적으로 제거합니다. S3에 새 빌드를 배포하면서 동일 키를 덮어쓴 뒤, 변경된 경로(특정 파일 또는 /*)를 invalidation하면 다음 viewer 요청에서 CloudFront가 S3에서 최신 객체를 가져오게 됩니다. 이는 파일명/경로가 고정되어 있고 TTL이 긴 경우 CloudFront를 즉시 갱신하는 올바른 방법입니다.
각 배포마다 CloudFront origin 버킷을 변경하는 것은 안티패턴입니다. 운영 복잡성을 증가시키고 설정 오류 위험을 높이며, 표준 CI/CD 관행과도 맞지 않습니다. 다른 origin에서 가져오도록 강제할 수는 있지만, invalidation이나 버전이 포함된 자산 파일명에 비해 불필요하고 파괴적입니다. 또한 확장성이 떨어지고 권한, OAC/OAI 설정, DNS 동작을 깨뜨릴 수 있습니다.
문제 분석
핵심 개념: 이 문제는 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을 선택하세요.
개발자가 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과 함께 사용할 때 최적입니다.
원격의료 플랫폼이 전국 단위 교육 웨비나를 출시하고 있으며, 동시 세션이 급증함에 따라 DevOps 팀은 WebRTC signaling 서비스를 실행하는 Amazon EC2 인스턴스가 10분 연속으로 CPU utilization 85%를 초과할 경우 알림을 받아야 합니다. 이를 통해 온콜 엔지니어가 용량을 확장할 수 있어야 합니다. 어떤 솔루션이 이 요구 사항을 충족합니까?
정답입니다. CloudWatch Alarms는 CPUUtilization 같은 EC2 metrics를 정의된 시간 창에서 threshold와 비교 평가하도록 설계되었습니다. 85% 초과 상태가 10분 연속 유지되도록 알람을 구성하고(예: 1-minute period에 10 evaluation periods, 또는 5-minute period에 2 evaluation periods), 알람 action을 SNS topic으로 publish하도록 설정합니다. 이는 metric 기반 alerting을 위한 표준적이며 운영 부담이 적은 솔루션입니다.
오답입니다. AWS CloudTrail은 CPU utilization metrics를 추적하지 않으며, 거버넌스, 컴플라이언스, 감사 목적의 API calls 및 account activity를 기록합니다. 데이터 소스가 잘못되었기 때문에 CPUUtilization에 대한 의미 있는 “CloudTrail alarm”을 만들 수 없습니다. 운영 metrics와 threshold에는 CloudTrail이 아니라 CloudWatch가 올바른 서비스입니다.
오답입니다. aws ssm describe-instance-information을 실행하는 cron job은 CPU utilization을 제공하지 않으며 신뢰할 수 있는 모니터링 방식이 아닙니다. 또한 운영 부담을 증가시키고, 인스턴스 credentials/permissions가 필요하며, 인스턴스가 비정상일 때(바로 모니터링이 가장 필요한 상황) 실패할 수 있습니다. CloudWatch는 custom scripts 없이도 CPU metrics를 이미 수집합니다.
오답입니다. CloudTrail logs에는 CPUUtilization metrics가 포함되어 있지 않으므로 Lambda로 이를 스캔해 지속적인 CPU threshold를 감지할 수 없습니다. 설령 metrics가 다른 곳에 있더라도, 10분마다 polling하고 custom evaluation logic을 구현하는 것은 불필요하며, evaluation periods, missing data 동작, alarm state 전환을 기본 제공하는 CloudWatch Alarms보다 견고하지 않습니다.
문제 분석
핵심 개념: 이 문제는 EC2 metrics에 대한 Amazon CloudWatch 모니터링 및 알람, 그리고 알림을 위한 Amazon SNS 사용을 평가합니다. CPU utilization은 CloudWatch에 게시되는 표준 EC2 metric이며, CloudWatch Alarms는 시간에 따른 metric threshold를 평가하고 작업을 트리거하는 기본 메커니즘입니다. 정답인 이유: 옵션 A는 EC2 인스턴스의 CPUUtilization metric에 대해 threshold 85%와 10분 지속 초과 조건을 갖는 CloudWatch alarm을 사용합니다. CloudWatch에서 “10분 연속”은 Period와 EvaluationPeriods를 적절히 설정하여 구현합니다(예: Period=60 seconds, EvaluationPeriods=10, DatapointsToAlarm=10으로 10개 datapoint 모두가 초과하도록 요구). 알람이 ALARM state로 전환되면 SNS topic으로 게시할 수 있고, SNS는 email, SMS 또는 통합(PagerDuty, Opsgenie 등)을 통해 온콜 엔지니어에게 알릴 수 있습니다. 이는 최소한의 운영 오버헤드로 요구 사항을 직접 충족합니다. 주요 AWS 기능: - CloudWatch EC2 metrics: CPUUtilization은 기본적으로 제공됩니다(basic monitoring은 5-minute granularity, detailed monitoring은 1-minute granularity). “10분 연속”을 신뢰성 있게 평가하려면 detailed monitoring을 활성화하거나 5-minute period와 2 evaluation periods를 사용합니다. - CloudWatch Alarm 구성: Threshold, Period, EvaluationPeriods, DatapointsToAlarm, TreatMissingData(일반적으로 데이터 공백 시 false alarm을 피하기 위해 “notBreaching”로 설정). - SNS notifications: 알림을 수신자와 분리하며 여러 subscriber와 protocol을 지원합니다. 흔한 오해: 자주 있는 함정은 CloudTrail에 성능 metrics가 포함된다고 가정하는 것입니다. CloudTrail은 API activity(누가, 무엇을, 언제 했는지)를 기록하며 CPU utilization은 기록하지 않습니다. 또 다른 오해는 CloudWatch가 기본적으로 제공하는 기능을 대신해 custom script나 Lambda log scanning을 구축하는 것으로, 이는 복잡성을 높이고 신뢰성을 낮춥니다. 시험 팁: “metric이 X를 Y분 동안 초과하면 알림”을 보면 먼저 CloudWatch Alarm을 떠올리십시오. 알림에는 SNS를 사용합니다. CloudTrail은 운영 metrics가 아니라 API calls 감사(auditing) 용도임을 기억하십시오. 또한 metric granularity를 고려하십시오. “연속 분”의 정밀도를 위해 1-minute detailed monitoring이 필요한 경우가 많습니다.
한 팀이 AWS Serverless Application Model (AWS SAM)을 사용하여 비디오 분석 마이크로서비스를 배포하고 있습니다. 이 마이크로서비스에는 AWS Lambda 함수 1개(메모리 512 MB, reserved concurrency 5)와 media-logs-789라는 이름의 Amazon S3 bucket 1개가 포함되어 있으며, 이 bucket은 incoming/ prefix 아래에 입력 파일을 저장합니다. 자동화된 배포의 일부로, 해당 함수는 그 bucket과 prefix에서만 객체를 읽을 수 있어야 하며(쓰기 또는 삭제는 불가) 어떻게 개발자가 필요한 read-only access를 부여하도록 SAM template을 구성해야 합니까?
Lambda authorizer는 Amazon API Gateway에서 API method에 대한 access를 제어하는 데 사용됩니다. 이는 Lambda 함수가 S3 APIs를 호출할 수 있는 권한을 부여하지 않습니다. 함수가 S3에서 읽을 수 있는지는 authorizer가 아니라 execution role IAM policies(그리고 경우에 따라 bucket policy)에 의해 결정됩니다. 이 선택지는 API에 대한 request authorization과 서비스 간 IAM permissions를 혼동하고 있습니다.
S3 bucket policy를 “Lambda 함수에” 연결할 수는 없습니다. Bucket policies는 S3 bucket에 연결되는 resource-based policies입니다. Bucket policy가 Lambda execution role에 access를 부여할 수는 있지만, SAM에서 동일 account access에 대해 가장 깔끔하거나 일반적인 접근은 아니며 과도한 권한을 부여하기 쉽습니다. 질문은 read-only access를 부여하도록 SAM template을 어떻게 구성하는지 묻고 있으며, 이는 함수 role에서 처리하는 것이 가장 적절합니다.
SQS는 queue( topic이 아님)이며, S3 objects에 대한 read permissions를 부여하는 것과는 관련이 없습니다. 객체가 생성될 때 S3 event notifications를 사용해 SQS로 메시지를 보낼 수는 있지만, 그것이 Lambda 함수가 객체를 읽도록 authorize하지는 않습니다. 여전히 s3:GetObject(그리고 경우에 따라 s3:ListBucket)에 대한 IAM permissions가 필요합니다. 이 선택지는 event-driven ingestion과 access control을 혼합하고 있습니다.
S3ReadPolicy는 S3에 대한 read-only access를 부여하도록 설계된 AWS SAM policy template입니다. Lambda 함수의 Policies 속성 아래에 추가하고 media-logs-789 bucket과 incoming/ prefix로 scope 지정하면, SAM이 함수의 execution role에 필요한 IAM statements를 생성합니다. 이는 자동화된 최소 권한 access(read-only, write/delete 없음)를 제공하며, SAM-native로 의도된 해결책입니다.
문제 분석
핵심 개념: 이 문제는 자동화된 배포 중에 특정 범위로 제한된 Amazon S3 read-only access를 Lambda execution role에 부여하기 위해, 최소 권한(least-privilege) IAM permissions에 대한 AWS SAM의 built-in policy templates를 테스트합니다. 정답이 맞는 이유: SAM에서 Lambda 함수에 권한을 부여하는 권장 방식은 Policies 속성을 통해 함수의 execution role에 IAM policies를 연결하는 것입니다. SAM은 deploy 시점에 올바른 IAM statements로 확장되는 managed “policy templates”(예: S3ReadPolicy)를 제공합니다. S3ReadPolicy를 사용하고 이를 특정 bucket(media-logs-789)과 prefix(incoming/)로 scope 지정하면, 함수는 필요한 권한만 받게 됩니다. 일반적으로 해당 bucket/prefix에 대해 s3:GetObject(그리고 종종 prefix condition이 포함된 s3:ListBucket)를 부여하며, write 또는 delete action은 포함하지 않습니다. 이는 최소 권한 원칙에 부합하며 SAM template 내에서 완전 자동화가 가능합니다. 주요 AWS 기능: - AWS SAM policy templates: 수동으로 policy를 작성하는 것보다 IAM authoring을 단순화하고 실수를 줄입니다. - Lambda execution role: Lambda service가 AWS APIs(S3 등)를 호출하기 위해 assume하는 role입니다. - Prefix scoping: object ARN을 arn:aws:s3:::media-logs-789/incoming/* 로 제한하고, 필요 시 ListBucket을 bucket ARN에 대해 s3:prefix conditions로 제한하여 달성합니다. - Infrastructure as Code: 권한이 SAM/CloudFormation을 통해 버전 관리되고 일관되게 배포됩니다. 흔한 오해: 자주 있는 혼동은 S3 access가 “Lambda 함수에 대한 bucket policy”로 부여된다고 생각하는 것입니다. Bucket policies는 함수가 아니라 bucket 리소스에 연결되며, 일반적으로 cross-account access 또는 제약을 강제하는 데 사용됩니다. 또 다른 오해는 reads를 “활성화”하기 위해 관련 없는 서비스(authorizers, SQS)를 도입하는 것이지만, reads는 eventing이나 API gateway authorizers가 아니라 IAM authorization으로 제어됩니다. 시험 팁: SAM 문제에서는 AWS::Serverless::Function의 “Policies:”를 확인하고, 요구사항이 단순할 때는 SAM policy templates(S3ReadPolicy, DynamoDBReadPolicy 등)를 우선 선택하십시오. 항상 최소 권한 및 Well-Architected Security best practices를 충족하도록 권한을 가장 작은 리소스 집합(bucket + prefix)과 최소 action(read-only)으로 scope 지정하십시오.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
한 물류 회사가 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)를 구분하세요.
한 회사가 Amazon ECS에서 AWS Fargate로 결제-승인 microservice를 실행하고 있으며, 각 승인은 2초 이내에 완료되어야 합니다. 단일 승인이라도 2초 이상 걸리면 개발 팀에 알림이 가야 합니다. 개발자는 운영 오버헤드를 최소화하면서 타이밍 측정과 알림을 어떻게 구현할 수 있습니까?
정답입니다. 각 authorization의 지연 시간을 CloudWatch custom metric으로 게시하는 것은 관리형 AWS 서비스에서 타이밍 데이터를 수집하는 가장 오버헤드가 낮은 방법입니다. 2초 이상 걸리는 단 한 번의 authorization이라도 알림을 트리거해야 한다는 요구 사항을 충족하려면, CloudWatch alarm은 해당 기간의 Maximum statistic을 2000 ms 임계값과 비교해 평가해야 합니다. SNS는 CloudWatch alarms의 표준 관리형 알림 대상이므로, 이 설계는 적시에 알림을 제공하면서도 custom code와 운영 부담을 최소화합니다.
오답입니다. SQS와 custom consumer로 >2000 ms 값을 감지할 수는 있지만 운영 오버헤드가 증가합니다. consumer를 빌드, 배포, scaling, 모니터링해야 하고, 실패, retry, poison message를 처리해야 합니다. CloudWatch alarm이 임계값을 네이티브하게 평가하고 SNS 알림을 트리거할 수 있는데, 이는 운영 오버헤드가 최소인 해법이 아닙니다.
오답입니다. 1분 평균에 대한 alarm은 단일 느린 승인을 놓칠 수 있습니다. 한 요청이 2초를 초과하더라도 평균이 2000 ms 아래로 유지될 수 있기 때문입니다. 또한 SES는 CloudWatch alarm 알림에 대한 표준 서비스가 아닙니다(SNS가 표준). 따라서 “단일 승인” 요구 사항을 충족하지 못합니다.
오답입니다. 이 사용 사례에는 Kinesis가 불필요하며 운영 복잡성과 비용을 추가합니다. 또한 CloudWatch alarm은 Kinesis record 내부의 “어떤 stream 값”을 직접 평가하지 못합니다. 값을 추출하고 metric을 게시하려면 여전히 consumer(Lambda/KCL)가 필요합니다. 이는 CloudWatch custom metric을 직접 사용하는 것에 비해 운영 오버헤드 최소 요구 사항에 어긋납니다.
문제 분석
핵심 개념: 이 문제는 ECS on Fargate 마이크로서비스에 대해 오버헤드가 낮은 지연 시간 모니터링 및 알림을 구현하는 방법을 테스트합니다. 가장 적합한 AWS 네이티브 접근 방식은 authorization 지연 시간을 CloudWatch custom metric으로 게시하고 CloudWatch alarm을 사용해 Amazon SNS를 통해 알림을 보내는 것입니다. 정답인 이유: 요구 사항은 단 한 번의 authorization이라도 2초 이상 걸리면 팀에 알리는 것입니다. 각 authorization의 처리 시간을 custom metric datapoint로 게시하면, 개발자는 Maximum statistic에 대해 임계값을 2000 ms로 설정한 CloudWatch alarm을 구성할 수 있습니다. 그러면 평가 기간 내 어떤 datapoint라도 2000 ms 이상이면 alarm이 트리거됩니다. SNS는 CloudWatch alarm의 표준 관리형 알림 대상이므로 운영 오버헤드를 낮게 유지할 수 있습니다. 주요 AWS 기능: - CloudWatch custom metrics: authorization별 지연 시간 값을 밀리초 단위로 게시하며, 필요에 따라 service name 또는 environment 같은 dimensions를 포함할 수 있습니다. - CloudWatch alarms: 짧은 period를 구성하고 Maximum statistic을 평가하여, 해당 기간 내 단 한 번의 느린 authorization만으로도 임계값 초과가 발생하도록 할 수 있습니다. high-resolution metrics를 사용하면 응답성을 높일 수 있습니다. - Amazon SNS: email, SMS, HTTPS endpoint 또는 incident-management integration으로 관리형 fan-out 알림을 제공합니다. 흔한 오해: 흔한 실수 중 하나는 평균 지연 시간 alarm이 개별적으로 느린 요청을 잡아낼 것이라고 가정하는 것입니다. 평균값은 이상치를 숨길 수 있습니다. 또 다른 오해는 단순한 임계값 감지를 위해 SQS 또는 Kinesis 같은 서비스가 필요하다고 생각하는 것이지만, 이런 서비스는 불필요한 consumer와 운영 복잡성을 추가합니다. 또한 CloudWatch alarms는 기간별 metric statistic을 기준으로 동작하므로, Maximum 같은 올바른 statistic을 사용하는 것이 중요합니다. 시험 팁: 요구 사항이 '단일 요청 하나라도 임계값을 초과하면 알림'이고 운영 오버헤드를 최소화해야 한다면, custom CloudWatch metric + Maximum 기준 alarm + SNS를 떠올리세요. 문제가 명시적으로 custom processing, replay 또는 downstream analytics를 요구하지 않는 한 queue 또는 stream consumer를 구축해야 하는 솔루션은 피하세요. 'any single event'와 'average over time' 같은 표현 차이에 특히 주의하세요.
한 팀이 이미지를 리사이즈하는 기존 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 변경 옵션을 배제해야 한다.
미디어 스트리밍 회사가 마이크로서비스 코드를 AWS CodeCommit에 저장하고 있으며, 컴플라이언스 요구사항으로 단위 테스트가 100% 통과해야 하고 상세 테스트 리포트는 60일 동안 보관되며 감사인이 열람할 수 있어야 합니다. main 및 develop 브랜치에 대해 하루 약 15회 커밋이 발생하는 상황에서, 팀은 각 커밋마다 Linux 빌드 환경에서 서비스를 자동으로 빌드하고 단위 테스트를 실행하며, 커스텀 UI를 만들지 않고도 탐색 가능한 JUnit 스타일 리포트를 생성해야 합니다. 또한 최소 8개의 동시 빌드를 지원하고 리포트를 중앙에서 접근 가능하게 유지해야 합니다. 어떤 솔루션이 이러한 요구사항을 충족합니까?
오답. AWS CodeDeploy는 EC2, Lambda 또는 ECS로 애플리케이션을 배포하고 배포 훅을 조정하도록 설계되었으며, CI 단위 테스트 및 풍부한 테스트 리포트 시각화를 위한 서비스가 아닙니다. 결과를 CloudWatch 메트릭으로 게시하는 것은 감사인을 위한 탐색 가능한 JUnit 스타일 리포트를 생성하지 못하며, 상세한 테스트 케이스 단위 결과를 해석하려면 추가 도구/대시보드가 필요합니다. 또한 단위 테스트를 배포에 결합하는 것은 빠른 피드백을 위한 CI 관점에서 모범 사례가 아닙니다.
오답. Amazon CodeWhisperer는 AI 코딩 어시스턴트이지 CI 시스템이 아닙니다. 커밋 기반 빌드 오케스트레이션, 대규모 단위 테스트 실행, 표준화된 테스트 리포트 시각화를 제공하지 않습니다. 단순히 원시 출력물을 S3에 저장하는 것만으로는 커스텀 UI 없이 탐색 가능한 JUnit 스타일 리포트 요구사항을 충족하지 못하며, 결과를 해석하고 탐색하기 위한 뷰어 또는 리포팅 계층이 여전히 필요합니다.
정답. AWS CodeBuild는 main/develop에 대한 각 커밋마다 CodeCommit에서 자동으로 트리거되어 관리형 Linux 환경에서 빌드와 단위 테스트를 실행하고, JUnit XML을 CodeBuild Report Groups로 수집하여 콘솔에서 내장된 탐색 가능한 경험을 제공합니다. 리포트와 아티팩트는 중앙 접근을 위해 S3로 내보낼 수 있으며 60일 라이프사이클 정책으로 관리할 수 있습니다. CodeBuild는 관리형 동시성과 할당량 구성을 통해 최소 8개의 동시 빌드로 확장할 수 있습니다.
오답. Lambda는 실행 시간 제한, 의존성/도구 체인 복잡성, 임시 스토리지 제약 때문에 일반적인 마이크로서비스를 컴파일/빌드하고 전체 단위 테스트 스위트를 실행하는 데 적합하지 않습니다. 결과를 Lambda 레이어에 저장하는 것은 내구적이고 조회 가능하며 감사인 친화적인 보관 메커니즘이 아니고, 탐색 가능한 JUnit 리포트 UI도 제공하지 않습니다. 이 접근은 사실상 커스텀 CI/리포팅 플러밍을 구축하고 유지보수해야 합니다.
문제 분석
핵심 개념: 이 문제는 AWS 개발자 도구, 특히 AWS CodeBuild의 네이티브 테스트 리포팅과 AWS CodeCommit과 통합된 확장 가능하고 관리형 빌드 실행을 활용한 CI 빌드 및 테스트 자동화를 평가합니다. 정답이 맞는 이유: 옵션 C는 모든 요구사항을 직접 충족합니다: main/develop에 대한 각 커밋 트리거, Linux 환경에서 빌드, 단위 테스트 실행, 커스텀 UI 없이 탐색 가능한 JUnit 스타일 리포트 생성, 리포트 60일 보관, 최소 8개의 동시 빌드 지원. CodeBuild는 웹훅(또는 EventBridge)을 통해 CodeCommit과 통합되어 커밋마다 자동으로 빌드를 시작할 수 있습니다. CodeBuild Report Groups는 JUnit XML 같은 일반 포맷에 대해 테스트 리포트를 1급 기능으로 수집하고 AWS 콘솔에서 시각화하여, 감사인이 테스트 스위트/케이스, 성공/실패, 추세를 탐색할 수 있는 내장 UI를 제공합니다. 주요 AWS 기능: 1) CodeBuild 관리형 Linux 환경: 표준 이미지(예: aws/codebuild/standard)를 선택하고 buildspec.yml에서 명령을 정의합니다. 2) 테스트 리포팅(Report Groups): buildspec.yml의 reports 섹션을 구성하여 JUnit XML을 수집하며, 결과는 커스텀 도구 없이 CodeBuild에서 조회할 수 있습니다. 3) 중앙 보관 및 감사인 접근: 원본 JUnit XML 및 HTML을 포함한 아티팩트를 Amazon S3로 내보내고, S3 Lifecycle 규칙을 적용하여 60일 후 객체를 만료시킵니다. 감사인 읽기 전용 접근을 위해 IAM 정책(필요 시 S3 Object Lock/WORM 옵션)을 사용할 수 있습니다. 4) 동시성: CodeBuild는 병렬 빌드를 지원합니다. 계정 빌드 동시성 한도를 최소 8로 설정(필요 시 할당량 증가 요청)하고 적절한 컴퓨트 타입을 선택합니다. 흔한 오해: CodeDeploy가 테스트에 적합하다고 가정하는 경우가 많지만, 이는 주로 배포 오케스트레이션을 위한 서비스이며 풍부하고 탐색 가능한 단위 테스트 리포팅을 제공하지 않습니다. 또한 Lambda 기반으로 빌드 시스템을 조립하려는 시도도 있지만, Lambda는 전체 빌드에 적합하지 않으며(런타임 제한, 도구 체인, 스토리지) 커스텀 리포트 호스팅이 필요합니다. 시험 팁: “JUnit 스타일 리포트”, “커스텀 UI 없이 조회”, “X일 보관”이 보이면 CodeBuild Report Groups + S3 lifecycle을 떠올리십시오. “모든 커밋마다”는 CodeCommit 웹훅/EventBridge 트리거를 찾으십시오. “N개의 동시 빌드”는 CodeBuild 동시성 할당량과 관리형 스케일링을 기억하십시오.
한 e스포츠 플랫폼이 실시간 글로벌 leaderboard 서비스를 구축하고 있습니다. 가장 자주 조회되는 상위 1%의 player profile에 대한 조회는 마이크로초 단위(p95 < 1 ms)로 반환되어야 하며, 서비스는 초당 최대 45,000건의 read request와 초당 1,500건의 write operation을 처리할 수 있어야 합니다. 또한 profile score가 생성, 업데이트 또는 삭제될 때마다 cache가 즉시 업데이트되어 client가 stale data를 절대 보지 않도록 해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
DynamoDB + DAX는 최소 운영으로 매우 높은 RPS에서 마이크로초 read latency를 제공하도록 목적에 맞게 설계되었습니다. DAX는 DynamoDB API 호환 관리형 in-memory cache이며 read-through 및 write-through 동작을 지원합니다. 애플리케이션이 DAX endpoint를 통해 write를 수행하면 DAX가 cached item을 업데이트/무효화하여 hot profile 조회가 custom invalidation 로직 없이도 일관되게 유지됩니다.
lazy loading을 사용하는 RDS + ElastiCache for Redis는 낮은 latency를 달성할 수 있지만, lazy loading은 본질적으로 stale read 위험이 있습니다(cache가 on demand 또는 TTL로 갱신됨). “stale data를 절대 보지 않음”을 충족하려면 모든 write/delete마다 명시적인 write-through 업데이트 또는 invalidation이 필요하고, race condition을 신중히 처리해야 합니다. 운영 오버헤드(cache-aside 로직, invalidation, potential thundering herd)가 DynamoDB와 함께 DAX를 사용하는 것보다 큽니다.
lazy loading을 사용하는 in-process memory cache는 글로벌로 확장된 서비스에서 운영상 위험합니다. 각 애플리케이션 인스턴스가 자체 cache를 가지므로 update/delete가 플릿 전체에 즉시 전파되지 않아 stale data가 발생합니다. 일관성을 달성하려면 분산 invalidation 메커니즘(pub/sub, messaging)과 정교한 조정이 필요해 복잡성이 증가하며, 모든 인스턴스에서 마이크로초 p95를 보장하기도 어렵습니다.
DAX는 DynamoDB에서만 동작하며 Amazon RDS를 가속할 수 없습니다. 또한 “DAX cluster에 TTL을 구성”하는 것은 DAX 일관성을 달성하는 방식이 아닙니다. TTL 기반 만료는 만료 시점까지 stale read를 허용할 수 있어 즉각적인 update/delete 요구 사항을 충족하지 못합니다. 이 옵션은 아키텍처적으로 유효하지 않으며 호환되지 않는 서비스를 혼합하고 있습니다.
문제 분석
핵심 개념: 이 문제는 고처리량 key-value workload에서 초저지연 read 최적화와 cache 일관성(cache coherency)을 테스트합니다. 핵심 서비스는 확장 가능한 read/write를 위한 Amazon DynamoDB와, 최소 운영 오버헤드로 마이크로초 단위 in-memory caching을 제공하는 DynamoDB Accelerator (DAX)입니다. 정답이 맞는 이유: 옵션 A(DynamoDB + DAX)는 가장 핫한 약 1%의 profile이 마이크로초(p95 < 1 ms)로 반환되어야 하며 초당 약 45,000 reads/sec와 1,500 writes/sec를 유지해야 한다는 요구 사항에 가장 부합합니다. DAX는 read-heavy workload에서 read latency를 한 자릿수 밀리초에서 마이크로초로 줄이도록 특별히 설계된, 완전 관리형(fully managed) DynamoDB 호환 in-memory cache입니다. 중요한 점은 DAX가 write-through 동작을 제공한다는 것입니다. 애플리케이션이 DAX endpoint를 통해 DynamoDB에 write를 수행하면, DAX가 cached item을 업데이트/무효화(invalidate)하여 이후 read가 stale data를 반환하지 않도록 합니다. 이는 애플리케이션이 read와 write 모두에 DAX를 사용한다는 전제하에 “생성/업데이트/삭제 시 즉시 업데이트” 및 “client가 stale data를 절대 보지 않음” 요구 사항과 일치합니다. 주요 AWS 기능: - DAX read-through 및 write-through caching: 가능하면 cache에서 read를 제공하며, DAX를 통한 write는 cache entry의 일관성을 유지합니다. - API 호환성: DAX는 DynamoDB API를 사용하므로 코드/운영 변경을 최소화합니다. - DynamoDB 확장: on-demand 또는 auto scaling이 포함된 provisioned capacity로 45k RPS read와 1.5k WPS write를 충족할 수 있으며, hot partition을 피하기 위한 partition key 설계가 중요합니다. - 최소 운영: DAX는 관리형(패치, cluster 내 복제)으로, 자체 cache invalidation 로직보다 단순합니다. 흔한 오해: 많은 사람들이 Redis가 항상 가장 빠른 옵션이라고 가정하지만, “stale data를 절대 보지 않음” 요구 사항은 일반적인 lazy-loading 패턴과 충돌합니다. lazy loading은 refresh/expiry 전까지 stale read를 본질적으로 허용하기 때문입니다. 또한 in-process cache는 인스턴스별 불일치와 운영 복잡성(플릿 전체 invalidation)을 유발합니다. 시험 팁: “마이크로초” + “DynamoDB workload” + “최소 운영 오버헤드”를 보면 DAX를 떠올리십시오. 또한 cache 일관성에 대한 문구를 주의하십시오. “즉시 업데이트”는 TTL/lazy loading이 아니라 write-through/관리형 invalidation을 시사합니다. DAX는 DynamoDB 전용이며 RDS 앞에 둘 수 없습니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Amazon RDS for PostgreSQL을 기반으로 하는 보고 API가 약 2억 5천만 행에 대한 복잡한 SQL view를 사용하여 5년치 데이터셋에 대한 읽기 전용 분석을 제공하고 있으며, 동일한 파라미터화된 보고 엔드포인트에 대한 트래픽이 초당 300건에서 2,000건으로 증가한 이후 평균 쿼리 지연 시간이 120ms에서 1.2초로 증가했지만 RDS CPU는 85% 이상을 유지하고 있습니다. 기본 테이블은 매일 02:00 UTC에 한 번 배치 업데이트되며, 대부분의 요청(≥95%)은 동일하거나 24시간 동안 캐시 가능하고, 팀은 데이터베이스 스키마를 변경하거나 다른 데이터베이스 엔진으로 마이그레이션할 수 없습니다. 개발자는 데이터베이스 구조를 수정하지 않고 읽기 성능을 개선하고 관리 오버헤드를 최소화해야 합니다. 다음 중 어떤 접근 방식이 이러한 요구 사항을 가장 잘 충족합니까?
DynamoDB로 마이그레이션하는 것은 핵심 제약을 위반합니다. 팀은 데이터베이스 엔진을 변경할 수 없고 데이터베이스 구조를 수정할 수 없습니다. 복잡한 SQL view가 있는 5년치 관계형 분석 데이터셋을 DynamoDB로 옮기려면 상당한 재모델링, 쿼리 재작성, 그리고 사전 집계가 필요할 가능성이 큽니다. 또한 이 시나리오에서 캐싱에 비해 프로젝트 위험과 가치 실현 시간이 증가하며 “관리 오버헤드 최소화”에도 부합하지 않습니다.
ElastiCache for Redis가 최적의 선택입니다. 관리형이며 빠르고, 비용이 큰 반복 읽기 결과를 캐싱하는 데 이상적입니다. 요청의 ≥95%가 동일하거나 24시간 동안 캐시 가능하고 데이터가 하루 한 번 업데이트되므로, 24시간 TTL과 02:00 UTC 배치 업데이트 이후 무효화를 결합하면 높은 cache hit rate와 RDS CPU의 큰 감소를 얻을 수 있습니다. 이는 스키마 변경이나 데이터베이스 마이그레이션 없이 지연 시간을 개선합니다.
EC2의 Memcached는 응답을 캐시할 수 있지만 자체 관리입니다. 인스턴스 사이징, 스케일링 정책, 패치, 장애, 캐시 워밍 동작을 처리해야 합니다. 이는 관리 오버헤드를 최소화해야 한다는 요구 사항과 충돌합니다. 또한 ElastiCache는 EC2에서 Memcached를 직접 운영하는 것에 비해 관리형 캐싱 계층으로 운영 단순성과 내장 기능(모니터링, 유지보수)이 더 좋습니다.
DynamoDB Accelerator (DAX)는 Amazon DynamoDB 테이블 앞단에서 DynamoDB 읽기를 가속하는 데만 동작합니다. Amazon RDS for PostgreSQL 앞단에 둘 수 없으며 SQL 쿼리나 view를 가속하지도 않습니다. 이는 시험에서 흔한 함정으로, DAX는 범용 데이터베이스 캐시가 아니며 RDS 엔진과 호환되지 않습니다.
문제 분석
핵심 개념: 이 문제는 외부 캐시 계층을 사용하여 Amazon RDS의 읽기 확장과 지연 시간 감소를 테스트합니다. 워크로드가 매우 반복적(≥95% 동일/캐시 가능)이고 소스 데이터가 예측 가능한 일정(일일 배치)으로 변경될 때, 애플리케이션 수준 캐싱이 관리 오버헤드를 최소화하면서 가장 효과적인 최적화입니다. 정답이 맞는 이유: Amazon ElastiCache for Redis를 추가하여 24시간 TTL로 보고 결과를 캐시하는 것은 병목을 직접적으로 해결합니다. 즉, 약 2억 5천만 행에 대한 복잡한 SQL view를 반복 실행하는 문제입니다. 트래픽이 2,000 RPS로 증가하면서 데이터베이스 CPU가 85%를 초과하고 지연 시간이 10배 증가한 것은 DB가 중복 읽기로 포화되었음을 의미합니다. 계산된 보고 응답(또는 쿼리 결과 집합)을 캐시하면 API는 대부분의 요청을 Redis에서 서브 밀리초~한 자릿수 밀리초 지연으로 제공할 수 있어 RDS CPU를 크게 낮추고 성능을 안정화할 수 있습니다. 테이블이 하루에 한 번 02:00 UTC에 업데이트되므로 배치 업데이트 이후 캐시를 무효화(키 플러시/버전 키)하여 스키마 변경 없이도 정확성을 보장할 수 있습니다. 주요 AWS 기능 / 모범 사례: - ElastiCache for Redis는 관리형 인메모리 데이터 스토어(패치, 모니터링, 장애 조치 옵션)로, 자체 관리 캐싱에 비해 관리 오버헤드가 낮습니다. - 보고 파라미터에서 파생된 결정적 캐시 키를 사용합니다(엔드포인트는 파라미터화되어 있지만 대부분 동일함). - TTL을 24시간으로 설정하고 02:00 UTC 로드 이후 명시적으로 무효화합니다(또는 캐시 버전 관리: 매일 변경되는 “data_version” 접두사를 포함). - 처리량 확장을 위해 Redis cluster mode 및 read replica(해당되는 경우)를 고려하고 CloudWatch metrics(CPU, evictions, hit rate)와 통합합니다. 흔한 오해: - “그냥 read replica를 추가”는 여기서 선택지로 제공되지 않으며, 모든 요청이 동일한 무거운 view를 실행한다면 비용이 많이 들 수 있습니다. 캐싱은 반복 계산을 피합니다. - DynamoDB/DAX는 RDS/PostgreSQL 쿼리에 대한 즉시 적용 가능한 가속기가 아닙니다. 데이터 모델링 변경이 필요하며 SQL view를 가속하지 않습니다. - EC2에서 자체 관리 Memcached는 운영 부담을 증가시키며 “관리 오버헤드 최소화” 요구 사항과 덜 부합합니다. 시험 팁: (1) 읽기 전용 분석, (2) 반복되는 동일 쿼리, (3) 예측 가능한 갱신 윈도우, (4) 스키마/엔진 변경 제약을 보면, 시험에서 선호하는 패턴은 관리형 서비스(ElastiCache)를 사용해 “결과를 캐시”하는 것입니다. 또한 DAX는 DynamoDB 전용이며 RDS용이 아니라는 점을 기억하세요.
한 미디어 분석 회사가 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 같은 커스텀 애플리케이션 메트릭도 모니터링해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
오답입니다. AWS X-Ray는 분산 추적(지연 시간 분해, service map, traces/segments)에 초점을 둡니다. 메모리 사용률, swap 사용량, filesystem 사용률, 또는 1분 단위 disk I/O 같은 OS 수준 메트릭을 수집하지 않습니다. 또한 X-Ray는 cacheHitRate 및 queueDepth 같은 임의의 커스텀 메트릭을 CloudWatch로 수집하는 표준 메커니즘도 아닙니다.
정답입니다. Amazon CloudWatch agent는 EC2 인스턴스에 설치하여 기본으로 제공되지 않는 1분 단위 OS 수준 메트릭(메모리, swap, disk, filesystem)을 게시할 수 있습니다. 또한 StatsD 또는 collectd를 통해 커스텀 애플리케이션 메트릭을 수집하는 것을 지원하므로, 서비스가 cacheHitRate 및 queueDepth를 최소 변경(대개 이미 메트릭 라이브러리가 있다면 구성만으로)으로 내보낼 수 있습니다. 이는 2주 일정과 적정 규모 조정 요구를 충족합니다.
오답입니다. 애플리케이션을 수정하여 AWS SDK로 메트릭을 게시하는 방식은 커스텀 애플리케이션 메트릭에는 가능할 수 있지만, 코드 변경이 필요하며 메모리, swap, filesystem 사용률 같은 OS 수준 메트릭을 본질적으로 제공하지 않습니다. 이러한 OS 메트릭을 수집하려면 여전히 agent 또는 추가 호스트 계측이 필요합니다. 이 접근은 CloudWatch agent의 내장 기능을 사용하는 것에 비해 개발 노력과 리스크를 증가시킵니다.
오답입니다. AWS CloudTrail은 거버넌스, 컴플라이언스, 감사(auditing)를 위해 AWS API 호출(누가, 무엇을, 언제, 어디서 했는지)을 기록합니다. 인스턴스별 OS 성능 메트릭이나 커스텀 애플리케이션 메트릭을 캡처하지 않습니다. CloudTrail 로그는 보안 조사 및 변경 추적에는 유용하지만, CPU/메모리/disk 사용률 기반의 적정 규모 조정이나 cacheHitRate 및 queueDepth 같은 애플리케이션 수준 KPI 모니터링에는 적합하지 않습니다.
문제 분석
핵심 개념: 이 문제는 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은 피하십시오.
한 핀테크 팀이 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을 업데이트”입니다.
한 물류 회사가 8,000대의 배송 밴에서 텔레매틱스 이벤트를 수신하며, 피크 시 초당 1,200개의 이벤트가 발생하고 이벤트당 평균 1.5 KB입니다. EC2 기반 처리 애플리케이션 3개(이상 징후 탐지, 과금, 실시간 대시보드)가 동일한 이벤트 스트림을 거의 실시간으로 서브초(sub-second) 지연으로 동시에 소비해야 합니다. 각 프로세서는 배포 또는 크래시 동안 일시 중지할 수 있어야 하며, 데이터 손실 없이 마지막 체크포인트에서 재개할 수 있어야 합니다. 팀은 다음 달에 프로세서 2개를 추가할 계획이며, 각 소비자마다 데이터 파이프라인을 중복하는 것을 피하고자 합니다. 이러한 요구 사항을 충족하기 위해 스트림을 수집하고 팬아웃(fan out)하는 데 개발자가 사용해야 하는 AWS 서비스는 무엇입니까?
Amazon SQS는 at-least-once 전달로 프로듀서와 컨슈머를 디커플링하는 데 최적화된 메시지 큐이지만, 경쟁 소비자 모델을 사용합니다. 즉, 메시지가 소비되고 삭제되면 다른 소비자는 이를 읽을 수 없습니다. 여러 큐로 메시지를 복제하거나 SNS-to-SQS 팬아웃을 사용할 수는 있지만, 이는 소비자별로 파이프라인을 명시적으로 중복하게 되며, 진정한 스트림에 비해 재생/체크포인팅 의미론이 복잡해집니다.
Amazon Kinesis Data Firehose는 S3, Redshift, OpenSearch 같은 목적지로 스트리밍 데이터를 버퍼링하여 전달하는 완전관리형 전달 서비스입니다. 여러 EC2 기반 애플리케이션이 서브초 지연으로 동일 스트림을 동시에 소비하고 독립적으로 체크포인트/재생을 수행하도록 설계되지 않았습니다. Firehose는 다중 소비자 실시간 처리보다는 버퍼링(수 초~수 분)과 변환을 포함한 전달에 초점을 둡니다.
Amazon EventBridge는 필터링과 SaaS 통합을 통해 이벤트를 타깃으로 라우팅하는 이벤트 버스입니다. 여러 타깃을 지원하긴 하지만, 샤드 기반 처리량, 순서가 있는 레코드, 소비자 제어 체크포인트를 갖춘 스트리밍 서비스는 아닙니다. 또한 EventBridge는 대규모에서 크래시 복구 및 거의 실시간 스트림 처리를 위해 필요한(시퀀스 체크포인트에서 소비자별로 재개하는) 동일한 스트림 재생 모델을 제공하지 않습니다.
Amazon Kinesis Data Streams는 여러 동시 소비자를 대상으로 하는 실시간 스트리밍 수집 및 처리를 위해 특별히 설계되었습니다. 낮은 지연의 읽기, 내구성 있는 retention(24시간~365일), 그리고 시퀀스 번호 및 체크포인팅(일반적으로 KCL + DynamoDB 사용)을 통한 독립적인 소비자 진행 상태를 지원합니다. Enhanced Fan-Out은 각 소비자에 전용 처리량을 제공할 수 있어, 수집을 중복하지 않고 더 많은 프로세서를 추가하는 데 이상적입니다.
문제 분석
핵심 개념: 이 문제는 여러 동시 소비자, 낮은 지연 시간, 그리고 파이프라인을 중복하지 않으면서도 소비자별로 독립적인 재생/체크포인팅이 가능한 실시간 스트리밍 수집을 평가합니다. 이를 위해 설계된 AWS 서비스는 Amazon Kinesis Data Streams (KDS)이며, 내구성 있는 스트림 저장과 동일 데이터를 읽는 여러 소비자 애플리케이션을 지원합니다. 정답이 맞는 이유: Kinesis Data Streams는 높은 처리량(초당 1,200 이벤트 × ~1.5 KB는 ~1.8 MB/s)으로 이벤트를 수집하고, 거의 실시간 처리를 위한 서브초 읽기 지연을 제공합니다. 무엇보다도 여러 처리 애플리케이션이 동일한 스트림을 동시에 소비할 수 있습니다. 각 애플리케이션은 자체 체크포인트(일반적으로 DynamoDB의 KCL lease/체크포인팅 또는 커스텀 체크포인팅)를 유지할 수 있으므로, 프로세서가 배포 중 일시 중지되거나 크래시가 발생해도 스트림 보존(retention) 기간 내에서 데이터 손실 없이 마지막으로 처리한 시퀀스 번호부터 재개할 수 있습니다. 다음 달에 새 프로세서를 추가하는 것도 간단합니다. 동일한 스트림에 추가 소비자로 연결하면 되며, 수집을 중복할 필요가 없습니다. 주요 AWS 기능: - 다중 소비자: 표준 폴링 소비자 또는 소비자별 전용 처리량과 낮은 지연을 위한 Enhanced Fan-Out (EFO) - 재생 가능성: 구성 가능한 retention(24시간~365일)로 재처리 및 복구 가능 - 순서 및 내구성: 샤드(shard)별 레코드 순서 보장 및 여러 AZ에 걸친 복제 - 확장: 샤드 수 증가(또는 on-demand 모드 사용)로 처리량 증가 대응 - 체크포인팅: Kinesis Client Library (KCL)가 일반적으로 DynamoDB에 체크포인트를 저장하여 장애 후 재개 의미론을 제공 흔한 오해: SQS는 디커플링에 자주 선택되지만, 여러 앱이 독립적으로 재생할 수 있는 스트림이 아니라 큐(경쟁 소비자)입니다. Firehose는 목적지(S3/Redshift/OpenSearch)로의 전달을 위한 서비스이며, 재생 기능을 갖춘 여러 거의 실시간 소비자를 위한 용도가 아닙니다. EventBridge는 라우팅/통합을 위한 이벤트 버스이며, 소비자별 체크포인트와 서브초 스트리밍 의미론을 갖춘 스트림 방식의 retention을 제공하지 않습니다. 시험 팁: “여러 애플리케이션이 동일 이벤트를 읽어야 함”, “거의 실시간/서브초”, “마지막 체크포인트에서 재개”를 보면 Kinesis Data Streams(또는 Kafka/MSK)를 떠올리십시오. “파이프라인을 중복하지 않고 많은 소비자에게 팬아웃” 요구가 있으면, KDS + Enhanced Fan-Out 및 소비자별 체크포인팅이 AWS 네이티브 정답 패턴입니다.
한 물류 회사는 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에서도 실패 허용 폭이 매우 작다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
한 fintech 회사는 Amazon ECS에서 AWS Fargate를 사용하여 환율 정규화 microservice를 실행하고, 분당 최대 20,000개의 JSON log event를 CloudWatch Logs로 전송합니다. 각 event에는 service='rates-pipeline', action='normalize', 그리고 정수 필드 latency_ms(밀리초)가 포함됩니다. 선택한 시간 범위 동안, service='rates-pipeline' 및 action='normalize'인 event에 대해 1분 간격으로 집계된 정규화 latency의 평균, 가장 느린 값(max), 가장 빠른 값(min)을 반환하는 Amazon CloudWatch Logs Insights query는 무엇입니까?
정답입니다. 필요한 두 JSON field(service 및 action)로 filter하고, avg(latency_ms), min(latency_ms)를 fastest로, max(latency_ms)를 slowest로 계산합니다. 또한 by bin(1m)을 사용해 결과를 1분 bucket으로 그룹화하여 요청된 집계 간격과 metric에 부합합니다. fields @timestamp, service, action, latency_ms를 포함하는 것은 괜찮으며 명확성을 위해 흔히 사용되지만, stats에는 latency_ms만 필수입니다.
오답입니다. action="normalize"만 filter하고 service="rates-pipeline"로 제한하지 않으므로 다른 service의 normalize event가 포함될 수 있습니다. 또한 요구된 1분 간격이 아니라 bin(1s)(1초 간격)로 집계하여, 요청한 것보다 훨씬 더 세분화되고 noisy한 결과를 생성합니다. stats 함수는 맞더라도 filter와 bin 크기가 문제 요구사항을 충족하지 않습니다.
오답입니다. service와 action으로 올바르게 filter하고 bin(1m)도 사용하지만, fastest와 slowest의 의미를 바꿔서 라벨링했습니다. latency 측정에서 가장 빠른 요청은 최소 latency에 해당하고, 가장 느린 요청은 최대 latency에 해당합니다. 이는 min/max 해석을 주의 깊게 보도록 하는 흔한 시험 트릭입니다.
문맥상 오답입니다. parse @message "normalize completed in * ms"를 사용해 latency_ms를 추출하는데, 이는 log가 비정형 텍스트일 때만 필요합니다. 문제에서는 각 JSON log event에 이미 정수 필드 latency_ms가 포함되어 있다고 했으므로 parsing은 불필요하며 message 형식이 다르면 실패할 수 있습니다. 또한 service와 action으로 filter하지 않으므로, parsed pattern에 맞는 관련 없는 event가 포함될 수 있습니다.
문제 분석
핵심 개념: 이 문제는 Amazon CloudWatch Logs Insights query 구성 능력을 평가합니다. 즉, field 선택, key/value 쌍으로 JSON log event를 filter하는 방법, 그리고 시간 bin(bin())으로 그룹화된 통계 집계 함수(avg/min/max)를 사용하는 방법입니다. Logs Insights는 log가 유효한 JSON인 경우 최상위 JSON field(예: service, action, latency_ms)를 자동으로 추출하므로, 직접 filter 및 집계를 수행할 수 있습니다. 정답이 맞는 이유: Option A는 다음을 올바르게 수행합니다. 1) JSON field(service, action, latency_ms)를 참조합니다. 2) service="rates-pipeline" AND action="normalize"인 event만 filter합니다. 3) latency_ms에 대해 stats avg(), min(), max()를 사용합니다. 4) by bin(1m)을 사용하여 결과를 1분 간격으로 집계합니다. 이는 요구사항(선택한 시간 범위 동안 분 단위로 평균, 가장 빠른(min), 가장 느린(max) 정규화 latency)을 정확히 충족합니다. 주요 AWS 기능: - CloudWatch Logs Insights는 데이터를 export하지 않고도 CloudWatch Logs에 대해 강력한 ad-hoc query를 지원합니다. - JSON field discovery를 통해 event가 구조화되어 있을 때 filter service="..." 및 action="..."로 filter할 수 있습니다. - stats 함수(avg, min, max, pct, count)는 log field로부터 metric을 계산합니다. - bin(1m)은 event를 timestamp에 정렬된 고정 1분 bucket으로 그룹화하며, 이는 운영 dashboard 및 latency spike 문제 해결에 흔히 사용되는 패턴입니다. 이는 AWS Well-Architected Operational Excellence 원칙(구조화된 logging과 중앙 집중식 분석을 사용하여 이상 징후와 추세를 탐지)과도 부합합니다. 흔한 오해: - min/max 라벨(가장 빠름 vs 가장 느림)을 혼동하는 것은 자주 나오는 시험 함정입니다. - 잘못된 bin 크기(1m 대신 1s)를 사용하면 집계 granularity가 달라져 요청한 것보다 더 noisy한 결과가 나올 수 있습니다. - JSON field가 이미 존재하는데도 @message를 parse해야 한다고 가정하는 경우가 있는데, parsing은 latency가 비정형 텍스트에 포함된 경우에만 필요합니다. 시험 팁: - 문제에서 log event가 field를 “포함한다”고 명시하면, parse보다 직접 field 참조를 우선하세요. - 시간 집계 요구사항(bin(1m) vs bin(5m) 등)을 확인하세요. - 의미 매핑을 다시 확인하세요: fastest = 최소 latency, slowest = 최대 latency. - Logs Insights에서 그룹화 절은 “by bin(1m)”(필요 시 추가 dimension 포함)이며, 집계에는 stats가 적절한 연산자입니다.
한 핀테크 스타트업이 두 개의 AWS 계정(prod 및 audit)에서 Amazon ECS with AWS Fargate로 규칙 엔진을 실행하며 분당 최대 3,000개의 이벤트를 처리한다. 이벤트가 검증에 실패하면 컨테이너는 런타임에 bearer access token을 조회해야 하는 서드파티 incident REST API를 호출해야 한다. 또한 token은 저장 시(at rest)와 전송 시(in transit) 모두 암호화되어야 하며, 관리 오버헤드를 최소화하면서 두 계정의 워크로드에서 모두 접근 가능해야 한다. 이러한 요구 사항을 충족하는 솔루션은 무엇인가?
Systems Manager Parameter Store SecureString은 민감한 값을 저장할 수 있으며, 일부 시나리오에서는 advanced parameter에 대한 resource policy를 사용하여 계정 간 공유할 수 있습니다. 그러나 이 보기에서는 AWS managed KMS key를 지정하고 있으며, 암호화된 값을 cross-account로 사용하려면 AWS managed key로는 적절하게 제어할 수 없는 KMS permissions가 필요합니다. 두 계정의 workloads가 동일한 token을 검색하고 복호화해야 하므로, customer managed KMS key가 올바른 패턴입니다. 이를 제외하더라도, Secrets Manager가 더 낮은 운영 오버헤드로 런타임 secret retrieval에 더 특화된 서비스입니다.
DynamoDB와 KMS 조합은 암호화된 데이터를 안전하게 저장할 수 있지만, 관리형 secrets 솔루션이 아니다. 조회, caching, rotation 전략과 DynamoDB 읽기 및 KMS decrypt에 대한 세심한 IAM 범위 지정을 직접 구현해야 한다. 이는 운영 및 개발 오버헤드를 증가시키고(예: plaintext 로깅, 부적절한 key policy) 실수 가능성을 높인다. 암호화 요구 사항은 충족하지만 “least management overhead”는 충족하지 못한다.
Secrets Manager는 token과 credential을 저장하기 위해 목적에 맞게 설계되었고, KMS(customer managed key 포함)로 secret을 at rest 암호화하며, 조회 시 TLS를 사용한다. resource-based policy로 cross-account access를 지원하므로 하나의 secret을 prod 및 audit 계정의 워크로드와 공유할 수 있다. ECS task role에는 최소 권한의 secretsmanager:GetSecretValue(필요 시 KMS decrypt)를 부여할 수 있어 운영 오버헤드를 최소화한다.
S3에서 SSE-KMS를 사용하면 객체를 at rest 암호화할 수 있고 TLS가 in transit을 보호하며, bucket policy로 cross-account access를 부여할 수 있다. 그러나 S3는 secret store가 아니므로 객체 포맷, 조회 로직, caching, 그리고 잠재적 노출 위험(예: 실수로 더 넓은 bucket 권한 부여)을 관리해야 한다. 또한 AWS managed KMS key를 사용하면 제어가 줄어든다. Secrets Manager보다 오버헤드가 크고 모범 사례에도 덜 부합한다.
문제 분석
핵심 개념: 민감한 런타임 자격 증명을 저장하도록 특별히 설계되었고, 저장 시와 전송 시 암호화를 지원하며, 최소한의 운영 노력으로 AWS 계정 간 공유할 수 있는 AWS 서비스를 선택해야 합니다. 가장 적합한 것은 customer managed KMS key와 cross-account access를 위한 resource-based policy를 사용하는 AWS Secrets Manager입니다. 정답인 이유: Secrets Manager는 bearer token 및 API credentials와 같은 secret를 위해 특별히 설계되었습니다. secret는 저장 시 KMS로 암호화되고, 전송 시에는 TLS를 통해 반환되며, resource-based policy를 통해 cross-account access를 지원합니다. customer managed KMS key를 사용하는 것이 중요한 이유는 cross-account decryption에 명시적인 key policy 제어가 필요하기 때문이며, AWS managed key는 동일한 방식으로 이를 제공하지 않기 때문입니다. 주요 기능: Secrets Manager는 기본 secret 저장, 세분화된 IAM permissions, 선택적 rotation 지원, 그리고 ECS workloads를 위한 직접적인 integration pattern을 제공합니다. secret에 대한 resource policy를 사용하면 prod 및 audit 계정의 task role이 동일한 secret를 검색하도록 허용할 수 있습니다. customer managed KMS key는 이러한 cross-account principal에 대해 명시적인 decrypt permissions를 허용합니다. 일반적인 오해: Parameter Store는 SecureString 값을 저장할 수 있고, 일부 경우에는 parameter sharing도 지원할 수 있습니다. 하지만 이 보기에서는 AWS managed KMS key를 지정하고 있으므로 여기서는 최선의 답이 아닙니다. 이는 필요한 cross-account decrypt model에 적합하지 않습니다. DynamoDB와 S3도 암호화된 데이터를 저장할 수 있지만, 범용 스토리지 서비스이므로 managed secrets service보다 더 많은 custom code와 운영 처리가 필요합니다. 시험 팁: 요구 사항에 token, credentials, 런타임 검색, 암호화, 그리고 최소 관리 오버헤드가 언급되면, 문제가 더 단순한 configuration store를 명확히 가리키지 않는 한 Secrets Manager를 우선 고려하세요. cross-account encrypted secret access의 경우, 항상 resource policy와 KMS key type 및 policy model을 모두 확인하세요.
Windows 노트북을 사용하는 site reliability engineer가 10분 이내에 ap-northeast-2 Region에서 애플리케이션 스택을 프로비저닝하기 위해 로컬 PowerShell 스크립트를 실행해야 한다. 새 AWS account에 대해 command-line-only access만 가능하며 programmatic access는 허용되지만 console sign-in은 불가하다. 배포를 수행하기 위해 엔지니어가 노트북에 무엇을 설정해야 하는가?
오답. AWS CLI는 IAM username과 password로 인증하지 않는다. 해당 자격 증명은 AWS Management Console sign-in(대화형 웹 로그인)에 사용되며, 프롬프트는 이를 명시적으로 허용하지 않는다. CLI에서 API calls를 하려면 AWS는 access keys 또는 temporary STS credentials로 request signing을 요구한다. IAM user가 존재하더라도 CLI에는 console password가 아니라 access key material이 필요하다.
오답. SSH keys는 EC2 instances(SSH/RDP 관련 워크플로), 일부 Git 작업(예: SSH를 통한 CodeCommit), 또는 secure shell sessions를 설정하는 데 사용된다. 이는 AWS CLI의 AWS API 인증을 제공하지 않는다. AWS CLI는 API requests에 서명하기 위해 SSH keypair가 아니라 IAM 기반 credentials(access keys 또는 STS tokens)가 필요하다.
정답. AWS CLI를 설치하고 IAM user access key ID와 secret access key로 구성하면 Windows 노트북에서 AWS APIs에 대한 programmatic access가 가능해진다. 이는 command-line-only access 및 console sign-in 불가 요구사항과 일치한다. 또한 엔지니어는 default region을 ap-northeast-2로 설정(또는 `--region` 전달)하여 PowerShell 프로비저닝 스크립트가 올바른 Region에 빠르게 배포되도록 할 수 있다.
오답. X.509 certificates는 AWS CLI 사용에서 표준 인증 메커니즘이 아니다. 현대적인 AWS API access는 일반적으로 IAM access keys 또는 AWS STS(대개 roles를 통해)의 temporary credentials로 수행된다. certificates는 일부 legacy 또는 특수한 컨텍스트에서 보일 수 있지만, 노트북에서 CLI 기반 프로비저닝을 위해 일반적으로 구성하는 대상이 아니며, 이 선택지는 현재 best practices나 일반적인 시험 기대치와도 맞지 않는다.
문제 분석
핵심 개념: 이 문제는 로컬 머신에서 command-line 도구를 사용해 AWS programmatic access를 수행하는 것을 평가한다. 특히 console sign-in이 허용되지 않을 때 AWS CLI가 새 AWS account에 어떻게 인증하는지에 초점을 둔다. 정답이 맞는 이유: 엔지니어는 “command-line-only access”만 있고 account가 “programmatic access는 허용하지만 console sign-in은 불가”하므로, 올바른 설정은 IAM access keys(access key ID 및 secret access key)로 구성된 AWS CLI이다. AWS CLI는 username/password가 아니라 이러한 자격 증명(또는 STS의 temporary credentials)을 사용해 SigV4 request signing을 수행한다. Windows 노트북에서 로컬 PowerShell 스크립트를 실행하는 상황에서 AWS CLI를 설치하고 자격 증명을 구성(일반적으로 `aws configure` 또는 environment variables 사용)하는 것이 ap-northeast-2에서 10분 제약 내에 스크립트가 AWS APIs를 호출할 수 있게 하는 표준적이고 가장 빠른 방법이다. 주요 AWS 기능: - AWS CLI credential sources: shared credentials file (~/.aws/credentials), config file (~/.aws/config), environment variables, 또는 credential_process. - IAM access keys: IAM user를 위한 장기 programmatic credentials. Best practice는 IAM roles/STS를 통한 temporary credentials를 선호하지만, 프롬프트는 새 account와 즉시 programmatic access를 시사한다. - Region targeting: CLI config에서 default region(ap-northeast-2)을 설정하거나 명령에 `--region ap-northeast-2`를 전달한다. 흔한 오해: 많은 사람이 “IAM username과 password”로 CLI login이 가능하다고 가정한다. 이는 AWS Management Console sign-in(대화형 웹 로그인)에 해당하며 AWS CLI의 API 인증에는 사용되지 않는다. 또 다른 오해는 SSH keys(EC2 instance login, CodeCommit SSH 등에서 사용)를 AWS API 인증과 혼동하는 것이다. X.509 certificates는 과거의 오래된 메커니즘(예: 일부 legacy EC2 API tools)에서 사용된 적이 있으나, AWS CLI 인증의 표준이 아니다. 시험 팁: - 문제가 “programmatic access”라고 하면 “access key ID + secret access key” 또는 “role을 통한 STS temporary credentials”를 떠올려라. - console sign-in이 불가하면 username/password는 무관하다. - SSH keys는 서버/리포지토리에 대한 인증이며 AWS API endpoints에 대한 인증이 아니다. - Region 요구사항을 항상 확인하라: default region을 설정하거나 `--region`을 지정해 잘못된 Region에 배포하는 것을 방지하라. (Reference: AWS IAM/AWS CLI 문서의 AWS CLI configuration 및 credential types; AWS Well-Architected Security Pillar는 least privilege와 가능한 경우 장기 credentials 회피를 강조한다.)
원격의료 제공업체가 지연 시간에 민감한 예약 API를 AWS Elastic Beanstalk(Amazon Linux 2, Auto Scaling이 적용된 load balanced 환경)에서 호스팅하고 있습니다. 사용자에게 보이는 다운타임 없이 새 버전을 배포해야 하며, 승격 또는 롤백 전에 15분 평가 구간 동안 들어오는 요청의 정확히 25%를 새 버전으로, 75%를 현재 버전으로 라우팅해야 합니다. 이러한 요구 사항을 충족하는 Elastic Beanstalk 배포 정책은 무엇입니까?
Rolling 배포는 인스턴스를 배치 단위로 업데이트하여, 일부 용량은 트래픽을 처리하는 동안 나머지를 업데이트합니다. 이는 다운타임을 줄일 수 있지만, 고정된 평가 구간 동안 두 버전 간 정확하고 제어된 비율 분할(25%/75%)을 제공하지는 않습니다. Rolling 중에는 배치 진행 상황에 따라 업데이트된/미업데이트 인스턴스가 섞여 트래픽을 받게 되며, 안정적인 카나리 비율이 아닙니다.
Traffic-splitting 배포는 Elastic Beanstalk에서 카나리 스타일 릴리스를 위해 목적에 맞게 설계되었습니다. 기존 버전과 함께 새 버전을 병행 실행하고, 환경의 load balancer를 사용해 지정된 비율의 요청(예: 25%)을 정의된 평가 기간(예: 15분) 동안 새 버전으로 라우팅합니다. 평가 후에는 사용자에게 보이는 다운타임 없이 100%로 승격하거나 롤백할 수 있습니다.
In-place 배포는 기존 인스턴스를 직접 업데이트합니다(한 번에 모두 또는 일시적으로 용량을 줄일 수 있는 방식). 이 접근은 특히 지연 시간에 민감한 API에서 짧은 중단이나 성능 저하를 유발할 수 있으며, 버전 간 25%/75% 트래픽 분할을 제어하는 기능을 제공하지 않습니다. 일반적으로 프로덕션 릴리스에서는 immutable 또는 traffic-splitting보다 안전성이 떨어집니다.
Immutable 배포는 새 버전으로 새로운 인스턴스 세트를 생성하고, health를 검증한 다음 전환하여 배포 리스크를 크게 줄이고 거의 제로 다운타임을 달성할 수 있습니다. 그러나 immutable은 주로 올-오어-낫싱 컷오버 모델이며, 시간 제한이 있는 평가 구간 동안 정확한 25%/75% 요청 라우팅 분할을 기본적으로 제공하지는 않습니다. 해당 요구 사항은 traffic-splitting에 직접적으로 매핑됩니다.
문제 분석
핵심 개념: 이 문제는 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을 가리킵니다.
한 핀테크 스타트업에는 1.8-MB 요청 검증 및 로깅용 유틸리티 라이브러리를 공유해야 하는 AWS Lambda 함수(Python 3.11) 8개가 있습니다. 개발자는 공유 라이브러리를 단일 zip 파일로 패키징했으며, 운영 오버헤드를 최소화하면서 dev, staging, prod 전반에서 한 번만 배포하고 8개 함수 모두를 업데이트해야 합니다. 이 요구 사항을 가장 운영 효율적으로 충족하는 솔루션은 무엇입니까?
Lambda는 일반적인 import 메커니즘의 일부로 런타임에 S3 object path에서 Python module을 직접 import할 수 없습니다. S3는 deployment artifact를 저장할 수는 있지만, 코드와 의존성은 함수 package, container image 또는 layer에 포함되어야 합니다. invocation 중에 S3에서 코드를 가져오려면 사용자 정의 다운로드 로직이 필요하고, 지연 시간과 장애 지점을 추가하며, 운영 효율적이거나 표준적인 패턴이 아닙니다.
검증/로깅을 수행하는 별도의 Lambda를 만들고 이를 동기적으로 invoke하면, 로컬 라이브러리 호출이 네트워크 호출로 바뀝니다. 이는 end-to-end 지연 시간을 증가시키고, invocation당 비용을 추가하며, 추가적인 throttling 및 오류 처리 문제를 도입하고, tracing과 retries를 복잡하게 만듭니다. 또한 함수 간에 강한 런타임 결합을 만듭니다. 이는 일반적으로 in-process로 실행되어야 하는 공유 유틸리티 코드에 대한 안티패턴입니다.
Lambda layer는 여러 함수에서 공통 라이브러리를 공유하도록 설계되었습니다. 유틸리티를 layer로 패키징하고 version을 게시한 다음 8개 함수 모두에 연결합니다. 업데이트는 새 layer version을 게시하고 환경별로(이상적으로 IaC/CI/CD를 통해) 함수 구성을 업데이트하여 처리합니다. 이는 중복을 최소화하고, 통제된 rollout/rollback을 지원하며, 가장 운영 효율적인 솔루션입니다.
Container images는 base image를 통해 공유 라이브러리를 포함할 수 있지만, 1.8-MB Python 유틸리티 라이브러리를 위해 모든 함수를 container packaging으로 마이그레이션하는 것은 필요 이상으로 운영 부담이 큽니다. Image build pipeline, ECR 관리, 더 큰 deployment artifact를 도입합니다. 가능하긴 하지만, 여러 함수에서 단순한 공유 의존성을 재사용하는 경우 Lambda layers에 비해 ‘가장’ 운영 효율적이지는 않습니다.
문제 분석
핵심 개념: 이 문제는 AWS Lambda에서 코드 공유 및 배포 모범 사례를 테스트합니다. 핵심 개념은 여러 Lambda 함수가 사용할 수 있도록 공유 의존성(라이브러리, runtime 또는 공통 코드)을 패키징하고 중앙에서 관리하기 위해 AWS Lambda layers를 사용하는 것입니다. 정답이 맞는 이유: Lambda layer는 정확히 이 시나리오를 위해 설계되었습니다. Python 3.11 함수 8개가 동일한 1.8-MB 유틸리티 라이브러리를 공유해야 하고, 팀은 dev, staging, prod 전반에서 운영 오버헤드를 최소화하면서 한 번만 배포하고 모든 함수를 업데이트하려고 합니다. 라이브러리를 포함한 layer version을 게시하고 각 함수에 연결하면, 공유 코드를 함수 코드와 분리할 수 있습니다. 업데이트는 통제된 작업이 됩니다. 즉, 새 layer version을 게시하고 함수 구성(또는 IaC/CI/CD를 통한 aliases/versions)이 새 layer version을 참조하도록 업데이트하면 됩니다. 이는 운영적으로 효율적이며 공유 라이브러리에 대한 AWS 권장 패턴과 일치합니다. 주요 AWS 기능: - Lambda layers는 의존성을 별도로 패키징하고 /opt(Python은 일반적으로 /opt/python)에 마운트하는 것을 지원합니다. - 버전이 있는 layers를 사용하면 환경별로 특정 layer version을 선택하여 안전한 rollout 및 rollback이 가능합니다. - AWS SAM/CloudFormation/CDK/Terraform과 깔끔하게 연동되어 여러 함수와 여러 환경에 동일한 layer를 일관되게 적용할 수 있습니다. - 함수 deployment package를 더 작게 유지하고 함수 간 중복을 줄입니다. 흔한 오해: 일부는 S3를 런타임 import path로 사용할 수 있다고 가정하지만(표준 Lambda import에서는 불가능), 또는 “공유 유틸리티 Lambda”가 좋은 재사용 메커니즘이라고 생각합니다. 검증/로깅을 위해 다른 Lambda를 invoke하면 지연 시간, 비용, 장애 지점, 운영 복잡성이 증가합니다. Container images는 base image를 공유할 수 있지만, 작은 공유 라이브러리를 위해 모든 함수를 images로 마이그레이션하는 것은 필요 이상으로 무겁고 build/publish 오버헤드를 증가시킵니다. 시험 팁: “여러 Lambda 함수가 동일한 라이브러리를 공유”하고 “한 번 배포/여러 개 업데이트”가 보이면 “Lambda layers”를 떠올리십시오. 또한 layers는 versioned이며, 환경은 일반적으로 특정 version에 고정하고 dev에서 staging, prod로의 통제된 승격을 위해 CI/CD로 업데이트합니다.
합격 후기(8)
학습 기간: 1 month
점수는 793점으로 합격했어요! 하루에 최소 30문제는 풀었어요. 밖에서도 짬 날 때마다 풀 수 있으니 좋네요ㅎㅎ
학습 기간: 2 months
앱 문제가 시험이랑 굉장히 유사했어요. 그리고 해설들이 왜 틀렸는지 이해하는데 도움이 됐어요.
학습 기간: 1 month
Thank you very much, these questions are wonderful !!!
학습 기간: 2 months
1달 전에 합격했는데 지금 후기쓰네요. 시험하고 문제 구성이 비슷했어요
학습 기간: 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.
다른 AWS 자격증
AWS Certified Solutions Architecture - Associate (SAA-C03)
Associate
AWS Certified AI Practitioner (AIF-C01)
Practitioner
AWS Certified Advanced Networking - Specialty (ANS-C01)
Specialty
AWS Certified Cloud Practitioner (CLF-C02)
Practitioner
AWS Certified Data Engineer - Associate (DEA-C01)
Associate
AWS Certified DevOps Engineer - Professional (DOP-C02)
Professional
AWS Certified Machine Learning Engineer - Associate (MLA-C01)
Associate
AWS Certified Security - Specialty (SCS-C02)
Specialty
AWS Certified Solutions Architect - Professional (SAP-C02)
Professional
지금 학습 시작하기
Cloud Pass를 다운로드하여 모든 AWS Certified Developer - Associate (DVA-C02) 기출 문제를 풀어보세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
앱 받기
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.