정답 · 해설

해설

【핵심 용어】 ▸ CloudTrail → CloudWatch Logs 메트릭 필터 — 보안 그룹 변경 로그 패턴을 메트릭으로 변환 ▸ CloudWatch 알람 + 알림 액션(SNS) — 메트릭 임계 초과 시 알림 발송 ▸ 파이프라인 점검 순서 — 메트릭 필터 → 알람 → SNS 액션 연결 확인 【정답 포인트】 ▸ "보안 그룹 변경을 했는데 알람이 안 옴" → 메트릭 필터가 실제로 생성되어 알람에 매핑됐는지, 알람의 알림 액션(SNS 등)이 제대로 설정됐는지 확인 (B) 【오답 체크】 (A) S3 버킷 액세스 로깅은 이 알림 파이프라인과 무관. (C) 대시보드 메트릭·디멘션 확인은 알림 트리거(메트릭 필터→알람→SNS)의 핵심 점검 지점이 아님. (D) GetMetricStatistics/ListMetrics 권한은 조회용이며 알람 통지 실패 원인과 무관. 【시험 포인트】 "CloudTrail 기반 알람 미작동" → 메트릭 필터 생성·알람 매핑·SNS 액션 연결 여부 점검.

해설

【핵심 용어】 ▸ SSM Parameter Store SecureString — KMS로 저장 시 암호화, 표준 파라미터는 추가 비용 없음(무료) ▸ Secrets Manager — 시크릿당 월 요금 발생(자동 교체 기능 제공) ▸ Lambda에서 SDK로 파라미터 조회 — 런타임에 복호화된 값 획득 【정답 포인트】 ▸ "액세스 토큰을 저장 시 암호화 + 런타임 전달 + 가장 비용 효율적" → Parameter Store SecureString에 저장하고 Lambda가 SDK로 조회 (C). KMS 암호화 저장 + 표준 파라미터 무료로 최저 비용. 【오답 체크】 (A) Secrets Manager는 동일 기능이나 시크릿당 요금이 있어 "가장 비용 효율적"에 밀림(자동 교체가 불필요한 경우). (B) 토큰 기반 Lambda 오소라이저는 API 게이트웨이 요청 인가용이지 토큰을 저장·복호화 전달하는 요건과 다름. (D) KMS로 암호화한 값을 환경 변수로 넘기면 환경 변수 자체는 콘솔/노출 위험이 있고 관리가 번거로움. 【시험 포인트】 "저장 시 암호화 + 최저 비용 시크릿 저장" → Parameter Store SecureString(무료), 교체 필요 시 Secrets Manager.

해설

【핵심 용어】 ▸ Lambda@Edge origin response 이벤트 — 오리진 응답 시점에 실행되어 두 오리진(EC2·S3) 모두의 응답 헤더를 일괄 처리 ▸ X-Frame-Options 헤더 — 클릭재킹/프레임 관련 공격 방지용 응답 헤더 ▸ viewer request vs origin response — request 이벤트는 요청 단계라 응답 헤더 추가와 무관 【정답 포인트】 ▸ "전체 스택(EC2·S3 두 오리진)의 응답에 X-Frame-Options 추가" → Lambda@Edge를 CloudFront origin response 이벤트에서 실행해 응답에 헤더 삽입 (A). 두 오리진 응답을 CloudFront 계층에서 일괄 처리. 【오답 체크】 (B) viewer request 이벤트는 클라이언트 요청 단계로 응답 헤더를 추가할 수 없음. (C) CloudFront 오리진 설정의 커스텀 헤더는 CloudFront→오리진 요청에 붙는 헤더이지 사용자에게 가는 응답 헤더가 아님. (D) EC2 앱만 수정하면 S3 오리진 응답은 여전히 헤더가 누락되어 "전체 스택 준수" 미달. 【시험 포인트】 "모든 오리진 응답에 헤더 추가" → Lambda@Edge origin response 이벤트.

해설

