1. Explain the difference between a Deployment and a StatefulSet in Kubernetes, and describe a scenario where you would use each.

A Deployment manages stateless applications with identical replicas that can be scheduled on any node, using a ReplicaSet controller to ensure desired pod count and rolling updates. A StatefulSet manages stateful applications requiring stable network identities and persistent storage, assigning each pod a unique ordinal and maintaining the same hostname across restarts. Use Deployments for web servers or APIs, and StatefulSets for databases or message queues that need ordered startup, stable DNS, and persistent volumes.

2. Your team deployed a service but pods are not receiving traffic. Walk through your debugging approach using kubectl commands to identify the root cause.

First, verify pods are running with kubectl get pods and check their status and readiness probes using kubectl describe pod. Next, inspect the Service resource with kubectl get svc and kubectl describe svc to confirm the selector matches pod labels and endpoints are populated with kubectl get endpoints. Then test connectivity inside the cluster using kubectl exec to curl the service DNS name, and check NetworkPolicies or Ingress rules that might block traffic. Finally, examine logs with kubectl logs to identify application-level errors or startup failures.

3. What is a resource request and limit in Kubernetes, and what happens when a pod exceeds its memory limit?

A resource request is the minimum CPU or memory guaranteed for a pod, used by the scheduler to place pods on nodes with sufficient available resources. A limit is the maximum a pod can consume; if a pod exceeds its memory limit, the kubelet will terminate the pod with an OOMKilled status. CPU limits work differently—the kernel throttles CPU usage rather than killing the pod. Properly setting requests ensures even distribution across nodes and prevents underutilized clusters, while limits protect node stability from runaway workloads.

4. Design a high-availability deployment for a stateless web application that must handle 10,000 concurrent users. What Kubernetes primitives would you use and what trade-offs would you consider?

Use a Deployment with multiple replicas managed by a Horizontal Pod Autoscaler that scales based on CPU or custom metrics, ensuring pods spread across multiple nodes with pod anti-affinity rules. Front the deployment with a LoadBalancer or Ingress service to distribute traffic, and configure readiness probes to ensure only healthy pods receive traffic. Trade-offs include higher resource costs for redundancy, complexity in monitoring and managing autoscaling policies, and the need for a persistent metric backend like Prometheus for HPA decision-making. Consider node affinity and topology spread constraints to distribute replicas across availability zones if running on a multi-zone cluster.

5. Explain how ConfigMaps and Secrets differ, and describe a security concern with each.

ConfigMaps store non-sensitive configuration data as key-value pairs and are not encrypted by default, making them unsuitable for passwords or tokens. Secrets store sensitive data like credentials and are base64-encoded but also unencrypted at rest by default in etcd, creating a security vulnerability if cluster access is not restricted. Both can be mounted as volumes or injected as environment variables into pods. The primary security concern with ConfigMaps is accidental exposure of sensitive data, while Secrets require encryption-at-rest enablement and RBAC policies to prevent unauthorized access to etcd or secret contents via kubectl.

6. A developer wants to run a batch job that processes 1000 log files. Design a solution using Kubernetes Job or CronJob, and explain your choice.

Use a Kubernetes Job with parallelism set to 10 and completions set to 1000, allowing 10 pods to run concurrently and process all files across multiple retries if any pod fails. Configure backoffLimit to define maximum retries and ttlSecondsAfterFinished to automatically clean up completed job resources. If processing recurs on a schedule, wrap it in a CronJob that creates new Job objects at specified times. The Job approach is preferred for one-time bulk processing because it automatically retries failed pods, tracks completion status, and cleans up resources, whereas CronJob is better for recurring workloads like daily log archival.

7. What is a liveness probe, a readiness probe, and a startup probe? Give an example of when each would differ.

