정답 · 해설

해설

【핵심 용어】 ▸ 포렌식 순서 — 휘발성 메모리 수집 → ASG에서 인스턴스 분리(suspend/detach) → 스냅샷, 증거 보존 ▸ 격리용 빈 보안 그룹 — 인바운드·아웃바운드 규칙 없는 SG로 교체해 트래픽 차단(무중단 격리) ▸ NACL 아웃바운드 Deny — 587 포트 이탈 트래픽 차단으로 봉쇄 보강 【정답 포인트】 ▸ "침해 인스턴스 봉쇄 + 포렌식 증거 보존 + 다운타임 최소" → 서브넷 NACL에 587 아웃바운드 Deny 추가 (B) ▸ 휘발성 메모리 수집 후 ASG에서 인스턴스 분리(suspend), 그다음 스냅샷 촬영 (C): 올바른 증거 보존 순서 ▸ 기존 SG를 규칙 없는 새 SG로 교체해 인스턴스 격리 (F) 【오답 체크】 (A) 침해 인스턴스 SG에 아웃바운드 Deny만 추가하는 것은 규칙 없는 SG 교체(F)로 더 확실히 격리되며 A는 세 조합에 불필요. (D) 스냅샷을 먼저 찍고 나중에 휘발성 메모리를 수집하면 메모리 증거가 소실될 수 있어 순서가 잘못됨. (E) 격리 서브넷으로 인스턴스 이동은 실행 중 인스턴스 서브넷 변경이 불가해 비현실적. 【시험 포인트】 침해 대응 순서 = 휘발성 메모리 먼저 → ASG 분리 → 스냅샷. 격리 = 빈 SG 교체 + NACL Deny.

해설

【핵심 용어】 ▸ Elastic Beanstalk 인스턴스 프로파일 — EC2 인스턴스에 부착된 IAM 역할, 앱의 AWS 리소스 접근 권한 ▸ EB 서비스 역할 vs 인스턴스 프로파일 — 서비스 역할은 EB 운영용, 앱의 S3 접근은 인스턴스 프로파일 ▸ S3 접근 문제 — 인스턴스 프로파일 권한 확인이 우선 【정답 포인트】 ▸ "EB의 앱이 S3 버킷 연결 실패" → EC2 인스턴스에서 실행되는 앱은 인스턴스 프로파일 권한 사용 ▸ Elastic Beanstalk 인스턴스 프로파일이 S3 접근 권한을 갖는지 확인 (B) 【오답 체크】 (A) 서비스 역할은 EB 환경 관리용으로 앱 런타임의 S3 접근 권한과 다름. (C) AWSElasticBeanstalkFullAccess는 사용자/배포자 권한이지 인스턴스의 S3 접근 권한이 아님. (D) 기본 구성 동일 계정 버킷은 IAM 권한이 우선 이슈이며 "애플리케이션 ARN" 기반 버킷 정책은 표준 접근 방식이 아님. 【시험 포인트】 EB 앱의 AWS 리소스 접근 실패 = EC2 인스턴스 프로파일 권한 확인(서비스 역할 아님).

해설

【핵심 용어】 ▸ S3 Object Lock — WORM(변경 불가) 방식으로 객체 불변성 보장, 디지털 증거 무결성 유지 ▸ SSE-KMS — KMS 키로 서버 측 암호화, 증거 암호화 요건 충족 ▸ 불변성 + 암호화 동시 충족 — Object Lock + KMS 암호화 조합 【정답 포인트】 ▸ "증거 암호화 + 원본 불변성 유지 + 가장 안전" → S3 Object Lock 활성화 버킷에 업로드 ▸ AWS KMS 서버 측 암호화(SSE-KMS) 적용 (B): 불변성과 암호화를 함께 보장 【오답 체크】 (A) Glacier Vault Lock도 불변성을 제공하나 KMS 암호화 명시가 없고 즉시 접근·관리 측면에서 B가 더 직접적·안전. (C) 버전 관리 + MFA Delete + presigned URL은 불변성 보장이 Object Lock만큼 강하지 않음. (D) EC2 + EBS + 종료 방지·스냅샷은 불변성 WORM을 제공하지 않아 증거 무결성 보장에 부적합. 【시험 포인트】 디지털 증거 불변성 + 암호화 = S3 Object Lock(WORM) + SSE-KMS.

