정답 · 해설

해설

【핵심 용어】 ▸ AWS CodeBuild — Jenkins 대체 가능한 관리형 빌드 서비스 ▸ 아티팩트 암호화 — CodeBuild 기본 기능 (KMS 지원) ▸ 패치 관리 불필요 — AWS 완전 관리형 서비스 【정답 포인트】 ▸ CodeBuild = Jenkins 대체 → EC2 패치 관리 제거 ▸ 기본 아티팩트 암호화 지원 → 준법 요구사항 만족 ▸ 관리형 서비스 → 유지보수 최소화 ▸ 가장 직접적이고 간단한 솔루션 【오답 체크】 (A) EBS 암호화는 아티팩트 암호화가 아님. EC2 패치 관리 여전히 필요 (B) ECS + Jenkins는 여전히 패치 관리 부담. S3 기본 암호화는 아티팩트 암호화와 다름 (C) CodePipeline + Secrets Manager는 아티팩트 암호화를 위한 표준 방식 아님. 복잡함 【시험 포인트】 CodeBuild는 Jenkins를 완전히 대체하며, 기본적으로 아티팩트 암호화를 지원합니다. EC2 관리 부담을 완전히 제거하면서 준법 요구사항을 만족하는 가장 우수한 솔루션입니다.

해설

【핵심 용어】 ▸ DeletionPolicy — CloudFormation 리소스 삭제 정책 ▸ 사용자 정의 리소스 (Custom Resource) — Lambda와 함께 사용하여 복잡한 삭제 로직 구현 ▸ S3 버킷 — 객체가 있으면 삭제 불가 【정답 포인트】 ▸ S3 버킷에 객체가 있으면 DeletionPolicy:Delete 실패 ▸ Lambda를 사용한 사용자 정의 리소스 필수 ▸ RequestType == Delete 감지 → 모든 객체 삭제 ▸ 그 후 버킷 자동 삭제 【오답 체크】 (A) DeletionPolicy:Delete는 버킷이 비어있어야만 작동. 객체가 있으면 실패 (C) 수동 삭제는 자동화되지 않음. 비효율적 (D) OpsWorks는 이 문제 해결에 불필요. 복잡도 증가 【시험 포인트】 CloudFormation에서 S3 버킷 삭제의 핵심은 버킷이 비어있어야 한다는 것입니다. 사용자 정의 리소스와 Lambda 함수를 통해 스택 삭제 시 자동으로 객체를 제거하고 버킷을 삭제할 수 있습니다.

해설

【핵심 용어】 ▸ Artifact Store — 각 리전별 CodePipeline 아티팩트 저장소 ▸ Cross-Region Replication — 자동 복제 메커니즘 ▸ cloudformation package — 템플릿을 각 리전용으로 패키징 【정답 포인트】 ▸ 각 리전의 CodePipeline에는 해당 리전의 Artifact Store 필요 ▸ CRR을 통해 eu-west-1의 아티팩트를 us-east-1로 복제 ▸ us-east-1 배포 작업 추가 → 복제된 아티팩트 사용 【오답 체크】 (A) 매개변수 재정의 불필요. 각 리전별 아티팩트 이미 생성됨 (B) 단독으로는 불충분. eu-west-1 파이프라인으로는 us-east-1 배포 불가 (D) CRR만으로는 배포 작업 추가 필요 【시험 포인트】 Cross-Region CodePipeline 배포의 핵심은 아티팩트 저장소가 각 리전별로 필요하다는 것입니다. CRR로 복제하고, 각 리전의 배포 작업을 추가해야 합니다.

해설

【핵심 용어】 ▸ OpsWorks 자동 치유 — 상태 확인 실패 시 인스턴스 교체 ▸ 수명 주기 이벤트 — 특정 시점에서 스크립트 실행 ▸ 메타데이터 동기화 — 인스턴스 재시작 시 S3에서 다시 로드 【정답 포인트】 ▸ OpsWorks 자동 치유 → 자동 재시작/재시작 ▸ 수명 주기 이벤트 (setup, configure 등) 활용 → 메타데이터 자동 검색 ▸ 통합된 솔루션 → 별도의 Lambda/SNS 불필요 【오답 체크】 (A) EC2 Auto Recovery는 상태 복구만 가능. S3 이벤트 알림은 수동 메타데이터 로드 필요 (C) Auto Recovery도 가능하지만 메타데이터 동기화 메커니즘 약함 (D) CloudFormation UserData는 초기 배포에만 작동. 재시작 후 메타데이터 동기화 안 됨 【시험 포인트】 OpsWorks의 수명 주기 이벤트는 인스턴스가 재시작될 때마다 스크립트를 자동 실행할 수 있어, 메타데이터 동기화를 완전히 자동화할 수 있습니다.

