KCA模擬試験A

Policy 와 ClusterPolicy 의 차이로 옳은 것은?

• Policy 는 validate 만 쓸 수 있고 ClusterPolicy 는 mutate 까지 쓸 수 있습니다
• Policy 는 백그라운드 스캔을 지원하지 않습니다
• ClusterPolicy 는 네임스페이스 리소스에는 적용되지 않습니다
• Policy 는 자신이 속한 네임스페이스에만, ClusterPolicy 는 클러스터 전체에 적용됩니다

Kyverno 가 admission 웹훅을 등록하는 방식으로 옳은 것은?

• 정책 내용에 따라 검증용과 변경용 웹훅 설정을 만들고 필요한 리소스만 대상으로 좁힙니다
• 모든 리소스에 대해 항상 고정된 웹훅 하나만 등록합니다
• 웹훅을 쓰지 않고 컨트롤러가 주기적으로 폴링합니다
• API 서버 설정 파일을 직접 수정해 등록합니다

Kyverno 규칙에서 match 블록이 하는 일은?

• 규칙 위반 시 사용자에게 보여 줄 메시지를 정의합니다
• 정책이 적용될 클러스터를 선택합니다
• 이 규칙이 평가될 리소스의 범위를 정합니다
• 여러 규칙의 실행 순서를 지정합니다

컨테이너 이미지에서 태그와 다이제스트의 차이로 옳은 것은?

• 태그는 언제나 불변이고 다이제스트는 재빌드 때마다 갱신될 수 있습니다
• 태그는 나중에 다른 이미지를 가리키도록 바뀔 수 있지만 다이제스트는 내용에서 계산되어 바뀌지 않습니다
• 둘 다 레지스트리가 임의로 부여하는 식별자입니다
• 다이제스트는 레지스트리마다 달라져 이식성이 없습니다

하나의 Kyverno 규칙에 대한 설명으로 옳은 것은?

• 한 규칙에 validate 와 mutate 를 함께 넣어 순서대로 실행할 수 있습니다
• 규칙 이름은 선택 사항이라 생략할 수 있습니다
• 한 규칙은 하나의 동작만 가지며 여러 동작이 필요하면 규칙을 나눕니다
• 규칙은 ClusterPolicy 안에서만 정의할 수 있습니다

Kyverno 가 정책 평가 결과를 클러스터에 남기는 방식으로 옳은 것은?

• 이벤트로만 남기고 별도 오브젝트는 만들지 않습니다
• 네임스페이스 범위와 클러스터 범위의 정책 보고서 리소스에 결과를 기록합니다
• 위반 내용을 ConfigMap 에 누적해 저장합니다
• 감사 로그 파일에만 기록하므로 kubectl 로는 볼 수 없습니다

Kyverno 의 cleanup 컨트롤러가 담당하는 일은?

• 정책 보고서에서 오래된 항목을 지웁니다
• 실패한 웹훅 설정을 제거합니다
• 종료된 파드의 로그를 정리합니다
• 조건에 맞는 리소스를 정해진 일정에 따라 삭제합니다

요청이 Kyverno 웹훅에 도달한 시점에 이미 끝나 있는 단계는?

• 사용자 인증과 RBAC 인가 심사입니다
• 오브젝트를 etcd 에 저장하는 일입니다
• 스케줄러가 파드에 노드를 배정하는 일입니다
• kubelet 이 컨테이너를 시작하는 일입니다

정책을 별도 언어가 아니라 쿠버네티스 리소스로 표현하는 것이 주는 이점은?

• 정책이 API 서버 없이도 항상 평가될 수 있습니다
• 기존 kubectl 과 RBAC, GitOps 흐름을 그대로 써서 정책을 다룰 수 있습니다
• 정책 평가 속도가 언제나 더 빠릅니다
• 정책을 컴파일해 바이너리로 배포할 수 있습니다

Deployment 를 대상으로 한 정책이 있는데 직접 만든 파드는 막히지 않았습니다. 원인으로 가장 적절한 것은?

• Kyverno 는 Deployment 를 대상으로 삼을 수 없습니다
• 웹훅 타임아웃이 짧아 요청이 통과했습니다
• 정책이 감사 모드로 설정되어 있었습니다
• 직접 만든 파드는 Deployment 를 거치지 않으므로 Pod 도 대상에 포함해야 합니다

