연습 문제

문제 1

한 회사는 2개의 AWS Region에 걸쳐 Auto-Tune이 활성화된 Amazon OpenSearch Service domain 10개를 운영하고 있으며, 지난 24시간 동안의 모든 Auto-Tune 작업(예: 메모리 또는 shard rebalancing 조정)을 1분 해상도로 Amazon CloudWatch dashboard에서 시각화해야 합니다. 어떤 솔루션이 이 요구 사항을 충족합니까?

문제 2

(2개 선택)

한 물류 기업이 두 개의 AWS Regions에 걸쳐 68개의 멤버 계정을 보유한 멀티-OU AWS Organizations 구성을 운영하고 있으며, 별도의 결제를 사용하는 11개의 독립형 AWS 계정을 사용하는 핀테크 스타트업을 인수했습니다. 플랫폼 팀은 단일 management account 하에서 관리를 중앙화하는 동시에, 가져온 모든 계정 전반에서 비상용(break-glass) 전체 관리자 제어 권한을 유지해야 하며, 전체 환경 전반의 보안 탐지 결과를 중앙에서 집계 및 그룹화하고 신규 계정이 온보딩될 때 자동으로 포함되도록 해야 합니다. 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하기 위해 플랫폼 팀이 수행해야 할 작업 조합은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS Organizations 계정 온보딩과 중앙화된 보안 운영을 평가합니다. 구체적으로: (1) management account가 멤버 계정에 대해 비상용(break-glass) 관리자 액세스를 어떻게 유지하는지, (2) 조직 통합 보안 서비스를 사용하여 모든 계정의 보안 탐지 결과를 중앙에서 집계하고 신규 계정을 자동으로 포함하는 방법을 묻습니다. 정답이 맞는 이유: 관리를 중앙화하려면 스타트업의 독립형 계정을 기존 AWS Organization으로 초대해야 합니다. 비상용 전체 관리자 제어를 위해서는 management account가 AdministratorAccess로 Assume할 수 있는 cross-account role이 각 멤버 계정에 필요합니다. 대표적인 메커니즘은 management account를 신뢰하는 OrganizationAccountAccessRole(또는 동등한 admin role)이며, 이는 옵션 B가 설명하는 내용으로, Organizations에서 계정 생성/초대 이후 중앙 액세스를 활성화하는 방식과 일치합니다. 신규 온보딩 계정의 자동 포함과 함께 전체 계정에 대한 보안 탐지 결과를 중앙에서 집계 및 그룹화하려면 AWS Security Hub가 올바른 서비스입니다. AWS Organizations와 통합하면 Security Hub는 delegated administrator, 멀티-account/멀티-Region 집계, 신규 organization accounts의 자동 등록을 지원하여 지속적인 운영 오버헤드를 최소화합니다(옵션 C). 주요 AWS 기능: - AWS Organizations: 계정 초대 및 통합 거버넌스. - Cross-account IAM role (OrganizationAccountAccessRole): management account를 신뢰하며, 비상용 액세스를 위해 AdministratorAccess를 부여. - AWS Security Hub + Organizations: delegated admin, 조직 전체 활성화, 자동 계정 등록, 계정/Regions 전반의 중앙 탐지 결과 집계. - 모범 사례: 일상 운영에서 management account를 사용하지 않도록 보안 도구에 delegated administrator를 사용. 흔한 오해: - SCP는 권한을 “부여”하지 않으며, 허용 가능한 권한의 가드레일(최대 허용치)만 설정합니다. 따라서 SCP만으로 management account에 대한 break-glass admin access를 만들 수 없습니다. - Firewall Manager는 중앙화된 방화벽 정책 관리(AWS WAF, Shield Advanced, security groups 등)를 위한 서비스이지, 일반적인 보안 탐지 결과 집계 서비스가 아닙니다. - Amazon Inspector는 취약점 탐지 결과를 생성하지만, 요구된 것처럼 광범위한 cross-service 탐지 결과 집계 계층은 아닙니다. 시험 팁: - 기억할 점: IAM policies는 권한을 부여하고, SCP는 권한을 제한합니다. - 자동 등록을 포함한 조직 전체 보안 탐지 결과 집계는 “Security Hub + Organizations + delegated admin”을 떠올리세요. - 멤버 계정에 대한 중앙 관리자 액세스는 “멤버 계정으로 Assume role” 패턴(OrganizationAccountAccessRole 또는 동등)을 찾으세요.

문제 3