【핵심 용어】 ▸ EC2 인스턴스 역할(Instance Profile) — 인스턴스가 SQS 접근에 사용하는 IAM 권한 ▸ SQS 리소스 정책 — 큐 차원에서 명시적 Deny가 있으면 역할 권한이 있어도 차단됨 ▸ 최소 권한 유지 — FullAccess 부여나 액세스 키 사용은 지양 【정답 포인트】 ▸ "IAM 변경 후 SQS 메시지 수신 불가, 최소 권한 유지 문제 해결" → SQS 리소스 정책이 해당 역할에 명시적 Deny를 걸고 있지 않은지 확인 (B), 인스턴스 역할에 큐 접근을 허용하는 정책이 있는지 확인 (E) 【오답 체크】 (A) 역할에 MFA 디바이스 할당은 EC2 인스턴스 역할 사용 방식이 아니며 트러블슈팅과 무관. (C) 역할은 액세스 키가 아니라 임시 자격증명을 사용 → "역할의 액세스 키" 개념 자체가 부정확. (D) AmazonSQSFullAccess 부여는 문제를 가릴 수 있으나 최소 권한 원칙 위배. 【시험 포인트】 "권한 문제 트러블슈팅(최소 권한)" → 역할의 허용 정책 확인 + 리소스 정책의 명시적 Deny 확인.

해설

【핵심 용어】 ▸ 가져온 키 자료(Imported Key Material) — 자동 키 교체(automatic rotation) 미지원 ▸ 수동 키 교체 — 새 KMS 키 생성 + 새 키 자료 임포트 + 별칭(alias)을 새 키로 전환 ▸ 별칭(Alias) — 애플리케이션이 키를 참조하는 안정적 이름, 교체 시 별칭만 옮기면 무중단 【정답 포인트】 ▸ "가져온 키 자료 CMK를 매년 교체" → 가져온 키 자료는 자동 교체를 지원하지 않으므로, 새 CMK를 만들고 새 키 자료를 임포트한 뒤 별칭을 새 키로 가리키게 함(수동 교체) (D) 【오답 체크】 (A) 가져온 키 자료 키는 자동 키 교체를 켤 수 없음. (B) 자동/수동 교체를 위한 Lambda 커스텀 구현은 표준 절차가 아니고 불필요. (C) 기존 키에 새 키 자료를 임포트한다고 키가 "교체"되는 것이 아님(같은 키 ID, 매년 교체 요건 미충족). 【시험 포인트】 "가져온 키 자료 교체" → 새 키 생성·새 자료 임포트·별칭 전환(수동 교체).

해설

【핵심 용어】 ▸ SCP(Service Control Policy) — Organizations에서 계정 전반의 최대 권한을 제한하는 예방적 가드레일, 확장성 우수 ▸ s3:DeleteBucket 차단 — 조직 전 계정 사용자에게 버킷 삭제 금지 ▸ 확장성 — 계정이 늘어도 OU/루트에 한 번 적용으로 전파 【정답 포인트】 ▸ "조직 전역에서 S3 버킷 삭제 금지 + 가장 확장 가능" → SCP로 s3:DeleteBucket을 거부 (D). 조직/OU 단위 한 번 적용으로 모든 현재·미래 계정에 강제. 【오답 체크】 (A) Permissions Boundary는 계정별 IAM 주체마다 적용해야 해 조직 전역 강제엔 확장성 낮음. (B) 버킷 정책은 버킷마다 설정해야 하므로 다수 계정·버킷에 비효율. (C) Tag 정책은 태그 표준화용이지 삭제 차단 통제가 아님. 【시험 포인트】 "조직 전역 행동 차단(확장성)" → SCP.

해설

【핵심 용어】 ▸ GuardDuty EKS Audit Log Monitoring — EKS 감사 로그를 분석해 비인가 접근 등 위협 탐지, 별도 EKS 구성 불필요 ▸ 관리형 위협 탐지 — GuardDuty가 로그를 자동 수집·분석(에이전트/추가 설정 최소) ▸ 최소 운영 노력 — 기존 EKS 배포를 변경하지 않음 【정답 포인트】 ▸ "EKS 비인증 접근 탐지 + 기존 EKS 추가 구성 없이 최소 노력" → GuardDuty를 켜고 EKS Audit Log Monitoring 사용 (D). GuardDuty가 감사 로그를 자동 분석. 【오답 체크】 (A) 서드파티 EKS 애드온 설치는 추가 구성·운영 부담이 큼. (B) Security Hub는 findings 집계용으로, EKS 비인가 접근을 직접 탐지하는 소스가 아님(탐지는 GuardDuty가 함). (C) Container Insights는 성능/리소스 모니터링 메트릭이지 위협 탐지가 아님. 【시험 포인트】 "EKS 위협/비인가 접근 탐지(무설정)" → GuardDuty EKS Audit Log Monitoring.

