Hard Difficulty Questions

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.

The policy does not have a namespaceSelector

Why wrong: The absence of a namespaceSelector is not the cause of the connectivity issue. A NetworkPolicy applies to the namespace in which it is created, and an empty podSelector (`podSelector: {}`) selects all pods in that namespace, so a namespaceSelector is unnecessary to make the policy effective. The policy already matches every pod in its own namespace, so DNS traffic is indeed affected by the egress rules.

The policy blocks all ingress traffic only

Why wrong: The policy does not only block ingress; it also blocks egress because the `egress` field is present but empty. In Kubernetes NetworkPolicy, an empty `egress` list results in a default-deny for all outbound traffic, and an empty `ingress` list similarly denies inbound traffic. Therefore, the pod cannot send DNS queries or any other outbound packets, which explains the DNS failure more directly than simply saying ingress is blocked.

The kube-dns service is not running

Why wrong: The kube-dns service is almost certainly running; the real cause is the NetworkPolicy blocking the pod's egress to port 53. If kube-dns were down, pods that are not subject to any policy would also experience DNS failures, but here the issue is isolated to the namespace or pods affected by the policy. Since the policy explicitly denies all egress, the DNS request never reaches the kube-dns service, so the service's availability is irrelevant to this failure.

helm template myrelease repo/chart --set key=value --namespace ns

Why wrong: helm template myrelease repo/chart --set key=value --namespace ns renders the chart's templates locally to stdout as YAML, but it never contacts the Kubernetes API server. It is a client-side dry-run tool used for review, CI/CD validation, or generating manifests for tools like kustomize. Because it does not create a release or apply any resources, it is not a command that installs a chart.

helm create myrelease repo/chart --set key=value --namespace ns

Why wrong: helm create myrelease repo/chart --set key=value --namespace ns scaffolds a new chart directory named 'myrelease' from scratch; it does not fetch anything from a repository. The 'repo/chart' argument is inappropriate because helm create takes a local path/name, not a repository reference, and the subcommand does not recognize the provided flags. It is a chart-authoring tool that generates a skeleton structure (Chart.yaml, values.yaml, templates/), not a deployment or installation mechanism.

helm upgrade --install --set key=value myrelease repo/chart --namespace ns

Why wrong: helm upgrade --install myrelease repo/chart --set key=value --namespace ns performs an 'install or upgrade' operation: if a release named 'myrelease' already exists, it upgrades it, and only if it does not exist does it behave like an install. This idempotent approach is common in CI/CD pipelines, but it is not the primary command for a first-time installation of a chart from a repository. The straightforward command is helm install; upgrade --install additionally expects to manage an existing release history and may trigger upgrade-specific hooks. Therefore it is not the best answer to the question.

2

Why wrong: Choosing 2 available incorrectly assumes that half the replicas can be temporarily down. A maxUnavailable of 25% permits only one unavailable Pod (since 25% of 4 rounds up to 1). With 2 unavailable, you'd be at 50%, violating the Deployment's availability guarantee and potentially causing a service disruption.

4

Why wrong: Selecting 4 assumes no Pod ever goes down during the update. While the desired end state is 4 available, the rolling update process intentionally cycles one Pod at a time; during that cycle a replacement may not be ready immediately. The standard guarantees only 3 available at any instant, and 4 is the upper bound, not the minimum.

1

Why wrong: Having just 1 available means 3 Pods are unavailable, which is 75% of the Deployment. This wildly exceeds the 25% maxUnavailable threshold (rounded up to 1). Even during a rollout, a healthy Deployment never drops below 3 available replicas, so 1 is far too low.

Add the diagnostic tool as a sidecar container in the same Pod

Why wrong: Adding the diagnostic tool as a sidecar container makes it start concurrently with the main app container, not ahead of it, because all regular containers in a Pod are scheduled and started in parallel. A sidecar is also a long-running process expected to stay alive, whereas a diagnostic check is a one-shot action that should terminate when finished. Therefore, a sidecar does not enforce the required before-start ordering.

Add the diagnostic tool as a sidecar container with a postStart hook

Why wrong: A postStart hook is executed after the container's main process starts, so it cannot push a diagnostic before the app container begins; the hook semantics are the wrong ordering direction. Moreover, the sidecar container itself starts at the same time as the app container, and its postStart hook fires only after that sidecar is already running. This approach is doubly incorrect because both the sidecar concurrency and the hook timing violate the required sequence.

Create a separate Job that runs before the Pod