해설

【핵심 용어】 ▸ IMDSv2 — 세션 토큰(PUT) 기반 인스턴스 메타데이터 서비스, SSRF 공격 방어 (IMDSv1은 토큰 없이 조회 가능해 취약) ▸ modify-instance-metadata-options — 실행 중 인스턴스의 메타데이터 옵션 변경 CLI, --http-tokens required로 IMDSv2 강제 ▸ ec2:MetadataHttpTokens 조건 키 — IAM/SCP에서 인스턴스 생성 시 IMDSv2 필수 여부 강제하는 조건 키 ▸ EC2:MetadataNoToken — 토큰 없는 IMDSv1 호출 수를 나타내는 CloudWatch 지표 【정답 포인트】 ▸ (A) IAM 정책으로 ec2:MetadataHttpTokens != required인 RunInstances를 Deny → 신규 인스턴스가 IMDSv1로 뜨는 것을 원천 차단 ▸ (C) modify-instance-metadata-options --http-tokens required → 이미 실행 중인 기존 인스턴스를 IMDSv2 강제로 전환 ▸ 신규(A)+기존(C) 양쪽을 모두 처리해야 마이그레이션 완료, 가용성 리스크 감수 전제와 일치 【오답 체크】 (B) hop-limit 0은 유효하지 않고, 홉 제한은 IMDSv1/v2 강제와 무관. (D) 169.254.169.254로의 아웃바운드를 SG로 막으면 메타데이터 자체를 못 써 애플리케이션 파손, IMDSv2 전환이 아님. (E) 옵션 텍스트가 비어 있어 유효한 조치로 볼 수 없음. 【시험 포인트】 IMDSv2 전면 강제 = "신규 생성 차단(IAM ec2:MetadataHttpTokens)" + "기존 전환(modify-instance-metadata-options --http-tokens required)" 조합.

해설

【핵심 용어】 ▸ Secrets Manager 회전 Lambda — VPC 내 배포된 함수가 DB와 Secrets Manager 양쪽에 접근해 자격 증명 회전 ▸ Interface VPC Endpoint (PrivateLink) — 인터넷 없이 VPC 내부에서 AWS 서비스 API(예: Secrets Manager)에 프라이빗 접근 ▸ NAT Gateway / Egress-only IGW — 인터넷 아웃바운드용, 인터넷 트래픽 금지 요건과 충돌 【정답 포인트】 ▸ "VPC가 인터넷을 통해 송수신 금지" + "Lambda가 Secrets Manager와 통신 불가" → Secrets Manager용 Interface VPC 엔드포인트를 만들고 Lambda 서브넷을 포함시키면 프라이빗 경로로 API 호출 가능 【오답 체크】 (A) Egress-only IGW는 IPv6 인터넷 아웃바운드용, 인터넷 금지 요건 위반이며 Secrets Manager 프라이빗 접근 해결책 아님. (B) NAT Gateway는 인터넷을 경유하므로 "인터넷 트래픽 금지" 정책 위반. (C) 기본 VPC와의 피어링으로는 Secrets Manager 퍼블릭 엔드포인트에 프라이빗 접근 불가, 구성도 부적절. 【시험 포인트】 "인터넷 없이 VPC에서 AWS 서비스 API 호출" → Interface VPC Endpoint(PrivateLink). NAT/IGW는 인터넷 경유라 오답.

해설