한 DevOps 엔지니어가 AWS Lambda 함수가 Amazon Kinesis Data Streams shard에서 배치된 레코드를 읽고 VPC를 통해 내부 ERP SOAP endpoint로 전달하는 데이터 포워딩 서비스를 구축하고 있습니다. 대략 12%의 수신 레코드는 검증에 실패하며 수동으로 처리되어야 합니다. Lambda event source mapping은 실패 시 destination으로 Amazon SQS dead-letter queue(DLQ)로 구성되어 있고, 함수는 재시도가 활성화된 배치 처리를 사용합니다. 부하 테스트 중 엔지니어는 DLQ에 데이터 문제가 없고 이미 ERP 서비스에서 수락된 레코드가 많이 포함되어 있음을 관찰했습니다. 이는 부분적으로 실패한 배치에서 성공한 항목들이 재시도되고, 결국 실패 항목들과 함께 DLQ로 전송되고 있음을 나타냅니다. 현재 처리량과 재시도 동작을 유지하면서 DLQ로 전송되는 오류 없는 레코드 수를 줄이기 위해 엔지니어가 구현해야 할 event source 구성 변경은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon Kinesis Data Streams에 대한 AWS Lambda event source mapping, 특히 부분 실패와 실패 시 destination(DLQ)에서 배치 재시도 의미론이 어떻게 상호작용하는지를 테스트합니다. Kinesis에서 Lambda는 shard로부터 배치를 읽으며, 기본적으로 배치를 성공/실패에 대한 원자적 단위로 취급합니다. 정답이 맞는 이유: Kinesis 배치에서 어떤 레코드든 Lambda invocation이 실패하도록 만들면(예: 검증 실패로 예외 발생), 전체 배치가 재시도됩니다. 즉, ERP endpoint로 이미 성공적으로 전달된 레코드도 다시 처리될 수 있으며, 중복을 유발할 수 있고 재시도가 소진된 후에는 실제로 나쁜 레코드와 함께 DLQ로 전송될 수 있습니다. “bisect batch on function error”(split/bisect)를 활성화하면 오류 발생 시 Lambda가 배치를 자동으로 더 작은 배치로 분할(이진 탐색)하여 재시도하도록 재시도 동작이 변경됩니다. 이는 문제 레코드를 가장 작은 실패 배치로 격리하여, 재시도되거나 최종적으로 DLQ로 전송되는 정상 레코드 수를 크게 줄이면서도 동일한 전체 처리량 목표를 유지하고 기존 재시도 메커니즘을 보존합니다. 주요 AWS 기능: - Event source mapping 설정: Kinesis/DynamoDB Streams용 BisectBatchOnFunctionError. - Event source mapping의 실패 시 destination(SQS DLQ): 레코드가 만료되거나 재시도가 소진될 때 사용. - 배치 처리 동작: bisection이 없으면 단 하나의 불량 레코드가 전체 배치를 오염(poison)시킴. 이는 Well-Architected Reliability 원칙(영향 범위 제한 및 실패 격리)과 일치합니다. 흔한 오해: 일시적 문제를 “해결”하기 위해 재시도를 늘리는 것(A)은 중복 처리만 증가시키고 DLQ 노이즈를 악화시킬 수 있습니다. parallelization(C)을 늘리면 처리량은 개선되지만 배치의 원자성은 바뀌지 않으며, 오히려 중복을 증폭시킬 수 있습니다. 최대 레코드 수명(D)을 줄이면 더 많은 레코드가 더 빨리 DLQ로 밀려나, 실패 격리보다는 손실/노이즈가 증가할 수 있습니다. 시험 팁: Kinesis/DynamoDB Streams + Lambda에서는, bisection을 활성화하거나(또는 지원되는 경우 partial batch response를 구현하지 않는 한) 배치가 재시도의 단위라는 점을 기억하세요. 증상이 “한 레코드가 실패해서 정상 레코드가 DLQ로 간다”라면, 재시도나 동시성 튜닝보다 BisectBatchOnFunctionError(또는 partial batch response)를 먼저 떠올리세요.

문제 4

