CKS Practice Test 5 — 25 Questions

Question 1

An administrator wants to enforce that no container in a specific namespace runs with the privileged security context. They decide to use Pod Security Standards. Which Pod Security Standard level should be applied to the namespace?

Accepted Answer

restricted. The restricted Pod Security Standard (PSS) level is the correct choice because it enforces the most stringent set of security controls, including the prohibition of privileged containers. This level denies any pod that requests `privileged: true` or uses other privileged capabilities, ensuring that no container in the namespace can run with elevated host access. The baseline level is less restrictive and allows some privileged configurations, while the privileged level imposes no restrictions at all.

Answer

baseline

Answer

custom

Answer

privileged

Question 2

Which kubectl command is used to check the AppArmor status on a Kubernetes node?

Accepted Answer

kubectl node-shell <node> -- aa-status. Option C is correct because `kubectl node-shell` provides a shell into the node's filesystem, allowing you to run `aa-status` directly on the node to check the AppArmor status. This is the standard method to verify AppArmor profiles and their enforcement state on a Kubernetes node, as AppArmor operates at the host kernel level and is not managed via the Kubernetes API.

Answer

kubectl describe node <node> | grep AppArmor

Answer

kubectl get apparmor

Answer

kubectl exec <pod> -- aa-status

Question 3

Which of the following is the correct command to load an AppArmor profile from a file named 'my-profile'?

Accepted Answer

apparmor_parser my-profile. The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Answer

apparmor_load my-profile

Answer

apparmor_parser -R my-profile

Answer

systemctl start apparmor my-profile

Question 4

Which of the following host access settings should be disabled to reduce the attack surface of a container?

Accepted Answer

hostPID: false. Option D is correct because setting `hostPID: false` explicitly disables the container's access to the host's process ID namespace, which reduces the attack surface by preventing the container from seeing or interacting with host processes. In Kubernetes, when `hostPID` is set to `true`, the container shares the host's PID namespace, allowing it to potentially escalate privileges or interfere with other workloads. Disabling this setting (i.e., `false`) is a recommended security best practice to enforce process isolation.

Answer

hostNetwork: true

Answer

hostPID: true

Answer

hostIPC: true

Question 5

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

Accepted Answer

PSP support was removed from Kubernetes in 1.25. PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Answer

The PSP API version needs to be updated to v1

Answer

PSPs were replaced by NetworkPolicies in 1.25

Answer

The PSP was not applied to the correct namespace

Question 6

An admin runs 'kubectl describe pod secure-pod' and sees 'seccompProfile: RuntimeDefault' under the container's security context. Which seccomp profile is being used?

Accepted Answer

The container runtime's default seccomp profile is applied. When `seccompProfile` is set to `RuntimeDefault` in a container's security context, Kubernetes instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile. This profile is typically a restrictive set of syscalls that blocks dangerous or unnecessary system calls while allowing common operations. It is not a custom profile from the node's filesystem, nor does it disable seccomp or set it to unconfined.

Answer

A custom seccomp profile from '/var/lib/kubelet/seccomp/' is used

Answer

The container runtime's seccomp profile is set to 'Unconfined'

Answer

Seccomp is disabled for this container

Question 7

A cluster uses PodSecurity admission. A namespace has the label 'pod-security.kubernetes.io/enforce: baseline'. A user creates a pod that runs a container with 'privileged: true'. What happens?

Accepted Answer

The pod is rejected by the admission controller.. The PodSecurity admission controller enforces the configured security level based on the namespace label. The 'baseline' level prohibits privileged containers, so a pod with 'privileged: true' violates the policy. The admission controller rejects the pod immediately, preventing its creation.

Answer

The pod is created but flagged with a warning.

Answer

The pod is created successfully because privileged is allowed at baseline.

Answer

The pod is created but the privileged setting is ignored.

Question 8

