KCSA模擬試験A

클라우드 네이티브 보안의 4C 모델에서 안쪽부터 바깥쪽 순서로 올바른 것은?

• Code → Container → Cluster → Cloud
• Container → Code → Cloud → Cluster
• Cloud → Cluster → Container → Code
• Cluster → Cloud → Code → Container

공동 책임 모델에서 관리형 쿠버네티스 사용자가 여전히 책임지는 영역으로 올바른 것은?

• 컨트롤 플레인 노드의 운영체제 패치
• etcd 인스턴스의 물리적 보안
• 워크로드의 RBAC 설정과 파드 보안 수준
• apiserver 바이너리의 취약점 수정

최소 권한 원칙을 쿠버네티스에 적용한 예로 가장 적절한 것은?

• 모든 파드에 cluster-admin 을 주되 감사 로그로 사후 추적한다
• 워크로드마다 전용 ServiceAccount 를 만들고 필요한 동사와 리소스만 허용한다
• 네임스페이스를 하나만 두고 모든 워크로드를 그 안에서 관리한다
• 권한을 넉넉히 주고 문제가 생기면 그때 줄인다

심층 방어(defense in depth)를 쿠버네티스에서 실천한 예로 가장 적절한 것은?

• 가장 강력한 통제 하나를 골라 그것에만 집중 투자한다
• 이미지 스캔, 어드미션 정책, 파드 보안 표준, 네트워크 정책, 런타임 탐지를 겹쳐 둔다
• 클러스터를 외부에서 접근할 수 없게 막으면 다른 통제는 생략한다
• 취약점이 발견된 뒤에 대응 절차를 만든다

쿠버네티스에서 공격 표면이 넓어지는 설정으로 보기 어려운 것은?

• apiserver 를 인터넷에 그대로 노출하는 것
• 익명 접근(--anonymous-auth=true)을 켜 두는 것
• 노드에 SSH 를 열어 두고 키를 공유하는 것
• 워크로드마다 별도의 네임스페이스를 두는 것

공급망 보안에서 SBOM 이 하는 역할로 가장 정확한 것은?

• 빌드 파이프라인에 서명을 붙여 위조를 막는다
• 아티팩트에 들어간 구성 요소와 버전 목록을 남겨 새 취약점이 공개됐을 때 영향 범위를 즉시 찾게 한다
• 실행 중인 컨테이너의 시스템 콜을 감시해 이상 행위를 탐지한다
• 이미지를 암호화해 레지스트리에서 내용을 읽지 못하게 한다

제로 트러스트를 클러스터 내부에 적용한다는 말의 의미로 가장 적절한 것은?

• 클러스터 안에 들어온 트래픽은 이미 검증된 것으로 보고 내부 통신은 열어 둔다
• 위치가 아니라 신원과 정책으로 매 요청을 판단하고 내부 통신도 인증과 인가를 거치게 한다
• 모든 외부 접근을 차단하고 내부 사용자만 클러스터를 쓰게 한다
• 방화벽 규칙을 촘촘히 짜서 경계를 강화한다

클러스터 보안 사고 대응에서 침해된 노드를 발견했을 때 순서로 가장 적절한 것은?

• 노드를 즉시 삭제해 흔적을 정리하고 새 노드를 붙인다
• 노드를 cordon 하고 증거를 보존한 뒤 워크로드를 옮기고 자격증명을 회수한다
• 노드를 재부팅해 정상 상태로 되돌린 다음 원인을 조사한다
• 먼저 클러스터 전체를 재설치하고 나중에 로그를 본다

apiserver 의 --authorization-mode 에 AlwaysAllow 가 포함되면 어떤 일이 벌어지는가?

• 인증에 성공한 요청은 RBAC 규칙과 무관하게 모두 허용된다
• 인증되지 않은 요청만 허용되고 인증된 요청은 RBAC 을 따른다
• RBAC 규칙이 없을 때만 허용되고 규칙이 있으면 그것을 따른다
• 감사 로그에 기록된 주체만 허용된다

kubelet 의 --anonymous-auth=true 가 위험한 이유로 가장 정확한 것은?

• kubelet 이 apiserver 에 익명으로 접속해 노드 등록이 실패한다
• 노드의 kubelet API 에 자격증명 없이 접근할 수 있는 경로가 열린다
• 파드의 ServiceAccount 토큰이 발급되지 않는다
• 컨테이너 런타임이 이미지 서명을 검증하지 않게 된다

