Application Deployment practice questions

During a deployment update, the rollout is stuck and new pods are not becoming ready. The developer checks the events and sees 'Back-off restarting failed container'. What is the most likely cause?

Trap 1: The liveness probe is failing

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.

Trap 2: The image pull secret is missing

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.

Trap 3: The pod exceeds its memory limit and is OOMKilled

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.

A
The liveness probe is failing
Why it fails: 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.
B
The container's entrypoint command fails immediately after start
An entrypoint that exits immediately with a non-zero code causes the container to crash right after startup. Kubernetes restarts the container, but each attempt fails equally quickly, so the restart loop triggers exponential back-off, producing CrashLoopBackOff. This directly stalls the deployment rollout because the new ReplicaSet can never reach the Ready state and the old ReplicaSet remains active.
C
The image pull secret is missing
Why it fails: 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.
D
The pod exceeds its memory limit and is OOMKilled
Why it fails: 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.

Question 2mediummulti select

Which THREE of the following are valid ways to expose a set of pods as a network service?

Trap 1: Ingress

Ingress is not a Service type, so it is invalid here. Ingress is a separate API object that defines HTTP/HTTPS routing rules (host, path, TLS) to Services, usually ClusterIP Services, and requires an Ingress controller (e.g., NGINX, Traefik) to implement them. While an Ingress can expose applications externally, it does not itself select pods or create endpoints; it only routes to Services.

Trap 2: ExternalName Service

ExternalName Service is invalid because it does not expose pods at all; it maps a Service name to an external DNS name by returning a CNAME record. It has no selector and no endpoints, so kube-proxy does not route traffic to pods. Instead, it allows pods to reference an external service (e.g., an RDS instance) using a local Service name, which is unrelated to exposing a pod set externally.

A
LoadBalancer Service
LoadBalancer Service is valid because it provisions a cloud provider load balancer (e.g., AWS ELB, GCP LB, Azure LB) and assigns it a stable external IP. That external IP forwards traffic to the Service's underlying ClusterIP, which then load-balances across ready pods. It is effectively a NodePort Service augmented with cloud-native ingress, making it suitable for directing external traffic to a set of pods from the internet.
B
Ingress
Why it fails: Ingress is not a Service type, so it is invalid here. Ingress is a separate API object that defines HTTP/HTTPS routing rules (host, path, TLS) to Services, usually ClusterIP Services, and requires an Ingress controller (e.g., NGINX, Traefik) to implement them. While an Ingress can expose applications externally, it does not itself select pods or create endpoints; it only routes to Services.
C
ClusterIP Service
ClusterIP Service is valid and is the default Service type, creating a stable virtual IP that is reachable only from within the cluster. It select pods using a label selector and load-balances traffic among their endpoints. Since it lacks external exposure mechanisms, it is suited for internal service-to-service communication, though it can be accessed externally via tools like kubectl port-forward or as the target of an Ingress.
D
NodePort Service
NodePort Service is valid because it opens a static port (30000-32767) on every node's IP address and forwards that traffic to the Service's ClusterIP, which then reaches the pods. This exposes the Service externally, but the client must know a node's IP and the NodePort; it is not cloud-aware and offers limited control over the external port. It is often used in on-premises or development environments or as a building block for LoadBalancer Services.
E
ExternalName Service
Why it fails: ExternalName Service is invalid because it does not expose pods at all; it maps a Service name to an external DNS name by returning a CNAME record. It has no selector and no endpoints, so kube-proxy does not route traffic to pods. Instead, it allows pods to reference an external service (e.g., an RDS instance) using a local Service name, which is unrelated to exposing a pod set externally.

Read the full DNS explanation →

Question 3hardmultiple choice

You are deploying a multi-tier application consisting of a frontend web service and a backend API. The frontend is deployed as a Deployment with 3 replicas, exposed via a ClusterIP Service named 'frontend-svc'. The backend is a StatefulSet with 3 replicas, each with its own PersistentVolumeClaim, and exposed via a headless Service named 'backend-svc'. The backend pods need to discover each other via DNS for clustering. After deployment, the backend pods cannot resolve the hostnames of other backend pods. The frontend can reach the backend via the Service name. You verify that the StatefulSet and its Service are correctly named. What is the most likely cause of the issue?

Trap 1: The StatefulSet's serviceName does not match the backend Service…

The serviceName field in a StatefulSet must reference a headless Service to serve as the governing Service for stable network identities. If it doesn't match the backend Service name, the StatefulSet cannot associate the pods with that Service, but the root cause here is that the referenced Service is not headless at all. Even a perfectly matching serviceName is useless for per-pod DNS records unless the Service has clusterIP: None.

Trap 2: The backend pods are not using the correct DNS domain

Kubernetes' default cluster DNS suffix is cluster.local, and StatefulSet pod FQDNs are constructed as <pod-name>.<service-name>.<namespace>.svc.cluster.local. The backend pods would only have DNS issues if the cluster's DNS domain were explicitly overridden or misconfigured, which is not indicated by the problem statement. Since the default domain is in effect, the DNS domain is not the source of the failure.

Trap 3: The frontend Service is interfering with the backend DNS

Services in Kubernetes are independent networking abstractions; the frontend Service only affects traffic destined for its own selector and has no bearing on DNS resolution for backend pods. DNS lookups for backend pod DNS names are answered by the cluster DNS service based on the backend Service and its pod endpoints. A frontend Service cannot influence or interfere with those DNS records, so this option is incorrect.

A
The StatefulSet's serviceName does not match the backend Service name
Why it fails: The serviceName field in a StatefulSet must reference a headless Service to serve as the governing Service for stable network identities. If it doesn't match the backend Service name, the StatefulSet cannot associate the pods with that Service, but the root cause here is that the referenced Service is not headless at all. Even a perfectly matching serviceName is useless for per-pod DNS records unless the Service has clusterIP: None.
B
The backend pods are not using the correct DNS domain
Why it fails: Kubernetes' default cluster DNS suffix is cluster.local, and StatefulSet pod FQDNs are constructed as <pod-name>.<service-name>.<namespace>.svc.cluster.local. The backend pods would only have DNS issues if the cluster's DNS domain were explicitly overridden or misconfigured, which is not indicated by the problem statement. Since the default domain is in effect, the DNS domain is not the source of the failure.
C
The frontend Service is interfering with the backend DNS
Why it fails: Services in Kubernetes are independent networking abstractions; the frontend Service only affects traffic destined for its own selector and has no bearing on DNS resolution for backend pods. DNS lookups for backend pod DNS names are answered by the cluster DNS service based on the backend Service and its pod endpoints. A frontend Service cannot influence or interfere with those DNS records, so this option is incorrect.
D
The backend Service is not headless
For a StatefulSet to provide stable DNS hostnames for its pods, the governing Service must be headless, meaning its clusterIP is set to None. A regular ClusterIP Service only exposes a single virtual IP for the entire set of pods and does not create individual DNS A records for each pod. Because the backend Service is not headless, the frontend cannot resolve names like backend-0.backend-svc.default.svc.cluster.local, causing the connection failure.

