How many Troubleshooting Scenario Questions questions are on this page?

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

How should I approach KCSA 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 Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Kubernetes and Cloud Native Security Associate (KCSA, CNCF) (KCSA) 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

KCSA

exam code

CNCF / Linux Foundation

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 1easymultiple choice

Full question →

You are troubleshooting a pod that fails to start because it attempts to run a container with privileges. The cluster enforces the 'baseline' Pod Security Standard. Which container configuration will cause the Pod Security Admission controller to reject the pod?

A
Mounting an emptyDir volume into the container.
Why wrong: emptyDir volumes are permitted under both baseline and restricted standards.
B
Omitting the 'runAsUser' field, allowing the container to run as UID 0 by default.
Why wrong: Running as root (UID 0) is permitted under the baseline standard (though forbidden under restricted).
C
Setting 'securityContext.privileged: true' on the container.
Privileged containers are explicitly prohibited by both baseline and restricted Pod Security Standards.
D
Adding the 'NET_BIND_SERVICE' capability to the container.
Why wrong: NET_BIND_SERVICE is allowed under the baseline standard.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full network assurance explanation →

You are troubleshooting a service mesh traffic split policy where telemetry shows that unauthorized external clients are bypassing the service mesh ingress gateway and directly accessing backend services via NodePort services. Which Kubernetes feature should you configure to prevent direct NodePort access to these sensitive pods?

A
Enabling anonymous authentication in kube-apiserver
Why wrong: Enabling anonymous authentication weakens cluster security rather than securing network paths.
B
Changing the service type from NodePort to ClusterIP
Why wrong: While changing to ClusterIP removes external cluster access, NodePort is specifically cited in the scenario and NetworkPolicies can protect pods regardless of service type.
C
Increasing the API server request rate limit
Why wrong: Rate limits control API server request frequency, not network packet routing to NodePorts.
D
NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector
NetworkPolicies ensure that pods only accept traffic from authorized sources such as the ingress gateway.

Full breakdown with real-world context →

Question 3mediummultiple choice

Full question →

You are troubleshooting a container image vulnerability scan report that flagged a high-severity CVE in a base image layer. The development team wants to ensure that vulnerable container images are automatically prevented from being deployed to any namespace in the cluster. Which Kubernetes mechanism should you implement?

A
Enable resource quotas on the default namespace
Why wrong: Resource quotas limit CPU, memory, and object counts, not image vulnerabilities.
B
Rotate the cluster certificate authority
Why wrong: Certificate rotation affects cluster authentication, not runtime deployment of vulnerable images.
C
Add network policies to restrict outbound CVE database queries
Why wrong: Network policies control pod-to-pod and pod-to-external network traffic, not image security.
D
Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs
Validating admission webhooks can block pods that use images with unresolved vulnerabilities.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

You are troubleshooting a control plane failure where the Kubernetes API server cannot communicate with etcd because of expired client certificates. Which command-line flag on the kube-apiserver specifies the client TLS certificate used for authentication against etcd?

A
--etcd-private-key
Why wrong: The corresponding private key flag is --etcd-keyfile.
B
--etcd-certfile
This flag provides the client certificate for API server to etcd mTLS authentication.
C
--client-cert-file
Why wrong: This is not the correct flag prefix for etcd client configurations.
D
--etcd-ca-file
Why wrong: This specifies the Certificate Authority for verifying etcd certificates, not the client cert itself.

Full breakdown with real-world context →

Question 5hardmultiple choice

Full question →

You are troubleshooting a secure etcd cluster where a new control plane node cannot join the cluster. The logs indicate a TLS handshake failure between etcd peers. Which etcd configuration flag specifies the trusted CA certificate used to verify peer certificates?

A
--trusted-ca-file
Why wrong: This validates client-to-server connections, not peer-to-peer connections.
B
--peer-client-cert-auth
Why wrong: This is a boolean flag enforcing client cert auth for peers, not the CA file itself.
C
--peer-trusted-ca-file
This flag ensures peer certificates are validated against the correct CA.
D
--etcd-ca-file
Why wrong: This is an API server flag, not an etcd daemon flag.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

You are troubleshooting a custom controller that fails to read ConfigMaps in the 'kube-system' namespace despite having a ClusterRole bound via a ClusterRoleBinding. What is the most likely reason for this failure?

A
The ClusterRole lacks the required verbs ('get', 'list', 'watch') or resources ('configmaps') for that API group.
RBAC permissions are explicitly defined by resource and verb combinations; if 'configmaps' or verbs are missing, access is denied.
B
ClusterRoleBindings cannot be used with ConfigMaps.
Why wrong: ClusterRoleBindings can grant access to any cluster-scoped or namespace-scoped resource.
C
ClusterRoleBindings are automatically disabled in 'kube-system'.
Why wrong: ClusterRoleBindings apply across all namespaces including kube-system.
D
ConfigMaps in 'kube-system' can only be accessed using ServiceAccounts named 'default'.
Why wrong: Any properly authorized service account or user can access resources.

Full breakdown with real-world context →

Question 7hardmultiple choice

Full question →

Your cluster uses the Pod Security admission controller with the 'restricted' profile enforced. A legacy application pod fails to start because it requires running as root (runAsNonRoot: false). How should you handle this securely without disabling the standard?

A
Disable the Pod Security admission controller entirely across the cluster.
Why wrong: Disabling the admission controller removes all baseline security guarantees cluster-wide.
B
Configure the Pod Security admission configuration file on the control plane to exempt the specific ServiceAccount or namespace from the restricted check.
The Pod Security admission plugin supports exemptions for specific usernames, namespaces, and runtime classes via its configuration file.
C
Set the namespace enforce level to 'privileged' permanently.
Why wrong: Lowering the entire namespace to privileged weakens security for all other pods in that namespace.
D
Mount the host socket inside the pod to bypass user namespace restrictions.
Why wrong: Mounting the host socket introduces severe security vulnerabilities like container breakout.

Full breakdown with real-world context →

These KCSA practice questions are part of Courseiva's free CNCF / Linux Foundation certification practice question bank. Courseiva provides original exam-style KCSA 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 KCSA topic practice pages

Kubernetes Security Fundamentals practice questions

Overview OF Cloud Native Security practice questions

Compliance And Security Frameworks practice questions

Kubernetes Cluster Component Security practice questions

Kubernetes Threat Model practice questions

Platform Security practice questions

KCSA fundamentals practice questions

KCSA scenario practice questions

KCSA troubleshooting practice questions

Practice scenarios

You are troubleshooting a pod that fails to start because it attempts to run a container with privileges. The cluster enforces the 'baseline' Pod Security Standard. Which container configuration will cause the Pod Security Admission controller to reject the pod?

You are troubleshooting a control plane failure where the Kubernetes API server cannot communicate with etcd because of expired client certificates. Which command-line flag on the kube-apiserver specifies the client TLS certificate used for authentication against etcd?

You are troubleshooting a secure etcd cluster where a new control plane node cannot join the cluster. The logs indicate a TLS handshake failure between etcd peers. Which etcd configuration flag specifies the trusted CA certificate used to verify peer certificates?

You are troubleshooting a custom controller that fails to read ConfigMaps in the 'kube-system' namespace despite having a ClusterRole bound via a ClusterRoleBinding. What is the most likely reason for this failure?

Your cluster uses the Pod Security admission controller with the 'restricted' profile enforced. A legacy application pod fails to start because it requires running as root (runAsNonRoot: false). How should you handle this securely without disabling the standard?