etcd 를 보호하기 위한 조치로 효과가 가장 적은 것은?

• 클라이언트와 피어 통신 모두에 상호 TLS 를 강제한다
• etcd 포트를 컨트롤 플레인 노드 사이로만 열고 나머지는 차단한다
• 저장 시 암호화를 켜서 Secret 이 평문으로 남지 않게 한다
• etcd 데이터 디렉터리의 파일 이름을 알아보기 어렵게 바꾼다

쿠버네티스의 저장 시 암호화(encryption at rest)에 대한 설명으로 올바른 것은?

• apiserver 가 etcd 에 쓰기 전에 암호화하고 읽을 때 복호화한다
• etcd 가 스스로 암호화하며 apiserver 는 관여하지 않는다
• kubelet 이 파드에 마운트하기 직전에 복호화한다
• 클라이언트인 kubectl 이 전송 전에 암호화한다

KMS 프로바이더를 쓰는 저장 시 암호화가 aescbc 같은 로컬 키 방식보다 나은 점은?

• 암호화 알고리즘이 더 빨라 apiserver 지연이 줄어든다
• 데이터 암호화 키를 외부 KMS 가 감싸므로 키가 설정 파일에 평문으로 남지 않는다
• etcd 백업 파일을 자동으로 복호화해 준다
• Secret 이외의 리소스까지 자동으로 암호화 대상에 넣는다

apiserver 의 인증 방식으로 쿠버네티스가 제공하지 않는 것은?

• 클라이언트 인증서
• OIDC 토큰
• ServiceAccount 토큰
• 리소스별 접근 제어 목록(ACL) 파일

바운드 ServiceAccount 토큰(projected token)이 기존의 Secret 기반 토큰보다 안전한 이유는?

• 토큰이 더 긴 문자열이라 추측하기 어렵다
• 만료 시간이 있고 특정 파드와 대상(audience)에 묶여 있어 유출 시 쓸 수 있는 범위와 기간이 좁다
• 토큰이 etcd 에 저장되지 않아 apiserver 도 검증할 수 없다
• 토큰이 파드 안에서만 생성되어 apiserver 가 발급에 관여하지 않는다

kube-scheduler 와 kube-controller-manager 의 --bind-address 를 루프백으로 두라고 권고하는 이유는?

• 다른 노드가 그 컴포넌트에 접속해야 하는데 대역폭을 아끼기 위해
• 지표와 디버그 엔드포인트가 노드 밖에서 접근 가능한 상태로 노출되지 않게 하려고
• 컴포넌트가 apiserver 에 접속할 때 지연을 줄이려고
• 리더 선출을 노드마다 독립적으로 수행하려고

컨트롤 플레인 컴포넌트의 --profiling=true 를 운영에서 끄라고 하는 이유는?

• 프로파일링이 켜지면 감사 로그가 남지 않기 때문
• profiling 엔드포인트가 내부 상태를 드러내고 부하를 유발할 수 있기 때문
• 프로파일링이 인증을 우회하도록 설계되어 있기 때문
• 프로파일링을 켜면 RBAC 규칙이 초기화되기 때문

kubelet 의 --read-only-port 와 --authorization-mode=Webhook 의 관계로 올바른 것은?

• 읽기 전용 포트는 인가 웹훅을 거치지 않으므로 웹훅을 켜도 그 포트는 따로 닫아야 한다
• 인가 웹훅을 켜면 읽기 전용 포트도 자동으로 보호된다
• 읽기 전용 포트를 닫으면 인가 웹훅이 동작하지 않는다
• 두 설정은 서로 배타적이라 함께 쓸 수 없다

어드미션 컨트롤러가 인증·인가와 다른 지점으로 가장 정확한 것은?

• 요청자가 누구인지 다시 확인해 신원을 이중으로 검증한다
• 요청의 내용을 보고 변형하거나 거부해 오브젝트가 지켜야 할 조건을 강제한다
• 요청을 etcd 에 저장한 뒤 사후에 검사해 위반을 보고한다
• 요청의 속도를 제한해 과부하를 막는 것만 담당한다

ValidatingAdmissionWebhook 의 failurePolicy: Ignore 가 만드는 위험은?

