연습 문제

문제 1

한 비디오 분석 회사는 모든 기능이 활성화된 단일 AWS Organizations organization에서 28개의 AWS account를 관리하고, 기준 배포를 위해 AWS CloudFormation StackSets를 사용하며, AWS Config는 이미 일반적인 S3 설정을 모니터링하고 있습니다. 이제 보안 팀은 모든 account와 Region 전반에서 발생하는 모든 S3 PutObject가 AWS Key Management Service (AWS KMS) server-side encryption (SSE-KMS)을 사용하도록 보장하고, 운영 오버헤드를 최소화하면서 비준수 업로드 시도를 차단하는 예방적 제어를 요구합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 분석

핵심 개념: 이 문제는 AWS Organizations Service Control Policies (SCPs)를 사용하여 Amazon S3에 대한 예방적이고 organization 전체 범위의 보안 제어를 테스트합니다. SCP는 account/OU에 대해 사용 가능한 최대 권한을 설정하는 가드레일로, 비준수 API 호출이 성공하기 전에 차단할 수 있습니다. 정답이 맞는 이유: 요구 사항은 모든 account와 Region 전반에서 모든 S3 PutObject가 SSE-KMS를 사용하도록 보장하고, 운영 오버헤드를 최소화하면서 비준수 업로드를 차단하는 것입니다. organization root에 연결된 SCP는 요청에서 AWS KMS server-side encryption (x-amz-server-side-encryption = aws:kms)을 지정하지 않을 때 s3:PutObject을 명시적으로 거부할 수 있습니다. SCP의 명시적 Deny는 IAM 권한과 무관하게 적용되므로, 이는 에이전트, rule 또는 account별 도구를 배포하지 않고도 모든 member account(신규 account 포함)에서 비준수 PutObject 요청을 중지하는 예방적 제어를 제공합니다. 주요 AWS 기능: - AWS Organizations SCPs: 중앙 집중식, 확장 가능한 가드레일; 명시적 Deny는 Allow를 무시합니다. - S3 condition key: s3:x-amz-server-side-encryption을 사용하여 PutObject에서 aws:kms를 요구합니다. 이는 요청 시점에 암호화를 강제합니다(예방적). - organization root 연결: 최소한의 지속 운영으로 모든 account/OU 및 Region 전반에 적용 범위를 보장합니다. 일반적인 오해: - AWS Config( conformance pack 포함)는 주로 탐지/수정 중심이며 예방적이지 않습니다. 비준수를 보고하고 알림 또는 remediation을 트리거할 수는 있지만, PutObject 호출을 본질적으로 차단하지는 않습니다. - CloudTrail + EventBridge 또한 탐지 방식입니다. 사후에 경고할 수는 있지만 업로드를 예방할 수는 없습니다. - CreateBucket을 거부하는 것은 object 업로드를 해결하지 못합니다. 암호화 요구 사항은 PutObject(그리고 실제 구현에서는 multipart upload 관련 action일 수 있음)에서 강제되어야 합니다. 시험 팁: 문제에서 “예방적 제어”와 “비준수 시도 차단”을 여러 account에 걸쳐 낮은 오버헤드로 요구하면, Config/CloudTrail보다는 SCP(또는 경우에 따라 permission boundary)를 떠올리십시오. 또한 policy의 action이 요구 동작과 일치하는지 확인하십시오. object 암호화는 bucket 생성이 아니라 s3:PutObject에서 강제됩니다. 실제로는 관련 S3 action(예: multipart upload)과 bucket policy도 고려할 수 있지만, organization 전체 강제에는 SCP가 시험에서의 정석 답입니다.

문제 2

데이터 플랫폼 팀이 팀들이 매일 밤 ETL proof of concept를 빠르게 실행하고 종료할 수 있도록 AWS CloudFormation template을 만들었습니다. 이 template은 AWS Glue job과 versioning이 활성화되어 있고 객체를 90일 동안 보관하는 lifecycle rule이 있는 Amazon S3 bucket을 프로비저닝합니다. 그런데 stack이 생성 후 24시간 이내에 삭제될 때 bucket에 여전히 객체와 delete marker가 남아 있어 CloudFormation에서 S3 bucket에 대해 DELETE_FAILED가 표시됩니다. 따라서 팀은 모든 리소스가 자동으로 제거되고 오류 없이 stack 삭제가 완료되도록 보장하는 가장 효율적인 방법이 필요합니다.

문제 분석

