CCNA Cloud Native Application Delivery Questions

Helm stores each release's revision history, so `helm rollback <release-name> <revision>` redeploys a specified earlier revision, restoring its manifests and values. This directly satisfies the requirement to revert a release to a previous revision, unlike `helm upgrade`, which moves forward to a new revision.

Deployment frequency counts how often the team ships releases to production within a given period. It directly measures release cadence, distinguishing it from lead time for changes, change failure rate and mean time to restore.

Argo Rollouts queries predefined metrics such as error rate through an AnalysisTemplate, which defines the Prometheus or other provider queries and success thresholds. The controller evaluates these during the canary step and only promotes when results pass, satisfying the stem's requirement for automated success determination before promotion.

Helm stores each release revision as a numbered snapshot, so rollback restores a prior revision's rendered Kubernetes manifests and configuration. This directly satisfies the release management requirement by enabling recovery from failed upgrades without manual re-editing, reverting both the deployed resources and Helm's stored release state.

The Image Automation Controller scans image repositories and, when it detects a newly pushed tag matching policy, commits the updated image reference back to Git, which Flux then reconciles. This delivers the automatic deployment update the organisation wants.

A Git commit SHA is unique and immutable, so the same tag always refers to the same image digest. Deploying that tag makes the running version auditable and reproducible, and rolling back means redeploying a previous SHA tag. This avoids the ambiguity of latest, which can point to different images over time.

Setting maxUnavailable to 0 guarantees no old pod is removed until a replacement passes its readiness probe, while maxSurge=1 permits one extra pod above the desired replica count so the new version can start alongside the old. This directly satisfies the stem's requirement that traffic shifts only after readiness succeeds, eliminating the brief downtime.

Git stores the declarative desired state, and an automated controller continuously reconciles the live cluster towards that committed state, satisfying GitOps's requirement for a single authoritative source. This enables versioned, auditable changes and rollback via Git history, rather than imperative cluster commands.

A rolling update replaces pods incrementally, using maxSurge and maxUnavailable to keep a portion of old replicas serving traffic until new ones pass readiness checks. This satisfies the availability constraint by avoiding the downtime a recreate strategy would cause.

A CI pipeline automatically builds and tests each code change on commit, giving fast feedback on integration errors and regressions. This satisfies the stem's cloud native delivery scenario, where frequent small merges require automated verification rather than manual, release-time testing.

LaunchDarkly is a dedicated feature-management platform, streaming flag evaluations to SDKs so toggles update without redeploying pods. It satisfies the stem's cloud-native rollout constraint directly, whereas general CI/CD or service-mesh tooling lacks native flag targeting, percentage rollouts and audit trails.

The --reuse-values flag merges the previous release's computed values with the new --set overrides, satisfying the requirement to retain prior configuration while changing only image.tag. Without it, Helm would reset unspecified values to chart defaults.

Canary deployment routes a small, controlled slice of live traffic to the new version while the old version serves the remainder, then progressively shifts weight as health metrics confirm stability. This satisfies the gradual traffic-shift and zero-downtime constraints without exposing all users to risk.

ArgoCD continuously reconciles cluster state against Git, automatically applying declared manifests when drift is detected. This satisfies the stem's requirement for automated sync from Git to cluster, the pull-based GitOps mechanism ArgoCD implements natively without external CI triggers.

`helm upgrade` applies a new chart revision to an existing release, preserving its name and revision history rather than creating a fresh deployment as `helm install` would. This directly satisfies the stem's requirement to move a release to a newer chart version while retaining release identity and enabling rollback via `helm rollback`.

values.yaml holds the chart's default parameters, which templates consume at render time. Users override individual entries via their own values files or --set flags during helm install, so this file provides the overridable baseline configuration the question describes.

Kustomize's patch transformers apply strategic merge patches, which use Kubernetes merge keys to combine list items by name, or JSON patches, which use RFC 6902 operations for precise edits. This satisfies the stem's requirement for a true statement, as both patch types are core, documented Kustomize features.

A container registry stores versioned container images and serves them to nodes during deployment, which is precisely the distribution role the CI/CD pipeline requires. Build stages push tagged images; runtime environments pull them by digest or tag, satisfying the stem's demand for a dedicated artefact repository rather than a build or orchestration function.