• 웹훅이 응답하지 않으면 검사 없이 요청이 통과해 정책이 조용히 비워진다
• 웹훅이 응답하지 않으면 클러스터의 모든 쓰기가 멈춘다
• 웹훅이 거부한 요청도 강제로 통과된다
• 웹훅이 오브젝트를 변형할 수 있게 되어 예상 밖의 값이 저장된다

컨트롤 플레인 노드에서 정적 파드(static pod) 매니페스트 디렉터리의 쓰기 권한이 중요한 이유는?

• 그 디렉터리에 파일을 쓸 수 있으면 apiserver 를 거치지 않고 원하는 파드를 실행시킬 수 있다
• 그 디렉터리가 손상되면 etcd 데이터가 함께 사라진다
• 그 디렉터리의 권한이 파드의 securityContext 기본값을 결정한다
• 그 디렉터리를 통해 클러스터의 감사 정책이 배포된다

파드 스펙의 automountServiceAccountToken: false 를 쓰는 이유로 가장 적절한 것은?

• API 를 호출하지 않는 워크로드에 토큰을 두지 않아 탈취 시 쓸 거리를 없앤다
• 파드가 API 서버에 접속하는 속도를 높인다
• ServiceAccount 를 아예 만들지 않아도 되게 한다
• 파드가 다른 네임스페이스의 Secret 을 읽을 수 있게 한다

NetworkPolicy 를 하나도 만들지 않은 네임스페이스의 기본 통신 상태는?

• 같은 네임스페이스 안에서만 통신이 허용된다
• 모든 파드가 모든 파드와 자유롭게 통신할 수 있다
• 모든 통신이 차단되어 있고 정책으로 열어야 한다
• 인그레스는 열려 있고 이그레스만 차단되어 있다

NetworkPolicy 로 막을 수 없는 것은?

• 특정 라벨을 가진 파드에서 들어오는 인그레스
• 지정한 CIDR 이외로 나가는 이그레스
• 허용된 연결 안에서 오가는 HTTP 요청 본문의 내용
• 특정 포트와 프로토콜로 들어오는 연결

securityContext.runAsNonRoot: true 만 설정하고 이미지가 root 로 실행되도록 만들어져 있으면?

• kubelet 이 사용자를 자동으로 비특권 사용자로 바꿔 실행한다
• 컨테이너가 시작을 거부당하고 파드가 실행되지 않는다
• 경고만 남고 root 로 그대로 실행된다
• 이미지가 다시 빌드되어 사용자만 바뀐 상태로 실행된다

allowPrivilegeEscalation: false 가 실제로 막는 것은?

• 컨테이너가 호스트의 네트워크 namespace 를 쓰는 것
• 자식 프로세스가 setuid 바이너리 등으로 부모보다 더 많은 권한을 얻는 것
• 파드가 다른 네임스페이스의 오브젝트를 읽는 것
• 컨테이너가 볼륨에 쓰기를 수행하는 것

리눅스 capability 를 다룰 때 권장되는 방식은?

• 모두 drop 한 뒤 꼭 필요한 것만 add 한다
• 기본값을 그대로 두고 문제가 생기면 그때 drop 한다
• NET_ADMIN 과 SYS_ADMIN 을 미리 add 해 두어 예외를 없앤다
• privileged 를 켜서 capability 를 신경 쓰지 않게 한다

hostPID: true 를 설정한 파드가 갖게 되는 능력은?

• 노드의 모든 프로세스를 볼 수 있고 접근 가능하면 그 프로세스에 신호를 보낼 수 있다
• 노드의 파일시스템 전체를 읽고 쓸 수 있다
• 노드의 네트워크 인터페이스를 그대로 쓸 수 있다
• 노드의 커널 모듈을 적재할 수 있다

Secret 을 환경변수 대신 볼륨으로 마운트하라고 권하는 이유로 가장 적절한 것은?

• 환경변수는 자식 프로세스로 상속되고 크래시 덤프나 프로세스 정보로 노출되기 쉽기 때문
• 환경변수로 주입한 값은 암호화되지 않고 볼륨은 암호화되기 때문
• 환경변수는 길이 제한이 있어 인증서를 담을 수 없기 때문
• 환경변수로 주입하면 apiserver 가 Secret 을 평문으로 저장하기 때문

쿠버네티스 Secret 의 base64 인코딩에 대한 올바른 이해는?