Question 4mediummultiple choice

You are responsible for deploying a critical application that must be highly available. The application consists of a single pod that should always be running on a node that has an SSD. You have two node pools: one with standard HDD and one with SSD. The application must be rescheduled immediately if the node fails. You create a Deployment with replicas: 1 and a nodeSelector for the SSD label. However, after a node failure, the pod is not rescheduled on another SSD node for several minutes. You check the Deployment and it shows the desired replica count is 1 but the current replica count is 0. What is the most likely reason for the delay?

Trap 1: The Deployment's progressDeadlineSeconds is set too high

progressDeadlineSeconds governs the maximum time a Deployment may remain in a progressing status before it is marked as failed. A high value would only delay the rollout failure detection, not the ReplicaSet's immediate reconciliation loop. Since the ReplicaSet creates a replacement pod as soon as it observes fewer than the desired number of active pods, an elevated progressDeadlineSeconds has no bearing on the initial scheduling delay.

Trap 2: The application's readiness probe is failing on the new node

A failing readiness probe causes the pod to be excluded from Service endpoints and marked NotReady, but it does not prevent the ReplicaSet from creating new pods. The ReplicaSet controller counts the pod as existing even if it is not ready, so the desired replica count is satisfied. Thus, a readiness probe failure would not explain a delay in pod creation, though it would explain traffic not being routed to the pod.

Trap 3: The nodeSelector is preventing the pod from being scheduled on…

A nodeSelector constraint causes a pod to remain Pending indefinitely if no node matches the label selector, but it does not affect the ReplicaSet's pod creation logic. The ReplicaSet still creates a replacement pod as soon as it realizes the old pod is gone; the placement problem arises after creation. In this scenario, the delay stems from the pod's final deletion, not from scheduling constraints, so nodeSelector is not the root cause.

A
The Deployment's progressDeadlineSeconds is set too high
Why it fails: progressDeadlineSeconds governs the maximum time a Deployment may remain in a progressing status before it is marked as failed. A high value would only delay the rollout failure detection, not the ReplicaSet's immediate reconciliation loop. Since the ReplicaSet creates a replacement pod as soon as it observes fewer than the desired number of active pods, an elevated progressDeadlineSeconds has no bearing on the initial scheduling delay.
B
The application's readiness probe is failing on the new node
Why it fails: A failing readiness probe causes the pod to be excluded from Service endpoints and marked NotReady, but it does not prevent the ReplicaSet from creating new pods. The ReplicaSet controller counts the pod as existing even if it is not ready, so the desired replica count is satisfied. Thus, a readiness probe failure would not explain a delay in pod creation, though it would explain traffic not being routed to the pod.
C
The pod is in Terminating state on the failed node and the ReplicaSet waits for it to be fully deleted
When a node fails, the pod on that node enters a Terminating state but is not immediately removed from the cluster's state. The ReplicaSet controller includes terminating pods in its current replica count, so until that pod is fully deleted, it perceives the desired number of replicas as already met. This behavior intentionally delays pod replacement to avoid exceeding the desired count, which is why the new pod is not created immediately.
D
The nodeSelector is preventing the pod from being scheduled on available SSD nodes
Why it fails: A nodeSelector constraint causes a pod to remain Pending indefinitely if no node matches the label selector, but it does not affect the ReplicaSet's pod creation logic. The ReplicaSet still creates a replacement pod as soon as it realizes the old pod is gone; the placement problem arises after creation. In this scenario, the delay stems from the pod's final deletion, not from scheduling constraints, so nodeSelector is not the root cause.

Question 5hardmultiple choice

A team is deploying a microservice that requires a ConfigMap mounted as a volume. The ConfigMap is expected to be updated frequently, and the application should read the latest values without restarting. Which volume type should be used?

Trap 1: hostPath

hostPath mounts a specific file or directory from the node's filesystem into the pod. It does not read from any Kubernetes API object, so it cannot deliver ConfigMap key-value pairs as requested. Using hostPath would require manually placing configuration data on a node's disk and creates portability and scheduling issues, since the pod would rely on node-local files. Therefore it is the wrong volume type for this requirement.

Trap 2: persistentVolumeClaim

A persistentVolumeClaim is a request for cluster storage backed by a PersistentVolume, such as an EBS volume or NFS share. It provides a raw block or filesystem store where files persist beyond pod restarts, but it has no mechanism to inject a ConfigMap's data. Even if you manually copied configuration data into the PV, the ConfigMap object would not be the source of truth and updates would not be propagated, so this option does not satisfy the microservice's need.

Trap 3: emptyDir

emptyDir creates an initially empty, ephemeral volume whose lifetime is tied to the pod. It is useful for scratch space or sharing data between containers in the same pod, but it never gets populated with ConfigMap contents. Since the volume starts empty and only holds whatever containers write to it, it cannot provide the key-value pairs from a ConfigMap, making this option incorrect for the deployment.

A
hostPath
Why it fails: hostPath mounts a specific file or directory from the node's filesystem into the pod. It does not read from any Kubernetes API object, so it cannot deliver ConfigMap key-value pairs as requested. Using hostPath would require manually placing configuration data on a node's disk and creates portability and scheduling issues, since the pod would rely on node-local files. Therefore it is the wrong volume type for this requirement.
B
persistentVolumeClaim
Why it fails: A persistentVolumeClaim is a request for cluster storage backed by a PersistentVolume, such as an EBS volume or NFS share. It provides a raw block or filesystem store where files persist beyond pod restarts, but it has no mechanism to inject a ConfigMap's data. Even if you manually copied configuration data into the PV, the ConfigMap object would not be the source of truth and updates would not be propagated, so this option does not satisfy the microservice's need.
C
emptyDir
Why it fails: emptyDir creates an initially empty, ephemeral volume whose lifetime is tied to the pod. It is useful for scratch space or sharing data between containers in the same pod, but it never gets populated with ConfigMap contents. Since the volume starts empty and only holds whatever containers write to it, it cannot provide the key-value pairs from a ConfigMap, making this option incorrect for the deployment.
D
Projected volume
A projected volume combines multiple Kubernetes resources into a single directory, and a ConfigMap can be explicitly included as one of its sources. When a ConfigMap is projected, its keys become files whose contents are the corresponding values, and the kubelet periodically refreshes those files so updates are reflected if the application watches them. This makes it the correct choice for a microservice that needs ConfigMap-backed configuration exposed as files.