해설

【핵심 용어】 ▸ VPC Flow Logs — 서브넷/ENI의 허용·거부 트래픽을 기록, REJECT 레코드로 차단된 시도 식별 ▸ NACL Deny 후 시도 탐지 — 차단된 아웃바운드(포트 2905)를 REJECT 레코드로 확인 ▸ 최소 운영 노력 — 기존 VPC에 Flow Logs만 켜면 됨 【정답 포인트】 ▸ "NACL로 차단한 포트 2905 통신을 시도하는 EC2 식별 + 최소 노력" → 해당 VPC에 VPC Flow Logs를 켜고 거부 트래픽을 캡처, REJECT 레코드 중 목적지 TCP 2905를 검색해 발신 인스턴스 식별 (B) 【오답 체크】 (A) Network Access Analyzer는 잠재적 접근 경로 분석 도구로 실제 트래픽 시도 로그를 보여주지 않음. (C) GuardDuty 커스텀 IP 리스트 + Detective 구성은 설정 부담이 크고 이 목적엔 과함. (D) Network Firewall를 새로 배포·규칙 구성하는 방식은 운영 노력이 훨씬 큼. 【시험 포인트】 "차단된 트래픽 시도 인스턴스 식별" → VPC Flow Logs의 REJECT 레코드.

해설

【핵심 용어】 ▸ Macie 자동 민감 데이터 탐지(Automated Discovery) — 다수 버킷을 지속적으로 샘플링해 민감 데이터 보유 버킷을 식별 ▸ 전체 스캔(Full Scan) — 민감 데이터가 발견된 버킷에 집중 심층 스캔 ▸ 최소 관리 부담 — 대량 버킷을 일일이 전수 스캔하지 않고 우선순위화 【정답 포인트】 ▸ "많은 버킷 중 민감 데이터 보유 버킷 식별 후 추가 스캔 + 최소 관리 부담" → Macie 자동 탐지로 버킷을 지속 샘플링해 민감 데이터를 찾고, 해당 버킷만 전체 스캔 (C) 【오답 체크】 (A) CRR로 다른 리전에 복제해 스캔하는 방식은 스토리지·복제 비용과 복잡도가 큼. (B) 업로드마다 Lambda로 객체별 스캔을 트리거하는 방식은 대량 버킷/객체에 운영 부담이 큼. (D) 전 버킷을 스캔해 DynamoDB에 집계하는 방식은 우선순위화 없이 전수 스캔이라 비효율. 【시험 포인트】 "민감 데이터 우선 식별 후 심층 스캔" → Macie 자동 탐지(샘플링) + 대상 버킷 전체 스캔.

해설

【핵심 용어】 ▸ AWS PrivateLink 엔드포인트 서비스 — NLB 뒤 서비스를 다른 계정에 인터넷 노출 없이 프라이빗 제공 ▸ 인터페이스 엔드포인트 — 소비자(자회사) 계정에서 서비스로 프라이빗 연결 ▸ 1,500개 CIDR 문제 — 보안 그룹/NACL 규칙 수 한도로 대규모 CIDR 관리 비현실적 【정답 포인트】 ▸ "1,500 자회사만 접근 + 공용 인터넷 비노출 + NLB" → 부모 계정 NLB에 PrivateLink 엔드포인트 서비스를 만들고, 인스턴스 보안 그룹은 그 엔드포인트에서 오는 443만 허용, 각 자회사는 인터페이스 엔드포인트로 연결 (C). CIDR 나열 없이 계정 단위 프라이빗 접근. 【오답 체크】 (A) NACL은 규칙 수 한도가 있어 1,500개 CIDR를 담을 수 없고 인스턴스에 직접 연결 불가(서브넷 단위). (B)(D) 보안 그룹도 규칙 수 한도가 있어 1,500개 CIDR 관리가 비현실적이고 공용 노출 우려. 【시험 포인트】 "다수 계정에 프라이빗 서비스 제공(대규모 CIDR 회피)" → PrivateLink 엔드포인트 서비스.

해설