Why wrong: A Job is a separate Pod-level resource, and creating it before the main Pod does not create any dependency or ordering guarantee between them. Without an explicit controller or external wait, the main Pod can start before or even while the Job is still running. The diagnostic tool would also not share volumes or lifecycle with the app container, whereas an init container is the native mechanism that makes the app container's start conditional on completion.

The pod will be evicted from the node

Why wrong: Eviction is triggered by kubelet when the node experiences conditions like memory pressure, disk pressure, or when the pod exceeds its resource limits, not by readiness probe outcomes. A readiness probe only controls whether the pod is included in Service endpoints; it has no effect on pod scheduling or lifecycle. Therefore, a failing tcpSocket readiness probe will never cause the pod to be evicted.

The pod will be marked not ready because the application returns errors

Why wrong: The tcpSocket probe cannot see application responses because it only checks whether the TCP handshake completes; it never receives an HTTP status, error message, or any payload. If the application returns errors over a connection that is still valid at the transport layer, the probe still passes. Thus a pod will not be marked not ready due to application-level errors when using a tcpSocket probe.

The container will be restarted due to readiness probe failure

Why wrong: Container restarts are governed by liveness probes, not readiness probes; a liveness probe failure causes the kubelet to kill and restart the container. A readiness probe failure merely sets the pod's Ready condition to false and removes it from Service endpoints, while the container continues running. Since the given probe is for readiness, a failed tcpSocket check will not trigger a restart.

The pod's memory limit is too low

Why wrong: A low memory limit causes the container to be killed by the OOM killer once it exceeds the limit, producing an OOMKilled or CrashLoopBackOff state, not a Pending pod. For a pod to remain Pending, the Kubernetes scheduler must fail to place it, and the event 'Insufficient memory' would appear—not 'Insufficient cpu'. Since the message specifically mentions CPU, memory limits are irrelevant to this scheduling failure.

The container image is not found in the registry

Why wrong: When a container image is missing or has invalid tags, the kubelet on an already scheduled node reports ImagePullBackOff or ErrImagePull. However, the pod in this scenario is still Pending, meaning it has not yet been assigned to any node by the scheduler. Image resolution happens after scheduling, so a missing image cannot generate the scheduling-related event 'Insufficient cpu'.

The node is under disk pressure

Why wrong: Disk pressure on a node is detected by kubelet and reported as a node condition such as NodeDiskPressure, which makes the node unschedulable or triggers eviction. The scheduler would mention disk pressure explicitly in events (e.g., 'node(s) had pressure') rather than 'Insufficient cpu'. Moreover, disk pressure does not affect the CPU fit calculation; the event text is a direct failure from the resource FitError predicate, so this option misrepresents the actual cause.

The Service `svc-a` does not have any endpoints

Why wrong: DNS lookup for a Service is based on the Service object itself, not on the backing EndpointSlice objects. Even if a Service has no matching pods (no endpoints), CoreDNS still returns a DNS record for the Service because the Service definition exists and carries a ClusterIP (for non-headless Services). Missing endpoints only cause connection failures after DNS resolution, since the name resolves to an IP that drops or rejects traffic. Thus the absence of endpoints does not prevent the name from resolving.

The Pod cannot resolve names from other namespaces

Why wrong: Kubernetes DNS uses the fully qualified domain name schema <service>.<namespace>.svc.<cluster-domain>, so a pod in any namespace can resolve a Service in another namespace simply by including that namespace in the query. There is no built-in namespace isolation for DNS lookups; network policies may block traffic between namespaces, but they do not affect the DNS resolution itself. The statement that the pod cannot resolve names from other namespaces is therefore incorrect, because cross-namespace resolution is a standard and expected capability.

The Service type is NodePort

Why wrong: The Service type (ClusterIP, NodePort, LoadBalancer) determines how the Service is exposed externally, not how it is discovered internally. For every type except headless, an A record is created for the Service in the cluster DNS, and that record points to the Service's ClusterIP (or to pod IPs for headless Services). Changing the type to NodePort does not remove or alter the DNS entry; the name still resolves normally. Consequently, the Service type being NodePort is an irrelevant detail for a DNS resolution failure.

No, because the ServiceAccount has automountServiceAccountToken: false, which is a hard block.

Why wrong: Setting automountServiceAccountToken: false on a ServiceAccount is not an immutable or mandatory block. It is a default value that applies only when the pod does not explicitly specify this field. Kubernetes documentation and API behavior show that the pod-level field takes precedence, so the ServiceAccount's false setting is effectively a soft default, not a hard prohibition. A pod can deliberately opt in to mount the token regardless of the ServiceAccount configuration.

It depends on the namespace default settings.

