CCNA Kcna App Delivery Questions — Page 2 of 2

MCQmedium

A DevOps team wants to adopt a deployment pattern where a new version of an application is gradually rolled out to a small subset of users before full deployment. Which progressive delivery technique should they use?

A.Canary deployment

B.Rolling update

C.Blue-green deployment

D.Recreate deployment

AnswerA

Canary releases a new version to a small subset of users, monitoring before full rollout.

Why this answer

Canary deployment releases the new version to a small percentage of users initially, then gradually increases traffic.

Practice this question →

Multi-Selectmedium

A DevOps team uses Helm to manage Kubernetes applications. They want to ensure that sensitive data (e.g., database passwords) is not stored in plaintext in the Helm chart or in the cluster's ConfigMaps/Secrets. Which TWO practices should they adopt? (Choose two.)

Select 2 answers

A.Use an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) to inject secrets at runtime

B.Store secrets in a separate Git repository with restricted access

C.Use a tool like sealed-secrets to encrypt the secrets before committing them to the chart

D.Store secrets as Kubernetes Secrets and reference them in the chart values

E.Use Helm's built-in encryption for values files

AnswersA, C

External secrets operators fetch secrets from external stores and create Kubernetes Secrets without exposing them in the chart.

Why this answer

Using an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) allows secrets to be injected directly into Pods at runtime without ever storing them in the Helm chart or as Kubernetes Secrets in plaintext. This approach leverages the Kubernetes CSI (Container Storage Interface) or a sidecar pattern to mount secrets from an external store, ensuring sensitive data never resides in the cluster's etcd or version control.

Exam trap

CNCF often tests the misconception that base64 encoding in Kubernetes Secrets is equivalent to encryption, leading candidates to incorrectly select Option D as secure, when in fact base64 is merely an encoding and provides no confidentiality.

Practice this question →

Matchingmedium

Match each Kubernetes resource to its primary purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Smallest deployable unit containing one or more containers

Stable network endpoint to access a set of Pods

Stores non-sensitive configuration data as key-value pairs

Cluster-wide storage resource provisioned by an administrator

Manages external access to services, typically HTTP

Why these pairings

Pods are the smallest deployable units; Services provide stable networking to Pods; Deployments manage Pod lifecycle. Common confusions involve swapping Pod with Service, Service with ConfigMap, and Deployment with storage resources.

Practice this question →

MCQhard

A team wants to implement GitOps for their Kubernetes workloads using Argo CD. They have multiple environments (dev, staging, prod) in separate clusters. What is the best practice for structuring the Git repository?

A.A single branch with all environment manifests in the same folder

B.Separate repositories per environment

C.Store all manifests in a single file with environment labels

D.A monorepo with a directory per environment and overlays for differences

AnswerD

Standard GitOps pattern; clear separation with shared base and overlays.

Why this answer

A monorepo with a directory per environment and overlays (e.g., using Kustomize or Helm) allows you to manage environment-specific differences declaratively while keeping a single source of truth. Argo CD can sync each environment's directory to its respective cluster, and overlays minimize duplication by applying only the necessary patches (e.g., replica counts, ingress hosts) on top of a common base. This approach aligns with GitOps best practices for multi-environment deployments.

Exam trap

The trap here is that candidates often choose Option B (separate repos) thinking it provides the best isolation, but the KCNA exam emphasizes that a monorepo with overlays is the recommended pattern for GitOps because it reduces duplication and simplifies cross-environment consistency.

How to eliminate wrong answers

Option A is wrong because storing all environment manifests in the same folder on a single branch makes it impossible to isolate environment-specific changes, leading to accidental cross-environment deployments and no clear promotion path. Option B is wrong because separate repositories per environment introduce fragmentation, making it harder to maintain consistency across environments and requiring duplicate base configurations, which violates the DRY principle. Option C is wrong because storing all manifests in a single file with environment labels (e.g., using YAML anchors or labels) is not supported by Argo CD's native sync mechanism—Argo CD syncs entire manifests, not filtered by labels, and this approach would cause all environments to be deployed simultaneously, breaking environment isolation.

Practice this question →

MCQmedium

A development team wants to implement GitOps for their Kubernetes deployments using ArgoCD. Which ArgoCD component is responsible for monitoring the Git repository for changes and syncing the desired state to the cluster?

