CCNA Ckad Deployment Questions

spec.metrics is a list of metric specifications in the autoscaling/v2 HPA API. It defines one or more metrics (resource, container resource, external, or object/pods) that the controller evaluates when computing the desired replica count. Each entry includes a type and target, such as AverageUtilization for CPU. This field replaces v1's single CPU metric, enabling multi-metric scaling where the largest resulting replica count wins.

Since both Deployments carry the same labels expected by the Service, their Pods are all included in the Service's endpoints. By gradually increasing the replicas of app-v2 while decreasing app-v1, you change the ratio of v2 Pod IPs to v1 Pod IPs in that endpoint list, and kube-proxy's round-robin load balancing naturally sends a corresponding proportion of traffic to each version. This gives you a gradual, reversible canary progression that you can manually control or script based on metrics.

A Service provides a stable virtual IP (ClusterIP) and a DNS record via the cluster's internal DNS (e.g., <service>.<namespace>.svc.cluster.local), so clients can resolve the backend without knowing individual Pod IPs. It uses label selectors to identify target Pods and load-balances traffic across them, which is precisely what this microservice needs for reliable internal reachability. This is the standard Kubernetes abstraction for service discovery within a cluster.

helm install myrelease stable/nginx creates a new release named 'myrelease' by resolving the chart reference 'stable/nginx' from your configured repositories, rendering its templates, and applying the resulting Kubernetes manifests to the cluster. This command performs the actual first-time deployment, which is exactly what the question asks for. Without a prior release, this is the only valid way to install a chart from a repo.

Altering the Service's label selector to match the green Deployment's pod labels is the canonical blue-green traffic switch. Because the Deployment labels are immutable to the selector only after the fact, you simply retarget the Service to the already-running and ready green pods, instantly moving all traffic without redeploying anything. This provides zero-downtime shifting and makes rollback trivial by reverting the selector to blue.

values.yaml is the central place where chart authors define default configuration values in key-value form, such as replica counts, image tags, or service ports. When a user installs the chart without specifying overrides, Helm uses these defaults to render the templates, but the defaults can be overridden at install or upgrade time using --values or --set flags. This design keeps templates reusable and lets users customize a chart without editing its source.

kubectl apply is a declarative command that merges the changes from the provided updated-deployment.yaml into the live Deployment object. It calculates a patch based on the difference between the new file and the existing object, then updates only the modified fields, such as the container image. This is a valid, recommended approach because the file represents the complete desired state, and apply also records the applied configuration for future three-way merges.

Ingress is the correct choice because it acts as a cluster-level HTTP(S) reverse proxy that exposes the web application to the internet while providing SSL/TLS termination, name-based virtual hosting, and path-based routing rules. An Ingress controller (such as NGINX or Traefik) reads Ingress resources and configures the proxy accordingly, allowing the web app to use a single external endpoint with a secure HTTPS listener. This matches the requirements precisely: external access, SSL termination, and routing are all natively supported by the Ingress API.

A Job is the Kubernetes workload designed for run-to-completion tasks. Its pod template must specify restartPolicy Never or OnFailure, and backoffLimit governs retry attempts on failure. Once the container exits successfully, the Job marks completion and does not restart the pod, which matches the requirement that the batch process complete exactly once.

maxSurge is a valid field within the `rollingUpdate` configuration. It specifies the maximum number of pods (or a percentage of desired pods) that can be created above the desired replica count during an update. This controls how quickly the Deployment can add new pods while maintaining available capacity, and it works together with maxUnavailable to define the update's pace.

values.yaml is the default source of user-supplied configuration for a Helm chart. During chart rendering, the template engine merges values.yaml with any --set or -f overrides, and the resulting object is exposed as .Values in Go templates.

kubectl apply performs a merge-patch on an existing object's desired state, so it can seamlessly update a resource that already exists in the cluster, whereas kubectl create sends POST requests to the API server and receives an AlreadyExists error if the resource is present. This distinction is fundamental: create is for initial provisioning only, while apply is idempotent and safe to run multiple times, making it ideal for declarative configuration management in CI/CD pipelines.

This is the dedicated command for viewing rollout history. It lists revisions (e.g., 'REVISION CHANGE-CAUSE'), showing each revision number and the change cause (if annotations are set). It reads the revision history stored in the Deployment's ReplicaSets. This command is specifically designed for that purpose.