Question 6hardmultiple choice

The exhibit shows a Deployment configuration. The application's /health endpoint returns HTTP 200 only after 30 seconds, while /ready returns 200 immediately. After applying this Deployment, what is the expected behavior?

Exhibit

Refer to the exhibit.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

Trap 1: Pods will become ready after 30 seconds when both probes pass.

The readiness probe hits /ready and gets a 200 response immediately after the container starts, so the pod becomes ready well before the 30-second mark. Liveness probe failures do not delay readiness; they only trigger container restarts. Therefore, the pod does not wait for both probes to pass, and this statement is inaccurate.

Trap 2: Pods will never become ready because the liveness probe fails…

Readiness and liveness probes serve independent purposes: readiness controls whether the pod is added to Service endpoints, while liveness only determines if the container should be restarted. Even though the liveness probe fails initially, the readiness probe still succeeds, so the pod becomes ready immediately. The failing liveness probe will cause repeated restarts, but it never prevents the pod from being marked ready. Thus the pod does become ready, making this option false.

Trap 3: Pods will never become ready because the readiness probe fails…

The readiness probe is configured to request /ready, which returns HTTP 200 as soon as the application process starts, so it passes on the first check. There is no initial failure period for readiness; the probe succeeds immediately. Consequently, the pod is marked ready almost instantly, not never. This option incorrectly assumes readiness fails initially, but the configuration shows it succeeds right away.

A
Pods will become ready after 30 seconds when both probes pass.
Why it fails: The readiness probe hits /ready and gets a 200 response immediately after the container starts, so the pod becomes ready well before the 30-second mark. Liveness probe failures do not delay readiness; they only trigger container restarts. Therefore, the pod does not wait for both probes to pass, and this statement is inaccurate.
B
Pods will never become ready because the liveness probe fails initially.
Why it fails: Readiness and liveness probes serve independent purposes: readiness controls whether the pod is added to Service endpoints, while liveness only determines if the container should be restarted. Even though the liveness probe fails initially, the readiness probe still succeeds, so the pod becomes ready immediately. The failing liveness probe will cause repeated restarts, but it never prevents the pod from being marked ready. Thus the pod does become ready, making this option false.
C
Pods will never become ready because the readiness probe fails initially.
Why it fails: The readiness probe is configured to request /ready, which returns HTTP 200 as soon as the application process starts, so it passes on the first check. There is no initial failure period for readiness; the probe succeeds immediately. Consequently, the pod is marked ready almost instantly, not never. This option incorrectly assumes readiness fails initially, but the configuration shows it succeeds right away.
D
Pods will become ready quickly but will be restarted repeatedly until the liveness probe starts succeeding after 30 seconds.
The readiness probe passes immediately, so the pod becomes ready and is added to the Service’s endpoint list within a few seconds of starting. However, the liveness probe, targeting /healthz, returns a non-2xx status for the first 30 seconds, causing the kubelet to repeatedly restart the container. Each restart makes the liveness probe fail again until the application finishes its 30-second initialization and begins returning 200. This produces a cycle of readiness and restarts until the liveness check finally succeeds, after which the pod stabilizes.

Read the full DNS explanation →

Question 7hardmultiple choice

You are deploying a microservice application on a Kubernetes cluster. The application consists of a frontend service (type: ClusterIP) and a backend service (type: ClusterIP). The frontend needs to communicate with the backend via DNS name 'backend-service'. The backend service runs three replicas, each listening on port 8080. You have created the backend service and deployment, and verified that pods are running. However, when you deploy the frontend pod and attempt to curl http://backend-service:8080 from within the frontend, you get 'connection refused'. The frontend pod is in the same namespace as the backend. You check the backend pods and they are all running and ready, and the endpoints object shows the correct pod IPs. You suspect a misconfiguration in the service definition. Which of the following is the most likely cause of the issue?

Trap 1: The backend pods are not running on the nodes because the cluster…

The backend pods are actually running and ready, which means the scheduler successfully placed them on nodes and they have sufficient CPU/memory to pass their probes. If the cluster lacked resources, the pods would remain in a Pending state, not Running/Ready, so resource exhaustion cannot be the cause of the observed issue.

Trap 2: The frontend pod is using the wrong service name; it should be…

Kubernetes DNS resolves the short service name 'backend-service' to a cluster IP within the same namespace, so a frontend pod in the default namespace can reach 'backend-service' without the fully qualified domain name. The FQDN 'backend-service.default.svc.cluster.local' is only necessary for cross-namespace access or certain network policies, not for same-namespace communication.

Trap 3: The backend service's port field is set to 8080, but the targetPort…

This option is wrong because while omitting targetPort does default it to the service's port field value (8080), the backend deployment's containerPort is actually 8081, so the defaulting would still produce a mismatch. The statement 'which is correct' is false in this scenario—the traffic would still be directed to port 8080 on the pod, where no process is listening, causing connection failures.

A
The backend pods are not running on the nodes because the cluster has insufficient resources.
Why it fails: The backend pods are actually running and ready, which means the scheduler successfully placed them on nodes and they have sufficient CPU/memory to pass their probes. If the cluster lacked resources, the pods would remain in a Pending state, not Running/Ready, so resource exhaustion cannot be the cause of the observed issue.
B
The frontend pod is using the wrong service name; it should be 'backend-service.default.svc.cluster.local'.
Why it fails: Kubernetes DNS resolves the short service name 'backend-service' to a cluster IP within the same namespace, so a frontend pod in the default namespace can reach 'backend-service' without the fully qualified domain name. The FQDN 'backend-service.default.svc.cluster.local' is only necessary for cross-namespace access or certain network policies, not for same-namespace communication.
C
The backend service's port field is set to 8080, but the targetPort is not specified, so it defaults to the port field value, which is correct.
Why it fails: This option is wrong because while omitting targetPort does default it to the service's port field value (8080), the backend deployment's containerPort is actually 8081, so the defaulting would still produce a mismatch. The statement 'which is correct' is false in this scenario—the traffic would still be directed to port 8080 on the pod, where no process is listening, causing connection failures.
D
The backend deployment's containerPort is set to 8081, but the service's targetPort is 8080, causing a mismatch.
A Service's targetPort specifies the port on the pod to which traffic is forwarded, and if that value does not match the containerPort (the port the application actually listens on), the connection is refused or fails. Here, the container listens on 8081 while the service forwards to 8080, so the frontend receives no valid response even though the service and endpoints exist.