Which annotation is used to apply an AppArmor profile to a pod?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. Option C is correct because the AppArmor profile for a container in a pod is specified using the annotation `container.apparmor.security.beta.kubernetes.io/`, where `` is the name of the container. This annotation, which was introduced in Kubernetes v1.4 as a beta feature, tells the kubelet to apply the referenced AppArmor profile (e.g., `localhost/k8s-apparmor-example`) to the specified container during runtime.

Answer

apparmor.security.kubernetes.io/profile

Answer

security.kubernetes.io/apparmor

Answer

seccomp.security.alpha.kubernetes.io/pod

Question 9

An administrator runs 'aa-status' on a node and sees a profile in 'complain' mode. What does this indicate?

Accepted Answer

The profile logs violations but does not block them.. AppArmor profiles in 'complain' mode log policy violations to the system log (e.g., /var/log/syslog or audit.log) but do not enforce them, meaning the actions are allowed while being recorded. This is distinct from 'enforce' mode, where violations are blocked. The 'aa-status' command shows the current mode of loaded profiles.

Answer

The profile is disabled and has no effect.

Answer

The profile is enforcing restrictions and blocking violations.

Answer

The profile is not loaded.

Question 10

What is the primary purpose of using a service mesh like Istio for microservices security?

Accepted Answer

To provide mTLS communication between services for encrypted and authenticated traffic.. The primary purpose of a service mesh like Istio for microservices security is to enforce mutual TLS (mTLS) between services, ensuring that all inter-service communication is both encrypted and authenticated. This is achieved by injecting sidecar proxies (Envoy) that handle TLS termination and certificate management transparently, without requiring changes to application code.

Answer

To replace Kubernetes NetworkPolicies for network segmentation.

Answer

To provide a centralized logging solution.

Answer

To automatically scale pods based on CPU usage.

Question 11

An administrator creates a custom seccomp profile and wants to apply it to a pod. The profile file is named 'audit.json' and is placed in the default seccomp directory on the node. Which securityContext field should be used?

Accepted Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json. Option C is correct because in Kubernetes, when using a custom seccomp profile stored on the node's default seccomp directory, the `securityContext.seccompProfile.type` must be set to `Localhost` and the profile filename is specified via the `localhostProfile` field. This field expects the filename (e.g., `audit.json`) relative to the node's default seccomp path (`/var/lib/kubelet/seccomp`). The `type: Localhost` instructs kubelet to load the profile from the node's filesystem.

Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.file: audit.json

Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json

Answer

seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json

Question 12

Which annotation is used to apply an AppArmor profile to a pod in Kubernetes?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. Option D is correct because the `container.apparmor.security.beta.kubernetes.io/` annotation is the exact key used to apply an AppArmor profile to a specific container within a pod. The value of this annotation specifies the profile name (e.g., `localhost/` or `runtime/default`), and it must be set on the Pod object before the pod is created, as AppArmor profiles cannot be applied to running containers.

Answer

security.alpha.kubernetes.io/apparmor

Answer

apparmor.kubernetes.io/default

Answer

seccomp.security.alpha.kubernetes.io/pod

Question 13

A pod runs with 'hostNetwork: true' and 'hostPID: true'. Which security concern is MOST directly increased?

Accepted Answer

The container can access host processes and potentially escape. Setting `hostNetwork: true` and `hostPID: true` in a pod grants the container direct access to the host's network namespace and process namespace. With `hostPID: true`, the container can see all host processes (e.g., via `ps aux`) and potentially interact with them using system calls like `ptrace`, which could allow escaping the container by injecting code into a host process. This combination directly increases the risk of container breakout, making A the most significant security concern.

Answer

The container can modify iptables rules

Answer

The container can sniff network traffic of other pods

Answer

The container can mount the host filesystem

Question 14

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

Accepted Answer

Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.

Answer

Create a NetworkPolicy to block pods without limits.

Answer

Create a MutatingWebhookConfiguration to add resource limits automatically.

