기출 문제

문제 1

미디어 스트리밍 회사가 마이크로서비스 코드를 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 동시성 할당량과 관리형 스케일링을 기억하십시오.

문제 2

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 회피를 강조한다.)

문제 3

한 스타트업이 분석을 위해 2개의 Availability Zones에 걸쳐 2노드 Amazon Redshift 클러스터를 운영하고 있으며, 스택 생성 중 추가 데이터베이스 구성을 적용하기 위해 AWS Lambda 함수(메모리 256 MB, 타임아웃 45초)가 백엔드인 AWS CloudFormation 사용자 지정 리소스를 생성해야 합니다. Lambda 함수는 배포 시 함께 프로비저닝되는 클러스터의 admin 사용자 자격 증명(사용자 이름은 dw_admin으로 설정됨)을 사용하여 Redshift 클러스터에 연결해야 합니다. Redshift 클러스터에 자격 증명을 제공하면서 동시에 Lambda 함수에 이러한 자격 증명을 제공하는 가장 secure 방법은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS CloudFormation을 통한 인프라 프로비저닝 중 안전한 secret 배포와, AWS Lambda의 안전한 런타임 조회를 평가합니다. 템플릿, parameter, 로그, environment variable에 평문 자격 증명이 노출되는 것을 피하고, IAM 최소 권한과 함께 관리형 secret 서비스를 사용하는 데 초점을 둡니다. 정답인 이유: 옵션 D가 가장 안전한 이유는 Redshift admin 비밀번호의 system of record로 AWS Secrets Manager를 사용하고, CloudFormation dynamic reference를 사용해 템플릿에 secret을 하드코딩하거나 직접 노출하지 않고 배포 시점에 Redshift 클러스터의 MasterUserPassword에 secret 값(을) 주입하기 때문입니다. Lambda 함수에는 런타임에 secret을 조회할 수 있도록 (secretsmanager:GetSecretValue) 권한이 부여되며, Lambda environment variable에는 secret 식별자(이름/ARN)만 저장됩니다. 이는 secret 노출을 최소화하고 rotation을 지원하며 자격 증명 관리 모범 사례에 부합합니다. 주요 AWS 기능 / 모범 사례: - CloudFormation dynamic reference(예: {{resolve:secretsmanager:...}})는 배포 시점에 안전하게 값을 조회할 수 있게 하며, CloudFormation은 템플릿에 평문 secret을 저장하지 않습니다. - Secrets Manager는 KMS를 통한 저장 시 암호화, 세분화된 IAM 접근 제어, CloudTrail을 통한 감사, 내장 rotation 워크플로를 제공합니다. - Lambda는 environment variable에 secret을 내장하기보다 런타임에 secret을 가져오고(이상적으로는 짧게 캐시) 사용해야 합니다. - 최소 권한: Lambda 실행 role에는 해당 secret에 대한 secretsmanager:GetSecretValue만 필요합니다. 흔한 오해: - CloudFormation parameter의 NoEcho는 콘솔 표시를 줄이지만, secret이 다른 경로(스택 이벤트, 로그, environment variable, CI/CD parameter 처리)를 통해 여전히 유출될 수 있습니다. 이는 관리형 secret store와 동일하지 않습니다. - Parameter Store는 SecureString을 저장할 수 있지만, 제시된 옵션은 SecureString 또는 dynamic reference 패턴을 명시하지 않습니다. 데이터베이스 자격 증명과 rotation에는 일반적으로 Secrets Manager가 선호됩니다. 시험 팁: “MOST secure”와 “Lambda + 데이터베이스 프로비저닝을 위한 자격 증명”이 보이면, Secrets Manager + dynamic reference + IAM을 통한 런타임 조회를 우선 선택하십시오. NoEcho가 있더라도 Lambda environment variable이나 평문 parameter로 secret을 전달하는 방식은 피하십시오. rotation을 지원하고 배포 산출물 전반에서 secret 노출을 최소화하는 해법을 찾으십시오.

문제 4

