Practice Test #1

오답입니다. 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는 버퍼링에 유용할 수 있지만, 여기서는 필요하지 않으며 이메일 요구 사항을 직접 충족하지도 못합니다.

오답입니다. 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가 의도된 도구이다.

오답입니다. 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를 제공하지 않습니다.

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로 더 잘 충족됩니다.

Fargate에서 EC2로 replatforming하여 SSH access를 얻는 것은 운영 부담이 크고(패치, scaling, host hardening) 새로운 관리 overhead를 유발합니다. 또한 incident response를 지연시킵니다. host-level inspection은 가능하겠지만 “운영 부담 최소화” 요구 사항을 위반하며, ECS Exec가 launch type 변경 없이 container access를 제공하므로 불필요합니다.

STDOUT과 awslogs driver를 통해 CloudWatch Logs로 로그를 전송하는 것은 좋은 logging 패턴이지만, live task를 조사하고 /var/log/app의 기존 파일을 가져오거나 필요 시 memory/core dump를 캡처해야 한다는 요구 사항을 충족하지 못합니다. 또한 애플리케이션 변경이 필요하며 로그만 다루고 interactive forensic collection은 제공하지 않습니다.

CloudWatch Container Insights와 ADOT는 observability 및 detection을 위한 metrics/traces/log telemetry를 제공할 뿐, interactive access나 artifact retrieval을 제공하지 않습니다. 실행 중인 Fargate container에 들어가 /var/log/app 파일을 가져오거나 특정 256-MB memory/core dump를 생성할 수 없습니다. 이는 incident response forensics라기보다 monitoring에 더 가깝습니다.

Incorrect. GuardDuty is primarily a threat detection service that generates findings based on suspicious activity (e.g., anomalous API calls, known malicious IPs). It does not provide a native “rule to block a leaked access key at the account boundary.” Prevention would require disabling the key in IAM or using other controls (e.g., SCPs/permissions boundaries), not GuardDuty.

Incorrect. Keeping the compromised key active for 24 hours to gather evidence conflicts with the requirement to “immediately prevent any additional use” and increases risk of further unauthorized actions. Evidence collection should be done from logs (CloudTrail, VPC Flow Logs, etc.) after containment. You can still investigate past usage even after disabling the key.

Incorrect. IAM credential reports provide metadata (e.g., key age, status, last used date in some contexts) but are not a detailed audit trail of API calls and do not reliably satisfy “determine whether used without authorization within the last 24 hours” with source IPs and resources accessed. CloudTrail is the authoritative source for API-level forensics.

오답입니다. IAM은 ECS task definitions를 보거나 tasks를 describe할 수 있는 사용자를 제한할 수는 있지만, 근본적인 위험을 제거하지는 못합니다. secret은 여전히 task definition에 plaintext로 존재하며 task metadata endpoints 또는 다른 운영 경로를 통해 노출될 수 있습니다. 보안 모범 사례는 secrets를 task definitions에서 완전히 제거하고 암호화 및 감사 가능한 액세스를 제공하는 전용 secret store에 저장하는 것입니다.

오답입니다. AWS Step Functions는 workflow/orchestration 서비스이며 secrets 저장을 위해 설계되지 않았습니다. PIN을 state machine input/output에 넣으면 execution history가(명시적으로 필터링하지 않는 한) 데이터를 보존할 수 있어 오히려 노출이 증가할 가능성이 있고, 불필요한 비용과 복잡성을 추가합니다. 이는 ECS/Fargate의 least privilege 또는 secret-management 모범 사례와도 맞지 않습니다.

부분적으로는 맞지만 MOST cost-effective는 아닙니다. AWS Secrets Manager는 강력한 기능(rotation, versioning, staging labels, integration patterns)을 갖춘 훌륭한 secret store이지만, per-secret 월 과금과 API call 비용이 있습니다. rotation workflow가 필요하지 않은 짧은 PIN의 경우, 대규모에서는 일반적으로 SSM Parameter Store SecureString보다 비용이 더 많이 듭니다.