Troubleshooting practice questions

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?

Trap 1: Enable resource quotas on the default namespace

Resource quotas cap aggregate CPU, memory and object counts per namespace; they inspect no image contents and cannot block a pod because of a CVE. It is tempting because quotas are the correct mechanism when the requirement is preventing one namespace from consuming cluster resources beyond its allocation.

Trap 2: Rotate the cluster certificate authority

Rotating the cluster certificate authority refreshes the trust material used for TLS authentication between components; it does not inspect image layers or block workloads. Its purpose is recovering from CA compromise or expiry. Admission control, via a policy engine such as Kyverno or Gatekeeper, is what evaluates image scan results before a pod is admitted.

Trap 3: Add network policies to restrict outbound CVE database queries

Network policies filter pod ingress and egress traffic; they never inspect image layers, so a vulnerable image still schedules and runs. It is tempting because network policies are the correct mechanism when the requirement is restricting which pods or external endpoints a workload may communicate with.

A
Enable resource quotas on the default namespace
Why it fails: Resource quotas cap aggregate CPU, memory and object counts per namespace; they inspect no image contents and cannot block a pod because of a CVE. It is tempting because quotas are the correct mechanism when the requirement is preventing one namespace from consuming cluster resources beyond its allocation.
B
Rotate the cluster certificate authority
Why it fails: Rotating the cluster certificate authority refreshes the trust material used for TLS authentication between components; it does not inspect image layers or block workloads. Its purpose is recovering from CA compromise or expiry. Admission control, via a policy engine such as Kyverno or Gatekeeper, is what evaluates image scan results before a pod is admitted.
C
Add network policies to restrict outbound CVE database queries
Why it fails: Network policies filter pod ingress and egress traffic; they never inspect image layers, so a vulnerable image still schedules and runs. It is tempting because network policies are the correct mechanism when the requirement is restricting which pods or external endpoints a workload may communicate with.
D
Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs
A validating admission webhook intercepts pod creation requests, queries image metadata against vulnerability data, and rejects any workload whose image contains known CVEs. This enforces prevention cluster-wide at admission time, satisfying the requirement to block deployment automatically.

Question 2hardmultiple choice

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?

Trap 1: --etcd-private-key

--etcd-private-key provides the private key matching the client certificate, not the certificate itself; both are needed, but the question asks for the certificate. It is tempting because key and certificate are configured together, and it would be correct when specifying the key half of the etcd client credential pair.

Trap 2: --client-cert-file

No such kube-apiserver flag exists; client certificate authentication to etcd uses --etcd-certfile. It is tempting because the name mirrors the generic TLS client-certificate concept, and a similarly named flag would be correct for a component whose actual flag is --client-cert-file.

Trap 3: --etcd-ca-file

--etcd-ca-file supplies the CA bundle used to verify etcd's server certificate, not the API server's client certificate. It is tempting because both flags concern etcd TLS trust, and it would be correct when configuring which authority signs etcd's serving certificate.

A
--etcd-private-key
Why it fails: --etcd-private-key provides the private key matching the client certificate, not the certificate itself; both are needed, but the question asks for the certificate. It is tempting because key and certificate are configured together, and it would be correct when specifying the key half of the etcd client credential pair.
B
--etcd-certfile
The `--etcd-certfile` flag supplies the client TLS certificate the kube-apiserver presents to etcd, directly resolving the expired-certificate failure described. Its counterpart, `--etcd-keyfile`, provides the matching private key, while `--tls-cert-file` covers serving clients rather than etcd authentication.
C
--client-cert-file
Why it fails: No such kube-apiserver flag exists; client certificate authentication to etcd uses --etcd-certfile. It is tempting because the name mirrors the generic TLS client-certificate concept, and a similarly named flag would be correct for a component whose actual flag is --client-cert-file.
D
--etcd-ca-file
Why it fails: --etcd-ca-file supplies the CA bundle used to verify etcd's server certificate, not the API server's client certificate. It is tempting because both flags concern etcd TLS trust, and it would be correct when configuring which authority signs etcd's serving certificate.

Question 3hardmultiple choice

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?

Trap 1: --trusted-ca-file

--trusted-ca-file sets the CA bundle for verifying client certificates, not peer certificates; peer verification uses --peer-trusted-ca-file. It is tempting because it is the correct flag for securing the client-facing listener, so it would be right if the failing handshake were between a client and etcd rather than between etcd peers.

Trap 2: --peer-client-cert-auth

--peer-client-cert-auth is a boolean that enables requiring and verifying peer client certificates; it does not name the CA used for that verification. It is tempting because it governs peer certificate authentication, so it would be correct alongside --peer-trusted-ca-file when enabling mutual TLS between peers, but it supplies no CA path itself.

Trap 3: --etcd-ca-file

--etcd-ca-file is not a valid etcd flag; no such option exists in etcd's configuration. It is tempting because the name mirrors kube-apiserver's --etcd-cafile, which the API server uses to verify the etcd server's certificate, so it would be correct when configuring a client connecting to etcd, not when configuring etcd's own peer trust.

A
--trusted-ca-file
Why it fails: --trusted-ca-file sets the CA bundle for verifying client certificates, not peer certificates; peer verification uses --peer-trusted-ca-file. It is tempting because it is the correct flag for securing the client-facing listener, so it would be right if the failing handshake were between a client and etcd rather than between etcd peers.
B
--peer-client-cert-auth
Why it fails: --peer-client-cert-auth is a boolean that enables requiring and verifying peer client certificates; it does not name the CA used for that verification. It is tempting because it governs peer certificate authentication, so it would be correct alongside --peer-trusted-ca-file when enabling mutual TLS between peers, but it supplies no CA path itself.
C
--peer-trusted-ca-file
The `--peer-trusted-ca-file` flag loads the CA bundle that etcd uses to validate certificates presented by peer nodes during mutual TLS. Since the stem describes a peer-to-peer TLS handshake failure, this flag directly satisfies the requirement for verifying peer certificates, unlike client-facing or server certificate flags.
D
--etcd-ca-file
Why it fails: --etcd-ca-file is not a valid etcd flag; no such option exists in etcd's configuration. It is tempting because the name mirrors kube-apiserver's --etcd-cafile, which the API server uses to verify the etcd server's certificate, so it would be correct when configuring a client connecting to etcd, not when configuring etcd's own peer trust.