해설

【핵심 용어】 ▸ 속성 기반 액세스 제어 (ABAC) — 주체(사용자)와 리소스의 태그를 매칭 ▸ aws:PrincipalTag — 사용자의 속성(department)을 조건으로 사용 ▸ aws:ResourceTag — EC2 인스턴스의 department 태그 【정답 포인트】 ▸ IAM Identity Center의 department 속성 → 사용자의 ${path:enterprise.department} ▸ aws:PrincipalTag:department → 사용자의 department 값 ▸ EC2 인스턴스의 aws:ResourceTag:department와 매칭 ▸ 조건: "aws:PrincipalTag:department":"${aws:ResourceTag:department}" 【오답 체크】 (B) aws:SourceTag — 소스(IP, VPC)를 나타내며, 사용자 속성이 아님 (C) aws:PrincipalOrgID — 조직 ID 매칭. 부서별 세분화 불가 (D) aws:ResourceTag — 리소스 태그 자체. 조건 구성에 리소스만 사용 불가 【시험 포인트】 ABAC는 조직 구조의 사용자 속성을 IAM 조건 키로 변환합니다. aws:PrincipalTag는 IAM Identity Center의 사용자 속성을 읽어와 인스턴스 태그와 매칭할 수 있습니다. 이를 통해 동적인 액세스 제어가 가능합니다.

해설

【핵심 용어】 ▸ SCP (Service Control Policy) — 조직 전체에 적용되는 상위 정책 ▸ 권한 경계 — 개별 IAM 역할 또는 사용자에만 적용 ▸ 조건부 Deny → 관리자 제외 — NotPrincipal 사용 【정답 포인트】 ▸ SCP를 조직 루트에 적용 → 모든 계정에 강제 ▸ iam:*Role 작업 Deny 포함 ▸ 조건: Deny에 aws:PrincipalArn NotLike 추가 → 관리자 역할 제외 ▸ 어떤 계정의 사용자도 우회 불가 【오답 체크】 (B) SCP는 IAM 서비스에 직접 연결 불가. 조직 단위만 가능 (C) 권한 경계는 감사 대상 계정에만 적용. 다른 계정 사용자의 권한 제어 불가 (D) 권한 경계는 역할 자체에만 적용. 역할 수정 액세스를 제어하지 못함 【시험 포인트】 SCP는 조직 전체에 강제되는 상위 정책으로, 어떤 IAM 정책도 이를 우회할 수 없습니다. 크로스 계정 보안 정책에는 SCP가 필수입니다.

해설

【핵심 용어】 ▸ Elastic Beanstalk — 애플리케이션 배포 및 관리 자동화 ▸ Blue/Green 배포 — Beanstalk 기본 지원 ▸ A/B 테스트 — Traffic Splitting을 통해 지원 ▸ 자동 스케일링 & 로드 밸런싱 — 기본 제공 【정답 포인트】 ▸ Elastic Beanstalk = PaaS 솔루션 ▸ Blue/Green 배포 기본 제공 ▸ Traffic Splitting으로 A/B 테스트 가능 ▸ S3에 .zip 업로드 → 자동 배포 ▸ 관리 최소화 (가장 간단함) 【오답 체크】 (A) EC2 + AMI + ASG는 Blue/Green을 수동으로 구현 필요. 복잡함 (B) Lightsail은 Blue/Green/A/B 테스트 기능 제한적 (C) CodeDeploy는 기본 Blue/Green 지원하지만 Elastic Beanstalk보다 복잡. CodeArtifact는 artifact repository이지 배포 도구가 아님 【시험 포인트】 Elastic Beanstalk은 배포 전략(Blue/Green, Rolling, Canary, Immutable)을 기본으로 제공하며, Traffic Splitting으로 A/B 테스트를 지원합니다. 관리 부담이 가장 적습니다.

