
65개 문제와 170분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
결제 마이크로서비스용 AWS CloudFormation 템플릿을 검토하던 중, 보안 엔지니어는 PaymentApiToken이라는 이름의 파라미터가 기본값으로 프로덕션 API 토큰을 plaintext로 노출하고 있음을 발견했다. 해당 토큰은 템플릿 전반에서 12번 참조되고 있으며(Lambda environment variables, API Gateway headers, ECS task definition), 엔지니어는 템플릿에서 plaintext를 제거하고, 스택 작업 중 12개 모든 위치에서 값을 참조할 수 있는 기능을 유지하며, secret이 at rest에서 암호화되고 stack events 또는 logs에 절대 나타나지 않도록 보장해야 한다. 또한 60일마다 자동 rotation을 지원해야 한다. 다음 중 이러한 요구사항을 가장 안전한 방식으로 충족하는 솔루션은 무엇인가?
Systems Manager Parameter Store SecureString은 저장 시 KMS 기반 암호화를 제공하며, ssm-secure dynamic reference 구문을 사용해 CloudFormation에서 참조할 수 있습니다. 그러나 Parameter Store는 관리형 secret rotation을 위한 주된 AWS 서비스가 아니며, 60일마다 자동 rotation을 구현하려면 기본 제공 workflow가 아니라 custom automation이 필요합니다. 문제에서 명시적으로 자동 rotation을 요구하고 가장 안전한 솔루션을 묻고 있으므로, Secrets Manager가 더 적합합니다. Parameter Store는 암호화된 configuration 값을 저장하는 데는 적절하지만, 전체 secret lifecycle management 측면에서는 덜 완전합니다.
AWS Secrets Manager는 API token과 같은 secret을 저장하고 관리하도록 특별히 설계된 AWS 서비스입니다. 이 서비스는 AWS KMS를 사용해 저장 시 secret을 암호화하고, 기본 제공 자동 rotation을 지원하므로 token을 60일마다 rotation해야 한다는 요구 사항을 직접 충족합니다. Secrets Manager에 대한 CloudFormation dynamic reference를 사용하면 template에 plaintext로 하드코딩하지 않고도 동일한 secret 값을 여러 속성에서 재사용할 수 있습니다. 이 선택지는 관리형 secret 저장, access control, auditing, rotation을 하나의 서비스에서 결합하므로 보기 중 가장 안전하고 운영적으로도 가장 적절한 옵션입니다.
Amazon DynamoDB는 template 속성에서 secret을 가져오기 위한 CloudFormation dynamic reference source로 지원되지 않습니다. DynamoDB는 저장 시 데이터를 암호화할 수 있지만, 관리형 secret 저장소가 아니라 범용 NoSQL database이므로 기본 제공 secret rotation, secret version staging, 또는 secret 전용 access pattern을 제공하지 않습니다. 운영 환경의 API token에 DynamoDB를 사용하는 것은 불필요한 application 및 운영 복잡성을 추가합니다. 또한 infrastructure와 application에서 사용하는 secret을 저장하고 rotation하는 AWS 모범 사례와도 맞지 않습니다.
Amazon S3는 template에서 secret을 해석하기 위한 CloudFormation dynamic reference source로 지원되지 않습니다. 객체가 SSE-S3로 암호화되어 있더라도, S3는 secret management 서비스가 아니라 object storage이므로 자격 증명과 token에 대한 기본 제공 secret rotation이나 version-stage semantics를 제공하지 않습니다. 또한 SSE-S3는 S3 관리형 key를 사용하며, Secrets Manager와 같은 secret 중심 제어 및 workflow를 제공하지 않습니다. 따라서 운영 환경의 API token을 관리하기에는 S3가 더 약하고 덜 안전한 설계 선택입니다.
핵심 개념: 이 문제는 infrastructure-as-code(CloudFormation)에서 dynamic references, at rest 암호화, 자동 rotation을 사용해 secret을 안전하게 관리하는지를 평가한다. 핵심 서비스는 AWS Secrets Manager(Secret + rotation에 특화)와 CloudFormation dynamic references(템플릿 및 stack outputs/events에서 plaintext를 피하기 위함)이다. 정답이 맞는 이유: Option B가 가장 안전한 이유는 AWS Secrets Manager가 AWS KMS로 암호화된 민감 값을 저장하도록 설계되어 있고, 템플릿에 plaintext를 포함하지 않고도 deploy/runtime 시점에 값을 조회할 수 있으며, rotation Lambda를 사용해 일정(60일) 기반의 native 자동 rotation을 지원하기 때문이다. Secrets Manager에 대한 CloudFormation dynamic references({{resolve:secretsmanager:...}})를 사용하면 템플릿 본문에 secret 값을 넣지 않고도 12개 모든 위치에서 secret을 참조할 수 있다. 올바르게 사용하면 CloudFormation이 배포 시점에 값을 resolve하고 템플릿에 plaintext를 영구 저장하지 않으므로, secret 값이 CloudFormation stack events/console output에 표시되지 않는다. 주요 AWS 기능: - KMS를 통한 Secrets Manager의 at rest 암호화(AWS-managed 또는 customer-managed keys). - 구성 가능한 간격(60일)과 rotation Lambda 통합을 통한 automatic rotation. - Secrets Manager에 대한 CloudFormation dynamic references를 사용해 parameters 및 resource properties에서 참조(예: Lambda environment variables, ECS task definition environment variables, 지원되는 경우 API Gateway integration/request parameters). - secret을 읽을 수 있는 주체를 제한하는 세분화된 IAM policies(least privilege) 및 secret access에 대한 CloudTrail auditing. 흔한 오해: SSM Parameter Store SecureString(Option A)은 암호화되어 있고 dynamic references를 지원하지만, Secrets Manager와 같은 1급(First-class) 내장 rotation 워크플로를 제공하지 않는다(rotation은 보통 custom automation이 필요). 또한 일부 팀은 “SecureString”이 자동으로 rotation과 전체 secret lifecycle management를 의미한다고 잘못 가정한다. 시험 팁: 요구사항에 “automatic rotation”과 “most secure”가 포함되면, 문제가 비용을 명시적으로 제한하거나 사용을 금지하지 않는 한 AWS Secrets Manager를 우선 선택하라. CloudFormation에서는 템플릿에서 plaintext를 피하고 코드 저장소에서의 우발적 노출을 줄이기 위해 “dynamic references”를 찾는 것이 핵심이다. secret 저장소는 항상 KMS 암호화와 least-privilege IAM과 함께 사용하라.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.


