Split View: [Golden Kubestronaut] CKS 추가 실전 문제 30제 - 고급 보안 시나리오
[Golden Kubestronaut] CKS 추가 실전 문제 30제 - 고급 보안 시나리오
CKS 추가 실전 문제 30제 - 고급 보안 시나리오
CKS 시험에서 출제되는 고급 보안 시나리오를 중심으로 구성한 추가 30문제입니다. Falco, Trivy, OPA/Gatekeeper, AppArmor/Seccomp, Pod Security Standards, RuntimeClass, 감사 정책, 공급망 보안 등을 다룹니다.
문제 1~10: Falco, 이미지 스캐닝, OPA/Gatekeeper
문제 1: Falco의 주요 역할은?
Kubernetes 환경에서 Falco의 주요 역할은 무엇입니까?
A) 컨테이너 이미지의 취약점을 스캔한다 B) 런타임에 시스템 콜을 모니터링하여 비정상적인 활동을 감지하고 경고한다 C) 네트워크 정책을 자동 생성한다 D) Pod의 리소스 사용량을 제한한다
정답: B
Falco는 Linux 커널의 시스템 콜을 실시간으로 모니터링하는 런타임 보안 도구입니다. 컨테이너 내 쉘 실행, 민감한 파일 읽기, 네트워크 연결 등 비정상적인 활동을 감지하여 경고합니다. eBPF 또는 커널 모듈을 사용하여 동작합니다.
문제 2: Falco 규칙에서 condition 필드의 역할은?
Falco 규칙의 condition 필드는 어떤 목적으로 사용됩니까?
A) 경고 메시지의 형식을 정의한다 B) 시스템 콜 이벤트를 필터링하는 조건식을 정의하여 어떤 이벤트가 규칙에 매칭되는지 결정한다 C) 규칙의 우선순위를 설정한다 D) 출력 채널을 지정한다
정답: B
condition은 Sysdig 필터 문법을 사용하여 이벤트 매칭 조건을 정의합니다. 예를 들어 container.id != host and proc.name = bash는 컨테이너 내에서 bash 프로세스가 실행되는 것을 감지합니다. syscall, process, file, network 관련 필드를 조합할 수 있습니다.
문제 3: Falco에서 특정 컨테이너의 쉘 실행을 감지하려면?
Falco 규칙으로 컨테이너 내부에서 쉘(bash, sh)이 실행되는 것을 감지하려면 어떤 condition을 사용해야 합니까?
A) fd.name contains /bin/bash B) container.id != host and proc.name in (bash, sh, zsh) and evt.type = execve C) k8s.pod.name exists D) syscall.type = open
정답: B
container.id != host로 컨테이너 환경을 필터링하고, proc.name으로 쉘 프로세스를 지정하며, evt.type = execve로 프로세스 실행 이벤트를 감지합니다. 이 조합으로 컨테이너 내 대화형 쉘 접근을 효과적으로 탐지할 수 있습니다.
문제 4: Trivy로 컨테이너 이미지 취약점을 스캔하는 방법은?
Trivy를 사용하여 컨테이너 이미지의 HIGH/CRITICAL 취약점만 확인하려면?
A) trivy image IMAGE_NAME 만 실행하면 된다 B) trivy image --severity HIGH,CRITICAL IMAGE_NAME으로 심각도를 필터링한다 C) trivy scan --level=high 명령을 사용한다 D) docker scan 명령만 사용 가능하다
정답: B
trivy image --severity HIGH,CRITICAL 플래그를 사용하면 지정된 심각도의 취약점만 표시합니다. --exit-code 1을 추가하면 취약점이 발견될 때 CI/CD 파이프라인을 실패시킬 수 있습니다. --ignore-unfixed로 수정 가능한 취약점만 표시할 수도 있습니다.
문제 5: Trivy와 Grype의 차이점은?
Trivy와 Grype 모두 이미지 스캐닝 도구입니다. 주요 차이점은?
A) 둘 다 완전히 동일한 도구이다 B) Trivy는 이미지, 파일시스템, Git 저장소, IaC 등 다양한 대상을 스캔하고, Grype는 주로 이미지와 SBOM 기반 취약점 스캔에 특화되어 있다 C) Grype는 런타임 보안 도구이다 D) Trivy는 네트워크 스캐닝 도구이다
정답: B
Trivy는 Aqua Security가 개발한 종합 보안 스캐너로 이미지, 파일시스템, IaC, Secret 스캔 등을 지원합니다. Grype는 Anchore가 개발한 도구로 이미지 및 SBOM 기반 취약점 스캔에 집중합니다. 둘 다 CKS 시험에서 다룰 수 있는 도구입니다.
문제 6: OPA Gatekeeper의 ConstraintTemplate 역할은?
OPA Gatekeeper에서 ConstraintTemplate의 역할은 무엇입니까?
A) Kubernetes 리소스를 직접 생성한다 B) Rego 언어로 작성된 정책 로직을 정의하며, 이를 기반으로 Constraint 리소스를 생성할 수 있게 한다 C) NetworkPolicy를 자동 생성한다 D) RBAC 규칙을 관리한다
정답: B
ConstraintTemplate은 정책의 스키마와 Rego 로직을 정의합니다. 이를 기반으로 Constraint 리소스를 생성하면 특정 조건에서 리소스 생성/수정을 제한할 수 있습니다. 예를 들어 privileged 컨테이너 금지, 특정 레지스트리만 허용 등의 정책을 구현합니다.
문제 7: OPA Gatekeeper에서 Constraint와 ConstraintTemplate의 관계는?
ConstraintTemplate과 Constraint의 관계에 대해 올바른 설명은?
A) Constraint가 정책 로직을 포함한다 B) ConstraintTemplate이 정책 로직(Rego)을 정의하고, Constraint가 해당 템플릿의 인스턴스로 구체적인 매개변수와 적용 범위를 지정한다 C) 둘은 독립적이며 관계가 없다 D) Constraint는 네임스페이스 단위로만 적용된다
정답: B
ConstraintTemplate은 재사용 가능한 정책 템플릿(Rego 코드 포함)이고, Constraint는 해당 템플릿의 인스턴스입니다. Constraint에서 match 필드로 적용 대상(네임스페이스, 리소스 종류 등)을 지정하고, parameters로 정책의 구체적인 값을 설정합니다.
문제 8: OPA Gatekeeper에서 dry-run 모드의 용도는?
Gatekeeper Constraint를 dry-run 모드로 설정하면?
A) 정책이 완전히 비활성화된다 B) 정책 위반을 감지하고 로그에 기록하지만, 실제로 리소스 생성/수정을 차단하지는 않는다 C) 정책이 강제 적용된다 D) 테스트 네임스페이스에만 적용된다
정답: B
Constraint의 enforcementAction을 dryrun으로 설정하면 정책 위반 시 리소스를 차단하지 않고 위반 사항만 기록합니다. 새 정책을 프로덕션에 적용하기 전에 영향도를 파악하는 데 유용합니다. deny는 차단, warn은 경고만 표시합니다.
문제 9: 이미지 다이제스트를 사용하는 이유는?
컨테이너 이미지를 태그 대신 다이제스트(sha256 해시)로 참조하는 이유는?
A) 이미지 다운로드 속도가 빨라진다 B) 동일한 태그에 다른 이미지가 푸시되는 태그 변조를 방지하고, 정확히 검증된 이미지를 사용하도록 보장한다 C) 이미지 크기가 줄어든다 D) 레지스트리 인증이 불필요해진다
정답: B
태그는 변경 가능하므로 같은 태그에 다른 이미지가 푸시될 수 있습니다(태그 변조). 다이제스트는 이미지 내용의 해시값이므로 내용이 변경되면 다이제스트도 변경됩니다. 이를 통해 서명된 정확한 이미지를 사용하는 것을 보장할 수 있습니다.
문제 10: OPA Gatekeeper로 특정 레지스트리만 허용하려면?
클러스터에서 특정 컨테이너 레지스트리(예: myregistry.io)의 이미지만 사용하도록 제한하려면?
A) NetworkPolicy로 레지스트리 접근을 차단한다 B) ConstraintTemplate에서 이미지 이름 접두사를 검사하는 Rego 정책을 작성하고, Constraint에서 허용 레지스트리 목록을 지정한다 C) kubelet 설정에서 레지스트리를 제한한다 D) Pod에 annotation을 추가한다
정답: B
ConstraintTemplate에서 컨테이너 이미지의 접두사가 허용 목록에 있는지 검사하는 Rego 코드를 작성합니다. Constraint에서 parameters로 허용 레지스트리 목록(예: myregistry.io)을 지정하면, 해당 레지스트리 이외의 이미지를 사용하는 Pod 생성이 거부됩니다.
문제 11~20: AppArmor, Seccomp, Pod Security Standards, RuntimeClass
문제 11: AppArmor 프로파일을 Pod에 적용하는 방법은?
Kubernetes에서 AppArmor 프로파일을 컨테이너에 적용하려면?
A) Pod의 securityContext에 직접 설정한다 B) 컨테이너의 securityContext.appArmorProfile 필드에 프로파일 타입과 이름을 지정한다(Kubernetes 1.30+) C) ConfigMap에 프로파일을 저장한다 D) 클러스터 전체에 한 번만 설정하면 된다
정답: B
Kubernetes 1.30+에서는 securityContext.appArmorProfile 필드를 사용합니다. type에 Localhost, RuntimeDefault 등을 지정하고, Localhost인 경우 localhostProfile에 프로파일 이름을 지정합니다. 프로파일은 해당 노드에 미리 로드되어 있어야 합니다.
문제 12: Seccomp 프로파일의 역할은?
Seccomp(Secure Computing Mode) 프로파일의 주요 역할은?
A) 네트워크 트래픽을 필터링한다 B) 컨테이너가 사용할 수 있는 Linux 시스템 콜을 제한하여 공격 표면을 줄인다 C) 파일 시스템 접근을 제어한다 D) CPU 사용량을 제한한다
정답: B
Seccomp은 컨테이너 프로세스가 호출할 수 있는 시스템 콜을 제한합니다. RuntimeDefault 프로파일은 일반적으로 안전하지 않은 시스템 콜을 차단합니다. 커스텀 프로파일을 만들어 특정 앱에 필요한 시스템 콜만 허용할 수도 있습니다.
문제 13: Pod에 Seccomp 프로파일을 적용하는 방법은?
Pod의 모든 컨테이너에 RuntimeDefault Seccomp 프로파일을 적용하려면?
A) Node에 설정해야 한다 B) Pod spec의 securityContext.seccompProfile에 type: RuntimeDefault를 설정한다 C) DaemonSet으로 배포해야 한다 D) kube-proxy에 설정한다
정답: B
Pod 수준의 securityContext.seccompProfile에 type: RuntimeDefault를 설정하면 모든 컨테이너에 적용됩니다. 컨테이너 수준에서도 개별 설정이 가능하며 컨테이너 설정이 Pod 설정보다 우선합니다. Localhost 타입으로 커스텀 프로파일도 사용 가능합니다.
문제 14: Pod Security Standards의 3가지 레벨은?
Kubernetes Pod Security Standards에서 정의하는 3가지 보안 레벨은?
A) Low, Medium, High B) Privileged, Baseline, Restricted C) Basic, Standard, Enterprise D) None, Default, Strict
정답: B
Pod Security Standards는 Privileged(제한 없음), Baseline(알려진 권한 상승 방지), Restricted(강화된 보안 모범 사례)의 3단계입니다. Baseline은 hostNetwork, privileged 컨테이너 등을 금지하고, Restricted는 추가로 root 실행, 권한 상승 등을 금지합니다.
문제 15: Pod Security Admission을 네임스페이스에 적용하는 방법은?
특정 네임스페이스에 Restricted 수준의 Pod Security를 적용하려면?
A) CRD를 생성해야 한다 B) 네임스페이스에 pod-security.kubernetes.io/enforce: restricted 레이블을 추가한다 C) 클러스터 전체 설정만 가능하다 D) Pod에 annotation을 추가한다
정답: B
네임스페이스에 pod-security.kubernetes.io/enforce 레이블을 설정하면 해당 수준을 초과하는 Pod 생성이 거부됩니다. enforce 외에 audit(감사 로그 기록)과 warn(경고 표시) 모드도 있습니다. 버전도 함께 지정할 수 있습니다(예: pod-security.kubernetes.io/enforce-version: v1.30).
문제 16: RuntimeClass의 용도는?
Kubernetes RuntimeClass는 어떤 목적으로 사용됩니까?
A) Pod의 네트워크 설정을 관리한다 B) 컨테이너 런타임 핸들러를 선택하여 gVisor, Kata Containers 등 다양한 격리 수준의 런타임을 Pod별로 지정할 수 있게 한다 C) 이미지 레지스트리를 관리한다 D) 스토리지 클래스를 관리한다
정답: B
RuntimeClass를 사용하면 Pod가 사용할 컨테이너 런타임을 선택할 수 있습니다. 예를 들어 보안이 중요한 워크로드에 gVisor나 Kata Containers를 사용하고, 일반 워크로드에는 runc를 사용하는 식으로 런타임을 분리할 수 있습니다.
문제 17: gVisor와 Kata Containers의 차이는?
gVisor와 Kata Containers의 격리 방식 차이는?
A) 둘 다 동일한 방식으로 동작한다 B) gVisor는 사용자 공간에서 Linux 커널을 에뮬레이션하고, Kata Containers는 경량 가상 머신(VM) 내에서 컨테이너를 실행한다 C) gVisor는 VM을 사용하고 Kata는 네임스페이스를 사용한다 D) 둘 다 eBPF 기반이다
정답: B
gVisor(runsc)는 Go로 작성된 사용자 공간 커널로, 시스템 콜을 인터셉트하여 제한된 커널 인터페이스를 제공합니다. Kata Containers는 각 컨테이너를 경량 VM에서 실행하여 하드웨어 레벨 격리를 제공합니다. 둘 다 runc보다 강한 격리를 제공하지만 오버헤드가 있습니다.
문제 18: RuntimeClass를 Pod에 적용하는 방법은?
Pod가 gVisor 런타임을 사용하도록 설정하려면?
A) 노드에 레이블을 추가한다 B) RuntimeClass 리소스를 생성하고, Pod spec의 runtimeClassName 필드에 해당 RuntimeClass 이름을 지정한다 C) kubelet 설정만 변경한다 D) 모든 Pod가 자동으로 gVisor를 사용한다
정답: B
먼저 RuntimeClass 리소스를 생성하여 handler(예: runsc)를 지정합니다. 그런 다음 Pod spec의 runtimeClassName 필드에 해당 RuntimeClass 이름을 지정하면 해당 런타임으로 컨테이너가 실행됩니다. 노드에 해당 런타임이 설치되어 있어야 합니다.
문제 19: AppArmor와 SELinux의 차이는?
AppArmor와 SELinux의 주요 차이점은?
A) 둘 다 동일한 방식으로 동작한다 B) AppArmor는 경로 기반 접근 제어를 사용하고, SELinux는 레이블 기반 접근 제어(MAC)를 사용한다 C) SELinux가 더 단순하다 D) AppArmor는 네트워크만 제어한다
정답: B
AppArmor는 파일 경로 기반으로 프로세스의 접근을 제어하며 프로파일 작성이 상대적으로 쉽습니다. SELinux는 모든 파일, 프로세스, 포트에 보안 레이블을 할당하여 레이블 기반 강제 접근 제어(MAC)를 수행하며, 더 세밀한 제어가 가능하지만 복잡합니다.
문제 20: Pod Security Admission의 exempt 설정은?
Pod Security Admission에서 특정 사용자나 네임스페이스를 정책에서 제외하려면?
A) 제외는 불가능하다 B) PodSecurityConfiguration의 exemptions 필드에서 usernames, runtimeClasses, namespaces를 지정하여 예외를 설정한다 C) 네임스페이스를 삭제해야 한다 D) RBAC로만 제어 가능하다
정답: B
PodSecurityConfiguration(AdmissionConfiguration 파일)의 exemptions에서 특정 사용자, RuntimeClass, 네임스페이스를 정책 적용에서 제외할 수 있습니다. 시스템 컴포넌트나 특수한 워크로드가 보안 제한을 우회해야 할 때 사용합니다.
문제 21~30: 감사 정책, 인증서 순환, Secrets 암호화, CIS 벤치마크, 공급망 보안
문제 21: 감사 정책에서 omitStages 설정의 역할은?
Kubernetes 감사 정책에서 omitStages 필드의 용도는?
A) 특정 리소스를 로깅에서 제외한다 B) RequestReceived 등 특정 요청 처리 단계를 로깅에서 제외하여 로그 볼륨을 줄인다 C) 감사 로그를 비활성화한다 D) 특정 사용자를 제외한다
정답: B
omitStages를 사용하면 RequestReceived, ResponseStarted, ResponseComplete, Panic 중 특정 단계를 로깅에서 제외할 수 있습니다. 예를 들어 RequestReceived를 제외하면 요청 수신 시점의 로그를 생략하여 로그 볼륨을 줄일 수 있습니다.
문제 22: 감사 로그 백엔드의 종류는?
Kubernetes API 서버 감사 로그의 백엔드 종류는?
A) 파일 백엔드만 지원한다 B) 로그 백엔드(파일)와 Webhook 백엔드(외부 서비스)를 지원한다 C) 데이터베이스 백엔드만 지원한다 D) syslog만 지원한다
정답: B
Kubernetes는 로그 백엔드(--audit-log-path로 파일에 기록)와 Webhook 백엔드(--audit-webhook-config-file로 외부 HTTP 서비스에 전송)를 지원합니다. 두 백엔드를 동시에 사용할 수 있으며, 각각 별도의 정책 설정이 가능합니다.
문제 23: kubelet 인증서 자동 순환(rotation) 설정 방법은?
kubelet의 클라이언트 인증서가 자동으로 순환되도록 설정하려면?
A) 수동으로만 갱신 가능하다 B) kubelet 설정에서 rotateCertificates를 true로 설정하고, controller-manager에서 CSR 자동 승인을 활성화한다 C) etcd에서 인증서를 관리한다 D) 인증서는 만료되지 않는다
정답: B
kubelet의 rotateCertificates: true 설정은 인증서 만료 전에 자동으로 CSR(Certificate Signing Request)을 생성합니다. kube-controller-manager의 csrsigning 컨트롤러가 CSR을 자동 승인하면 새 인증서가 발급됩니다. serverTLSBootstrap도 함께 설정하면 서빙 인증서도 자동 순환됩니다.
문제 24: Secrets 암호화 at rest 설정 방법은?
etcd에 저장되는 Secret을 암호화하려면?
A) Secret을 base64로 인코딩하면 암호화된다 B) EncryptionConfiguration 파일을 생성하고 kube-apiserver에 --encryption-provider-config 플래그로 지정한다 C) etcd 자체가 자동으로 암호화한다 D) Secret 대신 ConfigMap을 사용한다
정답: B
EncryptionConfiguration 파일에서 암호화 프로바이더(aescbc, aesgcm, secretbox 등)와 키를 정의합니다. kube-apiserver 시작 시 --encryption-provider-config로 이 파일을 지정하면 지정된 리소스(secrets 등)가 etcd에 암호화되어 저장됩니다. base64는 인코딩일 뿐 암호화가 아닙니다.
문제 25: KMS(Key Management Service) 프로바이더의 장점은?
Secrets 암호화에서 KMS 프로바이더를 사용하는 이점은?
A) 설정이 더 간단하다 B) 암호화 키가 외부 KMS에서 관리되어 키 관리가 중앙화되고, 키 순환이 API 서버 재시작 없이 가능하다 C) 암호화 성능이 떨어진다 D) 추가 인프라가 불필요하다
정답: B
KMS 프로바이더를 사용하면 DEK(Data Encryption Key)는 로컬에서 생성하고, DEK를 암호화하는 KEK(Key Encryption Key)는 외부 KMS(AWS KMS, GCP KMS, HashiCorp Vault 등)에서 관리합니다. 키 순환 시 API 서버 재시작이 불필요하며 키 관리가 중앙화됩니다.
문제 26: CIS Kubernetes Benchmark의 용도는?
CIS(Center for Internet Security) Kubernetes Benchmark는 무엇입니까?
A) Kubernetes 성능 벤치마크 도구이다 B) Kubernetes 클러스터의 보안 설정에 대한 모범 사례 가이드라인으로, 컨트롤 플레인, 노드, 정책 등의 보안 구성을 검사한다 C) 네트워크 성능 테스트 도구이다 D) 이미지 빌드 가이드이다
정답: B
CIS Benchmark는 Kubernetes 컴포넌트(API 서버, etcd, kubelet, 스케줄러 등)의 보안 설정을 점검하는 가이드라인입니다. kube-bench 도구를 사용하여 자동으로 검사할 수 있으며, 각 항목에 대해 통과/실패/경고 결과를 제공합니다.
문제 27: kube-bench 도구의 역할은?
kube-bench는 어떤 목적으로 사용됩니까?
A) Kubernetes 클러스터의 부하 테스트를 수행한다 B) CIS Kubernetes Benchmark에 따라 클러스터 보안 설정을 자동으로 검사하고 결과를 보고한다 C) 이미지 취약점을 스캔한다 D) 런타임 보안을 모니터링한다
정답: B
kube-bench는 Aqua Security가 개발한 오픈소스 도구로, CIS Benchmark 항목을 자동으로 검사합니다. 컨트롤 플레인, 워커 노드, etcd 등의 설정을 점검하고, 실패 항목에 대한 수정 방법을 안내합니다. Job으로 클러스터 내에서 실행할 수 있습니다.
문제 28: 컨테이너 이미지 서명 및 검증(cosign)의 목적은?
cosign을 사용하여 컨테이너 이미지에 서명하는 목적은?
A) 이미지 크기를 줄인다 B) 이미지의 출처와 무결성을 검증하여 승인된 빌드 파이프라인에서 생성된 이미지만 배포되도록 보장한다 C) 이미지 다운로드 속도를 높인다 D) 이미지의 취약점을 제거한다
정답: B
cosign(Sigstore 프로젝트)으로 이미지에 서명하면, 배포 시 서명을 검증하여 이미지가 신뢰할 수 있는 소스에서 빌드되었고 변조되지 않았음을 확인할 수 있습니다. 정책 엔진(Kyverno, OPA 등)과 연동하면 서명되지 않은 이미지의 배포를 자동 차단할 수 있습니다.
문제 29: SBOM(Software Bill of Materials)의 역할은?
컨테이너 이미지의 SBOM을 생성하는 이유는?
A) 이미지 빌드를 자동화한다 B) 이미지에 포함된 모든 소프트웨어 패키지와 의존성 목록을 제공하여 취약점 관리와 라이선스 준수를 지원한다 C) 이미지를 압축한다 D) 이미지 레이어를 최적화한다
정답: B
SBOM은 컨테이너 이미지에 포함된 모든 패키지, 라이브러리, 의존성의 상세 목록입니다. 새 취약점이 발견되었을 때 영향받는 이미지를 빠르게 파악하고, 라이선스 준수 여부를 확인하는 데 활용됩니다. Syft, Trivy 등으로 생성할 수 있습니다.
문제 30: 공급망 보안에서 admission controller의 역할은?
Kubernetes 공급망 보안에서 admission controller를 활용하는 방법은?
A) 이미지 빌드를 담당한다 B) 이미지 서명 검증, 허용 레지스트리 검사, 취약점 스캔 결과 확인 등을 배포 시점에 자동으로 수행하여 미승인 이미지의 배포를 차단한다 C) CI/CD 파이프라인을 관리한다 D) 소스 코드를 스캔한다
정답: B
Validating Admission Webhook이나 정책 엔진(Kyverno, OPA Gatekeeper)을 사용하여 Pod 생성 시 이미지 서명 검증, 허용된 레지스트리 확인, 취약점 스캔 결과 기반 차단, 다이제스트 사용 강제 등의 검사를 자동으로 수행합니다. 이를 통해 공급망 공격을 방어할 수 있습니다.
[Golden Kubestronaut] CKS Extra 30 Practice Questions - Advanced Security Scenarios
CKS Extra 30 Practice Questions - Advanced Security Scenarios
These 30 additional questions focus on advanced security scenarios for the CKS exam. Topics include Falco, Trivy, OPA/Gatekeeper, AppArmor/Seccomp, Pod Security Standards, RuntimeClass, audit policies, and supply chain security.
Questions 1-10: Falco, Image Scanning, OPA/Gatekeeper
Question 1: What is the primary role of Falco?
What is the primary role of Falco in a Kubernetes environment?
A) Scanning container images for vulnerabilities B) Monitoring system calls at runtime to detect and alert on abnormal activities C) Automatically generating network policies D) Limiting Pod resource usage
Answer: B
Falco is a runtime security tool that monitors Linux kernel system calls in real-time. It detects abnormal activities such as shell execution within containers, reading sensitive files, and network connections. It operates using eBPF or kernel modules.
Question 2: What is the role of the condition field in Falco rules?
What is the purpose of the condition field in Falco rules?
A) Defining the format of alert messages B) Defining filter expressions for system call events to determine which events match the rule C) Setting rule priority D) Specifying output channels
Answer: B
The condition uses Sysdig filter syntax to define event matching criteria. For example, container.id != host and proc.name = bash detects bash process execution within containers. Fields related to syscalls, processes, files, and networks can be combined.
Question 3: How to detect shell execution in containers with Falco?
What condition should be used in a Falco rule to detect shell (bash, sh) execution inside containers?
A) fd.name contains /bin/bash B) container.id != host and proc.name in (bash, sh, zsh) and evt.type = execve C) k8s.pod.name exists D) syscall.type = open
Answer: B
container.id != host filters for container environments, proc.name specifies shell processes, and evt.type = execve detects process execution events. This combination effectively detects interactive shell access within containers.
Question 4: How to scan container image vulnerabilities with Trivy?
How do you check only HIGH/CRITICAL vulnerabilities in a container image using Trivy?
A) Just run trivy image IMAGE_NAME B) Filter by severity with trivy image --severity HIGH,CRITICAL IMAGE_NAME C) Use the trivy scan --level=high command D) Only docker scan is available
Answer: B
Using the --severity HIGH,CRITICAL flag shows only vulnerabilities of the specified severity. Adding --exit-code 1 can fail CI/CD pipelines when vulnerabilities are found. --ignore-unfixed shows only fixable vulnerabilities.
Question 5: What are the differences between Trivy and Grype?
Both Trivy and Grype are image scanning tools. What are the main differences?
A) They are completely identical tools B) Trivy scans various targets including images, filesystems, Git repos, and IaC, while Grype specializes in image and SBOM-based vulnerability scanning C) Grype is a runtime security tool D) Trivy is a network scanning tool
Answer: B
Trivy, developed by Aqua Security, is a comprehensive security scanner supporting images, filesystems, IaC, and Secret scanning. Grype, developed by Anchore, focuses on image and SBOM-based vulnerability scanning. Both tools can be covered in the CKS exam.
Question 6: What is the role of OPA Gatekeeper ConstraintTemplates?
What is the role of ConstraintTemplate in OPA Gatekeeper?
A) Directly creating Kubernetes resources B) Defining policy logic written in Rego language, enabling the creation of Constraint resources based on it C) Automatically generating NetworkPolicies D) Managing RBAC rules
Answer: B
ConstraintTemplate defines the policy schema and Rego logic. Creating Constraint resources based on it can restrict resource creation/modification under certain conditions. For example, prohibiting privileged containers or allowing only specific registries.
Question 7: What is the relationship between Constraint and ConstraintTemplate?
What is the correct description of the relationship between ConstraintTemplate and Constraint?
A) Constraint contains the policy logic B) ConstraintTemplate defines the policy logic (Rego), and Constraint is an instance of that template specifying concrete parameters and scope C) They are independent and unrelated D) Constraint only applies at the namespace level
Answer: B
ConstraintTemplate is a reusable policy template (containing Rego code), and Constraint is an instance of that template. In Constraint, the match field specifies targets (namespaces, resource kinds, etc.), and parameters set specific policy values.
Question 8: What is the purpose of dry-run mode in OPA Gatekeeper?
What happens when a Gatekeeper Constraint is set to dry-run mode?
A) The policy is completely disabled B) Policy violations are detected and logged but resource creation/modification is not actually blocked C) The policy is strictly enforced D) It only applies to test namespaces
Answer: B
Setting enforcementAction to dryrun in a Constraint logs violations without blocking resources. This is useful for assessing impact before applying new policies to production. deny blocks resources, and warn only displays warnings.
Question 9: Why use image digests?
Why reference container images by digest (sha256 hash) instead of tags?
A) Image download speed improves B) It prevents tag mutation where different images are pushed to the same tag, ensuring exactly the verified image is used C) Image size is reduced D) Registry authentication becomes unnecessary
Answer: B
Tags are mutable, so different images can be pushed to the same tag (tag mutation). Digests are hash values of image content, so the digest changes when content changes. This ensures that the exact signed image is used.
Question 10: How to allow only specific registries with OPA Gatekeeper?
How do you restrict the cluster to only use images from a specific container registry (e.g., myregistry.io)?
A) Block registry access with NetworkPolicy B) Write a Rego policy in ConstraintTemplate that checks image name prefixes, and specify allowed registries in the Constraint C) Restrict registries in kubelet configuration D) Add annotations to Pods
Answer: B
Write Rego code in the ConstraintTemplate to check whether container image prefixes are in the allowed list. Specify the allowed registry list (e.g., myregistry.io) in the Constraint parameters, and Pod creation with images from other registries will be denied.
Questions 11-20: AppArmor, Seccomp, Pod Security Standards, RuntimeClass
Question 11: How to apply AppArmor profiles to Pods?
How do you apply an AppArmor profile to a container in Kubernetes?
A) Set it directly in the Pod's securityContext B) Specify the profile type and name in the container's securityContext.appArmorProfile field (Kubernetes 1.30+) C) Store the profile in a ConfigMap D) Configure it once for the entire cluster
Answer: B
In Kubernetes 1.30+, use the securityContext.appArmorProfile field. Specify the type (Localhost, RuntimeDefault, etc.), and for Localhost, specify the profile name in localhostProfile. The profile must be pre-loaded on the target node.
Question 12: What is the role of Seccomp profiles?
What is the primary role of Seccomp (Secure Computing Mode) profiles?
A) Filtering network traffic B) Restricting Linux system calls available to containers to reduce the attack surface C) Controlling filesystem access D) Limiting CPU usage
Answer: B
Seccomp restricts the system calls that container processes can make. The RuntimeDefault profile blocks generally unsafe system calls. Custom profiles can be created to allow only system calls needed by specific applications.
Question 13: How to apply Seccomp profiles to Pods?
How do you apply the RuntimeDefault Seccomp profile to all containers in a Pod?
A) It must be configured on the Node B) Set type: RuntimeDefault in the Pod spec's securityContext.seccompProfile C) Deploy as a DaemonSet D) Configure in kube-proxy
Answer: B
Setting type: RuntimeDefault in the Pod-level securityContext.seccompProfile applies to all containers. Container-level settings are also possible and take precedence over Pod settings. Custom profiles with Localhost type are also supported.
Question 14: What are the 3 levels of Pod Security Standards?
What are the 3 security levels defined by Kubernetes Pod Security Standards?
A) Low, Medium, High B) Privileged, Baseline, Restricted C) Basic, Standard, Enterprise D) None, Default, Strict
Answer: B
Pod Security Standards has 3 levels: Privileged (unrestricted), Baseline (prevents known privilege escalations), and Restricted (hardened security best practices). Baseline prohibits hostNetwork, privileged containers, etc. Restricted additionally prohibits running as root, privilege escalation, etc.
Question 15: How to apply Pod Security Admission to a namespace?
How do you apply Restricted level Pod Security to a specific namespace?
A) Create a CRD B) Add the label pod-security.kubernetes.io/enforce: restricted to the namespace C) Only cluster-wide configuration is possible D) Add annotations to Pods
Answer: B
Setting the pod-security.kubernetes.io/enforce label on a namespace denies Pod creation that exceeds that level. Besides enforce, there are audit (audit log recording) and warn (warning display) modes. Version can also be specified (e.g., pod-security.kubernetes.io/enforce-version: v1.30).
Question 16: What is the purpose of RuntimeClass?
What is the purpose of Kubernetes RuntimeClass?
A) Managing Pod network configuration B) Selecting container runtime handlers to specify various isolation levels like gVisor or Kata Containers per Pod C) Managing image registries D) Managing storage classes
Answer: B
RuntimeClass allows Pods to select their container runtime. For example, security-critical workloads can use gVisor or Kata Containers while regular workloads use runc, separating runtimes by workload requirements.
Question 17: What is the difference between gVisor and Kata Containers?
What is the difference in isolation approach between gVisor and Kata Containers?
A) Both work the same way B) gVisor emulates the Linux kernel in user space, while Kata Containers runs containers inside lightweight VMs C) gVisor uses VMs and Kata uses namespaces D) Both are eBPF-based
Answer: B
gVisor (runsc) is a user-space kernel written in Go that intercepts system calls and provides a limited kernel interface. Kata Containers runs each container in a lightweight VM providing hardware-level isolation. Both provide stronger isolation than runc but with overhead.
Question 18: How to apply RuntimeClass to a Pod?
How do you configure a Pod to use the gVisor runtime?
A) Add labels to the node B) Create a RuntimeClass resource and specify that RuntimeClass name in the Pod spec's runtimeClassName field C) Only change kubelet configuration D) All Pods automatically use gVisor
Answer: B
First create a RuntimeClass resource specifying the handler (e.g., runsc). Then specify that RuntimeClass name in the Pod spec's runtimeClassName field to run containers with that runtime. The runtime must be installed on the node.
Question 19: What is the difference between AppArmor and SELinux?
What are the main differences between AppArmor and SELinux?
A) Both work the same way B) AppArmor uses path-based access control, while SELinux uses label-based mandatory access control (MAC) C) SELinux is simpler D) AppArmor only controls networking
Answer: B
AppArmor controls process access based on file paths and is relatively easier to write profiles for. SELinux assigns security labels to all files, processes, and ports for label-based mandatory access control (MAC), offering more granular control but with greater complexity.
Question 20: What is the exempt configuration in Pod Security Admission?
How do you exclude specific users or namespaces from Pod Security Admission policies?
A) Exclusion is not possible B) Specify usernames, runtimeClasses, and namespaces in the exemptions field of PodSecurityConfiguration C) The namespace must be deleted D) Only controllable through RBAC
Answer: B
In the PodSecurityConfiguration (AdmissionConfiguration file), the exemptions section can exclude specific users, RuntimeClasses, and namespaces from policy enforcement. This is used when system components or special workloads need to bypass security restrictions.
Questions 21-30: Audit Policy, Certificate Rotation, Secrets Encryption, CIS Benchmarks, Supply Chain Security
Question 21: What is the role of omitStages in audit policy?
What is the purpose of the omitStages field in Kubernetes audit policy?
A) Excluding specific resources from logging B) Excluding specific request processing stages like RequestReceived from logging to reduce log volume C) Disabling audit logging D) Excluding specific users
Answer: B
omitStages can exclude specific stages (RequestReceived, ResponseStarted, ResponseComplete, Panic) from logging. For example, excluding RequestReceived omits logs at the request reception point, reducing log volume.
Question 22: What types of audit log backends exist?
What types of backends are available for Kubernetes API server audit logs?
A) Only file backend is supported B) Log backend (file) and Webhook backend (external service) are supported C) Only database backend is supported D) Only syslog is supported
Answer: B
Kubernetes supports a Log backend (writing to file via --audit-log-path) and a Webhook backend (sending to external HTTP services via --audit-webhook-config-file). Both backends can be used simultaneously with separate policy configurations.
Question 23: How to configure kubelet certificate auto-rotation?
How do you set up automatic rotation of kubelet client certificates?
A) Only manual renewal is possible B) Set rotateCertificates to true in kubelet config and enable CSR auto-approval in controller-manager C) Manage certificates in etcd D) Certificates never expire
Answer: B
Setting rotateCertificates: true in kubelet automatically generates CSRs (Certificate Signing Requests) before certificate expiration. The kube-controller-manager's csrsigning controller auto-approves CSRs and issues new certificates. Setting serverTLSBootstrap also enables serving certificate auto-rotation.
Question 24: How to configure Secrets encryption at rest?
How do you encrypt Secrets stored in etcd?
A) Base64 encoding Secrets provides encryption B) Create an EncryptionConfiguration file and specify it with the --encryption-provider-config flag on kube-apiserver C) etcd automatically encrypts D) Use ConfigMap instead of Secret
Answer: B
Define encryption providers (aescbc, aesgcm, secretbox, etc.) and keys in the EncryptionConfiguration file. Specifying it with --encryption-provider-config at kube-apiserver startup encrypts specified resources (like secrets) in etcd. Base64 is encoding, not encryption.
Question 25: What are the benefits of KMS providers?
What benefits does using a KMS provider for Secrets encryption offer?
A) Simpler configuration B) Encryption keys are managed by external KMS, centralizing key management and enabling key rotation without API server restart C) Encryption performance decreases D) No additional infrastructure required
Answer: B
With KMS providers, DEKs (Data Encryption Keys) are generated locally, while KEKs (Key Encryption Keys) that encrypt DEKs are managed by external KMS (AWS KMS, GCP KMS, HashiCorp Vault, etc.). Key rotation does not require API server restart, and key management is centralized.
Question 26: What is the CIS Kubernetes Benchmark?
What is the CIS (Center for Internet Security) Kubernetes Benchmark?
A) A Kubernetes performance benchmark tool B) A best practice guideline for Kubernetes cluster security settings that inspects security configuration of control plane, nodes, and policies C) A network performance testing tool D) An image build guide
Answer: B
The CIS Benchmark is a guideline for checking security settings of Kubernetes components (API server, etcd, kubelet, scheduler, etc.). It can be automatically checked using the kube-bench tool, providing pass/fail/warning results for each item.
Question 27: What is the role of kube-bench?
What is kube-bench used for?
A) Performing load tests on Kubernetes clusters B) Automatically checking cluster security settings according to CIS Kubernetes Benchmark and reporting results C) Scanning image vulnerabilities D) Monitoring runtime security
Answer: B
kube-bench is an open-source tool by Aqua Security that automatically checks CIS Benchmark items. It inspects control plane, worker node, etcd, and other configurations, providing remediation guidance for failed items. It can be run as a Job within the cluster.
Question 28: What is the purpose of container image signing with cosign?
What is the purpose of signing container images with cosign?
A) Reducing image size B) Verifying image provenance and integrity to ensure only images from approved build pipelines are deployed C) Increasing image download speed D) Removing image vulnerabilities
Answer: B
Signing images with cosign (Sigstore project) allows verifying during deployment that images were built from trusted sources and were not tampered with. Integration with policy engines (Kyverno, OPA, etc.) can automatically block deployment of unsigned images.
Question 29: What is the role of SBOM (Software Bill of Materials)?
Why generate an SBOM for container images?
A) Automating image builds B) Providing a complete list of all software packages and dependencies in an image to support vulnerability management and license compliance C) Compressing images D) Optimizing image layers
Answer: B
An SBOM is a detailed inventory of all packages, libraries, and dependencies included in a container image. When new vulnerabilities are discovered, it helps quickly identify affected images and verify license compliance. It can be generated with tools like Syft and Trivy.
Question 30: What role do admission controllers play in supply chain security?
How are admission controllers used in Kubernetes supply chain security?
A) Handling image builds B) Automatically performing image signature verification, allowed registry checks, and vulnerability scan result validation at deployment time to block unauthorized images C) Managing CI/CD pipelines D) Scanning source code
Answer: B
Using Validating Admission Webhooks or policy engines (Kyverno, OPA Gatekeeper), automatic checks are performed at Pod creation including image signature verification, allowed registry confirmation, vulnerability scan result-based blocking, and digest usage enforcement. This helps defend against supply chain attacks.