해설

【핵심 용어】 ▸ 수명 주기 후크 — Terminating:Wait 상태로 인스턴스 유보 ▸ EventBridge — EC2 수명 주기 이벤트 감지 ▸ Lambda + SSM Run Command — 인스턴스에서 로그 수집 실행 ▸ complete-lifecycle-action — 수명 주기 완료 【정답 포인트】 ▸ Terminating:Wait → 종료 전 대기 ▸ EventBridge는 EC2 수명 주기 이벤트 감지 (가장 적합) ▸ Lambda에서 SSM Run Command로 원격 명령 실행 ▸ 로그 수집 완료 후 수명 주기 작업 완료 【오답 체크】 (A) Pending:Wait는 시작 대기이지, 종료 대기가 아님. CloudWatch 알람은 실시간 감지 어려움 (B) AWS Config는 수명 주기 이벤트 감지 안 함 (C) CloudWatch 구독 필터는 로그 스트림 기반이지, 수명 주기 이벤트 아님 【시험 포인트】 Auto Scaling 수명 주기 후크와 EventBridge 통합은 종료 전 컨텍스트(인스턴스 접근 가능, 환경 보존)에서 로그를 수집하는 표준 패턴입니다.

해설

【핵심 용어】 ▸ 크로스 계정 AssumeRole — 다른 계정의 역할 가정 ▸ 신뢰 관계 — 특정 주체가 역할을 가정하도록 허용 ▸ IAM 사용자 그룹 — 사용자를 관리하고 정책을 그룹에 적용 【정답 포인트】 (B) 각 워크로드 계정에 SysAdmin 역할 생성 + 운영 계정 신뢰 (D) 운영 계정에 IAM 사용자 생성 (사용자 중앙관리) (E) 사용자들을 SysAdmins 그룹에 추가 + AssumeRole 정책 → 모든 워크로드 계정 역할 가정 가능 ▸ 프로세스: 운영 팀 사용자 → SysAdmins 그룹 → sts:AssumeRole → 워크로드 계정 SysAdmin 역할 【오답 체크】 (A) 운영 계정의 SysAdmin 역할에 관리자 액세스는 워크로드 계정 액세스 불가 (C) Cognito 자격 증명 풀은 페더레이션이지, 크로스 계정 액세스가 아님 (F) Cognito 사용자 풀은 사용자 인증이지, AWS 계정 액세스와 무관 【시험 포인트】 AWS Organizations에서 중앙 사용자 관리는 운영 계정의 IAM 사용자 + 크로스 계정 AssumeRole 패턴입니다. 각 워크로드 계정은 수신 역할을 설정하고, 운영 계정 사용자는 그 역할을 가정합니다.

해설

【핵심 용어】 ▸ AWS Config — 리소스 준수 상태 추적 ▸ 준수 팩 (Conformance Pack) — 여러 Config 규칙과 자동 개선 번들 ▸ s3-bucket-level-public-access-prohibited — S3 Public Access Block 상태 확인 규칙 ▸ Systems Manager 문서 — Config 비준수 시 자동 작업 실행 【정답 포인트】 ▸ AWS Config는 S3 Public Access 설정을 지속적으로 모니터링 ▸ 준수 팩으로 조직 전체에 자동 배포 가능 ▸ Config 규칙이 비준수를 감지 → Systems Manager 문서 실행 ▸ Systems Manager 문서가 SNS 알림 발행 ▸ 멤버 계정에서 Config를 비활성화할 수 없음 (중앙 관리) 【오답 체크】 (A) GuardDuty는 S3 Public Access Block을 모니터링하지 않음. 보안 위협 감지용 (B) StackSets 배포는 멤버 계정에서 삭제 가능 (중앙 제어 불충분) (D) Amazon Inspector는 네트워크 노출만 감지. Public Access Block 설정 변경을 감지하지 못함 【시험 포인트】 AWS Config는 리소스 상태 추적과 자동 개선을 위한 표준 솔루션입니다. 준수 팩은 조직의 멤버 계정에서 삭제할 수 없는 중앙집중식 정책으로 작동합니다.

해설

