Hard Difficulty Questions

Store the API key in a ConfigMap and reference it in the Pod spec.

Why wrong: ConfigMaps are for non-confidential data; Secrets are for sensitive data.

Embed the API key directly in the container image.

Why wrong: Embedding secrets in images is insecure and violates best practices.

Store the API key in a Pod annotation and read it with kubectl.

Why wrong: Annotations are not meant for secrets; they are metadata and not secure.

Use a nodeSelector to select the node.

Why wrong: Incorrect; nodeSelector cannot bypass taints.

Remove the taint from the node.

Why wrong: Incorrect; removing the taint allows all pods, not just the special one.

Use podAffinity to attract the pod to the node.

Why wrong: Incorrect; affinity does not override taints.

The image registry credentials are missing

Why wrong: Missing credentials would cause ImagePullBackOff, not CrashLoopBackOff with this error.

The liveness probe is misconfigured and killing the container

Why wrong: A failing probe would show probe failures in events, not an exec error.

The container is running as a non-root user without proper permissions

Why wrong: Permission issues would show 'permission denied', not 'executable file not found'.

RBAC Role

Why wrong: RBAC controls API access permissions.

PodSecurityPolicy

Why wrong: PSP is for security contexts, not network isolation.

ResourceQuota

Why wrong: ResourceQuota limits resource usage per namespace.

kubectl logs pod-name -c container-name --tail=100

Why wrong: This shows container logs, not arbitrary file contents.

kubectl cp pod-name:/var/log/app.log -

Why wrong: 'kubectl cp' copies files but requires a local destination path.

kubectl attach pod-name

Why wrong: Attach connects to the container's stdin/stdout, not for viewing files.

Via the node's IP address and a high port

Why wrong: NodePort services expose on node IP and high port, but ClusterIP is internal only.

Via an external load balancer

Why wrong: External load balancers are used with LoadBalancer services, not ClusterIP.

Directly via the pod's IP address

Why wrong: Pod IPs are ephemeral and not stable; services abstract away pod IPs.

NetworkPolicies are blocking cross-namespace traffic

Why wrong: While possible, the most likely cause is DNS naming.

The Service is not publishing the correct port

Why wrong: Port mismatch would cause connection failure, not DNS resolution issues across namespaces.

The Service selector does not match the Pod labels

Why wrong: If the selector didn't match, the Service wouldn't work within the namespace either.

Check that the container runtime is working

Why wrong: Container runtime issues affect Pods, but the Service connectivity problem is likely at the network layer.

Check the kube-apiserver status

Why wrong: The API server is for managing the cluster state, not for forwarding traffic to Services.

Restart all nodes in the cluster

Why wrong: This is a drastic measure and not an appropriate first troubleshooting step.

container resource limits

Why wrong: Resource limits control CPU/memory usage, not node selection.

tolerations

Why wrong: Tolerations are used to allow scheduling on tainted nodes, not to select nodes by label.

nodeAffinity

Why wrong: nodeAffinity provides more advanced scheduling but is not the only option; nodeSelector is simpler and sufficient.

Use an external service registry like Consul or etcd

Why wrong: While possible, this is not the most Kubernetes-native approach; Kubernetes provides built-in service discovery via DNS.

Hardcode the cluster IP of Service B in the configuration of Service A

Why wrong: Hardcoding is brittle and does not adapt to changes in the Service's IP.

Use environment variables injected by the Kubernetes API into each pod

Why wrong: While environment variables are injected, they are not updated if the Service changes, and they are less flexible than DNS-based discovery.

All pods are immediately terminated

Why wrong: The kubelet continues running pods independently.

Pods are rescheduled to the control-plane node

Why wrong: The control-plane node is unreachable, so rescheduling is not possible.

The worker node is automatically cordoned

Why wrong: Cordoning requires interaction with the control plane.

The Service is not associated with a namespace

Why wrong: Every Service must have a namespace.

The Service is exposed on the wrong port

Why wrong: Even if the port is wrong, endpoints would still exist if pods match.

The kube-proxy is not running on the node

Why wrong: Kube-proxy handles traffic, but endpoints would still be populated.

kubectl describe pod db-service

Why wrong: There is no pod named 'db-service' likely; the pod has a different name.

kubectl exec -it <some-pod> -- curl db-service

Why wrong: While this tests connectivity, first verify endpoints exist.

kubectl logs db-service

Why wrong: You cannot log a service; logs are for pods.

The pod will be throttled to 500m CPU

Why wrong: Throttling occurs only above the limit, not the request.

The pod will be evicted from the node

Why wrong: Eviction occurs due to memory pressure or disk pressure, not CPU usage.

The pod will be terminated for exceeding the limit

Why wrong: CPU is compressible; exceeding CPU limit causes throttling, not termination.

Deployment

Why wrong: Deployments are for long-running services, not batch jobs that run to completion.

CronJob

Why wrong: CronJob is for scheduled jobs, but the requirement is to run once, not on a schedule.

DaemonSet

Why wrong: DaemonSet runs one pod per node, not appropriate for batch jobs.

The Service type should be NodePort

Why wrong: Type ClusterIP works within the cluster.

The pod is in a different namespace

Why wrong: Services only select pods in the same namespace.

The pod's container port is not defined

Why wrong: The Service targetPort must match the container port, but missing container port would not prevent traffic if targetPort matches.

Node affinity with requiredDuringSchedulingIgnoredDuringExecution

Why wrong: Node affinity selects nodes based on node labels, not pod relationships.

Pod affinity with a preferredDuringSchedulingIgnoredDuringExecution

Why wrong: Pod affinity attracts pods to nodes with other pods; requiredDuringScheduling forces it.

Taints and tolerations

Why wrong: Taints and tolerations prevent pods from being scheduled on nodes with taints, but do not enforce pod-to-pod separation.

4 pods running

Why wrong: 4 would be the maximum allowed by maxSurge=1, but the controller would not keep both old and new at full count simultaneously during update.

3 pods running

Why wrong: 3 would be the initial count; after update and failure, only 2 remain.

1 pod running

Why wrong: The new ReplicaSet has 2 pods; the old had 1 left before failure, but after failure, only the 2 new pods remain.

Tight coupling between services to ensure performance

Why wrong: Tight coupling is an anti-pattern; microservices aim for loose coupling.

Monolithic codebase with centralized deployment

Why wrong: This describes a monolithic architecture, not microservices.

Use of a single, shared database for all services

Why wrong: Microservices often use a database-per-service pattern to ensure autonomy.

Infrastructure is version-controlled using Git

Why wrong: Version control is a practice, not a defining characteristic of immutability.

Servers are updated in-place with configuration management tools

Why wrong: That is mutable infrastructure.

Containers are used to ensure portability

Why wrong: Portability is a benefit of containers, but not specific to immutability.