실전 문제

문제 1

(2개 선택)

한 원격의료 스타트업은 12개의 파트너 클리닉이 presigned URL을 사용하여 최대 5 GB의 DICOM 이미지를 Amazon S3 bucket에 업로드하는 웹 포털을 운영하고 있습니다. 회사는 모든 업로드/다운로드에 대해 전송 중 암호화를 강제해야 하며, 환자 식별자가 포함된 모든 object는 보안 팀이 필요 시 온디맨드로 rotation할 수 있는 AWS KMS key로 저장 시 암호화되도록 보장해야 합니다. 어떤 단계 조합이 이러한 요구 사항을 충족합니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 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를 우선 선택하세요.

문제 2

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

문제 분석

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

문제 3

개발자가 Amazon API Gateway 뒤에서 AWS Lambda 기반의 serverless 이미지 처리 API를 구축하고 있습니다. 이 API는 조정 가능한 두 가지 runtime 파라미터—최대 병렬 변환 수(초기값 300)와 분당 처리 가능한 최대 이미지 수(초기값 900)—를 읽어야 하며, 운영팀이 이를 매주 업데이트할 수 있습니다. 또한 이러한 업데이트는 canary release(예: 20분 동안 10%)로 자동 롤아웃되어야 하고, 빠른 rollback을 허용해야 하며, function 코드를 재배포하거나 downtime을 유발하지 않고 모든 function 인스턴스에 걸쳐 적용되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 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과 함께 사용할 때 최적입니다.

문제 4

원격의료 플랫폼이 전국 단위 교육 웨비나를 출시하고 있으며, 동시 세션이 급증함에 따라 DevOps 팀은 WebRTC signaling 서비스를 실행하는 Amazon EC2 인스턴스가 10분 연속으로 CPU utilization 85%를 초과할 경우 알림을 받아야 합니다. 이를 통해 온콜 엔지니어가 용량을 확장할 수 있어야 합니다. 어떤 솔루션이 이 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 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이 필요한 경우가 많습니다.

문제 5

한 팀이 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을 구성해야 합니까?

문제 분석

핵심 개념: 이 문제는 자동화된 배포 중에 특정 범위로 제한된 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를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

문제 6

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

문제 7

한 회사가 Amazon ECS에서 AWS Fargate로 결제-승인 microservice를 실행하고 있으며, 각 승인은 2초 이내에 완료되어야 합니다. 단일 승인이라도 2초 이상 걸리면 개발 팀에 알림이 가야 합니다. 개발자는 운영 오버헤드를 최소화하면서 타이밍 측정과 알림을 어떻게 구현할 수 있습니까?

문제 분석

핵심 개념: 이 문제는 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' 같은 표현 차이에 특히 주의하세요.

문제 8

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

문제 9

미디어 스트리밍 회사가 마이크로서비스 코드를 AWS CodeCommit에 저장하고 있으며, 컴플라이언스 요구사항으로 단위 테스트가 100% 통과해야 하고 상세 테스트 리포트는 60일 동안 보관되며 감사인이 열람할 수 있어야 합니다. main 및 develop 브랜치에 대해 하루 약 15회 커밋이 발생하는 상황에서, 팀은 각 커밋마다 Linux 빌드 환경에서 서비스를 자동으로 빌드하고 단위 테스트를 실행하며, 커스텀 UI를 만들지 않고도 탐색 가능한 JUnit 스타일 리포트를 생성해야 합니다. 또한 최소 8개의 동시 빌드를 지원하고 리포트를 중앙에서 접근 가능하게 유지해야 합니다. 어떤 솔루션이 이러한 요구사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 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 동시성 할당량과 관리형 스케일링을 기억하십시오.

문제 10

한 e스포츠 플랫폼이 실시간 글로벌 leaderboard 서비스를 구축하고 있습니다. 가장 자주 조회되는 상위 1%의 player profile에 대한 조회는 마이크로초 단위(p95 < 1 ms)로 반환되어야 하며, 서비스는 초당 최대 45,000건의 read request와 초당 1,500건의 write operation을 처리할 수 있어야 합니다. 또한 profile score가 생성, 업데이트 또는 삭제될 때마다 cache가 즉시 업데이트되어 client가 stale data를 절대 보지 않도록 해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 고처리량 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 앞에 둘 수 없습니다.

문제 11