한 글로벌 미디어 회사는 두 개의 OU(루트 및 analytics)로 AWS Organizations를 사용합니다. 루트 OU에는 모든 리소스에 대한 모든 작업을 허용하는 단 하나의 Allow 문이 포함된 단일 SCP가 있습니다. 반면 analytics OU(계정 4개 포함, 그중 ext-ml 계정 ID 222222222222 포함)에는 s3:* 및 glue:만 허용하고, 모든 리소스에 대해 NotAction [s3:, glue:*]를 사용하는 Deny 문으로 그 외 모든 작업을 명시적으로 거부하는 SCP가 있습니다. ext-ml 계정에서 DevOps 엔지니어의 IAM 사용자에게 AdministratorAccess 정책이 연결되어 있으며, 엔지니어가 us-east-1에서 콘솔과 AWS CLI를 통해 Amazon RDS db.m6g.large 인스턴스(rds:CreateDBInstance)를 생성하려고 하면, 조직 service control policy에 의해 차단되었다는 AccessDeniedException과 함께 요청이 실패합니다. 어떤 변경을 하면 엔지니어가 ext-ml 계정에서 RDS 인스턴스를 성공적으로 생성할 수 있습니까?

문제 분석

핵심 개념 - 이 문제는 AWS Organizations Service Control Policies(SCP)가 IAM 권한과 무관하게 계정에서 사용할 수 있는 최대 권한을 설정하는 방식을 테스트합니다. SCP는 자체적으로 권한을 부여하지 않으며, 가드레일을 정의합니다. SCP의 명시적 Deny는 AdministratorAccess를 포함한 어떤 IAM 정책으로도 재정의할 수 없습니다. 정답이 맞는 이유 - ext-ml 계정은 analytics OU에 있으며, 이 OU에는 s3:* 및 glue:*만 허용하고 Deny with NotAction [s3:*, glue:*]를 사용해 그 외 모든 것을 명시적으로 거부하는 SCP가 있습니다. rds:CreateDBInstance는 NotAction 허용 목록에 포함되지 않으므로 Deny 문과 매칭되어 해당 OU의 모든 계정에 있는 모든 principal에 대해 명시적으로 거부됩니다. 따라서 엔지니어의 AdministratorAccess IAM 정책은 RDS 작업에 대해 의미가 없고, 요청은 Organizations 계층에서 차단됩니다. RDS 인스턴스 생성을 허용하려면 ext-ml 계정에 적용되는 유효 SCP를 변경하여 RDS 작업이 명시적으로 거부되지 않도록 해야 합니다. analytics OU SCP를 업데이트하여 NotAction 예외에 rds:*를 포함(또는 RDS에 대한 명시적 거부를 다른 방식으로 제거)하는 것이 직접적인 해결책입니다. 주요 AWS 기능 - SCP 평가는 “교집합 기반”입니다. 즉, 작업은 IAM에서 허용되어야 하고 SCP에 의해 차단되지 않아야 합니다. 명시적 Deny가 항상 우선합니다. OU 수준 SCP는 OU 내 모든 계정에 적용됩니다. 계정 수준 SCP는 추가 제약(더 많은 가드레일)일 뿐, 재정의가 아닙니다. 루트 OU SCP가 *를 허용하더라도 하위 OU의 명시적 Deny를 무효화하지 못합니다. 흔한 오해 - AmazonRDSFullAccess(또는 AdministratorAccess)를 연결하면 SCP 거부가 해결된다고 생각하는 실수가 흔합니다. 그렇지 않습니다. 또 다른 오해는 계정 또는 루트에 “allow RDS” SCP를 연결하면 OU의 Deny를 재정의할 수 있다는 것인데, 명시적 Deny가 계속 적용되므로 불가능합니다. 시험 팁 - “blocked by an organization service control policy”를 보면 즉시 SCP에서 명시적 Deny 또는 허용 목록(NotAction 패턴)을 확인하십시오. OU SCP가 Deny with NotAction을 사용한다면, 필요한 서비스 작업을 NotAction 목록에 추가(또는 SCP를 재설계)해야 하며, 또는 해당 작업이 허용되는 OU로 계정을 이동해야 합니다.

문제 5

(2개 선택)

한 미디어 스트리밍 스타트업은 모든 기능이 활성화된 AWS Organizations에서 멀티 계정 환경을 운영하고 있습니다. 운영(소스) 계정은 us-west-2에서 AWS Backup을 사용하여 120개의 Amazon EBS 볼륨을 보호하며, 고객 관리형 KMS 키(alias/ops-backup)로 복구 지점을 암호화합니다. DR 요구 사항을 충족하기 위해 회사는 관리 계정에서 교차 계정 복사를 구성하고, 새로 생성한 DR 계정에 dr-vault라는 이름의 백업 볼트와 고객 관리형 KMS 키(alias/dr-backup)를 생성한 다음, 운영 계정의 백업 플랜을 업데이트하여 모든 복구 지점을 DR 계정의 dr-vault로 복사하도록 설정했습니다. 운영 계정에서 백업 작업이 실행되면 운영 계정에서는 복구 지점이 성공적으로 생성되지만, DR 계정의 dr-vault에는 어떤 복사본도 나타나지 않습니다. AWS Backup이 복구 지점을 DR 계정의 볼트로 복사할 수 있도록 하는 단계 조합은 무엇입니까? (두 개 선택)