【핵심 용어】 ▸ IAM 인스턴스 프로파일 — EC2에 부여되는 역할, S3 GetObject 시 s3:GetObject + s3:ListBucket 등 필요 ▸ KMS 키 정책 — CMK 사용 권한 정의, 암호화 객체 복호화에는 kms:Decrypt 필수 ▸ S3 Gateway Endpoint + Prefix List — VPC 내부 S3 접근 시 SG 아웃바운드에서 S3 관리형 prefix list(443) 허용 필요 【정답 포인트】 ▸ (A) 인스턴스 프로파일에 s3:ListBucket 미허용 → 버킷 나열/객체 접근 실패 원인 ▸ (D) KMS 키 정책이 인스턴스 프로파일 ARN에 kms:Decrypt 미허용 → SSE-KMS 객체 복호화 불가로 GetObject 실패 ▸ (E) SG 아웃바운드 규칙에 S3 관리형 prefix list(443) 없음 → Gateway 엔드포인트 경유 트래픽 차단 【오답 체크】 (B) s3:ListParts는 멀티파트 업로드 조회용, 객체 GetObject 실패 원인 아님. (C) kms:ListKeys는 키 나열용, 객체 복호화와 무관. (F) S3는 아웃바운드로 접근하며 SG는 상태 저장(stateful)이라 인바운드 규칙은 불필요. 【시험 포인트】 SSE-KMS S3 접근 실패 3요소 = IAM(s3:ListBucket) + KMS(kms:Decrypt) + 네트워크(SG 아웃바운드 S3 prefix list 443).

해설

【핵심 용어】 ▸ aws kms encrypt — KMS CMK로 최대 4KB 이하 소량 데이터를 직접 암호화하는 명령 ▸ Envelope Encryption / generate-data-key — 대용량 데이터용, 데이터 키로 로컬 암호화 ▸ create-grant — 임시 위임 권한 부여용, 암호화 동작 아님 【정답 포인트】 ▸ 대상이 2KB(4KB 이하)의 소량 파일 → aws kms encrypt로 기존 CMK를 직접 사용해 암호화하는 것이 가장 단순·적절 【오답 체크】 (B) create-grant은 다른 principal에 CMK 사용을 위임하는 것, 파일 암호화 수행 아님. (C) encrypt 명령은 데이터 키를 생성하지 않음(개념 혼동). (D) generate-data-key는 대용량용 봉투 암호화 방식이며, 암호화된 데이터 키로는 파일을 직접 암호화할 수 없음(평문 키로 암호화해야 함). 【시험 포인트】 4KB 이하 소량 → aws kms encrypt 직접 사용. 4KB 초과 대용량 → generate-data-key 봉투 암호화.

해설

【핵심 용어】 ▸ SCP 리전 제한 — Deny + Condition(aws:RequestedRegion)로 특정 리전 외 배포 차단 ▸ NotAction — Deny 정책에서 이 목록의 액션은 거부에서 제외(전역 서비스 계속 허용) ▸ 글로벌 서비스 — IAM, CloudFront, Route 53 등은 us-east-1(글로벌 엔드포인트)에서 동작해 예외 필요 【정답 포인트】 ▸ 목표는 eu-west-1만 허용하되 S3/Route53/CloudFront/IAM은 계속 사용. S3는 리전 서비스로 eu-west-1에서 정상 동작하므로 NotAction 예외가 불필요 → s3:*를 제거해야 다른 리전 S3까지 차단하면서 eu-west-1 S3는 리전 허용으로 계속 동작 【오답 체크】 (B) iam:*는 글로벌(us-east-1) 서비스라 예외 유지 필요, 제거 시 IAM 사용 불가. (C) cloudfront:*는 글로벌 서비스라 예외 유지 필요. (D) route53:*는 글로벌 서비스라 예외 유지 필요. 【시험 포인트】 리전 제한 SCP에서 NotAction 예외는 글로벌 서비스(IAM/CloudFront/Route53)만 남기고, 리전 서비스(S3)는 제거해도 해당 리전에서 정상 동작.

해설