핵심 개념: 이 문제는 Amazon S3 bucket, 특히 versioning이 활성화된 경우의 CloudFormation stack 삭제 동작을 테스트합니다. CloudFormation은 S3 bucket이 비어 있을 때만 삭제할 수 있습니다. versioning이 있는 경우 “비어 있음”은 현재 객체가 없고, noncurrent version도 없고, delete marker도 없는 상태를 의미합니다. 정답이 맞는 이유: Option B는 가장 효율적이며 완전 자동화된 접근 방식입니다. Lambda-backed custom resource가 stack 삭제 중에 정리 작업을 수행합니다. RequestType=Delete에서 function이 객체 version과 delete marker(및 남아 있는 현재 객체)를 나열하고 삭제합니다. bucket이 실제로 완전히 비워지면 CloudFormation이 bucket 리소스를 성공적으로 삭제하고 DELETE_FAILED 없이 stack 삭제를 완료할 수 있습니다. 이는 IaC best practice와도 일치합니다. 즉, stack은 자체 포함적이어야 하며 수동 단계 없이 완전히 되돌릴 수 있어야 합니다(깨끗하게 생성 및 삭제). 주요 AWS 기능: - CloudFormation custom resource(Lambda-backed)는 stack lifecycle event(Create/Update/Delete) 동안 명령형 작업을 수행할 수 있게 합니다. - S3 versioning은 delete marker와 여러 version을 도입하며, 삭제에는 version ID와 delete marker에 대한 DeleteObjects가 필요합니다. - CloudFormation 리소스 dependency 제어(DependsOn)를 사용하면 CloudFormation이 bucket 삭제를 시도하기 전에 custom cleanup이 실행되도록 보장할 수 있습니다. - IAM least privilege: Lambda role에는 s3:ListBucket, s3:ListBucketVersions, s3:DeleteObject / s3:DeleteObjectVersion(그리고 사용 중이라면 s3:DeleteObjectTagging도) 권한이 필요합니다. 흔한 오해: 흔한 함정은 CloudFormation의 DeletionPolicy: Delete가 비어 있지 않은 bucket을 “강제로 삭제”해 준다고 가정하는 것입니다. 그렇지 않습니다. S3는 여전히 bucket 안에 무엇인가 남아 있으면 삭제를 거부합니다. 또 다른 오해는 lifecycle rule이 여기서 도움이 된다는 것입니다. lifecycle expiration은 즉시 실행되지 않으며, 특히 version과 delete marker에 대해서는 24시간 이내에 동작하지 않습니다. 시험 팁: “S3 bucket 삭제 실패” + “versioning enabled”를 보면 즉시 떠올려야 할 것은: 객체 version과 delete marker를 삭제해야 한다는 점입니다. CloudFormation에서는 표준적인 시험 패턴으로 Lambda-backed custom resource(또는 명시적으로 언급된 경우 더 새로운 native 메커니즘)를 사용해 stack 삭제 중에 bucket을 비웁니다. 수동 정리보다 자동화되고 반복 가능한 IaC 기반 솔루션을 선호하세요.

문제 3

한 온라인 게임 플랫폼이 Auto Scaling group에서 us-east-1 및 us-west-2에 걸쳐 12개의 Amazon EC2 instances를 운영하고 있습니다. AWS Health는 reboot가 필요한 scheduled instance retirement 및 underlying host maintenance notifications를 게시하며, 회사는 remediation이 매주 일요일 01:00~03:00 UTC의 기존 AWS Systems Manager maintenance window 내에서만 수행되어야 한다고 요구합니다. 그렇다면 DevOps engineer는 reboots가 maintenance window 안에서만 실행되도록 보장하면서 이러한 notifications를 자동으로 처리하기 위해 Amazon EventBridge rule을 어떻게 구성해야 합니까?

문제 분석

