퀴즈: mutate 와 generate

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

1. 추가 앵커 `+(cpu): 200m` 의 동작으로 옳은 것은?

   1. cpu 값이 200m 과 같은지 검사해서 다르면 그 요청을 거부한다
   2. cpu 키를 지워서 네임스페이스의 기본값이 적용되게 한다
   3. 값이 이미 있든 없든 cpu 를 항상 200m 으로 덮어쓴다
   4. cpu 가 없을 때만 200m 을 넣고, 이미 있으면 건드리지 않는다

2. 컨테이너 개수가 정해지지 않은 파드의 모든 컨테이너에 같은 값을 넣어야 합니다. 적절한 방식은?

   1. patchesJson6902 로 `/spec/containers/0` 부터 인덱스를 늘려 가며 넣는다
   2. foreach 로 `request.object.spec.containers` 를 돌며 element 를 쓴다
   3. patchStrategicMerge 로 containers 배열을 통째로 새로 써서 교체한다
   4. generate 규칙으로 값이 채워진 컨테이너를 필요한 만큼 새로 만든다

3. 레지스트리 시크릿을 여러 네임스페이스에 배포할 때 `data` 대신 `clone` 을 쓰는 이유는?

   1. 정책 파일은 보통 git 에 들어가므로 시크릿 내용을 정책에 적으면 그대로 유출되기 때문
   2. clone 은 원본이 바뀌어도 사본이 알아서 따라가 동기화 설정이 필요 없기 때문
   3. clone 이 값을 직접 적는 방식보다 리소스 생성 속도가 훨씬 빠르기 때문
   4. data 방식은 ConfigMap 만 만들 수 있고 Secret 은 지원하지 않기 때문

4. `generate.synchronize: true` 를 켰을 때의 동작은?

   1. 생성 시점에 한 번만 만들고 이후에는 관여하지 않는다
   2. 트리거 네임스페이스가 지워져도 생성물은 남는다
   3. 생성된 리소스를 누가 고치면 정책이 원래 상태로 되돌린다
   4. 생성 대신 검증만 수행한다

5. 생성 정책을 걸었는데 요청은 성공하는데 리소스가 만들어지지 않습니다. 가장 먼저 의심할 것은?

   1. 백그라운드 컨트롤러에 그 리소스 종류를 만들 RBAC 권한이 없는 것
   2. 트리거 리소스의 이름이 너무 길어 생성될 이름이 한도를 넘긴 것
   3. `synchronize: true` 가 켜져 있어 생성이 뒤로 보류된 것
   4. 정책 YAML 의 들여쓰기가 어긋나 generate 규칙이 무시된 것

6. `mutate.targets` 를 쓰는 규칙의 성격으로 옳은 것은?

   1. 요청으로 들어온 트리거 리소스 자신을 어드미션 단계에서 곧바로 고친다
   2. validate 규칙에만 붙일 수 있고 mutate 규칙에서는 쓰지 못한다
   3. 정책이 바뀌면 이미 존재하는 대상 전체를 자동으로 다시 고쳐 준다
   4. 트리거가 아닌 다른 리소스를 고치며, 백그라운드에서 돌기 때문에 추가 권한이 필요하다

7. 차트 기본값으로 두어야 할 값을 변형 정책으로 넣었을 때 생기는 문제는?

   1. 변형 규칙에는 통과·실패 판정이 없어 PolicyReport 에 아무런 기록도 남지 않게 된다
   2. 매니페스트와 실제 오브젝트가 달라져 배포 도구의 드리프트 감지와 계속 충돌하고, 나중에 누가 넣었는지 추적하기 어렵다
   3. 채워 넣을 기본값 수만큼 규칙이 늘어 모든 요청의 정책 평가 시간이 함께 길어진다
   4. 차트 기본값을 대신하는 변형은 검증 규칙보다 나중에 실행되어 아예 걸러지지 않는다