이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
글로벌 edtech 회사가 AWS Organizations에서 15개의 AWS 계정을 운영하고 있으며, 공개 또는 교차 계정 액세스를 탐지하기 위해 조직 수준에서 AWS Identity and Access Management (IAM) Access Analyzer를 활성화했습니다. 보안 팀은 새로 생성된 IAM 또는 리소스 정책이 ACTIVE Access Analyzer finding을 트리거하는 경우, IAM role trust policy를 업데이트하여 외부 principal에 대한 명시적 Deny를 추가함으로써 외부 액세스를 자동으로 교정(remediate)하고, 5분 이내에 security-ops@example.com으로 이메일 알림을 전송하는 자동화된 워크플로를 요구합니다. 이 요구 사항을 충족하기 위해 보안 엔지니어가 구현해야 하는 단계 조합은 무엇입니까? (세 개를 선택하세요.)
의도된 아키텍처에서 orchestration 구성 요소로서 올바릅니다. AWS Step Functions는 Access Analyzer finding을 검사하고, resource type에 따라 분기하며, AWS SDK integrations 또는 Lambda를 통해 필요한 remediation actions를 호출하는 데 매우 적합합니다. 또한 retries, error handling, auditability를 제공하므로 자동화된 보안 대응에 유용합니다. 옵션의 문구에서는 trust policy에 명시적 Deny를 추가한다고 되어 있지만, 올바른 remediation 패턴은 외부 access를 제거하거나 제한하도록 trust policy를 업데이트한 다음 SNS에 notification을 게시하는 것입니다.
오답입니다. AWS Batch는 큐잉된, 컴퓨팅 집약적이며 더 오래 실행되는 작업을 위해 설계되었고, 근실시간 보안 remediation에는 불필요한 인프라와 지연을 유발합니다. finding을 Batch를 통해 Lambda로 전달하는 것은 EventBridge에서 Step Functions/Lambda로 직접 통합하는 방식에 비해 안티패턴입니다. 또한 교차 계정 작업을 복잡하게 만들고 5분 알림 SLA를 더 비결정적으로 만듭니다.
정답입니다. Amazon EventBridge는 IAM Access Analyzer finding events를 수신하고 status가 ACTIVE인 findings를 필터링하기에 적절한 서비스입니다. Step Functions state machine을 직접 호출할 수 있으므로 polling이나 custom event ingestion 없이 near-real-time remediation이 가능합니다. 이는 조직 전체의 security findings에 대한 표준 AWS event-driven automation 패턴입니다.
오답입니다. CloudWatch metric filter는 CloudWatch Logs의 로그 이벤트에서 동작하며, IAM Access Analyzer finding을 1급 이벤트로 처리하지 않습니다. 설령 finding이 어딘가에 로깅되더라도, metric filter로 AWS Batch를 트리거하는 방식은 간접적이고 취약합니다. EventBridge가 서비스 이벤트를 위한 의도된 통합 지점이며, 자동 대응을 위한 더 나은 필터링, 라우팅, 신뢰성을 제공합니다.
오답입니다. SQS는 메시지 큐이며, 자체적으로 이메일 수신자에게 “알림을 전달”하지 못합니다. 큐를 폴링한 뒤 SNS/SES로 이메일을 보내는 consumer(Lambda/EC2)가 필요해 복잡성과 지연 가능성이 증가합니다. SQS는 버퍼링에 유용할 수 있지만, 여기서는 필요하지 않으며 이메일 요구 사항을 직접 충족하지도 못합니다.
정답입니다. Amazon SNS는 운영 팀에 email notifications를 보내기 위한 AWS의 기본 서비스입니다. SNS topic을 생성하고 security-ops@example.com을 구독시키면 workflow는 remediation 직후 보안 팀에 즉시 알릴 수 있습니다. SNS는 Step Functions와 깔끔하게 통합되며, 요구되는 5분 미만 notification 목표를 지원합니다.
핵심 개념: 이 문제는 IAM Access Analyzer findings에 대해 event-driven 방식의 조직 전체 자동 대응을 구축하는 것에 관한 것입니다. 요구되는 패턴은 near real time으로 ACTIVE findings를 탐지하고, 영향을 받은 policy를 수정하기 위한 orchestration workflow를 호출한 다음, email notification을 보내는 것입니다. 가장 적합한 AWS 서비스는 Access Analyzer events를 라우팅하는 Amazon EventBridge, workflow orchestration을 위한 AWS Step Functions, 그리고 email 전송을 위한 Amazon SNS입니다. 정답인 이유: EventBridge는 finding이 ACTIVE 상태가 될 때 IAM Access Analyzer finding events를 매칭하고 Step Functions workflow를 트리거할 수 있습니다. Step Functions는 finding 세부 정보를 검사하고 AWS APIs 또는 Lambda functions를 호출하여 영향을 받은 policy를 수정할 수 있습니다. 예를 들어, 외부 access를 제거하거나 제한하도록 IAM role trust policy를 업데이트할 수 있습니다. 그런 다음 SNS는 필요한 시간 창 내에 security-ops@example.com으로 필요한 email notification을 전송합니다. 주요 AWS 기능: 1) IAM Access Analyzer는 EventBridge와 통합되므로 polling 없이 findings가 automation을 트리거할 수 있습니다. 2) EventBridge는 ACTIVE와 같은 finding status에 대한 event pattern matching을 지원하며 Step Functions를 직접 호출할 수 있습니다. 3) Step Functions는 여러 account에 걸친 policy remediation workflows를 위해 branching, retries, 그리고 service integrations를 제공합니다. 4) SNS는 email subscriptions를 지원하며 운영 알림을 위한 표준 AWS-native 서비스입니다. 흔한 오해: CloudWatch metric filters는 log 기반 pattern matching용이지, Access Analyzer findings를 직접 소비하기 위한 것이 아닙니다. AWS Batch는 batch compute workloads를 위한 서비스이며 security findings에 대한 적절한 near-real-time trigger 또는 orchestration 메커니즘이 아닙니다. SQS는 consumer 분리에 유용하지만 자체적으로 email notifications를 보내지는 않습니다. 시험 팁: AWS 보안 automation 문제에서는 service-generated findings의 trigger로 EventBridge, remediation logic으로 Step Functions 또는 Lambda, 그리고 email notifications용으로 SNS를 찾으세요. IAM policy semantics에도 주의하세요. trust policies는 일반적으로 Allow statements를 통해 assumption을 허용하며, 보통 Deny statements를 추가하기보다는 해당 Allow를 제거하거나 더 엄격하게 제한하는 방식으로 수정합니다.
온라인 리테일 마켓플레이스는 회사의 audit account에서 AWS Security Hub와 통합되는 서드파티 SaaS container vulnerability scanner를 사용합니다. 보안 팀은 이 서드파티 제품에서 severity label이 HIGH 또는 CRITICAL인 새로운 finding이 us-east-1의 Security Hub로 import될 때, 60초 이내에 remediation workflow가 자동으로 트리거되어야 하며, 어떤 서버도 관리하지 않으면서 분당 최대 500개의 finding이 몰리는 burst도 처리할 수 있도록 확장 가능해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
정답입니다. Security Hub는 import된 finding을 동일한 Region에서 EventBridge 이벤트로 게시합니다. EventBridge rule은 “Security Hub Findings - Imported” 이벤트를 매칭하고 서드파티 제품 및 severity label HIGH/CRITICAL로 필터링할 수 있습니다. EventBridge는 수 초 내에 Lambda를 호출하며 두 서비스 모두 자동 확장되므로, 서버를 관리하지 않고도 60초 SLA와 burst 요구 사항을 충족합니다. 신뢰성을 위해 retry/DLQ 또는 destination을 추가할 수 있습니다.
오답입니다. 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초 요구 사항을 놓칠 위험이 있으며 개념적으로도 맞지 않습니다.
핵심 개념: 이 문제는 AWS Security Hub finding, Amazon EventBridge(이전 CloudWatch Events), 그리고 AWS Lambda를 사용하여 서버 없이(event-driven) 거의 실시간으로 대규모 remediation을 자동화하는 것을 테스트합니다. 정답이 맞는 이유: 서드파티 finding이 Security Hub로 import되면, Security Hub는 동일한 Region(여기서는 us-east-1)에서 “Security Hub Findings - Imported”와 같은 EventBridge 이벤트를 발행합니다. EventBridge rule은 product/source와 finding severity label(HIGH/CRITICAL)을 기준으로 필터링한 뒤, remediation을 실행하는 Lambda function을 호출할 수 있습니다. EventBridge는 수 초 내에 이벤트를 전달하므로 60초 요구 사항을 충족하며, EventBridge와 Lambda는 모두 완전관리형 서비스로 자동 확장됩니다. 분당 500개 finding burst(~초당 8.3개)는 일반적인 EventBridge 및 Lambda 확장 패턴에서 충분히 처리 가능하며, 적절한 Lambda concurrency 설정을 통해 대응할 수 있습니다. 주요 AWS 기능: - EventBridge rule pattern matching: 불필요한 invocation을 피하기 위해 Security Hub event type, product name/ARN, severity label로 필터링합니다. - Serverless scaling: EventBridge는 ingestion과 routing을 확장하고, Lambda는 concurrency로 확장합니다. downstream 시스템을 보호하기 위해 reserved concurrency를 설정할 수 있으며, 복원력을 위해 DLQ(SQS) 또는 on-failure destination을 사용할 수 있습니다. - Cross-account/central account: finding이 audit account로 들어오므로, EventBridge rule과 Lambda를 해당 계정의 us-east-1에 배포하여 event source Region과 정렬할 수 있습니다. 흔한 오해: Security Hub의 custom action(option B/C)은 자동 트리거로 혼동되는 경우가 많습니다. custom action은 Security Hub console에서 분석가가 시작하는 워크플로(또는 명시적 API 호출)를 위한 것이지, import 시 자동 실행을 위한 것이 아닙니다. AWS Config rule(option D)은 리소스 구성 compliance를 평가하는 것이며, 서드파티 vulnerability scanner finding이 Security Hub로 import되는 이벤트에 60초 이내로 반응하는 메커니즘으로는 적합하지 않습니다. 시험 팁: - “Security Hub finding에 대해 자동으로 트리거”라면 “Security Hub 이벤트에 대한 EventBridge rule”을 떠올리십시오. - “서버 없음”과 “burst 처리”라면, 수동/console 기반 action보다 EventBridge + Lambda(필요 시 SQS buffering)를 선호하십시오. - 자동화는 이벤트가 생성되는 Region(us-east-1)과 항상 정렬하십시오.
세 개의 Region(us-east-1, us-west-2, eu-west-1)에 걸쳐 AWS Organizations 조직 내 75개의 AWS 계정을 보유한 글로벌 핀테크 기업이, 조직 내 모든 계정에서 발생하는 보안 및 네트워크 이벤트, 해당 계정들에 배포된 모든 AWS Marketplace 파트너 도구의 이벤트, 그리고 온프레미스 데이터 센터 시스템( syslog를 전송하는 1,200대의 Linux 서버와 30대의 방화벽)에서 발생하는 이벤트를 집계하고 정규화할 수 있는 중앙집중식 솔루션이 필요합니다. 또한 데이터를 400일 동안 보관하고, 분석가가 임의의 SQL 쿼리를 실행할 수 있어야 합니다. 어떤 솔루션이 이러한 요구 사항을 가장 효과적으로 충족합니까?
S3 + Glue + Athena는 로그를 중앙화하고 쿼리할 수 있으며, 자체 구축 로그 lake 패턴으로는 유효합니다. 그러나 많은 AWS Marketplace 파트너 도구나 온프레미스 syslog/방화벽 소스 전반에서 이벤트를 본질적으로 정규화하지는 못하며, 각 소스별로 사용자 지정 수집, 파싱, 스키마 매핑을 구축하고 유지관리해야 합니다. 또한 기본 제공 OCSF 정규화를 제공하지 않으므로, 이 규모의 대형 핀테크 환경에서는 효과성이 떨어집니다.
CloudWatch Logs subscription filter를 OpenSearch로 전달하는 방식은 준실시간 검색과 대시보드를 지원하지만, 75개 계정과 온프레미스 로그까지 포함해 400일 보관을 수행하기에는 일반적으로 비용이 높고 운영 부담이 큽니다. OpenSearch는 저비용 장기 보관보다는 인덱싱된 검색에 최적화되어 있습니다. 또한 여러 파트너 도구 및 사용자 지정 소스에서 오는 이질적인 보안/네트워크 이벤트를 일관된 SQL 분석을 위한 공통 스키마로 자동 정규화하지도 않습니다.
Security Lake는 중앙집중식 다중 계정/다중 Region 보안 data lake를 위해 목적에 맞게 설계되었습니다. AWS Organizations에서 delegated administrator를 사용하면 모든 계정/Region 전반의 수집을 활성화하고, S3에 데이터를 저장하며, OCSF로 정규화할 수 있습니다. AWS 소스, AWS Marketplace 파트너 통합, 그리고 사용자 지정 소스(온프레미스 syslog/방화벽 이벤트 포함)를 지원하며, S3 lifecycle policy를 통해 장기 보관 요구 사항을 충족하면서 Athena로 임의의 SQL 쿼리 분석을 수행하도록 설계되었습니다.
SCP는 API 작업을 deny 또는 allow할 수는 있지만, 모든 서비스와 계정 전반에서 특정 S3 bucket으로 로그를 전달하도록 “강제”할 수는 없으며, 구성은 여전히 서비스별로 구현되어야 합니다. 또한 OpenSearch는 S3 로그 파일에 대한 직접적인 SQL 쿼리 엔진이 아니며(이 경우 Athena가 적합), 이 옵션은 AWS Marketplace 도구 및 온프레미스 소스 전반의 정규화 요구 사항도 다루지 않습니다. 기술적으로 부정확하고 요구 사항을 충족하기에 불완전합니다.
핵심 개념: 이 문제는 관리형 data lake 접근 방식을 사용하여 탐지 및 헌팅을 위해 중앙집중식으로 다중 계정/다중 Region 보안 데이터를 집계하고 정규화하는 능력을 평가합니다. 핵심 서비스는 Amazon Security Lake(조직 전체 수집 및 OCSF로 정규화), Amazon S3 기반 보관, 그리고 임의의 SQL 쿼리를 위한 Amazon Athena입니다. 정답인 이유: 옵션 C는 모든 요구 사항과 직접적으로 일치합니다. (1) delegated administrator를 사용하는 AWS Organizations를 통해 75개 계정과 3개 Region 전반의 보안 및 네트워크 이벤트를 집계합니다. (2) 서로 다른 보안 텔레메트리를 표준화하도록 명시적으로 설계된 Open Cybersecurity Schema Framework(OCSF)로 데이터를 정규화합니다. (3) Security Lake의 custom source 메커니즘을 통해 AWS 소스, AWS Marketplace 파트너 통합, 그리고 사용자 지정 소스(온프레미스 syslog/방화벽 로그 포함)로부터의 수집을 지원합니다. (4) 400일 보관 요구 사항을 충족하도록 구성 가능한 lifecycle/retention을 갖춘 S3 백엔드 data lake에 데이터를 저장합니다. (5) 정규화된 OCSF 테이블에 대해 Athena를 사용하여 분석가가 임의의 SQL 쿼리를 실행할 수 있습니다. 주요 AWS 기능 / 모범 사례: Security Lake는 조직 수준의 활성화, cross-account 데이터 액세스 패턴, 그리고 일관된 스키마(OCSF)를 제공하여 도구별 파싱 부담을 줄입니다. 각 로그 유형마다 ETL 파이프라인을 수동으로 구축하고 유지관리할 필요 없이 데이터를 중앙화합니다. 보관은 S3 lifecycle policy(예: 비용 최적화를 위해 S3 Glacier Instant Retrieval/Flexible Retrieval로 전환하면서 400일 보관 충족)로 처리합니다. Athena는 Security Lake 데이터의 네이티브 쿼리 엔진이며, 서버리스 및 쿼리당 과금 분석과 잘 부합합니다. 흔한 오해: A는 S3 + Glue + Athena가 흔한 로그 data lake 패턴이어서 매력적으로 보이지만, 상당한 사용자 지정 ETL과 스키마 관리 없이는 AWS Marketplace 파트너 도구 및 온프레미스 소스 전반에 걸친 “정규화” 요구 사항을 충족하지 못합니다. 이는 자체 구축 SIEM data lake에 가깝습니다. B는 전형적인 OpenSearch 스트리밍 접근 방식이지만, 대규모/비용 측면에서 400일 보관에 적합하지 않고 다양한 소스를 본질적으로 정규화하지도 않습니다. D는 SCP가 설명된 방식으로 “모든 서비스가 로그를 전달하도록 강제”할 수 없고, OpenSearch로 “S3의 파일을 쿼리”하는 것은 주요 패턴이 아니며(이 경우 Athena가 적합), 여전히 정규화가 부족하므로 부적절합니다. 시험 팁: “AWS Organizations + 계정/Region 전반 집계 + 보안 이벤트 정규화 + Athena SQL”을 보면 Amazon Security Lake와 OCSF를 떠올리십시오. 400일 이상의 장기 보관에는 hot indexing 스토어보다 lifecycle policy가 있는 S3 기반 lake를 선호하십시오. 또한 SCP는 작업을 제한하는 것이지 서비스를 구성하거나 로그 전달을 보장하는 것이 아님을 기억하십시오.
한 회사가 Application Load Balancer 뒤에서 AWS Fargate를 사용하는 Amazon ECS에서 컨테이너화된 REST API를 실행하고 있으며, Fargate task의 NGINX access log는 90일 보존 정책이 설정된 Amazon CloudWatch Logs log group으로 전송되고 있다. 어젯밤 보안 팀이 IPv4 address 203.0.113.77을 의심스러운 것으로 표시했으며, 보안 엔지니어는 최소한의 노력으로 지난 7일간의 log를 분석하여 해당 IP에서 발생한 총 요청 수와 접근한 특정 request path(예: /v1/* 및 /admin/*)를 확인해야 한다. 엔지니어는 무엇을 해야 하는가?
오답. 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에는 과도하다.
정답. CloudWatch Logs Insights는 기존 log group을 즉시 query할 수 있으며, 지난 7일로 범위를 지정하고 IP 203.0.113.77로 filter한 뒤, 필요 시 NGINX field를 parse하고 stats/count aggregation을 사용하여 총 요청 수와 접근한 request path(및 path/prefix별 count)를 반환할 수 있다. 이는 incident-response log 분석을 위한 가장 빠르고 설정이 최소인 접근 방식이다.
오답. S3로 export하고 Glue crawler를 실행한 뒤 Glue로 결과를 보는 것은 필요 이상으로 운영 작업이 많다. Glue crawler는 schema를 catalog하는 도구이며, 추가 ETL/filtering logic 없이 “IP를 포함하는 entry만 catalog”하는 것을 본질적으로 수행하지 않는다. 7일 범위에서의 단순 count 및 grouping에는 CloudWatch Logs Insights가 의도된 도구이다.
핵심 개념: 이 문제는 Amazon CloudWatch Logs Insights를 사용한 incident-response log 분석을 평가한다. log는 이미 충분한 보존 기간(90일)으로 CloudWatch Logs에 중앙화되어 있다. 요구 사항은 지난 7일을 빠르게 query하여 (1) 특정 IP에서의 요청 수를 집계하고 (2) 접근한 request path를 나열하는 것이다. 정답이 맞는 이유: CloudWatch Logs Insights는 별도의 analytics pipeline을 구축하지 않고도 CloudWatch Logs를 ad hoc 및 대화형으로 query하도록 설계되었다. 최소한의 노력으로 엔지니어는 지난 7일로 범위를 지정한 query를 실행하고, client IP 203.0.113.77로 filter하며, (필요 시) NGINX access log field를 parse한 뒤, 결과를 집계하여 총 요청 수와 request path별(또는 /v1/ 및 /admin/ 같은 path prefix별) count를 반환할 수 있다. 이는 몇 분 내에 두 가지 출력 요구 사항을 모두 충족하며, data export, 신규 infrastructure, 지속적인 ingestion 비용이 필요 없다. 주요 AWS 기능: CloudWatch Logs Insights는 time-range 선택, filtering, parsing(패턴/regex를 사용하는 parse command), aggregation(stats count() by field)을 지원한다. log group 내 여러 log stream에 걸쳐 query할 수 있으며, 보안 조사(예: 의심스러운 IP activity 식별)에 흔히 사용된다. 중앙화된 logging을 활용해 신속한 탐지/조사를 가능하게 하므로 AWS Well-Architected Security 및 Operational Excellence 원칙과도 부합한다. 흔한 오해: OpenSearch로 streaming(옵션 B)은 강력한 dashboard를 제공할 수 있지만, 일회성 7일 조사에 대해 “최소 노력”이 아니다. domain을 provisioning하고 subscription filter를 구성하며 ingestion을 기다려야 하고(또한 별도 재처리/export 없이는 지난 7일을 소급 포함하지 않는다). S3로 export한 뒤 Glue를 사용하는 것(옵션 D)도 운영 부담이 크고 반복 분석이 느리다. Macie(옵션 A)는 S3에서 민감 데이터 탐지를 위한 서비스이며, application log에서 IP/path 패턴을 query하는 용도가 아니다. 시험 팁: log가 이미 CloudWatch Logs에 있고 최근 기간에 대한 빠른 조사/집계가 목적이라면 기본 선택은 CloudWatch Logs Insights이다. 장기 분석, 복잡한 dashboard, 대규모 cross-source correlation, CloudWatch를 넘어서는 보존이 필요할 때 OpenSearch/S3+Athena/Glue를 선택하되, 즉각적이고 최소 노력의 incident triage에는 적합하지 않다.
한 미디어 분석 스타트업은 AWS Batch(EC2 compute environment)에서 비디오 트랜스코딩 작업을 실행하며, Amazon Elastic Container Registry(Amazon ECR)에서 private container image를 가져옵니다. 현재 두 Region에 걸친 12개의 ECR repository가 기본 AES-256 encryption을 사용하고 있지만, 컴플라이언스 요구 사항에 따라 모든 repository를 customer managed AWS KMS key(alias/media-sec)로 마이그레이션하고 image push 시 CVE detection을 활성화해야 합니다. 보안 엔지니어는 어떤 repository도 unencrypted 상태로 남지 않게 하면서, 다음 image push 이후 vulnerability report를 제공하는 접근 방식을 구현해야 합니다. 어떤 솔루션이 이러한 요구 사항을 충족합니까?
오답입니다. 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” 요구 사항을 충족하지 못합니다.
정답입니다. 각 Region에서 encryption을 customer managed KMS key(alias/media-sec)로 설정하여 repository를 다시 생성하면 모든 repository가 요구되는 CMK로 암호화됩니다. ECR image scanning on push를 활성화하면 다음번 image가 push될 때 ECR이 vulnerability scan을 수행하고 검토 가능한 findings를 scan 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를 제공하지 않습니다.
핵심 개념: 이 문제는 Amazon ECR repository 구성에서 (1) customer managed AWS KMS key(CMK)를 사용한 at rest encryption과 (2) 다음 image push 이후 findings를 생성하는 vulnerability scanning을 테스트합니다. 또한 기존 ECR repository에서 in-place로 변경할 수 있는 것과 없는 것을 간접적으로 테스트합니다. 정답이 맞는 이유: 새 컴플라이언스 규칙 하에서 “어떤 repository도 unencrypted 상태로 남지 않게” 하려면 각 repository가 지정된 CMK(alias/media-sec)를 사용하도록 구성되어야 합니다. ECR에서는 encryption 구성은 repository 생성 시점에 설정되며, 기존 repository를 AES-256(AWS owned key)에서 customer managed KMS key로 in-place로 소급 전환할 수 없습니다. 따라서 컴플라이언스를 만족하는 접근 방식은 각 Region에서 KMS encryption을 alias/media-sec로 설정하여 새 repository를 생성(또는 가능하다면 삭제 후 동일한 이름으로 재생성)하는 것입니다. 또한 “scan on push”를 활성화하면 다음번 image push 이후 ECR이 자동으로 vulnerability scan을 트리거하고 해당 push된 image에 대한 findings report를 생성합니다. 주요 AWS 기능 및 모범 사례: - ECR at rest encryption: AES-256(AWS owned) vs AWS KMS(customer managed key). CMK는 key policy 제어, rotation 옵션, AWS CloudTrail을 통한 감사 가능성을 제공합니다. - ECR image scanning: “scan on push”(basic scanning) 또는 account 설정에 따라 Amazon Inspector를 통한 enhanced scanning. 어느 쪽이든 scan on push를 활성화하면 다음 push 이후 report를 받는 요구 사항을 충족합니다. - Multi-Region: KMS key는 Regional입니다. 두 Region 모두에 alias/media-sec가 존재(또는 생성)해야 하며, ECR이 이를 사용할 수 있는 권한이 있어야 합니다. 흔한 오해: 자주 있는 함정은 일부 다른 서비스처럼 기존 ECR repository에서 “KMS encryption을 활성화”할 수 있다고 가정하는 것입니다. 또 다른 함정은 host 기반 CVE scanning(Inspector Agent/SSM inventory)과 ECR의 container image scanning을 혼동하는 것입니다. 요구 사항은 EC2 instance가 아니라 image push에 연동된 image에 대한 vulnerability report입니다. 시험 팁: “after the next image push”가 보이면 ECR “scan on push”(또는 Inspector enhanced scanning)를 떠올리십시오. “AES-256 default에서 CMK로 encryption 마이그레이션”이 보이면 해당 서비스가 in-place encryption 변경을 지원하는지 확인하십시오. ECR repository의 경우 repository 재생성과 image repush/retag를 마이그레이션의 일부로 계획해야 합니다.
한 fintech 회사의 security engineer는 임시 vendor IAM user가 특정 account에서 테이블을 보고 편집하기 위해 Amazon DynamoDB console에만 액세스할 수 있도록 보장해야 하며, 어떤 상황에서도 다른 AWS services를 사용하지 못하도록 방지해야 합니다. 해당 vendor IAM user는 나중에 광범위한 permissions(예: AdministratorAccess)을 부여하는 하나 이상의 IAM groups에 추가될 수 있지만, 사용자의 effective permissions는 DynamoDB로만 제한된 상태를 유지해야 합니다. 이 요구 사항을 충족하기 위해 security engineer가 취해야 할 접근 방식은 무엇입니까?
DynamoDB access를 허용하는 inline policy는 현재 필요한 permissions를 부여할 수는 있지만, 나중에 group membership이나 다른 attached policies를 통해 추가 permissions를 얻는 것을 막지 못합니다. 사용자가 이후 AdministratorAccess가 있는 group에 추가되면 다른 services에도 액세스할 수 있습니다. Inline policies는 guardrail이 아니라 identity-based permissions의 한 소스일 뿐입니다.
DynamoDB actions만 허용하는 permissions boundary는 사용자가 할 수 있는 일을, 향후 어떤 group memberships나 attached policies가 추가되더라도, 하드한 최대치로 제한합니다. 나중에 AdministratorAccess가 연결되더라도 DynamoDB 밖의 actions는 boundary에서 허용되지 않으므로 계속 deny됩니다. 이는 어떤 상황에서도 다른 AWS services 사용을 방지해야 한다는 요구 사항을 직접 충족합니다.
사용자를 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로 더 잘 충족됩니다.
핵심 개념: 이 문제는 IAM effective permissions와, 향후 group membership과 무관하게 최대 permission set을 강제하는 방법을 평가합니다. 핵심 개념은 IAM permissions boundary로, 이는 IAM principal(user 또는 role)이 받을 수 있는 permissions의 상한을 정의합니다. 정답인 이유: DynamoDB actions만 허용하는 permissions boundary policy는 vendor IAM user가 이후 AdministratorAccess 같은 광범위한 permissions를 가진 groups에 추가되더라도 다른 AWS services를 절대 사용할 수 없도록 보장합니다. IAM evaluation에서는 어떤 action이 identity-based policy에 의해 allowed되어야 하고 동시에 permissions boundary 범위 내에 있어야 합니다. 따라서 DynamoDB가 아닌 action은 boundary 내에서 허용되지 않으므로(implicit deny), group membership을 통한 privilege escalation을 방지합니다. 주요 AWS 기능: Permissions boundaries는 user 또는 role에 연결되는 managed policies로, 최대 permissions에 대한 guardrail을 설정합니다. 이는 delegated administration에 흔히 사용되며 임시 또는 vendor access를 제한하는 데도 사용됩니다. “console에서 테이블을 보고 편집” 요구를 충족하려면 boundary가 관련 DynamoDB actions(예: dynamodb:DescribeTable, dynamodb:UpdateTable, dynamodb:PutItem 등)을 허용해야 하며, 일반적으로 console 사용성을 위해 필요한 read-only actions도 허용해야 합니다(종종 AWS-managed DynamoDB policies 또는 custom least-privilege set을 통해). Resource scoping을 통해 account 내 특정 tables/ARNs로 추가 제한할 수도 있습니다. 흔한 오해: Inline policies 또는 group policies(옵션 A/C)는 permissions를 부여하지만 향후 permissions를 상한으로 제한하지는 못합니다. 나중에 AdministratorAccess를 추가하면 의도와 달리 권한이 확장됩니다. Role에서 explicit deny를 사용하는 전략(옵션 D)은 이론적으로 가능하지만, vendor가 일관되게 role을 assume하는 것에 의존하며, IAM user 자체가 직접 또는 groups를 통해 다른 permissions를 부여받는 것을 막지 못합니다. 시험 팁: 요구 사항에 “나중에 admin groups에 추가되더라도 제한이 유지되어야 함”이 포함되면 permissions boundary(또는 organization 수준의 SCP)를 떠올리십시오. Boundaries는 principal의 최대 permissions를 제한하며, 자체적으로 access를 부여하지는 않습니다—boundary 범위 내에서 DynamoDB permissions를 부여하는 identity-based policies가 별도로 필요합니다.
비디오 스트리밍 회사가 Application Load Balancer 뒤에서 AWS Fargate launch type을 사용하는 Amazon Elastic Container Service (Amazon ECS) cluster에서 썸네일 생성 microservice를 실행하고 있으며, 단일 ASN에서 분당 약 200건의 의심스러운 요청을 탐지한 후 보안 엔지니어는 운영 부담을 최소화하면서 live task를 조사하여 /var/log/app의 application log file을 가져오고 오프라인 분석을 위해 256-MB memory/core dump를 캡처해야 합니다. 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
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에 더 가깝습니다.
ECS Exec는 라이브 ECS task 내부에서 command를 실행하기 위한 AWS-native 기능이며, Fargate launch type을 사용하는 task도 포함됩니다. Host management가 필요 없는 안전하고 감사 가능한 access를 제공하므로, 최소한의 운영 노력이라는 요구 사항에 부합합니다. 연결 후 engineer는 /var/log/app을 검사하고, log file을 archive하여 외부로 복사하고, 적절한 in-container tooling을 실행해 오프라인 분석을 위한 요청된 memory/core dump를 생성할 수 있습니다. 이는 라이브 access와 artifact 수집이라는 두 요구 사항을 직접적으로 해결하며, 다른 선택지는 이를 제공하지 못합니다.
핵심 개념: 이 문제는 AWS Fargate launch type을 사용하는 Amazon ECS service에서 라이브 incident-response 조사를 수행하는 것에 관한 것입니다. Fargate는 host access를 제공하지 않으므로, 관련된 AWS-native 기능은 ECS Exec이며, 이를 통해 workload를 replatforming하지 않고도 실행 중인 container 내부에서 안전하게 command를 실행할 수 있습니다. 정답인 이유: ECS Exec는 기존 Fargate task에서 직접 작동하고 실행 중인 container에 대한 interactive access를 제공하므로 운영 노력 측면에서 가장 적은 솔루션입니다. 해당 session에서 engineer는 /var/log/app을 검사하고, log artifact를 패키징하여 가져오고, container 내부에서 tooling을 실행해 오프라인 분석을 위한 요청된 256-MB memory/core dump를 생성할 수 있습니다. 이는 이전에 export된 telemetry만 검토하는 것이 아니라 라이브 task를 조사해야 한다는 요구 사항을 충족합니다. 주요 기능: ECS Exec는 내부적으로 AWS Systems Manager Session Manager를 사용하며, 실행 중인 ECS task에 대해 감사 가능하고 IAM으로 제어되는 access를 지원합니다. EC2 host, SSH key, bastion host를 관리하거나 launch type migration을 수행할 필요가 없습니다. 이는 Fargate에서 실행되는 container에 대한 운영 access를 위한 표준 AWS 접근 방식입니다. 일반적인 오해: CloudWatch Logs, Container Insights, ADOT는 observability에 도움이 되지만, 라이브 Fargate container에 대한 shell access를 제공하거나 임의의 filesystem artifact와 on-demand memory dump를 수집할 수 있게 해주지는 않습니다. 또 다른 흔한 실수는 Fargate에서 SSH access가 가능하거나 바람직하다고 가정하는 것입니다. 로그인할 수 있는 customer-managed host는 없습니다. 시험 팁: 문제에서 Fargate와 함께 실행 중인 container를 검사하거나 라이브 forensic artifact를 수집해야 한다는 요구가 언급되면, 먼저 ECS Exec를 떠올리세요. 요구 사항이 중앙 집중식 application logging뿐이라면 CloudWatch Logs만으로 충분할 수 있지만, 라이브 triage와 artifact 수집은 ECS Exec를 가리킵니다. 또한 least operational effort 같은 표현도 주의해서 보세요. 이런 표현은 replatforming보다 managed access를 강하게 선호합니다.
한 미디어 스타트업이 CI 빌드 시스템에서 사용되는 IAM user의 plaintext AWS access key와 secret이 포함된 Docker image를 실수로 public registry에 푸시했습니다. 해당 image는 3시간 동안 공개적으로 다운로드 가능했으며, 보안 팀은 지난 24시간 내에 유출된 credentials가 무단으로 사용되었는지 여부를 판단하고, 동시에 해당 credentials의 추가 사용을 즉시 차단해야 합니다. 어떤 단계 조합이 이러한 요구 사항을 충족합니까? (두 개 선택)
Correct. Setting the exposed IAM access key to Inactive immediately prevents any further AWS API requests signed with that key, meeting the “immediately prevent any additional use” requirement. This is standard containment in AWS incident response. After disabling, rotate credentials and remediate the CI system to avoid long-term keys (prefer STS/roles).
Correct. CloudTrail logs API activity and includes the AccessKeyId used for each request, along with eventTime, sourceIPAddress, userAgent, and affected resources (where applicable). Querying Event history or CloudTrail Lake for the specific AccessKeyId over the last 24 hours is the most direct way to determine whether the leaked credentials were used and what actions were performed.
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 user access key에 대한 incident response를 테스트합니다: (1) 추가 오남용을 즉시 중단하기 위한 즉각적인 containment와 (2) 최근에 해당 key가 무엇을 했는지 판단하기 위한 detection/forensics. 주요 AWS 서비스/개념은 IAM access key 관리(비활성화/회전)와 CloudTrail 감사(AccessKeyId로 이벤트 쿼리)입니다. 정답이 맞는 이유: Option A는 즉각적인 containment를 제공합니다. 노출된 access key를 비활성화(Inactive)하면 해당 key로 서명된 추가 AWS API call을 즉시 차단하며, 이는 진행 중인 악용을 멈추는 가장 빠르고 신뢰할 수 있는 방법입니다. Option B는 요구되는 조사 기능을 제공합니다. CloudTrail은 (선택적으로 data event 포함) 사용된 access key, source IP, user agent, AWS service, API action을 포함한 management event를 기록합니다. 지난 24시간 동안 특정 AccessKeyId에 대해 CloudTrail Event history(최근 90일) 또는 CloudTrail Lake를 쿼리하면 credentials가 무단으로 사용되었는지와 어떤 작업이 수행되었는지를 직접적으로 확인할 수 있습니다. 주요 AWS 기능 / Best Practices: - IAM: 손상된 access key의 status를 Inactive로 설정한 다음, credentials를 회전(새 key는 containment 이후에 생성)하고 build pipeline에서 유출된 secret을 제거합니다. CI를 IAM roles/OIDC(예: GitHub Actions) 또는 STS AssumeRole을 통한 short-lived credentials로 전환하는 것을 고려합니다. - CloudTrail: 빠른 triage에는 Event history를 사용하고, 더 풍부한 SQL 쿼리와 더 긴 보존 기간이 필요하면 CloudTrail Lake를 사용합니다. AccessKeyId, eventTime, eventSource, eventName, sourceIPAddress, resources로 필터링합니다. CloudTrail data events(S3 object-level, Lambda invoke 등)를 활성화해 두었다면 조사에 포함합니다. 흔한 오해: 일부는 “증거 수집”을 위해 key를 활성 상태로 유지해야 한다고 생각하지만(Option D), 이는 containment를 위반하고 blast radius를 키웁니다. 또 다른 일부는 IAM credential report(Option E)에 의존하지만, 이는 API call에 대한 forensic log가 아니며 상세 사용 내역을 보여주지 않습니다. GuardDuty는 detector이지 특정 key를 차단하는 예방 통제가 아닙니다(Option C). Exam Tips: 유출된 IAM access key에 대한 시험 패턴은: 먼저 contain(키 비활성화/삭제)하고, 그 다음 CloudTrail에서 AccessKeyId로 조사하는 것입니다. GuardDuty는 의심스러운 동작을 탐지하는 데 도움이 되지만, 확정적인 이벤트 귀속을 위한 CloudTrail을 대체하지 못하며, account boundary에서 특정 access key를 직접 차단할 수도 없습니다.
한 핀테크 회사가 3개 Region에 걸쳐 AWS Fargate에서 600개의 Amazon ECS 서비스를 실행하고 있습니다. 보안 검토 중 엔지니어는 짧은 API PIN(6~10자)이 task definition environment variables에 plaintext로 저장되어 있으며, 런타임에 콘솔과 task metadata에서 확인할 수 있음을 발견했습니다. 이 보안 문제를 해결하는 가장 cost-effective 방법은 무엇입니까?
오답입니다. 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보다 비용이 더 많이 듭니다.
정답입니다. AWS Systems Manager Parameter Store SecureString은 KMS로 secrets를 암호화하며, “secrets” 필드를 통해 ECS task definitions와 직접 통합되어 값이 task definition에 plaintext로 저장되지 않습니다. IAM policies로 ssm:GetParameter(s) 및 kms:Decrypt를 액세스가 필요한 ECS task roles로만 제한할 수 있습니다. 고급 rotation 요구 사항이 없는 단순 secrets에 대해 일반적으로 가장 cost-effective한 managed 접근 방식입니다.
핵심 개념: 이 문제는 AWS Fargate의 Amazon ECS에서 secrets를 안전하게 처리하는 방법을 평가합니다. task definition의 environment variables는 안전한 secret store가 아닙니다. ECS 콘솔에서 볼 수 있고, 런타임에 task metadata endpoints를 통해 조회될 수 있으며, 충분한 ECS/CloudTrail/SSM 액세스 권한이 있는 누구에게나 노출될 수 있습니다. 모범 사례는 secrets를 외부화하고 IAM으로 범위를 제한한 액세스를 사용하여 런타임에 안전하게 주입하는 것입니다. 정답이 맞는 이유: AWS Systems Manager Parameter Store SecureString은 짧은 API PIN과 같은 작은 secrets를 저장하고 ECS tasks에서 런타임에 가져오는 데 가장 cost-effective한 managed 옵션입니다. SecureString은 AWS KMS로 값을 암호화하며, 세분화된 IAM policies를 지원하여 특정 parameters를 읽을 수 있는 주체를 task role(필요한 경우가 아니면 execution role이 아님)로 제한할 수 있습니다. ECS는 container definition의 “secrets” 필드를 통해 Parameter Store와 직접 통합되며, plaintext를 task definition에 두지 않고 값을 environment variables로 container에 주입합니다. 이를 통해 콘솔/task definition에서의 plaintext 노출을 제거하면서도 600개 서비스와 3개 Region 전반에서 운영 오버헤드를 낮게 유지할 수 있습니다. 주요 AWS 기능 및 모범 사례: - customer managed KMS key(또는 AWS managed key)와 least-privilege IAM(ssm:GetParameter(s)를 특정 parameter ARN으로 범위 제한, kms:Decrypt를 해당 key로 범위 제한)을 사용하여 SSM Parameter Store의 SecureString type parameters를 사용합니다. - ECS task definitions에서 “environment” 대신 “secrets”(parameter ARN/name을 참조하는 valueFrom)를 사용합니다. - 역할 분리: task execution role은 launch 시 secrets를 가져오고, task role은 런타임에 애플리케이션이 사용합니다(가져오는 방식에 따라 다름). 애플리케이션 측 호출을 피하기 위해 ECS secret injection을 선호합니다. - parameters는 Region 단위(Parameter Store는 regional)로 복제하고 IaC로 관리합니다. 흔한 오해: “secrets”라는 단어 때문에 Secrets Manager를 기본으로 선택하는 경우가 많지만, per-secret 월 과금과 API call 비용이 있어 3개 Region에 걸친 600개 서비스 규모에서는(특히 서로 다른 PIN이 많이 존재한다면) 비용이 커질 수 있습니다. Step Functions는 orchestration 서비스이지 secret store가 아닙니다. 콘솔에서 IAM으로 environment variables를 “숨기는” 것은 task metadata 또는 다른 조회 경로를 통한 노출을 해결하지 못합니다. 시험 팁: “task definition env vars에 plaintext”가 보이면 해결책은 Secrets Manager 또는 SSM Parameter Store SecureString을 사용하는 ECS secrets integration입니다. 문제가 “MOST cost-effective”를 강조하고 secrets가 단순/정적이라면 일반적으로 Parameter Store SecureString이 최선의 답입니다. rotation, built-in secret lifecycle, 또는 더 높은 수준의 secret 기능이 필요할 때는 Secrets Manager를 선택합니다.