Application Observability and Maintenance practice questions

Set the log level to ERROR only to reduce verbosity and avoid logging sensitive data.

Why it fails: Setting the log level to ERROR only reduces verbosity but does not guarantee that sensitive data is omitted, as error messages often contain contextual details like passwords or tokens. Moreover, this approach degrades observability by suppressing WARN, INFO, and DEBUG messages, making it harder to diagnose issues. It also fails to address sensitive data already being logged at ERROR level, so it is neither a complete nor a reliable solution.

Add a sidecar container that reads the application's log file, redacts sensitive data, and writes to stdout.

Why it fails: The sidecar pattern is the correct approach: add a container that shares a volume with the application container, reads the log file, applies regex-based redaction (e.g., masking password fields), and writes the sanitized output to stdout. This ensures only redacted logs are captured by the cluster-wide logging pipeline, while the application's original logging behavior remains unchanged. This pattern is commonly used in Kubernetes for log transformation and filtering without modifying application code, and it provides immediate mitigation for active pods.

Configure a LogCollector DaemonSet to filter logs at the node level.

Why it fails: Configuring a LogCollector DaemonSet to filter logs at the node level is impractical because DaemonSets like Fluentd or Filebeat typically collect raw logs from all containers and forwarded them as-is; node-level filtering would require intercepting streams per container before aggregation, which adds significant complexity and overhead. Additionally, redaction logic often depends on application-specific log formats, which the node-level collector cannot reliably interpret. This approach also fails to prevent sensitive data from being written to the node's local logs or transmitted before filtering, leaving exposure windows.

TCP socket probe

Why it fails: This is a type of probe handler, not a probe type.

HTTP GET probe

Why it fails: This is a type of probe handler, not a probe type.

Liveness probe

Why it fails: Restarts unhealthy pods but does not affect traffic routing.

kubectl logs pod-name --all-containers

Why it fails: The `--all-containers` flag instructs kubectl to aggregate and stream logs from every container in the pod, combining their stdout/stderr into one output. This is the opposite of what you need, because the task asks for logs from a single, specific container. Furthermore, `--all-containers` is mutually exclusive with `-c`/`--container`, so you cannot combine it with a container selector to narrow the output.

kubectl logs pod-name --container container-name

Why it fails: This command is an exact duplicate of the earlier `--container` option, so while the syntax is technically valid and would run correctly in a shell, it is not a separate correct answer in a single-choice question. In an exam context, duplicated options are traps that test your ability to recognize the canonical form; crediting a duplicate would be logically impossible. Thus it is incorrect due to redundancy, not due to any problem with the kubectl command itself.

kubectl logs pod-name

Why it fails: Running `kubectl logs pod-name` with no container flag does not isolate any container; for a multi-container pod, kubectl will not arbitrarily pick one and will instead return an error instructing you to specify a container or to use `--all-containers`. This command fails to deliver the specific container's logs, so it cannot be used to complete the task. Only adding `-c container-name` or `--container container-name` would make it work correctly.

Create an Ingress with the metrics path

Why it fails: Ingress routes traffic, not for scraping.

Add annotations 'prometheus.io/scrape: "true"' to the Deployment

Why it fails: Deployment is not scraped; pods are.

Store metrics in a ConfigMap and mount it to Prometheus

Why it fails: ConfigMap is static config, not live metrics.

kubectl logs <pod> --all-containers

Why it fails: The `--all-containers` flag is valid for fetching logs from every current container in the pod, but it does not access the terminated container's logs. If a container has crashed and been replaced, this command only shows the new instance's logs, so it fails to meet the typical goal of inspecting the previous instance's output. To view prior logs, you must combine `--all-containers` with `--previous` or use `-p` instead.

kubectl logs --all

Why it fails: The command `kubectl logs --all` is invalid because the `kubectl logs` subcommand does not support an `--all` flag. The kubectl CLI will return an error indicating that the flag does not exist. For retrieving logs from multiple containers, the correct flag is `--all-containers`, not `--all`, which is used for other operations like `kubectl get all`.

Write metrics to stdout and parse them with a log aggregator.

Why it fails: Writing metrics to stdout and parsing them with a log aggregator conflates the observability pillars. Log agents like Fluentd or Filebeat are optimized for collecting, filtering, and shipping log lines, not for turning them into time-series metrics with labels and histograms. While a log aggregator could theoretically parse a log line and emit a metric, that pipeline lacks the standard scrape semantics, cardinality controls, and query integration that Prometheus and the Kubernetes Metrics APIs expect. It is not a valid way to expose metrics to monitoring systems.