한 회사는 전국 규모의 스마트 온도조절기 플랫폼을 운영하고 있으며, 디바이스 펌웨어가 기존 Amazon API Gateway REST API를 통해 텔레메트리와 명령을 전송하고, 이 REST API는 검증과 라우팅을 위해 여러 AWS Lambda 함수를 호출합니다. 엔지니어링 팀은 새로운 규칙 처리 기능이 포함된 업데이트된 Lambda 코드를 구축했으며, 나머지 트래픽에 영향을 주거나 클라이언트 동작을 변경하지 않고 48시간 동안 들어오는 디바이스 요청의 정확히 5%(시간당 약 12,000건)를 테스트해야 합니다. 또한 지속적인 운영 작업이 가장 적고 API 변경이 최소인 접근 방식을 원합니다. 다음 중 이러한 요구 사항을 가장 적은 운영 노력으로 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 기존 Amazon API Gateway REST API 뒤에 있는 AWS Lambda에 대해, 클라이언트를 변경하지 않고도 제어된 canary 스타일 라우팅을 수행하기 위해 Lambda versions와 aliases(일반적인 배포 패턴)를 사용하여 안전하게 프로덕션 테스트/트래픽 시프팅을 하는지를 평가합니다. 정답이 맞는 이유: 옵션 A는 Lambda function versioning과 가중치가 적용된 alias를 사용하여 호출을 분할합니다(새 버전 5%, 현재 버전 95%). API Gateway는 동일한 디바이스 요청을 계속 수신하며, 단지 unqualified function ARN 대신 alias ARN을 호출합니다. 이는 48시간 동안 들어오는 요청의 정확히 5%를 최소한의 운영 노력으로 테스트해야 한다는 요구 사항을 충족합니다. 가중치를 설정하고 모니터링한 뒤, alias 가중치를 조정하여 되돌리거나 승격할 수 있습니다. 클라이언트 동작 변경이 필요 없고, API 표면도 사실상 변경되지 않습니다(통합 대상 ARN만 변경). 주요 AWS 기능 및 모범 사례: - Lambda versions는 코드/구성의 변경 불가능한 스냅샷입니다. - Lambda aliases는 versions에 대한 안정적인 포인터이며, 점진적 배포/canary를 위해 두 versions 간 가중치 라우팅을 지원합니다. - API Gateway REST API Lambda integration은 qualified ARN을 사용하여 특정 version/alias를 호출할 수 있습니다. - 운영 측면에서 이는 가볍습니다. 추가 API stages, 새 APIs, 외부 배포 오케스트레이터가 필요하지 않으며, 고정된 48시간 실험에 적합합니다. 흔한 오해: API Gateway stage canaries(옵션 B/D)는 종종 백엔드 canaries와 혼동됩니다. Stage canaries는 주로 stage 배포/구성(예: 다른 integrations, mappings, authorizers) 간에 트래픽을 전환하며, 일반적으로 canary 배포를 유지하고 구성을 중복해야 할 수 있습니다. 새 REST API를 만드는 것은 불필요하게 변경과 운영 오버헤드를 늘립니다. CodeDeploy canary deployments(옵션 C)는 자동화된 점진적 롤아웃에 매우 유용하지만, 시간이 지남에 따라 트래픽을 100%로 이동시키고 alarms/rollback을 관리하도록 설계되었습니다. 요구 사항은 48시간 동안 정확히 5%로 유지하는 것이므로, alias 가중치로 더 간단하게 처리할 수 있으며 CodeDeploy를 도입할 필요가 없습니다. 시험 팁: - API Gateway 뒤의 Lambda에서 가장 적은 노력으로 트래픽을 분할하는 방법은 보통 “Lambda version + weighted alias”이며, 이후 integration이 alias를 가리키도록 합니다. - API Gateway canary는 새 Lambda 코드만이 아니라 API Gateway 구성 변경(mappings, authorizers, stage variables)을 테스트해야 할 때 사용합니다. - CodeDeploy는 alarms와 진행 계획을 포함한 자동 롤아웃/롤백이 필요할 때 사용하며, 정해진 기간 동안 고정 비율 실험이 필요할 때는 적합하지 않습니다.