Question 8hardmulti select

You are deploying a microservice that reads from a ConfigMap and a Secret. The application logs show 'Failed to read configuration: missing key' on startup. Which TWO are likely causes?

Trap 1: The Secret data is base64 encoded in the manifest, but the…

Kubernetes stores Secret data in etcd as base64-encoded strings, but the kubelet decodes that data before presenting it to the container, either as a file in a volume or as an environment variable. Therefore, the application receives the original decoded bytes, and the fact that the manifest shows base64 is merely an internal representation detail; it does not cause a missing-key error.

Trap 2: The ServiceAccount used by the pod does not have permissions to…

RBAC permissions control whether the pod's ServiceAccount can call the Kubernetes API to get or list Secrets, but an already-mounted Secret is fetched by the kubelet before the container starts and is placed on the local filesystem. Once the container is running, it reads the Secret from the mounted volume, not from the API server, so a missing key error would not be caused by insufficient ServiceAccount permissions; an RBAC denial would instead happen during the initial volume setup or when attempting to access the API directly.

Trap 3: The ConfigMap was updated but the pod was not restarted

If a ConfigMap is updated but the Pod is not restarted, the application continues to see the old data until the kubelet propagates the updated values; for environment-variable references, the update is never reflected until the Pod is recreated, and for volume mounts there is a delay. This results in stale or outdated configuration, but the referenced key still exists and has a value, so it would not appear as a missing key error; the symptom is an obsolete value, not an absent one.

A
The Secret data is base64 encoded in the manifest, but the application expects decoded values
Why it fails: Kubernetes stores Secret data in etcd as base64-encoded strings, but the kubelet decodes that data before presenting it to the container, either as a file in a volume or as an environment variable. Therefore, the application receives the original decoded bytes, and the fact that the manifest shows base64 is merely an internal representation detail; it does not cause a missing-key error.
B
The ConfigMap does not exist in the namespace
When a Pod references a ConfigMap that does not exist in the Pod's namespace, the kubelet cannot create the volume mount or resolve the configMapKeyRef for an environment variable. For a required reference, the container will be stuck in ContainerCreating with a CreateContainerConfigError; for an optional reference, the key is simply absent, but in both cases the application may fail because the expected configuration data is never available, which is the direct cause of the missing key.
C
The Secret volume mount has files with incorrect permissions (e.g., 0400) and the application runs as a non-root user
Secret volumes are often mounted with restrictive file modes such as 0400, and because the files are owned by root, an application running as a non-root UID will not have read permission on those mounts. This results in an EACCES permission-denied error when the application attempts to read the mounted secret file, which is a filesystem-level access failure rather than a configuration-key absence, so it would not produce the same symptom as a missing ConfigMap key.
D
The ServiceAccount used by the pod does not have permissions to access Secrets
Why it fails: RBAC permissions control whether the pod's ServiceAccount can call the Kubernetes API to get or list Secrets, but an already-mounted Secret is fetched by the kubelet before the container starts and is placed on the local filesystem. Once the container is running, it reads the Secret from the mounted volume, not from the API server, so a missing key error would not be caused by insufficient ServiceAccount permissions; an RBAC denial would instead happen during the initial volume setup or when attempting to access the API directly.
E
The ConfigMap was updated but the pod was not restarted
Why it fails: If a ConfigMap is updated but the Pod is not restarted, the application continues to see the old data until the kubelet propagates the updated values; for environment-variable references, the update is never reflected until the Pod is recreated, and for volume mounts there is a delay. This results in stale or outdated configuration, but the referenced key still exists and has a value, so it would not appear as a missing key error; the symptom is an obsolete value, not an absent one.

Question 9mediumdrag order

Arrange the steps to create a PersistentVolumeClaim and use it in a Pod.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Create Pod referencing PVC first, then create PVC.

Creating the Pod before the PVC is invalid because the API will not allow the Pod to reference a non-existent object; validation fails at Pod submission, so the Pod never runs. Even if it were submitted, a missing PVC means the volume mount cannot be resolved. The PVC must be created first to provide the storage identity the Pod's volumes list will reference.

Trap 2: Create PVC, then create Pod referencing PVC, without verifying…

Skipping the binding check is dangerous because a PVC in Pending state (no matching PV or no StorageClass to dynamically provision) will leave any Pod that references it stuck in ContainerCreating or Pending indefinitely. The Pod cannot successfully mount storage until the PVC's status becomes Bound to a physical PV. A quick `kubectl get pvc` check catches misconfigurations such as wrong storageClassName, excessive accessModes, or insufficient requested capacity before Pod creation.

Trap 3: Create Pod with inline volume, then convert to PVC-based volume.

Using an inline emptyDir/hostPath volume and then converting to a PVC does not fulfill the objective of creating and directly using a PersistentVolumeClaim. This workflow adds unnecessary ambiguity because inline volumes bypass the PV/PVC lifecycle and do not demonstrate persistent storage semantics like decoupled provisioning and rebinding across Pod rescheduling. The correct path is to define the PVC as its own API object and reference it in the Pod's volumes section from the start.

A
Create PVC, then verify PVC is bound to a PV, then create Pod referencing PVC in volumes.
This is the correct sequence because the Pod's volume definition references the PVC by name, so the PVC must already exist and be in the Bound state before Pod creation. Verifying the PVC-to-PV binding (e.g., `kubectl get pvc` shows STATUS Bound) ensures a usable volume is present; creating the Pod before this check risks Pending status. The three steps form a dependency chain: PVC exists, it is bound to persistent storage, and then the Pod can safely mount it.
B
Create Pod referencing PVC first, then create PVC.
Why it fails: Creating the Pod before the PVC is invalid because the API will not allow the Pod to reference a non-existent object; validation fails at Pod submission, so the Pod never runs. Even if it were submitted, a missing PVC means the volume mount cannot be resolved. The PVC must be created first to provide the storage identity the Pod's volumes list will reference.
C
Create PVC, then create Pod referencing PVC, without verifying binding.
Why it fails: Skipping the binding check is dangerous because a PVC in Pending state (no matching PV or no StorageClass to dynamically provision) will leave any Pod that references it stuck in ContainerCreating or Pending indefinitely. The Pod cannot successfully mount storage until the PVC's status becomes Bound to a physical PV. A quick `kubectl get pvc` check catches misconfigurations such as wrong storageClassName, excessive accessModes, or insufficient requested capacity before Pod creation.
D
Create Pod with inline volume, then convert to PVC-based volume.
Why it fails: Using an inline emptyDir/hostPath volume and then converting to a PVC does not fulfill the objective of creating and directly using a PersistentVolumeClaim. This workflow adds unnecessary ambiguity because inline volumes bypass the PV/PVC lifecycle and do not demonstrate persistent storage semantics like decoupled provisioning and rebinding across Pod rescheduling. The correct path is to define the PVC as its own API object and reference it in the Pod's volumes section from the start.