【핵심 용어】 ▸ CloudWatch 로그 구독 필터 (Subscription Filter) — 로그 스트림에서 특정 패턴 감지 ▸ Lambda 구독 피드 대상 — 일치하는 로그를 Lambda로 실시간 전달 ▸ EKS CloudWatch Logs — API 서버, 컨트롤러 등의 로그 【정답 포인트】 ▸ CloudWatch Logs는 EKS 컨트롤 플레인 로그의 표준 저장소 ▸ 구독 필터로 각 컴포넌트별 로그 이벤트 캡처 ▸ Lambda가 실시간으로 로그 이벤트 수신 → SNS 주제 결정 → 발행 ▸ 메시지 기반, 실시간 처리 【오답 체크】 (B) CloudWatch Logs Insights는 쿼리 도구이지, 이벤트 스트림 아님 (C) EKS는 S3 로깅을 직접 지원하지 않음. 로그는 CloudWatch Logs를 통함 (D) S3 PUT Object 이벤트는 EKS 로그에 맞지 않음 【시험 포인트】 EKS 로그의 실시간 처리는 CloudWatch Logs 구독 필터 + Lambda 패턴입니다. 각 로그 이벤트에 대해 Lambda 함수가 호출되므로, 이벤트 기반 처리에 최적화되어 있습니다.

해설

【핵심 용어】 ▸ awslogs 드라이버 — ECS 작업에서 CloudWatch Logs로 로그 전송 ▸ ALB 액세스 로깅 — HTTP 요청 로그를 S3로 저장 ▸ Kinesis Firehose 구독 필터 — CloudWatch Logs를 Firehose로 자동 스트리밍 → S3 저장 【정답 포인트】 (B) ECS 작업의 애플리케이션 로그 → CloudWatch Logs (awslogs 드라이버) (D) ALB의 액세스 로깅 → S3에 직접 저장 (F) CloudWatch Logs → Firehose → S3 (근실시간 배치 저장) ▸ 애플리케이션 로그 + ALB 액세스 로그 모두 수집 완료 ▸ 근실시간 분석용 S3 저장소 【오답 체크】 (A) CloudWatch Logs 컨테이너 인스턴스는 표준 방식 아님 (C) create-export-task는 시간이 걸리며 지연 발생. 근실시간이 아님 (E) 대상 그룹은 액세스 로깅 미지원 【시험 포인트】 ECS 로그 수집의 표준 패턴: ECS → CloudWatch Logs (awslogs) + ALB → S3 (직접) + Firehose (근실시간 스트리밍).

해설

【핵심 용어】 ▸ Systems Manager Patch Manager — AWS 관리형 패치 배포 서비스 ▸ Patch Baseline — 사용자 정의 리포지토리를 포함할 수 있는 패치 정책 ▸ AWS-RunPatchBaseline — 패치 기준선을 실행하는 문서 【정답 포인트】 ▸ Patch Manager는 기본 + 사용자 정의 리포지토리 모두 지원 ▸ 사용자 정의 패치 기준선에서 사용자 정의 리포지토리 추가 ▸ AWS-RunPatchBaseline 문서로 패치 검증 및 설치 자동화 ▸ Systems Manager Maintenance Windows와 통합 가능 【오답 체크】 (B) AWS Direct Connect는 네트워크 연결 서비스. 패치 배포와 무관. CloudWatch는 패치 배포 도구 아님 (C) yum-config-manager는 수동 구성. 대규모 자동화에 부적합. 준법 요구사항 추적 불가 (D) AWS-AmazonLinuxDefaultPatchBaseline은 기본값만 사용. 사용자 정의 리포지토리 통합 불가 【시험 포인트】 Systems Manager Patch Manager는 대규모 패치 관리의 표준 솔루션입니다. 사용자 정의 리포지토리 지원 + 자동 기준선 생성 + 준법 추적이 모두 가능합니다.

해설