문제 5

한 차량 공유 회사가 25개의 파트너 서비스에서 여행 및 결제 데이터를 집계하여 하나의 대시보드로 보여주는 내부 콘솔을 구축하고 있습니다. 팀은 각 파트너로부터 API 클라이언트 자격 증명(client_id 및 client_secret)을 가져오는 OAuth 온보딩 워크플로를 자동화했습니다. 스택 업데이트 중에 AWS CloudFormation custom resource가 AWS Lambda 함수를 호출하여 해당 자격 증명을 가져오거나 새로 고칩니다. 개발자는 운영 오버헤드를 최소화하면서, 저장 시(at rest)와 전송 시(in transit) 모두에서 안전하게 보호된 상태로 가져온 자격 증명을 영속적으로 저장할 수 있는 솔루션이 필요합니다. 가장 안전한 방식으로 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 CloudFormation 업데이트 중 동적으로 가져온 자격 증명을 안전하게 저장하는 방법을 평가합니다. 핵심 서비스는 AWS Systems Manager Parameter Store(SecureString)와 AWS Secrets Manager이며, CloudFormation custom resource와 템플릿, 이벤트 또는 로그에서 비밀이 노출되지 않도록 하는 방법을 다룹니다. 정답이 맞는 이유: 옵션 B가 최선인 이유는 custom resource Lambda가 이미 OAuth client_id/client_secret을 가져오거나 새로 고치고 있으며, AWS SDK로 Type=SecureString을 사용한 ssm:PutParameter를 통해 즉시 이를 영속 저장할 수 있기 때문입니다. SecureString은 AWS KMS를 사용해 저장 시 암호화하고, AWS SDK를 통한 전송은 TLS로 보호됩니다. 이 방식은 비밀을 CloudFormation 템플릿이나 스택 상태에 포함시키지 않아 운영 오버헤드를 최소화하면서도 비밀을 보호합니다. 주요 AWS 기능: - Parameter Store SecureString: KMS로 저장 시 암호화(AWS-managed key가 기본이며, KeyId를 통해 customer managed key 사용 가능)되고, 권한이 있는 principal만 복호화할 수 있습니다. - IAM 최소 권한: Lambda를 특정 parameter ARN에 대한 ssm:PutParameter(및 필요 시 ssm:GetParameter)와 선택한 키에 대한 kms:Encrypt/Decrypt로 제한합니다. - 버전 관리/덮어쓰기: PutParameter는 Overwrite=true를 지원하여 값의 로테이션/갱신을 깔끔하게 처리할 수 있습니다. - CloudFormation 노출 방지: CloudFormation은 리소스 속성과 custom resource 응답을 스택 이벤트에 기록할 수 있으므로, Lambda 내부에서 비밀을 직접 기록하면 우발적 노출 가능성을 줄일 수 있습니다. 흔한 오해: 많은 사람이 “NoEcho”가 CloudFormation에서 어떤 비밀이든 안전하게 만든다고 생각합니다. NoEcho는 특정 출력/콘솔 뷰에서 값을 마스킹할 뿐이며, 백엔드 서비스가 제공하지 않는 한 저장 시 암호화를 제공하지 않습니다(또한 SDK 호출에는 적용되지 않음). 또 다른 오해는 Secrets Manager가 항상 “가장 안전”하다는 것입니다. Secrets Manager는 훌륭하지만, CloudFormation이 custom resource 반환값으로부터 비밀 값을 “안전하게 설정”하는 것은 노출 위험이 있으며, GenerateSecretString은 외부에서 가져온 자격 증명을 수용하는 용도가 아니라 비밀을 생성하는 용도입니다. 시험 팁: - 자격 증명이 동적으로 가져와지는 경우(custom resource/Lambda), CloudFormation 속성을 통해 전달하기보다 코드에서 직접 비밀 저장소(Parameter Store SecureString 또는 Secrets Manager의 PutSecretValue)에 저장합니다. - NoEcho는 암호화가 아니라 표시 마스킹에 관한 것입니다. - 운영 오버헤드가 낮고 KMS 기반 암호화가 필요하면 SecureString을 선택하고, 내장 로테이션 워크플로, cross-account replication, 더 풍부한 비밀 라이프사이클 기능이 필요하면 Secrets Manager를 선택합니다.

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

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

