Application Observability and Maintenance practice questions

kubectl logs -f web-app

Why wrong: Streams logs, not useful for CPU investigation.

kubectl describe node

Why wrong: Shows node-level resource allocation and conditions, not per-process.

kubectl top pod web-app

Why wrong: Shows overall CPU/memory usage of the pod, not per-process.

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

Why wrong: This does not update the deployment, and manual deletion causes disruption.

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

Why wrong: Removing limits may cause resource exhaustion on the node; restarting the pod causes a brief outage.

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

Why wrong: 'kubectl set resources' updates the deployment, not the running pod directly.

kubectl logs -f my-pod

Why wrong: Streams logs, not suitable for a quick look.

kubectl logs my-pod

Why wrong: Shows all logs, which may be too verbose.

kubectl get events --field-selector involvedObject.name=my-pod

Why wrong: Shows events, not container logs.

The pod 'frontend' is not in the same namespace as the service 'backend'.

Why wrong: If in different namespaces, the service would need to be accessed via fully qualified name, but endpoints could still exist.

The pod's container port is different from the service port.

Why wrong: Service port mapping works if targetPort matches container port; mismatch would not cause empty endpoints.

The kube-proxy is misconfigured and not updating iptables rules.

Why wrong: This would affect connectivity even if endpoints exist.

Check the liveness probe events via 'kubectl describe pod' to see the exact probe responses.

Why wrong: Events show probe results but not the application's internal errors.

Run 'kubectl exec' to curl the endpoint from another pod to test network connectivity.

Why wrong: Tests external connectivity, but probe failure may be due to internal state.

Review the liveness probe parameters in the deployment YAML and increase the failureThreshold.

Why wrong: May mask the issue rather than diagnose root cause.

Increase the CPU limits on the pod to give it more resources.

Why wrong: Increasing limits makes the problem worse; the pod requires more CPU than available.

Add another node to the cluster to increase overall CPU capacity.

Why wrong: Adding nodes could help but is a more drastic and slower solution; reducing request is quicker.

Add a nodeSelector to the pod to target a specific node.

Why wrong: NodeSelector does not solve insufficient CPU on all nodes.

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

Why wrong: This may still log sensitive data in error messages; also, it reduces overall observability.

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

Why wrong: LogCollector DaemonSets typically collect raw logs; filtering at node level is complex and not a standard practice.

Modify the application code to stop logging sensitive data before redeploying.

Why wrong: While ideal, this may take longer; the question asks for a recommendation to address the immediate requirement.

Create an Ingress resource that exposes the /metrics endpoint externally.

Why wrong: Ingress is for external HTTP access, not for Prometheus scraping inside the cluster.

Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

Why wrong: While possible, it is not a Kubernetes-native resource; the annotation approach is simpler.

Add a PrometheusRule resource that defines the scrape target.

Why wrong: PrometheusRule is for alerting rules, not scrape configuration.

TCP socket probe

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

HTTP GET probe

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

Liveness probe

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

Run 'kubectl top pod <pod-name>' to check CPU/memory usage.

Why wrong: Resource usage does not directly indicate probe status.

Run 'kubectl get nodes' to see node conditions.

Why wrong: Node conditions are not pod-specific.

kubectl logs pod-name --container container-name

Why wrong: Duplicated; but correct.

kubectl logs pod-name --all-containers

Why wrong: Shows logs from all containers, not a specific one.

kubectl logs pod-name

Why wrong: Without flags, only shows logs from the first container.

The liveness probe is failing, causing the container to be restarted.

Why wrong: No liveness probe events are shown.

The container is running out of memory (OOM).

Why wrong: No OOM events are present.

The container image is being pulled repeatedly.

Why wrong: Events show 'already present on machine', so not pulling.

Run 'kubectl describe pod backend' to see the pod's status.

Why wrong: Already saw events; describe may show additional info but logs are more direct.

Run 'kubectl get events' with a different filter to capture more details.

Why wrong: Events already show BackOff, but not the root cause.

Check if the image tag '1.0' exists in the registry.

Why wrong: The image is already present on the node, so pulling is not the issue.

Reduce the number of replicas to 2 to force the HPA to react more aggressively.

Why wrong: Reducing replicas increases load on remaining pods, but HPA still uses CPU target.

Increase the CPU target utilization to 90% so the HPA triggers earlier.

Why wrong: A higher target would make scaling even less likely.

Optimize the database queries to reduce response time.

Why wrong: While beneficial, it does not directly address the scaling mechanism.

The liveness probe uses a TCP socket check instead of an HTTP GET.

Why wrong: TCP socket check may be less resource-intensive than HTTP, but does not explain iptables churn.

The deployment sets resource requests and limits that are too low, causing pod throttling.

Why wrong: Throttling does not directly affect iptables rules.

The deployment uses a large number of environment variables, causing slow container startup.

Why wrong: Environment variables do not directly cause iptables churn.

kubectl describe deployment web-app

Why wrong: Describes deployment configuration, not memory usage.

kubectl get events

Why wrong: Shows cluster events, not memory metrics.

kubectl logs <pod>

Why wrong: Shows container logs, not memory usage.

Increase the restart policy to Always

Why wrong: Doesn't diagnose the root cause.

Run kubectl describe pod

Why wrong: Shows configuration, not runtime logs.

Check the pod's events with kubectl get events

Why wrong: Events may indicate issues but logs are more direct.

kubectl logs <pod> --node=<node>

Why wrong: Cannot get kubelet logs this way.

kubectl describe node <node>

Why wrong: Shows node status, not kubelet logs.

kubectl get events --field-selector involvedObject.kind=Node

Why wrong: Shows events, not kubelet logs.

Prometheus

Why wrong: Not built-in; requires separate deployment.

CoreDNS

Why wrong: DNS service, not metrics.

Kubernetes Dashboard

Why wrong: Web UI, not a metrics provider.

kubectl describe node

Why wrong: Shows node conditions, not pod storage errors.

kubectl get pvc

Why wrong: Shows PVC status, but not binding to pod.

kubectl get storageclass

Why wrong: Lists storage classes, but not pod issue.