Question 10mediummatching

Match each kubectl command to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Create or update resources from a file

Rollback a deployment to a previous revision

Execute a command inside a container

Forward local port to a pod port

Show detailed state of a resource

Trap 1: kubectl get: Create or update resources from a file

kubectl get has no capability to create or update resources; it is strictly for retrieving and listing objects from the cluster. Using get to apply a file would ignore the file entirely because get only issues GET requests and accepts no manifests for mutating operations. Creation and updates are performed by kubectl create or kubectl apply, which send POST and PATCH requests respectively, so the verb semantics directly oppose what this statement claims.

Trap 2: kubectl describe: Remove resources from the cluster

kubectl describe performs only read-only operations: it fetches a resource and its associated events via the API server and prints a human-readable report. It has no flag or subcommand that triggers deletion, and it never sends a DELETE request; attempting to use it to remove a resource will simply fail or output nothing. Deleting is exclusively the job of kubectl delete, which issues the destructive HTTP DELETE verb, not describe.

A
kubectl get: Retrieve resource information from the cluster
kubectl get issues a read-only GET request to the Kubernetes API server and displays the current state of the requested resources as a table (e.g., pods, services). It is the primary command for verifying that objects exist, checking their status (like READY or IP addresses), and seeing whether a resource has been created or updated. Because it never mutates cluster state, it is safe to run in any context.
B
kubectl describe: Display detailed state of a resource
kubectl describe goes beyond the summary table produced by get: it fetches the resource's full spec and status, then augments it with recent events from the event stream. This reveals conditions, container restart counts, pod scheduling details, and volume/drive information that are invaluable when diagnosing why a workload is unhealthy or stuck. It is a diagnostic read-only command that queries resource details and related events, not a way to change anything.
C
kubectl apply: Create or update resources from a file
kubectl apply is a declarative command that sends a PATCH to the Kubernetes API server, making the cluster match the desired YAML/JSON file you provide. It performs a three-way merge between the file, the live object, and the last-applied-configuration annotation, allowing it to create resources if they don't exist and update only the fields that differ otherwise. This makes it the standard tool for GitOps workflows where the cluster should always reflect the state of a repository.
D
kubectl delete: Remove resources from the cluster
kubectl delete sends an HTTP DELETE request to the Kubernetes API server for the specified resources, removing them by name, file, or label selector. It triggers graceful termination according to the resource's terminationGracePeriodSeconds and cascading deletion of dependent objects (e.g., deleting a Deployment also deletes its ReplicaSets and Pods). This is a destructive, irreversible action, so options like --dry-run are commonly used to verify what would be removed before executing.
E
kubectl get: Create or update resources from a file
Why it fails: kubectl get has no capability to create or update resources; it is strictly for retrieving and listing objects from the cluster. Using get to apply a file would ignore the file entirely because get only issues GET requests and accepts no manifests for mutating operations. Creation and updates are performed by kubectl create or kubectl apply, which send POST and PATCH requests respectively, so the verb semantics directly oppose what this statement claims.
F
kubectl describe: Remove resources from the cluster
Why it fails: kubectl describe performs only read-only operations: it fetches a resource and its associated events via the API server and prints a human-readable report. It has no flag or subcommand that triggers deletion, and it never sends a DELETE request; attempting to use it to remove a resource will simply fail or output nothing. Deleting is exclusively the job of kubectl delete, which issues the destructive HTTP DELETE verb, not describe.

Question 11mediummatching

Match each volume type to its use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Temporary storage that shares a pod's lifecycle

Mounts a file or directory from the host node

Requests durable storage from a PersistentVolume

Inject configuration data as files or env vars

Inject sensitive data as files or env vars

Trap 1: emptyDir: Mounts a file or directory from the host node's…

Incorrect — this describes hostPath, not emptyDir.

Trap 2: hostPath: Requests persistent storage that survives pod restarts.

Incorrect — this describes PersistentVolumeClaim, not hostPath.

A
emptyDir: Provides temporary storage that is created empty and persists for the lifetime of the pod.
emptyDir is a temporary volume that shares the pod's lifecycle.
B
hostPath: Mounts a file or directory from the host node's filesystem.
hostPath allows a pod to access the host's filesystem.
C
persistentVolumeClaim: Requests persistent storage that can be used by a pod and survives pod restarts.
PersistentVolumeClaim provides durable storage independent of pod lifecycle.
D
configMap: Injects configuration data as files or environment variables.
ConfigMap is used to supply non-sensitive configuration to pods.
E
emptyDir: Mounts a file or directory from the host node's filesystem.
Why it fails: Incorrect — this describes hostPath, not emptyDir.
F
hostPath: Requests persistent storage that survives pod restarts.
Why it fails: Incorrect — this describes PersistentVolumeClaim, not hostPath.

Question 12hardmultiple choice

You have an existing Deployment 'web' created with 'kubectl create deployment web --image=nginx --replicas=3'. You need to change the image to 'nginx:1.19' and record the change. Which command should you use?

Trap 1: kubectl replace -f deployment.yaml --record

kubectl replace requires a complete YAML file and performs a full object replacement, not an image-only update. It does not support the --record flag the way apply or set image do, so no change-cause annotation is written to the Deployment's template. Additionally, if deployment.yaml doesn't exactly match the live config, replace can overwrite other in-place changes. Therefore it is not the correct command for this task.

Trap 2: kubectl edit deployment web --record

kubectl edit launches an interactive editor for the live Deployment object; while any manual spec change is sent as an update, the edit command has no --record flag, so the change is not annotated with a change-cause. The resulting rollout history entry will lack a 'change-cause' field, making the update untraceable. It also cannot be used in a non-interactive exam shell, and it requires manually typing the image change.

Trap 3: kubectl patch deployment web -p…

kubectl patch does not accept a --record flag, so even though the JSON patch would change the image, no change-cause annotation is added to the Deployment template. The provided patch string also contains an extra closing brace and is not valid JSON, so kubectl would reject it before any update happens. Patching is used for targeted updates but lacks the built-in history recording that kubectl set image provides.

