Detailed Exam Domain Coverage

The Certified Kubernetes Security Specialist (CKS) certification is a performance-based exam that requires you to demonstrate competence across a broad range of security best practices. The exam evaluates your skills in the following domains:

Cluster Setup (10%): Kubernetes architecture overview, Security of cluster components, Kubernetes Network Policies.
Cluster Hardening (15%): RBAC configuration and management, API server authentication hardening, Admission controller policies.
System Hardening (15%): Seccomp profile creation, AppArmor profile enforcement, Linux capabilities restriction.
Minimize Microservice Vulnerabilities (20%): Pod Security Standards (PSS), Container image scanning with Trivy, Secure pod configuration.
Supply Chain Security (20%): Container image minimization, Software Bill of Materials (SBOM) generation, Registry access control and image signing, Static analysis of dependencies.
Monitoring, Logging, and Runtime Security (20%): Falco for runtime threat detection, Kubernetes audit logging, Seccomp and syscall monitoring.

Course Description

Passing the Certified Kubernetes Security Specialist (CKS) exam requires more than just reading documentation; it demands practical, muscle-memory-level knowledge of securing containerized environments. Because the CKS is a high-pressure, performance-based test, sitting for it without hands-on practice can be a costly mistake.

I designed this extensive practice test course to mirror the exact difficulty and domain distribution of the real CKS exam. You will work through complex scenarios covering Cluster Setup and Hardening, where you will tackle RBAC, network policies, and API server security. I have also heavily emphasized System Hardening and Microservice Vulnerabilities, pushing you to actively write Seccomp and AppArmor profiles, restrict Linux capabilities, and enforce Pod Security Standards (PSS).

Furthermore, modern Kubernetes security heavily relies on Supply Chain and Runtime protection. The practice questions included here will drill you on scanning images with Trivy, generating SBOMs, and writing Falco rules for real-time threat detection. By the time you complete these tests, you will understand not just how to find the right commands, but exactly why certain security configurations are necessary.

Below is a preview of the type of deep-dive questions you will encounter in this course.

Sample Practice Questions

Question 1: Cluster Hardening
- Scenario: You need to grant a specific ServiceAccount named audit-sa the ability to strictly view (read-only) Pods and Services within the staging namespace. Which combination of Kubernetes resources is the most appropriate and secure way to implement this according to the principle of least privilege?
- Options:
  - A) A ClusterRole granting 'get', 'watch', 'list' on Pods and Services, bound using a ClusterRoleBinding.
  - B) A Role granting 'get', 'watch', 'list' on Pods and Services, bound using a RoleBinding in the staging namespace.
  - C) A Role granting '*' on Pods and Services, bound using a RoleBinding in the staging namespace.
  - D) A PodSecurityPolicy mapped to the audit-sa ServiceAccount.
  - E) A NetworkPolicy allowing ingress traffic from audit-sa.
  - F) A ClusterRole granting 'get', 'watch', 'list' on Pods and Services, bound using a RoleBinding in the staging namespace.
- Correct Answer: B
- Overall Explanation: The principle of least privilege dictates that permissions should be as narrowly scoped as possible. Because the access is only needed in a specific namespace (staging), a Role and RoleBinding combination is the correct choice to localize the permissions.
- Option Explanations:
  - Option A is incorrect: A ClusterRoleBinding applies cluster-wide, which violates the principle of least privilege by granting access across all namespaces.
  - Option B is correct: A Role defines permissions within a specific namespace, and a RoleBinding attaches those permissions to the user within that same namespace.
  - Option C is incorrect: Using the wildcard * grants full permissions (create, delete, patch, etc.), failing the requirement for read-only access.
  - Option D is incorrect: PodSecurityPolicies control the security context of running pods (like running as root), not RBAC API access.
  - Option E is incorrect: NetworkPolicies control network traffic flow between pods at the IP/Port level, not Kubernetes API authorization.
  - Option F is incorrect: While technically possible to bind a ClusterRole with a RoleBinding to restrict it to a namespace, Option B is the more direct and standard practice for creating purely namespace-scoped permissions from scratch.