핵심 개념: 이 문제는 Amazon EventBridge, AWS Health 이벤트, 그리고 AWS Systems Manager (SSM) Maintenance Windows/Automation을 사용한 event-driven remediation을 테스트합니다. 핵심 요구 사항은 scheduled instance retirement 및 underlying host maintenance에 대한 AWS Health 알림을 단순히 감지하는 것뿐만 아니라, reboot와 같은 disruptive action이 사전에 승인된 maintenance window 동안에만 수행되도록 강제하는 것입니다. 정답인 이유: AWS Health는 EC2에 대한 account-specific operational event를 게시하며, 여기에는 reboot가 필요할 수 있는 scheduled instance retirement 및 underlying host maintenance 또는 scheduled change event가 포함됩니다. EventBridge는 이러한 AWS Health 이벤트를 매칭하고 downstream automation을 트리거할 수 있습니다. 그러나 EventBridge에서 reboot runbook을 직접 호출하면 즉시 실행되므로, 기존 Sunday 01:00–03:00 UTC maintenance window 동안에만 작업해야 한다는 요구 사항을 위반하게 됩니다. 선택지 C는 EventBridge를 사용해 Health 이벤트를 감지한 다음, Lambda function을 호출하여 기존 window에 대해 SSM Maintenance Window task를 등록하므로 AWS-RestartEC2Instance runbook이 해당 window가 열릴 때만 실행되도록 합니다. 주요 AWS 기능: - account-specific EC2 operational notification을 위한 AWS Health와 EventBridge의 통합. - 실행을 승인된 시간 범위로 제한하는 SSM Maintenance Windows. - 표준화된 remediation을 수행하는 AWS-RestartEC2Instance와 같은 SSM Automation runbook. - Health event payload를 영향을 받는 instance에 대한 maintenance window task로 변환하는 orchestration glue 역할의 Lambda. - AWS Health 이벤트는 특정 Region의 영향을 받는 resource를 식별하고, SSM action은 instance가 존재하는 Region에서 실행되어야 하므로 Regional awareness가 중요함. 흔한 오해: A는 AWS Health에서 올바르게 시작하기 때문에 그럴듯해 보이지만, restart automation을 즉시 호출하므로 maintenance window 요구 사항을 무시합니다. B는 영향을 받는 EC2 instance를 식별하는 source of truth를 Systems Manager maintenance window event로 잘못 간주하지만, 실제 트리거는 AWS Health에서 와야 합니다. D는 EC2 state-change notification을 사용하지만, 이는 예정된 retirement 또는 host maintenance 이벤트에 대한 authoritative source가 아니며 너무 늦게 발생할 수 있습니다. 시험 팁: 문제에서 remediation이 maintenance window 동안에만 발생해야 한다고 하면, 이를 강제하는 메커니즘은 SSM Maintenance Windows입니다. EventBridge는 AWS Health 이벤트를 감지하는 데 일반적으로 사용되지만, 승인된 window로 실행을 지연시키기 위해 Lambda 또는 다른 orchestration layer가 필요한 경우가 많습니다. 또한 scheduled retirement 및 host maintenance의 경우, 올바른 event source는 EC2 state-change notification이 아니라 AWS Health입니다.

문제 4

(3개 선택)