Read the full network assurance explanation →

Question 4hardmultiple choice

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?

Trap 1: Enabling anonymous authentication in kube-apiserver

Anonymous authentication lets unauthenticated requests reach the kube-apiserver as system:anonymous; it governs API access, not data-plane NodePort reachability, so external clients still hit backend pods directly. It is tempting because anonymous auth is genuinely used in some bootstrap or health-check scenarios where unauthenticated API reads are deliberately required.

Trap 2: Changing the service type from NodePort to ClusterIP

Switching to ClusterIP removes the node-level port, but ClusterIP addresses remain routable cluster-wide, so any pod or compromised workload can still reach the backend directly, bypassing the ingress gateway. It is tempting because ClusterIP is the default for internal-only services, which suits east-west traffic that genuinely needs no external exposure.

Trap 3: Increasing the API server request rate limit

Rate-limiting kube-apiserver requests throttles control-plane API calls; it never filters data-plane traffic reaching a NodePort, so external clients still connect directly to backend pods. It is tempting because API server request limits genuinely protect the control plane from overload or brute-force authentication attempts, which is a different scenario entirely.

A
Enabling anonymous authentication in kube-apiserver
Why it fails: Anonymous authentication lets unauthenticated requests reach the kube-apiserver as system:anonymous; it governs API access, not data-plane NodePort reachability, so external clients still hit backend pods directly. It is tempting because anonymous auth is genuinely used in some bootstrap or health-check scenarios where unauthenticated API reads are deliberately required.
B
Changing the service type from NodePort to ClusterIP
Why it fails: Switching to ClusterIP removes the node-level port, but ClusterIP addresses remain routable cluster-wide, so any pod or compromised workload can still reach the backend directly, bypassing the ingress gateway. It is tempting because ClusterIP is the default for internal-only services, which suits east-west traffic that genuinely needs no external exposure.
C
Increasing the API server request rate limit
Why it fails: Rate-limiting kube-apiserver requests throttles control-plane API calls; it never filters data-plane traffic reaching a NodePort, so external clients still connect directly to backend pods. It is tempting because API server request limits genuinely protect the control plane from overload or brute-force authentication attempts, which is a different scenario entirely.
D
NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector
NetworkPolicies select pods by label and filter ingress at the CNI level, so only traffic from the gateway's pod selector reaches the backends. This blocks NodePort traffic arriving from any other source, closing the bypass the telemetry revealed.

Question 5hardmultiple choice

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?

Trap 1: ClusterRoleBindings cannot be used with ConfigMaps.

ClusterRoleBindings grant ClusterRoles cluster-wide, and ConfigMap read verbs (get, list, watch) are ordinary RBAC resources, so binding them works. The claim is false. It tempts because ClusterRoleBindings are often associated with cluster-scoped objects rather than namespaced ones, but they legitimately authorise namespaced resources too.

Trap 2: ClusterRoleBindings are automatically disabled in 'kube-system'.

No such automatic disabling exists; ClusterRoleBindings grant cluster-wide permissions regardless of namespace, including kube-system. The failure instead stems from the controller's ServiceAccount lacking the binding or using a namespaced Role. This option tempts when namespace-scoped RBAC is confused with cluster-scoped grants, which is the correct model for cross-namespace access.

Trap 3: ConfigMaps in 'kube-system' can only be accessed using…

No such restriction exists; any ServiceAccount with the granted RBAC permissions can read ConfigMaps in kube-system. The 'default' ServiceAccount naming rule is fabricated, so it cannot explain the failure. It tempts because ServiceAccount tokens are one authentication path, but RBAC authorisation, not the account's name, governs access.

A
The ClusterRole lacks the required verbs ('get', 'list', 'watch') or resources ('configmaps') for that API group.
A ClusterRoleBinding grants whatever permissions the referenced ClusterRole defines; if that role omits get, list or watch on configmaps in the core API group, every request is denied by RBAC regardless of the binding's scope.
B
ClusterRoleBindings cannot be used with ConfigMaps.
Why it fails: ClusterRoleBindings grant ClusterRoles cluster-wide, and ConfigMap read verbs (get, list, watch) are ordinary RBAC resources, so binding them works. The claim is false. It tempts because ClusterRoleBindings are often associated with cluster-scoped objects rather than namespaced ones, but they legitimately authorise namespaced resources too.
C
ClusterRoleBindings are automatically disabled in 'kube-system'.
Why it fails: No such automatic disabling exists; ClusterRoleBindings grant cluster-wide permissions regardless of namespace, including kube-system. The failure instead stems from the controller's ServiceAccount lacking the binding or using a namespaced Role. This option tempts when namespace-scoped RBAC is confused with cluster-scoped grants, which is the correct model for cross-namespace access.
D
ConfigMaps in 'kube-system' can only be accessed using ServiceAccounts named 'default'.
Why it fails: No such restriction exists; any ServiceAccount with the granted RBAC permissions can read ConfigMaps in kube-system. The 'default' ServiceAccount naming rule is fabricated, so it cannot explain the failure. It tempts because ServiceAccount tokens are one authentication path, but RBAC authorisation, not the account's name, governs access.