`spec.strategy.rollingUpdate.maxSurge` is the correct field because it directly controls the maximum number of pods that can be created above the desired `replicas` value during a rolling update. It allows the Deployment to temporarily overshoot the steady-state replica count to ensure new pods become ready before old ones are terminated, thereby maintaining capacity. For example, `maxSurge: 1` permits one extra pod beyond the desired count, while `maxSurge: 25%` allows a percentage-based overshoot.

The `kubectl rollout history deployment app` command is the dedicated subcommand that displays the rollout history for a Deployment, showing an ordered list of revisions, each with its revision number and, if specified, the change cause from the `kubernetes.io/change-cause` annotation. This output directly reveals how the Deployment has evolved over time, making it the correct choice for viewing rollout history. Additionally, you can use the `--revision` flag to inspect a specific historical revision's detailed configuration.

This is a valid use case for HPA, implemented through custom metrics. By exposing HTTP request counters from the application (e.g., via Prometheus) and registering a custom metrics adapter, HPA can query a metric like `http_requests_per_second` and scale replicas proportionally. The `autoscaling/v2` API allows referencing this custom metric via the `type: Object` or `type: Pods` metric source, making request-driven scaling a common real-world pattern.

The correct value is 1 because maxSurge is defined as the number of additional pods that can be created above the desired replica count during a rolling update. Setting maxSurge=1 means that while updating, the deployment may temporarily run one extra pod beyond the desired replicas, ensuring that new pods are available before old ones are terminated, thereby maintaining service availability without exceeding a small, controlled increase in resources.

`kubectl apply -k overlays/production/` is the correct declarative approach because the `-k` flag tells kubectl to treat the directory as a kustomization root, build the resource set defined in `kustomization.yaml`, and send the resulting resources to the API server for apply. It is a single command that natively leverages the kustomize build process inside kubectl, exactly matching the requirement to use kustomize to patch a deployment. This is the canonical way to apply an overlay in modern kubectl without extra tools or piping.

`helm upgrade --dry-run` is the right choice because it previews the exact changes that an upgrade to `my-release` would apply by rendering the new templates and performing a three-way merge between the last release manifest, the live cluster state, and the desired chart output. It shows a diff of what will be created, updated, or deleted—without actually touching the cluster—so you can catch template errors, missing values, or resource conflicts. Unlike `install`, this command targets the existing release, making it the standard tool for safe upgrade validation.

The correct scale-down timing is 300 seconds because the HorizontalPodAutoscaler always applies the scale-down stabilization window before reducing replicas. This window, defaulting to 300 seconds, prevents the controller from reacting to short-lived CPU drops that might be transient, ensuring that the number of pods is only decreased after the low utilization is consistently observed. Once the stabilization window has passed, the HPA reevaluates the desired replica count and performs the scale-down.

The kubectl rollout undo deployment <name> command reverts a Deployment to its previous revision by scaling down the current ReplicaSet and scaling up the prior ReplicaSet according to the stored rollout history. This updates the pod template to the old spec, effectively reversing the changes made by the rolling update. Use --to-revision to target a specific revision, otherwise it selects the last available revision.

Setting behavior.scaleDown.stabilizationWindowSeconds configures the HPA to remember the desired replica counts from the last N seconds and, when scaling down, to use the maximum of those historical values instead of the newest recommendation. This creates the cooldown effect: after CPU utilization falls, the controller will not immediately shrink to the new lower desired count; it will only step down once the higher value ages out of the window. This prevents rapid, oscillating scale-downs during transient load dips and is exactly the field needed to avoid premature replica reduction.

This is the correct definition. The maxUnavailable field in a Deployment's rolling update strategy sets the maximum number of Pods that can be unavailable relative to the desired replicas during the update process. It guarantees that a sufficient number of Pods remain running to serve traffic, with the default of 25% ensuring at least 75% availability.

Correct because maxSurge: 5 allows up to 5 extra pods, and maxUnavailable: 2 allows up to 2 unavailable, matching the requirement.

kubectl scale deployment nginx --replicas=5 is the correct command because the scale subcommand directly adjusts the desired replica count for a Deployment, updating spec.replicas in the live object. It also accepts optional flags like --current-replicas to perform optimistic concurrency checks and --timeout to wait for the scale operation to complete. This is the standard imperative way to resize a Deployment's pod count in Kubernetes.