에너지 스타트업이 시간별로 내보낸 120GB의 센서 진단 데이터를 CSV 형식으로 Amazon S3 bucket에 날짜/시간 파티션 prefix(예: s3://env-data/diagnostics/year=2025/month=08/day=16/hour=00-23) 아래에 저장합니다. SQL 분석가 팀은 어떤 서버도 관리하지 않고 standard SQL을 사용해 ad hoc 쿼리를 실행해야 하며, 24시간마다 새로 고침되는 line 및 bar chart가 포함된 interactive dashboard를 게시해야 합니다. 또한 팀은 새로운 시간별 object가 도착할 때마다 CSV 파일의 table metadata(컬럼, 데이터 타입, 파티션)를 캡처하고 유지 관리할 수 있는 효율적이고 자동화되며 지속적인 방법이 필요합니다. 가장 적은 노력으로 이러한 요구 사항을 충족하는 단계 조합은 무엇입니까? (세 가지를 선택하세요.)

문제 분석

핵심 개념: 이 문제는 AWS에서의 전형적인 serverless analytics 패턴을 테스트합니다. 즉, 원시 파일을 Amazon S3에 저장하고, Amazon Athena(serverless SQL)로 쿼리하며, AWS Glue Data Catalog에서 metadata와 파티션을 유지하고, Amazon QuickSight로 결과를 시각화하는 방식입니다. 또한 지속적으로 유입되는 데이터에 대해 schema/partition discovery를 자동화하는지도 간접적으로 테스트합니다. 정답이 맞는 이유: (C) Amazon Athena는 서버를 프로비저닝하거나 관리하지 않고도 S3의 CSV 데이터에 대해 직접 ad hoc 쿼리를 실행할 수 있게 해줍니다. standard SQL(Presto/Trino 기반)을 지원하며 data lake에 대한 interactive querying을 위해 설계되었습니다. (E) AWS Glue Data Catalog는 테이블 정의(컬럼, 데이터 타입)와 파티션을 위한 지속적이고 관리형 metastore를 제공합니다. Glue crawler는 CSV에서 schema를 자동으로 추론하고, 시간별 prefix가 도착함에 따라 새로운 파티션을 발견하여 metadata를 최신 상태로 유지하므로 수동 작업을 최소화합니다. (B) Amazon QuickSight는 interactive dashboard(line/bar chart)를 위한 관리형 BI 서비스이며, dataset을 스케줄에 따라(예: 24시간마다) 새로 고침할 수 있습니다. QuickSight는 Athena(및 Athena가 사용하는 Glue Data Catalog 테이블)와 네이티브로 통합되어 S3에서 dashboard까지 운영 부담이 적은 파이프라인을 제공합니다. 주요 AWS 기능: Athena는 Glue Data Catalog를 기본 metastore로 사용하므로 Glue에서 테이블/파티션을 정의하면 즉시 쿼리할 수 있습니다. Glue crawler는 스케줄링하거나 트리거하여 새로운 S3 prefix가 나타날 때 파티션을 업데이트할 수 있습니다. QuickSight는 Athena를 data source로 사용할 수 있고, 더 빠른 dashboard 성능을 위해 SPICE로 가져올 수 있으며, 24시간마다 refresh를 스케줄링할 수 있습니다. 흔한 오해: Redshift(D)는 강력하지만 cluster 관리가 필요하며(Redshift Serverless를 사용하더라도 데이터 모델링/로딩 결정이 필요), Athena로 in-place 쿼리하는 것보다 ad hoc 분석에는 더 많은 노력이 듭니다. DynamoDB(F)는 SQL 엔진을 위한 metastore가 아니며 custom schema/partition 관리 로직이 필요합니다. X-Ray(A)는 분산 애플리케이션 tracing 용도이지 analytics/visualization 용도가 아닙니다. 시험 팁: “ad hoc SQL”, “no servers”, “data in S3”를 보면 Athena를 떠올리세요. “persistent metadata”, “schema/partitions”, “automated discovery”를 보면 Glue Data Catalog + crawler를 떠올리세요. “interactive dashboards”와 “scheduled refresh”를 보면 QuickSight를 떠올리세요. 이 조합(S3 + Glue + Athena + QuickSight)은 Well-Architected 관점에서 운영 부담이 적은 analytics reference pattern으로 흔히 사용됩니다.

문제 5

미디어 스트리밍 스타트업이 AWS CloudFormation으로 실시간 ingestion 계층을 전적으로 관리하고 있다. 템플릿은 두 개의 private subnet(us-east-1) 전반에 걸쳐 Launch Template에서 Amazon EC2 인스턴스를 시작하는 AWS::AutoScaling::AutoScalingGroup(min=2, desired=4, max=6), Network Load Balancer, 그리고 기타 지원 리소스를 프로비저닝하며, 회사 정책은 CloudFormation 외부에서의 어떤 변경도 금지한다. 한 엔지니어가 AWS CLI를 사용해 업데이트를 배포했지만, 업데이트는 “ERROR: both the deployment and the CloudFormation stack rollback failed. The deployment failed because the following resource(s) failed to update: [AutoScalingGroup]”라는 메시지와 함께 실패했고, 스택은 UPDATE_ROLLBACK_FAILED 상태로 남았다 — 어떤 조치가 이 문제를 해결하는가?

문제 분석

핵심 개념: 이 문제는 AWS CloudFormation 스택 실패 상태와 복구 조치, 특히 UPDATE_ROLLBACK_FAILED, 그리고 AWS::AutoScaling::AutoScalingGroup 같은 리소스를 CloudFormation이 update/rollback하기 위해 필요한 운영 control plane을 테스트한다. 정답인 이유: 스택 업데이트가 실패하면 CloudFormation은 마지막으로 정상 동작하던 상태로 rollback을 시도한다. rollback도 실패하면 스택은 UPDATE_ROLLBACK_FAILED 상태가 된다. 이때 지원되는 해결 방법은 rollback을 막았던 근본 원인(일반적으로 IAM 권한 누락, 리소스 수준 접근 문제, 또는 외부 제약)을 수정한 뒤 aws cloudformation continue-update-rollback을 실행하여 CloudFormation이 rollback을 완료하고 스택을 안정 상태로 되돌리게 하는 것이다. 문제에서 “배포와 CloudFormation 스택 rollback이 모두 실패했다”고 하며, 실패한 리소스가 AutoScalingGroup이라고 명시한다. ASG에서 rollback이 실패하는 흔한 이유는 CloudFormation 실행 role(또는 service role을 사용하지 않는 경우 호출자의 권한)에 관련 리소스를 수정하거나 분리하는 권한이 부족하기 때문이다(예: UpdateAutoScalingGroup, CreateOrUpdateTags, TerminateInstanceInAutoScalingGroup, DetachLoadBalancerTargetGroups). 필요한 권한을 포함하도록 IAM role을 업데이트하면 rollback 실패 원인을 직접 해결할 수 있고, continue-update-rollback이 이 스택 상태에 맞는 올바른 명령이다. 주요 AWS 기능 / 모범 사례: - CloudFormation 스택 상태: UPDATE_FAILED vs UPDATE_ROLLBACK_FAILED. - 복구 메커니즘: 근본 원인 수정 후 ContinueUpdateRollback. - 최소 권한 원칙과 완전성: CloudFormation service role에 관리 대상 모든 리소스의 create/update/delete/rollback에 필요한 모든 action이 포함되도록 보장. - “CloudFormation 외부 변경 금지” 정책은 수동 삭제가 아닌 CloudFormation 네이티브 복구를 사용하는 것과 일치. 흔한 오해: - 업데이트를 “취소”해야 한다고 생각: cancel-update-stack은 UPDATE_ROLLBACK_FAILED의 표준 해결책이 아니며, 이미 실패한 rollback을 해결하지 못한다. - EC2 quota 문제라고 단정: quota는 업데이트 실패를 유발할 수 있지만, 이 문제는 rollback 실패를 강조하며 올바른 remediation 흐름은 여전히 차단 요인을 해결하고 rollback을 계속하는 것이다. - 리소스를 수동으로 삭제: 정책을 위반하고 drift를 악화시키는 경우가 많다. CloudFormation은 통제된 복구 경로를 제공한다. 시험 팁: 다음 매핑을 암기하라: UPDATE_ROLLBACK_FAILED → 근본 원인(대개 IAM/permissions 또는 리소스 제약) 수정 → ContinueUpdateRollback. 문제가 rollback 실패를 언급하면 update-stack/update-stack-set/cancel-update-stack 또는 수동 개입보다 continue-update-rollback을 찾아라.

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

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

문제 6

미디어 분석 플랫폼은 eu-central-1에서 Amazon Aurora PostgreSQL-Compatible Multi-AZ DB cluster로 프로덕션 데이터베이스를 실행하고, 재해 복구를 위해 eu-west-1에 cross-Region read replica를 두고 있으며, RPO ≤1분 및 RTO ≤10분을 요구합니다. 또한 writer cluster endpoint에 2분 이상 도달할 수 없을 경우 cross-Region replica를 자동으로 primary로 승격해야 하며, Amazon ECS Fargate에서 실행되는 컨테이너화된 애플리케이션이 최소한의 수동 개입으로 계속 동작하도록 보장해야 합니다. 애플리케이션은 시작 시 AWS Systems Manager Parameter Store에서 가져온 데이터베이스 endpoint를 사용하고 60초 동안 캐시합니다. 어떤 솔루션이 이를 달성할 수 있습니까?

문제 분석

핵심 개념: 이 문제는 cross-Region Aurora 재해 복구 자동화, 이벤트 기반 failover 오케스트레이션, 그리고 애플리케이션 endpoint 관리에 대한 이해를 평가합니다. 핵심 서비스는 Amazon Aurora(cross-Region read replica promotion), Amazon EventBridge(RDS/Aurora events), AWS Lambda(자동화), AWS Systems Manager Parameter Store(동적 endpoint 배포)입니다. 정답이 맞는 이유: 옵션 D는 명시된 동작과 일치합니다. 애플리케이션은 시작 시 Parameter Store에서 DB endpoint를 읽고 60초 동안 캐시합니다. eu-west-1 replica를 승격하고 Parameter Store 값을 자동으로 업데이트하면, 애플리케이션은 캐시된 값을 갱신하거나 연결 실패 시 최소한의 수동 개입으로 재연결할 수 있습니다. EventBridge는 unavailability/failover 조건을 나타내는 RDS/Aurora 이벤트에 빠르게 반응할 수 있고, Lambda는 적절한 RDS/Aurora API를 호출하여 cross-Region read replica를 승격할 수 있습니다. “writer endpoint unreachable 2분” 요구사항은 이벤트 감지(또는 보조적인 health check/alarms)와 자동화를 결합하여 충족할 수 있으며, 60초 캐시와 재시도 로직은 ≤10분 RTO를 지원합니다. 주요 AWS 기능: - Aurora cross-Region read replica promotion: DR Region에서 replica cluster를 쓰기 가능하도록 승격합니다. - RDS events와의 Amazon EventBridge 통합: failover 관련 이벤트를 자동화로 거의 실시간 라우팅합니다. - Lambda 자동화: 승격을 실행한 다음 Parameter Store를 새 writer endpoint로 업데이트합니다. - 구성 소스로서의 Parameter Store: 중앙 집중적이고 감사 가능한 endpoint 값이며, task를 재배포하지 않고도 빠른 전환을 지원합니다. - 애플리케이션 복원력 모범 사례: exponential backoff를 포함한 연결 재시도와 실패/TTL 시 구성 새로고침을 구현합니다. 흔한 오해: 흔한 함정은 Route 53을 사용해 Aurora cluster endpoint 간 “fail over”를 한다고 생각하는 것입니다. DNS failover는 read replica를 writer로 승격하지 않으며 TTL/캐싱으로 인해 느려질 수 있습니다. 또한 Aurora cluster endpoint는 writer 가용성을 반영하는 일반적인 health check 대상으로 적합하지 않습니다. 또 다른 오해는 CloudTrail이 RDS 장애의 올바른 트리거라는 것입니다. CloudTrail은 API 호출을 기록할 뿐, 서비스 health/failover 이벤트를 기록하지 않습니다. 시험 팁: Aurora cross-Region replica를 사용하는 DR에서는 다음을 기억하십시오: (1) Aurora Global Database managed failover를 사용하지 않는 한(여기서는 설명되지 않음) 승격은 명시적으로 자동화되어야 합니다. (2) 이벤트 기반 자동화는 일반적으로 EventBridge RDS events를 사용합니다. (3) endpoint 관리는 애플리케이션이 구성을 소비하는 방식(Parameter Store + refresh/retry)과 일치해야 합니다. 항상 RTO/RPO를 복제 유형과 자동화 지연에 매핑하고, 상태 있는 승격이 필요한 경우 DNS-only 답안을 피하십시오.

문제 7

미디어 분석 스타트업이 us-east-1의 두 VPC에 걸쳐 180개의 EBS-backed Amazon EC2 인스턴스(c5 및 m6i)를 운영하고 있습니다. 수동 개입을 줄이기 위해 DevOps 팀은 AWS가 EC2 인스턴스 retirement event를 스케줄링할 때마다, 영향을 받는 인스턴스만 관리형 서비스를 사용해 5분 이내에 자동으로 재시작(중지 후 시작)되도록 보장해야 합니다. 또한 Systems Manager는 모든 인스턴스에서 이미 활성화되어 있습니다. 엔지니어는 어떤 접근 방식을 구현해야 합니까?

문제 분석

핵심 개념: 이 문제는 계획된 AWS 인프라 라이프사이클 이벤트(EC2 instance retirement)에 대해 이벤트 기반으로 remediation을 수행하는 것을 테스트합니다. 핵심 서비스는 AWS Health(retirement 알림), Amazon EventBridge(이벤트 매칭 및 라우팅), AWS Systems Manager Automation(특정 인스턴스에 대한 제어된 stop/start 작업)입니다. 정답이 맞는 이유: EC2 scheduled retirement는 AWS가 인스턴스가 retire될 것임을 알리는 계획된 이벤트이며, 정상 하드웨어로 이동하려면 인스턴스를 stop/start(또는 교체)해야 합니다. 요구사항은 영향을 받는 인스턴스만 5분 이내에 자동으로 재시작하고, 수동 개입을 최소화하며, 관리형 서비스를 사용하고, Systems Manager가 이미 활성화되어 있다는 것입니다. AWS Health 이벤트는 영향을 받는 인스턴스에 대해 발생합니다. EventBridge rule은 특정 retirement event type을 매칭하고 이벤트 payload에서 instance ID를 추출할 수 있습니다. 그런 다음 해당 rule이 그 instance ID에 대해 stop 후 start를 수행하는 SSM Automation runbook을 호출하여 “영향받는 인스턴스만” 및 “5분 이내” 요구사항을 충족합니다. 주요 AWS 기능: - AWS Health + EventBridge 통합: 계정에 영향을 주는 서비스 이벤트를 거의 실시간으로 전달. - source/detail-type(예: AWS Health) 및 특정 EC2 retirement 세부 정보에 대한 EventBridge rule pattern matching. - 파라미터(InstanceId)와 EC2 StopInstances/StartInstances를 호출하는 단계로 구성된 Systems Manager Automation runbooks(AWS-managed 또는 custom). - IAM least privilege: EventBridge는 Automation execution을 시작할 권한이 필요하고, Automation은 대상 인스턴스에 대해 ec2:StopInstances/ec2:StartInstances 권한이 필요함. 흔한 오해: 많은 사람이 “retirement”를 “impaired host” recovery와 혼동합니다. EC2 Auto Recovery는 CloudWatch alarms를 사용해 기본 호스트 장애를 대상으로 하며, scheduled retirement events를 처리하지 않고 stop/start도 수행하지 않습니다. 또한 매주 스케줄된 점검은 이벤트 기반이 아니므로 5분 SLA를 놓칠 수 있습니다. 시험 팁: “scheduled event”(retirement, maintenance)와 “몇 분 이내”가 보이면 EventBridge 기반 자동화를 떠올리세요. “managed remediation”과 “SSM enabled”가 보이면 EventBridge로 트리거되는 SSM Automation runbooks를 떠올리세요. Auto Recovery(예기치 않은 호스트 impairment)와 retirement notifications(계획된 라이프사이클 이벤트)를 구분하세요.

문제 8

플랫폼 팀이 us-east-1의 단일 Amazon EC2 인스턴스에서 외부 핀테크 파트너를 위한 webhook relay broker를 운영하고 있습니다. Amazon Route 53은 현재 simple A record(TTL 20초)를 사용하여 broker.payco.example을 해당 인스턴스로 매핑하고 있습니다. broker는 /data에 마운트된 Amazon EFS file system에 session state와 message offset을 저장하며, 여러 개의 active node에 걸쳐 동작할 수 없습니다. 또한 팀은 동일한 EFS를 마운트하고 패치된 상태로 idle로 유지되는, 다른 Availability Zone(us-east-1b)의 warm standby EC2 인스턴스를 프로비저닝해 두었습니다. 팀은 자동 failover를 원합니다. 즉, primary broker의 /healthz endpoint가 5초 간격의 연속 3회 검사에서 HTTP 200을 반환하지 않으면, 수동 개입 없이 client traffic이 standby로 리디렉션되어야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족하나요?

문제 분석

핵심 개념: 이 문제는 단일-active 워크로드를 위한 Amazon Route 53 health check 및 routing policy를 사용한 DNS 기반 failover를 테스트합니다. broker는 active-active로 실행할 수 없고 EFS의 shared state에 의존하므로, 장애 시 자동 리디렉션을 제공하면서도 오직 하나의 node만 트래픽을 수신하도록 설계해야 합니다. 정답이 맞는 이유: 옵션 A는 health check가 연결된 Route 53 weighted record를 사용하여 active/passive 패턴을 구현합니다. primary record의 weight는 100이고 standby는 0이므로, 정상 상태에서는 DNS 응답에 primary만 반환됩니다. Route 53이 primary를 unhealthy로 표시하면(/healthz endpoint가 5초 간격으로 연속 3회 non-200을 반환하는 기준), Route 53은 primary record를 더 이상 반환하지 않습니다. primary가 제거되면 남아 있는 “healthy” record는 standby뿐이므로, DNS 응답이 자동으로 standby로 전환되어 수동 개입 없이 failover가 이루어집니다. 주요 AWS 기능: - Route 53 health check: HTTP endpoint(/healthz)를 probe할 수 있으며, request interval을 5초(fast check)로 설정하고 failure threshold를 3으로 설정할 수 있어 요구 사항과 일치합니다. - health check가 있는 weighted routing 동작: Route 53은 healthy로 간주되는 record만 반환하며, unhealthy record는 응답에서 제외됩니다. - 낮은 TTL(20초): client 측 캐싱 시간을 줄여 실질적인 전환을 빠르게 하지만, 일부 client는 TTL을 무시할 수 있습니다. 흔한 오해: - 99/1 weight(옵션 B)는 진정한 standby가 아닙니다. primary가 healthy일 때도 standby로 일부 production traffic을 의도적으로 보내므로, “여러 active node에 걸쳐 동작할 수 없음” 제약을 위반합니다. - weight를 사용하는 ALB(옵션 C/D)는 health 기반 라우팅에 매력적으로 보일 수 있지만, ALB target group weight는 엄격한 failover가 아니라 active 분산을 위한 것입니다. weight 0은 “절대 트래픽을 보내지 않음”을 표현하는 신뢰할 수 있거나 유효한 방식이 아니며, ALB는 DNS 수준의 failover 의미론이 아니라 load balancer 계층에서 라우팅/health를 고려합니다. 시험 팁: “single active node”, “warm standby”, “Route 53 record와 health 기반 cutover”를 보면 Route 53 failover 또는 health check가 있는 weighted routing을 떠올리세요. 애플리케이션이 active-active가 될 수 없는데도 두 node로 트래픽을 보내는(1%라도) 옵션은 피하세요. 또한 health check interval과 failure threshold가 요구 사항과 정확히 일치하는지 확인하세요.

문제 9

한 회사는 AWS Organizations 조직에서 12개의 AWS 계정을 운영하고 있으며, SecOps 팀은 us-east-1 또는 eu-west-1의 어떤 멤버 계정이든 Amazon RDS DB 인스턴스를 공개적으로 액세스 가능하도록 변경하는 경우(PubliclyAccessible=true) 5분 이내에 Amazon Simple Notification Service (Amazon SNS) 알림을 받아야 합니다. 또한 DevOps 엔지니어는 기존 워크로드를 중단하지 않으면서, 멤버 계정이 알림을 비활성화하거나 우회할 수 없도록 보장하며, us-east-1의 위임된 관리자 계정에서 이를 중앙에서 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?

문제 10

미디어 분석 스타트업이 Amazon EC2에서 Nginx 하에 실행되는 Node.js 서비스를 롤아웃 자동화하기 위해 AWS CodeDeploy로 표준화하고 있습니다. 팀은 proof of concept으로 시작해 dev 환경용 deployment group을 생성하고 기능 테스트를 완료했으며, 다음으로 staging 및 production group을 추가할 계획입니다. 현재 request logging level은 Nginx configuration에 정의되어 있지만, 팀은 별도의 application revision이나 group별로 다른 script version을 유지하지 않으면서도 관리 오버헤드를 최소화하고 CodeDeploy lifecycle hook과 configuration에 의존하여, 배포 시점에 이 log verbosity가 동적으로 변경되기를 원합니다. 즉 dev는 DEBUG, staging은 INFO, production은 WARN을 사용해야 합니다. 이 요구 사항을 가장 잘 충족하는 접근 방식은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon EC2에서의 AWS CodeDeploy in-place deployment, 특히 별도의 application revision을 만들지 않고도 배포 시점에 environment별 configuration을 적용하기 위해 CodeDeploy lifecycle event hook과 built-in environment variable을 사용하는 방법을 평가합니다. 정답인 이유: Option B가 최선인 이유는 CodeDeploy가 instance에서 실행되는 lifecycle hook script에 DEPLOYMENT_GROUP_NAME을 자동으로 노출하기 때문입니다. 단일 script가 deployment group name(dev/staging/prod)을 원하는 Nginx log level(DEBUG/INFO/WARN)에 매핑하고, Nginx configuration(또는 templated include file)을 업데이트한 뒤 Nginx를 reload할 수 있습니다. 이는 group별로 별도 revision이나 다른 script를 유지하지 않으면서도 CodeDeploy의 native context에 의존해 관리 오버헤드를 최소화한다는 요구 사항을 충족합니다. 주요 AWS 기능 / Best Practice: - CodeDeploy lifecycle hook(예: BeforeInstall, AfterInstall, ApplicationStart, ValidateService)을 사용하면 배포 과정의 제어된 시점에 script를 실행할 수 있습니다. - CodeDeploy environment variable(DEPLOYMENT_GROUP_NAME 포함)은 외부 조회 없이 deployment context를 제공합니다. - Nginx의 경우 configuration을 변경한 뒤 graceful reload(예: nginx -s reload 또는 systemctl reload nginx)하여 연결을 끊지 않고 변경 사항이 적용되도록 하는 것이 best practice입니다. - deployment group name을 selector로 사용하면 configuration을 중앙화할 수 있고 EC2 tag, instance metadata, 추가 IAM permission에 대한 결합을 피할 수 있습니다. 흔한 오해: - “현재 위치”를 파악하기 위해 EC2 tag나 CodeDeploy API를 조회해야 한다고 생각하기 쉽지만, CodeDeploy는 이미 deployment group name을 script에 제공합니다. - ValidateService 같은 더 늦은 hook이 더 안전해 보일 수 있지만, configuration은 일반적으로 service가 start/restart되기 전에 적용되어야 실행 중인 process가 의도한 설정을 사용합니다. 시험 팁: - CodeDeploy가 hook script에 유용한 environment variable을 제공한다는 점을 기억하고, custom discovery mechanism보다 이를 우선하세요. - moving part를 최소화하세요: CodeDeploy context만으로 문제가 해결되는데 EC2 API 호출, instance metadata parsing, 추가 IAM permission을 더하지 마세요. - configuration이 반드시 존재해야 하는 시점에 맞는 lifecycle hook을 선택하세요(대개 service start/reload 이전의 BeforeInstall/AfterInstall).

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(6)

다른 모의고사

Practice Test #2

지금 학습 시작하기