문제 분석

핵심 개념: 이 문제는 AWS Organizations 환경에서 AWS Backup 교차 계정 복사의 전제 조건, 특히 관련된 두 가지 권한 계층인 (1) 대상 백업 볼트 액세스 정책과 (2) 복사된 복구 지점을 암호화하기 위한 AWS KMS 키 정책을 테스트합니다. Organizations에서 “all features”가 활성화되어 있더라도, AWS Backup은 여전히 대상 볼트에 대한 명시적인 리소스 기반 권한과 대상 CMK를 사용할 수 있는 KMS 권한을 필요로 합니다. 정답이 맞는 이유: 교차 계정 복사를 위해서는 소스 계정의 AWS Backup이 DR 계정의 대상 볼트에 쓰기 권한을 가져야 합니다. 이 권한은 대상 백업 볼트(dr-vault)의 리소스 기반 정책으로 부여됩니다. 이 정책이 없으면 복사 작업이 거부되어 DR 볼트에 복구 지점이 나타나지 않습니다. 또한 대상 볼트는 고객 관리형 KMS 키(alias/dr-backup)로 복구 지점을 암호화하므로, AWS Backup 서비스(소스 계정을 대신하여 동작)가 암호화 작업(예: 서비스에 필요한 GenerateDataKey, Encrypt, Decrypt 등)을 위해 해당 키를 사용할 수 있도록 대상 CMK 키 정책에서 허용되어야 합니다. 키 정책이 이를 허용하지 않으면 AWS Backup은 DR 계정에서 복사된 복구 지점을 암호화할 수 없고 복사가 실패합니다. 주요 AWS 기능: - AWS Backup 교차 계정 복사는 소스 계정이 복사/쓰기 작업을 수행할 수 있도록 허용하는 대상 볼트 액세스 정책이 필요합니다. - AWS KMS CMK는 주로 키 정책(단순히 IAM이 아님)에 의해 제어됩니다. 교차 계정 사용은 키 정책에서 명시적으로 허용되어야 합니다. - 멀티 계정 DR 설계에서는 일반적으로 대상 계정이 볼트와 CMK를 소유하고, 소스 계정에는 해당 볼트로 복사할 수 있는 제한된 권한만 부여합니다. 일반적인 오해: 자주 하는 실수는 AWS Organizations에서 “all features”를 활성화하면 교차 계정 백업 복사가 자동으로 승인된다고 가정하는 것입니다. 그렇지 않으며, 볼트 정책과 KMS 키 정책은 여전히 구성해야 합니다. 또 다른 오해는 소스 CMK를 DR 계정과 공유해야 한다고 생각하는 것입니다. 복사 시 AWS Backup은 대상 CMK를 사용해 다시 암호화하므로, 핵심 권한은 대상 CMK에 있습니다. 시험 팁: “cross-account copy” + “customer managed KMS key”를 보면 즉시 두 가지 필수 권한을 확인하십시오: 대상 볼트 정책(리소스 기반)과 대상 KMS 키 정책. 복사본이 나타나지 않는다면, 대부분 소스 볼트 정책이 아니라 이 두 권한 중 하나(또는 둘 다)의 누락 때문입니다.

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

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

문제 6