Why wrong: Namespace-level settings do not introduce any layer that overrides explicit pod or ServiceAccount configurations. There is no field like defaultAutomountServiceAccountToken on a Namespace object, and Kubernetes admission controllers do not inject such a default based on namespace. The only defaults that matter are the ServiceAccount's own field and the pod's explicit field. Thus, the outcome depends solely on those two values, with the pod taking precedence, not on the namespace.

No, because the ServiceAccount setting overrides the pod setting.

Why wrong: This claim reverses the actual precedence order in the Kubernetes API. The pod spec's automountServiceAccountToken is the higher-priority field; the ServiceAccount's setting acts merely as a fallback when the pod field is absent. When both are defined, the pod value wins, so the ServiceAccount cannot override the pod. For example, if the pod sets automountServiceAccountToken: true and the ServiceAccount sets false, the token is still mounted because the pod spec is authoritative.

--container

Why wrong: The --container flag is an option for kubectl exec, used to select which container in a multi-container Pod receives the command; it does not influence how an ephemeral container is wired to existing kernel namespaces. In kubectl debug, --target occupies a similar role but is not an alias: --target shares PID, network, IPC, and UTS namespaces from the chosen container, whereas --container in exec merely scopes where a single command runs. Passing --container to kubectl debug would not establish the required namespace-sharing link and would be interpreted differently or rejected.

--namespace

Why wrong: The --namespace flag is a global kubectl option that sets the Kubernetes namespace—the cluster-scoping API object—used to locate the target Pod, not a Linux process namespace. On Linux, process/PID namespaces are kernel-level isolation mechanisms that can be shared between containers using kubernetes-level flags such as --target or the Pod spec's shareProcessNamespace field. Confusing the Kubernetes 'namespace' concept with the kernel 'namespace' term is a common pitfall, but --namespace only affects API discovery and never changes how the ephemeral container's processes are isolated.

--share-process-namespace

Why wrong: The --share-process-namespace flag is actually a field in the Pod specification (spec.shareProcessNamespace) that statically enables a single PID namespace for all containers created within that Pod. It is not a valid kubectl debug command-line flag, and setting it in the Pod spec does not automatically grant an ephemeral container access to existing containers' namespaces; the ephemeral container must still specify --target to join the namespace of a particular existing container. So even though the flag name sounds relevant, it is the wrong interface for dynamically debugging a running Pod.

The ServiceAccount can read secrets in all namespaces

Why wrong: This is incorrect because a ClusterRole by itself does not grant permissions anywhere; it only becomes effective when bound. A ClusterRoleBinding would grant the permissions across all namespaces, but here the ClusterRole is bound with a RoleBinding, which is always namespace-scoped. Since the RoleBinding exists in the 'app' namespace, the ServiceAccount's read access to secrets is confined to that namespace only.

The RoleBinding is invalid because ClusterRole cannot be used with RoleBinding

Why wrong: This is a common misunderstanding. Kubernetes explicitly permits a RoleBinding to reference a ClusterRole; the binding is valid as long as the referenced role exists. When used this way, the ClusterRole's rules are copied into the RoleBinding's scope, meaning the permissions apply only to resources within the RoleBinding's own namespace. This pattern is often used to reuse broadly defined roles like 'view' without granting cluster-wide access.

The ServiceAccount can read secrets only in the default namespace

Why wrong: This is incorrect because the namespace that matters is the RoleBinding's metadata.namespace, not any implicit 'default' namespace or the ServiceAccount's own namespace. The RoleBinding in question is explicitly created in the 'app' namespace, so its permissions apply to resources in 'app'. The ServiceAccount would need a separate RoleBinding (or a ClusterRoleBinding) to gain secret access in the 'default' namespace.

9

Why wrong: The value 9 is likely derived by adding parallelism (3) and completions (6), but no Kubernetes Job field represents that sum. The Job controller treats parallelism and completions independently: parallelism caps concurrent Pods, while completions defines the total target for successful completions. Therefore, 9 is not a meaningful concurrency or completion count for this Job.

6

Why wrong: The value 6 corresponds to the 'completions' field, which specifies the desired number of successful Pod completions the Job must achieve overall. It is not a concurrency limit; the maximum simultaneous Pods is governed by 'parallelism'. Due to retries or replacements, the actual total number of Pods created may exceed 6, but the Job completes only after 6 distinct successful Pods finish.

1

Why wrong: While Kubernetes does default 'parallelism' to 1 when the field is absent, this Job explicitly sets parallelism to 3. That explicit setting overrides the default, so the controller allows up to three Pods to run at once. Choosing 1 would ignore the spec and misrepresent the concurrency behavior, especially since completions is 6 and parallelism directly controls how many Pods can progress in parallel.