• 대칭키 암호화의 일종이라 키가 없으면 읽을 수 없다
• 단순한 인코딩이라 누구나 되돌릴 수 있고 기밀성을 제공하지 않는다
• 해시 함수라 원본을 복원할 수 없다
• 전송 구간을 보호하기 위한 서명 방식이다

RBAC 에서 get, list, watch 를 모두 허용할 때 특히 주의할 점은?

• list 와 watch 는 오브젝트 전체를 돌려주므로 이름을 몰라도 내용을 통째로 읽을 수 있다
• get 만 있으면 이름을 알아도 내용을 읽을 수 없다
• watch 는 읽기가 아니라 쓰기 동사로 분류된다
• 세 동사는 resourceNames 로 제한할 때 모두 동일하게 동작한다

감사 로그(audit log)의 레벨 중 요청 본문과 응답 본문을 모두 기록하는 것은?

• Metadata
• Request
• RequestResponse
• None

ResourceQuota 와 LimitRange 를 보안 관점에서 쓰는 이유는?

• 네임스페이스 하나가 클러스터 자원을 독점해 다른 워크로드를 굶기는 일을 막는다
• 파드가 다른 네임스페이스의 오브젝트를 읽지 못하게 막는다
• 컨테이너 이미지의 취약점을 검사한다
• 파드 사이의 네트워크 통신을 제한한다

감사 로그를 apiserver 노드의 로컬 파일로만 남길 때의 약점은?

• 그 노드를 장악한 공격자가 자기 흔적을 지울 수 있다
• 감사 로그가 etcd 를 가득 채워 클러스터가 멈춘다
• 감사 로그가 평문이라 전송 중 도청된다
• 감사 로그의 시간대가 노드마다 달라진다

STRIDE 의 Spoofing 위협에 대응하는 쿠버네티스의 통제로 가장 적절한 것은?

• ResourceQuota 로 네임스페이스 사용량을 제한한다
• 감사 로그에 요청을 기록한다
• readOnlyRootFilesystem 으로 파일 변조를 막는다
• 상호 TLS 와 강한 인증으로 요청자의 신원을 검증한다

컨테이너 탈출(container escape)로 이어질 가능성이 가장 높은 설정은?

• 파드에 리소스 limits 를 지정하지 않은 경우
• 파드가 ClusterIP 서비스로 노출된 경우
• 파드가 privileged 로 실행되며 호스트 경로를 마운트한 경우
• 파드의 복제본 수가 하나뿐인 경우

공격자가 파드 안에서 코드 실행에 성공했을 때 가장 먼저 노리는 것으로 알려진 대상은?

• 마운트된 ServiceAccount 토큰과 환경변수 속의 자격증명
• 컨테이너 이미지의 레이어 구조와 빌드 시각 정보
• 노드의 커널 버전과 배포판 이름 같은 시스템 정보
• 파드에 붙은 라벨과 어노테이션의 메타데이터

클라우드 메타데이터 서비스로의 접근을 파드에서 막아야 하는 이유는?

• 메타데이터 서비스가 파드의 로그를 외부로 전송하기 때문
• 메타데이터 서비스가 파드의 DNS 해석을 가로채기 때문
• 메타데이터 서비스 접근이 노드의 CPU 를 크게 소모하기 때문
• 메타데이터 서비스에서 노드에 붙은 클라우드 역할의 자격증명을 받아 클러스터 밖 자원까지 넘볼 수 있기 때문

권한 상승 경로 중 '노드 접근을 통한 상승'에 해당하는 것은?

• RBAC 의 bind 동사를 이용해 더 강한 ClusterRole 을 자신에게 연결한다
• 어드미션 웹훅을 등록해 새로 만들어지는 파드를 변형한다
• CRD 를 등록해 새 리소스 종류를 추가한다
• 노드에 스케줄된 다른 파드의 Secret 볼륨을 kubelet 의 디렉터리에서 읽는다

공급망 공격 중 '의존성 혼동(dependency confusion)'을 가장 정확히 설명한 것은?

• 빌드 서버가 감염되어 산출물에 악성 코드가 삽입되는 것
• 이미지 태그를 바꿔치기해 다른 이미지를 배포하게 하는 것
• 내부 전용 패키지와 같은 이름의 패키지를 공개 저장소에 올려 빌드가 그것을 당겨 가게 하는 것
• 레지스트리 자격증명을 훔쳐 이미지를 몰래 내려받는 것

