SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
KCNA · Domain 3

Cloud Native Application Delivery practice questions

Cloud Native Application Delivery is worth 16% of the KCNA exam — the 3rd-heaviest of the 4 domains. Delivering and debugging applications on cloud-native platforms. Official weighting 16%. 6 fully worked examples are further down this page, answers included.

Exam weight
16%
the 3rd-heaviest of the 4 domains
Questions
40
across 2 topics
Free, no account
5/day
sign up free to remove the cap
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 4 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Cloud Native Application Delivery questions, fully explained

Questions from the KCNA bank mapped to domain 3, with the answer key and the reasoning behind every option. None of them repeat the examples on the main KCNA practice page.

Question 1Cloud Native Application Delivery

A team wants two complete, independently running environments, old and new, and plans to switch all production traffic from one to the other in a single cut-over. Which deployment pattern are they describing?

Choose one.

  • a
    RollingUpdate

    RollingUpdate replaces Pods gradually within a single Deployment; it does not run two full separate environments.

  • b
    Blue-green Correct

    Blue-green runs the old (blue) and new (green) versions as two full environments and switches traffic from one to the other in a single cut-over, typically by updating a Service selector or load balancer target.

  • c
    Canary

    Canary exposes a small percentage of traffic to the new version first rather than switching all traffic at once.

  • d
    Recreate

    Recreate is a Deployment strategy field value that tears down old Pods before creating new ones inside one Deployment, not a two-environment pattern.

The concept

Blue-green deployment is a release pattern, not a built-in Kubernetes Deployment strategy value.

Why that’s the answer

In blue-green, both versions are deployed and fully scaled at the same time as separate resources, for example two Deployments, and traffic is redirected all at once, often by changing which Pods a Service's label selector matches. This gives an instant, easily reversible cutover, at the cost of running double the capacity briefly.

How to reason it out
  1. Deploy the new (green) version alongside the running (blue) version, fully scaled.
  2. Validate the green environment separately from production traffic.
  3. Switch the Service or load balancer to point at green all at once, and keep blue available for a fast rollback.

Exam tip: Blue-green is an application-level pattern built from ordinary Kubernetes objects, not a Deployment strategy field value.

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies — the lesson that teaches this.

Question 2Cloud Native Application Delivery

Which statement correctly describes canary releases on Kubernetes?

Choose one.

  • a
    Canary is a built-in Deployment strategy value alongside RollingUpdate and Recreate.

    The Deployment strategy field only accepts RollingUpdate or Recreate. Canary is not one of its values.

  • b
    Canary always requires deleting the old ReplicaSet before any traffic reaches the new version.

    Canary intentionally keeps the old version running and serving most of the traffic while the new version is validated with a small slice.

  • c
    Canary sends a small, controlled percentage of traffic to a new version before it fully replaces the old one, typically using a service mesh or a tool like Argo Rollouts to manage the split. Correct

    Fine-grained traffic splitting between old and new Pods is not something a plain Deployment does on its own, so canary rollouts are usually implemented with a service mesh for traffic-splitting rules, or a specialized controller such as Argo Rollouts.

  • d
    Canary is a synonym for the Recreate strategy.

    Recreate removes all old Pods before starting new ones; canary keeps both versions running simultaneously with split traffic.

The concept

Canary is a progressive-delivery pattern for validating a new version with a small slice of real traffic before a full rollout.

Why that’s the answer

A plain Deployment can approximate a canary by running a second small Deployment behind the same Service, but precise percentage-based traffic control needs weighted routing, which comes from a service mesh, such as Istio or Linkerd traffic splitting, or a purpose-built controller like Argo Rollouts.

How to reason it out
  1. Deploy a small number of Pods running the new version alongside the stable version.
  2. Route a controlled slice of traffic, for example 5 percent, to the new Pods, using a mesh or Argo Rollouts.
  3. Monitor the canary's metrics, then gradually increase its traffic share or roll it back.

