CCNA Kcna App Delivery Questions

Deployment frequency is a DORA metric that measures how often an organization deploys code to production or an operational environment.

Argo Rollouts uses metrics from a service mesh or monitoring to analyze the canary's health and decide whether to proceed.

Helm provides rollback to previous revisions, stores release history, and upgrades releases while preserving history. It does not natively do canary deployments or autoscaling.

Flux's Image Automation Controller automates updates based on image policies. It can update manifests in Git when a new image tag is found, triggering a sync.

Scale command, check pods, verify deployment, monitor rollout, and adjust resources if needed.

GitOps uses Git as the single source of truth and automatically reconciles cluster state with the repository.

The Rolling update strategy is the correct answer because it incrementally replaces old pods with new ones while maintaining application availability. In Kubernetes, a rolling update updates pods one by one (or in small batches), ensuring that a specified number of pods remain available throughout the process. This is achieved by gradually scaling down the old ReplicaSet and scaling up the new one, controlled by parameters like `maxSurge` and `maxUnavailable` in the Deployment spec.

CI automates building and testing code changes to catch integration issues early, ensuring that code is always in a deployable state.

A is correct because ConfigMaps are mounted into pods as volumes or consumed via environment variables at pod creation time. Kubernetes does not automatically propagate ConfigMap updates to running pods; the only way to pick up the new configuration is to restart the pods. A rollout restart of the deployment (e.g., `kubectl rollout restart deployment`) triggers a new ReplicaSet, which creates fresh pods that read the updated ConfigMap.

The --reuse-values flag tells Helm to reuse the last release's values and merge any provided overrides. This is the correct approach to preserve existing values while updating a specific one.

Canary deployment involves rolling out the new version to a small subset of users initially and gradually increasing traffic while monitoring for issues. This minimizes risk and provides control over the rollout.

ArgoCD provides automated sync (applying desired state from Git) and self-healing (automatically reverting configuration drift). It is not a CI tool and does not build images.

The 'helm upgrade' command upgrades an existing release with a new chart version or configuration.

Container registries store container images after they are built, allowing them to be pulled by Kubernetes clusters during deployment. They are the intermediary between CI and CD.

values.yaml provides default configuration values that can be overridden at install/upgrade time.

Kustomize overlays allow customizing a base configuration for different environments (e.g., dev, prod) by applying patches without modifying the base.

Change failure rate is the percentage of deployments that result in degraded service or require remediation.

Helm manages Kubernetes application releases as packaged charts. The `helm rollback` command allows you to revert to a previous revision of a release, which is a core benefit for safe application delivery and disaster recovery. This capability is built into Helm's release management system, which tracks each deployment as a revision with a unique version number.

Kustomize uses overlays to customize Kubernetes manifests without templating. It does not use values files or require a package manager.

ArgoCD assesses health based on Kubernetes resource status and can take actions when health degrades.

Flux's Source Controller fetches artifacts (e.g., Git repositories, Helm repos) but does not apply changes. The Kustomize Controller is the primary controller that reconciles the desired state from those sources to the cluster.

The correct sequence to create a ConfigMap from a file in Kubernetes is: first prepare the configuration file, then create the ConfigMap using kubectl create configmap, next verify the ConfigMap with kubectl get configmaps, then optionally describe it with kubectl describe configmap, and finally use it in a Pod as environment variables or volume mounts. This order ensures the ConfigMap is available and correctly configured before consumption.

ArgoCD Image Updater is the official tool to automatically update image tags in Kubernetes manifests (including Helm values) and commit changes to Git, triggering ArgoCD to sync.

Flux Source Controller fetches changes from Git; Kustomize Controller reconciles the kustomization and applies to the cluster.

Start with describe for events, then logs for errors, check resources, verify image/command, then fix and redeploy.

Blue-green and canary are deployment patterns that reduce downtime by gradually shifting traffic. Rolling update is also a pattern but the question asks for minimal downtime; blue-green and canary are specifically designed for that.

The Queue-based Load Leveling pattern uses a message queue (e.g., RabbitMQ, Amazon SQS) as a buffer between the microservice and the database. When traffic spikes occur, requests are queued and processed at a manageable rate, preventing the database connection pool from being exhausted. This decouples the service from direct database connections and smooths out bursts, directly addressing the latency issue.

Self-healing automatically reverts any manual changes made to the live cluster state back to the desired state defined in Git, ensuring configuration drift is corrected.

Change Failure Rate is the percentage of changes that result in a failure (e.g., service degradation, rollback). It is one of the four key DORA metrics.

ArgoCD detects drift and can automatically sync the cluster to match Git, enabling self-healing.

A container registry stores built container images and provides a mechanism to push and pull images. It is a central component in the CI/CD workflow for image distribution.

Overlays in Kustomize allow you to define environment-specific customizations (e.g., dev, prod) on top of a common base configuration.

The correct matches are: PersistentVolume is a cluster storage resource, PersistentVolumeClaim is a user request for storage, and StorageClass defines storage classes. Two common confusions are swapping PV and PVC definitions.