클러스터에 지속성을 확보하려는 공격자가 어드미션 웹훅을 노리는 이유는?

• 웹훅이 감사 로그를 남기지 않아 흔적이 사라지기 때문
• 웹훅이 etcd 에 직접 접근할 수 있기 때문
• 웹훅이 노드의 커널 파라미터를 바꿀 수 있기 때문
• 웹훅이 새로 만들어지는 모든 오브젝트를 변형할 수 있어 지워도 다시 심을 수 있기 때문

이미지에 취약점 스캔을 붙였는데도 놓치기 쉬운 위험은?

• 베이스 이미지에 포함된 오래된 시스템 라이브러리
• 애플리케이션 의존성의 알려진 CVE
• 이미지 안에 커밋된 자격증명 같은 비밀값
• 이미지에 포함된 취약한 인터프리터 버전

임시 컨테이너(ephemeral container)를 디버깅에 쓸 때 보안상 유의할 점은?

• 대상 파드의 namespace 를 공유하므로 그 파드의 프로세스와 파일에 접근할 수 있다
• 대상 파드를 재시작시키므로 서비스가 잠시 끊긴다
• 대상 파드의 이미지가 교체되어 원래 버전을 알 수 없게 된다
• 감사 로그에 남지 않아 사용 이력을 추적할 수 없다

런타임 탐지 도구가 빌드 시점 검사와 다르게 잡아낼 수 있는 것은?

• 이미지에 들어 있는 취약한 패키지 버전
• 매니페스트의 잘못된 securityContext 설정
• 실행 중 컨테이너가 셸을 띄우거나 예상 밖의 파일에 접근하는 행위
• Dockerfile 에 남은 하드코딩된 토큰

Pod Security Admission 의 세 모드 중 warn 이 하는 일은?

• 위반 파드를 거부하고 이유를 응답에 담는다
• 위반 사실을 감사 로그의 어노테이션으로만 남긴다
• 위반 사실을 요청자에게 경고 메시지로 돌려주되 생성은 허용한다
• 위반 파드를 생성한 뒤 일정 시간이 지나면 삭제한다

Pod Security Standards 의 세 프로파일 중 baseline 의 위치로 올바른 것은?

• 아무 제약이 없는 가장 느슨한 프로파일이다
• 가장 엄격해 비특권 실행과 capability 제거까지 요구한다
• 알려진 권한 상승을 막되 흔한 워크로드가 대부분 통과하도록 만든 중간 프로파일이다
• 네임스페이스가 아니라 파드마다 개별 지정해야 하는 프로파일이다

PSA 를 네임스페이스 라벨로 적용할 때의 한계로 올바른 것은?

• 네임스페이스를 새로 만들면 라벨이 자동으로 사라진다
• 라벨을 붙여도 kubelet 이 무시할 수 있다
• 한 네임스페이스에는 하나의 모드만 지정할 수 있다
• 이미지 출처나 레지스트리 같은 파드 보안 표준 밖의 조건은 검사하지 못한다

이미지 서명 검증을 어드미션 단계에서 강제하면 얻는 것은?

• 이미지 안의 취약점이 자동으로 제거된다
• 이미지 크기가 줄어 배포가 빨라진다
• 신뢰하는 파이프라인이 만들지 않은 이미지가 클러스터에 들어오지 못한다
• 이미지가 실행 중에 변조되어도 즉시 탐지된다

외부 시크릿 관리 시스템(Vault 등)을 연동해도 남는 위험은?

• 외부 시스템이 값을 암호화해 저장하지 않는다
• 쿠버네티스가 외부 시스템을 지원하지 않아 연동 자체가 불가능하다
• 외부 시스템을 쓰면 시크릿 회전을 할 수 없게 된다
• 값을 가져올 권한을 가진 워크로드가 침해되면 결국 평문 시크릿에 닿는다

노드 자체를 강화하는 조치로 가장 적절한 것은?

• 노드에 개발자용 SSH 계정을 만들어 두어 조사에 대비한다
• 노드에 특권 컨테이너를 상시 띄워 두어 문제를 즉시 고칠 수 있게 한다
• 불필요한 패키지와 서비스를 제거하고 kubelet 설정 파일의 권한을 좁힌다
• 노드의 방화벽을 꺼서 진단을 쉽게 한다