A single Service with multiple selectors

Why wrong: A single Service uses a label selector to create a flat pool of Pods, and it load-balances to every Pod in that pool with equal weight. Adding multiple selector terms only filters or expands the set of matched Pods; it cannot assign a 10% weight to one subset. Therefore, if stable and canary Pods both match, they receive roughly equal traffic, not a controlled 10% canary share.

NetworkPolicy

Why wrong: NetworkPolicy is an imperative firewall that governs which Pods can communicate with one another based on labels, namespaces, and ports. It can block or allow connections, but it has no notion of request routing or weighted distribution, so it cannot forward only a fraction of traffic to a canary. Since its verdict is binary allow/deny, it is fundamentally unsuited for percentage-based canary traffic.

HorizontalPodAutoscaler

Why wrong: HorizontalPodAutoscaler monitors metrics like CPU utilization or request latency and automatically adjusts the replica count of a Deployment. It only affects how many instances of the same Pod are running; it does not distinguish between versions or route traffic proportionally. Even if it scales the canary to one out of ten replicas, the Service still round-robins across all Pods, so you cannot guarantee an exact 10% split.

kubectl create secret generic my-tls --from-file=cert.pem --from-file=key.pem

Why wrong: This creates a generic secret, not a tls secret. The tls secret type expects cert and key to be stored under specific keys.

kubectl create secret tls my-tls --certificate=cert.pem --private-key=key.pem

Why wrong: The flags are --cert and --key, not --certificate and --private-key.

kubectl create secret tls my-tls --from-file=tls.crt=cert.pem --from-file=tls.key=key.pem

Why wrong: The correct flags are --cert and --key, not --from-file.

The kube-dns service is responsible for DNS resolution

Why wrong: The kube-dns service is not the component that performs DNS resolution; it is a ClusterIP service that points to the CoreDNS pods. CoreDNS is the actual DNS server that handles queries, while the kube-dns service exists for backward compatibility so that applications can resolve cluster-internal names. Saying the service itself is responsible conflates a stable network endpoint with the workload that implements the DNS feature.

Pods with hostNetwork: true automatically get DNS entries

Why wrong: Pods that run with `hostNetwork: true` share the node's network namespace and therefore do not receive a unique pod IP from the cluster CIDR. Because Kubernetes DNS does not have a pod IP to format into an A record, it does not automatically create a DNS entry for these pods. They can still use DNS as clients, but they are not discoverable via a pod-specific DNS name unless you manually assign a `hostname` and `subdomain` and attach them to a headless service.

A pod's DNS name is always 'pod-ip.namespace.pod.cluster.local'

Why wrong: Pod DNS records use the pod IP with dots replaced by dashes, for example `10-0-0-1.default.pod.cluster.local`, so the literal string `pod-ip` is never part of the name. These records are only created when the pod has a specified `hostname` and `subdomain` and belongs to a non-headless service; many pods do not have an A record at all. Therefore the statement's claim that the DNS name is 'always' this format is false, as most pods rely on service DNS names rather than their own.

Jobs will never overlap because the schedule is too frequent

Why wrong: This option is incorrect because a schedule interval shorter than the job's runtime does not prevent overlap; it actually guarantees overlap attempts. The CronJob controller triggers a new Job every 5 minutes regardless of whether the previous Job has completed. Since Replace policy is configured, the controller will forcibly terminate the prior Job at that point, so overlap is actively resolved, not avoided by the frequency itself.

The job will be skipped if the previous one hasn't finished

Why wrong: This behavior belongs to concurrencyPolicy: Forbid, not Replace. With Forbid, the controller skips the newly scheduled run if the previous Job is still running, leaving the old Job untouched. Replace, by contrast, never skips a schedule; it instead cancels and replaces the running Job so the new run proceeds immediately.

Jobs will overlap, with up to two jobs running concurrently

Why wrong: This is false because Replace is designed to eliminate overlap entirely, not limit it to two. The controller terminates the currently running Job before creating the next one, so at most one Job exists at a time. Allowing up to two concurrent Jobs would be the result of concurrencyPolicy: Allow, but even that policy does not impose a fixed maximum — it permits unbounded concurrency, not a cap of two.

Create a new pod with a higher memory limit and delete the old pods manually.

Why wrong: Manually creating a separate pod and deleting Deployment pods fights the controller: the Deployment's ReplicaSet immediately recreates deleted pods to match its current template, so the manual replacement is cosmetic and short-lived. A standalone pod is outside the Deployment's management, meaning it receives no rolling updates, self-healing, or replica reconciliation. This approach causes unnecessary downtime and does not persist the increased memory limit in the desired state.