설치 시 kube-system 같은 네임스페이스를 기본적으로 제외하는 이유는?

• 그 네임스페이스에는 검사할 파드가 없기 때문입니다
• 정책 보고서의 용량을 줄이기 위해서입니다
• 클러스터 핵심 구성 요소가 웹훅 때문에 기동하지 못하는 상황을 피하기 위해서입니다
• 해당 네임스페이스는 RBAC 으로 이미 충분히 보호되기 때문입니다

Kyverno 를 Helm 으로 설치할 때 사용자 정의 리소스 정의는 어떻게 다뤄지나요?

• 차트가 함께 설치하며, 업그레이드 시에는 정의 갱신이 제대로 반영됐는지 따로 확인해야 합니다
• 컨트롤러가 기동하면서 스스로 만들어 냅니다
• 쿠버네티스에 내장되어 있어 설치할 필요가 없습니다
• 첫 정책을 만들 때 자동으로 생성됩니다

고가용성 구성으로 Kyverno 를 설치할 때 권장되는 사항은?

• 컨트롤러 레플리카를 셋 이상 두고 노드에 흩어지도록 배치 규칙을 겁니다
• 레플리카를 하나로 두고 노드 장애 시 손으로 옮깁니다
• 모든 컨트롤러를 같은 노드에 모아 지연을 줄입니다
• 웹훅 실패 정책을 무시로 바꿔 가용성을 확보합니다

정책이 늘어난 뒤 admission 컨트롤러가 반복해서 재시작합니다. 가장 먼저 조정할 것은?

• 모든 정책의 실패 동작을 감사 모드로 바꿉니다
• 웹훅 타임아웃을 최대치로 늘립니다
• 컨트롤러의 메모리 요청과 상한을 올리고 캐시 관련 설정을 점검합니다
• 클러스터의 노드 수를 늘립니다

generate 규칙으로 사용자 정의 리소스를 만들려 합니다. 권한을 주는 방법으로 옳은 것은?

• 정책에 서비스 어카운트 이름을 적으면 필요한 권한이 자동으로 생깁니다
• Kyverno 파드에 최고 관리자 권한을 부여하는 방법뿐입니다
• 관리자 kubeconfig 를 시크릿으로 넣어 줍니다
• 역할 집계에 참여하는 ClusterRole 을 만들어 필요한 리소스 권한을 더합니다

Kyverno 컨트롤러의 동작을 배포 시점에 바꾸는 수단으로 옳은 것은?

• 정책 리소스의 spec 에 컨트롤러 설정을 적습니다
• 컨테이너 인자로 넘기는 플래그와 Kyverno 설정 ConfigMap 을 사용합니다
• API 서버의 admission 플러그인 목록을 수정합니다
• 사용자 정의 리소스 정의의 스키마에 기본값을 넣습니다

Kyverno 를 여러 마이너 버전 건너뛰어 올리려 합니다. 권장되는 방식은?

• 차트 버전만 최신으로 지정해 한 번에 올립니다
• 기존 설치를 지우고 새로 설치하면 정책도 그대로 남습니다
• 릴리스 노트의 지원 경로를 확인하고 한 단계씩 올리며 정의 변경을 반영합니다
• 컨트롤러 이미지 태그만 바꿔 재시작합니다

Kyverno 를 설치한 직후 일부 워크로드 생성이 실패했습니다. 가장 유력한 원인은?

• 웹훅은 등록되었는데 컨트롤러가 아직 준비되지 않아 요청이 거절되었습니다
• 사용자 정의 리소스 정의가 설치되지 않아 파드 생성이 막혔습니다
• 정책 보고서 리소스가 가득 찼습니다
• 릴리스 이름이 명명 규칙에 맞지 않았습니다

Kyverno 웹훅이 사용하는 TLS 인증서에 대한 설명으로 옳은 것은?

• 관리자가 직접 발급해 시크릿으로 넣어야만 동작합니다
• 기본적으로 스스로 관리되며 만료 전에 갱신되고, 필요하면 외부 발급 인증서로 바꿀 수 있습니다
• 인증서 없이 평문으로 통신합니다
• 서비스 어카운트 토큰이 인증서를 대신합니다

특정 네임스페이스를 모든 정책 대상에서 클러스터 차원으로 제외하려면?

