The correct approach is to structure the Dockerfile so that commands requiring root (like package installation) are done as root, and then the non-root user is created and switched to. Using a high UID (>1000) is a common convention for unprivileged users. The other options compromise security: adding to the root group or using –privileged grants excessive privileges, and modifying host device permissions is a dangerous anti-pattern.

CoreDNS is the standard cluster DNS provider in Kubernetes. When internal service name resolution fails but IP-based connectivity works, the issue is typically with the DNS service itself. Checking CoreDNS logs and config (like the Corefile) is the most direct first step. DNS policy is usually ‘ClusterFirst’, and while misconfiguration is possible, checking the active DNS service’s health is more immediate. Resource limits and kube-proxy are less directly related to name resolution.

The `–selector` (or `-l`) flag is used to filter Kubernetes resources based on their labels. The syntax `app=api,environment=production` uses a logical AND, meaning it will return only pods that have **both** the label `app` with value `api` **and** the label `environment` with value `production`. It does not modify the pods, change output formatting, or filter by controller.

Kubernetes determines if a deployment needs to roll out new pods by checking for changes in the pod template spec. Using a mutable tag like `:latest` means the spec itself doesn’t change when a new image with that same tag is pushed. The best practice is to use immutable tags (e.g., version numbers, git commit SHAs). Changing the tag in the manifest triggers a rollout. While `imagePullPolicy: Always` can force a pull, it doesn’t solve the core declarative trigger problem and is less efficient.

A NodePort Service exposes the service on a static port (the NodePort, e.g., 3xxxx) on each node’s IP. When traffic arrives at any node’s IP on that port, the node’s kube-proxy component (using iptables or IPVS rules) intercepts it and forwards it to a pod that is an endpoint for the service, which may be on the same node or a different node in the cluster. It does not require direct pod-node coupling or an external load balancer.

Kubernetes Secrets are designed for this purpose. They store sensitive data in an encoded (base64) format, can be mounted as volumes into pods, and are managed by the API server with optional encryption at rest. This separates config from image and deployment manifests. Environment variables can be insecure (visible in pod specs and sometimes in logs). Building into the image is inflexible and exposes secrets in image layers. Using a public Git repo is a severe security violation.

The message breaks down the scheduling failure: 1) One node has insufficient CPU to meet the pod’s `requests.cpu`. 2) Two other nodes (likely control-plane/master nodes) have a taint that repels pods unless they have a matching toleration, which this pod does not. Therefore, the pod cannot be scheduled. The issue is a combination of resource constraints and standard taints on master nodes, not node selectors or node status.

These two parameters define the “battlefield” of a rolling update. `maxUnavailable` (often a number or percentage, e.g., 25%) determines how many of the *old* pods can be unavailable during the update process. `maxSurge` (e.g., 25%) determines how many *new* pods can be created *in addition to* the desired replica count. Together, they allow you to balance update speed (high surge) against service availability (low maxUnavailable).

Helm’s template language uses the `{{ if }}` function with a condition. The `eq` function is used to test equality. The correct syntax is `{{ if eq .Values.environment “production” }}`. Option A checks only for existence/truth, not a specific value. Option C has incorrect syntax for the `if` argument. Option D incorrectly uses `range` for a non-iterable value.

The correct approach is to structure the Dockerfile so that commands requiring root (like package installation) are done as root, and then the non-root user is created and switched to. Using a high UID (>1000) is a common convention for unprivileged users. The other options compromise security: adding to the root group or using –privileged grants excessive privileges, and modifying host device permissions is a dangerous anti-pattern.0