【핵심 용어】 ▸ Amazon Inspector — EC2·컨테이너·Lambda의 소프트웨어 취약점(CVE)과 의도치 않은 네트워크 노출을 지속 스캔 ▸ 하이브리드 스캐닝(Hybrid Scanning) — 에이전트 기반 + 에이전트리스 스캔 조합으로 지속 평가 ▸ GuardDuty — 위협 탐지(악성 활동)용으로 취약점 스캔 도구가 아님 【정답 포인트】 ▸ "EC2의 소프트웨어 취약점 + 의도치 않은 네트워크 노출 지속 스캔" → Amazon Inspector, 스캔 모드는 하이브리드 (A). Inspector가 CVE와 네트워크 도달성(노출)을 함께 평가. 【오답 체크】 (B)(D) GuardDuty는 위협/이상 행위 탐지로 취약점·네트워크 노출 스캔 목적과 다름. (C) Inspector에는 "Malware Protection" 기능이 없음(멀웨어 보호는 GuardDuty 기능) → 조합 오류. 【시험 포인트】 "소프트웨어 취약점 + 네트워크 노출 스캔" → Amazon Inspector.

해설

【핵심 용어】 ▸ AWS Config 관리형 규칙 restricted-ssh — 보안 그룹이 0.0.0.0/0에서 SSH를 허용하는지 준수 평가 ▸ EventBridge Config 규정 준수 변경 이벤트 — 규칙의 compliance 상태 변화를 실시간 이벤트로 발행 ▸ 근실시간 알림 — 이벤트 → SNS 【정답 포인트】 ▸ "restricted-ssh 위반 시 근실시간 알림" → AWS Config의 규정 준수 상태 변경 이벤트를 매칭하는 EventBridge 규칙을 만들고 SNS를 타깃으로 통지 (B) 【오답 체크】 (A) Config 스냅샷을 S3에 보내 Lambda로 파싱하는 방식은 복잡하고 근실시간성이 떨어짐. (C) Config 알림을 CloudWatch Logs로 보내 메트릭 필터·알람을 거는 방식은 불필요하게 복잡. (D) restricted-ssh용 CloudWatch 메트릭에 직접 알람을 거는 방식은 표준 구성이 아님(Config는 이벤트로 통지). 【시험 포인트】 "Config 규칙 준수 변경 근실시간 알림" → EventBridge Config compliance change 이벤트 + SNS.

해설

【핵심 용어】 ▸ IAM(온프레미스 AD 페더레이션) — 실제 사용자·비밀번호는 온프레미스 AD가 관리, IAM 비밀번호 정책은 IAM 사용자에만 적용 ▸ Cognito 사용자 풀 — 자체 비밀번호 정책(최소 길이 등) 설정 ▸ 비밀번호 정책 적용 위치 — 각 자격증명 소스별로 별도 설정 【정답 포인트】 ▸ "온프레미스 AD 페더레이션 + Cognito 두 IdP의 최소 비밀번호 길이 강제": ▸ Cognito 사용자 풀은 Cognito 구성에서 비밀번호 길이 정책 설정 (B) ▸ 페더레이션된 AD 사용자의 비밀번호는 온프레미스 AD가 관리하므로 AD에서 정책 설정 (C) 【오답 체크】 (A) IAM 비밀번호 정책은 IAM 사용자에만 적용, 페더레이션 AD 사용자에는 미적용 → 요구 미충족. (D) SCP로 비밀번호 길이를 강제할 수 없음(권한 제어용이지 비밀번호 정책 아님). (E) IAM 정책 조건으로 비밀번호 최소 길이를 강제하는 방법은 존재하지 않음. 【시험 포인트】 "IdP별 비밀번호 정책" → Cognito는 Cognito에서, 페더레이션 AD는 AD 원본에서 설정.

해설

【핵심 용어】 ▸ KMS 가져온 키 자료 삭제 — 키가 사용 불가(PendingImport) 상태가 되어 암호화된 데이터 키 복호화 불가 ▸ EBS 암호화 데이터 키 — CMK로 래핑되어 있어 CMK가 살아 있어야 복호화 가능 ▸ 삭제 이전 스냅샷 복구 — 키 자료 삭제 전에 확보한 상태에서 데이터 복원 【정답 포인트】 ▸ "가져온 키 자료가 삭제되어 데이터 키 복호화 불가, 데이터가 필요" → 키 자료 삭제 이전에 만든 스냅샷에서 EBS 볼륨을 복원 (B). 원본 키 자료를 더 이상 보유하지 않는 상황에서 데이터를 되살리는 실질적 방법. 【오답 체크】 (A) 새(다른) 키 자료를 임포트해도 기존 데이터 키를 복호화할 수 없음(원본과 동일해야 함). (C) 정확히 동일한 원본 키 자료를 다시 임포트하면 이론상 복호화가 가능하나, 원본 자료를 더 이상 보유하지 않으면 불가 → 문제 상황에서 신뢰할 수 없는 방법. (D) 완전히 새 키·새 자료를 만드는 방식은 기존 암호화 데이터와 무관해 복호화 불가. 【시험 포인트】 "삭제된 가져온 키 자료 + 데이터 복구" → 삭제 이전 스냅샷에서 복원(원본 자료 재보유가 불확실할 때).