Answer

Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.

Question 15

You have an existing deployment that uses environment variables for secrets. Which kubectl command can be used to update the deployment to mount secrets as volumes without recreating the pods?

Accepted Answer

kubectl patch deployment <deploy> -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","volumeMounts":[{"name":"secret","mountPath":"/etc/secret"}]}],"volumes":[{"name":"secret","secret":{"secretName":"mysecret"}}]}}}}'. Option A is correct because `kubectl patch` directly updates the deployment's pod template spec to add a volume and volumeMount for the secret. This triggers a rolling update, applying the change without manually recreating pods. Option B only sets environment variables, not volume mounts. Option C (`kubectl edit`) requires manual editing and is less direct. Option D is invalid as `kubectl set volume` is not a real kubectl command.

Answer

kubectl set env deployment <deploy> --from=secret/mysecret

Answer

kubectl edit deployment <deploy>

Answer

kubectl set volume deployment/<deploy> --add --name=secret --mount-path=/etc/secret --secret-name=mysecret

Question 16

A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?

Accepted Answer

PeerAuthentication with mTLS mode set to STRICT. PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls configuration

Answer

ServiceEntry with mTLS enabled

Question 17

A ValidatingWebhookConfiguration is not working as expected. The webhook server is running and accessible. What is a common misconfiguration that would cause the webhook to not be called?

Accepted Answer

The 'clientConfig.service.namespace' does not match the namespace of the webhook service. Option D is correct because the ValidatingWebhookConfiguration's `clientConfig.service.namespace` field must exactly match the namespace where the webhook's Kubernetes Service object resides. If this namespace is misconfigured, the API server cannot resolve the service endpoint to call the webhook, causing the webhook to be silently skipped or fail to be invoked.

Answer

The webhook server uses HTTP instead of HTTPS

Answer

The webhook service is of type ClusterIP

Answer

The webhook server returns a 502 status code

Question 18

You run 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' and get 'no'. What does this mean?

Accepted Answer

The service account 'sa1' does not have permission to create pods in the default namespace. The command 'kubectl auth can-i create pods --as=system:serviceaccount:default:sa1 -n default' impersonates the service account 'sa1' to check if it has RBAC permissions to create pods in the 'default' namespace. A response of 'no' means that the current RBAC bindings (Role/ClusterRole and RoleBinding/ClusterRoleBinding) do not grant the 'create' verb on 'pods' resources to that service account. This is a direct authorization check against the Kubernetes RBAC system, not an indication of the service account's existence or general capability.

Answer

The command is invalid because 'system:serviceaccount' is not a valid user

Answer

The service account 'sa1' does not exist

Answer

The service account 'sa1' is not allowed to perform any actions

Question 19

Order the steps to configure and apply a NetworkPolicy to restrict pod-to-pod traffic.

Accepted Answer

Create the NetworkPolicy YAML manifest, then apply it using kubectl apply, then deploy test pods with appropriate labels, then verify connectivity using kubectl exec.. NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Answer

Apply the NetworkPolicy using kubectl apply, then create the YAML manifest, then deploy test pods, then verify connectivity.

Answer

Create the NetworkPolicy YAML, then deploy test pods, then apply the policy, then verify connectivity.

Answer

Deploy test pods, then create and apply the NetworkPolicy, then verify connectivity.

Question 20

A security auditor requires that all pods in a cluster must not run as root. Which Pod Security Standard (PSS) and enforcement mode should be applied at the namespace level?

Accepted Answer

Restricted profile with enforce mode. The Restricted profile is the only Pod Security Standard that prohibits running containers as root by enforcing the 'MustRunAsNonRoot' security context constraint. Applying it in 'enforce' mode ensures that any pod violating this rule is immediately rejected at admission time, which directly meets the auditor's requirement.

Answer

Baseline profile with enforce mode

Answer

Baseline profile with warn mode

Answer

Privileged profile with audit mode