모의고사 1

AWS Config conformance pack은 bucket 암호화 설정을 평가하고 SNS로 알릴 수 있지만, S3 PutObject 호출을 실시간으로 차단하지는 못합니다. 주의: 이미 Config가 S3를 모니터링하고 있어 그럴듯하지만, 이 선택지는 예방이 아니라 탐지입니다.

s3:CreateBucket을 거부해도 object 업로드 암호화를 강제하지 못하며, 각 PutObject 요청을 평가하지도 않습니다. 주의: 가드레일 종류는 맞지만 S3 API action을 잘못 골랐습니다.

CloudTrail data event와 EventBridge, SNS 조합은 암호화되지 않은 PutObject를 나중에 알릴 수 있지만, 업로드 자체는 이미 성공한 뒤입니다. 주의: 감사 증거로는 유용하지만 규정 위반 시도를 차단하는 제어는 아닙니다.

AWS Health는 올바른 이벤트 소스지만, EventBridge에서 AWS-RestartEC2Instance를 직접 호출하면 이벤트가 도착하는 즉시 인스턴스가 재시작됩니다. 주의: 올바른 알림 소스와 런북을 사용하지만 maintenance-window 통제를 건너뜁니다.

Systems Manager 유지 관리 기간 이벤트는 예약된 EC2 사용 중지 또는 호스트 유지 관리 알림과 영향을 받는 인스턴스를 식별하지 않습니다. 주의: Window는 중요하지만 AWS infrastructure 유지 관리의 이벤트 소스가 아닙니다.

EC2 state-change 알림은 예약된 인스턴스 사용 중지나 호스트 유지 관리의 사전 신호가 아니므로 자동화가 너무 늦게 실행되거나 필요한 신호를 놓칠 수 있습니다. 주의: Lambda와 maintenance-window task 조합은 그럴듯하지만 트리거가 잘못된 control-plane 이벤트입니다.

AWS Config는 규정 준수를 평가하고 Resource Data Sync는 인벤토리 및 규정 준수 데이터를 집계합니다. 두 서비스 모두 스택 메타데이터가 바뀔 때 EC2 인스턴스에 TOML 파일을 배치하지 않습니다. 주의: 거버넌스 루프처럼 보이지만, 요구사항은 구성 배포와 제자리 재적용입니다.

cfn-init과 cfn-hup이라는 헬퍼 스크립트 선택은 맞지만, 파일을 시작 템플릿 데이터에 넣으면 cfn-hup이 실행 중인 인스턴스에서 감시할 CloudFormation 메타데이터가 생기지 않습니다. 주의: 헬퍼 스크립트 이름이 매력적이지만, 파일은 CloudFormation init 메타데이터에 있어야 합니다.

시작 템플릿의 내용은 향후 시작에 영향을 주며, SSM Resource Data Sync는 인스턴스에 구성 업데이트를 폴링하고 적용하는 기능이 아닙니다. 주의: IaC와 SSM 기능을 결합하지만, 이 SSM 기능은 데이터를 밖으로 보고하는 용도이지 파일을 안으로 푸시하는 용도가 아닙니다.

aws:VpcSourceIp가 CIDR 안에 있는지만 확인하고 private IPv4 address를 VPC ID와 비교하므로 자격 증명을 정확한 인스턴스에 바인딩할 수 없습니다. 주의: Shared VPC CIDR은 관련 있어 보이지만 CIDR 안의 다른 호스트에서도 replay가 가능해집니다.

VPC ID와 private IP의 정적 allow list는 자격 증명을 받은 인스턴스가 실제로 사용 중임을 증명하지 못하며, 계정별 적용은 OU-level 요구사항을 놓칩니다. 주의: Allow list는 넓은 네트워크 위치를 제한할 수 있지만 동적인 credential-to-instance binding은 만들지 못합니다.

VPC ID를 IP address와, IP address를 VPC ID와 비교하도록 뒤집었고 정책도 OU가 아니라 계정별로 적용합니다. 주의: 올바른 조건 키를 언급하지만 키 pairing과 거버넌스 범위가 잘못되었습니다.

S3는 리포지토리 객체나 archive를 저장할 수 있지만, 개발자가 push 및 pull할 수 있는 일반 Git remote가 아닙니다. 주의: 백업처럼 보이지만 요구사항은 사용 가능한 Git 엔드포인트를 통한 엔지니어링 연속성입니다.

