AWS Certified Security - Specialty (SCS-C02)

오답입니다. AWS Batch는 큐잉된, 컴퓨팅 집약적이며 더 오래 실행되는 작업을 위해 설계되었고, 근실시간 보안 remediation에는 불필요한 인프라와 지연을 유발합니다. finding을 Batch를 통해 Lambda로 전달하는 것은 EventBridge에서 Step Functions/Lambda로 직접 통합하는 방식에 비해 안티패턴입니다. 또한 교차 계정 작업을 복잡하게 만들고 5분 알림 SLA를 더 비결정적으로 만듭니다.

오답입니다. CloudWatch metric filter는 CloudWatch Logs의 로그 이벤트에서 동작하며, IAM Access Analyzer finding을 1급 이벤트로 처리하지 않습니다. 설령 finding이 어딘가에 로깅되더라도, metric filter로 AWS Batch를 트리거하는 방식은 간접적이고 취약합니다. EventBridge가 서비스 이벤트를 위한 의도된 통합 지점이며, 자동 대응을 위한 더 나은 필터링, 라우팅, 신뢰성을 제공합니다.

오답입니다. SQS는 메시지 큐이며, 자체적으로 이메일 수신자에게 “알림을 전달”하지 못합니다. 큐를 폴링한 뒤 SNS/SES로 이메일을 보내는 consumer(Lambda/EC2)가 필요해 복잡성과 지연 가능성이 증가합니다. SQS는 버퍼링에 유용할 수 있지만, 여기서는 필요하지 않으며 이메일 요구 사항을 직접 충족하지도 못합니다.

instance profile을 제거하거나 취소하는 것은 비정상적인 egress traffic volume에 대한 GuardDuty finding에 대해 가장 효과적인 첫 번째 격리 단계가 아닙니다. 의심스러운 트래픽은 malware, 손상된 애플리케이션 프로세스 또는 instance profile credentials에 전혀 의존하지 않는 data exfiltration으로 인해 발생할 수 있습니다. 또한 실행 중인 EC2 인스턴스에서 IAM role을 변경하거나 제거하는 것은 직접적인 network isolation 메커니즘이 아니며 outbound connections를 즉시 중단시키지 못할 수 있습니다. 이러한 유형의 finding에 대한 AWS 모범 사례는 먼저 credentials에 집중하기보다 인스턴스의 network access를 격리하는 것입니다.

세 개의 private subnet 모두에 대해 network ACLs를 변경하면 불필요하게 큰 blast radius가 발생합니다. NACLs는 의심스러운 인스턴스만이 아니라 해당 subnet의 모든 리소스에 적용되기 때문입니다. 이는 동일한 VPC와 subnet에서 호스팅되는 관련 없는 워크로드를 중단시킬 수 있으며, 애플리케이션과 다른 리소스에 대한 영향을 최소화해야 한다는 요구 사항과 직접적으로 충돌합니다. 또한 NACLs는 stateless이므로, 정밀한 deny rules를 구현하고 유지 관리하는 것은 quarantine security group을 사용하는 것보다 오류가 발생하기 쉽습니다. GuardDuty EC2 findings의 경우 AWS는 일반적으로 광범위한 subnet 수준 network 변경보다 대상이 명확한 인스턴스 격리를 선호합니다.

GuardDuty findings를 email notification용 SNS topic으로 보내는 것은 alerting은 제공하지만 자동화된 containment는 수행하지 않습니다. 문제는 즉각적인 초기 대응 조치를 명시적으로 요구하므로, 보안 팀의 수동 triage는 너무 느리며 자동화 요구 사항을 충족하지 못합니다. 이 옵션은 또한 의심스러운 egress traffic을 줄이거나 잠재적으로 손상된 인스턴스를 격리하는 데 아무런 역할도 하지 않습니다. SNS는 자동화된 워크플로를 보완할 수는 있지만, 그 자체만으로는 incident containment에 충분하지 않습니다.