글로벌 물류 회사가 3개 AWS Regions에 걸쳐 12,000대의 휴대용 스캐너에서 텔레메트리를 수집하고 있으며, 각 디바이스 유형은 Region별로 전용 Amazon CloudWatch Logs log group에 기록하여 총 약 90개의 log group이 있습니다. 지난 14일 동안 계획된 변경 사항이 없었음에도 CloudWatch Logs ingestion 요금이 68% 증가했습니다. DevOps 엔지니어는 remediation 우선순위를 정하기 위해 어떤 디바이스 유형 또는 Regions가 ingestion 급증을 유발하는지 신속하게 파악해야 합니다. 가장 운영 효율적인 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 Amazon CloudWatch Logs 수집 비용을 증가시키는 소스를 식별하는 가장 빠른 운영 방식이 무엇인지 찾는 것에 관한 것입니다. 이상적인 솔루션은 log group별 수집 볼륨을 직접 측정해야 합니다. 각 log group은 Region의 device type에 매핑되기 때문입니다. 실제로 CloudWatch Logs Insights는 스캔되거나 쿼리된 로그 콘텐츠 특성을 보고할 수 있고, Cost Explorer는 서비스 수준의 비용 추세를 보여줄 수 있으며, CloudTrail은 API 활동을 보여줄 수 있습니다. 그러나 이들 중 어느 것도 목적에 맞게 설계된 수집 metric만큼 특정 log group에 대한 수집 byte를 직접적이고 효율적으로 깔끔하게 귀속시키지는 못합니다. 정답인 이유: Option A가 최선의 정답인 이유는 지난 14일 동안 log group 전반의 수집 볼륨을 비교하고 상위 기여자를 시각화하기 위해 CloudWatch 고유 telemetry를 사용하는 데 초점을 맞추기 때문입니다. 이것이 빠른 triage를 위한 올바른 운영 패턴입니다. 로그를 스캔하거나 API 호출로부터 추론하는 대신 metrics를 사용합니다. 각 device type은 Region별 전용 log group에 기록하므로, log group의 순위를 매기면 증가를 유발하는 device type과 Region을 효과적으로 식별할 수 있습니다. 주요 AWS 기능: - CloudWatch metrics와 dashboards는 시간 경과에 따라 많은 리소스를 비교하는 데 가장 운영 효율적인 도구입니다. - Metric math는 여러 time series를 한곳에서 집계, 비교, 시각화하는 데 도움이 될 수 있습니다. - Cost Explorer는 청구 수준 추세에는 유용하지만, 이 시나리오에서 리소스 수준의 운영 귀속에는 적합하지 않습니다. - CloudTrail은 control-plane 및 data-plane API 활동을 캡처하지만, 비용 귀속에 필요한 실제 수집 볼륨은 캡처하지 않습니다. 흔한 오해: - Logs Insights는 로그 콘텐츠 분석에 매우 뛰어나지만, event 수를 세는 것은 수집 요금을 유발하는 수집된 byte를 측정하는 것과 같지 않습니다. - Cost Explorer는 CloudWatch 비용이 증가했다는 것은 보여줄 수 있지만, 일반적으로 정확히 어떤 log group이 원인인지까지는 특정할 수 없습니다. - PutLogEvents와 같은 CloudTrail event 수는 payload 크기가 다양하기 때문에 수집 볼륨과 신뢰성 있게 상관관계를 가지지 않습니다. 시험 팁: 시험에서 목표가 많은 리소스 전반의 사용량 급증에 대한 상위 기여자를 빠르게 식별하는 것이라면, ad hoc 쿼리나 청구 보고서보다 기본 제공 metrics와 dashboards를 우선적으로 선택하세요. 또한 event 수, API 수, byte 볼륨을 구분하세요. byte 볼륨만이 CloudWatch Logs 수집 요금에 직접적으로 매핑됩니다.

문제 7

DevOps 엔지니어가 us-east-2에서 두 개의 private subnet(10.20.1.0/24 및 10.20.2.0/24)에 걸쳐 public IP가 없는 Amazon EC2 인스턴스 8대로 구성된 Auto Scaling group을 배포한다. 새로운 FedRAMP High 통제로 인해 VPC에는 internet gateway 또는 NAT gateway가 없고 모든 internet egress가 금지되어 있으며, user data는 부팅 시 AWS CLI를 사용하여 s3://company-artifacts-prod/builds/2.7.4/app.tar.gz에서 아티팩트를 다운로드한다. 그러나 인스턴스는 상태 확인을 정상(healthy)으로 보고하지만 다운로드가 실패하여 애플리케이션이 설치되지 않는다. Internet egress 금지 요구 사항을 준수하면서 애플리케이션을 설치할 수 있는 조치는 무엇인가?

문제 분석