【핵심 용어】 ▸ AWS Signer — Lambda/컨테이너 코드 서명 및 검증 서비스, 서명 프로파일 기반 ▸ 서명 프로파일(Signing Profile) — 코드 서명에 사용되는 프로파일, 버전 취소(revoke)로 해당 서명 무효화 ▸ 서명 검증(Code Signing Config) — Lambda가 유효 서명 코드만 배포하도록 강제 【정답 포인트】 ▸ "그 개발자가 작성한 코드를 더 이상 Lambda에 배포 불가하게" → 해당 개발자에게 할당된 서명 프로파일의 모든 버전을 revoke하면 그 프로파일로 서명된 코드는 검증 실패로 배포 차단 【오답 체크】 (B) IAM에서 Signer 권한 제거는 향후 서명 행위만 막을 뿐, 이미 서명된 기존 코드 배포는 계속 유효. (C) KMS로 재암호화는 코드 서명/배포 차단과 무관. (D) CodeGuru 프로파일링은 성능/품질 분석 도구, 배포 차단 기능 없음. 【시험 포인트】 "특정 서명 코드의 배포를 무효화" → AWS Signer 서명 프로파일 버전 revoke.

해설

【핵심 용어】 ▸ ACM 인증서 — 무료 공용 인증서, ALB/CloudFront 등 관리형 통합 리소스에 직접 연결(EC2 설치·내보내기 불가) ▸ Application Load Balancer (ALB) — L7, HTTPS(443) 리스너에 ACM 인증서 연결해 TLS 종료 ▸ Network Load Balancer (NLB) — L4, TLS 리스너로 ACM 인증서 사용 가능하나 EC2 직접 연결 방식은 불가 【정답 포인트】 ▸ 공용 웹앱 + SSL/TLS + ACM 사용 → EC2를 ALB 뒤에 두고 ALB에 HTTPS/443 리스너로 ACM 인증서를 연결하는 것이 표준 (ACM 인증서는 ALB에서 직접 사용) 【오답 체크】 (B) 인증서를 EC2 인스턴스에 직접 연결하는 방식은 ACM 통합 방식이 아님(ACM 인증서는 EC2에 설치 불가). (C) NLB는 L4로 웹(HTTPS) 애플리케이션 종료에 부적합하고 서술도 부정확. (D) ALB는 맞지만 인증서를 EC2에 연결한다는 부분이 틀림(ALB에 연결해야 함). 【시험 포인트】 ACM 인증서는 내보내기·EC2 설치 불가, ALB/CloudFront 등에 직접 연결. HTTPS 웹앱 → ALB + ACM(443).

해설

【핵심 용어】 ▸ NLB Health Check — 대상 인스턴스 상태 확인, 실패 시 InService 진입 불가 ▸ NLB 특성 — 트래픽 소스가 NLB 노드/클라이언트 IP, 대상 SG는 소스 IP 범위(또는 VPC CIDR)를 허용해야 함 ▸ Network ACL — 서브넷 레벨 무상태 필터, 헬스 체크 트래픽 차단 가능 【정답 포인트】 ▸ (A) 대상 인스턴스 SG가 NLB로부터의 트래픽을 허용하지 않음 → 헬스 체크 실패 ▸ (D) 대상 서브넷의 네트워크 ACL이 NLB 트래픽을 허용하지 않음 → 차단 ▸ (E) 대상 SG가 IP 주소 기반으로 NLB 트래픽을 허용하도록 구성되지 않음 → NLB는 SG를 소스로 참조 불가하므로 IP/CIDR로 허용 필요 【오답 체크】 (B) NLB에 대상 인스턴스 SG를 "부착"하는 개념이 없음. (C) NLB 자체 SG를 대상에 붙이는 개념이 없어 원인이 될 수 없음. (F) 네트워크 ACL은 NLB에 부착하는 것이 아니라 서브넷에 연결됨. 【시험 포인트】 NLB 헬스 체크 실패 원인 = 대상 SG(IP 기반 허용) + 서브넷 NACL 허용 여부. NLB는 SG 참조가 아닌 IP로 허용해야 함.

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — OU/계정 단위 권한 상한(guardrail) 설정, 특정 위험 액션 차단 ▸ OU(Organizational Unit) — 데이터 분류/유형별 계정 그룹화로 확장성 있는 정책 적용 ▸ 위임 IAM 역할(delegated role) — 최소 권한으로 다른 IAM principal을 프로비저닝하는 위임 관리 패턴 【정답 포인트】 ▸ (A) SCP로 고위험/미승인 액션 차단 → 보안 가드레일 제공하면서 개발 자율성 보존 ▸ (C) 다른 역할을 만들 수 있는 위임 IAM 역할로 최소 권한 프로비저닝 → 확장성·자율성 균형 ▸ (D) 데이터 분류/유형별 OU 구성 후 계정 배치 → 분류별 정책 적용으로 확장성 극대화 【오답 체크】 (B) 조직 내 모든 principal에 단일 permissions boundary를 일괄 부여하는 방식은 다양한 분류/자율성에 부적합하고 확장성 저하. (E) 계정마다 IAM 그룹을 수동 구성하는 방식은 확장성이 떨어짐(계정별 반복 작업). (F) 계정마다 IAM 정책을 수동 관리하는 방식도 확장성 부족. 【시험 포인트】 조직 규모 가드레일 = SCP(상한) + OU(분류별 그룹화) + 위임 역할(최소 권한 프로비저닝). 계정별 수동 그룹/정책은 확장성 부족으로 오답.