Use kubectl top to collect metrics and expose them via a Service.

Why it fails: kubectl top is a client-side utility that retrieves current CPU and memory usage from the metrics-server (resource metrics API) and prints it to the terminal. It does not create a server-side endpoint; the output is ephemeral and not scrapeable. The only way to 'expose' it via a Service would be to proxy the Kubernetes API, which is neither application-specific nor Prometheus-suitable. Resource usage of pods is not the same as application metrics exposed by a /metrics endpoint.

Create a ServiceMonitor custom resource to push metrics to Prometheus.

Why it fails: A ServiceMonitor is a Prometheus Operator CRD used to declaratively define which Kubernetes Services should be scraped and with what labels. It merely generates Prometheus scrape configs; it does not cause an application to emit, push, or expose any metrics. Without an existing HTTP metrics endpoint on the target Service, creating a ServiceMonitor has no effect. The direction is pull: Prometheus scrapes the target defined by the ServiceMonitor, not push from the CRD.

ConfigMap

Why it fails: ConfigMaps are API objects designed to hold non-sensitive configuration data such as key-value pairs, environment variables, or small config files. They are mounted into pods and consumed by containers at runtime. They do not capture or expose operational events like pod crashes or restarts; they are purely declarative configuration inputs.

Secret

Why it fails: Secrets are API objects intended to store sensitive data, such as credentials, tokens, or keys, and they are base64 encoded but not encrypted at rest by default. They are used to inject confidential information into pods. Secrets have no relation to runtime events; they do not track or record system occurrences like pod lifecycle changes.

CronJob

Why it fails: CronJobs are workload resources that schedule the creation of Jobs on a repeating schedule using a cron expression. They are used for recurring tasks such as backups, reports, or cleanup scripts. CronJobs do not provide real-time monitoring of events; they run batch jobs at fixed times, not in response to pod crashes, and they do not emit event streams about cluster incidents.

imagePullPolicy: Defines the policy for restarting the container after exit.

Why it fails: Incorrect — this describes restartPolicy, not imagePullPolicy.

restartPolicy: Defines when to pull the container image.

Why it fails: Incorrect — this describes imagePullPolicy, not restartPolicy.

Service: apps/v1

Why it fails: Services are in the core v1 API group, not apps/v1.

ConfigMap: networking.k8s.io/v1

Why it fails: ConfigMaps are in the core v1 API group, not networking.k8s.io/v1.

PersistentVolumeClaim: apps/v1

Why it fails: PersistentVolumeClaims are in the core v1 API group, not apps/v1.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace and redeploying all workloads is a destructive and overly broad action. It removes every resource in the production namespace, causing widespread downtime, and the newly deployed pod will still inherit the same memory limit unless the manifest is changed. This does not address the specific OOMKilled event affecting a single pod.

Delete and recreate the pod to clear the crash loop

Why it fails: Deleting and recreating the pod will only restart the container with the same configured resource limits. Since the manifest still sets an insufficient memory limit, the container will quickly exceed it again and be terminated by the kernel, resulting in the same CrashLoopBackOff. This action treats the symptom without correcting the underlying configuration.

Increase the CPU request for the container

Why it fails: Increasing the CPU request for the container does not affect the memory cgroup quota that governs OOM kills. OOMKilled indicates the container's memory usage exceeded resources.limits.memory, not that it lacked CPU shares. Adjusting CPU requests may even alter scheduling but cannot prevent memory exhaustion, so this option is orthogonal to the problem.

kubectl attach pod-name -c sidecar

Why it fails: kubectl attach pod-name -c sidecar attaches your terminal's standard input/output to the running sidecar process, establishing an interactive session rather than reading historical logs. It does not dump previous log lines; it connects to the container's live streams, and it may hang waiting for input or require a TTY, making it completely unsuitable for viewing logs.

kubectl logs pod-name

Why it fails: kubectl logs pod-name omits the container name, which is mandatory for a multi-container pod. When a pod has more than one container and no container is specified, kubectl returns an error asking for a container name (unless --all-containers is used), so this command fails instead of streaming any logs, let alone the sidecar's logs.

kubectl logs pod-name --container sidecar

Why it fails: kubectl logs pod-name --container sidecar is invalid because kubectl logs only recognizes the short -c flag for container selection, not the long --container form in the context tested. The command will be rejected with an unknown-flag error, so it never reaches the API server and therefore cannot display the sidecar logs.

Increase the CPU request for the container