When you run kubectl rollout undo with no flags, Kubernetes automatically selects the last available revision from the workload's rollout history and applies that configuration to replace the current pod template. This is a single-step revert that undoes only the most recent change, leaving older revisions untouched. If you need to return to an earlier state, you must explicitly specify --to-revision.

With the Recreate update strategy, the Deployment controller first terminates all existing Pods from the old ReplicaSet, then creates the new Pods from the updated ReplicaSet. For replicas: 3, all three old Pods are shut down before any new Pod is scheduled, resulting in a complete but brief period of unavailability. This is the correct behavior of Recreate.

kubectl describe pod displays the pod's full specification in a human-readable format, including each container's livenessProbe, readinessProbe, and startupProbe with their exact HTTP paths, ports, initialDelaySeconds, periodSeconds, failureThreshold, and timeoutSeconds. It also surfaces recent events, such as 'Liveness probe failed,' which directly indicate why the pod is unresponsive. This is the definitive command for inspecting probe configuration and diagnosing probe-related responsiveness issues.

helm ls is correct because it is a built-in alias for the `helm list` command, which enumerates all deployed Helm releases in your current Kubernetes namespace. When run, it queries Helm's release storage (typically Secrets or ConfigMaps) and displays a table with release name, status, revision, and chart details. The shorthand form is widely used in scripts and everyday operations, making it a convenient equivalent to the command that the question asks about.

StatefulSet is the correct controller because it assigns each pod a stable, ordinal hostname (e.g., db-0, db-1) backed by a Headless Service, so cluster members can discover each other deterministically. Its volumeClaimTemplates provision a unique PersistentVolumeClaim for every replica, ensuring data survives restarts. StatefulSet also supports ordered, graceful deployment and scaling, which matches the initialization and quorum requirements of stateful databases.

A Job creates one or more pods and tracks them until a specified number of successful completions are reached, which exactly matches the semantics of a batch operation. The Job controller uses a restart policy of Never or OnFailure, and it implements backoff limits, active deadlines, parallelism, and completion counts to govern how failed pods are retried. This allows the developer to express 'run this container once' and have Kubernetes guarantee the task eventually ends in a completed state, or fail according to policy. Hence, for a container that runs a batch job and exits, Job is the correct workload controller.

kubectl rollout restart deployment/<name> is correct because it modifies the pod template's annotation (spec.template.metadata.annotations) without changing container images, forcing the Deployment controller to create a new ReplicaSet and perform a rolling update. New pods are scheduled with the patched template and therefore mount the latest ConfigMap data at container start, while old pods are terminated gradually. This is the recommended declarative way to reload configuration changes with zero downtime and full rollout history.

kubectl rollout status deployment/web-app attaches to the Deployment's status and blocks until the rollout reaches completion, printing progress messages like 'Waiting for deployment spec update...' and finally 'deployment "web-app" successfully rolled out'. It returns a non-zero exit code if the rollout times out or fails, making it the canonical command for checking rollout success. It also supports a `--timeout` flag to bound the wait, which is essential in scripts and CI pipelines.

This command is correct because it imperatively modifies the container's image using the syntax `deployment/<name> <container>`=`<new-image>`. It directly patches the live Deployment object and triggers a rollout if the pod template changes. It is the most concise and readable way to update an image for a single Deployment, which is why it is commonly used in CI/CD pipelines.

The correct sequence is `kubectl rollout resume` to unpause the deployment, letting the deployment controller continue the rolling update from where it left off, followed by `kubectl rollout status` to poll the rollout until it completes or reports an error. The status command blocks until the rollout condition is successful, giving immediate and accurate feedback on the health of the deployment. This directly addresses the user's intent: resume the paused deployment and confirm it reaches the desired state.

This is correct: 'kubectl apply' provides declarative management—it creates a resource if absent and updates it if present by calculating a PATCH based on the object's live state and its stored last-applied configuration. 'kubectl create' is imperative and only performs an initial POST, failing with an error if the resource already exists. Because 'apply' knows the last-applied state, it supports partial updates, while 'create' does not.

