75 of 94 questions · Page 1/2 · Kcna App Delivery topic · Answers revealed
Which command is used to rollback a Helm release to a previous revision?
Why this answer
The `helm rollback` command rolls back a release to a specified revision. Option A is correct. Option B (helm upgrade) upgrades to a new version.
Option C (helm history) shows revision history. Option D (helm install) installs a new release.
In the context of DORA metrics, which metric measures how often an organization successfully releases to production?
Deployment frequency measures how often deployments occur.
Why this answer
Deployment frequency is a DORA metric that measures how often an organization deploys code to production or an operational environment.
During a canary deployment using Argo Rollouts, how does the tool determine the success of the canary before promoting it?
AnalysisTemplate runs metric queries and determines success/failure.
Why this answer
Argo Rollouts uses metrics from a service mesh or monitoring to analyze the canary's health and decide whether to proceed.
Which THREE of the following are features of Helm that facilitate release management? (Choose three.)
Helm supports rollback with 'helm rollback'.
Why this answer
Helm provides rollback to previous revisions, stores release history, and upgrades releases while preserving history. It does not natively do canary deployments or autoscaling.
An organization uses Flux with Kustomize to manage their Kubernetes applications. They want to automatically update their deployment when a new container image is pushed to the registry. Which Flux component should they use?
This controller watches for new images and updates the Git repository with the new tag, triggering a reconciliation.
Why this answer
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.
Drag and drop the steps to scale a Kubernetes Deployment horizontally into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Scale command, check pods, verify deployment, monitor rollout, and adjust resources if needed.
A team is deploying a microservice application on Kubernetes. They want to ensure that during rolling updates, the new version of the service receives traffic only after the readiness probe succeeds. However, they observe that the old pods are terminated before the new pods are ready, causing a brief downtime. Which configuration change should they make to the Deployment to prevent this?
Why this answer
Option B is correct because setting spec.strategy.rollingUpdate.maxSurge=0 and maxUnavailable=1 ensures that during a rolling update, the old pods are not terminated until new pods become ready. Option A is incorrect because it allows surge but does not guarantee readiness. Option C is incorrect because it doesn't change the update behavior.
Option D is incorrect because it adds a liveness probe, which is for restarting unhealthy pods, not for traffic shifting.
Which TWO statements about GitOps are correct?
GitOps defines desired state in Git.
Why this answer
GitOps uses Git as the single source of truth and automatically reconciles cluster state with the repository.
Which deployment strategy updates pods incrementally, replacing old pods with new ones while ensuring availability?
This is the default Kubernetes deployment strategy.
Why this answer
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.
Exam trap
CNCF often tests the distinction between deployment strategies by confusing candidates with 'Canary deployment' because it also involves gradual traffic shifting, but the key difference is that Canary does not replace pods incrementally—it runs both versions concurrently and requires external traffic routing.
How to eliminate wrong answers
Option A is wrong because a Canary deployment routes a small percentage of traffic to a new version before a full rollout, but it does not incrementally replace pods; it runs both versions simultaneously and requires traffic management (e.g., via a service mesh or ingress). Option B is wrong because a Blue-green deployment creates a completely new environment (green) alongside the old one (blue) and switches traffic all at once, rather than updating pods incrementally. Option C is wrong because the Recreate strategy terminates all old pods before creating new ones, causing downtime and violating the availability requirement.
What is the primary purpose of a continuous integration (CI) pipeline in cloud native application delivery?
CI focuses on building and testing every change.
Why this answer
CI automates building and testing code changes to catch integration issues early, ensuring that code is always in a deployable state.
A team wants to use feature flags to control the rollout of a new feature in a Kubernetes-deployed microservice. Which tool is specifically designed for managing feature flags in cloud-native applications?
Why this answer
LaunchDarkly is a feature management platform commonly used for feature flags. Argo Rollouts is for progressive delivery (canary, blue-green). Helm is a package manager.
Kustomize is for configuration management. Option A is correct.
A user reports that a ConfigMap update is not reflected in running pods. Which action should be taken to ensure pods receive the updated configuration?
Triggers new pods with updated ConfigMap values.
Why this answer
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.
Exam trap
The trap here is that candidates assume Kubernetes automatically propagates ConfigMap changes to running pods, but in reality, pods are immutable after creation and require a restart to pick up new configuration.
How to eliminate wrong answers
Option B is wrong because deleting and recreating the ConfigMap does not affect running pods; pods still reference the old data from the initial mount or environment variable injection. Option C is wrong because changing a label on the deployment does not cause pods to be recreated; labels are metadata and do not trigger a pod restart or re-read of ConfigMap data. Option D is wrong because restarting the kubelet on nodes restarts the node agent but does not force pods to re-read their ConfigMap; pods continue using the cached configuration from their initial creation.
A team uses Helm to manage their Kubernetes applications. They need to upgrade a release and want to reuse the values from the previous release while overriding a specific value. Which helm command should they use?
--reuse-values retains the previous release's values and merges the new --set overrides.
Why this answer
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.
A Kubernetes cluster runs a critical application that must be updated with zero downtime. The team wants to gradually shift traffic from the old version to the new version over a period of time. Which deployment pattern is MOST appropriate?
Canary deployment gradually shifts a percentage of traffic to the new version, allowing monitoring and controlled rollout.
Why this answer
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.
Which TWO of the following are capabilities of ArgoCD? (Choose two.)
ArgoCD syncs applications automatically or on demand.
Why this answer
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.
Which Helm command is used to upgrade a release to a newer version of a chart?
helm upgrade updates an existing release to a new chart version or configuration.
Why this answer
The 'helm upgrade' command upgrades an existing release with a new chart version or configuration.
In a Helm chart, which file is used to define default configuration values that can be overridden by users during installation?
Why this answer
values.yaml is the conventional file in Helm charts for default values. Users can override these with --set or custom values files. Option B (Chart.yaml) contains metadata.
Option C (templates/) contains Kubernetes manifest templates. Option D (charts/) contains subchart dependencies.
Which TWO statements are true about Kustomize? (Choose 2)
Why this answer
Kustomize uses a base+overlay model without templating (A). It supports patching to customize resources (B). Option C is false because Kustomize does not use templates (it's template-free).
Option D is false because Kustomize does not manage Helm charts natively. Option E is false because Kustomize does not handle traffic routing.
What is the primary purpose of a container registry in the CI/CD pipeline?
Container registries like Docker Hub, Google Container Registry, or AWS ECR store images and allow them to be pulled by Kubernetes or other systems.
Why this answer
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.
What is the purpose of values.yaml in a Helm chart?
values.yaml holds default parameters.
Why this answer
values.yaml provides default configuration values that can be overridden at install/upgrade time.
In Kustomize, what is the purpose of an overlay?
Overlays use patches to modify the base for specific environments.
Why this answer
Kustomize overlays allow customizing a base configuration for different environments (e.g., dev, prod) by applying patches without modifying the base.
A DevOps team wants to implement GitOps for their Kubernetes cluster. Which tool is specifically designed for Kubernetes GitOps and can automatically sync the cluster state with a Git repository?
Why this answer
ArgoCD is a GitOps tool that continuously monitors a Git repository and syncs the cluster state. Flux is also a GitOps tool but the question asks for a tool specifically designed for Kubernetes GitOps; both are valid, but ArgoCD is more commonly associated with the term 'GitOps'. Option A (Helm) is a package manager.
Option B (Kustomize) is a configuration management tool. Option D (Jenkins) is a CI/CD tool but not GitOps-native.
Which DORA metric measures the percentage of deployments that cause a failure in production?
Change failure rate is the percentage of deployments causing failure.
Why this answer
Change failure rate is the percentage of deployments that result in degraded service or require remediation.
Which TWO of the following are benefits of using Helm for application delivery?
Helm tracks releases and supports rollback with helm rollback.
Why this answer
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.
Exam trap
CNCF often tests the distinction between Helm's release management features and Kubernetes-native or third-party operational features, so candidates mistakenly attribute capabilities like autoscaling or canary deployments to Helm because they see Helm used in CI/CD pipelines alongside those tools.
Which TWO of the following are characteristics of Kustomize?
Kustomize supports strategic merge patches and JSON patches.
Why this answer
Kustomize uses overlays to customize Kubernetes manifests without templating. It does not use values files or require a package manager.
Which TWO statements are true about ArgoCD's health status?
Self-healing can trigger rollback if health check fails.
Why this answer
ArgoCD assesses health based on Kubernetes resource status and can take actions when health degrades.
Which THREE are examples of DORA metrics used to measure DevOps performance? (Choose 3)
Why this answer
In Flux, which controller is responsible for reconciling the desired state defined in a Git repository to the cluster?
The Kustomize Controller watches for changes in Kustomize overlays and applies them to the cluster, ensuring the cluster matches the desired state.
Why this answer
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.
Drag and drop the steps to create a ConfigMap from a file in Kubernetes into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Prepare the file, create ConfigMap, verify, describe, and use it in a Pod.
A team uses ArgoCD with a Git repository that contains Helm charts. They want ArgoCD to automatically sync when a new image tag is pushed to the container registry. Which approach should they use?
ArgoCD Image Updater monitors registries and updates the desired state in Git automatically.
Why this answer
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.
A team uses Flux with the Source Controller and Kustomize Controller. They update a YAML file in Git to change a Deployment's replica count. What describes the synchronization flow?
Kustomize Controller reconciles the source and applies.
Why this answer
Flux Source Controller fetches changes from Git; Kustomize Controller reconciles the kustomization and applies to the cluster.
Drag and drop the steps to troubleshoot a Pod stuck in CrashLoopBackOff into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Start with describe for events, then logs for errors, check resources, verify image/command, then fix and redeploy.
Which TWO of the following are deployment patterns that can be used to update applications with minimal downtime? (Choose two.)
Blue-green deploys a new version alongside the old and switches traffic after testing.
Why this answer
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.
Which deployment strategy is characterized by gradually shifting traffic from an old version to a new version of an application, often requiring a service mesh or ingress controller to manage traffic splitting?
Why this answer
A canary deployment gradually shifts traffic to the new version, allowing monitoring before full rollout. Option A (Rolling update) replaces pods incrementally without traffic splitting. Option B (Blue-green) switches traffic entirely between two environments.
Option D (Recreate) kills all old pods before creating new ones.
A microservice application is experiencing high latency during traffic spikes. The team identifies that the database connection pool is exhausted. They want to implement a pattern that helps decouple the microservice from direct database connections and smooth out traffic bursts. Which design pattern should they apply?
A message queue buffers requests, decouples services, and smooths traffic spikes.
Why this answer
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.
Exam trap
CNCF often tests the distinction between patterns that handle failures (Circuit Breaker, Retry) versus patterns that manage load (Queue-based Load Leveling), and the trap here is that candidates confuse 'smoothing traffic bursts' with 'preventing repeated failures,' leading them to pick the Circuit Breaker or Retry pattern incorrectly.
How to eliminate wrong answers
Option A is wrong because the Bulkhead pattern isolates resources (e.g., thread pools) within a service to prevent cascading failures, but it does not buffer traffic spikes or decouple from database connections. Option B is wrong because the Circuit Breaker pattern monitors for failures and opens the circuit to stop requests temporarily, but it does not smooth out traffic bursts or prevent connection pool exhaustion during spikes. Option D is wrong because the Retry pattern automatically retries failed operations, but it can exacerbate connection pool exhaustion by adding more load during traffic spikes, not decouple or level the load.
In GitOps with ArgoCD, what does 'self-healing' refer to?
Self-healing ensures the cluster state continuously matches the Git repository, undoing any drift.
Why this answer
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.
A team uses Argo Rollouts for progressive delivery. They configure a canary rollout with a traffic split of 20% to the new version. After verification, the rollout automatically increases traffic to 100%. Which Argo Rollout manifest field controls this gradual traffic increase?
Why this answer
The steps field in an Argo Rollout defines the sequence of canary steps, including traffic percentages. Option B (strategy.canary.steps) is correct. Option A (strategy.canary.trafficRouting) configures how traffic routing is done (e.g., with a service mesh).
Option C (spec.replicas) sets the total replicas. Option D (template.spec.containers) defines containers.
Which DORA metric measures the percentage of deployments that cause a failure in production?
This measures the percentage of changes that result in a failure in production.
Why this answer
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.
In a blue-green deployment strategy, at any given time, only one environment (blue or green) is active. What is the primary advantage of this approach?
Why this answer
Blue-green deployments allow instant rollback by switching traffic back to the previous environment. Option A is correct. Option B is a benefit of canary deployments.
Option C is a benefit of rolling updates. Option D is not a primary advantage.
In GitOps with ArgoCD, what happens when the desired state in Git differs from the live state in the cluster?
Auto-sync ensures cluster state matches Git.
Why this answer
ArgoCD detects drift and can automatically sync the cluster to match Git, enabling self-healing.
What is the primary purpose of a container registry in a CI/CD pipeline?
Container registries are designed to store and distribute container images, enabling deployment in Kubernetes.
Why this answer
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.
Refer to the exhibit. The deployment myapp is updated from image myapp:1.0 to myapp:2.0. During the rollout, what is the maximum number of pods that will be unavailable at any given time?
maxUnavailable: 0 ensures at least 3 pods are always available.
Why this answer
Option B is correct because the deployment strategy defaults to RollingUpdate with a maxUnavailable setting of 25% (rounded up), which for a deployment with 4 replicas allows 1 pod to be unavailable. However, the question states that during the rollout the maximum number of pods that will be unavailable at any given time is 0, which implies the deployment uses a maxSurge and maxUnavailable configuration that ensures no pods are taken down until new ones are ready—this is achieved by setting maxUnavailable to 0 and maxSurge to 1 or more, so the deployment creates a new pod before terminating an old one, guaranteeing zero downtime.
Exam trap
CNCF often tests the default rolling update behavior (maxUnavailable=25%) to trick candidates into calculating a nonzero value, but the trap here is that the question explicitly describes a scenario where no pods are unavailable, which requires recognizing that maxUnavailable can be set to 0 to achieve zero-downtime updates.
How to eliminate wrong answers
Option A (2) is wrong because it assumes a maxUnavailable of 50% or a reckless scaling behavior that would allow two pods to be down simultaneously, which contradicts the zero-downtime requirement implied by the correct answer. Option C (3) is wrong because it suggests a majority of pods could be unavailable, which would violate the deployment's desired state and is not allowed by any standard rolling update configuration. Option D (1) is wrong because while a default rolling update with 4 replicas would allow 1 unavailable pod (25% rounded up), the question's context indicates that the deployment is configured to maintain full availability, so even 1 unavailable pod is not permitted.
In Kustomize, what is the purpose of an overlay?
Overlays contain patches that customize the base for specific environments.
Why this answer
Overlays in Kustomize allow you to define environment-specific customizations (e.g., dev, prod) on top of a common base configuration.
Match each Kubernetes storage concept to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Request for storage by a user, referencing a PersistentVolume
Describes classes of storage with different QoS, backup policies, etc.
Ephemeral volume that shares a pod's lifecycle
Mounts a file or directory from the host node's filesystem
Container Storage Interface standard for pluggable storage drivers
Why these pairings
These are key storage abstractions in Kubernetes.
A startup wants to minimize downtime during application updates in Kubernetes. Which deployment strategy should they use?
Replaces pods incrementally, maintaining availability.
Why this answer
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.
Exam trap
The trap here is that candidates often confuse 'minimizing downtime' with 'risk mitigation' and pick Canary or Blue/Green, but the question specifically asks for the simplest strategy to minimize downtime during updates, which is RollingUpdate by default in Kubernetes.
How to eliminate wrong answers
Option B (Canary) is wrong because while it reduces risk by routing a small percentage of traffic to the new version, it is not primarily designed to minimize downtime during updates; it focuses on validating changes with a subset of users and often requires additional service mesh or ingress configuration. Option C (Blue/Green) is wrong because it minimizes downtime by running two full environments and switching traffic instantly, but it doubles resource costs and is not the simplest or most cost-effective choice for a startup aiming to minimize downtime without extra overhead. Option D (Recreate) is wrong because it terminates all old Pods before creating new ones, causing guaranteed downtime during the update, which directly contradicts the goal of minimizing downtime.
Drag and drop the steps to create a Kubernetes deployment using kubectl into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
First, define the deployment in a YAML file, then apply it, verify creation, check pods, and optionally expose it as a service.
A container image is being pushed to a private registry. What is the correct workflow?
This is the correct sequence.
Why this answer
The standard workflow is: build image, tag it with registry URL, then push to registry.
Which THREE of the following are key capabilities of progressive delivery tools like Argo Rollouts?
Argo Rollouts can integrate with feature flags to control exposure.
Why this answer
Progressive delivery tools enable traffic splitting, automated rollbacks based on metrics, and integration with feature flags.
What is Helm's role in Kubernetes?
Helm manages charts to define, install, and upgrade applications.
Why this answer
Helm is a package manager that simplifies deploying and managing Kubernetes applications using charts.
In a CI pipeline, image scanning is integrated to detect vulnerabilities. What is the best practice when a critical vulnerability is found in a base image?
Failing the pipeline enforces security.
Why this answer
The pipeline should fail so that the vulnerability is addressed before deployment, preventing insecure images from reaching production.
A team is using Kustomize to manage configurations for different environments. They want to create a variant of a base deployment that uses a different number of replicas. Which Kustomize feature should they use?
Why this answer
Kustomize uses overlays to customize bases for different environments. Patches are used to modify specific fields. Option B (Patches) is correct for changing replicas.
Option A (Bases) is the common configuration. Option C (Components) is a newer feature for reusable pieces. Option D (Generators) creates ConfigMaps/Secrets.
What is the primary advantage of using Helm to package a Kubernetes application?
Helm uses Go templates to allow users to inject values into manifests.
Why this answer
Helm packages Kubernetes manifests into a single chart, allowing easy installation, upgrades, and rollbacks with parameterization via values.yaml.
A financial services company runs a critical trading application on Kubernetes. The application is deployed as a Deployment with 3 replicas. Each pod exposes metrics on port 8080 and uses a ConfigMap to load configuration. Recently, after a configuration change via a ConfigMap update, two of the three pods started crashing with an out-of-memory (OOM) error, while the third pod continues to run fine. The team verified that the ConfigMap was updated correctly and that the application code did not change. The pods have resource limits set: memory limit of 512Mi and request of 256Mi. The application's memory usage before the change was around 200Mi. The new configuration increases the in-memory cache size. The team suspects the issue is related to the configuration change. What is the best course of action?
This directly addresses the OOM caused by increased cache size.
Why this answer
Option D is correct because 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.
Exam trap
CNCF often tests the misconception that scaling replicas or removing limits solves resource exhaustion, when the correct approach is to adjust resource limits to match the application's new requirements.
How to eliminate wrong answers
Option A is wrong because scaling to 5 replicas does not resolve the OOM issue; each pod still has a 512Mi limit, and the new configuration causes each pod to exceed that limit, so more replicas would just crash more pods. Option B is wrong because removing the memory limit removes a critical safeguard, risking node instability and potential OOM kills of other pods or system processes; Kubernetes requires limits for predictable scheduling and resource isolation. Option C is wrong because reverting the ConfigMap only avoids the problem temporarily without addressing the need for a larger cache; the team should adjust limits to support the new configuration rather than abandoning the intended change.
A Kubernetes Deployment is configured with 'strategy.type: RollingUpdate'. The team wants to ensure that during an update, no more than 25% of pods are unavailable at any time. Which specification should be added?
maxUnavailable sets the maximum number of pods that can be unavailable during a rolling update.
Why this answer
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.
Which TWO actions can improve the DORA metric 'Mean Time to Recovery (MTTR)'?
Feature flags allow instant disabling of problematic features.
Why this answer
Reducing MTTR involves quick detection and rollback or fix of failures.
What is the primary purpose of a container registry in a CI/CD pipeline?
Container registries store built images that can be pulled by Kubernetes or other orchestration platforms.
Why this answer
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.
Your organization runs a microservices application on a Kubernetes cluster with 5 worker nodes (each with 4 vCPU, 16GB RAM). The application consists of 20 microservices, each deployed as a Deployment with 3 replicas. Recently, after a new microservice 'inventory' was deployed with resource requests of 2 CPU and 4GB memory per pod, the cluster started experiencing pod scheduling failures. Many existing pods are in 'Pending' state with events indicating 'Insufficient cpu' or 'Insufficient memory'. The cluster has cluster autoscaling enabled (node pool ranging from 3 to 10 nodes), but new nodes are not being added quickly enough, and the existing nodes are heavily utilized. You need to resolve the scheduling failures while ensuring the inventory service can scale. Which course of action should you take?
Lowering requests improves packing and reduces pending status immediately.
Why this answer
Option C is correct because 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.
Exam trap
The trap here is that candidates may think increasing cluster autoscaler limits or setting limits equal to requests will solve the problem, but they overlook that the autoscaler cannot instantaneously add nodes and that setting limits does not free up existing resources, while reducing requests directly addresses the immediate scheduling bottleneck.
How to eliminate wrong answers
Option A is wrong because increasing the cluster autoscaler max nodes to 20 and setting a 0-second scale-up delay does not address the immediate scheduling failures; the autoscaler cannot add nodes instantly due to cloud provider provisioning latency, and the existing nodes are already heavily utilized, so pods will remain pending. Option B is wrong because setting resource limits equal to requests for all microservices does not free up resources; it only prevents bursting, which does not resolve the existing resource shortage on the nodes. Option D is wrong because deleting all pending pods and recreating them manually does not change the underlying resource constraints; the scheduler will still fail to place them due to insufficient CPU and memory on the nodes.
Which THREE of the following practices are essential for a secure cloud native CI/CD pipeline?
Ensures image integrity and authenticity.
Why this answer
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.
Exam trap
CNCF often tests the misconception that storing secrets in plain text is acceptable if the pipeline is 'internal' or 'trusted,' but the KCNA exam emphasizes that secrets must never be stored in plain text in any CI/CD configuration.
An application deployment in Kubernetes uses a Deployment object. During a rolling update, the new ReplicaSet fails to become healthy. What is the default behavior of the Deployment controller?
By default, the Deployment controller will pause the rollout, leaving the old ReplicaSet active.
Why this answer
By default, the Deployment controller will stop the rollout if the new pods are unhealthy, and the old ReplicaSet remains running.
In a CI/CD pipeline, what is the difference between continuous delivery and continuous deployment?
That is the key distinction.
Why this answer
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.
Which THREE of the following are important security practices in a container image CI/CD pipeline?
Image signing verifies the image was produced by a trusted source.
Why this answer
Image scanning, signing, and using minimal base images are key security practices. Hardcoding credentials and running containers as root are anti-patterns.
A team uses Helm to manage a complex application. They want to perform a release upgrade but keep a record of the previous release so they can roll back if needed. Which Helm command should they use?
This upgrades the release and keeps the last 5 revisions, allowing rollback. It retains history.
Why this answer
The 'helm upgrade' command with the '--history-max' flag sets the maximum number of release versions to retain. Without this flag, old versions are kept by default, allowing rollback. Alternatively, 'helm upgrade' alone maintains history; 'helm rollback' is used later.
But the question asks which command to use for the upgrade while keeping history. 'helm upgrade' naturally keeps history unless '--history-max' is set to 0.
Match each CNCF project to its primary function.
Drag a concept onto its matching description — or click a concept then click the description.
Monitoring and alerting toolkit
High-performance proxy for service mesh
Package manager for Kubernetes
Distributed key-value store for cluster state
DNS server for service discovery in Kubernetes
Why these pairings
These are graduated CNCF projects commonly used in cloud native environments.
Refer to the exhibit. The deployment above is created, but the pods are not receiving traffic from the associated Service. The Service selector matches 'app: web'. The Service endpoints list is empty. What is the most likely cause?
The readiness probe is configured to GET /health on port 80, but the default nginx image does not serve a /health page. The probe fails, so the pod is not ready and is removed from Service endpoints.
Why this answer
The correct answer is C because 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.
Exam trap
CNCF often tests the distinction between readiness probes and liveness probes, and the trap here is that candidates assume a missing endpoint only affects liveness (causing restarts) rather than readiness (causing removal from Service endpoints).
How to eliminate wrong answers
Option A is wrong because the question states that the Service selector matches 'app: web', and the pods are created with that label, so the selector does match. Option B is wrong because the containerPort and Service targetPort are independent; the Service routes traffic to the containerPort, not the targetPort, and a mismatch would not cause an empty endpoints list—it would cause connection failures to the pod. Option D is wrong because an unavailable container image would prevent the pod from running (e.g., ImagePullBackOff), but the question says the pods are created and not receiving traffic, implying they are running; an unavailable image would not lead to an empty endpoints list.
Which TWO statements are true about Kubernetes Deployments?
Rolling updates and rollbacks are core features of Deployments.
Why this answer
Option A is correct because 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.
Exam trap
CNCF often tests the misconception that Deployments are suitable for stateful workloads or that they inherently expose applications externally, when in fact StatefulSets and Services are the correct components for those responsibilities.
Which TWO of the following are features of ArgoCD that support GitOps principles?
ArgoCD provides a UI to show the health and sync status of applications.
Why this answer
ArgoCD automatically syncs the cluster state to the desired state defined in Git (self-healing) and displays health status of applications. It does not generate manifests from templates natively (that's Kustomize's role) nor does it manage secrets directly.
What is the primary purpose of continuous integration (CI) in a cloud-native application delivery pipeline?
Why this answer
CI automates building and testing code changes to catch integration issues early. Option A correctly describes this. Option B is continuous deployment.
Option C refers to infrastructure as code. Option D is continuous delivery.
Which TWO of the following are benefits of using Helm for managing Kubernetes applications?
Helm uses Go templates to create reusable charts.
Why this answer
Helm provides templating for reusable configurations and allows for easy rollback to previous releases.
When using Kustomize, how do you apply a common label to all resources in the base?
commonLabels is designed for this purpose.
Why this answer
Kustomize's commonLabels field adds labels to all resources, including selectors.
Which tool can be used to implement feature flags in a Kubernetes-native progressive delivery setup?
Argo Rollouts provides canary deployments and integrates with feature flag systems like Flagd.
Why this answer
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.
Which DORA metric measures how quickly code changes are deployed to production?
This metric tracks the speed from commit to production.
Why this answer
Lead time for changes measures the time from code commit to running in production.
Which TWO of the following are benefits of implementing progressive delivery techniques (e.g., canary releases)?
Canary releases target a small percentage of users for validation.
Why this answer
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.
A company is adopting a GitOps workflow for their Kubernetes deployments. They want to ensure that the cluster state always matches the desired state defined in a Git repository. Which tool is specifically designed for this purpose?
Argo CD is a GitOps tool that syncs cluster state with a Git repository.
Why this answer
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.
Exam trap
The trap here is that candidates often confuse Helm or Kustomize as GitOps tools because they are used in GitOps pipelines, but they lack the continuous reconciliation and drift detection that a dedicated GitOps operator like Argo CD provides.
How to eliminate wrong answers
Option A is wrong because Helm is a package manager for Kubernetes that uses charts to define, install, and upgrade applications, but it does not provide continuous synchronization or drift detection from a Git repository; it is a deployment tool, not a GitOps operator. Option C is wrong because Kustomize is a configuration management tool that allows customizing Kubernetes manifests without templates, but it is a CLI tool or a kubectl plugin, not a controller that continuously reconciles cluster state with a Git repository. Option D is wrong because Prometheus is a monitoring and alerting toolkit for metrics collection and alerting, not a deployment or GitOps tool; it has no mechanism to enforce desired state from Git.
Which TWO components are part of the core Flux GitOps toolkit? (Choose 2)
Why this answer
Flux includes Source Controller and Kustomize Controller as core components. Helm Controller is also part of Flux, but the question asks for 'core' components; however, typically the core includes Source, Kustomize, and Helm. But since we need exactly two, the most essential are Source and Kustomize.
ArgoCD is a separate tool. Helm is a separate tool, though Flux has a Helm Controller. The question might expect Source and Kustomize as the answer.
A CI/CD pipeline includes image scanning. What is the primary security benefit of scanning container images in the CI phase?
Scanning early in the pipeline allows teams to fix vulnerabilities before deployment.
Why this answer
Scanning images in CI catches vulnerabilities before the image is deployed, preventing vulnerable images from reaching production.
Ready to test yourself?
Try a timed practice session using only Kcna App Delivery questions.