핵심 개념: 이 문제는 internet egress 없이 private subnet에서 AWS 서비스에 연결하는 방법과, 엄격한 컴플라이언스 통제(FedRAMP High)를 충족하면서 VPC endpoint를 사용해 VPC에서 Amazon S3에 접근하는 방법을 평가한다. 또한 최소 권한 액세스를 위한 IAM instance profile도 다룬다. 정답이 맞는 이유: 인스턴스는 internet gateway(IGW)와 NAT gateway가 없는 private subnet에 있으므로 인터넷을 통해 public S3 endpoint에 도달할 수 없다. 하지만 S3는 Gateway VPC Endpoint for S3를 사용하여 VPC 내부에서 private하게 접근할 수 있는 AWS 서비스이다. S3 gateway endpoint를 생성하고 private route table에 추가하면 public internet을 경유하지 않고 subnet에서 S3로 가는 private 경로가 제공되어 “no internet egress” 요구 사항을 충족한다. 또한 인스턴스가 객체를 읽을 수 있도록 권한이 필요하므로 bucket/prefix에 대해 s3:GetObject를 부여하는 IAM instance profile이 필요하다. 선택적으로 bucket policy에서 특정 VPC endpoint ID(aws:SourceVpce)로 접근을 제한하여 endpoint를 통해서만 접근하도록 강제할 수 있다. 주요 AWS 기능: - Gateway VPC Endpoint for S3: route table에 route(prefix list)를 추가하여 S3에 private하게 도달. - Route table 통합: 두 private subnet의 route table 모두에 연결되어야 함. - IAM instance profile: static credential 없이 EC2에서 AWS CLI가 S3를 호출할 수 있게 함. - Bucket policy 조건: VPC endpoint ID로 제한하여 endpoint 외 접근을 차단. 이는 AWS Well-Architected Security(네트워크 분리, 최소 권한) 및 컴플라이언스 요구 사항과 부합한다. 흔한 오해: 많은 사람이 S3가 public DNS name을 사용하므로 항상 internet 또는 NAT가 필요하다고 생각한다. S3 gateway endpoint를 사용하면 DNS는 정상적으로 resolve되지만 트래픽은 endpoint를 통해 private하게 라우팅된다. 또 다른 오해는 security group이 S3 접근을 “가능하게” 만든다는 것이다. security group은 route나 private connectivity를 생성하지 않는다. 시험 팁: “private subnet + IGW/NAT 없음 + S3 접근 필요”가 보이면 기본 정답은 “S3 Gateway VPC Endpoint + IAM role”이다. 다른 AWS 서비스(SSM, CloudWatch, ECR API)의 경우 일반적으로 Interface VPC Endpoint(PrivateLink)가 필요하다. 항상 네트워크 연결성과 IAM 권한을 함께 고려하고, 컴플라이언스를 위해 endpoint로 제한된 bucket policy도 검토하라.

문제 8

한 대학 컨소시엄은 2개 Region에 걸쳐 4개의 OU와 platform-ops라는 이름의 delegated administrator account로 AWS Organizations를 사용하고 있으며, research OU(58개 AWS account)는 us-east-1 또는 eu-west-1에서 어떤 AWS CloudFormation stack create 또는 update가 실행되기 전에 stack에 정의된 모든 Amazon EBS volume과 Amazon SQS queue에 KMS key alias alias/research-default를 사용한 server-side encryption이 활성화되어 있고, 이 제어가 해당 OU의 모든 account에 걸쳐 일관되게 강제되도록 보장해야 합니다. 이러한 account에서 CloudFormation stack 작업 전에 이 정책을 강제할 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 AWS CloudFormation을 사용하는 Infrastructure as Code(IaC)에 대한 예방적 guardrail을 테스트합니다. 구체적으로, 비준수 리소스가 절대 프로비저닝되지 않도록 CloudFormation stack create/update 전에 실행되는 제어가 필요합니다. 관련 기능은 CloudFormation Hooks(CloudFormation Guard/Hook framework의 일부)이며, StackSets를 통한 조직 단위 배포가 함께 사용됩니다. 정답이 맞는 이유: CloudFormation Hooks는 stack 작업(create/update) 중에 리소스 속성을 동기적으로 검증하고 정책을 위반하면 해당 작업을 실패시킬 수 있습니다. Hook은 AWS::EC2::Volume 및 AWS::SQS::Queue를 대상으로 encryption이 활성화되어 있는지, 그리고 KMS key 참조가 alias/research-default와 일치하는지를 강제할 수 있습니다. Hook을 research OU의 모든 account와 두 Region에 배포하면 us-east-1 및 eu-west-1의 58개 account 전반에서 일관된 강제가 보장됩니다. AWS Organizations의 CloudFormation StackSets trusted access를 사용하면 delegated administrator(platform-ops)에서 account별 수동 설정 없이 중앙집중적이고 확장 가능하게 배포할 수 있습니다. 주요 AWS 기능: - CloudFormation Hooks: 리소스가 요구사항을 충족하지 않으면 stack 작업을 차단할 수 있는 사전 프로비저닝(pre-provision) 검사. - trusted access가 활성화된 StackSets: OU 및 여러 Region에 걸쳐 Hook(및 필요한 IAM role/permission)을 배포. - delegated administrator: platform-ops가 조직 규모로 StackSets를 관리할 수 있도록 지원. 흔한 오해: SCP는 강력한 예방적 제어이지만 API authorization 계층에서 동작하며 CloudFormation 전용이 아닙니다. 또한 특정 alias 사용을 강제하는 것과 같은 속성 수준(property-level) 검증에는 취약할 수 있고, CloudFormation이 다른 API call을 사용하거나 기본값으로 encryption이 활성화되는 경우를 놓칠 수 있습니다. AWS Config는 탐지적(detective) 제어(배포 후)이며 “stack 실행 전”을 보장할 수 없습니다. Lambda 스캔 역시 반응적이며 race condition이 발생하기 쉽습니다. 시험 팁: 요구사항에 “어떤 CloudFormation stack create 또는 update가 실행되기 전에”라고 명시되면 AWS Config(탐지)나 Lambda remediation이 아니라 CloudFormation Hooks(예방)를 찾으십시오. 많은 account/Region에 걸친 조직 단위 일관성이 필요하면 StackSets 및 Organizations trusted access/delegated admin 패턴과 결합하십시오.

