How many Troubleshooting Scenario Questions questions are on this page?

This page has 8 Troubleshooting Scenario Questions scenario questions for the CKS exam, each with detailed explanations and wrong-answer analysis.

How should I approach CKS scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Certified Kubernetes Security Specialist CKS questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Certified Kubernetes Security Specialist CKS practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

CKS

exam code

CNCF

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmultiple choice

Full question →

A pod fails to start with the error 'Container runtime network not ready', and the node uses Kata Containers (RuntimeClass: kata). What is the most likely cause?

A
The node has insufficient memory
Why wrong: Insufficient memory would cause OOM, not a network error.
B
The pod is trying to mount a hostPath volume
Why wrong: HostPath mounts are supported by Kata, though with some restrictions.
C
The CNI plugin is not configured correctly for the kata RuntimeClass
Kata requires specific CNI configuration; misconfiguration leads to network not ready.
D
The pod's securityContext sets runAsNonRoot: true
Why wrong: runAsNonRoot does not affect network readiness.

Full breakdown with real-world context →

Question 2mediummultiple choice

Full question →

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?

A
The webhook server uses HTTP instead of HTTPS
Why wrong: Although HTTPS is recommended, HTTP is allowed if configured; this would not prevent the webhook from being called.
B
The webhook service is of type ClusterIP
Why wrong: ClusterIP is fine for internal communication.
C
The webhook server returns a 502 status code
Why wrong: The webhook is still called; the response status affects admission decision but does not prevent the call.
D
The 'clientConfig.service.namespace' does not match the namespace of the webhook service
The API server uses this namespace to route requests to the webhook service.

Full breakdown with real-world context →

Question 3mediummultiple choice

Full question →

A pod fails to start with 'CrashLoopBackOff'. The pod's YAML includes securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ['ALL'] } }. What is the likely cause?

A
The container image requires privilege escalation to run
If the application needs to perform privileged operations (e.g., setuid binaries, syscalls), dropping all capabilities and disabling privilege escalation will cause it to fail.
B
The pod is missing a required environment variable
Why wrong: Missing environment variables typically cause runtime errors, not crash loops due to security settings.
C
The node does not support seccomp profiles
Why wrong: Seccomp profiles are unrelated to the given security context settings.
D
The pod's service account lacks permissions to create pods
Why wrong: Service account permissions affect pod creation, not the pod's runtime behavior.

Full breakdown with real-world context →

Question 4mediummultiple choice

Full question →

An administrator creates a Pod with the following securityContext: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 The container image has a binary that requires read/write access to /data, which is an emptyDir volume mounted by the Pod. The container fails to start with 'Permission denied' when writing to /data. What is the most likely cause?

A
The container's base image has a restrictive umask that overrides the pod's security context.
Why wrong: umask is a filesystem attribute, but the fsGroup should allow the group to write; the issue is likely that the volume's permissions are not set correctly.
B
The fsGroup is set but the volume's fsGroupChangePolicy is missing.
Why wrong: fsGroupChangePolicy controls when ownership is changed, but the default is Always; permission denied suggests ownership is wrong.
C
The emptyDir volume is not writable by default; it needs to be explicitly configured.
Why wrong: emptyDir volumes are writable by default.
D
The container is running as user 1000, but the volume is owned by root (uid 0) and the fsGroup 2000 does not give write permission.
Why wrong: fsGroup will change the group ownership, so group 2000 should have write access if the volume supports it.

Full breakdown with real-world context →

Question 5mediummultiple choice

Full question →

An administrator deploys a Pod with the following security context:

securityContext: runAsNonRoot: true runAsUser: 1000

However, the Pod fails to start with an error: 'container has runAsNonRoot and image will run as root'. What is the most likely cause?

A
The container runtime does not support runAsNonRoot
Why wrong: The error message is from the kubelet, not the runtime; runAsNonRoot is supported by all runtimes.
B
The pod is missing a seccomp profile
Why wrong: Missing seccomp profile does not cause this specific error.
C
The runAsUser field is set to 1000, which is a non-root user
Why wrong: runAsUser: 1000 is a non-root user, but the error indicates the image itself runs as root, which conflicts with runAsNonRoot.
D
The container image specifies USER root in its Dockerfile
runAsNonRoot: true checks the image's default user; if the image runs as root (USER root), the pod is rejected even if runAsUser: 1000 is set.

Full breakdown with real-world context →

Question 6hardmultiple choice

Read the full NAT/PAT explanation →

A CI pipeline fails with the error 'cosign: error: unable to verify image: no matching signatures' when running 'cosign verify --key pubkey.pem myregistry/myapp:latest'. The image was previously signed with a private key. What is the MOST likely cause?

A
The public key is incorrect
Why wrong: If the key was previously used, it should work unless changed.
B
The registry requires authentication
Why wrong: Authentication errors would appear earlier; this error is about missing signatures.
C
Cosign is not installed correctly
Why wrong: The error message indicates the command ran but found no signatures.
D
The image tag was overwritten without signing
Overwriting a tag with a new, unsigned image removes the previous signature.

Full breakdown with real-world context →

Question 7mediummultiple choice

Full question →

An administrator runs 'kubectl run test-pod --image=nginx:latest' and the pod fails to start. The event log shows 'ImagePullBackOff' with error 'manifest for nginx:latest not found: manifest unknown'. The image 'nginx:latest' exists in the registry. What is the most likely cause?

A
The pod is running in a different namespace
Why wrong: Namespace does not affect image pull errors.
B
The registry requires authentication
Why wrong: Authentication errors produce 'unauthorized' messages, not 'manifest unknown'.
C
The image tag is misspelled or points to a non-existent tag
'Manifest unknown' means the specific tag is not found. The user might have made a typo or the tag doesn't exist in the registry.
D
The image is a multi-architecture image and the node does not support the required architecture
Why wrong: Multi-architecture issues typically result in 'exec format error' or 'not found' for the manifest, not 'manifest unknown' for the tag.

Full breakdown with real-world context →

Question 8mediummultiple choice

Full question →

You suspect a container has been compromised. You run 'kubectl exec -it <pod> -- bash' to investigate. Which of the following is the BEST next step to preserve evidence?

These CKS practice questions are part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style CKS questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related CKS topic practice pages

Monitoring Logging and Runtime Security practice questions

Cluster Setup and Hardening practice questions

System Hardening practice questions

Minimize Microservice Vulnerabilities practice questions

Supply Chain Security practice questions

Monitoring, Logging and Runtime Security practice questions

Cluster Setup practice questions

Cluster Hardening practice questions

CKS fundamentals practice questions

CKS scenario practice questions

CKS troubleshooting practice questions

Practice scenarios

A pod fails to start with the error 'Container runtime network not ready', and the node uses Kata Containers (RuntimeClass: kata). What is the most likely cause?

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?

A pod fails to start with 'CrashLoopBackOff'. The pod's YAML includes securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ['ALL'] } }. What is the likely cause?

A CI pipeline fails with the error 'cosign: error: unable to verify image: no matching signatures' when running 'cosign verify --key pubkey.pem myregistry/myapp:latest'. The image was previously signed with a private key. What is the MOST likely cause?

An administrator runs 'kubectl run test-pod --image=nginx:latest' and the pod fails to start. The event log shows 'ImagePullBackOff' with error 'manifest for nginx:latest not found: manifest unknown'. The image 'nginx:latest' exists in the registry. What is the most likely cause?

You suspect a container has been compromised. You run 'kubectl exec -it <pod> -- bash' to investigate. Which of the following is the BEST next step to preserve evidence?