CKS Practice Questions

These questions cover cluster hardening and workload security — the two highest-weighted domains on the CKS and where candidates need both theoretical knowledge and the ability to write working YAML and kubectl commands under time pressure.

Question 1

You need to implement logical multi-tenancy so that teams sharing a cluster cannot consume each other's resources or reach each other's pods. Which combination of features achieves this?

• A) DaemonSets per namespace with security enforcement containers
• B) ResourceQuotas combined with NetworkPolicies per namespace
• C) Node selectors that physically pin each namespace to dedicated nodes
• D) ConfigMaps with namespace-specific security settings

Answer: B — ResourceQuotas + NetworkPolicies

Logical multi-tenancy in Kubernetes uses namespace-level controls to isolate teams:

• ResourceQuota: Limits CPU, memory, and object counts within a namespace, preventing one team from exhausting cluster resources
• NetworkPolicy: Restricts which pods can communicate with which, preventing cross-namespace traffic

A complete isolation setup also includes LimitRanges (default resource requests/limits per pod) and RBAC (controlling who can deploy into which namespace).

Node selectors with dedicated nodes provide physical isolation (stronger but more expensive). Logical isolation via namespaces is the standard first approach — the CKS tests both.

DaemonSets are for running agents on every node; they don't enforce tenancy isolation. ConfigMaps are configuration storage, not security controls.

Question 2

You need to configure API server audit logging to detect potential insider threats. Which logging configuration is most effective?

• A) Log only failed authentication attempts to reduce storage overhead
• B) Log all access to Secrets, RBAC changes, and pod creation/deletion at the RequestResponse level
• C) Log only API calls from service accounts while excluding human users
• D) Log only GET requests since write operations are tracked elsewhere

Answer: B — Log Secrets access, RBAC changes, and pod lifecycle at RequestResponse level

Insider threat detection requires comprehensive audit coverage with full request and response bodies for sensitive operations. An audit policy that captures:

• Reads and writes to secrets (data exfiltration)
• Changes to roles, rolebindings, clusterroles (privilege escalation)
• Pod creation and deletion (workload tampering)

A minimal audit policy in the right direction:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]
- level: RequestResponse
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
- level: Metadata
  resources:
  - group: ""
    resources: ["pods"]

Logging only failures misses successful insider actions. Excluding human users is backwards — insiders are human users. GET requests are often the exfiltration step.

Question 3

A pod must be restricted from writing to any filesystem path except /tmp. Which Linux kernel security mechanism enforces this at the container level in Kubernetes?

• A) A Kubernetes admission controller that validates pod manifests
• B) AppArmor — a Linux kernel security module that restricts file access by profile
• C) A NetworkPolicy that restricts the pod's egress connections
• D) seccomp — a kernel feature that filters system calls

Answer: B — AppArmor

AppArmor is a Linux Mandatory Access Control (MAC) system that confines programs to a defined set of resources using profiles. An AppArmor profile can allow writes only to /tmp/** and deny writes everywhere else — and this enforcement happens at the kernel level, outside the container's control.

To apply an AppArmor profile to a Kubernetes pod:

metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/my-container: localhost/deny-writes

Comparing kernel security mechanisms the CKS tests:

seccomp filters system calls, not filesystem paths. NetworkPolicies don't touch the local filesystem. Admission controllers validate at deployment time but can't enforce at runtime.

Key Takeaways

• Logical multi-tenancy = ResourceQuotas (resource limits) + NetworkPolicies (traffic isolation) + RBAC (API access)
• Audit logging for insider threats needs RequestResponse level on Secrets and RBAC resources — don't log only failures
• AppArmor = filesystem and capability restrictions; seccomp = syscall filtering — both are runtime enforcement, not admission-time