해설

【핵심 용어】 ▸ Lambda 환경 변수 — 콘솔에서 평문 노출 가능, 민감 정보 저장에 부적합 ▸ SSM Parameter Store SecureString — KMS 암호화 파라미터, 소량 비밀 저장에 저비용(표준 파라미터 무료) ▸ Secrets Manager — 자동 회전 지원하나 시크릿당 월 과금으로 상대적 고비용 【정답 포인트】 ▸ "민감 정보가 짧고 다수" + "가장 비용 효율적" → SSM Parameter Store SecureString에 저장 후 런타임 조회, IAM으로 접근 제한. 회전 요건 없이 소량 비밀에는 Parameter Store가 가장 저렴 【오답 체크】 (A) IAM 정책으로 환경 변수를 숨길 수 없음(여전히 평문 저장). (B) Step Functions는 환경 변수 저장소가 아님, 부적절. (C) Secrets Manager도 가능하나 시크릿당 과금으로 수천 개 함수에 비용 효율성이 떨어짐(회전 불필요). 【시험 포인트】 비밀 저장 비용 비교: 회전 필요 없고 저비용 → Parameter Store SecureString. 자동 회전 필요 → Secrets Manager.

해설

【핵심 용어】 ▸ Route 53 Resolver Query Logging — Resolver를 통한 DNS 쿼리를 로깅(소스 인스턴스 IP, 쿼리 도메인 포함) ▸ 대상: CloudWatch Logs / S3 / Kinesis Firehose — 쿼리 로그 전송처 ▸ CloudWatch Logs Insights — 로그에 대해 소스 IP·DNS 이름 등 쿼리 분석 【정답 포인트】 ▸ "온프렘 포워딩 DNS 트래픽 로깅 + 소스 인스턴스 IP + 요청 DNS 이름" → Route 53 Resolver 쿼리 로깅을 VPC에 구성해 CloudWatch Logs로 전송, Insights로 쿼리 → 요구 필드 정확히 제공 【오답 체크】 (A) VPC Traffic Mirroring는 과도하게 복잡하고 amazon-dns 필터/구성이 요건에 부적합. (B) VPC 플로우 로그는 IP/포트 메타데이터만 담고 DNS 쿼리 이름을 기록하지 못함. (D) Resolver 규칙 수정으로는 로깅이 되지 않음, 서술 부정확. 【시험 포인트】 "DNS 쿼리 이름 + 소스 인스턴스 IP 로깅" → Route 53 Resolver Query Logging. 플로우 로그는 DNS 이름을 담지 못함.

해설