A
kubectl set image deployment/web web=nginx:1.19 --record
kubectl set image deployment/web web=nginx:1.19 is the imperative command specifically designed to update the image of a container named 'web' in the Deployment. The --record flag annotates the Deployment template with kubernetes.io/change-cause, which causes the Deployment controller to roll out a new ReplicaSet and record the command as the change-cause in rollout history. This is the correct way to perform and log this image update.
B
kubectl replace -f deployment.yaml --record
Why it fails: kubectl replace requires a complete YAML file and performs a full object replacement, not an image-only update. It does not support the --record flag the way apply or set image do, so no change-cause annotation is written to the Deployment's template. Additionally, if deployment.yaml doesn't exactly match the live config, replace can overwrite other in-place changes. Therefore it is not the correct command for this task.
C
kubectl edit deployment web --record
Why it fails: kubectl edit launches an interactive editor for the live Deployment object; while any manual spec change is sent as an update, the edit command has no --record flag, so the change is not annotated with a change-cause. The resulting rollout history entry will lack a 'change-cause' field, making the update untraceable. It also cannot be used in a non-interactive exam shell, and it requires manually typing the image change.
D
kubectl patch deployment web -p '{"spec":{"template":{"spec":{"containers":[{"name":"web","image":"nginx:1.19"}]}}}}}' --record
Why it fails: kubectl patch does not accept a --record flag, so even though the JSON patch would change the image, no change-cause annotation is added to the Deployment template. The provided patch string also contains an extra closing brace and is not valid JSON, so kubectl would reject it before any update happens. Patching is used for targeted updates but lacks the built-in history recording that kubectl set image provides.

Question 13mediummultiple choice

You are using Kustomize to manage configurations. Your project structure is: 'base/kustomization.yaml', 'overlays/prod/kustomization.yaml'. The base defines a Deployment with image 'nginx:1.18'. The overlay wants to patch the image to 'nginx:1.19'. Which is the correct way to define the patch in the overlay?

Trap 1: Use 'resources: [../base]' and then define a new Deployment with…

Listing '../base' as a resource and then defining a new Deployment with the same name would create conflicting resources with identical name/namespace/kind in the kustomize build, causing a resource conflict error. Kustomize does not perform automatic last-write-wins merging for duplicate resources; you must use a strategic merge patch to override specific fields like the container image. Using a separate Deployment would also reintroduce the original container, defeating the override.

Trap 2: Use 'patchesJson6902: [target: ..., patch: ...]'

`patchesJson6902` applies a JSON Patch (RFC 6902) operation to a specific target resource, but the stem requires a strategic merge patch that overlays the image field onto the base Deployment. It is tempting because `patchesJson6902` can modify any field in any resource, and would be correct if the overlay needed to replace a list element or apply an operation like `replace` or `add` to a nested path, rather than merging a simple scalar override.

A
Use 'patches: [path: deployment-patch.yaml]'
The bare 'patches' field is not recognized by kustomize; kustomization.yaml uses 'patchesStrategicMerge' for strategic merge patches (or 'patchesJson6902' for JSON patches). Using 'patches' would have no effect or cause a validation error, so the image override would not be applied. The correct approach is to list the patch file under 'patchesStrategicMerge'.
B
Use 'resources: [../base]' and then define a new Deployment with the same name to override.
Why it fails: Listing '../base' as a resource and then defining a new Deployment with the same name would create conflicting resources with identical name/namespace/kind in the kustomize build, causing a resource conflict error. Kustomize does not perform automatic last-write-wins merging for duplicate resources; you must use a strategic merge patch to override specific fields like the container image. Using a separate Deployment would also reintroduce the original container, defeating the override.
C
Use 'patchesStrategicMerge: [deployment-patch.yaml]' where deployment-patch.yaml contains the image override.
The 'patchesStrategicMerge' field in kustomization.yaml accepts a list of YAML resource fragments that are strategic-merge-patched onto the base resources. For example, a patch that specifies the same kind/name/metadata and the container with the new image will override the base image while preserving unchanged fields. This is the idiomatic, declarative overlay mechanism that supports merging by object name and container name.
D
Use 'patchesJson6902: [target: ..., patch: ...]'
Why it fails: `patchesJson6902` applies a JSON Patch (RFC 6902) operation to a specific target resource, but the stem requires a strategic merge patch that overlays the image field onto the base Deployment. It is tempting because `patchesJson6902` can modify any field in any resource, and would be correct if the overlay needed to replace a list element or apply an operation like `replace` or `add` to a nested path, rather than merging a simple scalar override.

Question 14hardmultiple choice

You have a HorizontalPodAutoscaler (HPA) targeting a Deployment. The HPA is configured with 'targetCPUUtilizationPercentage: 50'. The current CPU utilization is 60% across the pods. What action does the HPA take?

Trap 1: Scale down the Deployment because the target is 50%.

Scaling down would increase per-pod CPU utilization, moving further from the target.

Trap 2: Mark the HPA as unable to calculate metrics and stop scaling.

Metrics are being collected; the HPA will calculate the desired replicas and scale up.

Trap 3: Take no action because the deviation is within tolerance.

The default tolerance is 0.1 (10% of target), so 60% is above 55% (50% + 5%), triggering a scale-up.

A
Scale down the Deployment because the target is 50%.
Why it fails: Scaling down would increase per-pod CPU utilization, moving further from the target.
B
Mark the HPA as unable to calculate metrics and stop scaling.
Why it fails: Metrics are being collected; the HPA will calculate the desired replicas and scale up.
C
Scale up the Deployment to reduce per-pod CPU utilization.
By adding more pods, the load is distributed, reducing the average CPU utilization towards the target.
D
Take no action because the deviation is within tolerance.
Why it fails: The default tolerance is 0.1 (10% of target), so 60% is above 55% (50% + 5%), triggering a scale-up.

Question 15mediummultiple choice

You are performing a blue-green deployment for an application. You have two Deployments: 'app-blue' (current production) and 'app-green' (new version). Both have label 'app: myapp' and are exposed by a Service 'myapp-svc'. How do you switch traffic from blue to green?

Trap 1: Delete the Service and recreate it with the selector pointing to…

Deleting the Service causes downtime until it is recreated.

Trap 2: Delete the blue Deployment after ensuring green is ready.

Deleting the blue Deployment does not switch traffic; the Service still points to blue pods if the selector matches.

Trap 3: Update the blue Deployment's image to the new version.

This would perform a rolling update, not a blue-green deployment.

A
Delete the Service and recreate it with the selector pointing to app-green.
Why it fails: Deleting the Service causes downtime until it is recreated.
B
Update the Service's selector to match the labels of the green Deployment's pods (e.g., 'version: green').
Changing the selector immediately routes traffic to the pods matching the new selector. If the green pods are ready, traffic switches seamlessly.
C
Delete the blue Deployment after ensuring green is ready.
Why it fails: Deleting the blue Deployment does not switch traffic; the Service still points to blue pods if the selector matches.
D
Update the blue Deployment's image to the new version.
Why it fails: This would perform a rolling update, not a blue-green deployment.