Set the memory limit to unlimited by removing the limit section and restart the pod.

Why wrong: Removing the memory limit entirely removes the safety boundary that prevents a single container from exhausting node memory; the kubelet or OOM killer may then terminate the container or evict neighboring pods when the workload spikes. Restarting the pod manually only applies to that ephemeral instance—the Deployment controller will enforce the original spec on the next reconciliation, so the change is lost. Unbounded pods are a cluster-risk anti-pattern, not a fix for memory pressure.

Use 'kubectl set resources' to increase the limit on the running pod dynamically.

Why wrong: 'kubectl set resources' is a subcommand for mutating workload controllers such as Deployments, StatefulSets, or ReplicaSets—it cannot mutate an individual Pod because a Pod's resource requests and limits are immutable after creation. Running it against a Pod either fails or changes the controller's template, which then triggers a rollout of new pods, not a dynamic in-place adjustment. The running pod keeps its old limit until it is terminated and replaced, so the phrase 'increase the limit on the running pod dynamically' is technically false.

Skip

Why wrong: Skip is not a valid concurrencyPolicy value in the Kubernetes CronJob specification. The only accepted values for the spec.concurrencyPolicy field are "Allow", "Forbid", and "Replace". If you attempt to use "Skip", the CronJob will be rejected by the API server with a validation error, so this option is incorrect.

Allow

Why wrong: Allow is the default concurrencyPolicy, but it would not solve the problem of overlapping runs. With Allow, the CronJob controller launches a new Job on every scheduled time, even if a previously started Job from the same CronJob is still running. This can lead to concurrent executions, which may cause race conditions, resource exhaustion, or inconsistent results for workloads that require strict ordering.

Replace

Why wrong: Replace would cancel the currently running Job and start a new one at the next scheduled time. While this prevents overlapping active Jobs, it forcibly terminates the existing Job by deleting its Pods, which can leave incomplete work, orphaned side effects, or corrupted state if the job is not designed to handle abrupt termination. Therefore it is not the safest choice for a job that must run every 5 minutes without overlap.

The pod will be terminated and not restarted

Why wrong: A failing liveness probe does not terminate the entire pod; the kubelet kills the individual container and then consults the pod's restartPolicy. Since restartPolicy defaults to Always when omitted, the container is immediately scheduled for another start rather than leaving the pod terminated. Pod termination would require a node-level failure, eviction, or a restartPolicy of Never combined with container exit, none of which apply here.

The pod will start and run normally

Why wrong: The pod will not operate normally because the liveness probe targets TCP port 8080, which has no listener inside the container, so every probe attempt times out or returns a non-success response. Kubelet treats repeated failures as an unhealthy container and restarts it, producing a CrashLoopBackOff instead of a steady Running state. A normally running pod must have its liveness probe succeed (e.g., HTTP 200 or a successful TCP connection) once the process starts.

The pod will be stuck in 'Pending' state

Why wrong: A Pod enters Pending only before any containers are created, typically due to unschedulable resources, taints, or image pull problems. The liveness probe is executed by the kubelet only after the container has been successfully created and started, so a failing probe cannot affect the Pending phase. Even if the probe fails immediately, the pod first moves to Running and then shows restarts, never reverting to Pending.

images: - name: my-app newName: v2

Why wrong: The `images` key in Kustomize accepts `newName` to replace the image repository/name, not the tag. Setting `newName: v2` changes the image name to literally 'v2', leaving the tag unchanged or defaulting it, so the deployment will not run the v2 tag. To set a tag, use `newTag` instead.

patches: - target: kind: Deployment patch: |- - op: replace path: /spec/template/spec/containers/0/image value: my-app:v2

Why wrong: Although a JSON Patch via `patches` can replace the image string, it is not the correct idiomatic Kustomize configuration for this simple tag update. This patch hard-codes the full image reference and the container index, making it brittle if the container order or name changes, and it bypasses Kustomize's structured `images` transformer which can apply globally and handle digest and tag updates consistently. The question asks for a correct kustomization configuration, and the `images` field is the standard, less error-prone approach.

imageTag: - name: my-app tag: v2

Why wrong: Kustomize does not define an `imageTag` directive; the key is `images` (a list) with `newTag` for tag overrides. Using `imageTag` will cause kustomize to error out or ignore the entry because it is not a recognized field, so this is not a valid kustomization. The correct structure is `images: - name: my-app newTag: v2`.