오답입니다. AWS Audit Manager는 PCI DSS 같은 framework에 대한 evidence(예: configuration snapshot, control mapping)를 수집하는 compliance automation 서비스입니다. near-real-time threat detection engine으로 동작하지 않으며 InstanceCredentialExfiltration 같은 GuardDuty 스타일의 보안 finding을 생성하거나 인덱싱하지 않습니다. Audit Manager report에 의존하는 것은 간접적이며, 요구된 시간 구간 내의 특정 질문에 답하기 어렵습니다.

오답입니다. CloudTrail에서 GetSessionToken을 검색하는 것은 도난당한 instance profile credential 사용을 탐지하는 신뢰할 수 있는 방법이 아닙니다. Instance profile credential은 이미 temporary STS credential이며 AWS API를 호출하는 데 직접 사용될 수 있어, 공격자가 GetSessionToken을 호출하지 않을 수 있습니다. 또한 CloudTrail은 caller identity(access key, principal)와 source IP를 기록하지만, 단순한 GetSessionToken 쿼리만으로 “외부 AWS account”를 확실히 귀속시키는 것은 보장되지 않습니다.

오답입니다. 여기서 CloudWatch Logs에는 VPC Flow Logs가 포함되어 있는데, 이는 네트워크 flow record(5-tuple metadata)이며 GetSessionToken 같은 AWS API call을 포함하지 않습니다. CloudTrail log가 CloudWatch Logs로 명시적으로 전달된 것이 아니라면(문제에 언급되지 않음) CloudWatch Logs는 STS API event 검색을 위한 올바른 데이터 소스가 아닙니다. 설령 CloudTrail이 CloudWatch에 있더라도, option C와 동일하게 GetSessionToken은 적절한 지표가 아닙니다.

오답입니다. Security Hub custom action은 주로 수동, 분석가 주도 워크플로(예: console에서 finding을 선택하고 custom action을 실행) 또는 명시적 API 호출을 위한 것입니다. 새로운 finding이 import될 때 자동으로 실행되지 않습니다. Systems Manager Automation이 remediation을 수행할 수는 있지만, 여기서의 트리거 메커니즘은 import 시 60초 이내 자동 실행 요구 사항을 충족하지 못합니다.

오답입니다. option B와 마찬가지로, Lambda를 target으로 하는 Security Hub custom action은 일반적으로 Security Hub console에서 사용자가 시작하거나(또는 명시적 custom action API 사용) 실행되며, import되는 모든 finding에 대해 자동으로 실행되지 않습니다. 따라서 Lambda 자체는 serverless이고 확장 가능하더라도, HIGH/CRITICAL finding이 import될 때 자동으로 remediation을 트리거해야 한다는 요구 사항을 충족하지 못합니다.

오답입니다. AWS Config rule은 AWS 리소스 구성과 원하는 상태에 대한 compliance를 평가하도록 설계되었으며, Security Hub로 import된 서드파티 vulnerability finding에 반응하도록 설계된 것이 아닙니다. Config 평가는 주기적이거나 구성 변경 기반일 수 있지만, Security Hub import finding을 event source로 네이티브하게 소비하지 않습니다. 이 접근은 60초 요구 사항을 놓칠 위험이 있으며 개념적으로도 맞지 않습니다.

S3 + Glue + Athena는 로그를 중앙화하고 쿼리할 수 있으며, 자체 구축 로그 lake 패턴으로는 유효합니다. 그러나 많은 AWS Marketplace 파트너 도구나 온프레미스 syslog/방화벽 소스 전반에서 이벤트를 본질적으로 정규화하지는 못하며, 각 소스별로 사용자 지정 수집, 파싱, 스키마 매핑을 구축하고 유지관리해야 합니다. 또한 기본 제공 OCSF 정규화를 제공하지 않으므로, 이 규모의 대형 핀테크 환경에서는 효과성이 떨어집니다.