해설

【핵심 용어】 ▸ ALB 액세스 로그 → S3 — ALB는 액세스 로그를 S3 버킷에 저장(직접 CloudWatch/OpenSearch 전송 아님) ▸ Amazon Athena — S3의 로그를 SQL로 서버리스 분석 ▸ Amazon QuickSight — 분석 결과 시각화 대시보드 【정답 포인트】 ▸ "ALB 액세스 로그 분석 + 알려진 IP의 봇 로그인 시각화" → ALB 로그를 S3에 저장하고 Athena로 분석, QuickSight로 시각화 (D). ALB 로깅의 표준 파이프라인. 【오답 체크】 (A) ALB 액세스 로그를 CloudWatch Logs로 직접 보내는 기능은 없음(로그는 S3로 감). (B) ALB 액세스 로그를 Redshift로 직접 보내는 기능도 없음. (C) ALB 액세스 로그를 OpenSearch로 직접 보내는 기능도 없음(중간 처리 필요) → "직접 전송" 전제가 틀림. 【시험 포인트】 "ALB 액세스 로그 분석·시각화" → S3 저장 → Athena 쿼리 → QuickSight.

해설

【핵심 용어】 ▸ aws kms encrypt — KMS에 직접 데이터를 보내 암호화, 평문 4KB 이하만 지원 ▸ Envelope Encryption(generate-data-key) — 큰 데이터용, 데이터 키를 생성해 로컬 암호화 ▸ 2KB 파일 — 4KB 미만이므로 KMS encrypt로 직접 처리 가능 【정답 포인트】 ▸ "2KB 파일 암호화" → 4KB 이하이므로 aws kms encrypt로 기존 CMK를 사용해 직접 암호화 (A). 별도 데이터 키 생성 불필요. 【오답 체크】 (B) create-grant는 임시 권한 위임용이지 파일 암호화 동작이 아님. (C) aws kms encrypt로는 "데이터 키를 생성"하지 않음(그 역할은 generate-data-key) → 절차 오류. (D) generate-data-key는 유효하지만 2KB 소량 파일엔 과하고, "암호화된 데이터 키로 파일을 암호화"한다는 서술은 봉투 암호화 절차와 맞지 않음(평문 데이터 키로 암호화해야 함). 【시험 포인트】 "4KB 이하 소량 암호화" → aws kms encrypt 직접. "대용량" → generate-data-key(봉투 암호화).

해설

【핵심 용어】 ▸ Athena SQL — S3의 웹 로그를 SQL로 조회, LIKE로 URL 경로 패턴 매칭 ▸ HTTP 403 Forbidden — 접근이 거부(권한 없음)된 상태 코드(실패한 접근 시도) ▸ /admin 경로 필터 — client_request LIKE '%/admin%' 【정답 포인트】 ▸ "/admin 접근을 시도했으나 실패(403)한 IP와 시도한 URL 식별" → client_ip와 client_request를 함께 선택하고, WHERE client_request LIKE '%/admin%' AND server_status = '403' (A). 실패한 접근은 403, 시도 URL은 client_request로 반환. 【오답 체크】 (B) SQL에 CONTAINS 연산자는 없음(LIKE 사용). 401은 인증 실패 코드로 문제의 "제한 콘텐츠 접근 거부(403)"와 다르고 client_request(URL)를 선택하지 않음. (C) server_status='403'만 필터하고 /admin 경로 조건이 없어 요구를 정확히 충족 못 함. (D) user_id 조건·401 사용으로 /admin 경로 및 403 실패 접근 식별 요건과 어긋남. 【시험 포인트】 "제한 경로 접근 거부 식별" → LIKE '%/admin%' AND server_status='403', IP·요청 URL 함께 선택.