`helm list` is the canonical Helm verb for enumerating releases in the current Kubernetes namespace. It queries Helm's stored release records (Secrets/ConfigMaps tagged with helm.sh/release.v1) and displays columns for release name, status, chart version, app version, and namespace, with options like `--all-namespaces` (`-A`) to expand scope and `--short` to print names only. Without `-A`, it respects the default namespace from kubeconfig or the `--namespace` flag.

Ingress controllers such as NGINX Ingress expose canary-specific annotations (e.g., nginx.ingress.kubernetes.io/canary-weight) that allow precise, percentage-based traffic splitting between two backend Services, while a service mesh like Istio provides similar fine-grained control through VirtualService and DestinationRule resources. This approach operates at the L7 routing layer, so it can deterministically send exactly 10% of requests to the canary version instead of relying on heuristics like replica counts or connection persistence.

Helm's upgrade subcommand follows the positional contract `helm upgrade [RELEASE] [CHART]`, so `myapp` is the release being upgraded and `./mychart` is the chart to deploy. The `--values prod-values.yaml` flag (or `-f`) passes the production overrides file, which is merged into the release's configuration. This is the exact, minimal, and idempotent command for upgrading an existing release named `myapp` from the local chart directory using the specified values file.

kubectl replace with an updated YAML file is a declarative update: it submits the entire Deployment manifest to the API server, replacing the existing resource representation. This is a valid method because the file contains the new image, and the server applies it atomically. It differs from set image in that you must provide a full manifest rather than a targeted field change.

This command reverts the Deployment to its previous revision, making the prior pod template the current desired state. It works by creating a new ReplicaSet from the last configuration and using the rolling update strategy to replace the current ReplicaSet, thereby undoing the most recent rollout.

When you run kubectl apply -k overlays/production, kustomize reads the kustomization.yaml in that overlay directory, which typically lists the base directory as a resource. It then merges the base resources with overlay-specific patches, strategic merge patches, name prefixes, labels, or namespace changes, producing a single unified manifest set. This rendered output is sent to kubectl apply, which creates or updates the live cluster objects accordingly.

When memory and CPU requests are set identically to their limits, the pod belongs to the Guaranteed QoS class, which is the only class with the highest eviction priority. The node reserves exactly 2Gi of memory and 500m of CPU for scheduling, while the runtime caps actual usage at those same values, preventing memory overcommit and making the pod's resource behavior completely predictable. This matches the stated 2Gi requirement and ensures the application is never silently granted less or allowed to escape its quota.

kubectl rollout history deployment/myapp is the dedicated command for displaying the rollout history of a Deployment. It lists each revision number, the change-cause annotation (if set), and the revision timestamps, directly derived from the underlying ReplicaSets created by the Deployment controller. This command provides a concise, numbered table that lets you compare revisions and identify which revision to roll back to, making it the correct and most direct way to see revision numbers in a deployment.

5 is correct because with a desired replica count of 4, the 25% maxSurge rounds up to exactly 1 additional pod. This brings the total possible pods during the rollout to 5 (4 desired + 1 surge), enabling the Deployment to create the new pod before scaling down the old ReplicaSet, thereby preserving availability.

This is a valid blue-green pattern that uses two dedicated Services, one for each version, with an Ingress as the traffic switch. Initially the Ingress backend points to the blue Service; after the green version is fully tested and ready, you update the Ingress to route traffic to the green Service. This gives you a stable network endpoint for each environment and lets you roll back instantly by reverting the Ingress backend to blue. It is technically sound and demonstrates a clean separation between routing and application lifecycle.

kubectl describe deployment mydeployment gives a detailed multi-section view that includes the Annotations block, notably the deployment.kubernetes.io/revision annotation, which records the current rollout revision. It also lists ReplicaSet names under the Status section and surfaces Events that document previous scaling or update actions, giving a narrative of the rollout history. This makes it a valid, though less structured, way to view rollout history information compared to the dedicated rollout history command.

In Helm, values.yaml is a YAML file that supplies configuration defaults, and replicaCount is a conventional top-level scalar key (type integer). It is accessed in deployment templates via {{ .Values.replicaCount }} to set the replicas spec. This is valid because values.yaml accepts any YAML primitives, and Helm later merges this value with user-provided overrides such as --set replicaCount=5.

