Application Deployment practice questions

ConfigMap

Why wrong: A ConfigMap is an API object for storing non-confidential key-value configuration data, such as environment variables, command-line arguments, or config file contents. It has no IP address, DNS name, or endpoint mechanism, and mounting it into a Pod does not make the Pod reachable to other components. Thus, while a ConfigMap might hold the microservice's settings, it cannot provide the network endpoint that the deployment requires.

Secret

Why wrong: A Secret is designed to hold sensitive information (e.g., passwords, tokens, keys) and is encoded in etcd; it is injected into Pods via volume mounts or environment variables. A Secret does not create any networking objects or assign any cluster-internal identity, so it cannot be used for service discovery or stable network addressing. Even though a Secret might contain connection details for another service, it does not itself make the microservice reachable.

Ingress

Why wrong: An Ingress is an L7 (HTTP/HTTPS) routing object that manages external access to Services, typically via path- or host-based rules through a controller (e.g., NGINX). It exposes web traffic from outside the cluster, but it does not create an internal stable IP/DNS entry for Pod-to-Pod communication within the cluster. Service discovery inside Kubernetes relies on the built-in Service object and DNS, not on Ingress.

The liveness probe is failing

Why wrong: A failing liveness probe triggers a container restart, but that alone does not create a stuck rollout with back-off. After the kubelet restarts the container, subsequent successful probes keep the pod running, so no crash-related or image-related back-off occurs. A persistent liveness failure would eventually produce CrashLoopBackOff, but the observed reason would be 'Back-off restarting failed container' after repeated crashes, not an immediate ImagePullBackOff.

The image pull secret is missing

Why wrong: A missing image pull secret results in failed registry authentication, so the kubelet cannot download the container image from a private repository. The pod therefore transitions through phases of ErrImagePull and ImagePullBackOff, which are distinct from crash-loop back-off caused by command exits. Because the container never starts, the rollout cannot progress until the correct Secret is applied to the namespace or referenced in the podSpec.

The pod exceeds its memory limit and is OOMKilled

Why wrong: An OOMKilled status means the kernel terminated the container because it exceeded its memory limit, not because of a faulty entrypoint. The container state shows 'OOMKilled' and the exit reason is '137' (SIGKILL), which is not the same as the restart back-off seen when a command fails repeatedly. While the pod may be restarted, the underlying cause is memory pressure, so fixing it requires raising the limit or reducing workload memory usage, not debugging the entrypoint logic.

backoffLimit: 0

Why wrong: backoffLimit: 0 is a Job spec field that controls how many times the controller retries a failed Pod before the Job is marked as failed. Setting it to 0 means the Job will fail immediately if the first Pod fails, but it has no impact on what happens to Pods after the Job completes successfully. The developer's goal is to retain the completed Pod for later inspection, and backoffLimit only governs retry behavior, not pod retention or cleanup.

ttlSecondsAfterFinished: -1

Why wrong: ttlSecondsAfterFinished: -1 is not a valid configuration because the TTL field expects a non-negative integer; Kubernetes API validation rejects negative values. Even if the API accepted it, the field is specifically designed to automatically delete the Job after the specified number of seconds from completion, not to disable cleanup. To retain Pods, you must simply leave the field unset, because relying on a negative value to mean 'keep forever' is neither documented nor supported.

activeDeadlineSeconds: 3600

Why wrong: activeDeadlineSeconds: 3600 sets a time limit on the duration of a Job's active Pods; if the total running time exceeds 3600 seconds, the Job is terminated and marked as failed. This parameter is useful for bounding how long a job can run, but it does not affect pod retention after the Job finishes. Since the data processing job is presumably expected to finish well within an hour and the developer wants to retain the successful Pod, this deadline does not solve the cleanup or retention question.

Deployment