문제 6

(2개 선택)

한 핀테크 스타트업은 Amazon EventBridge에 의해 트리거되는 결제 처리 AWS Lambda 함수를 실행하고 있습니다. us-west-2에서 30분간의 플래시 세일 동안 Amazon CloudWatch에서 Throttles metric이 분당 900까지 급증하는 것이 관측되었습니다. 계정 수준 동시 실행 quota는 1,000이며, 또 다른 중요 Lambda에 800 reserved concurrency가 설정되어 있습니다. 팀은 워크로드를 재설계하지 않고 결제 함수의 throttling을 줄이기 위한 가장 운영 효율적인 조치를 원합니다(두 개 선택).

문제 분석

핵심 개념: 이 문제는 AWS Lambda의 concurrency 제어와 throttling 동작, 특히 계정 수준(리전) concurrency quota와 함수 수준 reserved concurrency 간의 상호작용을 테스트합니다. 또한 이벤트 소스 재시도 동작(EventBridge)과 운영 효율적인 완화책도 다룹니다. 정답이 맞는 이유: 리전 quota가 1,000이고 다른 함수에 800 reserved concurrency가 설정된 상태에서 Throttles가 급증한다는 것은 결제 함수가 남은 unreserved pool(약 200 동시 실행)을 두고 경쟁하고 있음을 강하게 시사합니다. 플래시 세일 동안 수요가 그 pool을 초과하므로 Lambda가 invocation을 throttling합니다. 재설계 없이 가장 운영 효율적으로 해결하는 방법은 (C) 결제 함수에 reserved concurrency를 할당하여 다른 함수가 용량을 소비하더라도 보장된 concurrency 몫을 확보하는 것과, (E) 리전 concurrency quota 증가를 요청하여 전체 가용 concurrency가 피크 수요를 충족하도록 하는 것입니다. 주요 AWS 기능: Reserved concurrency는 함수가 해당 수치까지 확장할 수 있음을 보장하며 동시에 상한도 설정합니다(다운스트림 시스템 보호). 중요한 점은 reserved concurrency가 리전 quota에서 분리되어 할당되므로 다른 함수로 인한 noisy-neighbor 영향을 방지한다는 것입니다. Service Quotas를 사용하면 리전 Lambda concurrency 한도 증가를 요청할 수 있으며, 이는 전체 수요가 계정 quota를 초과할 때 throttling을 직접적으로 줄입니다. EventBridge는 throttled Lambda invocation을 재시도하지만, 재시도는 throttling을 제거하지 않고 처리 시점을 미루기만 합니다. 흔한 오해: 재시도 window/이벤트 수명(B)을 늘리면 데이터 손실은 줄일 수 있지만 throttling 자체는 줄지 않으며, backlog를 늘리고 복구 시간을 길게 만들 수 있습니다. 권한 변경(D)은 concurrency에 영향을 주지 않습니다. ECS로 재구축(A)은 재설계이며 즉각적인 운영 효율 조치가 아닙니다. 시험 팁: 트래픽이 높을 때 throttles가 보이면, 병목이 함수 reserved concurrency인지, 리전 concurrency quota인지, 또는 이벤트 소스의 concurrency 제한인지 먼저 판단하십시오. 다른 함수에 큰 reserved concurrency가 있으면, 그것이 다른 모든 함수가 공유하는 pool을 줄인다는 점을 기억하십시오. 가장 빠른 레버는 (1) 중요한 함수에 reserved concurrency를 설정해 용량을 보장하는 것과 (2) 계정 수준 상한이 제한 요인일 때 quota 증가를 요청하는 것입니다.

문제 7