CloudWatch Logs subscription filter를 OpenSearch로 전달하는 방식은 준실시간 검색과 대시보드를 지원하지만, 75개 계정과 온프레미스 로그까지 포함해 400일 보관을 수행하기에는 일반적으로 비용이 높고 운영 부담이 큽니다. OpenSearch는 저비용 장기 보관보다는 인덱싱된 검색에 최적화되어 있습니다. 또한 여러 파트너 도구 및 사용자 지정 소스에서 오는 이질적인 보안/네트워크 이벤트를 일관된 SQL 분석을 위한 공통 스키마로 자동 정규화하지도 않습니다.

SCP는 API 작업을 deny 또는 allow할 수는 있지만, 모든 서비스와 계정 전반에서 특정 S3 bucket으로 로그를 전달하도록 “강제”할 수는 없으며, 구성은 여전히 서비스별로 구현되어야 합니다. 또한 OpenSearch는 S3 로그 파일에 대한 직접적인 SQL 쿼리 엔진이 아니며(이 경우 Athena가 적합), 이 옵션은 AWS Marketplace 도구 및 온프레미스 소스 전반의 정규화 요구 사항도 다루지 않습니다. 기술적으로 부정확하고 요구 사항을 충족하기에 불완전합니다.

오답. Amazon Macie는 주로 Amazon S3에서 민감 데이터(PII, credential 등)를 발견하고 분류하도록 설계되었다(관리형 data identifier 사용). NGINX access log를 위한 log query engine이 아니며 “IP와 path별 요청 수 집계” 같은 ad hoc aggregation을 기본적으로 제공하지 않는다. 또한 log를 S3로 export하는 것은 7일 조사에 불필요한 단계와 지연을 추가한다.

“최소 노력” 관점에서 오답. CloudWatch Logs subscription filter를 OpenSearch로 보내는 방식은 near-real-time indexing 및 dashboard 구축에 유용하지만, OpenSearch domain을 provisioning/운영하고 ingestion을 구성해야 한다. 또한 추가적인 export/replay 단계 없이 기존 log의 지난 7일을 자동으로 backfill하지 않는다. 빠른 incident query에는 과도하다.

오답. S3로 export하고 Glue crawler를 실행한 뒤 Glue로 결과를 보는 것은 필요 이상으로 운영 작업이 많다. Glue crawler는 schema를 catalog하는 도구이며, 추가 ETL/filtering logic 없이 “IP를 포함하는 entry만 catalog”하는 것을 본질적으로 수행하지 않는다. 7일 범위에서의 단순 count 및 grouping에는 CloudWatch Logs Insights가 의도된 도구이다.

오답입니다. AWS Systems Manager Change Manager는 approval, scheduling, governance workflow를 갖춘 통제된 운영 변경을 위해 설계되었습니다. 이는 120개 계정 전반에서 configuration drift를 지속적으로 탐지하거나 security baseline violation을 거의 실시간에 가까운 수준으로 자동 remediation하기 위한 기본 서비스가 아닙니다. remediation에 SSM runbook을 사용할 수는 있지만, detection 및 eventing 요구 사항은 AWS Config, Security Hub, EventBridge가 더 잘 충족합니다.

오답입니다. Security Hub custom action은 주로 analyst가 Security Hub console에서 수동으로 downstream workflow를 트리거할 수 있게 하는 데 사용됩니다. 자동 remediation에는 필요하지 않은데, EventBridge가 analyst의 상호작용 없이도 Security Hub finding에 직접 반응할 수 있기 때문입니다. custom action을 포함하면 자동 응답이라는 명시된 요구 사항에 대해 확장성이나 비용 효율성을 개선하지 못하는 추가적인 수동 지향 구성 요소만 더하게 됩니다.

