Hard Difficulty Questions

Service

Why it fails: A Service provides stable virtual IPs and load balancing to a pod set; it forwards traffic rather than permitting or denying it. It is tempting because Services genuinely define how pods are reached, which suits service discovery and exposure, whereas inter-pod traffic control requires NetworkPolicy.

PodSecurityPolicy

Why it fails: PodSecurityPolicy governs pod security contexts — privileges, volumes, capabilities — and never inspects network traffic between pods. It is tempting because it genuinely restricts what pods may do at admission time, which suits hardening workloads, but traffic filtering between pods requires NetworkPolicy.

Ingress

Why it fails: Ingress manages inbound HTTP and HTTPS routing to Services; it does not select pods or define allow/deny rules between them. It is tempting because Ingress genuinely controls external access into the cluster, which suits exposing applications, whereas pod-to-pod traffic control requires NetworkPolicy.

The Pod's restartPolicy is set to Always, which causes the volume to be recreated after deletion.

Why it fails: restartPolicy controls container restarts within a Pod, not volume persistence. Even with Always, when the Pod is deleted, the hostPath volume remains because it is tied to the node, not the Pod. The policy does not affect volume lifecycle.

The volume is backed by a PersistentVolume that retains data even after the Pod is deleted.

Why it fails: A PersistentVolume is a separate resource with its own lifecycle and reclaim policy. The scenario describes a hostPath volume, not a PersistentVolume. hostPath volumes are ephemeral from the Pod's perspective but persistent on the node's filesystem.

The kubelet caches volume data in memory and writes it back to the hostPath after Pod deletion.

Why it fails: The kubelet does not cache volume data in memory for hostPath volumes. Data is written directly to the host's filesystem. There is no write-back mechanism; the persistence is simply because the host directory is not cleaned up when the Pod is removed.

Use a single centralized logging solution to aggregate logs from all components.

Why it fails: Single point of failure; prefer highly available solutions.

Store all debug logs for a minimum of 90 days for compliance.

Why it fails: Debug logs are verbose; store selectively.

Disable leader election for monitoring components to reduce complexity.

Why it fails: Leader election prevents duplicate metrics in HA setups.

Helm

Why it fails: Helm templates and versions Kubernetes manifests; it has no runtime flag evaluation or targeting rules. It tempts because chart values can toggle configuration per release, which suits deployment-time variation, but flags must change without redeploying, which Helm cannot do.

Kustomize

Why it fails: Kustomize overlays patch Kubernetes manifests per environment; it cannot evaluate flags at runtime or target individual users. It tempts because overlays vary configuration between deployments, which suits environment-specific settings, but feature-flag evaluation requires a dedicated flag management service.

Argo Rollouts

Why it fails: Argo Rollouts automates progressive delivery through canary and blue-green strategies, shifting traffic by percentage, but it exposes no user-targeting flag SDK. It tempts because gradual rollout resembles flagging, and it would be correct for automated canary analysis, not runtime toggles.

The container is running but producing no output

Why it fails: PodInitializing means init containers are still running, so the main container has not started and has produced no log output at all. It is tempting because a started container with a silent application also returns no lines, which would be the correct reading once the pod reaches Running state.

The container runtime is failing to start the container

Why it fails: The BadRequest arises because the container is waiting on init containers, not because the runtime failed; a genuine runtime failure surfaces as ImagePullBackOff, CrashLoopBackOff or a create-container error. It is tempting because waiting states often accompany start failures, which would be the right diagnosis if the status showed a runtime error rather than PodInitializing.

The container has crashed and is restarting

Why it fails: PodInitializing means init containers or image pulls are still completing, so the main container has not started at all; a crash-restart loop would instead show CrashLoopBackOff with a non-zero exit code. Restarting is the right diagnosis when logs reveal repeated container exits, not a pod still in its initialisation phase.

Knative

Why it fails: Knative is a serverless framework on Kubernetes, but it requires cluster management and may not scale to zero as efficiently as a FaaS platform.

Apache Kafka

Why it fails: Apache Kafka is a distributed streaming platform, not designed for serverless function execution.

Kubernetes CronJob

Why it fails: Kubernetes CronJob is for scheduled tasks, not event-driven processing, and does not automatically scale to zero.

Deploy a single Kubernetes cluster spanning all regions

Why it fails: A single cluster spanning regions places its control plane across a WAN, so a region outage partitions etcd quorum and stalls scheduling cluster-wide, worsening rather than tolerating failure. It tempts teams wanting one pane of glass; that fits low-latency single-region or edge topologies, not region-failure isolation.