The Service selector must include a label common to both Deployments—such as app: myapp—so that its endpoints automatically include pods from the stable and canary versions. Once the Service selects both sets of pods, Kubernetes round-robins requests across all available endpoints, and the proportion of traffic to each version roughly equals the ratio of ready pod counts (e.g., 9 v1 pods and 1 v2 pod for ~10% canary traffic). This shared-label selector is what enables a simple, replica-count-based canary without external traffic-weighting tools.

`kubectl rollout undo deployment <name>` is the canonical rollback command: it instructs the Deployment controller to scale down the current ReplicaSet and scale up the ReplicaSet from the previous revision, thereby restoring that prior pod template (image, env, labels, etc.). The controller then performs a normal rolling update to converge the Deployment to that older spec, and the revision history is updated accordingly. This is the safest automated method because it relies on the Deployment's revision tracking rather than on hand-crafting a manifest.

`patchesStrategicMerge` is the designated Kustomize feature for overlaying partial YAML onto a base resource with Kubernetes-aware merge semantics. For a Deployment, a patch that adds a container with a new name under `spec.template.spec.containers` gets appended to the existing container list because that field uses `name` as its merge key. This lets you inject a sidecar without rewriting the whole manifest. It is specifically listed as the correct answer because it's the standard way to perform structural list modifications like adding containers.

Overlays layer environment-specific patches on top of a shared base, letting one set of manifests serve development, staging and production without duplication. This directly satisfies the stem's requirement that overlays customise resources per environment, since each overlay directory supplies only the differing values while inheriting the base.

This is the defining behavior of the Recreate strategy: when a Deployment's pod template changes, the controller sets the old ReplicaSet's desired replicas to zero, waits for all existing pods to terminate, and only then scales up the new ReplicaSet. This guarantees zero overlap between old and new versions, at the cost of complete downtime during the rollout. It is correct because the rollout is strictly sequential, never concurrent.

spec.strategy.rollingUpdate.maxUnavailable is correct because it sets the maximum number of pods that can be unavailable during a rolling update, relative to the desired replica count. It ensures a specified number of pods remain available to serve traffic while new pods come up. Tuning this value directly controls the trade-off between update speed and service availability, which is exactly what the question asks about.

This is the canonical blue-green deployment pattern in Kubernetes. You run two identical Deployment resources (one for the current 'blue' version, one for the new 'green' version) and a single Service that exposes them. By changing the Service's spec.selector to match the labels of the green Pods, you atomically shift production traffic from one version to the other, enabling zero-downtime releases and instant rollback by re-pointing the selector back to blue.

The `kubectl scale` command is the correct, direct way to adjust the desired replica count for a Deployment. By setting `--replicas=5`, it updates the `spec.replicas` field in the Deployment's spec, causing the ReplicaSet controller to create or terminate Pods to reach exactly five replicas. This is an imperative, one-time change that does not register a separate autoscaling policy.

Annotations hold non-identifying metadata that Kubernetes never uses for scheduling or selection. Recording the deploying CI/CD tool's name is purely informational, so it fits an annotation rather than a label, which must remain queryable and short.

spec.replicas is the correct field because it lives directly under the Deployment's top-level spec and defines the desired number of running pod replicas. The Deployment controller ensures the current number of pods matches this value by creating or deleting ReplicaSets, and it is optional; if omitted, it defaults to 1.

In the Recreate strategy, the Deployment controller first terminates all existing pods by scaling the old ReplicaSet down to 0, and only after all old pods have been deleted does it create new pods by scaling up the new ReplicaSet. This guarantees there is never a period where old and new versions run concurrently, but it also means the application experiences full downtime during the switch. The sequence is deliberate: scale down must complete before scale up starts.

helm list queries the configured Helm storage backend (typically Secrets in the target namespace) and returns every installed release in the current namespace by default, displaying the release name, chart, app version, revision, and status. It is the standard command to enumerate releases; adding the -A or --all-namespaces flag widens the search across all namespaces.

Blue-green deployment is implemented by two separate Deployments, one labelled as blue (current) and one as green (new), with a single Service whose selector is initially set to match the blue pods' labels. After the green Deployment is fully rolled out and verified, you update the Service's selector to point at the green pods, which instantly changes the traffic destination for all clients without any downtime. This gives you a fast, atomic switchover and an equally fast rollback by reverting the selector, because both versions remain running throughout the process.