A.Repo Server

B.API Server

C.Application Controller

D.Redis Server

AnswerC

The Application Controller is the core component that monitors Git repositories and syncs applications to match the desired state.

Why this answer

The Application Controller in ArgoCD is the component that continuously monitors the Git repository and compares the desired state (in Git) with the live state (in the cluster). It triggers sync operations when differences are detected.

Practice this question →

MCQmedium

A team uses Flux to manage GitOps. Which Flux component is responsible for reconciling the cluster state with the desired state defined in a Git repository?

A.Kustomize Controller

B.Source Controller

C.Helm Controller

D.Notification Controller

AnswerA

Why this answer

In Flux, the Kustomize Controller (option A) is responsible for reconciling the cluster state with the desired state defined in a Git repository. It applies Kubernetes manifests, including Kustomize overlays, to the cluster to ensure the actual state matches the desired state. The Source Controller (option B) fetches source artifacts from Git or other sources, but does not perform reconciliation.

The Helm Controller (option C) manages Helm releases, and the Notification Controller (option D) handles event notifications. Therefore, the correct answer is the Kustomize Controller.

Practice this question →

Multi-Selectmedium

Which THREE of the following are DORA metrics?

Select 3 answers

A.Mean time to restore (MTTR)

B.Lead time for changes

C.Deployment frequency

D.Code coverage

E.Number of deployments per developer

AnswersA, B, C

It measures the time to recover from a failure.

Why this answer

Mean time to restore (MTTR) is one of the four key DORA metrics defined by the DevOps Research and Assessment (DORA) team. It measures the average time it takes to recover from a failure in a production environment, directly reflecting the resilience and incident response capability of a cloud-native system. In Kubernetes, this often involves automated rollback strategies, pod rescheduling, or canary deployments to minimize downtime.

Exam trap

CNCF often tests candidates by including plausible but non-DORA metrics like code coverage or deployment counts, exploiting the misconception that any useful DevOps metric qualifies as a DORA metric, when in fact only the four specific metrics (deployment frequency, lead time for changes, mean time to restore, and change failure rate) are officially defined.

Practice this question →

MCQmedium

A DevOps engineer notices that after a Helm upgrade, the new pods are crash looping with 'ImagePullBackOff'. What is the most likely cause?

A.The pod's liveness probe is misconfigured

B.The Helm chart has a wrong image tag

C.The service account lacks permissions

D.The deployment's resource requests exceed node capacity

AnswerB

A mistyped or non-existent tag leads to pull failures.

Why this answer

The 'ImagePullBackOff' error indicates that Kubernetes is unable to pull the container image from the registry. The most common cause during a Helm upgrade is a misconfigured or incorrect image tag in the Helm chart's values or templates, which causes the kubelet to fail when attempting to pull the specified image. This is distinct from runtime issues like probe failures or resource constraints, which would manifest as different error states.

Exam trap

CNCF often tests the distinction between pre-start errors (ImagePullBackOff, ErrImagePull) and runtime errors (CrashLoopBackOff, probe failures), so candidates mistakenly associate any pod failure with liveness probes or resource constraints rather than image availability.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe would cause the pod to be restarted or killed after starting (e.g., 'CrashLoopBackOff' with a running container), not an 'ImagePullBackOff' which occurs before the container can even start. Option C is wrong because service account permissions affect API access (e.g., for listing secrets or interacting with the Kubernetes API), not the ability to pull container images from a registry; image pull failures are governed by image pull secrets and registry authentication, not RBAC on the cluster. Option D is wrong because resource requests exceeding node capacity would result in a 'Pending' or 'Unschedulable' pod status, not 'ImagePullBackOff', which is a pull-time error unrelated to scheduling.

Practice this question →

MCQhard

A CI pipeline scans container images for vulnerabilities. The scan report shows a critical vulnerability in a base image layer. What is the most efficient way to remediate this issue?

A.Update the base image to a patched version and rebuild the application image

B.Use a runtime security tool to block exploitation

C.Apply a security patch directly to the running container

D.Ignore the vulnerability if the application code is not affected

AnswerA

Updating the base image and rebuilding ensures the vulnerability is removed from all layers.

Why this answer

Rebuilding the image with an updated base image that includes the security fix is the standard approach to address base image vulnerabilities.

Practice this question →

Multi-Selecthard

