CCNA Application Deployment Questions

If the container's resource requests are set lower than actual usage, the utilization percentage can be higher. For example, if request is 100m but usage is 200m, utilization is 200% even if absolute CPU is low. This could trigger scaling.

This is the canonical imperative command to manually change the DesiredReplicas field of a deployment. `kubectl scale` works on deployments, replication controllers, replica sets, and stateful sets, and the `--replicas=` flag explicitly sets the target count. It is the correct way to immediately scale a deployment without altering any other spec.

7 is correct because during a rolling update with a desired replica count of 5 and a maxSurge set to 2, Kubernetes is allowed to create up to 2 additional pods above the desired count. This surge capacity means the absolute maximum number of pods that can be running simultaneously is 5 + 2 = 7. The deployment controller uses this headroom to bring up new pods before terminating old ones, ensuring zero downtime and a smooth transition.

In a Recreate strategy, the Deployment controller first scales the old ReplicaSet down to zero and waits for all old pods to terminate completely. Only after a clean shutdown does it create the new ReplicaSet and its pods. This guarantees that no two versions of the application ever run concurrently, but it intentionally introduces downtime during the transition.

Kustomize's overlay patches are applied on top of the base after the base is fully rendered. A patch that sets replicas to 5 will replace the base's value of 3, because overlays are designed to be the final authority for customized values. The kustomize build output therefore contains the patched field, not the base's original value, making 5 the correct and deterministic result.

helm install <release-name> <chart> is the correct command to create a Helm release from a chart source. The chart argument can be a repository reference like 'bitnami/nginx', a local directory path, a packaged .tgz file, or a URL. Executing this command renders the chart's templates with the default values and applies them to the cluster, registering the release so that later upgrades or rollbacks can be performed via `helm upgrade` and `helm rollback`.

`helm list` is the correct command here because it enumerates every Helm release installed in the current namespace, displaying each release's name, status, chart version, app version, and revision number. It also indicates whether a release is deployed, failed, pending, or uninstalled, giving a concise overview similar to how `kubectl get pods` lists pods. Since you installed a WordPress chart via Helm, running `helm list` will confirm that the release exists and show its current lifecycle state.

`kubectl rollout pause deployment/my-deployment` is the correct command because it updates the Deployment's `.spec.paused` field to `true`, signaling the deployment controller to stop progressing the current rollout. The running Pods and existing ReplicaSets remain untouched, but any template changes you've made are held back until you run `kubectl rollout resume`. This gives you a controlled window to verify or modify configuration mid-stream.

This works because removing the version label from the Service selector makes it match every pod labeled app: myapp, including both v1 and v2. With v1 replicas=9 and v2 replicas=1, the Service sees 10 ready endpoints, and the default load-balancing behavior sends roughly one-tenth of requests to v2. This replica ratio is the standard lightweight canary technique for a single Service, as long as both Deployments share the same app label and no other version-specific selector remains.

StatefulSet is the correct controller because it gives each pod a stable ordinal identity (e.g., db-0, db-1) and stable, dedicated PersistentVolumeClaims via volumeClaimTemplates. It supports ordered startup, shutdown, and scaling, which is critical for database clustering and failover. The stable network DNS names enable database nodes to discover and communicate with each other reliably across rescheduling. Thus, it matches the requirements of a stateful database deployment.

Correct. The maxUnavailable value is derived by taking 25% of the desired replicas: 0.25 × 5 = 1.25. Since the number of pods must be an integer, Kubernetes rounds this up to 1, ensuring at most one pod is unavailable at a time. This leaves at least 4 replicas running throughout the update, matching the configured tolerance.

The `images` field with `newTag` is the purpose-built transformer for overriding container image tags in Kustomize. It preserves the original image name and replaces only the tag with the specified value, making it the simplest and most declarative way to pin a new version across all matching containers. This is why this option is the correct answer.

This is the classic Kubernetes-native canary pattern: both Deployments' pods share a common label (e.g., app: myapp, version: stable/canary) and the same Service selects on that common label, so the Service's Endpoints automatically include pods from both versions. The proportion of requests reaching the canary is approximately the ratio of canary replicas to total replicas, so starting with 1 canary replica and many stable replicas delivers a small traffic share. Incrementally scaling up canary replicas shifts more traffic incrementally, allowing monitoring for regressions without needing any additional routing components.