문제 9

한 telemedicine 회사의 실시간 상담 플랫폼은 일일 활성 사용자 수가 8,000명에서 7개 국가에 걸쳐 60,000명으로 증가했으며, 해당 microservices는 20분 피크 시간대 동안 최대 2,500개 노드까지 확장되는 Amazon Elastic Kubernetes Service (Amazon EKS)에서 실행되고 있습니다. 또한 보안 검토 결과 간헐적인 무단 sign-in 시도와 갑작스러운 session 종료가 확인되었습니다. 따라서 이 회사는 플랫폼 전반에 걸친 추가 보호와 함께, 모든 AWS accounts 전반에서 login attempts, API calls, network traffic를 보여주는 단일 요약 뷰를 요구하고, raw log 관리 오버헤드를 최소화하면서 network traffic 분석을 허용하며, EKS workload와 관련된 잠재적으로 악의적인 활동을 신속하게 조사할 수 있어야 합니다. 이러한 요구 사항을 가장 잘 충족하는 솔루션은 무엇입니까?

문제 분석

핵심 개념: 이 문제는 raw log 관리 오버헤드를 최소화하면서 EKS 기반 workload에 대해 accounts 전반의 AWS 위협 탐지 및 조사를 테스트합니다. 핵심 서비스는 Amazon GuardDuty(CloudTrail, VPC Flow Logs, DNS logs, EKS audit logs를 사용하는 managed threat detection)와 Amazon Detective(signals를 상관 분석하여 unified view로 제공하는 managed investigation)입니다. 정답인 이유: 이 회사는 (1) 플랫폼 전반의 추가 보호, (2) 모든 AWS accounts 전반에서 login attempts, API calls, network traffic를 보여주는 단일 요약 뷰, (3) raw log 관리를 최소화하면서 network traffic 분석, (4) EKS와 관련된 의심스러운 활동의 신속한 조사가 필요합니다. GuardDuty for EKS Audit Log Monitoring을 활성화하면 IAM/console sign-in anomalies, API calls(CloudTrail management events를 통해), network threats(VPC Flow Logs/DNS를 통해)에 대한 표준 탐지에 더해, 의심스러운 Kubernetes control-plane activity(예: anomalous kubectl exec, suspicious API calls, privilege escalation patterns)에 대한 탐지를 제공합니다. 그런 다음 Amazon Detective는 multi-account management(일반적으로 AWS Organizations를 통해)를 사용하여 GuardDuty findings와 관련 activity(CloudTrail, VPC Flow Logs 및 기타 context)를 accounts 전반에서 자동으로 집계하고 상관 분석함으로써 “단일 요약 뷰”와 신속한 조사 기능을 제공합니다. 이는 incident 조사를 위해 S3/Athena/QuickSight pipeline을 구축하고 운영할 필요가 없으므로 raw log 관리 최소화 요구 사항을 충족합니다. 주요 AWS 기능 / 모범 사례: - GuardDuty EKS Audit Log Monitoring: custom analytics를 구축하지 않고도 Kubernetes audit events에서 위협을 탐지합니다. - Detective: investigation graphs, entity timelines, cross-account context를 제공하여 GuardDuty finding에서 관련 API calls, IAM principals, network connections로 pivot할 수 있게 합니다. - accounts 전반의 중앙 집중식 활성화와 가시성을 위해 AWS Organizations에서 delegated administrator를 사용합니다. 흔한 오해: logs를 Amazon S3에 저장하고 Athena/QuickSight로 쿼리하면 dashboards를 만들 수 있지만, 운영 오버헤드가 증가하며 Detective와 같은 managed correlation/investigation workflow를 제공하지는 않습니다. CloudWatch Container Insights는 성능/운영 telemetry용이지, 보안 조사용이 아닙니다. 시험 팁: 요구 사항에 “rapid investigation”, “summarized view”, “minimize log management”가 포함되면 GuardDuty(detect) + Detective(investigate)를 떠올리십시오. EKS 관련 의심 활동에 대해서는 “GuardDuty for EKS Audit Logs”를 찾으십시오.