gVisor 나 Kata Containers 같은 샌드박스 런타임을 쓰는 이유는?

• 컨테이너 이미지의 크기를 줄이기 위해
• 컨테이너 시작 시간을 단축하기 위해
• 여러 노드의 컨테이너를 하나로 묶어 관리하기 위해
• 호스트 커널과 워크로드 사이에 층을 하나 더 두어 커널 취약점의 영향을 줄이기 위해

RuntimeClass 의 역할로 올바른 것은?

• 파드가 쓸 수 있는 최대 CPU 와 메모리를 정한다
• 파드가 접근할 수 있는 네트워크 대역을 정한다
• 파드가 어떤 컨테이너 런타임 설정으로 실행될지 고르게 한다
• 파드의 이미지를 어느 레지스트리에서 받을지 정한다

멀티 테넌트 클러스터에서 테넌트 사이의 격리를 강화하는 조합으로 가장 적절한 것은?

• 네임스페이스만 나누고 나머지는 기본값으로 둔다
• 모든 테넌트를 하나의 네임스페이스에 두고 라벨로만 구분한다
• 테넌트마다 별도의 kubeconfig 파일만 나눠 준다
• 네임스페이스, RBAC, NetworkPolicy, 쿼터, 그리고 필요하면 노드 분리까지 함께 쓴다

OPA Gatekeeper 나 Kyverno 같은 정책 엔진이 PSA 위에 필요한 이유는?

• PSA 가 어드미션 단계에서 동작하지 않기 때문
• PSA 가 네임스페이스 단위로 적용되지 않기 때문
• PSA 가 파드 이외의 리소스와 조직 고유 규칙을 다루지 못하기 때문
• PSA 가 위반을 거부하지 못하고 경고만 남기기 때문

CIS Kubernetes Benchmark 를 가장 정확히 설명한 것은?

• 공격자의 행위를 전술과 기법으로 분류한 지식 베이스다
• 쿠버네티스 취약점에 번호를 부여하는 공식 데이터베이스다
• 클라우드 제공자가 준수해야 하는 법적 규제다
• 클러스터 구성 요소의 설정을 점검하는 항목별 권고와 검증 절차의 모음이다

NSA/CISA 쿠버네티스 하드닝 가이드가 강조하는 축으로 보기 어려운 것은?

• 파드 보안 강화와 네트워크 분리
• 인증·인가와 감사 로깅
• 지속적인 업데이트와 취약점 점검
• 단일 벤더 제품 도입을 통한 표준화

MITRE ATT&CK for Containers 를 실무에서 쓰는 방법으로 가장 적절한 것은?

• 클러스터 설정이 기준을 충족하는지 항목별로 점검하는 체크리스트로 쓴다
• 취약점의 심각도 점수를 계산하는 공식으로 쓴다
• 알려진 공격 기법 목록에 대해 우리 탐지와 통제가 어디까지 닿는지 지도로 그린다
• 감사 로그의 보존 기간을 정하는 규정으로 쓴다

컴플라이언스 자동화 도구가 클러스터에서 하는 일로 가장 적절한 것은?

• 발견된 위반을 자동으로 고쳐 클러스터를 즉시 기준에 맞춘다
• 규제 기관에 보고서를 직접 제출한다
• 위반이 발견되면 해당 워크로드를 삭제한다
• 정해진 기준에 대해 현재 설정을 주기적으로 검사하고 통과·실패를 증거와 함께 남긴다

감사 정책(audit policy)을 설계할 때 흔한 실수는?

• 읽기 요청은 기록하고 쓰기 요청은 제외하는 것
• 네임스페이스별로 서로 다른 레벨을 지정하는 것
• 모든 리소스에 가장 자세한 레벨을 걸어 저장 비용이 폭발하고 민감한 값까지 로그로 새는 것
• 인증 실패 요청을 기록 대상에 포함하는 것

보안 기준을 통과했다는 보고서가 있는데도 사고가 나는 이유로 가장 설득력 있는 것은?

• 보안 기준이 서로 모순되는 항목을 담고 있기 때문
• 기준을 통과하면 로그를 남기지 않아도 되기 때문
• 기준을 통과한 클러스터는 감시 대상에서 제외되기 때문
• 기준은 점검한 시점의 설정만 보증하고 그 뒤의 변경과 기준 밖의 위험은 담지 못하기 때문