Helm reads values.yaml to supply the chart's built-in defaults, which templates reference during rendering. Any value a user omits at install time falls back to these entries, so the file defines the chart's baseline configuration rather than per-release overrides.

An overlay is a Kustomization layered over a base, patching or adding resources so the same base yields environment-specific output such as dev or production variants. This satisfies the requirement to customise a shared base per environment.

ArgoCD is a declarative GitOps continuous delivery controller built specifically for Kubernetes. It continuously reconciles live cluster state against manifests stored in Git, automatically syncing drift back to the declared desired state, which directly satisfies the requirement for automatic cluster-to-repository synchronisation.

Helm tracks each release as a revision, so helm rollback restores the previous manifest and Kubernetes objects. This gives deterministic recovery from a failed upgrade, satisfying the benefit of reverting to an earlier working release without manual reapplication.

Kustomize applies patchesStrategicMerge to merge partial resource definitions onto base manifests, modifying only the fields specified. This strategic merge behaviour distinguishes it from templating engines, satisfying the requirement for patching existing resources without altering the originals.

Deployment Frequency directly measures how often code reaches production, satisfying the stem's requirement for a DORA metric. It belongs to the throughput axis, alongside lead time for changes, distinguishing it from stability metrics such as change failure rate and mean time to restore. Accelerate's research identifies it as a core predictor of DevOps performance.

With automated sync and self-heal enabled, Argo CD continuously compares the live cluster state to the desired state stored in Git. When it detects that the Deployment's replica count was manually changed to 5, which diverges from the Git-declared value of 3, it automatically applies the Git version, restoring the replica count to 3. This enforces Git as the single source of truth.

ArgoCD Image Updater watches the container registry and writes the new image tag back into the Git repository, letting ArgoCD's existing sync detect the change. This satisfies the stem's requirement for automatic synchronisation triggered by a registry push, without manual commits or CI pipeline edits.

The Kustomize Controller reconciles the Kustomization custom resource, fetching the Git source through the Source Controller's artefact and applying the rendered manifests to the cluster. This satisfies the stem's requirement that a Git commit changing replica count propagates without manual intervention, since the Kustomize Controller owns the apply step rather than the Source Controller.

Blue-green deployment runs two identical environments, switching traffic from the old (blue) to the new (green) only after the new version is verified. This satisfies the stem's minimal-downtime constraint because the cutover is near-instantaneous and rollback is immediate.

Canary deployment routes a small percentage of live traffic to the new version while the remainder still reaches the old one, then shifts that weighting gradually. This satisfies the stem's requirement for traffic splitting, which needs a service mesh or ingress controller to manipulate routing weights at the network layer.

Queue-based Load Leveling inserts a queue between the microservice and database, letting producers enqueue requests while consumers drain them at a controlled rate. This decouples direct database connections and absorbs traffic bursts, preventing connection pool exhaustion.

Self-healing means ArgoCD continuously compares live cluster state against the desired state declared in Git. When drift is detected, it automatically reapplies the Git version, discarding manual kubectl edits so the repository remains the single source of truth.

Change Failure Rate directly quantifies the proportion of production deployments that result in degraded service or require remediation, such as a hotfix or rollback. This precisely matches the stem's requirement to measure the percentage of deployments causing production failures, distinguishing it from deployment frequency, lead time, and mean time to restore.

Because the previous environment remains fully deployed and idle, reverting is simply a matter of repointing the router or load balancer, giving near-instantaneous rollback. This satisfies the stem's single-active-environment constraint while minimising downtime risk during release.

With auto-sync enabled, ArgoCD continuously compares the Git-declared desired state against live cluster resources and applies the difference, reconciling the cluster back to Git. This satisfies the GitOps requirement that Git remains the single source of truth.

Kustomize keeps one base directory and applies overlays that patch only the fields each environment changes, such as replicas, image tags, and resources. It uses plain YAML with no template syntax, so the shared base stays authoritative and environment differences remain explicit and reviewable.

RollingUpdate replaces pods incrementally, keeping a proportion of replicas available via maxUnavailable and maxSurge, so the Service always has ready endpoints. This satisfies the requirement to minimise downtime during updates without extra tooling or duplicate environments.