한 미디어 회사가 웹 플레이어에서 Amazon Kinesis Data Streams 스트림으로 비디오 재생 텔레메트리를 수집하고, 스트림에 의해 트리거되는 AWS Lambda 함수가 각 재생 이벤트를 구조화된 JSON으로 로깅하고 처리합니다. 운영 검토 결과 일부 이벤트에서 playbackDurationSeconds가 0으로 설정되어 있는 것이 확인되었습니다. 개발자는 매일(1일 기간으로 그룹화) 영향을 받는 고유 viewerId 수를 보여주는 대시보드를 구축해야 합니다. 대시보드를 구현하기 위해 개발자가 해야 할 일은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon CloudWatch Logs + CloudWatch Logs Insights + CloudWatch Dashboards를 사용하여 애플리케이션 로그로부터 운영 분석을 도출하는 것을 평가합니다. 핵심 요구사항은 조건(playbackDurationSeconds = 0)을 만족하는 고유 viewerId를 카운트하고, 이를 1일 단위 시간 구간으로 그룹화하는 것입니다. 정답이 맞는 이유: Lambda 함수는 이미 각 재생 이벤트를 “구조화된 JSON으로 로깅하고 처리”하고 있습니다. 해당 JSON 이벤트(또는 viewerId와 playbackDurationSeconds를 포함하는 일부)가 CloudWatch Logs에 기록된다면, CloudWatch Logs Insights는 로그 그룹을 직접 쿼리할 수 있습니다. Logs Insights는 JSON 필드에 대한 필터링, 고유 개수 계산(예: count_distinct(viewerId)), 그리고 시간 구간화(예: bin(1d))를 지원하여 일별 집계를 생성할 수 있습니다. CloudWatch 대시보드는 Logs Insights 쿼리 위젯을 포함할 수 있으므로, 별도의 데이터 레이크나 metrics 파이프라인을 구축하지 않고도 일별로 영향을 받는 고유 시청자 수를 시각화할 수 있습니다. 주요 AWS 기능: 1) CloudWatch Logs 구조화 로깅: Lambda는 권한이 있을 때(일반적으로 AWSLambdaBasicExecutionRole) 자동으로 CloudWatch Logs에 기록합니다. JSON 로그를 사용하면 Insights에서 필드 추출이 가능합니다. 2) CloudWatch Logs Insights: filter 표현식, stats 집계, bin()을 통한 시계열 그룹화를 포함한 대화형 로그 분석에 최적화되어 있습니다. 3) CloudWatch Dashboards: Logs Insights 쿼리 결과를 위젯으로 표시하여 거의 실시간에 가까운 운영 가시성을 제공합니다. 흔한 오해: 자주 있는 함정은 CloudTrail 또는 EventBridge를 사용해 “이벤트를 쿼리”할 수 있다고 가정하는 것입니다. CloudTrail은 애플리케이션 텔레메트리가 아니라 AWS API 활동을 기록합니다. EventBridge는 이벤트를 라우팅하지만, 대시보드를 위한 시간 창 기반의 고유 개수 집계를 기본 제공하지 않습니다. 또 다른 오해는 고유 시청자 수를 위해 CloudWatch metrics/alarms를 사용하는 것입니다. CloudWatch metrics는 숫자 시계열이며, 사용자 지정 집계 로직 없이 고카디널리티 ID에 대한 고유 개수 계산을 기본적으로 지원하지 않습니다. 시험 팁: 문제에서 “구조화된 JSON으로 로깅”을 언급하고, 대시보드와 함께 애드혹 집계(고유 개수, 일별 그룹화)를 요구한다면 CloudWatch Logs Insights + Dashboard 위젯을 떠올리십시오. Athena는 데이터가 S3(데이터 레이크)에 있고 저장된 객체에 대해 SQL이 필요할 때 선택합니다. CloudWatch metrics/alarms는 고카디널리티 고유 분석이 아니라 숫자 metrics의 임계값 경보에 사용합니다.

문제 8