【핵심 용어】 ▸ CodeDeploy AppSpec 후크 (Hooks) — Blue/Green 배포 중 특정 라이프사이클 이벤트에서 검증 스크립트 실행 ▸ AfterAllowTestTraffic — Green 버전이 테스트 트래픽을 받은 후, 트래픽을 모두 이동하기 전 검증 ▸ 자동 롤백 — Lambda 함수 실패 → 배포 자동 롤백 【정답 포인트】 ▸ AppSpec 후크는 Blue/Green 배포 라이프사이클에 통합됨 ▸ AfterAllowTestTraffic에서 실행 → Green 버전이 실제 인스턴스에서 실행 중 ▸ Lambda 함수 오류 → CodeDeploy가 자동으로 롤백 ▸ 별도의 stop-deployment 명령 불필요 【오답 체크】 (A) CodeBuild는 빌드 단계용. Blue/Green 배포 후 테스트에는 부적합 (B) CodePipeline 단계에서의 테스트는 배포 전. Green 버전이 실행되지 않음 (D) AfterAllowTraffic은 이미 트래픽이 이동된 후. 테스트 목적이 아님. 테스트 후 롤백이 안 됨 【시험 포인트】 CodeDeploy AppSpec 후크는 Blue/Green 배포의 검증 지점입니다. AfterAllowTestTraffic → 트래픽 이동 → AllowTraffic → 최종 트래픽 이동. 후크에서의 실패는 자동 롤백을 보장합니다.

해설

【핵심 용어】 ▸ Storage Gateway 파일 게이트웨이 — S3를 NFS/SMB 파일 시스템으로 제공 ▸ 캐시 동기화 문제 — S3에 직접 쓴 객체는 게이트웨이 캐시에 반영 안 됨 ▸ RefreshCache — 게이트웨이 캐시를 S3와 동기화 【정답 포인트】 ▸ 파일 게이트웨이는 로컬 캐시를 유지함 ▸ S3에 직접 쓴 객체는 캐시에 없음 ▸ EventBridge 예약 이벤트로 매일 RefreshCache 실행 ▸ 아침 업무 시작 전에 캐시 새로 고침 【오답 체크】 (B) AWS Transfer for SFTP로 변경해도 S3 직접 쓰기 문제 해결 안 됨 (C) 볼륨 게이트웨이는 블록 저장소. 파일 공유 용도가 아님 (D) S3 Same-Region Replication은 리전 간 복제용. 같은 리전에서는 동작 안 함 【시험 포인트】 Storage Gateway 파일 게이트웨이의 캐시 동기화 문제는 RefreshCache로 해결합니다. S3에 직접 쓰는 외부 프로세스가 있을 때는 주기적인 캐시 새로 고침이 필수입니다.

해설

【핵심 용어】 ▸ 크로스 리전 + 크로스 계정 복제 — 소스 계정의 역할 필요 ▸ 복제 규칙 — 소스 버킷에서만 정의 ▸ 버킷 정책 — 소스에서 대상으로 PutObject 권한 필요 【정답 포인트】 (A) 소스 계정에 복제 IAM 역할 생성 (s3:GetObject*, s3:ListBucket 권한) (D) 대상 버킷 정책에 소스 역할의 PutObject 권한 명시 (크로스 계정) (E) 소스 버킷에 복제 규칙 생성 (대상 버킷 ARN, 역할 ARN 지정) ▸ 프로세스: 소스 역할 → 복제 규칙 → 대상 버킷의 정책으로 PutObject 확인 【오답 체크】 (B) 대상 계정 역할 생성 불필요. 소스 역할이 대상 계정에 접근 (C) 소스 버킷 정책이 아니라 대상 버킷 정책 필요 (F) 복제 규칙은 소스에서만 정의. 대상에서는 정의 안 함 【시험 포인트】 S3 크로스 계정 복제의 핵심: (1) 소스 계정 역할, (2) 대상 버킷 정책, (3) 소스 버킷 복제 규칙. 역할은 소스에서만 생성되고, 대상 정책은 해당 역할에 PutObject 권한을 명시합니다.

해설