The image must first be built locally, then tagged with the private registry's repository path and version, then pushed. Tagging before pushing ensures the registry stores the image under the correct name, satisfying the private registry workflow requirement.

Helm is the Kubernetes package manager: it bundles related manifests into a chart, templates them with values, and tracks each install as a revision so rollbacks are a single command. That directly satisfies packaging, versioning, and atomic install/rollback for the described application.

OPA Gatekeeper is a Kubernetes admission controller that enforces policies at admission time. By integrating with a vulnerability scanner or using a pre-populated list of vulnerable images, it can deny Pod creation if the image has critical vulnerabilities. This enforces the policy directly in the cluster, preventing deployment regardless of the CI pipeline. It is a Kubernetes-native solution that provides a strong guardrail.

Helm packages Kubernetes resources into a chart, a versioned archive containing templated manifests, a values.yaml file for defaults, and Chart.yaml metadata. Installing or upgrading the chart renders templates with supplied values and applies them to the cluster, giving the team a single distributable artifact with a semantic version.

Helm packages Kubernetes manifests into versioned charts, enabling repeatable installs, upgrades and rollbacks of applications and their dependencies. This directly answers the stem's question of Helm's role: it manages the packaging and release lifecycle of Kubernetes applications, rather than scheduling workloads or storing images.

Failing the pipeline blocks the vulnerable image from progressing, forcing remediation of the base image before rebuild. This satisfies the stem's requirement for best practice on detecting a critical base-image vulnerability, preventing insecure artefacts reaching production.

Patches apply targeted modifications to a base resource without duplicating it, so the team can override the replica count for a specific environment variant. This satisfies the requirement of deriving an environment-specific variant from shared base configuration, keeping the base reusable while changing only the replicas field.

A versioned chart or base-with-overlays artifact lets one tested package move from dev to staging to production with only environment-specific values changing. That promotes consistency, makes the promoted revision identifiable, and shrinks the surface where environments can diverge.

Helm renders parameterised templates into concrete Kubernetes manifests, letting one chart produce environment-specific YAML through values files. This templating engine satisfies the packaging requirement by removing duplicated manifests and enabling consistent, repeatable deployments across clusters.

Setting `maxUnavailable: 25%` directly caps how many pods may be taken offline during a rolling update, satisfying the stem's requirement that no more than a quarter be unavailable at once. It works alongside `maxSurge` to control update pacing, and belongs under `strategy.rollingUpdate` in the Deployment spec.

Feature flags let operators disable faulty code paths at runtime, restoring service without redeploying or rolling back artefacts. This directly shortens the time between failure detection and recovery, satisfying the MTTR improvement by removing the build-and-deploy delay from remediation.

A registry stores and versions container images, letting pipeline stages pull the exact artefact for deployment. This satisfies the stem's deployment need: the built image is pushed once, then retrieved by orchestrators, decoupling build output from runtime hosts.

Signing images at build time and verifying signatures at admission ensures only artefacts produced by trusted pipeline identities reach the cluster, blocking tampered or substituted images. This satisfies the supply-chain integrity requirement of a secure cloud-native CI/CD pipeline.

A Job runs Pods to completion and is designed for finite tasks like migrations. Setting restartPolicy to OnFailure lets the container retry on failure, and backoffLimit caps retries before the Job is marked failed. Completion status can gate the application rollout, ensuring the migration succeeds before new code starts.

Continuous delivery stops short of production, requiring a manual approval gate before release; continuous deployment removes that gate and pushes every passing change automatically. This distinction satisfies the stem's requirement to differentiate the two practices by their production approval step.

Cryptographic signing with tools such as Cosign or Notation attaches a verifiable signature to the image digest, letting the admission controller reject tampered or unsigned artefacts before deployment. This satisfies the stem's integrity requirement, ensuring only images built by the trusted pipeline are admitted to the cluster.

Helm is the package manager for Kubernetes, designed to template manifests using values files and manage releases with versioning, rollback, and atomic upgrades. It allows teams to define a chart with templates and override values per environment, exactly matching the requirement for environment-specific values and release management. Other tools may assist with deployment but do not provide Helm's integrated packaging and release lifecycle.