• 정책마다 exclude 블록을 하나씩 추가하는 방법뿐입니다
• 해당 네임스페이스에 레이블을 붙이면 자동으로 제외됩니다
• 웹훅 설정 오브젝트를 손으로 편집해 제외합니다
• Kyverno 설정 ConfigMap 의 리소스 필터에 해당 네임스페이스를 추가합니다

여러 레플리카로 띄운 백그라운드 컨트롤러가 같은 작업을 중복 수행하지 않는 이유는?

• 레플리카마다 담당 네임스페이스가 자동으로 나뉘기 때문입니다
• 작업이 멱등이라 중복 수행해도 결과가 같기 때문입니다
• 리더 선출로 한 인스턴스만 실제 처리를 맡기 때문입니다
• API 서버가 중복 요청을 걸러 주기 때문입니다

Kyverno 를 제거할 때 주의할 점은?

• 웹훅 설정과 정의가 남으면 요청이 계속 막히거나 정책 오브젝트가 남을 수 있으므로 정리 순서를 확인해야 합니다
• 제거하는 즉시 클러스터의 모든 파드가 다시 생성됩니다
• 제거한 뒤에도 기존 정책이 계속 강제됩니다
• 제거하면 mutate 로 바뀐 값이 원래대로 되돌아갑니다

Kyverno CLI 를 설치하는 방법으로 적절한 것은?

• 클러스터에 CLI 파드를 배포하고 들어가서 실행합니다
• kubectl 플러그인 이름을 바꾸면 자동으로 활성화됩니다
• Helm 차트를 설치하면 로컬에도 바이너리가 함께 놓입니다
• 릴리스에서 바이너리를 내려받거나 패키지 관리자로 설치해 실행 경로에 둡니다

kyverno apply 명령의 성격으로 옳은 것은?

• 클러스터에 정책을 등록해 즉시 강제합니다
• 정책과 리소스를 로컬에서 평가해 통과와 실패를 출력하며 클러스터를 바꾸지 않습니다
• 클러스터의 기존 리소스를 정책에 맞게 변경합니다
• 정책 보고서를 클러스터에 생성합니다

kyverno test 가 kyverno apply 와 다른 점은?

• test 는 클러스터에 접속해야만 동작합니다
• test 는 기대 결과를 적은 파일을 함께 읽어 실제 결과와 비교해 합격 여부를 판정합니다
• test 는 mutate 정책만 다룰 수 있습니다
• test 는 정책 문법 검사만 수행합니다

kyverno jp 하위 명령이 필요한 상황은?

• 정책을 클러스터에 적용하기 전에 서명하려 할 때입니다
• 정책 보고서를 표 형태로 출력하려 할 때입니다
• 사용자 정의 리소스 정의의 스키마를 검증하려 할 때입니다
• 정책에 쓴 표현식이 어떤 값을 내는지 미리 확인하려 할 때입니다

정책이 참조하는 값을 CLI 평가에서 찾지 못해 검사가 실패합니다. 해결 방법은?

• 변수 값을 담은 파일을 CLI 에 함께 넘겨 평가에 쓰이게 합니다
• 그 규칙만 검사에서 건너뛰도록 정책을 나눕니다
• CLI 를 포기하고 클러스터에 적용해 확인합니다
• 정책에서 변수 참조를 모두 상수로 바꿉니다

kyverno apply 를 지속적 통합 게이트로 쓸 때 실패를 판정하는 방법은?

• 출력 문자열에 실패라는 단어가 있는지 검사합니다
• 명령 실행 시간이 길어지면 실패로 봅니다
• 명령의 종료 코드를 확인하고 필요하면 결과를 파일로 받아 함께 검사합니다
• 클러스터의 정책 보고서를 조회해 확인합니다

Kyverno CLI 만으로 완전히 검증하기 어려운 정책은?

• 클러스터의 다른 리소스를 실시간으로 조회해 판단하는 규칙입니다
• 레이블이 존재하는지만 확인하는 규칙입니다
• 컨테이너 이미지의 접두어를 검사하는 규칙입니다
• 리소스 상한 지정을 요구하는 규칙입니다

레이블이 붙은 네임스페이스에만 정책을 적용하려면?

• match 의 종류 목록에 Namespace 를 추가합니다
• 그 네임스페이스마다 Policy 를 하나씩 따로 만듭니다
• match 의 리소스 조건에 네임스페이스 셀렉터를 넣어 레이블로 고릅니다
• exclude 에 나머지 네임스페이스를 모두 나열합니다