오답입니다. Lambda를 사용해 API request를 검사하고 custom finding을 생성하는 것은 기본 AWS compliance 및 security 서비스를 맞춤형 솔루션으로 대체하는 것입니다. API request inspection은 일반적으로 CloudTrail event를 기반으로 하며, drift detection에서 중요한 현재 configuration state를 신뢰성 있게 나타내지 못합니다. 이 옵션은 public bucket이나 과도하게 허용적인 security group을 탐지하는 데 AWS Config + Security Hub를 사용하는 것보다 확장성이 낮고 운영적으로 더 복잡하며 열등합니다.

Amazon Macie는 주로 Amazon S3에서 민감 데이터를 발견하고 분류하며(그리고 findings/alerts를 지원), 개발자가 로그 이벤트의 나머지 부분은 보되 이메일 주소는 보지 못하도록 CloudWatch Logs에서 인플레이스(in-place)로 마스킹/리댁션을 제공하지 않는다. Macie는 이메일이 존재함을 식별할 수는 있지만 CloudWatch Logs 콘솔/API에서 “개발자는 이메일을 볼 수 없음”을 강제하지는 못한다.

customer managed KMS key로 로그 그룹을 암호화하고 개발자 액세스를 거부하면 개발자는 로그를 복호화하고 읽을 수 없게 된다. 요구 사항은 선택적 보호로, 개발자는 문제 해결을 위해 다른 모든 필드는 보되 이메일 주소만 보지 못해야 한다. KMS key policy와 grants는 로그 이벤트 내 필드 수준 redaction을 지원하지 않으며, 암호화된 데이터 전체에 대한 액세스를 제어한다.

Lambda로 보내는 subscription filter는 이메일을 파싱해 마스킹할 수 있지만, 다른 목적지(대개 다른 로그 그룹, S3, 또는 OpenSearch)로 전달해야 한다. 이는 사실상 중복된 sanitized 사본을 만드는 것이며, 문제에서 명시적으로 금지한다. 또한 높은 수집률(분당 18,000 이벤트)에서 운영 오버헤드와 비용을 증가시키고, 네이티브 CloudWatch Logs 기능 대비 장애 지점/지연을 추가한다.

오답입니다. AES-256으로 생성된 기존 ECR repository에서 단순히 “KMS encryption을 활성화”할 수는 없습니다. ECR repository encryption 설정은 생성 시 정의되며 일반적으로 CMK로 전환하도록 변경할 수 없습니다. 또한 EC2 instance에 Amazon Inspector Agent를 설치하는 것은 host vulnerability를 평가하는 것이지, ECR로 image push 시 트리거되는 container image CVE를 평가하는 것이 아니므로 “다음 image push 이후 report” 요구 사항을 충족하지 못합니다.

오답입니다. CMK로 repository를 재생성하고 scanning을 활성화하는 것은 ECR 요구 사항과는 부합하지만, AWS Systems Manager(SSM) Agent를 설치하고 inventory report를 생성하는 것은 container image CVE findings를 제공하지 않습니다. SSM Inventory는 instance/software inventory 및 compliance metadata를 위한 것이지, image push 이벤트에 연동된 ECR image vulnerability scanning 결과가 아닙니다.

오답입니다. A와 마찬가지로 기존 ECR repository를 AES-256에서 CMK encryption으로 in-place로 변경할 수는 없습니다. 또한 AWS Trusted Advisor는 image push 이후 container image CVE scanning이나 vulnerability report를 제공하지 않습니다. Trusted Advisor는 비용 최적화, 성능, 내결함성, service limits, 일부 보안 점검에 초점을 두며, ECR image CVE findings를 제공하지 않습니다.

오답. Session Manager가 올바른 원격 액세스 메커니즘이긴 하지만, SSH-RSA key pair를 생성하고 배포하는 것은 불필요하며 SSH key pair 배포를 피하라는 요구 사항을 위반한다. Session Manager는 SSH key가 전혀 필요 없다. 이 옵션은 이점 없이 운영 오버헤드와 위험(키 관리/로테이션)을 추가한다.