Deployments manage ReplicaSets to perform rolling updates, replacing pods gradually while maintaining availability, and retain revision history so `kubectl rollout undo` can revert to a prior ReplicaSet. This satisfies the stem's requirement for both update and rollback capability, unlike bare pods or standalone ReplicaSets.

The `range` action in Helm templates iterates over a collection, such as a list of service definitions in values.yaml, and renders the enclosed template block for each item. This eliminates duplicate YAML by generating ConfigMap, Deployment, and Service resources dynamically. The values file supplies per-service data like name and image tag, and the chart templates reference those values with `.` inside the loop, producing one set of manifests per service entry.

Automatically building and testing each commit delivers the rapid, early feedback that CI exists to provide, catching integration defects before they reach later stages. This directly satisfies the stem's focus on the primary purpose of continuous integration within a cloud-native delivery pipeline, distinguishing it from continuous delivery or deployment concerns.

Helm's templating engine parameterises Kubernetes manifests, letting one chart render environment-specific YAML from values files rather than duplicating manifests per cluster. This directly satisfies the scenario's need to manage applications across differing environments, since Go templates inject variables at install time and reduce configuration drift between deployments.

Setting `commonLabels` in `kustomization.yaml` makes Kustomize inject the specified labels into every resource's metadata during the build, satisfying the requirement to label all base resources uniformly. Kustomize applies this transformation automatically across the entire base, so no per-resource edits are needed.

Lead time for changes measures the elapsed time from code committed to code successfully running in production, directly quantifying deployment speed. Deployment frequency counts how often releases occur, while MTTR and change failure rate address stability rather than velocity.

Canary releases route a small percentage of live traffic to the new version, so real users exercise the feature before full rollout. This directly satisfies the stem's requirement to test with a subset, limiting blast radius and enabling fast rollback if metrics degrade.

Argo CD continuously reconciles live cluster state against manifests held in Git, detecting and reverting drift automatically. This declarative pull-based reconciliation is precisely the GitOps guarantee the company requires: cluster state always matching the desired state defined in the repository.

Flux ships several purpose-built controllers, and the Helm Controller is one of them, reconciling HelmRelease custom resources to install and upgrade charts declaratively, which is a core component of the GitOps toolkit alongside source, kustomize and notification controllers.

Scanning during CI catches known CVEs in base images and dependencies before the image reaches a registry, letting the pipeline fail the build and block promotion. This satisfies the stem's CI-phase constraint: remediation happens pre-deployment, so vulnerable artefacts never reach production clusters.

Feature flags decouple deployment from release, letting operators enable or disable functionality at runtime for specific users or cohorts. This satisfies progressive delivery's requirement to expose changes to a subset first, so impact can be observed before full rollout.

Argo Rollouts provides a Kubernetes controller and custom resources that automate canary progression, shifting traffic in weighted increments and analysing metrics before promotion. This satisfies the stem's requirement for a tool specifically designed for progressive delivery, unlike standard Deployments, which only support rolling updates without metric-driven canary automation.

Self-heal is a sub-feature of automated sync that reverts manual changes to the cluster, ensuring the live state always reflects Git. Without self-heal, manual edits could persist, causing drift. Configuring self-heal ensures that any out-of-band modifications are automatically corrected, which is essential for the team's goal of continuous state matching.

The Kustomize controller continuously reconciles cluster state against Kustomization manifests sourced from Git, applying declared resources and pruning drift. It satisfies the stem's requirement for the component that pulls the source of truth from Git and enforces it, rather than merely building manifests or serving artefacts.

Kubernetes Deployments trigger rolling updates only when the pod template spec changes. Pushing a new image with the same tag does not modify the template, so the Deployment controller sees no difference and does not create new ReplicaSets or update Pods. Even with imagePullPolicy: Always, existing Pods are not restarted. Thus, the Deployment remains unchanged and Pods continue running the old image.

Canary deployment routes a small percentage of live traffic to the new version, then progressively increases it while monitoring metrics. This satisfies the stem's requirement to expose only a subset of users before full rollout.

Progressive delivery depends on controlling the percentage of requests reaching each version. A mesh routing rule, such as an Istio VirtualService with weighted destinations, directs a small share of traffic to the canary while the rest goes to the stable version. Without this split, all traffic hits one version and no gradual exposure occurs.