Question 2: System Hardening
- Scenario: You have created a custom AppArmor profile named secure-web-profile on your worker nodes. How do you correctly enforce this profile on a specific container named nginx-container running inside a new Pod?
- Options:
  - A) Add the annotation container. apparmor. security. beta. kubernetes. io/nginx-container: localhost/secure-web-profile to the Pod metadata.
  - B) Set apparmorProfile: secure-web-profile under the Pod's securityContext specification.
  - C) Deploy an AppArmorProfile Custom Resource (CR) and link it using a ValidatingWebhook.
  - D) Apply the label security.kubernetes. io/apparmor: secure-web-profile to the deployment.
  - E) Pass --apparmor-profile=secure-web-profile as a command-line argument to the kubelet service.
  - F) Add the annotation pod.apparmor.security.beta.kubernetes. io/nginx-container: secure-web-profile to the Pod metadata.
- Correct Answer: A
- Overall Explanation: In Kubernetes, applying custom AppArmor profiles to specific containers is currently achieved using a specific beta annotation format on the Pod's metadata that references the container name and the profile residing on the node's localhost.
- Option Explanations:
  - Option A is correct: This is the exact syntax required by Kubernetes to attach an AppArmor profile to a specific container within a pod.
  - Option B is incorrect: Unlike Seccomp, AppArmor is not yet configured directly via a dedicated field in the standard securityContext API block; it still relies on annotations.
  - Option C is incorrect: There is no native AppArmorProfile Custom Resource Definition (CRD) built into standard Kubernetes for this purpose.
  - Option D is incorrect: Labels are used for selecting and grouping objects, not for enforcing kernel-level security profiles.
  - Option E is incorrect: Kubelet arguments configure node-level behavior, not per-pod or per-container application of security profiles.
  - Option F is incorrect: The prefix pod. apparmor is invalid; the correct beta annotation prefix is container. apparmor. security. beta. kubernetes. io/.
Question 3: Monitoring, Logging, and Runtime Security
- Scenario: You are writing a custom Falco rule to alert administrators whenever a terminal shell is spawned inside any container in your cluster. Which macro best represents the condition for detecting this behavior?
- Options:
  - A) k8s. audit. log. shell == true
  - B) syscall. type=execve and syscall. args contains "bash"
  - C) spawned_process and container and proc. name in (shell_binaries)
  - D) pod. security. standard=restricted
  - E) container. tty=true and process. name="bash"
  - F) syslog.facility=authpriv and message contains "shell"
- Correct Answer: C
- Overall Explanation: Falco utilizes system call monitoring combined with extensive rule macros to detect anomalous behavior. The condition requires identifying a new process spawning, verifying it is within a container, and checking if the process name matches known shell binaries.
- Option Explanations:
  - Option A is incorrect: Kubernetes audit logs track API requests made to the API server, not internal system calls or processes executing inside the containers.
  - Option B is incorrect: While technically valid system calls, this approach is too rigid. It misses other shells like sh, zsh, or ash and doesn't explicitly filter for containerized environments.
  - Option C is correct: This utilizes standard Falco macros. spawned_process detects the execve system call, container ensures it's happening inside a container environment, and proc. name in (shell_binaries) covers multiple shell types globally.
  - Option D is incorrect: Pod Security Standards define cluster admission policies (like preventing root usage), they do not monitor runtime process execution.
  - Option E is incorrect: Falco rules use specific syntax and macros; container.tty is not the standard way Falco evaluates shell spawning events.
  - Option F is incorrect: Syslog monitors general system logs, whereas Falco operates directly on the Linux kernel level via eBPF or kernel modules to intercept system calls.
Welcome to the Mock Exam Practice Tests Academy to help you prepare for your CKS: Certified Kubernetes Security Specialist course.
You can retake the exams as many times as you want.
This is a huge original question bank.
You get support from me if you have questions.
Each question has a detailed explanation.
Mobile-compatible with the Udemy app.

I hope that by now you're convinced! And there are a lot more questions inside the course.