Question 16mediummulti select

Which TWO of the following are valid methods to achieve a blue-green deployment in Kubernetes? (Select two.)

Trap 1: Use a single Deployment and change the image, then use kubectl…

A single Deployment cannot provide two separate environments; changing its image triggers a rolling update even if you pause or resume the rollout. kubectl rollout pause merely halts the ReplicaSet progression, and resume continues it; it does not route traffic to a separate green set. Thus, this describes a controlled rolling update, not blue-green deployment, because there's no simultaneously running stable and candidate stack.

Trap 2: Set maxSurge=100% and maxUnavailable=0% in the Deployment strategy.

Setting maxSurge=100% and maxUnavailable=0% causes the new ReplicaSet to scale up to full replicas before the old ReplicaSet scales down, but this still occurs within the same Deployment and is governed by the Deployment controller. The old and new pods briefly coexist, yet a single Service selects both via the same labels, so traffic is not explicitly switched. This is a zero-downtime rolling update strategy, not a blue-green deployment, because there is no independent Service endpoint for the old version.

Trap 3: Create multiple Deployments with different images and use Ingress…

Weight-based routing via Ingress splits traffic proportionally between two Deployments, which is characteristic of canary releases rather than blue-green deployments. Blue-green requires an all-or-nothing traffic switch, where 100% of requests move from blue to green at once, without gradual weighting. Additionally, Ingress weight configuration often relies on an external controller (e.g., Nginx or Istio) and does not provide an atomic cutover; a Service selector change is the native Kubernetes mechanism.

A
Use a single Deployment and change the image, then use kubectl rollout pause/resume to control traffic.
Why it fails: A single Deployment cannot provide two separate environments; changing its image triggers a rolling update even if you pause or resume the rollout. kubectl rollout pause merely halts the ReplicaSet progression, and resume continues it; it does not route traffic to a separate green set. Thus, this describes a controlled rolling update, not blue-green deployment, because there's no simultaneously running stable and candidate stack.
B
Set maxSurge=100% and maxUnavailable=0% in the Deployment strategy.
Why it fails: Setting maxSurge=100% and maxUnavailable=0% causes the new ReplicaSet to scale up to full replicas before the old ReplicaSet scales down, but this still occurs within the same Deployment and is governed by the Deployment controller. The old and new pods briefly coexist, yet a single Service selects both via the same labels, so traffic is not explicitly switched. This is a zero-downtime rolling update strategy, not a blue-green deployment, because there is no independent Service endpoint for the old version.
C
Create multiple Deployments with different images and use Ingress with weight-based routing.
Why it fails: Weight-based routing via Ingress splits traffic proportionally between two Deployments, which is characteristic of canary releases rather than blue-green deployments. Blue-green requires an all-or-nothing traffic switch, where 100% of requests move from blue to green at once, without gradual weighting. Additionally, Ingress weight configuration often relies on an external controller (e.g., Nginx or Istio) and does not provide an atomic cutover; a Service selector change is the native Kubernetes mechanism.
D
Create two Deployments (blue and green) with different labels, and a Service that selects one of them. Update the Service's selector to switch traffic.
This is the classic blue-green pattern: two Deployments run with different labels, and a Service's selector points to the active version. When ready, you update the Service's selector (e.g., from 'version: blue' to 'version: green'), causing Kubernetes to update the Endpoints and route all traffic instantly. The old Deployment remains untouched, enabling immediate rollback by reverting the selector. This leverages core Service load-balancing semantics and provides zero-downtime releases.
E
Create a Service that selects pods with label 'app: myapp' and manipulate the 'version' label on pods to shift traffic.
This is also valid: if the Service's selector includes a mutable label such as 'version', you can shift traffic by relabeling pods so that only the desired version matches. However, directly editing pod labels is subtly different from updating the Service selector, because the Deployment controller manages replica pods and may revert label changes. A more practical variant is to use a Deployment with the new pod template and change labels via a rolling update, but the selector-based routing logic still works. The key is that the Service must select on a label that you change atomically on all pods.

Question 17hardmulti select

Which TWO of the following are valid ways to view the rollout history of a Deployment named 'myapp'? (Select two.)

Trap 1: kubectl describe deployment myapp

Incorrect. Only shows the current revision annotation; does not list past revisions.

Trap 2: kubectl rollout status deployment myapp

Incorrect. Monitors the progress of a current rollout, not the history.

Trap 3: kubectl get deployment myapp -o yaml

Incorrect. Outputs the current Deployment manifest; does not contain revision history.

A
kubectl get replicasets -l app=myapp
ReplicaSets created by the Deployment carry the pod-template-hash and app labels, so filtering by app=myapp lists each revision's ReplicaSet, revealing rollout history. This satisfies the stem's requirement for a valid way to view a Deployment's rollout history.
B
kubectl rollout history deployment myapp
The rollout history subcommand queries the Deployment's stored revision records, listing each ReplicaSet revision and its change-cause annotation. Naming the resource type and name directly satisfies the stem's requirement to view rollout history for 'myapp' without needing a pod or container selector.
C
kubectl describe deployment myapp
Why it fails: Incorrect. Only shows the current revision annotation; does not list past revisions.
D
kubectl rollout status deployment myapp
Why it fails: Incorrect. Monitors the progress of a current rollout, not the history.
E
kubectl get deployment myapp -o yaml
Why it fails: Incorrect. Outputs the current Deployment manifest; does not contain revision history.

Question 18mediummultiple choice

You need to scale a Deployment named 'frontend' to 10 replicas. Which command correctly accomplishes this?

Trap 1: kubectl patch deployment frontend -p '{"spec":{"replicas":10}}'

This works but is not the simplest command; the question asks for the command to scale.

Trap 2: kubectl set replicas deployment/frontend 10

'kubectl set' does not have a 'replicas' subcommand; use 'scale'.

Trap 3: kubectl scale --replicas=10 deployment frontend

The flag --replicas should come after the resource.

A
kubectl scale deployment/frontend --replicas=10
This is the correct syntax.
B
kubectl patch deployment frontend -p '{"spec":{"replicas":10}}'
Why it fails: This works but is not the simplest command; the question asks for the command to scale.
C
kubectl set replicas deployment/frontend 10
Why it fails: 'kubectl set' does not have a 'replicas' subcommand; use 'scale'.
D
kubectl scale --replicas=10 deployment frontend
Why it fails: The flag --replicas should come after the resource.

Question 19mediummulti select

Which TWO of the following are valid methods to perform a blue-green deployment in Kubernetes?