오답. EC2 Instance Connect는 주로 Linux 인스턴스에 대한 SSH 액세스를 위한 것이며, 여전히 22번 포트에 대한 네트워크 연결(연결 소스에서의 인바운드 허용)과 적절한 security group/NACL 규칙이 필요하다. TCP 22를 열지 말라는 요구 사항을 충족하지 못하며, S3로의 중앙 집중식 세션 로깅을 포함해 Windows Server 관리를 대규모로 수행하는 표준 통합 접근 방식도 아니다.

오답. 이 옵션은 두 가지 측면에서 맞지 않는다: SSH key를 생성/배포해야 하며(명시적으로 금지됨), EC2 Instance Connect에 의존하는데 이는 여전히 22번 포트의 SSH를 사용하고 Windows 관리에 대한 포괄적 솔루션이 아니다. 또한 Session Manager의 S3 로깅과 같은 중앙 집중식 세션 로깅/감사 모델을 본질적으로 제공하지 않는다.

기능적으로는 per-object signed URL도 동작하지만 CMAF에 대해 가장 단순한 방법은 아닙니다. 6~10시간 스트림에서 약 10,800개의 세그먼트는 애플리케이션이 지속적으로 signed URL을 생성·전달해야 하고(새 세그먼트가 나타날 때마다 재서명 필요 가능), 이는 애플리케이션 복잡도를 높이고 재생 지연을 유발할 수 있으며 플레이어 로직을 복잡하게 만듭니다. Signed URL은 소수의 파일 또는 일회성 다운로드에 더 적합합니다.

Lambda@Edge로 JWT를 검증하면 커스텀 인가 로직을 강제할 수 있지만, Lambda@Edge 배포/복제, 요청당 실행 비용/지연, 운영 복잡성 등 구성 요소가 추가됩니다. 여기서는 CloudFront가 이미 native private content 제어(signed cookie/URL)를 제공하고 오리진도 이미 CloudFront 뒤에서 private이므로 불필요합니다. signed cookie/policy로 표현할 수 있는 시간/경로/IP 기반 정책을 넘어서는 로직이 필요할 때만 Lambda@Edge를 사용하세요.

CloudFront distribution URL을 암호화하는 것은 실질적인 접근 제어가 아닙니다. 앱이 URL을 숨기거나 런타임에 복호화하더라도 클라이언트는 결국 복사·재사용 가능한 요청을 전송하게 됩니다. 이는 보안의 은폐에 불과하며, KMS는 이런 방식으로 CloudFront 요청 인가와 통합되지 않습니다. 올바른 제어는 CloudFront signed URL/cookie와 private 오리진을 통해 수행합니다.

오답(제시된 대상 집단에 대해). IAM account password policy는 해당 AWS account의 IAM user에만 적용됩니다(IAM user의 console password). Okta에서 인증하는 SAML-federated 직원에게는 영향을 주지 않으며, Amazon Cognito user pool user에도 적용되지 않습니다. 회사에 console password를 가진 IAM user가 추가로 있는 경우에만 유용할 수 있으나, 시나리오에서는 이를 나타내지 않습니다.

오답. AWS Organizations의 Service Control Policy는 member account에서 principal이 수행할 수 있는 AWS API action을 제한하지만, IAM user, Cognito user 또는 외부 IdP에 대해 password length를 강제하는 메커니즘을 제공하지 않습니다. SCP는 Okta에 영향을 줄 수 없고, Cognito password policy 설정을 강제할 수도 없습니다. 기껏해야 특정 구성을 변경하지 못하게 막을 수는 있어도 password complexity를 강제하지는 못합니다.

오답. IAM policy(및 condition key)는 AWS API action과 resource에 대한 authorization을 제어할 뿐, IAM user password의 length 규칙을 검증하거나 강제하지 않으며 Cognito user pool password에도 적용할 수 없습니다. Cognito password policy는 IAM policy condition이 아니라 user pool에서 구성합니다. 마찬가지로 federated user의 password는 AWS가 아니라 IdP에서 관리합니다.