해설

【핵심 용어】 ▸ Cognito API 감사 — CloudTrail이 cognito-idp.amazonaws.com 이벤트를 기록 ▸ InitiateAuth 이벤트 — 로그인(인증) 시도, 성공·실패 모두 CloudTrail에 기록 ▸ CloudTrail → S3 → Athena — 로그를 S3에 배달하고 Athena로 쿼리 【정답 포인트】 ▸ "Cognito 로그인 성공·실패 캡처 + 쿼리" → CloudTrail을 S3로 배달하고 Athena로 eventName=InitiateAuth, eventSource=cognito-idp.amazonaws.com를 쿼리 (B). InitiateAuth가 로그인 시도에 해당. 【오답 체크】 (A) Cognito가 사용자 활동 로그를 CloudWatch로 보내는 표준 경로가 아니고, SignUp은 회원가입 이벤트이지 로그인 시도가 아님. (C) SignUp은 로그인이 아니며, CloudTrail을 CloudWatch로 보내 쿼리하는 방식은 대상 이벤트가 어긋남. (D) CloudWatch 메트릭 대시보드는 로그인 시도의 개별 기록 쿼리에 부적합하고 InitiateAuth를 메트릭으로 조회하는 구성이 부정확. 【시험 포인트】 "Cognito 로그인 시도 기록·쿼리" → CloudTrail InitiateAuth 이벤트 → S3 → Athena.

해설

【핵심 용어】 ▸ CloudTrail SSE-KMS 로그 암호화 — 로그 파일은 KMS 키로 암호화, 읽으려면 KMS 복호화 권한 필요 ▸ 다이제스트 파일(Digest File) — 로그 무결성 검증용, KMS로 암호화되지 않아 KMS 권한 없이도 읽힘 ▸ KMS 키 정책 — 복호화(kms:Decrypt) 권한 부여 위치 【정답 포인트】 ▸ "다이제스트는 읽히는데 로그 파일은 안 읽힘" → 로그 파일은 SSE-KMS로 암호화돼 있어 복호화하려면 KMS 권한이 필요한데, KMS 키 정책이 해당 IAM 사용자/역할에 복호화 권한을 주지 않아 읽지 못함 (B). 다이제스트는 KMS 암호화 대상이 아니라 읽힘. 【오답 체크】 (A) 무결성 검증 실패로 파일이 자동으로 "읽기 불가"가 되는 동작은 존재하지 않음. (C) 버킷 기본 암호화가 SSE-S3라도 SSE-KMS 파일 업로드를 막지 않으며, 증상(다이제스트만 읽힘)과 무관. (D) IAM 정책이 "CloudTrail/" 접두사를 거부한다면 다이제스트도 못 읽어야 함 → 증상과 모순. 【시험 포인트】 "SSE-KMS 로그만 못 읽음" → KMS 키 정책의 kms:Decrypt 권한 누락.

해설

【핵심 용어】 ▸ AWS Service Catalog + CloudFormation — 승인된 아키텍처(제품/포트폴리오)를 조직 계정에 배포·통제 ▸ 포트폴리오 배포 — 조직 전 계정에 승인된 패턴만 프로비저닝 허용 ▸ AWS Config 규칙 — 태그 요구사항·리소스 구성 정책을 계정 전반에 강제/평가 【정답 포인트】 ▸ "승인된 CloudFormation IaC 패턴 관리 + 태깅/구성 지침 강제(전 계정)" → Service Catalog로 승인 아키텍처를 관리하고 포트폴리오를 조직 계정에 배포, Config 규칙으로 태깅·구성 정책 강제 (D) 【오답 체크】 (A) CloudFormation 스택 정책은 스택 내 리소스 업데이트 보호용이지 승인 패턴·태깅 전사 강제 도구가 아님. (B) CodePipeline+Config+SCP도 가능해 보이나 "승인된 아키텍처 패턴 셀프서비스 관리"의 정석은 Service Catalog이며 SCP만으로 세부 태깅/구성 강제엔 한계. (C) Permissions Boundary는 IAM 권한 상한 제어용으로 태깅·리소스 구성 표준 강제 수단이 아님. 【시험 포인트】 "승인된 IaC 아키텍처 셀프서비스 배포·통제" → Service Catalog + CloudFormation + Config 규칙.