Why wrong: A Deployment manages stateless pods as interchangeable replicas; each pod gets a random hostname and no guaranteed stable network identity. Persistent database clusters need each node to maintain a fixed identity so clients and peers can reliably reconnect. Deployments also lack volumeClaimTemplates, making it awkward to give every pod its own dedicated PersistentVolume. Thus, using a Deployment for a database cluster risks split-brain and data inconsistencies.

CronJob

Why wrong: CronJob is fundamentally a job scheduler: it creates one or more short-lived Pods at predetermined times to run tasks like backups or reports, then terminates them. It does not maintain a continuous, multi-node cluster, nor does it provide stable identities or persistent storage for a database. Even if you scheduled a database launch, it would run once and exit, so a highly available stateful cluster cannot be built on CronJob.

DaemonSet

Why wrong: DaemonSet ensures that a copy of a Pod runs on every node in the cluster, which is ideal for node-level infrastructure such as log collectors, metrics agents, or network proxies. For a database cluster, using a DaemonSet would tie replica count to the node count and force exactly one database pod per node, with no control over cluster state or scaling based on capacity. DaemonSet also does not provide per-replica persistent volumes or ordered startup, so it cannot support the requirements of a coordinated database cluster.

5

Why wrong: The value 5 represents the desired steady-state replica count, not the upper limit during a rolling update. Because maxSurge=2 explicitly allows the controller to spin up additional pods beyond that target (up to 2 extra) to speed up the rollout, the actual pod count can temporarily exceed 5. Thus, answering 5 confuses the normal operating level with the surge-allowed maximum.

8

Why wrong: A total of 8 pods would require a maxSurge of at least 3, since the desired replicas is 5 and 5 + 3 = 8. In this deployment, maxSurge is set to 2, which caps the total pod count at 5 + 2 = 7. Therefore, 8 is an impossible number because it exceeds the configured surge limit and the controller would never allow such an over-provisioned state.

6

Why wrong: While 6 is a possible intermediate value during the rolling update—for example, when one new pod is created before any old pod is terminated—it is not the maximum. The surge configuration permits up to 2 extra pods, not just 1, so the controller can transiently run 7 pods in total. Choosing 6 underestimates the surge allowance and ignores the full extent of the 2-pod buffer.

StatefulSet

Why wrong: StatefulSet is designed for stateful workloads that require stable network identities, persistent storage, and ordered deployment, not for ensuring a pod runs on every node. It maintains a specified number of replicas, but those replicas are scheduled arbitrarily across nodes based on available resources and constraints. For a critical application that must be present on every cluster node, a DaemonSet is the appropriate controller.

ReplicaSet

Why wrong: ReplicaSet is a low-level controller that simply ensures a specified number of pod replicas are running, but it has no concept of node-wide coverage. Even if you set the replica count equal to the number of nodes, the scheduler may pack multiple replicas onto the same node, leaving other nodes without a copy. ReplicaSets are mainly used internally by Deployments and are not intended for daemon-style per-node workloads.

Deployment

Why wrong: Deployment manages ReplicaSets and provides declarative rolling updates, scaling, and self-healing, but it targets a desired replica count rather than every node. To run a pod on all nodes, a Deployment would require complex node affinity/anti-affinity rules and still would not automatically cover newly added nodes. The native Kubernetes workload object for guaranteeing one pod per node is a DaemonSet, not a Deployment.

kubectl logs <pod-name>

Why wrong: kubectl logs streams the container's stdout and stderr, which reflect application output, errors, and possibly probe failure messages generated by the kubelet—but it never reveals the probe configuration defined in the pod spec. The developers' request is about checking how probes are set, not app-level messaging. Thus, logs cannot show endpoints, thresholds, or probe types, making this the wrong tool.

kubectl exec <pod-name> -- env

Why wrong: kubectl exec ... -- env runs the env binary inside the container, printing environment variables like PATH and custom variables—information entirely unrelated to pod-level or container-level probe settings. It requires a running container with a shell/environment tool, and it cannot access the pod's API representation. Therefore, it provides no insight into how liveness or readiness probes are configured.