Trap 1: Use kubectl patch to modify the Deployment's image and rely on the…

Patching the Deployment's image under the Recreate strategy simply terminates the existing pod and replaces it with the new version, causing downtime and providing no parallel old or new environment. Blue-green requires both versions to run simultaneously so that traffic can be switched atomically; patching in-place gives you no independent green environment to validate against or fall back to, making this a plain update rather than a blue-green deployment.

Trap 2: Use kubectl rollout undo to revert to the previous version.

kubectl rollout undo is a rollback mechanism that returns the existing Deployment to a previous revision, not a blue-green deployment. It does not create or maintain a second, parallel environment; instead, it actively replaces the current version with an older one, often via a rolling update that can cause partial unavailability and does not offer an atomic traffic switch between two live environments.

Trap 3: Use the RollingUpdate strategy with maxSurge=100% and…

The RollingUpdate strategy with maxSurge=100% and maxUnavailable=0% scales up the new ReplicaSet while gradually terminating old pods, but it never runs two complete, fully independent versions to support a controlled traffic cutover. Blue-green requires both deployments to coexist fully with a Service-level switch, whereas this strategy rolls pods incrementally and lacks the ability to keep the entire previous build intact for an instant switch-back.

A
Use kubectl patch to modify the Deployment's image and rely on the Recreate strategy.
Why it fails: Patching the Deployment's image under the Recreate strategy simply terminates the existing pod and replaces it with the new version, causing downtime and providing no parallel old or new environment. Blue-green requires both versions to run simultaneously so that traffic can be switched atomically; patching in-place gives you no independent green environment to validate against or fall back to, making this a plain update rather than a blue-green deployment.
B
Create a new Deployment for the new version, then update the Service's selector to point to the new pods.
This is the canonical blue-green pattern: create a completely separate Deployment for the new version, leaving the old Deployment untouched, then flip the Service's selector from the old pod labels to the new pod labels. Because the Service is the single stable entry point, changing its selector instantly re-routes all incoming traffic to the new pods, and you can switch back just as quickly if the new version misbehaves, providing zero-downtime release with fast rollback.
C
Deploy the new version in a separate namespace and use a Service to route traffic to the new namespace.
Deploying the new version in a separate namespace and using a Service to route traffic to that namespace is a valid namespace-isolated blue-green approach. The new namespace functions as the 'green' environment with its own Deployments and Services; switching traffic consists of pointing an Ingress, load balancer, or Service mesh to the new namespace's Service, and reverting means pointing it back to the original namespace. Namespace isolation also simplifies cleanup — deleting the namespace removes the entire green environment and all its resources.
D
Use kubectl rollout undo to revert to the previous version.
Why it fails: kubectl rollout undo is a rollback mechanism that returns the existing Deployment to a previous revision, not a blue-green deployment. It does not create or maintain a second, parallel environment; instead, it actively replaces the current version with an older one, often via a rolling update that can cause partial unavailability and does not offer an atomic traffic switch between two live environments.
E
Use the RollingUpdate strategy with maxSurge=100% and maxUnavailable=0%.
Why it fails: The RollingUpdate strategy with maxSurge=100% and maxUnavailable=0% scales up the new ReplicaSet while gradually terminating old pods, but it never runs two complete, fully independent versions to support a controlled traffic cutover. Blue-green requires both deployments to coexist fully with a Service-level switch, whereas this strategy rolls pods incrementally and lacks the ability to keep the entire previous build intact for an instant switch-back.

Question 20mediummulti select

Which TWO of the following commands are used to inspect the rollout history of a Deployment?

Trap 1: kubectl rollout status deployment/my-deployment

kubectl rollout status deployment/my-deployment is a synchronization command that blocks until the deployment's current rollout completes, reporting whether new replicas are available and old ones are terminated. It provides a live progress view, not a historical log, and contains no notion of revisions or past rollouts, so it cannot be used to inspect rollout history.

Trap 2: kubectl get events --field-selector…

kubectl get events --field-selector involvedObject.name=my-deployment retrieves events associated with the deployment object, such as scaling or scheduling messages. Events are ephemeral, time-stamped records that are typically retained for only a short period, and they do not enumerate rollout revisions or maintain a persistent history. Therefore, this command may show some rollout activity but is not a reliable or complete way to inspect rollout history.

Trap 3: kubectl describe deployment my-deployment

kubectl describe deployment my-deployment displays a detailed snapshot of the deployment's current desired state, status, labels, selectors, and the latest rollout revision annotation. While it may reveal the current revision or recent events, it collapses all historical ReplicaSets into an aggregated status and does not list past revisions or their change-cause metadata. It is a state inspection tool, not a history browser, so it is incorrect for this purpose.

A
kubectl rollout status deployment/my-deployment
Why it fails: kubectl rollout status deployment/my-deployment is a synchronization command that blocks until the deployment's current rollout completes, reporting whether new replicas are available and old ones are terminated. It provides a live progress view, not a historical log, and contains no notion of revisions or past rollouts, so it cannot be used to inspect rollout history.
B
kubectl rollout history deployment/my-deployment
kubectl rollout history deployment/my-deployment is the dedicated kubectl subcommand for inspecting a deployment's rollout history. It prints a table of revisions, with optional --revision flag to show detailed information for a specific revision, including the change-cause annotation. This command directly queries the underlying ReplicaSets and their revision annotations, making it the authoritative way to view rollout history.
C
kubectl get replicasets -l app=my-app
kubectl get replicasets -l app=my-app lists ReplicaSets owned by the deployment based on the label selector. Because each rollout creates a new ReplicaSet tagged with the deployment.kubernetes.io/revision annotation, this command can infer history by showing the different ReplicaSets and their replica counts. It is a valid inspection method, though it requires knowing the correct selector and lacks the consolidated revision formatting of rollout history.
D
kubectl get events --field-selector involvedObject.name=my-deployment
Why it fails: kubectl get events --field-selector involvedObject.name=my-deployment retrieves events associated with the deployment object, such as scaling or scheduling messages. Events are ephemeral, time-stamped records that are typically retained for only a short period, and they do not enumerate rollout revisions or maintain a persistent history. Therefore, this command may show some rollout activity but is not a reliable or complete way to inspect rollout history.
E
kubectl describe deployment my-deployment
Why it fails: kubectl describe deployment my-deployment displays a detailed snapshot of the deployment's current desired state, status, labels, selectors, and the latest rollout revision annotation. While it may reveal the current revision or recent events, it collapses all historical ReplicaSets into an aggregated status and does not list past revisions or their change-cause metadata. It is a state inspection tool, not a history browser, so it is incorrect for this purpose.