실시간 티켓팅 웹 앱이 Application Load Balancer 뒤에서 6대의 Amazon EC2 인스턴스로 구성된 Auto Scaling group에서 실행됩니다. 사용자 장바구니 및 로그인 상태를 클라이언트별로 인메모리에 유지하며(세션당 최대 64 KB), 1,500 writes/s와 1,500 reads/s가 발생합니다. 갑작스러운 인스턴스 종료 또는 scale-in 이벤트가 발생해도 어떤 세션 데이터도 유실되지 않아야 하고, 1초 이내에 복구되어야 하며, 여러 AZ에 걸쳐 높은 가용성을 유지해야 합니다. EC2 인스턴스가 실패하더라도 세션이 유실되지 않도록 개발자는 무엇을 해야 합니까?

문제 분석

핵심 개념: 이 문제는 Application Load Balancer(ALB) 뒤의 Auto Scaling group에 대해 stateless 웹 계층 설계와 고가용성 세션 관리 방식을 평가합니다. 핵심 원칙은 인스턴스가 종료되거나 scale-in될 수 있는 환경에서 사용자 세션 상태를 일시적인 EC2 인스턴스 메모리에 저장하지 않는 것입니다. 정답이 맞는 이유: 옵션 C는 세션 상태를 내구성이 있고 여러 AZ에 걸쳐 관리되는 데이터 저장소(Amazon DynamoDB)로 외부화합니다. 어떤 EC2 인스턴스가 예기치 않게 종료되더라도 세션 데이터는 계속 사용 가능하며, 다른 인스턴스가 DynamoDB에서 세션을 읽어 다음 요청을 즉시 처리할 수 있습니다. 이는 갑작스러운 종료/scale-in에도 세션 데이터 유실 없이 생존해야 하고 ~1초 내 복구해야 한다는 요구사항을 충족합니다(DynamoDB는 일반적으로 한 자릿수 ms 지연 시간이 일반적). 30분 TTL은 세션 만료와 정합하며 오래된 세션을 자동으로 제거합니다. 주요 AWS 기능: DynamoDB는 Region 내 여러 AZ에 걸쳐 본질적으로 높은 가용성을 제공하며 매우 높은 요청률을 위해 설계되었습니다. 1,500 writes/s와 1,500 reads/s, 그리고 작은 아이템(<=64 KB) 조건에서 DynamoDB는 매우 적합합니다. TTL을 사용하면 운영 부담이 줄어듭니다. 성능과 비용을 위해 애플리케이션은 on-demand capacity 또는 auto scaling이 있는 provisioned capacity를 사용할 수 있습니다. 필요하다면 DynamoDB Accelerator(DAX)가 read 지연 시간을 더 줄일 수 있지만, 문제에서 요구하는 사항은 아닙니다. 흔한 오해: Sticky sessions(A)는 사용자를 한 인스턴스에 고정하지만 인스턴스 장애나 scale-in을 방지하지 못합니다. 인스턴스가 사라지면 인메모리 세션도 사라집니다. Connection draining(D)은 정상적인 deregistration에 도움이 되지만 갑작스러운 종료를 처리하지 못하고 세션 상태를 복제하지도 않습니다. SQS(B)는 메시징 서비스이며 요청마다 세션을 읽는 저지연 key-value store가 아닙니다. queue에서 상태를 재구성하는 것은 복잡하고 즉시 read-after-write 세션 조회를 위해 설계되지 않았습니다. 시험 팁: “세션 상태를 메모리에 저장” + “Auto Scaling” + “세션 유실 금지”가 함께 나오면, 올바른 패턴은 웹 계층을 stateless로 만들고 세션을 공유되는 내구성 저장소(DynamoDB, ElastiCache/Redis, 또는 데이터베이스)에 저장하는 것입니다. 문제가 multi-AZ HA와 빠른 복구를 강조한다면, AZ 간 복제를 제공하고 저지연 read/write를 지원하는 managed service를 선택하십시오.

문제 9

