KCA — Kyverno 인증 어소시에이트 · 모의고사 · 퀴즈

KCA 모의고사 A

LabHub 에서 이어서 보기

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

Policy 와 ClusterPolicy 의 차이로 옳은 것은?
1. Policy 는 validate 만 쓸 수 있고 ClusterPolicy 는 mutate 까지 쓸 수 있습니다
2. Policy 는 백그라운드 스캔을 지원하지 않습니다
3. ClusterPolicy 는 네임스페이스 리소스에는 적용되지 않습니다
4. Policy 는 자신이 속한 네임스페이스에만, ClusterPolicy 는 클러스터 전체에 적용됩니다
Kyverno 가 admission 웹훅을 등록하는 방식으로 옳은 것은?
1. 정책 내용에 따라 검증용과 변경용 웹훅 설정을 만들고 필요한 리소스만 대상으로 좁힙니다
2. 모든 리소스에 대해 항상 고정된 웹훅 하나만 등록합니다
3. 웹훅을 쓰지 않고 컨트롤러가 주기적으로 폴링합니다
4. API 서버 설정 파일을 직접 수정해 등록합니다
Kyverno 규칙에서 match 블록이 하는 일은?
1. 규칙 위반 시 사용자에게 보여 줄 메시지를 정의합니다
2. 정책이 적용될 클러스터를 선택합니다
3. 이 규칙이 평가될 리소스의 범위를 정합니다
4. 여러 규칙의 실행 순서를 지정합니다
컨테이너 이미지에서 태그와 다이제스트의 차이로 옳은 것은?
1. 태그는 언제나 불변이고 다이제스트는 재빌드 때마다 갱신될 수 있습니다
2. 태그는 나중에 다른 이미지를 가리키도록 바뀔 수 있지만 다이제스트는 내용에서 계산되어 바뀌지 않습니다
3. 둘 다 레지스트리가 임의로 부여하는 식별자입니다
4. 다이제스트는 레지스트리마다 달라져 이식성이 없습니다
하나의 Kyverno 규칙에 대한 설명으로 옳은 것은?
1. 한 규칙에 validate 와 mutate 를 함께 넣어 순서대로 실행할 수 있습니다
2. 규칙 이름은 선택 사항이라 생략할 수 있습니다
3. 한 규칙은 하나의 동작만 가지며 여러 동작이 필요하면 규칙을 나눕니다
4. 규칙은 ClusterPolicy 안에서만 정의할 수 있습니다
Kyverno 가 정책 평가 결과를 클러스터에 남기는 방식으로 옳은 것은?
1. 이벤트로만 남기고 별도 오브젝트는 만들지 않습니다
2. 네임스페이스 범위와 클러스터 범위의 정책 보고서 리소스에 결과를 기록합니다
3. 위반 내용을 ConfigMap 에 누적해 저장합니다
4. 감사 로그 파일에만 기록하므로 kubectl 로는 볼 수 없습니다
Kyverno 의 cleanup 컨트롤러가 담당하는 일은?
1. 정책 보고서에서 오래된 항목을 지웁니다
2. 실패한 웹훅 설정을 제거합니다
3. 종료된 파드의 로그를 정리합니다
4. 조건에 맞는 리소스를 정해진 일정에 따라 삭제합니다
요청이 Kyverno 웹훅에 도달한 시점에 이미 끝나 있는 단계는?
1. 사용자 인증과 RBAC 인가 심사입니다
2. 오브젝트를 etcd 에 저장하는 일입니다
3. 스케줄러가 파드에 노드를 배정하는 일입니다
4. kubelet 이 컨테이너를 시작하는 일입니다
정책을 별도 언어가 아니라 쿠버네티스 리소스로 표현하는 것이 주는 이점은?
1. 정책이 API 서버 없이도 항상 평가될 수 있습니다
2. 기존 kubectl 과 RBAC, GitOps 흐름을 그대로 써서 정책을 다룰 수 있습니다
3. 정책 평가 속도가 언제나 더 빠릅니다
4. 정책을 컴파일해 바이너리로 배포할 수 있습니다
Deployment 를 대상으로 한 정책이 있는데 직접 만든 파드는 막히지 않았습니다. 원인으로 가장 적절한 것은?
1. Kyverno 는 Deployment 를 대상으로 삼을 수 없습니다
2. 웹훅 타임아웃이 짧아 요청이 통과했습니다
3. 정책이 감사 모드로 설정되어 있었습니다
4. 직접 만든 파드는 Deployment 를 거치지 않으므로 Pod 도 대상에 포함해야 합니다
설치 시 kube-system 같은 네임스페이스를 기본적으로 제외하는 이유는?
1. 그 네임스페이스에는 검사할 파드가 없기 때문입니다
2. 정책 보고서의 용량을 줄이기 위해서입니다
3. 클러스터 핵심 구성 요소가 웹훅 때문에 기동하지 못하는 상황을 피하기 위해서입니다
4. 해당 네임스페이스는 RBAC 으로 이미 충분히 보호되기 때문입니다
Kyverno 를 Helm 으로 설치할 때 사용자 정의 리소스 정의는 어떻게 다뤄지나요?
1. 차트가 함께 설치하며, 업그레이드 시에는 정의 갱신이 제대로 반영됐는지 따로 확인해야 합니다
2. 컨트롤러가 기동하면서 스스로 만들어 냅니다
3. 쿠버네티스에 내장되어 있어 설치할 필요가 없습니다
4. 첫 정책을 만들 때 자동으로 생성됩니다
고가용성 구성으로 Kyverno 를 설치할 때 권장되는 사항은?
1. 컨트롤러 레플리카를 셋 이상 두고 노드에 흩어지도록 배치 규칙을 겁니다
2. 레플리카를 하나로 두고 노드 장애 시 손으로 옮깁니다
3. 모든 컨트롤러를 같은 노드에 모아 지연을 줄입니다
4. 웹훅 실패 정책을 무시로 바꿔 가용성을 확보합니다
정책이 늘어난 뒤 admission 컨트롤러가 반복해서 재시작합니다. 가장 먼저 조정할 것은?
1. 모든 정책의 실패 동작을 감사 모드로 바꿉니다
2. 웹훅 타임아웃을 최대치로 늘립니다
3. 컨트롤러의 메모리 요청과 상한을 올리고 캐시 관련 설정을 점검합니다
4. 클러스터의 노드 수를 늘립니다
generate 규칙으로 사용자 정의 리소스를 만들려 합니다. 권한을 주는 방법으로 옳은 것은?
1. 정책에 서비스 어카운트 이름을 적으면 필요한 권한이 자동으로 생깁니다
2. Kyverno 파드에 최고 관리자 권한을 부여하는 방법뿐입니다
3. 관리자 kubeconfig 를 시크릿으로 넣어 줍니다
4. 역할 집계에 참여하는 ClusterRole 을 만들어 필요한 리소스 권한을 더합니다
Kyverno 컨트롤러의 동작을 배포 시점에 바꾸는 수단으로 옳은 것은?
1. 정책 리소스의 spec 에 컨트롤러 설정을 적습니다
2. 컨테이너 인자로 넘기는 플래그와 Kyverno 설정 ConfigMap 을 사용합니다
3. API 서버의 admission 플러그인 목록을 수정합니다
4. 사용자 정의 리소스 정의의 스키마에 기본값을 넣습니다
Kyverno 를 여러 마이너 버전 건너뛰어 올리려 합니다. 권장되는 방식은?
1. 차트 버전만 최신으로 지정해 한 번에 올립니다
2. 기존 설치를 지우고 새로 설치하면 정책도 그대로 남습니다
3. 릴리스 노트의 지원 경로를 확인하고 한 단계씩 올리며 정의 변경을 반영합니다
4. 컨트롤러 이미지 태그만 바꿔 재시작합니다
Kyverno 를 설치한 직후 일부 워크로드 생성이 실패했습니다. 가장 유력한 원인은?
1. 웹훅은 등록되었는데 컨트롤러가 아직 준비되지 않아 요청이 거절되었습니다
2. 사용자 정의 리소스 정의가 설치되지 않아 파드 생성이 막혔습니다
3. 정책 보고서 리소스가 가득 찼습니다
4. 릴리스 이름이 명명 규칙에 맞지 않았습니다
Kyverno 웹훅이 사용하는 TLS 인증서에 대한 설명으로 옳은 것은?
1. 관리자가 직접 발급해 시크릿으로 넣어야만 동작합니다
2. 기본적으로 스스로 관리되며 만료 전에 갱신되고, 필요하면 외부 발급 인증서로 바꿀 수 있습니다
3. 인증서 없이 평문으로 통신합니다
4. 서비스 어카운트 토큰이 인증서를 대신합니다
특정 네임스페이스를 모든 정책 대상에서 클러스터 차원으로 제외하려면?
1. 정책마다 exclude 블록을 하나씩 추가하는 방법뿐입니다
2. 해당 네임스페이스에 레이블을 붙이면 자동으로 제외됩니다
3. 웹훅 설정 오브젝트를 손으로 편집해 제외합니다
4. Kyverno 설정 ConfigMap 의 리소스 필터에 해당 네임스페이스를 추가합니다
여러 레플리카로 띄운 백그라운드 컨트롤러가 같은 작업을 중복 수행하지 않는 이유는?
1. 레플리카마다 담당 네임스페이스가 자동으로 나뉘기 때문입니다
2. 작업이 멱등이라 중복 수행해도 결과가 같기 때문입니다
3. 리더 선출로 한 인스턴스만 실제 처리를 맡기 때문입니다
4. API 서버가 중복 요청을 걸러 주기 때문입니다
Kyverno 를 제거할 때 주의할 점은?
1. 웹훅 설정과 정의가 남으면 요청이 계속 막히거나 정책 오브젝트가 남을 수 있으므로 정리 순서를 확인해야 합니다
2. 제거하는 즉시 클러스터의 모든 파드가 다시 생성됩니다
3. 제거한 뒤에도 기존 정책이 계속 강제됩니다
4. 제거하면 mutate 로 바뀐 값이 원래대로 되돌아갑니다
Kyverno CLI 를 설치하는 방법으로 적절한 것은?
1. 클러스터에 CLI 파드를 배포하고 들어가서 실행합니다
2. kubectl 플러그인 이름을 바꾸면 자동으로 활성화됩니다
3. Helm 차트를 설치하면 로컬에도 바이너리가 함께 놓입니다
4. 릴리스에서 바이너리를 내려받거나 패키지 관리자로 설치해 실행 경로에 둡니다
`kyverno apply` 명령의 성격으로 옳은 것은?
1. 클러스터에 정책을 등록해 즉시 강제합니다
2. 정책과 리소스를 로컬에서 평가해 통과와 실패를 출력하며 클러스터를 바꾸지 않습니다
3. 클러스터의 기존 리소스를 정책에 맞게 변경합니다
4. 정책 보고서를 클러스터에 생성합니다
`kyverno test` 가 `kyverno apply` 와 다른 점은?
1. test 는 클러스터에 접속해야만 동작합니다
2. test 는 기대 결과를 적은 파일을 함께 읽어 실제 결과와 비교해 합격 여부를 판정합니다
3. test 는 mutate 정책만 다룰 수 있습니다
4. test 는 정책 문법 검사만 수행합니다
`kyverno jp` 하위 명령이 필요한 상황은?
1. 정책을 클러스터에 적용하기 전에 서명하려 할 때입니다
2. 정책 보고서를 표 형태로 출력하려 할 때입니다
3. 사용자 정의 리소스 정의의 스키마를 검증하려 할 때입니다
4. 정책에 쓴 표현식이 어떤 값을 내는지 미리 확인하려 할 때입니다
정책이 참조하는 값을 CLI 평가에서 찾지 못해 검사가 실패합니다. 해결 방법은?
1. 변수 값을 담은 파일을 CLI 에 함께 넘겨 평가에 쓰이게 합니다
2. 그 규칙만 검사에서 건너뛰도록 정책을 나눕니다
3. CLI 를 포기하고 클러스터에 적용해 확인합니다
4. 정책에서 변수 참조를 모두 상수로 바꿉니다
`kyverno apply` 를 지속적 통합 게이트로 쓸 때 실패를 판정하는 방법은?
1. 출력 문자열에 실패라는 단어가 있는지 검사합니다
2. 명령 실행 시간이 길어지면 실패로 봅니다
3. 명령의 종료 코드를 확인하고 필요하면 결과를 파일로 받아 함께 검사합니다
4. 클러스터의 정책 보고서를 조회해 확인합니다
Kyverno CLI 만으로 완전히 검증하기 어려운 정책은?
1. 클러스터의 다른 리소스를 실시간으로 조회해 판단하는 규칙입니다
2. 레이블이 존재하는지만 확인하는 규칙입니다
3. 컨테이너 이미지의 접두어를 검사하는 규칙입니다
4. 리소스 상한 지정을 요구하는 규칙입니다
레이블이 붙은 네임스페이스에만 정책을 적용하려면?
1. match 의 종류 목록에 Namespace 를 추가합니다
2. 그 네임스페이스마다 Policy 를 하나씩 따로 만듭니다
3. match 의 리소스 조건에 네임스페이스 셀렉터를 넣어 레이블로 고릅니다
4. exclude 에 나머지 네임스페이스를 모두 나열합니다
match 에서 any 와 all 의 차이로 옳은 것은?
1. any 는 모든 조건을 만족해야 하고 all 은 하나만 만족하면 됩니다
2. any 는 나열된 조건 중 하나라도 맞으면 되고 all 은 모두 맞아야 합니다
3. any 는 클러스터 리소스에만, all 은 네임스페이스 리소스에만 쓸 수 있습니다
4. 둘은 같은 뜻이며 가독성을 위해 나뉘어 있습니다
이미 클러스터에 존재하던 리소스도 새 정책으로 평가하려면?
1. 모든 리소스를 다시 만들어야 합니다
2. 정책을 강제 모드로 바꾸면 기존 리소스도 자동으로 평가됩니다
3. 웹훅 설정을 다시 등록해야 합니다
4. 백그라운드 스캔이 켜져 있어야 하며 그 결과는 정책 보고서로 확인합니다
정책을 적용했더니 기존 워크로드는 그대로인데 신규 생성만 막힙니다. 이 동작에 대한 설명은?
1. 정책이 잘못 작성되어 일부만 동작하는 것입니다
2. 웹훅 타임아웃 때문에 일부 요청만 검사된 것입니다
3. 백그라운드 스캔이 신규 리소스만 처리하기 때문입니다
4. admission 검사는 새 요청에만 작용하고 기존 리소스는 보고서로만 드러나는 정상 동작입니다
match 로도 걸 수 있는 조건을 굳이 preconditions 로 옮기는 경우는?
1. match 가 레이블 조건을 지원하지 않기 때문입니다
2. 리소스 내부 필드 값처럼 match 로 표현할 수 없는 조건을 변수로 평가해야 할 때입니다
3. preconditions 가 언제나 더 빠르게 평가되기 때문입니다
4. match 는 규칙마다 하나만 쓸 수 있기 때문입니다
정책이 수정 요청에는 적용되지 않고 생성 요청에만 적용됩니다. 확인할 곳은?
1. 정책의 실패 동작 설정입니다
2. 웹훅의 실패 정책 설정입니다
3. match 에 지정한 요청 동작 목록입니다
4. 백그라운드 스캔 활성화 여부입니다
다음 규칙을 통과하는 파드는? ```yaml validate: message: 메모리 상한을 지정해야 합니다 pattern: spec: containers: - resources: limits: memory: "?*" ```
1. 모든 컨테이너에 비어 있지 않은 메모리 상한이 지정된 파드입니다
2. 첫 번째 컨테이너에만 메모리 상한이 있는 파드입니다
3. 메모리 요청만 지정하고 상한은 생략한 파드입니다
4. 컨테이너 목록 자체가 비어 있는 파드입니다
패턴에서 필드 이름을 괄호로 감싼 조건부 앵커의 의미는?
1. 그 필드는 반드시 존재해야 하며 값도 일치해야 합니다
2. 조건이 맞을 때만 같은 블록의 나머지 검사를 적용하고 맞지 않으면 그 항목을 건너뜁니다
3. 그 필드를 검사에서 완전히 제외합니다
4. 그 필드의 값을 지정한 값으로 바꿉니다
패턴 대신 deny 와 조건식을 쓰는 편이 나은 경우는?
1. 여러 필드 값을 비교하거나 계산해서 판단해야 할 때입니다
2. 필드가 존재하는지만 확인하면 될 때입니다
3. 배열의 모든 원소에 같은 모양을 요구할 때입니다
4. 특정 문자열 접두어만 검사할 때입니다
정책에서 `{{ request.object.metadata.labels.team }}` 이 가리키는 것은?
1. 정책이 만들어질 때 고정된 문자열입니다
2. 클러스터에 존재하는 모든 팀 레이블의 목록입니다
3. Kyverno 설정 ConfigMap 에 적힌 값입니다
4. 심사 중인 요청 대상 리소스에 붙은 team 레이블 값입니다
정책이 판단에 쓸 값을 ConfigMap 에서 가져오려면?
1. ConfigMap 이름을 메시지 필드에 적습니다
2. ConfigMap 을 정책과 같은 파일에 함께 정의합니다
3. 규칙의 context 에 ConfigMap 참조를 선언하고 변수로 참조합니다
4. Kyverno 컨트롤러에 ConfigMap 을 볼륨으로 마운트합니다
다음 mutate 규칙이 하는 일은? ```yaml mutate: patchStrategicMerge: metadata: labels: +(team): unassigned ```
1. team 레이블을 언제나 unassigned 로 덮어씁니다
2. team 레이블이 이미 있으면 규칙 전체를 건너뜁니다
3. team 레이블이 없을 때만 unassigned 로 추가합니다
4. team 레이블을 삭제합니다
여러 컨테이너의 이미지 접두어를 사내 레지스트리로 바꾸려 합니다. 적절한 방법은?
1. 전략적 병합 패치로 첫 컨테이너만 바꿉니다
2. generate 규칙으로 새 파드를 만들어 냅니다
3. cleanup 정책으로 기존 파드를 지웁니다
4. foreach 로 컨테이너 목록을 돌며 각 이미지 값을 치환합니다
새 네임스페이스마다 기본 NetworkPolicy 를 만들려 합니다. 알맞은 규칙 종류와 대상은?
1. Namespace 생성을 대상으로 삼는 generate 규칙을 씁니다
2. Pod 생성을 대상으로 삼는 mutate 규칙을 씁니다
3. NetworkPolicy 생성을 대상으로 삼는 validate 규칙을 씁니다
4. Namespace 생성을 대상으로 삼는 verifyImages 규칙을 씁니다
generate 규칙에서 데이터 직접 지정 대신 원본 복제를 쓰는 경우는?
1. 생성할 리소스가 클러스터 범위일 때입니다
2. 이미 관리하고 있는 원본 리소스를 그대로 복제해 배포하고 싶을 때입니다
3. 생성 대상이 사용자 정의 리소스일 때입니다
4. 생성 결과를 정책 보고서에 남기고 싶을 때입니다
verifyImages 규칙이 실패했을 때 기본적으로 일어나는 일은?
1. 해당 요청이 거부되어 파드가 만들어지지 않습니다
2. 이미지가 자동으로 이전 버전으로 교체됩니다
3. 경고만 남기고 파드는 정상적으로 생성됩니다
4. 이미지가 사내 레지스트리로 복사됩니다
Pod 를 대상으로 쓴 정책이 Deployment 로 만든 파드에도 적용되는 이유는?
1. Deployment 컨트롤러가 정책을 다시 평가하기 때문입니다
2. 백그라운드 스캔이 생성된 파드를 나중에 검사하기 때문입니다
3. 웹훅이 모든 리소스를 조건 없이 가로채기 때문입니다
4. Kyverno 가 컨트롤러 종류에 맞는 규칙을 자동으로 만들어 상위 리소스에도 적용하기 때문입니다
자동 생성 규칙이 만들어지는 대상을 조정하려면?
1. 규칙 이름을 정해진 접두어로 바꿉니다
2. match 의 종류 목록에 상위 리소스를 직접 나열합니다
3. 정책에 자동 생성 대상 컨트롤러를 지정하는 애너테이션을 붙입니다
4. Kyverno 컨트롤러를 재시작합니다
일정 시간이 지난 완료 상태 Job 을 정리하려 합니다. Kyverno 로 하는 방법은?
1. validate 규칙으로 오래된 Job 의 생성을 막습니다
2. cleanup 정책에 대상 조건과 일정을 적어 주기적으로 삭제하게 합니다
3. generate 규칙으로 삭제를 수행하는 Job 을 만듭니다
4. mutate 규칙으로 Job 의 소유자 참조를 지웁니다
Kyverno 정책에서 CEL 표현식을 쓸 수 있게 된 것이 주는 이점은?
1. 정책을 자바스크립트로 작성할 수 있게 됩니다
2. 정책이 클러스터 없이도 언제나 평가됩니다
3. 평가 결과가 캐시되어 웹훅이 필요 없어집니다
4. 쿠버네티스 내장 검증 정책과 같은 표현식 문법으로 조건을 간결하게 적을 수 있습니다
JSON 패치로 슬래시가 들어간 레이블 키를 추가할 때 주의할 점은?
1. 키에 점이 들어가면 패치를 사용할 수 없습니다
2. 경로에 슬래시를 그대로 적으면 됩니다
3. 키에 포함된 슬래시는 지정된 이스케이프 표기로 바꿔 적어야 합니다
4. 경로를 모두 대문자로 적어야 합니다
검증 실패 메시지에 위반한 리소스의 이름을 넣으려면?
1. 메시지에 리소스 이름을 미리 적어 둡니다
2. 메시지 문자열 안에 변수 참조를 넣어 심사 대상의 이름을 채웁니다
3. 메시지는 고정 문자열만 지원하므로 불가능합니다
4. 정책 보고서에서만 이름을 확인할 수 있습니다
요청자 정보를 참조하는 규칙을 백그라운드 스캔에서도 쓰려 하면 생기는 문제는?
1. 스캔에는 요청을 보낸 사용자 정보가 없어 값을 채울 수 없으므로 그 규칙은 스캔에서 제외해야 합니다
2. 스캔이 항상 관리자 계정으로 평가되어 모든 리소스가 통과합니다
3. 스캔이 사용자 정보를 감사 로그에서 읽어 채웁니다
4. 정책이 아예 등록되지 않고 거부됩니다
다음 규칙의 동작으로 옳은 것은? ```yaml validate: message: 볼륨은 다섯 개까지만 허용합니다 deny: conditions: all: - key: "{{ request.object.spec.volumes[] | length(@) }}" operator: GreaterThan value: 5 ```
1. 볼륨이 다섯 개 이하일 때 요청을 거부합니다
2. 볼륨이 여섯 개 이상일 때 요청을 거부합니다
3. 볼륨 개수와 무관하게 언제나 요청을 거부합니다
4. 볼륨을 다섯 개만 남기고 나머지를 지웁니다
다음 규칙에 대한 설명으로 옳은 것은? ```yaml preconditions: all: - key: "{{ request.operation }}" operator: Equals value: CREATE mutate: patchStrategicMerge: metadata: annotations: created-by: "{{ request.userInfo.username }}" ```
1. 모든 요청에 애너테이션을 붙입니다
2. 수정 요청에만 애너테이션을 붙입니다
3. 생성 요청에만 요청자 이름을 애너테이션으로 붙입니다
4. 애너테이션 값이 비어 있으면 요청을 거부합니다
네임스페이스 범위의 정책 보고서를 확인하는 방법으로 옳은 것은?
1. `kubectl get policyreport -n prod` 로 그 네임스페이스의 결과를 조회합니다
2. 컨트롤러 로그를 읽어 위반 줄을 찾는 방법뿐입니다
3. Kyverno 설정 ConfigMap 을 조회해 확인합니다
4. 웹훅 설정 오브젝트를 조회해 확인합니다
클러스터 범위 리소스에 대한 정책 평가 결과는 어디에 기록되나요?
1. default 네임스페이스의 보고서에 함께 기록됩니다
2. 각 리소스의 애너테이션에 기록됩니다
3. 컨트롤러의 메모리에만 유지됩니다
4. 클러스터 범위 정책 보고서 리소스에 기록됩니다
PolicyException 오브젝트가 실제로 하는 일은?
1. 지정한 정책과 규칙에 대해 정해진 리소스만 평가에서 벗어나게 합니다
2. 정책 전체를 일시적으로 비활성화합니다
3. 위반 결과를 보고서에서 숨기지만 강제는 그대로 유지합니다
4. 위반한 리소스를 자동으로 수정해 통과시킵니다
예외를 안전하게 운영하기 위한 설정으로 적절한 것은?
1. 예외 오브젝트를 모든 네임스페이스에서 자유롭게 만들게 둡니다
2. 예외를 만들 수 있는 네임스페이스를 제한하고 만료 기한과 소유자를 함께 관리합니다
3. 예외 대신 해당 정책을 감사 모드로 바꿔 둡니다
4. 예외를 쓰지 않고 규칙을 그때그때 고칩니다
정책이 실제로 요청을 막고 있는지 지표로 확인하려면 무엇을 봐야 하나요?
1. 컨트롤러 파드의 CPU 사용량입니다
2. 클러스터에 등록된 정책 오브젝트의 개수입니다
3. 웹훅 인증서의 남은 유효 기간입니다
4. 규칙 실행 결과를 통과와 실패로 나눈 카운터와 admission 요청 지표입니다
대규모 클러스터에서 정책 보고서가 지나치게 커질 때의 대응으로 적절한 것은?
1. 백그라운드 스캔을 끄고 기존 보고서를 모두 삭제합니다
2. 보고서를 파일로 내보낸 뒤 관련 정의를 제거합니다
3. 스캔 대상 리소스를 필터로 좁히고 주기를 조정해 생성량을 줄입니다
4. 모든 정책을 강제 모드로 바꿔 위반 자체를 없앱니다