CKS — Practice Questions

7 minute read

Introduction Practice Questions

Test your understanding of CKS fundamentals before diving into the technical chapters. These questions cover all six exam domains at an introductory level.

Scoring Guide:

  • 9–10 correct: You have a strong foundation — proceed to technical chapters
  • 7–8 correct: Good understanding, review the gaps
  • Below 7: Re-read the introduction topics before continuing

Q1: What is the prerequisite for taking the CKS exam?

Show Answer

You must hold a valid (non-expired) CKA certification at the time of CKS registration.

Key details:

  • CKAD is NOT sufficient — only CKA satisfies the requirement
  • CKA validity is 2 years from passing date
  • If your CKA has expired, you must renew it before registering for CKS
  • The registration system blocks you if no valid CKA is found

This is the only CNCF Kubernetes certification that has a prerequisite.

Q2: Name the 6 CKS exam domains with their weights.

Show Answer
# Domain Weight
1 Cluster Setup 10%
2 Cluster Hardening 15%
3 System Hardening 15%
4 Minimize Microservice Vulnerabilities 20%
5 Supply Chain Security 20%
6 Monitoring, Logging & Runtime Security 20%

Memory aid: The three domains at 20% (Microservice Vulns, Supply Chain, Runtime) cover 60% of the exam. The two at 15% (Cluster Hardening, System Hardening) cover 30%. Cluster Setup at 10% is the smallest.

Total: 100% Passing score: 67%

Q3: Which tool scans Kubernetes clusters for CIS benchmark compliance?

Show Answer

kube-bench

kube-bench runs automated checks against the CIS Kubernetes Benchmark, which defines security best practices for cluster configuration.

Usage:

# Scan control plane components
kube-bench run --targets=master

# Scan worker node components
kube-bench run --targets=node

# Run a specific check
kube-bench run --targets=master --check=1.2.6

Output categories:

  • PASS — Configuration meets the benchmark
  • FAIL — Configuration violates the benchmark (action required)
  • WARN — Manual review recommended
  • INFO — Informational only

kube-bench maps to the Cluster Setup (10%) exam domain.

Q4: What does Falco detect, and how does it work?

Show Answer

Falco detects runtime security threats by monitoring Linux system calls (syscalls) in real time.

How it works:

  1. Falco hooks into the Linux kernel to capture syscall events
  2. Each event is evaluated against a set of rules
  3. Matching events generate alerts (to stdout, syslog, files, or HTTP endpoints)

What Falco detects:

  • Shell spawned in a container — e.g., someone runs kubectl exec -it pod -- /bin/bash
  • Sensitive file access — Container reads /etc/shadow, /etc/passwd, or private keys
  • Unexpected network connections — Container makes outbound connections to unknown IPs
  • Binary modification — New executables written inside a running container
  • Privilege escalation — Process gains elevated capabilities
  • Cryptomining activity — Known mining process signatures detected

Key files:

  • /etc/falco/falco_rules.yaml — Default rules (do NOT edit)
  • /etc/falco/falco_rules.local.yaml — Custom rules (edit THIS file)

Falco maps to the Monitoring, Logging & Runtime Security (20%) exam domain.

Q5: What are the 3 Pod Security Standards levels, and what does each enforce?

Show Answer
Level Description Use Case
Privileged Unrestricted — no security restrictions applied System-level workloads (kube-system, monitoring agents)
Baseline Prevents known privilege escalations — blocks hostNetwork, hostPID, privileged containers General workloads that need some flexibility
Restricted Strictest — enforces current security best practices Sensitive workloads, multi-tenant environments

Restricted is the most secure and requires:

  • runAsNonRoot: true
  • allowPrivilegeEscalation: false
  • readOnlyRootFilesystem (recommended)
  • Drop ALL capabilities (can add back NET_BIND_SERVICE only)
  • seccompProfile.type: RuntimeDefault or Localhost
  • No hostPath volumes, hostNetwork, hostPID, or hostIPC

These standards are enforced via Pod Security Admission (PSA) using namespace labels:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Pod Security Standards map to the Minimize Microservice Vulnerabilities (20%) domain.

Q6: How do you enable encryption at rest for Secrets in a Kubernetes cluster?

Show Answer

You create an EncryptionConfiguration file and configure the API server to use it.

Step 1: Create the encryption configuration:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}  # Fallback for reading unencrypted data

Step 2: Add the flag to the API server:

--encryption-provider-config=/etc/kubernetes/enc/encryption-config.yaml

Step 3: Mount the config file in the API server static Pod manifest and restart.

Step 4: Re-encrypt existing Secrets:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Important: The identity: {} provider must be listed last — it allows the API server to read Secrets that were stored before encryption was enabled.

Encryption at rest maps to the Minimize Microservice Vulnerabilities (20%) and Cluster Hardening (15%) domains.