【핵심 용어】 ▸ 크로스 계정 AssumeRole — 관리 계정의 Lambda가 멤버 계정 역할 가정 ▸ 신뢰 관계 — AssumeRole 권한 설정 ▸ ReadOnly 정책 — EC2 리소스 읽기만 가능 【정답 포인트】 (B) 각 멤버 계정에 역할 생성 + 관리 계정의 신뢰 관계 설정 (C) 멤버 계정 역할에 AmazonEC2ReadOnlyAccess 연결 (E) 관리 계정에 역할 생성 + 멤버 계정 역할 AssumeRole 권한 ▸ 프로세스: 관리 계정 Lambda → 멤버 계정 역할 AssumeRole → EC2 정보 조회 【오답 체크】 (A) 역방향 신뢰 (멤버 → 관리). 요구사항 반대 (D) 멤버 계정에서 관리 계정으로 AssumeRole. 데이터 조회 불가 (F) 관리 계정 역할에 EC2ReadOnly 권한은 멤버 계정 EC2 조회 불가 (크로스 계정 권한 아님) 【시험 포인트】 Cross-Account 리소스 조회의 표준 패턴: (1) 대상 계정 역할 생성 + 권한 부여, (2) 소스 계정에서 해당 역할 AssumeRole. 관리 계정 Lambda가 멤버 계정의 EC2를 조회하려면 멤버 계정 역할을 가정해야 합니다.

해설

【핵심 용어】 ▸ SQS Dead-Letter Queue (DLQ) — 처리 실패한 메시지를 자동 이동 ▸ Redrive Policy — Maximum Receives 설정 후 DLQ로 이동 ▸ 자동 격리 — 개발자 개입 없이 실패 메시지 관리 【정답 포인트】 ▸ 애플리케이션이 메시지 처리 실패 → 재시도 ▸ Maximum Receives = 1 설정 → 1회 실패 후 DLQ로 이동 ▸ DLQ에서 과학자가 데이터 검토 가능 ▸ 수정 후 재처리 (별도 프로세스) ▸ 자동화되고 간단함 【오답 체크】 (A) 수정된 메시지로 기존 큐 메시지 수정 불가 (메시지 ID 변경 필요) (B) FIFO는 필수 요구사항 아님. 시간 기반 필터도 복잡 (D) 가상 큐 개념은 SQS에 없음. 별도 큐 생성하려면 관리 부담 증가 【시험 포인트】 SQS DLQ는 메시지 처리 실패의 표준 패턴입니다. 특정 횟수의 재시도 실패 후 자동으로 DLQ로 이동되어, 장애 격리와 검토를 간단하게 만듭니다.

해설

【핵심 용어】 ▸ CloudFormation StackSets — 여러 계정/리전에 스택 배포 ▸ AWS Service Catalog — 조직의 승인된 제품 포트폴리오 관리 ▸ 정책 준수 — 회사 표준 강제 【정답 포인트】 ▸ Service Catalog는 승인된 템플릿만 제공 → 개발자가 정책 준수 리소스만 배포 가능 ▸ 복수 버전 관리, 태깅, 리전 제한이 모두 템플릿 수준에서 제어됨 ▸ 사용자 편의성과 거버넌스의 균형 = 회사 정책 자동 적용 【오답 체크】 (A) Trusted Advisor: 사후 분석 도구, 사전 제어 불가 (B) 드리프트 감지: 배포 후 검사만 가능, 정책 시행 불가 (C) StackSets: 템플릿 통제 없음, 개발자가 부적절한 설정 가능 【시험 포인트】 거버넌스 + 배포 자동화 → Service Catalog가 정답 패턴. 승인되지 않은 리소스 배포 방지 = 사전 제어 메커니즘 필요

해설

【핵심 용어】 ▸ 고가용성(HA) — 다중 AZ 분산, 무중단 서비스 ▸ NAT 게이트웨이(per-AZ) — AZ별 독립적 아웃바운드 경로 ▸ ALB — 트래픽 분산, 장애 인스턴스 자동 배제 【정답 포인트】 ▸ (B) ALB + 다중 AZ EC2: 웹 계층 HA 달성, 수평 확장 가능 ▸ (D) 각 AZ마다 NAT GW: NAT 가용성 확보 (1개 NAT GW 장애 = 해당 AZ만 영향) ▸ E는 오류 — NAT GW는 AZ별 생성 필수, "span" 불가 【오답 체크】 (A) NAT Auto Scaling: NAT는 상태 저장, Auto Scaling 부적절 (C) CloudWatch 복구: Single point of failure 해결 안 함, 재부팅만 가능 (E) 다중 AZ NAT GW: 기술적 불가능, NAT는 반드시 AZ별 【시험 포인트】 HA 질문 → 다중 AZ + 적절한 서비스 조합 검증. NAT GW는 항상 "per-AZ" 개념