【핵심 용어】 ▸ SAML 페더레이션 / IAM Identity Provider — IdP 메타데이터(인증서 포함)를 IAM IdP 엔터티에 등록 ▸ IdP 인증서 회전 — 회전 후 IAM에 새 메타데이터 반영 안 하면 서명 검증 실패(Response Signature Invalid) ▸ 이중 인증서(secondary certificate) — 만료 전 미리 새 인증서를 추가해 무중단 회전 【정답 포인트】 ▸ (C) IdP에서 새 SAML 메타데이터 파일을 받아 기존 IAM IdP 엔터티에 업로드 → 즉시 서명 검증 오류 해결(엔터티 재생성 불필요) ▸ (B) 다음 회전 주기에 만료 전 secondary 인증서를 IdP에 추가하고 새 메타데이터를 엔터티에 업로드 → 재발 방지(무중단 회전) 【오답 체크】 (A) 새 IdP 엔터티를 만드는 것은 불필요하고 신뢰 설정을 새로 해야 해 과함(기존 엔터티 업데이트로 충분). (D) secondary 인증서 취지는 맞으나 새 엔터티 생성이 불필요. (E) 새 엔터티 생성 + assertion에 엔터티명 전달은 SAML 흐름상 부정확하고 과도. 【시험 포인트】 SAML 서명 검증 오류(인증서 회전 후) → 기존 IAM IdP 엔터티에 새 메타데이터 업로드. 재발 방지 → 만료 전 secondary 인증서 사전 등록.

해설

【핵심 용어】 ▸ CloudWatch Agent (VPC 내 EC2) — 로그 전송에 인스턴스 프로파일 권한 + 엔드포인트 경로 필요 ▸ VPC Endpoint(모니터링/로그) — IGW 없는 서브넷에서 CloudWatch API 프라이빗 접근, 엔드포인트 정책이 접근 제어 ▸ 에이전트 구성 파일 — 수집 대상 로그 파일 경로 지정, 잘못되면 로그 미수집 【정답 포인트】 ▸ (A) 인스턴스 프로파일에 로그 스트림 생성/쓰기 권한이 있는지 확인 → 권한 없으면 로그 미전송 ▸ (C) 각 인스턴스의 CloudWatch 에이전트 구성 파일이 올바른 로그 파일을 수집하는지 확인 ▸ (D) 두 VPC 엔드포인트의 정책이 인스턴스의 사용을 허용하는지 확인 → 엔드포인트 정책이 막으면 전송 실패 【오답 체크】 (B) 메트릭 필터는 로그를 콘솔에서 보기 위한 것이 아니며 로그 미표시 원인과 무관. (E) 이미 VPC 엔드포인트가 있으므로 NAT 게이트웨이 추가는 불필요(인터넷 경유도 요건에 반함). (F) 인스턴스 간 통신은 CloudWatch로의 로그 전송과 무관. 【시험 포인트】 VPC 엔드포인트 경유 CloudWatch 로그 미표시 → IAM 권한 + 에이전트 설정 파일 + 엔드포인트 정책 3요소 점검.

해설

【핵심 용어】 ▸ SSH 키 영구 설치 금지 + IAM 사용자 접근 → 키 없는 관리형 셸 필요 ▸ Systems Manager Session Manager — SSM 에이전트 기반 브라우저/CLI 셸, SSH 키·인바운드 포트 불필요, IAM으로 접근 제어·감사 로깅 ▸ Run Command / Inventory — 각각 명령 실행·자산 인벤토리용, 대화형 SSH 세션 아님 【정답 포인트】 ▸ "SSH 키 영구 설치 금지" + "IAM 사용자에게 SSH 세션 제공" → Session Manager 사용, IAM 권한으로 접근 부여 (키·포트 개방 없이 대화형 세션) 【오답 체크】 (A) Inventory는 소프트웨어/구성 자산 수집 기능, 대화형 접속 불가. (B) Run Command는 스크립트/명령 실행용이며 SSH 연결을 여는 방식이 아님. (D) 콘솔 EC2 SSH 클라이언트(ec2-user)는 결국 키 기반 접속으로 요건(키 미설치) 위배. 【시험 포인트】 "SSH 키 없이 IAM 기반 셸 접근·감사" → Systems Manager Session Manager.