The RollingUpdate strategy is the default in Kubernetes and minimizes downtime by gradually replacing old Pods with new ones while the application remains available. It uses a configurable `maxSurge` and `maxUnavailable` parameters to control the rate of change, ensuring that a specified number of Pods are always serving traffic. This makes it ideal for startups seeking zero-downtime updates without the complexity of additional tooling or infrastructure.

First, define the deployment in a YAML file, then apply it, verify creation, check pods, and optionally expose it as a service.

The standard workflow is: build image, tag it with registry URL, then push to registry.

Progressive delivery tools enable traffic splitting, automated rollbacks based on metrics, and integration with feature flags.

Helm is a package manager that simplifies deploying and managing Kubernetes applications using charts.

The pipeline should fail so that the vulnerability is addressed before deployment, preventing insecure images from reaching production.

Helm packages Kubernetes manifests into a single chart, allowing easy installation, upgrades, and rollbacks with parameterization via values.yaml.

The OOM errors are directly caused by the increased memory usage from the larger in-memory cache, which exceeds the current 512Mi memory limit. Increasing the limit to 1Gi accommodates the new cache size while preserving resource boundaries, and a rolling update applies the change without downtime. This aligns with Kubernetes best practices of setting realistic resource limits based on application requirements.

The 'maxUnavailable' field in the rolling update strategy controls how many pods can be unavailable during the update. Setting it to 25% ensures at most 25% are down.

Reducing MTTR involves quick detection and rollback or fix of failures.

A container registry stores and distributes container images. After building and scanning, images are pushed to a registry so that deployment tools can pull them to run containers.

Reducing the CPU request of the inventory deployment to 1 CPU per pod allows the scheduler to pack pods more efficiently on existing nodes, alleviating immediate 'Insufficient cpu' and 'Insufficient memory' failures while the cluster autoscaler provisions new nodes. This approach balances short-term scheduling needs with the ability to scale the inventory service later, as requests can be adjusted upward once the cluster has more capacity.

Signing container images (e.g., using Cosign or Notary) and verifying those signatures during deployment ensures that only trusted, unmodified images are deployed, preventing supply chain attacks. This practice enforces image integrity and provenance, which is a core security requirement for cloud native CI/CD pipelines.

By default, the Deployment controller will stop the rollout if the new pods are unhealthy, and the old ReplicaSet remains running.

Continuous delivery ensures code is always in a deployable state but requires manual approval for production deployment. Continuous deployment automatically deploys every change to production without manual intervention.

Image scanning, signing, and using minimal base images are key security practices. Hardcoding credentials and running containers as root are anti-patterns.

The correct matches are: Kubernetes → Container orchestration, Envoy → Service proxy, Fluentd → Log collection. Common confusions include mixing Prometheus (monitoring) with Fluentd (logging) and CoreDNS (DNS) with Prometheus.

A readiness probe that fails (e.g., the /health endpoint does not exist in the nginx container) will cause the pod to be marked as not ready. Kubernetes removes pods with failing readiness probes from the Service's endpoints list, resulting in an empty endpoints list even though the Service selector matches the pod labels. This is a common misconfiguration where the probe endpoint is not actually served by the container.

Deployments inherently support rolling updates and rollbacks through their declarative update strategy. When you change the pod template in a Deployment, it creates a new ReplicaSet and gradually scales it up while scaling down the old ReplicaSet, ensuring zero-downtime updates. If the update fails, you can roll back to a previous revision using `kubectl rollout undo`, which reverts the Deployment to a prior ReplicaSet state.

Helm provides templating for reusable configurations and allows for easy rollback to previous releases.

Kustomize's commonLabels field adds labels to all resources, including selectors.

Argo Rollouts supports progressive delivery with features like canary, blue-green, and integration with service mesh for traffic shifting, and can be combined with feature flag systems.

Lead time for changes measures the time from code commit to running in production.

Progressive delivery reduces risk by gradual rollout and provides the ability to test new versions with a subset of users. It does not eliminate the need for monitoring nor does it replace CI/CD pipelines.

Argo CD is a declarative, GitOps continuous delivery tool specifically designed for Kubernetes that automatically synchronizes the live cluster state with the desired state defined in a Git repository. It continuously monitors the cluster and Git, applying any drift to ensure the cluster matches the repository, which is the core requirement of a GitOps workflow.

The core components of the Flux GitOps toolkit include Source Controller, Helm Controller, and Kustomize Controller. These controllers manage sources, Helm releases, and Kustomize overlays respectively. Helm (option B) is a standalone tool, and ArgoCD (option D) is a different GitOps tool.

Scanning images in CI catches vulnerabilities before the image is deployed, preventing vulnerable images from reaching production.

Progressive delivery uses gradual rollout, feature flags, and analysis to reduce risk.

Argo Rollouts is a Kubernetes controller and set of CRDs that provides advanced deployment capabilities such as blue-green and canary deployments with automated promotion and rollback.

A failed Helm upgrade usually means the Kubernetes API rejected the manifests (e.g., invalid YAML, resource conflict).