kubectl get pod <pod-name>

Why wrong: kubectl get pod outputs a concise table of the pod's status, such as NAME, READY, STATUS, RESTARTS, and AGE, which is useful for a quick overview but omits all container-level details, including probe definitions. Unless combined with -o yaml or -o json, it does not expose the spec fields where probes live. Hence, it cannot show the probe configuration the developer needs.

kubectl set image deployment/<name> <container>=<new-image>

Why wrong: This command updates the container image reference in the deployment's pod template, which in turn creates a new ReplicaSet and restarts pods—so it would indirectly refresh the mounted ConfigMap. However, using it solely to reload configuration is wrong because it changes the deployed container image, potentially introducing an unintended version or tag, and it does not regard ConfigMap as the source of change. The image update is a side effect, not a targeted way to propagate ConfigMap changes.

The pods automatically mount the new ConfigMap within seconds

Why wrong: The kubelet periodically syncs ConfigMap volumes, so a file mounted as a volume may eventually show updated data after the sync period (often up to a minute), but environment variables are injected only at pod creation and never refreshed. Crucially, most applications read configuration at startup, so even if the volume file changes, the running process does not reload it automatically. Therefore, saying pods automatically mount the new ConfigMap within seconds is false and risky; a rollout restart is required to guarantee the new configuration is loaded.

Delete and recreate each pod manually

Why wrong: Manually deleting each pod forces the ReplicaSet controller to create replacements that mount the updated ConfigMap, but this is an imperative, ad-hoc process that requires handling multiple pods individually and offers no granular rollout control. If you delete all pods at once, you risk downtime unless you carefully sequence deletions; and you lose the deployment rollout history and easy rollback that a rollout restart provides. The Kubernetes-native approach is to trigger a new rollout declaratively rather than phasing pods by hand.

Canary

Why wrong: Canary is a release pattern that routes a small subset of live traffic to a newly deployed version before gradually increasing the percentage. It is not a built-in Deployment strategy field; Kubernetes only offers `RollingUpdate` and `Recreate` for the `strategy.type` setting. To implement canary, you typically combine a Deployment with a Service Mesh, Ingress controller, or a progressive delivery tool like Argo Rollouts.

Ramped

Why wrong: Ramped is merely an alternative term for the rolling update process, often used in visual deployment strategy diagrams to describe the gradual increase in new pod count. It is not a separate strategy in Kubernetes; the only two `strategy.type` values you can set are `RollingUpdate` and `Recreate`. Selecting 'Ramped' as a strategy would be invalid, as it does not correspond to any Kubernetes API field.

Blue/Green

Why wrong: Blue/Green is a release pattern that runs two complete environments (older 'blue' and newer 'green') simultaneously, then switches the service selector to the green version to instantly shift all traffic. It is not a built-in Deployment strategy, because the Deployment API itself only supports `RollingUpdate` or `Recreate`. Implementing blue/green requires additional resources like a Service or an ingress to perform the traffic switch, and it can be automated with tools such as Flagger or Argo Rollouts.

Ingress

Why wrong: Ingress is not a Service type, so it is invalid here. Ingress is a separate API object that defines HTTP/HTTPS routing rules (host, path, TLS) to Services, usually ClusterIP Services, and requires an Ingress controller (e.g., NGINX, Traefik) to implement them. While an Ingress can expose applications externally, it does not itself select pods or create endpoints; it only routes to Services.

ExternalName Service

Why wrong: ExternalName Service is invalid because it does not expose pods at all; it maps a Service name to an external DNS name by returning a CNAME record. It has no selector and no endpoints, so kube-proxy does not route traffic to pods. Instead, it allows pods to reference an external service (e.g., an RDS instance) using a local Service name, which is unrelated to exposing a pod set externally.

The new ReplicaSet must have the desired number of pods