해설

【핵심 용어】 ▸ AWS WAF Web ACL — ALB에 부착, 애플리케이션 계층(L7) 트래픽 필터링 ▸ Rate-based Rule — 지정 시간당 요청 수 초과 IP를 자동 차단, 브루트포스/봇 완화에 즉효 ▸ ALB 리스너 규칙 / Lambda 로그 처리 — 수동/사후 처리로 즉시성 낮음 【정답 포인트】 ▸ "여러 IP의 브루트포스" + "가장 빠른 완화" → ALB에 WAF Web ACL을 만들고 rate-based 규칙을 추가해 요청 임계 초과 IP를 자동 차단 【오답 체크】 (A) Lambda가 ALB 로그를 분석해 SG에 IP 차단은 사후 처리로 느리고 운영 부담 큼. (C) 리스너 규칙에 고정 IP/경로 조합은 변하는 다수 봇 IP에 대응 불가. (D) rate-based 규칙을 별도 rule group에 넣어 붙이는 구성은 불필요하게 복잡, 웹 ACL에 직접 추가가 더 빠름(정답 B가 최단). 【시험 포인트】 "다수 IP 브루트포스 즉시 완화" → WAF rate-based rule을 Web ACL에 직접 추가. Lambda/SG 사후 차단은 느림.

해설

【핵심 용어】 ▸ Secrets Manager 리소스 정책 — 시크릿에 직접 부착, principal 접근 제어 ▸ ABAC(태그 기반 접근 제어) — aws:PrincipalTag / aws:ResourceTag 조건으로 태그 매칭 시 접근 허용, principal 변경에 유연·확장적 ▸ RBAC(역할 기반) / deny-by-default 그룹 관리 — principal 잦은 변경 시 유지보수 부담 큼 【정답 포인트】 ▸ "접근 principal이 자주 변경" + "유연성·확장성 극대화" → 태그 기반(ABAC) 접근: 시크릿에 리소스 정책 부착, 시크릿·principal에 태그 부여, PrincipalTag/ResourceTag 조건으로 제어 (정책 수정 없이 태그만으로 확장) 【오답 체크】 (A) 역할 신뢰 정책의 principal 목록을 매번 수정하는 방식은 잦은 변경에 유지보수 부담. (B) VPC 엔드포인트 정책은 principal 목록을 계속 갱신해야 해 확장성 낮음. (D) 그룹에서 principal을 넣고 빼는 deny 관리 방식은 오류 유발·비확장적. 【시험 포인트】 "접근 대상이 자주 바뀌고 확장성 필요" → 태그 기반 ABAC(PrincipalTag/ResourceTag). principal 목록 직접 관리는 비확장적.

해설

【핵심 용어】 ▸ 암호화 트래픽 심층 패킷 검사(DPI) → 먼저 TLS 종료(복호화)가 필요 ▸ Network Load Balancer TLS 종료 — L4에서 TLS 종료 후 복호화된 트래픽을 다음 검사 지점으로 전달 ▸ AWS Network Firewall — 상태 저장 심층 패킷 검사(DPI) 제공 (WAF은 L7 웹 규칙, 범용 DPI 아님) 【정답 포인트】 ▸ "암호화 트래픽 심층 패킷 검사" → NLB로 TLS 종료(복호화)한 뒤 복호화 트래픽을 AWS Network Firewall 엔드포인트로 보내 DPI 수행 【오답 체크】 (A) ALB + Network Firewall 조합은 ALB→Network Firewall 트래픽 전달 흐름이 표준 구성이 아님. (C) WAF는 HTTP(L7) 웹 요청 규칙 검사로 범용 심층 패킷 검사가 아님. (D) 마찬가지로 WAF는 DPI 도구가 아니라 부적합. 【시험 포인트】 "암호화 트래픽 DPI" = TLS 종료(복호화) + AWS Network Firewall(심층 패킷 검사). WAF는 L7 웹 규칙이라 DPI 아님.