Which THREE of the following are core components of Flux?

Select 3 answers

A.Source controller

B.Notification controller

C.GitOps controller

D.Kustomize controller

E.Helm controller

AnswersA, D, E

Manages sources like Git repositories and OCI artifacts.

Why this answer

Flux has a source-controller that manages artifact sources (e.g., Git repositories), a kustomize-controller that applies Kustomize overlays, and a helm-controller for Helm releases. The gitops-controller is not a specific Flux component (it's a generic term), and the notification-controller is not a core component (it's a separate controller for events).

Practice this question →

MCQhard

In a GitOps workflow, a team uses ArgoCD. A developer manually changes a Deployment's replica count in the cluster via kubectl. ArgoCD has self-healing enabled. What will happen?

A.ArgoCD creates a new Deployment with the manual change

B.ArgoCD updates the Git repository to reflect the manual change

C.ArgoCD ignores the change because it was made manually

D.ArgoCD reverts the replica count to the value in Git

AnswerD

Self-healing ensures the cluster state matches Git, so it undoes the manual change.

Why this answer

With self-healing enabled, ArgoCD continuously monitors the cluster for drift. When a manual change is made via kubectl, ArgoCD detects that the live state no longer matches the desired state defined in Git. It then automatically reverts the change to bring the cluster back into sync with the Git repository.

Practice this question →

Matchingmedium

Match each Kubernetes networking concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Default service type; exposes service on a cluster-internal IP

Exposes service on each node's IP at a static port

Exposes service externally using a cloud provider's load balancer

Service without a cluster IP; used for direct pod-to-pod communication

Implements traffic routing rules defined by Ingress resources

Why these pairings

Common confusions arise between ClusterIP (internal-only) and NodePort (node-level external access), and between LoadBalancer (cloud-integrated external LB) and Ingress (HTTP routing with rules).

Practice this question →

MCQeasy

What is the purpose of container image scanning in a CI/CD pipeline?

A.To ensure the image is stored in a registry

B.To measure the image size and optimize it

C.To verify the image tag follows naming conventions

D.To identify security vulnerabilities in the image

AnswerD

Why this answer

Container image scanning checks for known security vulnerabilities (e.g., CVEs) in the image layers and dependencies. This helps prevent deploying vulnerable containers into production. Option A is incorrect because storing in a registry is unrelated; scanning can occur before or after pushing.

Option B is incorrect because image size and optimization are separate concerns, often handled by multi-stage builds or other tools. Option C is incorrect because naming conventions are typically enforced via policies or linting, not scanning. Option D correctly identifies the purpose of scanning: identifying security vulnerabilities.

Practice this question →

MCQeasy

A team is deploying a new microservice that processes sensitive user data. They want to ensure that secrets such as database passwords are not exposed in the container image or environment variables. Which approach should they use?

A.Embed the secret directly in the Docker image and use it via environment variables

B.Store the secret in a ConfigMap and reference it in the pod spec

C.Store the secret in a Kubernetes Secret and mount it as a volume in the pod

D.Use a PersistentVolumeClaim to store the secret and mount it into the pod

AnswerC

Secrets are designed for sensitive data; volume mounts reduce exposure.

Why this answer

Kubernetes Secrets are designed specifically to store sensitive data like database passwords. Mounting the Secret as a volume ensures the secret data is available to the pod as files, without being exposed in environment variables (which can be leaked via logs or `kubectl describe`) or embedded in the container image. This approach follows security best practices for handling sensitive information in cloud-native applications.

Exam trap

CNCF often tests the misconception that ConfigMaps are suitable for secrets because they can store key-value pairs, but the trap is that ConfigMaps store data in plaintext and are not designed for sensitive information, whereas Secrets provide base64 encoding and optional encryption at rest.

How to eliminate wrong answers

Option A is wrong because embedding secrets directly in a Docker image makes them part of the image layers, which can be inspected by anyone with access to the image registry, violating the principle of least privilege. Option B is wrong because ConfigMaps are intended for non-sensitive configuration data; storing secrets in a ConfigMap leaves them unencrypted and accessible via `kubectl get configmap`, which is a security risk. Option D is wrong because PersistentVolumeClaims are used for persistent storage of application data, not for storing secrets; they lack the encryption and access control features provided by Kubernetes Secrets.

Practice this question →