Why it fails: OOMKilled is purely a memory exhaustion condition; the Linux OOM killer operates on memory pages, not CPU time or CPU throttling. Increasing the CPU request only alters the container's scheduling weight and guaranteed CPU share, which does nothing to expand the memory cgroup or prevent the kernel from reclaiming the container's pages. In fact, if the container is memory-bound, a larger CPU share can let it allocate memory faster, potentially making OOM events more frequent rather than fixing them.

Delete and recreate the pod to clear the crash loop

Why it fails: This action treats the symptom rather than the cause: a pod in CrashLoopBackOff will be recreated by its ReplicaSet or Deployment with the exact same resource `limits.memory`, so the new container will hit the identical OOMKilled threshold and crash again. Even a manual `kubectl delete pod` followed by `kubectl apply` of the same manifest reproduces the loop because no specification change was made. Only adjusting the memory limit (or fixing the application's memory leak) breaks the cycle.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the entire `production` namespace is a massive blast-radius action that removes every Service, Deployment, ConfigMap, Secret, and PVC in that environment, not just the problematic pod. Even after recreating all workloads, the pod's YAML still contains the original memory limit, so the container will be OOMKilled identically. Pod-level issues should be remediated with targeted edits such as `kubectl edit` or `kubectl patch` on the specific resource, never by destroying shared infrastructure.

Delete and recreate the pod to clear the crash loop

Why it fails: Deleting and recreating the pod is futile because the pod's resource limits are defined in its manifest, not in the running instance. The replacement pod will inherit the same memory limit, so the container will again consume beyond that bound and receive the same OOMKilled termination. The crash loop persists because the underlying cause — an insufficient memory limit relative to the workload's actual footprint — remains completely unchanged.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace is a sledgehammer approach that removes every Secret, ConfigMap, Service, Deployment, and unrelated workload in that namespace, causing broad, avoidable downtime. It does nothing to alter the memory limit in the pod's spec, so even if the pod is recreated elsewhere, the OOMKilled condition will simply return. Namespace deletion is reserved for cleaning up an entire logical environment, not for fixing a single misconfigured container's resource constraint.

Increase the CPU request for the container

Why it fails: Increasing the CPU request is irrelevant because OOMKilled is a memory-specific failure: the kernel's OOM killer triggers when anonymous memory usage exceeds the cgroup's memory.max limit, independent of CPU allocation. CPU requests only influence scheduler placement and CPU-bandwidth guarantees; they do not enlarge the memory cgroup or reduce the container's memory footprint. A CPU-heavy but memory-light change cannot stave off a memory-limit violation, so the container will continue to be terminated and restarted.

kubectl run -it <pod> --image=busybox -- /bin/sh

Why it fails: Incorrect. `kubectl run` creates a new pod, it does not attach to an existing pod. To run an interactive shell inside a running container, use `kubectl exec`.

kubectl exec -i <pod> -- /bin/bash

Why it fails: Incorrect. The `-i` flag only keeps STDIN open, but without `-t`, a pseudo-TTY is not allocated, which is required for an interactive shell like /bin/bash.

kubectl debug -it <pod> --image=busybox -- /bin/sh

Why it fails: Uses `kubectl debug -it <pod> --image=busybox -- /bin/sh`. This command creates a temporary debug container in the pod, which is appropriate for troubleshooting but not for running an interactive shell in an existing container. Additionally, note that `--container` is a valid flag in `kubectl logs`, not in `kubectl debug`; however, the main issue here is that `kubectl debug` creates a new container rather than attaching to an existing one. Therefore, while this command can be used for debugging, it does not meet the requirement of running an interactive shell inside a running container.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the namespace destroys every workload, service and volume in production, far exceeding the OOMKilled fault. It is tempting as a blunt reset when a namespace is corrupted, but the diagnosis already isolates one container exceeding its memory limit; raising that limit or the request is the targeted fix.

Delete and recreate the pod to clear the crash loop

Why it fails: Recreating the pod restores the same memory limit from its spec, so the container will be OOMKilled again once it reaches that ceiling. It is tempting because deletion clears a transient crash loop, which works for image or config errors, but not for a resource limit the workload genuinely exceeds.

Increase the CPU request for the container

Why it fails: CPU requests govern scheduling and throttling, not the cgroup memory limit that triggers OOMKilled; the container would still be terminated. It is tempting because resource tuning is the right family of fix, and raising CPU helps CPU-starved pods, but memory limits and requests are the axis that matters here.

kubectl run debug --image=busybox -it --rm

Why it fails: This creates a new pod, not debugging the original.

kubectl exec -it <pod> -- /bin/sh

Why it fails: The container crashes before you can exec.

kubectl debug -it <pod> --image=busybox

Why it fails: This adds an ephemeral container, but the original container still crashes; you can't access its filesystem easily.

Increase the CPU request for the container

Why it fails: OOMKilled is explicitly a memory exhaustion event, not a CPU contention issue. Increasing the CPU request only affects scheduling and CPU bandwidth guarantees; it has no influence on the memory cgroup limit that governs when the kernel kills the container. The crash loop will continue with the same OOMKilled status because the memory limit remains unchanged and the process still exceeds it.

Delete and recreate the pod to clear the crash loop

Why it fails: Deleting and recreating the pod without modifying the memory limit will produce an identical pod with the same resource constraints. The new container will start, exhaust its memory again, and be OOMKilled, re-entering CrashLoopBackOff. This action simply resets the restart counter; it does not alter the underlying reason the kernel terminates the process, so the outcome remains unchanged.

Delete the namespace and redeploy all workloads

Why it fails: Deleting the entire namespace is far too broad an action for a single pod's memory issue. It removes all pods, services, ConfigMaps, secrets, and other resources in that namespace, causing downtime for every workload there, not just the crashing pod. The correct remediation is scoped to the individual pod's resource limits, making this option both ineffective and unnecessarily destructive.

kubectl logs sidecar -p app-pod -n dev

Why it fails: This command is malformed because `kubectl logs` expects the pod name as the first positional argument, not the container name. Here `sidecar` is mistakenly placed first, so kubectl treats it as the pod name, and `-p` (which requests logs from a previously terminated container instance) applies to that non-existent pod. The extraneous `app-pod` argument then causes a parsing error or unexpected behavior, and the intended `-c sidecar` flag is entirely absent.

kubectl logs app-pod -n dev

Why it fails: Running `kubectl logs app-pod -n dev` without a `-c` flag is insufficient because the pod contains more than one container (the main container and the sidecar). When a pod has multiple containers, `kubectl logs` cannot infer which container's log stream you want, so it will return an error like 'must specify a container name'. The namespace flag alone does not resolve the ambiguity, making this command invalid for this scenario.

kubectl top nodes node01

Why it fails: This command asks the metrics API for aggregate CPU and memory usage on node01, summing all containers plus system overhead into a single node-level line. It reveals node pressure, not individual pod consumption, so you cannot isolate which workload is using resources from this output. The node-level view is useful for capacity checks, but it does not answer a question that explicitly asks about all pods on the node.

kubectl get pods -o wide --all-namespaces --field-selector spec.nodeName=node01

Why it fails: This is purely an object listing from the Kubernetes API server: it retrieves Pod resources across every namespace and uses the spec.nodeName field selector to match pods bound to node01, displaying networking information such as pod IP and node IP. Nowhere does it consult the metrics API, and standard pod objects contain no live CPU/memory usage data. It correctly identifies the set of pods on the node, but it is silent on their actual resource consumption.

kubectl describe node node01 | grep -A 10 'Non-terminated Pods'

Why it fails: kubectl describe node reads the node object from etcd and prints a status section that includes a static list of non-terminated pods, their containers, and their readiness states; grepping for that header only extracts that pre-rendered table. None of this is derived from metrics-server, and the node status does not include CPU/memory utilization samples for those pods. It is a debugging aid for pod placement and health, not a usage-reporting tool.

kubectl exec -it pod-name -- /bin/sh

Why it fails: `kubectl exec` requires a running container to attach to; it injects a process into the container's PID namespace, which only exists while the container is alive. If the container has already crashed and is restarting, there is no live process to run `/bin/sh`, so the API server rejects the request. Even if the pod is in CrashLoopBackOff, the container itself might be in a `Waiting` or `Terminated` state, meaning the connection cannot be established. This command only works for containers that are currently running, not for exited ones.

kubectl logs pod-name --previous

Why it fails: `kubectl logs --previous` reads the captured stdout/stderr from the terminated container instance, giving you the crash error message or stack trace from the previous execution. However, it is a read-only stream of log lines and provides no access to the container's filesystem, configuration files, or live state. If the crash involves missing directories, permission issues, or volume contents, logs alone cannot show you those details. It is a useful diagnostic starting point, but it cannot replace interactive inspection.

kubectl describe pod pod-name

Why it fails: `kubectl describe pod` displays the pod's metadata, status, and recent events, including restart counts, image pull attempts, liveness probe failures, and scheduling decisions. It explains why the pod crashed or restarted from the perspective of the kubelet and API server, but it never opens a shell or mounts the container's filesystem. It is a read-only, metadata-focused command that helps you reason about causes, not inspect runtime state. To actually see files or run commands, you need an ephemeral container, as `kubectl debug` provides.