오답입니다. AmazonSSMManagedInstanceCore는 Systems Manager 기능(SSM Agent, Session Manager, Run Command)을 활성화하며 sts:AssumeRole 권한 부여와는 관련이 없습니다. 이를 연결하면 인스턴스를 관리하거나 트러블슈팅하는 데 도움이 될 수는 있지만, CorpForensicsAccessRole을 assume할 권한을 부여하지 않으며 AssumeRole AccessDenied 오류를 해결하지 못합니다.

오답입니다. WebForensicsRole의 trust policy는 ec2.amazonaws.com이 이를 assume하도록 허용해야(인스턴스 프로파일이 자격 증명을 전달할 수 있도록) 하지만, 시나리오에서는 애플리케이션이 이미 인스턴스 프로파일 role을 사용하여 AssumeRole을 시도하고 있습니다. 실패한 작업은 CorpForensicsAccessRole로의 cross-account AssumeRole이며, 이는 WebForensicsRole의 trust policy 수정이 아니라 A와 C에 의해 좌우됩니다.

오답입니다. 호출을 특정 regional STS endpoint(예: us-east-1)로 보내는 것은 일반적으로 AccessDenied 오류의 원인이 아닙니다. endpoint 선택 문제는 보통 네트워크/endpoint 오류, 서명 문제 또는 서비스 가용성 문제로 나타납니다. AssumeRole에 대한 권한 부여 실패는 거의 항상 호출자 권한 누락, trust policy 누락/오류, 또는 명시적 deny/조건 문제 때문입니다.

DynamoDB access를 허용하는 inline policy는 현재 필요한 permissions를 부여할 수는 있지만, 나중에 group membership이나 다른 attached policies를 통해 추가 permissions를 얻는 것을 막지 못합니다. 사용자가 이후 AdministratorAccess가 있는 group에 추가되면 다른 services에도 액세스할 수 있습니다. Inline policies는 guardrail이 아니라 identity-based permissions의 한 소스일 뿐입니다.

사용자를 DynamoDB-only group에 넣는 것은 access를 부여하는 일반적인 방법이지만, 향후 변경에 대해 지속적으로 보장되지 않습니다. 사용자가 이후 더 광범위한 permissions(예: AdministratorAccess)을 가진 다른 group에 추가되면 사용자의 effective permissions가 확장됩니다. Group 기반 permission 관리는 additive이며, 본질적으로 최대 permission boundary를 강제하지 않습니다.

Explicit denies가 있는 role은 role이 할 수 있는 일을 제한할 수는 있지만, vendor가 항상 그 role을 assume하고 해당 role credentials만 사용한다는 전제에 의존합니다. 또한 underlying IAM user가 나중에 직접 또는 groups를 통해 다른 permissions를 부여받는 것을 본질적으로 막지 못합니다. 요구 사항은 향후 어떤 attachment가 있더라도 IAM user의 effective permissions를 제한하는 것이며, 이는 permissions boundary로 더 잘 충족됩니다.

AWS Directory Service for Microsoft AD는 SAML/ADFS 스타일 구성과 통합할 수 있지만, AWS Organizations를 통해 여러 AWS account에 대한 액세스를 중앙에서 관리하기 위한 적절한 control plane이 아닙니다. 또한 directory user에 IAM policy를 직접 연결할 수 없습니다. AWS에서 권한 부여는 IAM role/policy를 통해 수행됩니다. 이 옵션은 중앙 집중식 multi-account RBAC 및 SAML app assignment 요구 사항을 깔끔하게 충족하지 못합니다.