Why wrong: During a rolling update, the new ReplicaSet is scaled up incrementally, with the controller determining the exact scale based on the rollout's surge and availability constraints. The new ReplicaSet only reaches the full desired replica count at the very end of the rollout, after the old ReplicaSet has been fully scaled down. Requiring it to have the desired number from the start would defeat the purpose of rolling updates, which aim to maintain service availability by avoiding all-at-once pod replacement.

The old ReplicaSet must be scaled to zero

Why wrong: In a rolling update, the old ReplicaSet is scaled down gradually, in lockstep with the new ReplicaSet's scale-up, to keep the total number of pods within the surge and availability limits. It is never scaled to zero at the beginning; instead, its scale gradually decreases to zero only at the end of the rollout. Scaling it to zero immediately would be a recreate strategy, not a rolling update, and would cause downtime.

The old ReplicaSet must be deleted

Why wrong: Kubernetes retains the old ReplicaSet after a rollout completes, along with its pod template's revision history. This historical record enables instant rollback to a previous version by simply scaling down the current ReplicaSet and scaling up the old one. Deleting the old ReplicaSet would eliminate the ability to perform an easy rollback to that prior revision, so it is intentionally kept (subject to revisionHistoryLimit).

The StatefulSet's serviceName does not match the backend Service name

Why wrong: The serviceName field in a StatefulSet must reference a headless Service to serve as the governing Service for stable network identities. If it doesn't match the backend Service name, the StatefulSet cannot associate the pods with that Service, but the root cause here is that the referenced Service is not headless at all. Even a perfectly matching serviceName is useless for per-pod DNS records unless the Service has clusterIP: None.

The backend pods are not using the correct DNS domain

Why wrong: Kubernetes' default cluster DNS suffix is cluster.local, and StatefulSet pod FQDNs are constructed as <pod-name>.<service-name>.<namespace>.svc.cluster.local. The backend pods would only have DNS issues if the cluster's DNS domain were explicitly overridden or misconfigured, which is not indicated by the problem statement. Since the default domain is in effect, the DNS domain is not the source of the failure.

The frontend Service is interfering with the backend DNS

Why wrong: Services in Kubernetes are independent networking abstractions; the frontend Service only affects traffic destined for its own selector and has no bearing on DNS resolution for backend pods. DNS lookups for backend pod DNS names are answered by the cluster DNS service based on the backend Service and its pod endpoints. A frontend Service cannot influence or interfere with those DNS records, so this option is incorrect.

The Deployment's progressDeadlineSeconds is set too high

Why wrong: progressDeadlineSeconds governs the maximum time a Deployment may remain in a progressing status before it is marked as failed. A high value would only delay the rollout failure detection, not the ReplicaSet's immediate reconciliation loop. Since the ReplicaSet creates a replacement pod as soon as it observes fewer than the desired number of active pods, an elevated progressDeadlineSeconds has no bearing on the initial scheduling delay.

The application's readiness probe is failing on the new node

Why wrong: A failing readiness probe causes the pod to be excluded from Service endpoints and marked NotReady, but it does not prevent the ReplicaSet from creating new pods. The ReplicaSet controller counts the pod as existing even if it is not ready, so the desired replica count is satisfied. Thus, a readiness probe failure would not explain a delay in pod creation, though it would explain traffic not being routed to the pod.

The nodeSelector is preventing the pod from being scheduled on available SSD nodes

Why wrong: A nodeSelector constraint causes a pod to remain Pending indefinitely if no node matches the label selector, but it does not affect the ReplicaSet's pod creation logic. The ReplicaSet still creates a replacement pod as soon as it realizes the old pod is gone; the placement problem arises after creation. In this scenario, the delay stems from the pod's final deletion, not from scheduling constraints, so nodeSelector is not the root cause.

ClusterIP

Why wrong: ClusterIP exposes the Service on a stable virtual IP that is only routable from inside the Kubernetes cluster; it is not reachable from outside the cluster without an additional proxy or tunnel. Since the requirement is to deploy a stateless web application for external users, a ClusterIP Service alone cannot provide any external connectivity. It also cannot terminate TLS or apply routing rules, because it operates purely at L4 inside the cluster network.