Run active-active in all regions with synchronous data replication

Why it fails: Synchronous replication across regions forces every write to wait on inter-region round trips, so a failed region stalls writes or breaks quorum, and complexity rises sharply. It suits low-latency metro pairs needing zero data loss, not geographically dispersed region-failure tolerance.

Implement manual failover procedures documented in runbooks

Why it fails: Runbooks leave recovery dependent on human detection and execution, so availability during a full region failure is bounded by response time, not automation. Manual failover fits rare, planned migrations or tightly regulated changes where automated cutover is unacceptable.

The image 'myapp:v2' does not exist.

Why it fails: A missing image tag yields ErrImagePull/ImagePullBackOff before any container starts, which matches the exhibit's pull-stage backoff rather than a running container. It is tempting because image errors are the classic BackOff cause, but the stem states the container starts, so the failure occurs after startup.

The container exceeds its memory limit.

Why it fails: Exceeding the memory limit triggers OOMKilled and exit code 137, restarting a container that had started, not the pull-stage backoff shown. It is tempting because memory exhaustion is a common restart cause, but the exhibit's events point to image retrieval failing before the container ever runs.

The liveness probe is failing.

Why it fails: A failing liveness probe restarts a running container, producing 'Unhealthy' and restart counts, not 'BackOff' on image pulls. It is tempting because probe failures do cause CrashLoopBackOff, but that requires the container to have started successfully first; the exhibit shows pull-stage backoff.

All pods are immediately terminated

Why it fails: Pods are not terminated when the control-plane is unreachable; kubelet on the worker keeps existing containers running from its cached pod specs, so workloads persist. This option confuses control-plane loss with node failure. It would be correct if the worker node itself went offline, since the pods there would then stop.

Pods are rescheduled to the control-plane node

Why it fails: Pods cannot be rescheduled without a functioning control plane: the scheduler, controller manager and API server all run there, so no new bindings occur. It would apply only after the control plane recovers and the node is marked NotReady.

The worker node is automatically cordoned

Why it fails: Cordoning requires interaction with the control plane.

Single monolithic codebase

Why it fails: Monolithic is the opposite of microservices.

Shared database schema across services

Why it fails: Microservices often use separate databases per service.

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

Why it fails: ConfigMaps store non-confidential configuration in plaintext, so an API key placed there is readable by anyone with get access. ConfigMaps suit ordinary settings such as feature flags or log levels; credentials require a Secret, which supports base64 encoding and RBAC restriction.

Embed the API key directly in the container image.

Why it fails: Baking the key into the image exposes it to every registry reader and forces a rebuild to rotate it, and it cannot be mounted as an environment variable from the cluster. Image embedding suits static build-time constants, not credentials that must be rotated independently.

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

Why it fails: Annotations hold non-sensitive metadata for tooling and are not mounted into containers, so the key never reaches the environment variable. Annotations suit documenting ownership or build information; secrets belong in a Secret object consumed via envFrom or valueFrom.

Mean Time to Restore (MTTR)

Why it fails: MTTR measures how long recovery takes after an incident, expressed in time, not the proportion of deployments that fail. It would be correct if the question asked how quickly service is restored following a failed release, rather than the failure rate itself.

Deployment Frequency

Why it fails: Deployment Frequency counts how often releases reach production, a throughput measure. It would be correct for a question about release cadence, but it says nothing about the proportion of those deployments that subsequently fail in production.

Lead Time for Changes

Why it fails: Lead Time for Changes measures elapsed time from code commit to production deployment, a duration metric. It answers how long delivery takes, not what percentage of releases fail, so it would fit a question about delivery speed rather than deployment failure rate.

The container image is not found in the registry

Why it fails: Image-pull failures surface as ErrImagePull or ImagePullBackOff events, not Pending, so a missing registry image cannot explain the taints shown. It is tempting because image-not-found genuinely blocks pod startup, and would be the answer if describe reported a pull error rather than node taints.

The pod has a resource request that exceeds available capacity on all nodes

Why it fails: The taints shown are node conditions, not capacity shortfalls: disk-pressure and memory-pressure are applied by the kubelet when a node's own disk or memory thresholds are breached, so the scheduler refuses placement regardless of the pod's requests. It tempts because insufficient allocatable CPU or memory genuinely leaves pods Pending, but that event reads "Insufficient cpu/memory" instead.

The pod's liveness probe is failing

Why it fails: A failing liveness probe restarts a running container; it cannot produce a Pending pod, since scheduling occurs before any probe executes. The event names node taints — disk-pressure and memory-pressure — as the binding constraint. Liveness probes are tempting when diagnosing CrashLoopBackOff, where repeated restarts stem from failed health checks.