20개 account 각각에서 SAML federation을 별도로 구성하면 관리 오버헤드가 크게 증가하고 거버넌스가 일관되지 않게 됩니다. 또한 OU 전반에서 management account로부터 중앙에서 관리해야 한다는 요구 사항을 약화시킵니다. 추가로 federated user는 IAM user가 아니며, “federated user”에 policy를 직접 연결하는 것이 아니라 role을 assume하여 액세스를 부여합니다. 이 접근 방식은 확장성이 떨어지고 오류가 발생하기 쉽습니다.

Amazon Cognito는 주로 고객 대상 application 인증/권한 부여(web/mobile) 및 app user를 위한 social/SAML IdP federation을 위해 설계되었습니다. AWS Organizations 환경에서 workforce가 AWS account에 액세스하도록 하는 표준 솔루션이 아니며, IAM Identity Center와 같은 중앙 집중식 multi-account permission-set 모델을 제공하지 않습니다. 3,200명의 직원에 대한 AWS account 액세스를 Cognito로 관리하는 것은 비정형적이며 복잡합니다.

오답. governance mode의 S3 Object Lock는 절대적인 WORM이 아니다. s3:BypassGovernanceRetention 권한(또는 이에 준하는 privileged access)을 가진 사용자는 보존을 무시하고 객체를 삭제/수정할 수 있다. 이는 “root account를 포함한 어떤 사용자도” 보관 기간 동안 삭제 또는 수정할 수 없어야 한다는 요구 사항을 충족하지 못한다. governance mode는 변경 불가능한 컴플라이언스 보존이 아니라 내부 통제를 위한 것이다.

이 시나리오에서 최선의 답이 아니다. S3 Glacier Vault Lock는 Glacier vault에 컴플라이언스 제어를 강제할 수 있지만, 레거시 Glacier vault 모델과 별도의 API를 사용하므로 S3에 비해 운영 오버헤드가 증가한다. 문제는 4.5 PB를 오버헤드를 최소화하면서 비용 효율적으로 보관하라고 하며, 일반적으로 S3에서 Object Lock + lifecycle로 Glacier Deep Archive를 사용하는 방식이 하나의 서비스 내에서 더 단순한 관리와 동등하거나 더 나은 비용 최적화를 제공한다.

오답. S3 Lifecycle로 S3 Glacier storage class로 전환된 객체에 S3 Glacier Vault Lock를 적용할 수 없다. Vault Lock는 S3 Glacier vault(레거시)에 적용되며 S3 bucket이나 S3 Glacier/Deep Archive storage class에는 적용되지 않는다. S3 객체의 경우 올바른 변경 불가능성 메커니즘은 Glacier Vault Lock가 아니라 S3 Object Lock(compliance mode)이다.

오답입니다. 2분마다 retry하는 방식은 디바이스 등록 후 100 ms 이내에 암호화해야 한다는 애플리케이션 요구 사항을 충족하지 못합니다. eventual consistency 문제가 그 시점에는 해결될 수 있더라도, 이 접근 방식은 즉시 grant를 사용하도록 설계된 KMS 기능을 사용하는 대신 증상만 다루는 것입니다. 또한 높은 처리량의 워크로드에 심각한 지연과 운영 비효율을 초래합니다.

오답입니다. 이 선택지는 클라이언트가 제공한 token을 CreateGrant에 전달하는 것으로 설명하지만, 이 워크플로에서 KMS grant token은 사용자가 임의로 제공하는 값이 아닙니다. 관련 token은 CreateGrant 응답이 반환하는 grant token이며, 이후 KMS 작업의 GrantTokens를 통해 전달됩니다. 따라서 이 선택지는 KMS grant token이 어떻게 획득되고 사용되는지를 잘못 설명하고 있습니다.

오답입니다. grant name은 단지 grant의 식별자일 뿐이며 authorization을 우회하거나 consistency를 건너뛰게 해주지 않습니다. Encrypt 요청에 grant name을 제공해도 새로 생성된 grant를 더 빨리 유효하게 만들 수 없습니다. KMS는 GrantTokens 파라미터에서 grant name이 아니라 grant token을 기대하기 때문입니다. 이 선택지는 grant를 라벨링하는 데 사용되는 메타데이터와 해당 grant를 즉시 사용할 수 있게 하는 token을 혼동하고 있습니다.