match 에서 any 와 all 의 차이로 옳은 것은?

• any 는 모든 조건을 만족해야 하고 all 은 하나만 만족하면 됩니다
• any 는 나열된 조건 중 하나라도 맞으면 되고 all 은 모두 맞아야 합니다
• any 는 클러스터 리소스에만, all 은 네임스페이스 리소스에만 쓸 수 있습니다
• 둘은 같은 뜻이며 가독성을 위해 나뉘어 있습니다

이미 클러스터에 존재하던 리소스도 새 정책으로 평가하려면?

• 모든 리소스를 다시 만들어야 합니다
• 정책을 강제 모드로 바꾸면 기존 리소스도 자동으로 평가됩니다
• 웹훅 설정을 다시 등록해야 합니다
• 백그라운드 스캔이 켜져 있어야 하며 그 결과는 정책 보고서로 확인합니다

정책을 적용했더니 기존 워크로드는 그대로인데 신규 생성만 막힙니다. 이 동작에 대한 설명은?

• 정책이 잘못 작성되어 일부만 동작하는 것입니다
• 웹훅 타임아웃 때문에 일부 요청만 검사된 것입니다
• 백그라운드 스캔이 신규 리소스만 처리하기 때문입니다
• admission 검사는 새 요청에만 작용하고 기존 리소스는 보고서로만 드러나는 정상 동작입니다

match 로도 걸 수 있는 조건을 굳이 preconditions 로 옮기는 경우는?

• match 가 레이블 조건을 지원하지 않기 때문입니다
• 리소스 내부 필드 값처럼 match 로 표현할 수 없는 조건을 변수로 평가해야 할 때입니다
• preconditions 가 언제나 더 빠르게 평가되기 때문입니다
• match 는 규칙마다 하나만 쓸 수 있기 때문입니다

정책이 수정 요청에는 적용되지 않고 생성 요청에만 적용됩니다. 확인할 곳은?

• 정책의 실패 동작 설정입니다
• 웹훅의 실패 정책 설정입니다
• match 에 지정한 요청 동작 목록입니다
• 백그라운드 스캔 활성화 여부입니다

다음 규칙을 통과하는 파드는?

validate:
  message: 메모리 상한을 지정해야 합니다
  pattern:
    spec:
      containers:
      - resources:
          limits:
            memory: "?*"

• 모든 컨테이너에 비어 있지 않은 메모리 상한이 지정된 파드입니다
• 첫 번째 컨테이너에만 메모리 상한이 있는 파드입니다
• 메모리 요청만 지정하고 상한은 생략한 파드입니다
• 컨테이너 목록 자체가 비어 있는 파드입니다

패턴에서 필드 이름을 괄호로 감싼 조건부 앵커의 의미는?

• 그 필드는 반드시 존재해야 하며 값도 일치해야 합니다
• 조건이 맞을 때만 같은 블록의 나머지 검사를 적용하고 맞지 않으면 그 항목을 건너뜁니다
• 그 필드를 검사에서 완전히 제외합니다
• 그 필드의 값을 지정한 값으로 바꿉니다

패턴 대신 deny 와 조건식을 쓰는 편이 나은 경우는?

• 여러 필드 값을 비교하거나 계산해서 판단해야 할 때입니다
• 필드가 존재하는지만 확인하면 될 때입니다
• 배열의 모든 원소에 같은 모양을 요구할 때입니다
• 특정 문자열 접두어만 검사할 때입니다

정책에서 {{ request.object.metadata.labels.team }} 이 가리키는 것은?

• 정책이 만들어질 때 고정된 문자열입니다
• 클러스터에 존재하는 모든 팀 레이블의 목록입니다
• Kyverno 설정 ConfigMap 에 적힌 값입니다
• 심사 중인 요청 대상 리소스에 붙은 team 레이블 값입니다

정책이 판단에 쓸 값을 ConfigMap 에서 가져오려면?

• ConfigMap 이름을 메시지 필드에 적습니다
• ConfigMap 을 정책과 같은 파일에 함께 정의합니다
• 규칙의 context 에 ConfigMap 참조를 선언하고 변수로 참조합니다
• Kyverno 컨트롤러에 ConfigMap 을 볼륨으로 마운트합니다

다음 mutate 규칙이 하는 일은?