A liveness probe detects if a container is deadlocked or hung and restarts it, while a readiness probe signals if a pod is ready to receive traffic, removing it from the load balancer if it fails. A startup probe gives applications extra time to initialize before liveness and readiness probes run, useful for slow-starting applications. An example: a Java application might use a startup probe checking if the application has fully initialized, a readiness probe hitting the health endpoint to confirm it can handle requests, and a liveness probe executing a TCP connection to detect frozen threads. Without distinction, a slow startup would cause premature restarts before the app is ready.

8. Describe how Kubernetes resource quotas and limit ranges work together to enforce cluster-wide resource governance.

ResourceQuota sets aggregate limits on CPU, memory, pods, and services per namespace, preventing one team from monopolizing cluster resources. LimitRange enforces minimum and maximum resources per pod or container within a namespace, and can set default requests and limits if not specified. Together, a quota might allow namespace production 100 CPU cores total, while a limit range ensures no single pod can consume more than 16 cores or have less than 100m CPU requested. If a pod creation would violate either, the API server rejects it immediately. This two-level enforcement enables fair resource sharing across teams while preventing resource starvation or runaway workloads.

9. A pod is stuck in pending state. List three possible causes and how you would diagnose each.

First cause: insufficient node resources; run kubectl describe node to check available CPU and memory, and verify pod requests are not exceeding available capacity. Second cause: node selector or affinity mismatch; check the pod spec for nodeSelector or affinity rules that conflict with node labels using kubectl get nodes --show-labels. Third cause: insufficient persistent volume capacity or unavailable storage class; check kubectl get pvc to see if volumes are bound and inspect the storage class with kubectl describe storageclass. The describe pod output shows events explaining why scheduling failed, which is the fastest diagnostic path.

10. Explain how Kubernetes network policies work and design a policy to restrict a frontend pod to only receive traffic from an Ingress controller and communicate with backend pods on port 8080.

NetworkPolicy uses selectors and port specifications to allow or deny traffic between pods and external sources, defaulting to allow-all if no policy exists. Create an ingress policy selecting the frontend pods, allowing traffic from pods with the ingress-controller label on all ports, and a separate egress policy allowing traffic to backend pods with a backend label on port 8080 only. Combine both policies in a single NetworkPolicy manifest with podSelector matching frontend labels, policyTypes including both Ingress and Egress, and separate ingress and egress rules. Apply the policy in the same namespace, and verify it using kubectl get networkpolicy and testing connectivity with kubectl exec.

11. Your cluster has persistent volumes that were provisioned manually. A developer requests automatic volume provisioning for a new application. Explain storage classes and how you would set one up.

A StorageClass is a Kubernetes resource that defines how to dynamically provision persistent volumes on-demand, specifying a provisioner like AWS EBS, Azure Disk, or a CSI driver, and parameters like volume type or replication factor. Create a StorageClass manifest specifying the provisioner and parameters, then a PersistentVolumeClaim can reference this class by name in its storageClassName field, triggering automatic volume creation. The advantage over manual provisioning is eliminating the lag between requesting storage and availability, enabling self-service for developers, and allowing different storage tiers for different workloads. Set a default StorageClass by adding the storageclass.kubernetes.io/is-default-class annotation so claims without a specified class automatically use it.

12. A team member accidentally exposed a secret in a pod's environment variable that was logged to stdout. How would you remediate this, and what preventive measures would you recommend?

Immediately rotate the exposed credential in your external system, create a new Secret with the rotated value, and update the pod or Deployment to reference the new secret, triggering a rolling restart. Search logs and container image registries to determine exposure scope, and audit RBAC and secret access logs to identify who accessed the secret. Prevent future incidents by enforcing pod security policies that deny privileged containers, implementing audit logging on all secret reads, using encryption-at-rest for etcd, and restricting kubectl access via RBAC. Additionally, configure applications to read secrets from mounted volumes rather than environment variables, which reduces accidental logging of values, and use tools like sealed-secrets or external secret operators to manage secret lifecycle.