문제 10

한 헬스케어 회사는 가져온 키 자료(imported key material) 요구 사항 때문에 자동 로테이션이 비활성화된 customer managed AWS KMS keys를 사용하고 수동 로테이션을 수행하고 있으며, 보안 팀은 us-east-1 또는 eu-west-1에 있는 어떤 활성 키라도 지난 120일 이내에 로테이션되지 않은 경우 알림을 받기를 원한다. 어떤 솔루션이 이를 달성할 수 있는가?

문제 분석

핵심 개념: 이 문제는 imported key material에 의존하기 때문에 automatic rotation을 사용할 수 없는 customer managed AWS KMS key에 대해 custom compliance check를 구축하는 내용입니다. 요구 사항은 us-east-1 또는 eu-west-1의 모든 active key 중 manual rotation 없이 120일을 초과한 경우 경고하는 것이며, 이를 위해서는 기본 KMS 기능이 아니라 custom evaluation logic이 필요합니다. 정답인 이유: AWS Config는 지속적인 compliance evaluation을 위해 설계되었고 AWS Lambda로 지원되는 custom rule을 지원하므로 가장 적합합니다. custom rule은 각 필수 Region의 KMS key를 평가하고, key가 active 상태인지 판단하며, key의 마지막 manual rotation 날짜를 120일 임계값과 비교할 수 있습니다. KMS는 manually rotated imported key material에 대해 age 기반 경고를 기본적으로 제공하지 않으므로, 구현은 rotation 이벤트마다 조직이 기록하는 metadata(예: tag, parameter 또는 rotation process 중 업데이트되는 다른 authoritative store)에 의존해야 합니다. key가 기한을 초과하면 rule은 이를 NON_COMPLIANT로 표시하고, Config compliance 변경에 대한 EventBridge rule을 통해 또는 직접 SNS 알림을 트리거할 수 있습니다. 주요 AWS 기능: 1. AWS Config custom rule은 managed rule로 제공되지 않는 조직별 compliance logic을 허용합니다. 2. Regional deployment를 통해 us-east-1 및 eu-west-1에서 KMS key를 각각 확인할 수 있으며, 선택적으로 aggregation을 사용해 중앙 집중식 가시성을 확보할 수 있습니다. 3. Lambda-backed evaluation은 120일 임계값 및 active key 상태에 대한 custom comparison logic을 가능하게 합니다. 4. SNS와 EventBridge를 사용하여 key가 noncompliant 상태가 될 때 security team에 알릴 수 있습니다. 일반적인 오해: 흔한 실수는 AWS KMS가 key가 특정 임계값보다 오래되었거나 manual rotation이 기한을 초과했을 때 직접 알림을 보낼 수 있다고 가정하는 것입니다. 또 다른 오해는 Trusted Advisor 또는 Security Hub가 이 정확한 imported-key-material manual-rotation 요구 사항에 대한 built-in control을 제공한다고 생각하는 것입니다. 실제로 이것은 manual rotation이 언제 발생했는지에 대한 supporting metadata와 함께 AWS Config가 필요한 custom compliance 사용 사례입니다. 시험 팁: 문제가 custom threshold와 alerting을 포함한 지속적인 compliance monitoring을 요구한다면, AWS Config가 보통 가장 강력한 정답입니다. KMS manual rotation 시나리오에서는 imported key material이 automatic rotation을 비활성화하고 KMS가 기본 overdue-rotation alarm을 제공하지 않는다는 점에 주의하세요. 시험에서는 요구 사항이 정확하고, customizable하며, compliance 중심적일 때 일반적인 security dashboard보다 AWS Config custom rule을 우선 선택하세요.

Practice Test #2

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(6)

다른 모의고사

Practice Test #1

지금 학습 시작하기