NodePort

Why wrong: NodePort publishes the Service on every node's IP at a static port in the 30000–32767 range, making it externally reachable without a cloud LoadBalancer. However, it only provides raw TCP/UDP passthrough at L4, so it cannot terminate SSL/TLS, perform host- or path-based routing, or offload HTTPS termination. For the stated goal of a web application requiring SSL termination and route management, NodePort is insufficient and would force clients to handle TLS themselves or require a separate reverse proxy.

LoadBalancer

Why wrong: A LoadBalancer Service provisions a cloud provider–managed external load balancer (e.g., AWS ELB, GCP TCP LB) and assigns a public IP, which gives external access to the web application. However, a standard LoadBalancer Service operates at L4 and forwards raw TCP traffic to the backend pods, so it does not terminate SSL/TLS or support host/path-based routing rules. It would require a separate TLS-terminating proxy or a custom LoadBalancer implementation, making it less suitable than Ingress for the stated SSL and routing requirements.

DaemonSet

Why wrong: A DaemonSet guarantees a pod copy runs on every node (or a subset) and is intended for long-running infrastructure components like log shippers or health probes, not for one-off tasks. Deploying a batch job as a DaemonSet would start the container on potentially many nodes simultaneously and there is no controller logic to treat a successful pod exit as a completed task—the pod would be restarted or remain failed. The batch's expectation of running once and exiting successfully is therefore fundamentally at odds with DaemonSet's per-node, continuous execution model.

Deployment

Why wrong: Deployment manages a replica set of pods that are meant to run indefinitely, with a desired state that is continuously maintained through restarts, scaling, and rolling updates. A batch job is by definition transient: it should run to completion and then exit with a zero status. If wrapped in a Deployment, the pod's exit would be seen as a crash, triggering an automatic restart with backoff, so the work would either never be acknowledged as complete or would loop unexpectedly. Deployment is appropriate for stateless web services, not finite batch workloads.

StatefulSet

Why wrong: StatefulSet is designed for stateful applications that require stable unique network identifiers, persistent storage per instance, and ordered scaling/termination—characteristics of databases, key-value stores, or other clustered services. A batch job typically has no such needs: it is stateless, requires no stable identity, and is expected to terminate when the work is done. Using a StatefulSet would force the batch container to be treated as a long-lived, replicated service, and because the controller expects pods to stay alive, the successful completion of a batch workload would be misread as a failure. StatefulSet therefore adds unnecessary complexity and breaks the job-completion model.

hostPath

Why wrong: hostPath mounts a specific file or directory from the node's filesystem into the pod. It does not read from any Kubernetes API object, so it cannot deliver ConfigMap key-value pairs as requested. Using hostPath would require manually placing configuration data on a node's disk and creates portability and scheduling issues, since the pod would rely on node-local files. Therefore it is the wrong volume type for this requirement.

persistentVolumeClaim

Why wrong: A persistentVolumeClaim is a request for cluster storage backed by a PersistentVolume, such as an EBS volume or NFS share. It provides a raw block or filesystem store where files persist beyond pod restarts, but it has no mechanism to inject a ConfigMap's data. Even if you manually copied configuration data into the PV, the ConfigMap object would not be the source of truth and updates would not be propagated, so this option does not satisfy the microservice's need.

emptyDir

Why wrong: emptyDir creates an initially empty, ephemeral volume whose lifetime is tied to the pod. It is useful for scratch space or sharing data between containers in the same pod, but it never gets populated with ConfigMap contents. Since the volume starts empty and only holds whatever containers write to it, it cannot provide the key-value pairs from a ConfigMap, making this option incorrect for the deployment.

Job