During a rolling update, the Deployment controller creates a new ReplicaSet and scales it up. Before it proceeds to terminate old pods and scale up further, it must confirm that newly created pods are actually Ready by passing their readiness probes. If a new pod fails its readiness probe, the rollout stalls to protect availability, preventing traffic from being routed to unhealthy pods and avoiding cascading failures.

Containers in a pod share the same network namespace, meaning they have a single IP address, a shared port space, and a common loopback interface. This allows the main application and sidecar to communicate directly on localhost without additional service discovery. However, they do not automatically share a filesystem unless a volume is explicitly mounted into both.

The `kubectl rollout undo deployment my-deployment` command is the correct rollback mechanism because it reverts the Deployment to the previously active ReplicaSet, effectively restoring the last known good Pod template. You can optionally specify `--to-revision` to target a specific historical revision; otherwise, it undoes only the most recent rollout, scaling down the current ReplicaSet and scaling up the prior one.

spec.strategy.rollingUpdate.maxUnavailable: 2 directly caps the number of pods that may be unavailable during a rolling update, ensuring that at most 2 pods are down at any given time relative to the desired replica count. The Deployment controller uses this value to decide when it can scale down old ReplicaSets and scale up new ones, keeping the available pod count at desired minus 2. This is the exact setting needed for the stated requirement of allowing at most 2 replicas to be unavailable.

A StatefulSet assigns each pod a stable, zero-based ordinal hostname (e.g., web-0, web-1) derived from the StatefulSet name and replica index. These identities persist across rescheduling because a replacement pod always inherits the same ordinal and, if configured, the same PersistentVolumeClaim. Combined with a headless service, each pod gets a unique DNS name, which perfectly fulfills the requirement for stable network identities in a stateless or stateful application.

Setting maxSurge=1 allows the deployment controller to create one additional pod beyond the desired 4 replicas before terminating any existing pods. This temporarily raises the total pod count to 5, ensuring that the running workload always has at least 4 available replicas throughout the rolling update. This strategy results in zero downtime as new pods become ready before old ones are removed.

When a Deployment's strategy is set to Recreate, the controller first scales the current ReplicaSet to zero, ensuring every old pod has terminated gracefully, and only then creates the new ReplicaSet and starts new pods. This eliminates any overlap between old and new versions, guaranteeing that no mixed-version traffic can occur, but it also means the application experiences full downtime during the transition. The ordering is strictly linear: the old pods must be gone before the new pods appear.

kubectl set image deployment/web-app app=nginx:1.21 changes the container named app in the Deployment web-app to use the nginx:1.21 image, directly altering the pod template of the Deployment. This triggers a rolling update by creating a new ReplicaSet and scaling it up while scaling down the old one, honoring maxSurge and maxUnavailable. It is the concise, imperative command explicitly designed for this image-update operation.

The `helm rollback my-app 3` command is the valid way to revert the release to revision 3. Helm will take the chart manifest and values stored at revision 3, apply them to the cluster, and then record a new revision number (for example, revision 5 if the current is 4) to preserve the ability to later roll forward or back. This is the canonical command for undoing a bad upgrade and it works exactly as written, with the release name and target revision as positional arguments.

This is the correct configuration because maxSurge: 1 caps the total number of pods at one beyond the desired 4, so at most 5 pods run during the update. Meanwhile, maxUnavailable: 0 forbids terminating any old pod until a new pod has become Ready, ensuring at least 4 pods are always available to serve traffic. Together they enforce exactly the stated constraints: no more than one extra pod and zero downtime.

The maxUnavailable field directly specifies the maximum number of pods that can be unavailable during a rolling update relative to the desired replica count. With maxUnavailable set to 2, the Deployment controller will ensure that at least 8 of the 10 original pods remain available at any time. Therefore, the maximum number of unavailable pods is exactly 2.

The HPA calculates the desired replicas using the formula desiredReplicas = ceil(currentReplicas * (currentMetric / targetMetric)). With current average CPU at 90% and target at 80%, the ratio is 1.125, so the HPA will increase the replica count to spread traffic and reduce per-pod CPU utilization back toward 80%. This is the only response aligned with the HPA's design, as scaling out dilutes workload across more pods and brings the metric within the target threshold.

kubectl apply operates declaratively: it sends the object configuration to the API server, which computes a difference between the desired state, the current live object, and the last-applied configuration, then issues a PATCH (or a POST if the resource does not exist). This allows apply to transparently create new resources and update existing ones in the same workflow. In contrast, kubectl create is imperative and always attempts to create a fresh resource per invocation; if the API server finds an existing object with the same identity, it returns an error instead of reconciling the object. Therefore, apply is suitable for both initial creation and ongoing updates, while create is intentionally limited to one-time creation where failure on duplicates is desirable.

