测验：在抵达集群之前就拦下来

어드미션 컨트롤만으로는 부족해 IaC 계획 단계에도 정책을 거는 이유는?

• 어드미션은 변형 단계 이후만 보므로 원본 매니페스트를 검사할 방법이 없기 때문
• 보안 그룹이나 버킷 같은 변경은 쿠버네티스 API 를 지나지 않아 어드미션이 볼 자리에 오지 않기 때문
• 어드미션 웹훅은 초당 처리량이 낮아 대량 변경을 처리하지 못하기 때문
• 계획 단계에서 막지 않으면 어드미션이 같은 자원을 두 번 평가해 중복 거부가 생기기 때문

계획 JSON 에서 자원 교체(replace)는 어떻게 표현되는가?

• actions 가 ["replace"] 라는 전용 값 하나로 표현된다
• actions 는 ["update"] 이고 replace 여부는 별도의 불리언 필드로 표시된다
• actions 가 ["delete", "create"] 또는 ["create", "delete"] 두 원소 배열로 표현된다
• actions 에는 나타나지 않고 resource_drift 배열에만 기록된다

계획 JSON 의 after_unknown 이 뜻하는 것은?

• after 와 같은 구조에서 적용해야 알 수 있는 잎 값만 true 로 남기고 아는 값은 빠진 객체
• 적용 중 오류로 끝난 자원의 목록과 그 오류 메시지를 담은 객체
• 이전 계획과 이번 계획 사이에서 값이 달라진 필드만 모아 둔 차이 객체
• 프로바이더 스키마에 없는 필드가 코드에 적혔을 때 경고로 모이는 객체

필수 태그 검사를 after.tags 만 보고 썼더니 특정 모듈에서 전부 위반으로 떴다. 원인으로 가장 알맞은 것은?

• 태그 값이 프로바이더 기본값으로 채워져 계획 JSON 에서 통째로 생략되었다
• 태그는 resource_changes 가 아니라 configuration 객체에만 기록되어 after 에는 원래 없다
• 모듈 안의 자원은 address 에 module 접두가 붙어 정책이 자원을 찾지 못했다
• 그 모듈이 태그를 계산해서 넣기 때문에 값이 계획 단계에 아직 없고 after_unknown 에만 나타났다

정책 도구를 CI 게이트로 붙일 때 종료 코드만 믿으면 안 되는 이유는?

• 종료 코드는 셸에 따라 값이 달라져 같은 결과가 파이프라인마다 다르게 읽히기 때문
• 정책 도구는 관례상 위반 건수를 종료 코드로 돌려주므로 128건이 넘으면 값이 넘치기 때문
• 위반을 찾고도 0 으로 끝나는 도구가 실제로 있어서, 그 경우 파이프라인이 영원히 초록불이 되기 때문
• 종료 코드는 마지막 명령의 것만 남아 파이프 앞쪽 명령의 실패가 항상 가려지기 때문

보고서를 파싱하는 게이트에서 파싱 결과가 비어 있지 않은지까지 확인해야 하는 이유는?

• 빈 결과는 도구가 아직 실행 중이라는 뜻이라 조금 기다렸다가 다시 읽어야 하기 때문
• 도구를 판올려 보고서 키가 바뀌면 파싱이 늘 빈 결과를 내고 위반 0건으로 읽히기 때문
• 보고서가 비어 있으면 정책 파일이 문법 오류라는 뜻이라 즉시 실패시켜야 하기 때문
• 빈 결과는 검사 대상 파일이 하나도 없다는 뜻이라 입력 경로를 다시 계산해야 하기 때문