Q7: What admission controller enforces container image policies, and how does it work?

Show Answer

ImagePolicyWebhook is the built-in admission controller for enforcing image policies.

How it works:

  1. When a Pod is created, the API server sends an admission review request to an external webhook
  2. The webhook evaluates the container images against policy rules (e.g., allowed registries, required signatures, vulnerability scan results)
  3. The webhook returns allow or deny
  4. The API server enforces the decision

Configuration:

# Enable in API server flags
--enable-admission-plugins=...,ImagePolicyWebhook
--admission-control-config-file=/etc/kubernetes/admission/config.yaml

Alternatively, OPA Gatekeeper and Kyverno can enforce image policies via validating admission webhooks:

# Kyverno example: restrict to approved registries
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-registries
    match:
      any:
      - resources:
          kinds: ["Pod"]
    validate:
      message: "Images must come from approved registries."
      pattern:
        spec:
          containers:
          - image: "myregistry.io/*"

Image policies map to the Supply Chain Security (20%) domain.

Q8: What is the default behavior of NetworkPolicies in Kubernetes?

Show Answer

By default, if no NetworkPolicy exists in a namespace, ALL ingress and egress traffic is allowed to and from every Pod.

Kubernetes networking is open by default:

  • Every Pod can communicate with every other Pod
  • Every Pod can reach external endpoints
  • No traffic is blocked

NetworkPolicies are additive — they do not deny traffic; they select which traffic to allow once applied. However, the moment a NetworkPolicy selects a Pod, all other traffic to/from that Pod (for the specified policyType) is denied.

To implement default deny for a namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}    # Selects ALL pods
  policyTypes:
  - Ingress
  - Egress

This blocks ALL traffic. Then you create additional NetworkPolicies to selectively allow required communication.

Key exam insight: The question asks about default behavior — no policy means all traffic is allowed. Many candidates mistakenly think traffic is blocked by default. It is not.

NetworkPolicies map to the Cluster Setup (10%) domain.

Q9: Name 2 container runtime sandboxes and explain why they’re used.

Show Answer

1. gVisor (runsc)

gVisor is an application kernel that implements a substantial portion of the Linux system interface in a memory-safe language (Go). It intercepts syscalls from the container and handles them in userspace, providing an additional isolation layer between the container and the host kernel.

2. Kata Containers

Kata Containers run each container (or Pod) inside a lightweight virtual machine (VM). This provides hardware-level isolation using a dedicated kernel per Pod, combining the speed of containers with the security of VMs.

Why they’re used:

  • Defense in depth — If a container escapes its namespace/cgroup isolation, the sandbox prevents access to the host kernel
  • Untrusted workloads — Run third-party or user-submitted code safely
  • Compliance requirements — Some regulations require VM-level isolation for sensitive workloads

How to use in Kubernetes:

apiVersion: v1
kind: Pod
metadata:
  name: sandboxed-pod
spec:
  runtimeClassName: gvisor   # or "kata"
  containers:
  - name: app
    image: nginx:1.27

A RuntimeClass resource must be configured on the cluster:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

Runtime sandboxes map to the Minimize Microservice Vulnerabilities (20%) domain.

Show Answer

RuntimeDefault is the recommended Seccomp profile type for production workloads.

Why RuntimeDefault:

  • Uses the container runtime’s (containerd/CRI-O) built-in default profile
  • Blocks ~60+ dangerous syscalls including reboot, mount, kexec_load, ptrace, and keyctl
  • Allows common syscalls needed by most applications (read, write, open, mmap, etc.)
  • Zero configuration needed — works out of the box with no custom profile files
  • Recommended by the CIS Kubernetes Benchmark and Pod Security Standards (Restricted level requires it)

Applying to a Pod:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: nginx:1.27

The three Seccomp profile types:

Type Security Level Use Case
Unconfined Lowest — no restrictions Debugging only (never in production)
RuntimeDefault Good — blocks known dangerous syscalls Recommended default for all workloads
Localhost Strictest — custom allowlist High-security workloads needing minimal syscalls

Seccomp maps to the System Hardening (15%) domain.

Self-Scoring Guide

Count your correct answers and assess your readiness:

Score Assessment Recommendation
9–10 Excellent foundation Proceed to Chapter 2: Cluster Setup & Hardening
7–8 Good understanding Review the specific topics you missed, then proceed
5–6 Gaps in fundamentals Re-read Security Tools Overview and Exam Overview
Below 5 Significant gaps Review all introduction sub-topics; consider revisiting CKA material

Remember: These are introductory-level questions. The actual CKS exam requires you to perform these tasks hands-on, not just know the theory. Use the technical chapters to build hands-on proficiency.

Chapter Complete! You now have a solid overview of the CKS exam, its domains, tools, and preparation strategy.

← Exam Tips & Strategies Next Chapter: Cluster Setup & Hardening →

Updated:

You may also enjoy