Code아티팩트는 패키지를 배포하는 서비스가지 브랜치, refs, tags, push/pull 흐름이 있는 Git 리포지토리가 아닙니다. 주의: 소스를 패키징하면 소비자에게는 도움이 될 수 있지만 개발자를 위한 리포지토리 미러링을 보존하지 못합니다.

Cloud9은 개발 환경이며 모든 개발자를 위한 보조 CodeCommit 미러링을 자동으로 유지하지 않습니다. 주의: 장애 중 작업할 장소를 제공할 수는 있지만 작업 흐름이 바뀌고 복제 문제가 남습니다.

ALB가 퍼블릭 IPv6 엔드포인트라면 모든 프라이빗 인스턴스에 IPv6 address를 할당할 필요가 없으며, 필수인 dualstack ALB front end도 정의하지 않습니다. 주의: End-to-end IPv6가 철저해 보이지만 시나리오는 서비스에 대한 IPv6 클라이언트 ingress만 요구합니다.

IPv6 Elastic IP는 여기서 EC2 노출 메커니즘이 아니며, 인스턴스에 퍼블릭 address를 할당하면 private-instance 요구사항을 위반합니다. 주의: ALB 리스너는 포함하지만 잘못된 계층을 노출합니다.

ALB를 NLB로 교체할 필요가 없고, 선택지는 표준 솔루션이 아닌 IPv6 Elastic IP 개념에 의존합니다. 주의: NLB도 dualstack일 수 있지만 기존 ALB가 필요한 HTTPS ingress 패턴을 이미 지원합니다.

GuardDuty는 유용하지만 S3, Athena, QuickSight 조사 대시보드를 구축하면 문제에서 피하려는 원시 로그 관리 오버헤드가 생깁니다. 주의: 올바른 탐지 서비스는 포함하지만 분석 계층이 사용자 지정이고 운영이 더 느립니다.

Container Insights는 리소스와 성능 텔레메트리를 모니터링합니다. 관리형 위협 탐지나 악성 활동 조사를 제공하지 않습니다. 주의: EKS 관측성에는 관련이 있지만 요구사항은 보안 조사입니다.

GuardDuty, Container Insights, VPC Flow Logs, CloudTrail은 유용한 신호를 수집하지만, 이 선택지에는 Detective나 다른 요약 조사 계층이 없습니다. 주의: 여러 데이터 원본을 나열하지만 핵심 요구사항은 로그 관리 오버헤드가 낮은 단일 관리형 보기입니다.

IAM Identity Center는 workforce 액세스와 SSO 권한 할당을 위한 서비스가지, 워크로드가 OIDC ID token을 DynamoDB 자격 증명으로 교환하기 위한 서비스가 아닙니다. 주의: 외부 IdP를 언급하지만 이 포털의 pod-to-AWS API federation 문제를 해결하지 못합니다.

IAM 역할 신뢰 정책에서 OIDC provider claim에 대한 audience 조건 키는 sts:aud가 아니라 provider-specific key입니다. 주의: 역할 권한 범위는 올바르게 제한하지만 trust-policy 조건 키가 잘못되었습니다.

GetFederationToken은 포털의 외부 OIDC token을 받는 web identity federation API가 아닙니다. 주의: Temporary 자격 증명을 반환하기는 하지만 OIDC token 교환에는 잘못된 STS operation입니다.

서비스 및 Region 제한을 강제하는 Organization 그룹 정책은 없으며, StackSets만으로는 예방적 가드레일을 제공하지 못합니다. 주의: 역할 배포에 StackSets를 포함하지만 governance 제어가 잘못되었습니다.

Permissions 경계는 IAM 보안 주체가나 역할을 제한하지만 모든 계정을 특정 AWS Region과 서비스로 중앙 제한하지는 않습니다. 주의: Boundary는 delegation ceiling에는 유용하지만 Organization 전체 서비스 allowlist에는 맞지 않습니다.

SCP는 가드레일에 맞지만 AWS RAM은 설명된 것처럼 workforce가 멤버 계정에서 수임할 IAM 역할을 공유할 수 없습니다. 주의: IAM Identity Center와 RAM은 중앙화된 것처럼 보이지만, 문제는 동일한 account-local 작업 역할을 요구합니다.