mutate:
  patchStrategicMerge:
    metadata:
      labels:
        +(team): unassigned

• team 레이블을 언제나 unassigned 로 덮어씁니다
• team 레이블이 이미 있으면 규칙 전체를 건너뜁니다
• team 레이블이 없을 때만 unassigned 로 추가합니다
• team 레이블을 삭제합니다

여러 컨테이너의 이미지 접두어를 사내 레지스트리로 바꾸려 합니다. 적절한 방법은?

• 전략적 병합 패치로 첫 컨테이너만 바꿉니다
• generate 규칙으로 새 파드를 만들어 냅니다
• cleanup 정책으로 기존 파드를 지웁니다
• foreach 로 컨테이너 목록을 돌며 각 이미지 값을 치환합니다

새 네임스페이스마다 기본 NetworkPolicy 를 만들려 합니다. 알맞은 규칙 종류와 대상은?

• Namespace 생성을 대상으로 삼는 generate 규칙을 씁니다
• Pod 생성을 대상으로 삼는 mutate 규칙을 씁니다
• NetworkPolicy 생성을 대상으로 삼는 validate 규칙을 씁니다
• Namespace 생성을 대상으로 삼는 verifyImages 규칙을 씁니다

generate 규칙에서 데이터 직접 지정 대신 원본 복제를 쓰는 경우는?

• 생성할 리소스가 클러스터 범위일 때입니다
• 이미 관리하고 있는 원본 리소스를 그대로 복제해 배포하고 싶을 때입니다
• 생성 대상이 사용자 정의 리소스일 때입니다
• 생성 결과를 정책 보고서에 남기고 싶을 때입니다

verifyImages 규칙이 실패했을 때 기본적으로 일어나는 일은?

• 해당 요청이 거부되어 파드가 만들어지지 않습니다
• 이미지가 자동으로 이전 버전으로 교체됩니다
• 경고만 남기고 파드는 정상적으로 생성됩니다
• 이미지가 사내 레지스트리로 복사됩니다

Pod 를 대상으로 쓴 정책이 Deployment 로 만든 파드에도 적용되는 이유는?

• Deployment 컨트롤러가 정책을 다시 평가하기 때문입니다
• 백그라운드 스캔이 생성된 파드를 나중에 검사하기 때문입니다
• 웹훅이 모든 리소스를 조건 없이 가로채기 때문입니다
• Kyverno 가 컨트롤러 종류에 맞는 규칙을 자동으로 만들어 상위 리소스에도 적용하기 때문입니다

자동 생성 규칙이 만들어지는 대상을 조정하려면?

• 규칙 이름을 정해진 접두어로 바꿉니다
• match 의 종류 목록에 상위 리소스를 직접 나열합니다
• 정책에 자동 생성 대상 컨트롤러를 지정하는 애너테이션을 붙입니다
• Kyverno 컨트롤러를 재시작합니다

일정 시간이 지난 완료 상태 Job 을 정리하려 합니다. Kyverno 로 하는 방법은?

• validate 규칙으로 오래된 Job 의 생성을 막습니다
• cleanup 정책에 대상 조건과 일정을 적어 주기적으로 삭제하게 합니다
• generate 규칙으로 삭제를 수행하는 Job 을 만듭니다
• mutate 규칙으로 Job 의 소유자 참조를 지웁니다

Kyverno 정책에서 CEL 표현식을 쓸 수 있게 된 것이 주는 이점은?

• 정책을 자바스크립트로 작성할 수 있게 됩니다
• 정책이 클러스터 없이도 언제나 평가됩니다
• 평가 결과가 캐시되어 웹훅이 필요 없어집니다
• 쿠버네티스 내장 검증 정책과 같은 표현식 문법으로 조건을 간결하게 적을 수 있습니다

JSON 패치로 슬래시가 들어간 레이블 키를 추가할 때 주의할 점은?

• 키에 점이 들어가면 패치를 사용할 수 없습니다
• 경로에 슬래시를 그대로 적으면 됩니다
• 키에 포함된 슬래시는 지정된 이스케이프 표기로 바꿔 적어야 합니다
• 경로를 모두 대문자로 적어야 합니다

검증 실패 메시지에 위반한 리소스의 이름을 넣으려면?