온라인 티켓팅 플랫폼이 8개의 AWS Lambda 함수, 1개의 Amazon API Gateway HTTP API, 그리고 1개의 Amazon DynamoDB 테이블로 구성된 새로운 serverless 알림 서비스를 출시하려고 합니다. 이 서비스는 자동화를 통해 dev 및 prod에 배포되어야 하며, 배포 코드는 100줄 미만이어야 합니다. 또한 5분 동안 10% canary를 지원하고 자동 rollback을 제공해야 하며, 함수와 해당 인프라를 모두 빌드 및 배포하는 데 운영 오버헤드가 최소여야 합니다. 이러한 요구 사항을 가장 잘 충족하는 방법은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS Lambda에 대한 serverless Infrastructure as Code (IaC) 및 배포 전략, 특히 AWS SAM을 사용해 코드와 인프라를 모두 정의하고 안전한 점진적 배포(canary)와 자동 rollback을 수행하는 방법을 평가합니다. 정답인 이유: 옵션 B는 모든 요구 사항을 가장 잘 충족합니다: 최소한의 배포 코드(<100줄), dev 및 prod로의 자동 배포, 최소 운영 오버헤드, 그리고 5분 동안 10% canary 및 자동 rollback. AWS SAM을 사용하면 8개의 Lambda 함수, API Gateway HTTP API, DynamoDB 테이블을 간결한 SAM template로 정의할 수 있으며(내부적으로 CloudFormation 사용), 점진적 배포를 위해 SAM은 Lambda deployment preferences(예: Canary10Percent5Minutes)를 통해 AWS CodeDeploy와 통합되고 CloudWatch alarm 또는 health check 실패 시 자동으로 rollback할 수 있습니다. 주요 AWS 기능: - AWS SAM template: serverless 리소스를 위한 간결한 문법(AWS::Serverless::Function, AWS::Serverless::HttpApi, DynamoDB 테이블 리소스)으로 dev/prod 파라미터화를 지원합니다. - SAM CLI: sam build/package/deploy를 통해 artifact를 빌드하고 S3에 업로드한 뒤 CloudFormation stack을 일관되게 배포합니다. - CodeDeploy for Lambda: Canary10Percent5Minutes 같은 traffic shifting 구성과 alarm 트리거 시 자동 rollback을 제공합니다. - CI/CD 통합: SAM은 CodePipeline/CodeBuild 또는 서드파티 CI와 잘 연동되어 동일한 template을 환경 간 승격(promote)할 수 있습니다. 흔한 오해: A와 C는 zip 파일과 CLI/script를 사용하므로 “단순”해 보일 수 있지만, 운영 오버헤드를 증가시키고 일반적으로 애플리케이션 코드 배포와 인프라 프로비저닝을 분리하여 반복 가능한 환경 생성이 IaC 방식보다 더 어렵고 오래 걸립니다. D는 현대적으로 들릴 수 있으나(container), 복잡성(image build/push lifecycle)을 추가하고 CodeArtifact를 잘못 사용합니다(container image의 올바른 registry는 ECR). 또한 container는 자체적으로 canary/rollback 또는 IaC의 간결함을 해결하지 못합니다. 시험 팁: “serverless + 최소 운영 오버헤드 + 인프라와 코드를 함께 배포 + canary/rollback”을 보면 AWS SAM(또는 CDK)과 CodeDeploy를 떠올리세요. 또한 Lambda canary 배포는 일반적으로 CodeDeploy deployment preferences로 구현되며, Lambda용 container image는 CodeArtifact가 아니라 Amazon ECR에 저장한다는 점을 기억하세요. 참고: AWS SAM Developer Guide(serverless template 및 SAM CLI)와 AWS CodeDeploy의 AWS Lambda traffic shifting 및 자동 rollback 지원 문서.

문제 10