Why wrong: A Job is a workload controller for finite, batch tasks that run to completion, such as data migration or backup. It cannot maintain a long-running stateful database because if the database process exits, the Job treats it as successful completion rather than restarting it, and it does not provision stable persistent storage or stable network identities for each replica. Therefore, a Job is inappropriate for deploying a continuously available database.

Deployment

Why wrong: A Deployment manages stateless, interchangeable pods with random identifiers; its default behavior is to create and destroy pods without guaranteeing stable hostnames or fixed storage per replica. Deployments share volumes across replicas rather than provisioning unique persistent storage per pod, and rolling updates recreate pods with new names, breaking database cluster membership. Because databases need each node to have a stable identity and dedicated storage, a Deployment is not suitable without heavy external workarounds.

DaemonSet

Why wrong: A DaemonSet is designed to run exactly one pod per node for node-level services like log collection or monitoring, ensuring cluster-wide coverage. It cannot be used to run a database replica set because its pod count is tied to cluster nodes, not application requirements, and it does not provide separate stable storage or identity per database instance. Scaling a DaemonSet means adding nodes, not adding database replicas, so it is fundamentally misaligned with a stateful database deployment.

Pods will become ready after 30 seconds when both probes pass.

Why wrong: The readiness probe hits /ready and gets a 200 response immediately after the container starts, so the pod becomes ready well before the 30-second mark. Liveness probe failures do not delay readiness; they only trigger container restarts. Therefore, the pod does not wait for both probes to pass, and this statement is inaccurate.

Pods will never become ready because the liveness probe fails initially.

Why wrong: Readiness and liveness probes serve independent purposes: readiness controls whether the pod is added to Service endpoints, while liveness only determines if the container should be restarted. Even though the liveness probe fails initially, the readiness probe still succeeds, so the pod becomes ready immediately. The failing liveness probe will cause repeated restarts, but it never prevents the pod from being marked ready. Thus the pod does become ready, making this option false.

Pods will never become ready because the readiness probe fails initially.

Why wrong: The readiness probe is configured to request /ready, which returns HTTP 200 as soon as the application process starts, so it passes on the first check. There is no initial failure period for readiness; the probe succeeds immediately. Consequently, the pod is marked ready almost instantly, not never. This option incorrectly assumes readiness fails initially, but the configuration shows it succeeds right away.

Set maxUnavailable=1

Why wrong: Setting maxUnavailable=1 permits the deployment to make up to one pod unavailable during the update, meaning the available replica count can drop to 3 out of the desired 4. This creates a temporary capacity shortfall and could potentially cause degradation or downtime for the application. Consequently, it does not satisfy the requirement of maintaining full replica availability.

Use Recreate strategy

Why wrong: The Recreate strategy is a deployment strategy that terminates all existing pods at once, and only after they are fully removed does it create new pods. This results in a period of zero available replicas, causing complete application downtime during the update. For a deployment that must always have 4 replicas available, this strategy is fundamentally unsuitable.

Set maxSurge=0

Why wrong: Setting maxSurge=0 disallows the creation of any extra pods beyond the desired 4 replicas. If maxUnavailable is also 0, the deployment cannot proceed because there are no spare pods to replace existing ones; if maxUnavailable is greater than 0, the controller must first terminate pods, reducing the available replica count below 4. Thus, this setting either blocks the update or allows a temporary drop in capacity, making it incorrect for ensuring continuous availability.

Containers in a pod share the same filesystem root.

Why wrong: Each container in a pod runs with its own root filesystem, isolated by the container runtime, so they do not share the same filesystem root. While containers in a pod can share volumes by mounting them explicitly, they cannot access each other's root filesystems without doing so. This isolation is a fundamental security boundary even within the same pod.

The sidecar container must use the same image as the main container.

Why wrong: The sidecar container is a separate container that can run a completely different image from the main application container. For example, a web application container might use an nginx image, while a log-shipping sidecar uses a Fluentd image. Kubernetes only requires that all containers in a pod be co-scheduled and share resources; it does not mandate any image consistency.