• 메시지에 리소스 이름을 미리 적어 둡니다
• 메시지 문자열 안에 변수 참조를 넣어 심사 대상의 이름을 채웁니다
• 메시지는 고정 문자열만 지원하므로 불가능합니다
• 정책 보고서에서만 이름을 확인할 수 있습니다

요청자 정보를 참조하는 규칙을 백그라운드 스캔에서도 쓰려 하면 생기는 문제는?

• 스캔에는 요청을 보낸 사용자 정보가 없어 값을 채울 수 없으므로 그 규칙은 스캔에서 제외해야 합니다
• 스캔이 항상 관리자 계정으로 평가되어 모든 리소스가 통과합니다
• 스캔이 사용자 정보를 감사 로그에서 읽어 채웁니다
• 정책이 아예 등록되지 않고 거부됩니다

다음 규칙의 동작으로 옳은 것은?

validate:
  message: 볼륨은 다섯 개까지만 허용합니다
  deny:
    conditions:
      all:
      - key: "{{ request.object.spec.volumes[] | length(@) }}"
        operator: GreaterThan
        value: 5

• 볼륨이 다섯 개 이하일 때 요청을 거부합니다
• 볼륨이 여섯 개 이상일 때 요청을 거부합니다
• 볼륨 개수와 무관하게 언제나 요청을 거부합니다
• 볼륨을 다섯 개만 남기고 나머지를 지웁니다

다음 규칙에 대한 설명으로 옳은 것은?

preconditions:
  all:
  - key: "{{ request.operation }}"
    operator: Equals
    value: CREATE
mutate:
  patchStrategicMerge:
    metadata:
      annotations:
        created-by: "{{ request.userInfo.username }}"

• 모든 요청에 애너테이션을 붙입니다
• 수정 요청에만 애너테이션을 붙입니다
• 생성 요청에만 요청자 이름을 애너테이션으로 붙입니다
• 애너테이션 값이 비어 있으면 요청을 거부합니다

네임스페이스 범위의 정책 보고서를 확인하는 방법으로 옳은 것은?

• kubectl get policyreport -n prod 로 그 네임스페이스의 결과를 조회합니다
• 컨트롤러 로그를 읽어 위반 줄을 찾는 방법뿐입니다
• Kyverno 설정 ConfigMap 을 조회해 확인합니다
• 웹훅 설정 오브젝트를 조회해 확인합니다

클러스터 범위 리소스에 대한 정책 평가 결과는 어디에 기록되나요?

• default 네임스페이스의 보고서에 함께 기록됩니다
• 각 리소스의 애너테이션에 기록됩니다
• 컨트롤러의 메모리에만 유지됩니다
• 클러스터 범위 정책 보고서 리소스에 기록됩니다

PolicyException 오브젝트가 실제로 하는 일은?

• 지정한 정책과 규칙에 대해 정해진 리소스만 평가에서 벗어나게 합니다
• 정책 전체를 일시적으로 비활성화합니다
• 위반 결과를 보고서에서 숨기지만 강제는 그대로 유지합니다
• 위반한 리소스를 자동으로 수정해 통과시킵니다

예외를 안전하게 운영하기 위한 설정으로 적절한 것은?

• 예외 오브젝트를 모든 네임스페이스에서 자유롭게 만들게 둡니다
• 예외를 만들 수 있는 네임스페이스를 제한하고 만료 기한과 소유자를 함께 관리합니다
• 예외 대신 해당 정책을 감사 모드로 바꿔 둡니다
• 예외를 쓰지 않고 규칙을 그때그때 고칩니다

정책이 실제로 요청을 막고 있는지 지표로 확인하려면 무엇을 봐야 하나요?

• 컨트롤러 파드의 CPU 사용량입니다
• 클러스터에 등록된 정책 오브젝트의 개수입니다
• 웹훅 인증서의 남은 유효 기간입니다
• 규칙 실행 결과를 통과와 실패로 나눈 카운터와 admission 요청 지표입니다

대규모 클러스터에서 정책 보고서가 지나치게 커질 때의 대응으로 적절한 것은?

• 백그라운드 스캔을 끄고 기존 보고서를 모두 삭제합니다
• 보고서를 파일로 내보낸 뒤 관련 정의를 제거합니다
• 스캔 대상 리소스를 필터로 좁히고 주기를 조정해 생성량을 줄입니다
• 모든 정책을 강제 모드로 바꿔 위반 자체를 없앱니다