스포츠 분석 스타트업이 두 개의 Availability Zone에 걸쳐 Amazon EC2 launch type을 사용하여 Amazon ECS에서 지연 시간에 민감한 leaderboard microservice를 실행하고 있으며, 워크로드를 거의 중단 없이 Amazon ECS on AWS Fargate로 마이그레이션해야 합니다. blue/green cutover 동안 개발자는 cluster의 capacity providers를 구성하여 on-demand Fargate tasks가 기본으로 실행되도록(최소 1개의 task가 on-demand에서 실행되도록 보장) 하고, FARGATE_SPOT은 오버플로에만 사용되도록 해야 하며, AWS-owned capacity providers를 생성하려는 API 호출은 피해야 합니다. 어떤 솔루션이 가장 적은 다운타임으로 마이그레이션을 달성합니까?

문제 분석

핵심 개념: 이 문제는 ECS service를 EC2 launch type에서 AWS Fargate로 최소한의 중단으로 마이그레이션할 때의 Amazon ECS capacity providers 및 capacity provider strategies를 테스트합니다. 또한 AWS-owned capacity providers(FARGATE, FARGATE_SPOT)와 customer-managed capacity providers(일반적으로 EC2용 Auto Scaling groups 기반)의 차이도 테스트합니다. 정답이 맞는 이유: Fargate에서 tasks를 실행하려면 cluster가 AWS-owned FARGATE 및(선택적으로) FARGATE_SPOT capacity providers와 연결되어 있어야 합니다. 기존 cluster에 이를 연결하는 올바른 방법은 PutClusterCapacityProviders를 사용하는 것으로, 이는 cluster에서 사용 가능한 capacity providers 목록과 cluster의 default capacity provider strategy를 모두 설정합니다. 그런 다음 on-demand Fargate가 기본이 되도록 하고 최소 1개의 task가 항상 on-demand에서 실행되도록 하려면 FARGATE에 base=1인 strategy를 설정합니다. 추가 tasks는 weight에 따라 분배되며, FARGATE에 FARGATE_SPOT 이상(>=)의 weight를 부여하면 on-demand가 선호되면서도 FARGATE_SPOT을 오버플로에 사용할 수 있습니다. 이는 기존 서비스가 정상 상태를 유지하는 동안 새로운 Fargate 기반 service/task set을 배포한 뒤 트래픽을 전환할 수 있으므로 거의 다운타임 없이 blue/green cutover를 지원합니다. 주요 AWS 기능: - PutClusterCapacityProviders: AWS-owned capacity providers를 cluster에 연결하고 default strategy를 설정합니다. - Capacity provider strategy 필드: - base: weight가 적용되기 전에 해당 provider에 배치되는 최소 task 수 - weight: 나머지 tasks에 대한 상대적 분배 비율 - AWS-owned providers: FARGATE 및 FARGATE_SPOT은 고객이 생성하는 것이 아니라 참조/연결합니다. - ECS에서 blue/green은 일반적으로 CodeDeploy(ECS deployment controller)와 ALB로 구현되지만, 이 문제의 초점은 cutover 동안의 capacity placement 동작을 보장하는 것입니다. 흔한 오해: 자주 걸리는 함정은 CreateCapacityProvider로 Fargate capacity providers를 “생성”해야 한다고 생각하는 것입니다. 해당 API는 custom capacity providers(예: EC2 Auto Scaling 기반)를 위한 것이지 AWS-owned FARGATE/FARGATE_SPOT을 위한 것이 아닙니다. 또 다른 함정은 FARGATE_SPOT에 base=1을 설정하는 것으로, 이는 최소 1개의 task가 on-demand에서 실행되어야 한다는 요구사항을 위반합니다. 시험 팁: - 기억할 점: AWS-owned capacity providers(FARGATE/FARGATE_SPOT)는 생성이 아니라 연결합니다. - “X에 최소 N개의 tasks”는 base=N을 사용합니다. - “Spot은 오버플로에만 사용”은 on-demand provider에 base 및/또는 더 높은 weight를 주고, Spot은 더 낮은 weight의 보조로 둡니다.

Practice Test #1

3중 AI 검증 답안 및 해설

기출 문제

합격 후기(8)

다른 모의고사

Practice Test #2

Practice Test #3

Practice Test #4

Practice Test #5

Practice Test #6

지금 학습 시작하기