퀴즈: 정책 예외와 리포트

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. `Audit` 모드의 성격으로 옳은 것은?

   1. 위반 요청을 거부하되 리포트나 로그에는 아무것도 남기지 않는 상태
   2. 어드미션 판정은 그대로 두고 백그라운드 스캔만 꺼 두는 설정
   3. 판정은 그대로 일어나되 위반 요청을 통과시키고 리포트에 기록만 하는 상태
   4. 정책을 등록만 해 두고 평가 자체를 하지 않는 보류 상태

2. 새 정책을 프로덕션에 도입하는 순서로 가장 적절한 것은?

   1. Enforce 로 먼저 배포 → 막히는 것이 나올 때마다 그때그때 예외 처리 → 안정화
   2. Audit 으로 배포하고 리포트 관찰 → 고칠 수 있는 것 수정 → 못 고치는 것만 좁은 예외 → Enforce 전환
   3. 예상되는 예외를 먼저 전부 만들어 둠 → Enforce 로 배포 → 남은 예외 정리
   4. 개발 클러스터에서만 Enforce 로 검증 → 프로덕션에는 아예 배포하지 않고 유지

3. 어드미션 단계만으로는 부족해 백그라운드 스캔이 필요한 이유는?

   1. 어드미션은 앞으로 들어올 요청만 보므로 이미 클러스터에 있는 리소스는 아무도 다시 검사하지 않기 때문
   2. 백그라운드 스캔만이 정책 YAML 의 문법과 스키마를 대신 검사해 주기 때문
   3. 어드미션 웹훅이 느려서 무거운 규칙은 백그라운드로 미뤄 두어야 하기 때문
   4. 어드미션 단계는 Audit 모드를 지원하지 않아 관찰 자체가 불가능하기 때문

4. `PolicyReport` 와 `ClusterPolicyReport` 의 차이는?

   1. 전자는 네임스페이스 범위 리소스의 결과를, 후자는 클러스터 범위 리소스의 결과를 담는다
   2. 전자는 Audit 모드의 결과를, 후자는 Enforce 모드의 결과를 담는다
   3. 전자는 CRD 로 조회되고 후자는 컨트롤러의 로그 파일로만 남는다
   4. 전자는 통과한 판정만 담고 후자는 실패한 판정만 모아 담는다

5. PolicyException 에서 `ruleNames` 를 생략하고 정책 전체를 면제하면 생기는 문제는?

   1. 그 리소스가 앞으로 그 정책에 추가되는 모든 규칙에서도 빠진다
   2. 그 리소스에 한해 정책 전체가 Audit 모드로 내려간다
   3. 그 정책의 판정 결과가 리포트에서 통째로 사라진다
   4. 규칙 이름이 없으면 예외 자체가 등록되지 않는다

6. 정책 도입 작업의 진척을 가장 잘 나타내는 지표는?

   1. 리포트의 summary.fail 이 시간이 지나며 줄어들어 남은 예외 건수에 수렴하는 것
   2. 작성해서 클러스터에 올린 정책과 규칙이 모두 몇 개까지 늘었는지
   3. 어드미션 웹훅의 평균 응답 시간이 목표치까지 얼마나 짧아졌는지
   4. PolicyException 을 몇 개나 만들어 예외 처리를 끝냈는지

7. 예외 관리에서 실무적으로 가장 어려운 부분은?

   1. 예외와 정책을 한 파일에 둘지 나눌지 정하는 것
   2. 예외의 match 블록 문법을 정확히 적는 것
   3. 만들어 둔 예외를 다시 지우는 절차를 유지하는 것
   4. 하나의 예외를 여러 네임스페이스에 걸치게 적는 것