Exam tip: Canary is a pattern layered on top of Kubernetes, not a native Deployment strategy field value.

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies — the lesson that teaches this.

Question 3Cloud Native Application Delivery

Which kubectl command reports whether an in-progress Deployment rollout has finished successfully?

Choose one.

  • a
    kubectl get deployments

    This lists Deployments and a snapshot of replica counts, but it does not actively watch and report rollout completion the way rollout status does.

  • b
    kubectl rollout history

    This lists past revisions of a Deployment; it does not report on the currently in-progress rollout.

  • c
    kubectl rollout status Correct

    kubectl rollout status deployment/NAME watches the rollout and blocks until it completes, reporting success or that it is still waiting.

  • d
    kubectl describe pod

    This shows detail about a single Pod, not the overall progress of a Deployment rollout.

The concept

kubectl rollout status is the standard way to watch a Deployment update reach completion.

Why that’s the answer

Running kubectl rollout status deployment/NAME attaches to the rollout and streams progress until the Deployment reports all replicas updated and available, or until it times out, making it the direct answer to whether an update finished.

How to reason it out
  1. Trigger an update, for example with kubectl set image.
  2. Run kubectl rollout status deployment/NAME.
  3. The command returns successfully once the rollout completes, or keeps waiting if it has stalled.

Exam tip: kubectl rollout status is the command for checking whether a rollout has completed.

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies — the lesson that teaches this.

Question 4Cloud Native Application Delivery

Which kubectl command reverts a Deployment to its previous revision?

Choose one.

  • a
    kubectl rollout restart

    This restarts the Pods of the current revision; it does not switch to a prior revision.

  • b
    kubectl apply -k

    This applies manifests built with Kustomize; it is unrelated to rolling back a Deployment revision.

  • c
    kubectl rollout undo Correct

    kubectl rollout undo deployment/NAME rolls the Deployment back to its previous revision by re-applying that revision's Pod template.

  • d
    kubectl scale

    This changes the replica count of a Deployment; it does not change which revision is running.

The concept

kubectl rollout undo is the command for reverting a Deployment to an earlier recorded revision.

Why that’s the answer

Because Deployments keep a history of ReplicaSets, bounded by revisionHistoryLimit, kubectl rollout undo can restore the Pod template of a previous revision, causing a new rollout back to that known-good state.

How to reason it out
  1. Identify that the current rollout is unhealthy.
  2. Run kubectl rollout undo deployment/NAME to revert to the previous revision.
  3. Kubernetes performs a new rolling update back to the prior Pod template.

Exam tip: kubectl rollout undo rolls a Deployment back by rolling forward to a previous revision's template.

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies — the lesson that teaches this.

Question 5Cloud Native Application Delivery

In the GitOps model, what is treated as the single source of truth for the desired state of a cluster?

Choose one.

  • a
    The live state currently running in the cluster

    In GitOps the live cluster state is meant to converge to match Git, not the other way around.

  • b
    A Git repository containing declarative configuration Correct

    GitOps defines the desired state declaratively in a Git repository, and that repository is authoritative over what should be running.

  • c
    The CI pipeline's build logs

    Build logs record what a pipeline did; they are not a declarative description of desired cluster state.

  • d
    Whatever an administrator last applied with kubectl

    Manual kubectl changes are exactly what GitOps treats as drift to be reconciled away, not as the source of truth.

The concept

GitOps is an operating model where Git holds the declarative desired state of infrastructure and applications.

Why that’s the answer

Because every intended change is expressed as a commit to Git, the repository's current contents fully describe what should be running. An in-cluster controller continuously compares the live cluster to that repository and reconciles any difference.

How to reason it out
  1. A change, for example a new image tag, is committed to the Git repository.
  2. A GitOps controller detects the commit.
  3. The controller reconciles the live cluster state to match the repository's declared state.

Exam tip: In GitOps, Git is the single source of truth, and the cluster is reconciled to match it.

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies — the lesson that teaches this.