A kustomization.yaml file is the mandatory entrypoint for every Kustomize directory; without it, kustomize build fails because Kustomize has no manifest of resources, transformers, or patches to process. This file declares the resources list and any customization directives, and it must be named exactly kustomization.yaml (or kustomization.yml) for the directory to be recognized as a valid Kustomize target.

kubectl apply is declarative: it stores a `last-applied-configuration` annotation, computes a patch against the live object, and performs a three-way merge so changes made by other controllers are preserved, while fields you explicitly removed are deleted. kubectl replace reads the entire YAML/JSON you supply and submits it as the new full object definition, overwriting the live resource outright without merging or reconciling differences with the current state.

When the average CPU utilization across the current pods is above the target value, the HPA controller calculates a desired replica count using the formula `ceil(currentReplicas * (currentMetric / desiredMetric))`. Since the ratio is greater than 1, it produces a response that increases `spec.replicas` on the target workload. This is the exact behavior expected: scale-out to reduce the per-pod CPU load to the configured target. The controller will gradually raise the replica count, subject to the `maxReplicas` limit.

With maxSurge set to 1, Kubernetes is allowed to create one extra pod above the desired replica count during a rolling update. Since the deployment's desired count is 4, the absolute maximum number of pods that can exist at any moment is 4 + 1 = 5. This surge pod ensures the new ReplicaSet can scale up before any old pods are terminated, maintaining availability throughout the update.

The patch command mutates the existing Service's selector in place, updating the label selector from version=blue to version=green. Because the Service object is not deleted, its ClusterIP and NodePort are preserved, and Kubernetes immediately reconciles the Endpoints to include the green pods and exclude blue pods. This is the canonical zero-downtime traffic shift in a blue-green deployment, as it requires no file creation and only a single atomic API call.

A service mesh such as Istio provides VirtualService and DestinationRule resources that split traffic between the stable and canary Deployments by weighted percentages, giving fine-grained, L7 control that a plain Kubernetes Service cannot achieve on its own.

helm upgrade my-release ./mychart --set key=value is the correct Helm-native way to apply new chart values to an existing release. The upgrade command compares the current release's manifests (from the last rendered chart) with the desired state rendered from ./mychart combined with the new --set key=value override, then computes and applies a Kubernetes patch to update only changed resources. It increments the release revision, updates the Helm release metadata, and preserves prior revisions so the change can be rolled back if needed.

With maxUnavailable=0, the Deployment controller guarantees that the desired 5 pods remain available throughout the update, so the available count never falls below 5. At the same time, maxSurge=1 allows at most one additional pod to be created above the desired count, capping the total at 6 (5 old + 1 new, or 5 new + 1 old). Therefore the running pod count stays between 5 and 6 for the duration of the rolling update.

`helm upgrade myapp ./mychart --set key=value` is the correct command because it tells Helm to update the existing release `myapp` using the chart at `./mychart`, while `--set` overrides the chart's default value for `key`. Helm increments the release revision, applies a calculated patch to the cluster resources, and records the new values in its history so the change can be rolled back if needed. This is the standard Helm workflow for updating an application after the initial `helm install`.

The `kubectl scale deployment api --replicas=10` command is the standard, imperative way to directly change the replica count of a Deployment. It updates the Deployment's desired state to 10 replicas, causing the ReplicaSet controller to create or remove Pods until the actual count matches the desired count. This command is explicit, concise, and explicitly designed for scaling resources, making it the correct answer.

It is the correct field because it defines how many extra pods can be created over the desired replica count during a rolling update, enabling faster rollout by ensuring new pods become ready before old ones are terminated. The default value is 25% of the desired pods, and the total number of pods can temporarily exceed the desired count by this amount.

The HPA controller watches metrics such as CPU utilisation and adjusts a workload's replica count to meet a target, scaling pods horizontally. It satisfies the requirement to match capacity to demand automatically rather than manually resizing deployments.

`spec.strategy.rollingUpdate.maxSurge` is the correct field because it explicitly caps how many Pods can be temporarily created above the desired replica count during a rolling update. It can be configured as an absolute number or as a percentage of `spec.replicas`, giving the controller permission to overshoot the target while replacing old Pods. This overshoot allows new Pods to become ready before old ones are terminated, reducing downtime. Without this field, the default value is 25%, meaning Kubernetes will not create more than 25% extra Pods beyond the replica target.