`kubectl rollout history deployment my-deployment` is the canonical command to view a Deployment's rollout history. It lists all revisions, showing their revision numbers and change-cause annotations (if recorded), which gives you an overview of every template change. This is exactly what the question asks for, and it provides the foundation for rolling back to a specific revision.

This is the correct configuration: maxSurge=2 allows the Deployment to temporarily run up to 7 pods (5 desired + 2 extra), while maxUnavailable=1 guarantees that no more than 1 of the 5 desired replicas is unavailable, so at least 4 are always serving traffic. The controller first creates 2 new pods, then terminates old ones in a controlled manner, maintaining both the surge cap and availability floor. These values exactly match the requirement of allowing 2 extra pods and 1 unavailable pod during the update.

The command kubectl set image deployment/web app=nginx:1.21 targets the existing Deployment and updates the image of the container literally named 'app' in its pod template. This change to the pod template makes the Deployment controller detect a diff and begin a rolling update: it creates a new ReplicaSet with the nginx:1.21 image and progressively replaces old pods, preserving availability according to the rollout strategy. You can watch progress with kubectl rollout status deployment/web, and if needed, the update can be rolled back with kubectl rollout undo.

kubectl rollout status is the correct command to monitor a live rollout's progress. It polls the Deployment's status conditions and prints whether the update is still ongoing, has succeeded, or failed during the process deadline. It's a read-only operation and returns a successful exit code once the rollout has completed.

`kubectl rollout status deployment/myapp` is a valid subcommand that monitors the progress of a rollout in real time, waiting until the Deployment's pods are fully updated and available. It returns a non-zero exit code if the rollout fails, making it valuable in CI/CD to block execution until the deployment is healthy. It is one of the primary rollout inspection commands.

A kustomization.yaml file is Kustomize's declarative entry point, listing resources, patches, and generators that Kustomize applies to produce the final manifests. This directly satisfies the stem's requirement for a statement describing Kustomize's core mechanism, since every overlay and base depends on this file to define its customisation rules.

kubectl set image deployment/my-deployment nginx=nginx:1.21 is the correct imperative command because it directly changes the image of the container named nginx in the existing Deployment's pod template. The Deployment controller detects the template hash change, creates a new ReplicaSet, and performs a rolling update while keeping the Deployment name and metadata intact. This is a one-line, non-interactive, auditable update that accomplishes exactly the requested change.

This is correct because kubectl rollout undo deployment/myapp inspects the Deployment's rollout history, retrieves the spec of the last completed revision, and copies that Pod template back into the Deployment. The change triggers a new ReplicaSet that runs the previously known-good image and performs a rolling update. This is the standard, trackable mechanism for recovering from a bad rollout.

The Service acts as the traffic switch in a blue-green deployment; updating its selector from 'blue' to 'green' atomically redirects all client traffic to the green pods. Because green pods are already deployed and ready, this change requires no downtime and no pod restarts. This is the canonical cutover step: the selector change is the single point of control that moves production traffic to the new version.

kubectl rollout pause is the correct command because it sets the deployment's spec.paused field to true, instructing the deployment controller to stop creating or scaling new ReplicaSets. This freezes the rollout's current state and gives you a stable point to inspect logs, events, and resource metrics without the controller racing ahead. It directly addresses the need to investigate a stuck rollout.

kubectl apply -f deploy.yaml is the correct declarative command for this question. It sends a PATCH request using the apply semantics, which computes a three-way merge between the local YAML, the live object's current state, and the last-applied-configuration annotation (kubectl.kubernetes.io/last-applied-configuration). This creates the Deployment if it does not exist, or updates only the fields that differ from the desired state while preserving changes made by controllers or other actors. Because the question asks about a YAML deployment definition without any conditional like 'if it does not exist', apply is the idiomatic and safe way to ensure the desired state is enforced idempotently.

'kubectl scale' is the canonical command for resizing a Deployment's replica count. The resource type 'deployment' and the resource name 'frontend' are given as positional arguments, while '--replicas=5' sets the desired number of pods. This directly updates the Deployment's spec.replicas field and triggers the ReplicaSet/Deployment controllers to converge to the new count.

With maxUnavailable=0, the rolling update guarantees that no existing pods are terminated until replacement pods have been created and reached the Ready state. The default maxSurge=25% allows the deployment to temporarily provision additional pods beyond the desired replica count, ensuring a buffer of ready pods during the transition. This combination provides zero-downtime because traffic continues to be served by the old pods until new pods are fully ready and can take over seamlessly.

