퀴즈: validate 정책

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

1. 패턴에서 `team: "?*"` 가 뜻하는 것은?

   1. team 라벨 값이 정확히 물음표여야 한다
   2. team 라벨은 있어도 되고 없어도 된다
   3. team 라벨이 없어야 한다
   4. team 라벨이 있고 값이 비어 있지 않아야 한다

2. `preconditions` 와 `validate.deny.conditions` 의 차이로 옳은 것은?

   1. deny 는 참이면 규칙을 건너뛰고, preconditions 는 거짓이면 요청을 거부한다
   2. 둘은 적는 문법만 다를 뿐 평가 결과도 리포트에 남는 모습도 완전히 같다
   3. preconditions 는 거짓이면 규칙 자체를 건너뛰고, deny 는 참이면 규칙이 실행된 결과로 거부한다
   4. preconditions 는 mutate 규칙에서만 쓸 수 있고 validate 에서는 못 쓴다

3. 부정 앵커 `X(privileged)` 의 의미는?

   1. privileged 가 있으면 경고만 남긴다
   2. privileged 키가 존재하면 안 된다
   3. privileged 값이 false 여야 한다
   4. privileged 값이 무엇이든 상관없다

4. 새 검증 정책을 만들고 통과하는 리소스로만 테스트했습니다. 이때 놓치는 위험은?

   1. 거부 메시지가 너무 길어져 API 응답에서 뒷부분이 잘리는 것
   2. 통과 사례만 있으면 background 스캔이 자동으로 꺼지는 것
   3. 같은 리소스가 어드미션과 백그라운드에서 두 번 평가되는 것
   4. 매치 범위가 잘못돼 아무것도 매칭하지 않는 정책과 구분할 수 없는 것

5. `validate.failureAction` 이 정책 수준에서 규칙 수준으로 내려온 덕분에 가능해진 것은?

   1. 같은 정책을 네임스페이스마다 서로 다른 강제 수준으로 적용할 수 있게 됐다
   2. 규칙마다 서로 다른 match 블록을 두어 대상 범위를 나눌 수 있게 됐다
   3. 한 정책 안에서 어떤 규칙은 Enforce, 다른 규칙은 Audit 으로 둘 수 있다
   4. Audit 으로 둔 규칙도 심각도가 높으면 요청을 거부할 수 있게 됐다

6. 이미 돌고 있는 워크로드가 새 정책에 걸릴 때 가장 적절한 대응은?

   1. 정책 전체를 다시 Audit 으로 되돌려 두고 위반 목록이 저절로 줄기를 기다린다
   2. 그 네임스페이스를 정책의 match 에서 통째로 빼서 앞으로 만들 것까지 제외한다
   3. 정책을 일단 삭제했다가 걸린 워크로드를 전부 고친 다음 다시 만들어 올린다
   4. PolicyException 으로 정책 이름·규칙 이름·리소스 이름까지 좁혀 예외를 남기고 목록을 줄여 나간다

7. 거부 메시지를 공들여 쓰는 실용적 이유는?

   1. 거부 메시지를 근거로 PolicyException 이 자동으로 만들어지기 때문
   2. 메시지가 길수록 정책 평가와 리포트 기록 속도가 함께 느려지기 때문
   3. 배포가 막힌 사람이 볼 수 있는 것은 그 한 줄뿐이라 스스로 고칠 수 있느냐가 여기서 갈리기 때문
   4. message 필드가 비어 있으면 정책 등록 단계에서 거부되기 때문