Amazon RDS for PostgreSQL을 기반으로 하는 보고 API가 약 2억 5천만 행에 대한 복잡한 SQL view를 사용하여 5년치 데이터셋에 대한 읽기 전용 분석을 제공하고 있으며, 동일한 파라미터화된 보고 엔드포인트에 대한 트래픽이 초당 300건에서 2,000건으로 증가한 이후 평균 쿼리 지연 시간이 120ms에서 1.2초로 증가했지만 RDS CPU는 85% 이상을 유지하고 있습니다. 기본 테이블은 매일 02:00 UTC에 한 번 배치 업데이트되며, 대부분의 요청(≥95%)은 동일하거나 24시간 동안 캐시 가능하고, 팀은 데이터베이스 스키마를 변경하거나 다른 데이터베이스 엔진으로 마이그레이션할 수 없습니다. 개발자는 데이터베이스 구조를 수정하지 않고 읽기 성능을 개선하고 관리 오버헤드를 최소화해야 합니다. 다음 중 어떤 접근 방식이 이러한 요구 사항을 가장 잘 충족합니까?

문제 분석

핵심 개념: 이 문제는 외부 캐시 계층을 사용하여 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용이 아니라는 점을 기억하세요.

문제 12

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

문제 분석

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

문제 13

한 핀테크 팀이 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을 업데이트”입니다.

문제 14

한 물류 회사가 8,000대의 배송 밴에서 텔레매틱스 이벤트를 수신하며, 피크 시 초당 1,200개의 이벤트가 발생하고 이벤트당 평균 1.5 KB입니다. EC2 기반 처리 애플리케이션 3개(이상 징후 탐지, 과금, 실시간 대시보드)가 동일한 이벤트 스트림을 거의 실시간으로 서브초(sub-second) 지연으로 동시에 소비해야 합니다. 각 프로세서는 배포 또는 크래시 동안 일시 중지할 수 있어야 하며, 데이터 손실 없이 마지막 체크포인트에서 재개할 수 있어야 합니다. 팀은 다음 달에 프로세서 2개를 추가할 계획이며, 각 소비자마다 데이터 파이프라인을 중복하는 것을 피하고자 합니다. 이러한 요구 사항을 충족하기 위해 스트림을 수집하고 팬아웃(fan out)하는 데 개발자가 사용해야 하는 AWS 서비스는 무엇입니까?

문제 분석

핵심 개념: 이 문제는 여러 동시 소비자, 낮은 지연 시간, 그리고 파이프라인을 중복하지 않으면서도 소비자별로 독립적인 재생/체크포인팅이 가능한 실시간 스트리밍 수집을 평가합니다. 이를 위해 설계된 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 네이티브 정답 패턴입니다.

문제 15

(2개 선택)

한 물류 회사는 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,' 오류가 표시되었는데, 이 실패를 설명할 수 있는 두 가지 이슈는 무엇인가?

문제 분석

핵심 개념: 이 문제는 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에서도 실패 허용 폭이 매우 작다.

문제 16

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

문제 분석

핵심 개념: 이 문제는 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가 적절한 연산자입니다.

문제 17

한 핀테크 스타트업이 두 개의 AWS 계정(prod 및 audit)에서 Amazon ECS with AWS Fargate로 규칙 엔진을 실행하며 분당 최대 3,000개의 이벤트를 처리한다. 이벤트가 검증에 실패하면 컨테이너는 런타임에 bearer access token을 조회해야 하는 서드파티 incident REST API를 호출해야 한다. 또한 token은 저장 시(at rest)와 전송 시(in transit) 모두 암호화되어야 하며, 관리 오버헤드를 최소화하면서 두 계정의 워크로드에서 모두 접근 가능해야 한다. 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

문제 18

Windows 노트북을 사용하는 site reliability engineer가 10분 이내에 ap-northeast-2 Region에서 애플리케이션 스택을 프로비저닝하기 위해 로컬 PowerShell 스크립트를 실행해야 한다. 새 AWS account에 대해 command-line-only access만 가능하며 programmatic access는 허용되지만 console sign-in은 불가하다. 배포를 수행하기 위해 엔지니어가 노트북에 무엇을 설정해야 하는가?

문제 분석

핵심 개념: 이 문제는 로컬 머신에서 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 회피를 강조한다.)

문제 19

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

문제 분석

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

문제 20

한 핀테크 스타트업에는 1.8-MB 요청 검증 및 로깅용 유틸리티 라이브러리를 공유해야 하는 AWS Lambda 함수(Python 3.11) 8개가 있습니다. 개발자는 공유 라이브러리를 단일 zip 파일로 패키징했으며, 운영 오버헤드를 최소화하면서 dev, staging, prod 전반에서 한 번만 배포하고 8개 함수 모두를 업데이트해야 합니다. 이 요구 사항을 가장 운영 효율적으로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 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로 업데이트합니다.