Troubleshooting practice questions

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?

Trap 1: Mounting an emptyDir volume into the container.

emptyDir volumes are permitted under both baseline and restricted standards.

Trap 2: Omitting the 'runAsUser' field, allowing the container to run as…

Running as root (UID 0) is permitted under the baseline standard (though forbidden under restricted).

Trap 3: Adding the 'NET_BIND_SERVICE' capability to the container.

NET_BIND_SERVICE is allowed under the baseline standard.

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.

Read the full network assurance explanation →

Question 2hardmultiple 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

Enabling anonymous authentication weakens cluster security rather than securing network paths.

Trap 2: Changing the service type from NodePort to ClusterIP

While changing to ClusterIP removes external cluster access, NodePort is specifically cited in the scenario and NetworkPolicies can protect pods regardless of service type.

Trap 3: Increasing the API server request rate limit

Rate limits control API server request frequency, not network packet routing to NodePorts.

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.

Question 3mediummultiple choice

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 limit CPU, memory, and object counts, not image vulnerabilities.

Trap 2: Rotate the cluster certificate authority

Certificate rotation affects cluster authentication, not runtime deployment of vulnerable images.

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

Network policies control pod-to-pod and pod-to-external network traffic, not image security.

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.

Question 4hardmultiple 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

The corresponding private key flag is --etcd-keyfile.

Trap 2: --client-cert-file

This is not the correct flag prefix for etcd client configurations.

Trap 3: --etcd-ca-file

This specifies the Certificate Authority for verifying etcd certificates, not the client cert itself.

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.

Question 5hardmultiple 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

This validates client-to-server connections, not peer-to-peer connections.

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

This is a boolean flag enforcing client cert auth for peers, not the CA file itself.

Trap 3: --etcd-ca-file

This is an API server flag, not an etcd daemon flag.

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.

Question 6hardmultiple 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 can grant access to any cluster-scoped or namespace-scoped resource.

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

ClusterRoleBindings apply across all namespaces including kube-system.

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

Any properly authorized service account or user can access resources.

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.