Under the Recreate strategy, the Deployment controller first scales the old ReplicaSet down to zero and confirms all Pods have been terminated (respecting terminationGracePeriodSeconds and preStop hooks) before it creates any new Pods from the updated ReplicaSet. This guarantees that at no point are old and new versions running concurrently, at the cost of an explicit downtime interval during the rollout.

kubectl rollout status deployment web-app is the dedicated command for observing the progress of a Deployment rollout. It watches the Deployment's updated ReplicaSet status and returns a stream of updates, for example 'Waiting for rollout to finish: 1 out of 3 new replicas have been updated...', exiting with 0 when the rollout succeeds or non-zero if it fails. Its synchronous behavior makes it ideal for scripting CI/CD pipelines that need to wait for a deployment to settle.

Two parallel Deployments let you validate the green version fully before cutover, and switching the Service selector redirects all traffic atomically without recreating pods. This satisfies the requirement for an instant, reversible switch between versions.

When you run kubectl scale deployment demo --replicas=5, the Deployment's scale subresource is updated, and the Deployment controller reconciles by adjusting the desired replicas on the currently active ReplicaSet. Because the pod template is unchanged, no new ReplicaSet is created or replaced; the existing ReplicaSet's spec.replicas is set to 5, and its controller creates exactly two new pods to go from 3 to 5 running instances.

This is the correct Helm conditional: `{{- if` trims all whitespace before it so the ConfigMap YAML sits directly at the intended indentation level, and `{{- end }}` trims the trailing whitespace after the block. Helm checks whether `.Values.config.enabled` evaluates to a truthy value (true for booleans, non-empty for strings/lists/maps) and renders the enclosed YAML only in that case. The dash (`-`) is critical for producing clean YAML without stray blank lines that can break resource parsing.

Kustomize's overlay mechanism layers environment-specific patches on top of a base kustomization, allowing you to modify replicas, images, or namespaces per environment. The base directory holds common resources, and overlays reference it via a `kustomization.yaml` with fields like `resources` and `patchesStrategicMerge`. This avoids duplicating manifests and keeps a single source of truth across dev, staging, and production.

`kubectl rollout status deployment web-app` is the correct command to monitor a Deployment's rollout progress. It blocks and repeatedly polls the Deployment's status, providing real-time updates until the rollout completes successfully, or it exits with an error if the rollout gets stuck. This command is specifically designed to report the rollout state, waiting for the new ReplicaSet to become fully available.

kubectl apply computes a patch between the desired configuration in your file and the current live object, then merges changes into the existing resource, thus it can update resources. In contrast, kubectl create sends a POST request to the API server and expects to create a brand-new object; if the resource already exists, the API server returns a 409 Conflict error. This fundamental difference makes apply the preferred tool for declarative updates.

The `kubectl scale` command is the canonical Kubernetes imperative operation for altering the desired replica count of a resource. Using `deployment api --replicas=5` explicitly identifies the resource type and name while supplying the target count through the mandatory `--replicas` flag. This triggers the scale subresource of the Deployment, updating its `spec.replicas`, and the corresponding ReplicaSet controller then adjusts pods to match. This syntax is correct because every required argument is provided and no invalid flags are used.

This correctly sets `maxSurge: 50%` and `maxUnavailable: 25%`, which are the exact fields and values requested for managing the rolling update. With four replicas, 50% surge translates to two extra pods (rounded up), allowing up to six pods, while 25% unavailable translates to one pod down (rounded down), guaranteeing at least three pods remain available during the update. This is the valid YAML representation of a rolling update with a 50% surge and 25% maximum unavailability.

Updating the Service's label selector to match the green Deployment's pod labels is the correct control point for traffic shifting. When the selector changes, the EndpointSlice controller re-evaluates matching Pods and replaces blue pod IPs with green pod IPs, atomically switching the backend. This approach preserves the ability to instantly roll back by reverting the selector to blue labels, provided the blue Deployment remains available.

With maxSurge=0, the desired replica count cannot be exceeded, and with maxUnavailable=1, at most one pod may be down during the update. This configuration forces a strictly sequential pattern: the controller first terminates an old pod, which counts as one unavailable pod, then creates a new pod to restore the replica count to the desired number. It then repeats this cycle for each remaining old replica, so one old pod is terminated, a new pod is created, and this continues until all pods are rolled over. This approach maintains availability without any temporary scaling up.