오답입니다. AWS KMS는 ScheduleKeyDeletion에 대해 PendingWindowInDays를 0으로 설정하는 것을 허용하지 않으며, 대기 기간(최소 7 days, 최대 30 days)이 강제됩니다. 또한 KMS key를 비활성화하는 것은 즉각적인 cryptographic erasure와 동일하지 않습니다. 따라서 fleet 전반에서 1분 미만의 철회 RTO를 충족할 수 없습니다.

오답입니다. CloudHSM은 고객이 제어하는 HSMs를 제공하지만, EBS encryption은 AWS KMS와 통합되며 PKCS#11을 통해 CloudHSM keys를 EBS volume encryption에 직접 사용하지 않습니다. CloudHSM을 사용하면 운영 오버헤드(clusters, HA, backups, lifecycle)가 크게 증가하고, KMS만큼 “투명한 EBS encryption” 통합 요구 사항을 깔끔하게 충족하지 못합니다.

오답입니다. Systems Manager Parameter Store는 EBS encryption을 위한 암호학적 key management system으로 설계되지 않았습니다. Parameter Store에 키를 저장하면 applications 또는 개발자가 key material을 조회하고 처리해야 하므로, 개발자가 암호화 키를 절대 다루지 않아야 한다는 요구 사항을 위반합니다. 또한 KMS처럼 EBS encryption과 통합되지 않습니다.

golden AMI에 agent를 사전 설치하는 것은 향후 인스턴스에 대한 강력한 예방 조치이며, 승인된 AMI로만 시작을 제한하면 표준화를 개선할 수 있습니다. 그러나 이것은 기존 인스턴스에 agent가 없는지 또는 나중에 agent가 제거되거나 비정상 상태가 되는지를 지속적으로 탐지하지는 못합니다. 요구 사항은 교체 없이 기존 인스턴스를 포함하여 agent가 없는 인스턴스에 자동 설치를 명시적으로 요구합니다. AMI 또는 인스턴스에 태그를 지정하는 것 자체로는 compliance 평가나 수정이 제공되지 않습니다.

Systems Manager Patch Manager는 patch baseline과 maintenance schedule을 기반으로 한 patch compliance 및 배포를 위해 설계되었으며, 일부 애플리케이션 patch 시나리오도 포함합니다. 그러나 이것은 근본적으로 예약 기반 프로세스이며, 모든 Region에서 인스턴스 시작 후 15분 이내에 EDR agent가 설치되도록 보장하는 데 필요한 near-real-time의 event-driven 탐지 및 수정 루프를 제공하지 않습니다. 또한 compliance event를 기반으로 새롭게 noncompliant 상태가 된 인스턴스만 자연스럽게 대상으로 삼지도 않으므로, Config + EventBridge + SSM 수정 패턴보다 적합성이 떨어집니다. agent package를 baseline에 포함할 수 있다고 하더라도, 이 옵션은 명시된 지속적인 자동 수정 요구 사항을 여전히 충족하지 못합니다.

Systems Manager Distributor는 EDR installer와 같은 third-party software를 표준화된 방식으로 패키징하고 배포하는 데 유용합니다. 그러나 이 옵션은 모든 인스턴스를 선택하고 Run Command로 package를 설치하는 것만 설명하며, 이는 지속적인 compliance 모니터링이라기보다 일회성 또는 수동 시작 배포 방식입니다. 새 인스턴스가 agent 없이 시작되거나 나중에 agent가 누락되는 시점을 탐지하는 메커니즘은 포함되어 있지 않습니다. 자동화된 compliance trigger와 대상 지정된 수정 워크플로가 없으면, 명시된 요구 사항을 충족하지 못합니다.