Question 6Cloud Native Application Delivery

In the GitOps pull model, which component is responsible for fetching the desired state from Git and applying it to the cluster?

Choose one.

  • a
    An external CI pipeline that holds cluster credentials and pushes changes in

    That describes the traditional CI/CD push model. In the pull model, the pipeline does not hold cluster credentials or push changes directly.

  • b
    An agent or controller running inside the cluster that pulls from the Git repository Correct

    In the pull model, a controller such as Argo CD or Flux runs inside the cluster, periodically or continuously pulling the desired state from Git and applying it, so no external system needs direct write access to the cluster.

  • c
    The kube-scheduler

    The scheduler assigns Pods to nodes; it has no role in fetching desired state from a Git repository.

  • d
    A developer's local kubectl client

    GitOps automates reconciliation so that manual, ad hoc kubectl usage from a laptop is not the delivery mechanism.

The concept

The defining trait of the GitOps pull model is that an in-cluster agent initiates synchronization, rather than an external system pushing changes in.

Why that’s the answer

Tools like Argo CD and Flux run as controllers inside the target cluster. They watch the configured Git repository, detect new commits, and apply the corresponding manifests, which means cluster credentials never need to leave the cluster.

How to reason it out
  1. The GitOps controller is installed inside the cluster and configured with a Git repository URL.
  2. It periodically polls, or receives a webhook trigger, for new commits.
  3. It pulls the latest manifests and applies them, reconciling the cluster to match.

Exam tip: In the pull model, an in-cluster controller fetches from Git; credentials and control stay inside the cluster.

Cloud Native Application Delivery: GitOps, Helm, and Deployment Strategies — the lesson that teaches this.

What KCNA domain 3 tests, topic by topic

The official exam guide breaks Cloud Native Application Delivery into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published KCNA practice questions per topic in Cloud Native Application Delivery
TopicWhat it coversQuestions
Application DeliveryOfficial KCNA competency (Cloud Native Application Delivery). Delivering applications on Kubernetes: deployment strategies and rollouts, GitOps and CI/CD fundamentals, package management with Helm, and the application definition and image-build landscape.20
DebuggingOfficial KCNA competency. Debugging application delivery: inspecting Deployments and rollouts, diagnosing failed releases, and using observability signals during delivery.20
Total40

Revise Cloud Native Application Delivery before you drill it

Cloud Native Application Delivery: GitOps, Helm, and Deployment StrategiesKCNA tests this topic with recognition questions: which strategy is the Deployment default, which pattern runs two full environments and switches traffic at once, and which tools implement GitOps. Trigger words include single source of truth, pull-based reconciliation, and drift (GitOps); chart, values, and release (Helm); and template-free overlays (Kustomize). Expect at least one question distinguishing the CI/CD push model from the GitOps pull model, and one matching blue-green or canary to its description.Debugging Application Delivery: Stuck Rollouts, Failed Releases, and RollbacksKCNA frames this topic as scenario questions: a rollout that hangs, one new Pod in ImagePullBackOff while old Pods keep serving, and what command recovers it. Trigger words include rollout status, rollout undo, ProgressDeadlineExceeded, revisionHistoryLimit, and helm rollback. Expect to be tested on the facts that Kubernetes never rolls back automatically, that readiness probe failures block rollout progress, and that the old ReplicaSet keeps serving while the new one is unhealthy.

Other KCNA domains

Domain 1: Kubernetes Fundamentals44% of the exam · 80 questionsDomain 2: Container Orchestration28% of the exam · 80 questionsDomain 4: Cloud Native Architecture12% of the exam · 60 questionsAll KCNA practice questionsMixed sessions across all 4 domains — the way the real exam interleaves them.

Cloud Native Application Delivery: your questions

Cloud Native Application Delivery is domain 3 of the KCNA exam guide and carries 16% of the scored content — the 3rd-heaviest of the 4 domains. On a 60-question paper that works out to roughly 10 questions, though CNCF does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official KCNA exam guide.