Configuring ingress controllers with specific settings like rewrite rules is a valid use of annotations because ingress controllers (e.g., NGINX, Traefik) are designed to read controller-specific annotations attached to the Ingress resource to customize routing behavior. For example, `nginx.ingress.kubernetes.io/rewrite-target` instructs the NGINX controller to rewrite request paths before proxying them to backend services. These annotations act as declarative configuration that the controller consumes, while the core Ingress spec remains portable across different controllers.

helm list is the correct command because it queries the Helm storage backend in the current Kubernetes namespace and returns all installed releases with their name, status, revision, update time, and chart version. You can filter with flags like --namespace and --all-namespaces, and by default it excludes uninstalled releases.

A `maxSurge` value of 1 correctly indicates that exactly one pod may be created above the desired replica count during a rolling update. This allows the Deployment controller to bring up a new pod before terminating an old one, reducing downtime while keeping the surge limited to a single extra pod. Kubernetes interprets this as an absolute number, so the controller ensures the total pod count never exceeds `replicas + 1` during the update.

This is the precise imperative command to add an annotation to a Pod object in the cluster. `kubectl annotate pod my-pod key=value` directly updates the `metadata.annotations` map of the specified Pod, and the change is immediately visible to the API server. This approach works for any Pod, but it is especially appropriate when the Pod is statically created or when you intentionally want to modify only the live object. For controller-managed Pods, remember that this change is ephemeral — if the Pod is recreated by its Deployment or ReplicaSet, the annotation will be lost unless the Pod template is also updated.

helm history frontend --namespace web is the correct command to display the full revision history for the release named 'frontend' in the 'web' namespace. It outputs a table with each revision number, the chart and app version used, the status (e.g., superseded, failed, deployed), a description of the action (install, upgrade, rollback, or test), and the timestamp of the operation. This provides an audit trail that lets you verify when changes occurred, investigate unexpected behavior, and choose a revision for potential rollback, making it the appropriate command for the question.

This is the textbook blue-green cutover. By changing the Service's selector to 'app: myapp, version: green', the Service will match only the pods belonging to the green Deployment, since those pods carry both labels. The blue pods remain running but are no longer selected, so all incoming traffic is instantly redirected to the green version. This is a declarative, reversible change that requires no pod restarts, making it the simplest and standard approach.

This is the exact definition. During a rolling update, the Deployment controller ensures that at most maxUnavailable pods (default 25% of desired replicas, rounded to an integer) are out of service at any moment. It gives you control over the trade-off between update speed and service availability, allowing you to keep most of your workload serving traffic while the rest are replaced. This setting is evaluated continuously, so even if one pod fails to become ready, the controller pauses further changes to maintain the unavailability limit.

With the Recreate strategy, the Deployment controller first scales the old ReplicaSet to zero, ensuring all existing pods are terminated and removed. Only after all old pods have reached a terminated state does it scale up the new ReplicaSet, creating replacement pods. This guarantees that there is no overlap between old and new pod versions during the update.

Using `--set replicaCount=5` is the correct and idiomatic way to override a single chart value from the CLI. Helm parses the value using YAML type inference, so `5` is interpreted as an integer, which aligns with the expected type for a Deployment's `replicas` field. This avoids the need to create a separate values file and gives the highest precedence among value sources, taking precedence over the chart's default `values.yaml` and any `-f` files. The `--set` flag also supports comma-separated key/value pairs and complex structures with dots.

With a Deployment of 4 replicas and the default rolling update strategy, maxUnavailable is 25% of 4, which equals 1 (Kubernetes rounds up for maxUnavailable). This means at any point during the rollout, at most one Pod can be taken down or become unhealthy, so at least 3 replicas remain available to serve traffic. Thus the minimum guaranteed availability is 3, not 2 or 4.

kubectl rollout resume deployment/app is the correct command because it exits the paused state created by `kubectl rollout pause`, allowing the Deployment controller to proceed with the current rollout revision. When a rollout is paused, the controller stops creating new ReplicaSets or scaling them until resumed; this command explicitly tells the controller to continue reconciling the desired state, picking up any pending changes that occurred during the pause.

The 'resources' field is a foundational Kustomize feature that declares all the YAML manifests (files or directories) to be included in the final rendered output. These resources can be local files, remote URLs, or other kustomization directories, and Kustomize will merge, patch, and transform them according to the other directives in kustomization.yaml. Without 'resources', a kustomization has nothing to process, making it the core entry point for defining what your application consists of.