Tight coupling between services to ensure performance

Why it fails: Tight coupling contradicts the independent deployability and scaling that orchestration platforms like Kubernetes provide; each microservice must be separately releasable and scalable. It is tempting because coupling services can reduce network latency in monolithic or performance-critical designs, where shared in-process calls genuinely outperform inter-service communication.

Monolithic codebase with centralized deployment

Why it fails: A monolithic codebase with centralised deployment contradicts the independent, per-service deployability that container orchestration exists to support; orchestrators schedule discrete containers, not one coupled artefact. It is tempting because centralised deployment genuinely suits single-unit applications, where one build-and-release pipeline is the intended model rather than a limitation.

Use of a single, shared database for all services

Why it fails: A shared database couples services through a common schema, so independent deployment and scaling break. It is tempting because it simplifies transactions and reporting; it would suit a monolith, not the decentralised data ownership container orchestration supports.

The pod is running on a different node

Why it fails: kubectl exec works across nodes; the location does not prevent connection.

The container image does not have /bin/sh

Why it fails: Missing shell would give a different error, typically 'executable file not found'.

The container name is misspelled

Why it fails: If the container name is wrong, the error would mention 'container not found' but the user says the container is named 'app'.

The 'replicas' field is set to 0

Why it fails: The 'replicas' field is set to 3, not 0, so option B is incorrect.

The 'containers' field is misspelled as 'container'

Why it fails: The 'containers' field is spelled correctly, so option C is incorrect.

The 'apiVersion' should be 'v1'

Why it fails: The 'apiVersion: apps/v1' is correct for Deployment, so option D is incorrect.

The rollout will terminate all old pods at once and then create new ones

Why it fails: maxUnavailable: 0 forbids dropping below the desired ready replica count, so old pods cannot all be terminated before replacements exist. It is tempting because Recreate strategy does exactly that, but this Deployment specifies rollingUpdate, which preserves availability throughout the rollout.

The rollout will create all new pods first, then delete all old pods

Why it fails: maxSurge: 1 caps extra pods at one above desired count, so Kubernetes adds one new pod at a time rather than all new pods before deleting old ones. It is tempting because a full surge rollout does create replacements ahead of termination, but that requires maxSurge set to the full replica count.

The rollout will terminate one old pod before creating a new one

Why it fails: maxUnavailable: 0 prevents terminating any old pod before its replacement is ready, so capacity never dips. It is tempting because terminating one old pod then creating a new one describes a surge-free rolling update, which requires maxUnavailable of at least one and maxSurge of zero.

Bulkhead pattern

Why it fails: Bulkhead isolates failures by partitioning resources such as thread pools per dependency, so one saturated pool cannot exhaust others; it does not decouple callers from the database or buffer bursts. Bulkhead suits limiting blast radius across independent downstream services.

Circuit Breaker pattern

Why it fails: Circuit Breaker stops calls after a failure threshold, preventing repeated attempts, but it does not decouple the microservice from direct database connections or absorb traffic bursts. Circuit Breaker suits halting calls to a failing dependency to allow recovery.

Retry pattern

Why it fails: The retry pattern re-issues failed requests, so it cannot decouple the service from database connections or absorb bursts; repeated attempts would worsen pool exhaustion during spikes. It is tempting because retries genuinely help with transient, intermittent faults such as brief network blips or momentary timeouts, where a single repeated call succeeds.

Deployment

Why it fails: A Deployment maintains a desired count of long-running pods, restarting them indefinitely, so it never terminates after the queue empties. It is tempting because it manages replicated pods, and would be correct for a continuously available stateless service such as a web API.

CronJob

Why it fails: A CronJob creates Jobs on a time schedule, not on demand when a queue needs draining, so it would wait for its next cron tick. It is tempting because it does manage finite, terminating pods, and would be correct for recurring scheduled batch work.

DaemonSet

Why it fails: A DaemonSet runs one pod on every node continuously, so it never terminates after finishing a queue. It is tempting because it suits cluster-wide background agents such as log shippers or node monitors, where a persistent pod per node is genuinely required.

maxSurge: 0, maxUnavailable: 2

Why it fails: Setting maxSurge to 0 forbids any extra pods, so the rollout cannot create the 2 additional replicas the scenario demands; maxUnavailable: 2 also permits two pods down at once, violating the single-unavailable limit. It would suit a resource-constrained cluster where spare capacity is unavailable and brief downtime is acceptable.