Running kubectl rollout restart patches the Deployment's pod template with a kubectl.kubernetes.io/restartedAt annotation, creating a new ReplicaSet revision. Because volume-mounted ConfigMaps are refreshed asynchronously but the app reads only at startup, restarting pods forces them to load the new values. The old ReplicaSet is retained, so kubectl rollout undo remains available for rollback.

RollingUpdate is the default Deployment strategy, which replaces old pods with new ones incrementally to maintain availability. It uses two parameters: `maxSurge` (number of extra pods allowed above desired count) and `maxUnavailable` (number of pods allowed to be down during update). This strategy is ideal for stateless applications that can tolerate multiple versions running briefly during the rollout.

Keeping the Service selector as 'app: myapp' while setting canary replicas to 1 and stable to 9 ensures that both Deployments' pods match the selector. The Service then performs round-robin or random load balancing across all matching endpoints, so traffic is distributed proportionally to pod counts—approximately 10% to canary and 90% to stable. This is the correct method because it uses the natural endpoint-count-based weighting of a Service without introducing label restrictions that would isolate one version.

Adding the 'version: canary' label to the canary pod template and updating the Service selector to a set-based requirement (version in (stable, canary)) allows the existing Service to include both stable and canary pods in its endpoints. Kubernetes Services load-balance across all ready endpoints, so traffic is distributed proportionally to the replica counts of each Deployment. You can then carefully scale the canary Deployment up to increase its traffic share, making this a native, controlled canary strategy.

The serviceName field binds the StatefulSet to a headless Service, giving each pod a stable DNS name like db-0.db-headless. volumeClaimTemplates creates a PersistentVolumeClaim per replica, named by combining the template name with the pod name, so storage is dedicated and persists across rescheduling. Together these provide the stable identity and per-pod storage the application needs.

This is the correct command. 'kubectl rollout status' tracks the lifecycle of a Deployment's rollout (or DaemonSet/StatefulSet) in real time, blocking until the desired number of pods are available. It prints progress messages such as 'Waiting for deployment spec update to be observed' and 'deployment "mydeployment" successfully rolled out', and its exit code indicates success or failure, making it ideal for scripted CI/CD pipelines.

`kubectl rollout undo deployment/myapp` is the correct way to revert a Deployment to its previous revision. It inspects the Deployment's rollout history (stored in the ReplicaSets it manages), identifies the most recent revision's pod template, and creates a new ReplicaSet with that template while scaling down the current one—effectively undoing the last change. This is a standard, safe operation that preserves rollout history and can be repeated to continue stepping backward.

Leaving ttlSecondsAfterFinished unset is the correct way to ensure the Job and its Pods remain after completion. By default, the Kubernetes Job controller does not automatically delete finished Pods or the Job object; they stay in the cluster indefinitely until a human or an automated process removes them. This gives the developer time to inspect the Pod's logs, output files, or status, which is exactly what is needed for a one-time batch job.

`kubectl rollout undo` is the proper remediation for a failing rollout because it instructs the Deployment controller to revert to the previous revision's pod template, creating a new ReplicaSet and scaling down the bad one. This is a mutating command that performs a rolling update, so it preserves the Deployment's UID, labels, and entire revision history, letting you redo the change later. Running undo directly is far safer than deleting and recreating with an old manifest, as it uses Kubernetes' built-in revision tracking rather than a manual, history-destroying replacement.

Executing 'kubectl rollout pause deployment' sets the deployment's .spec.paused field to true. This causes the deployment controller to stop reconciling the desired state from the deployment specification, meaning any template, image, or label changes are not propagated to the existing ReplicaSet. The current ReplicaSet and its Pods remain untouched, and the rollout is effectively frozen until 'kubectl rollout resume deployment' sets paused back to false, at which point the controller resumes applying changes.

kubectl rollout pause deployment/myapp is the dedicated imperative command for pausing a rollout. It immediately sets the deployment's spec.paused field to true, which halts any ongoing rollout and prevents any new rollout from being triggered until the rollout is resumed. This is the standard, direct method because it requires no manual manifest edits and is explicitly designed for this purpose.

Ingress controllers such as NGINX, Traefik, and HAProxy implement canary annotations (for example, nginx.ingress.kubernetes.io/canary-weight) that instruct the controller to send a specified percentage, e.g. 10%, of requests to a secondary canary Service while the rest go to the stable Service. The annotation can also be based on headers or cookies for test-specific routing. This gives a control plane at the edge to adjust weight dynamically without redeploying Services.