CCNA Kcna App Delivery Questions — Page 2 of 2

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 →

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

A monorepo with a directory per environment, using overlays (for example Kustomize) to express per-environment differences, keeps shared manifests DRY while allowing dev, staging and prod to diverge safely. This satisfies the constraint of managing multiple separate clusters from one auditable source of truth, with Argo CD Applications targeting each overlay.

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 continuously polls the Git repository, compares the desired manifests against live cluster state, and triggers sync when drift is detected. It satisfies the stem's requirement for the component that monitors Git and reconciles changes, unlike the API Server (which serves requests) or the repo server (which renders manifests).

Why this answer

The Application Controller in ArgoCD is responsible for monitoring the Git repository for changes and syncing the desired state to the Kubernetes cluster. It continuously compares the live state of applications with the desired state defined in Git and takes corrective actions to reconcile them.

Exam trap

KCNA often tests the roles of ArgoCD components, and candidates may confuse the Repo Server's role (fetching manifests) with the Application Controller's role (syncing), leading to wrong answers.

How to eliminate wrong answers

Option A is wrong because the Repo Server is responsible for cloning and parsing Git repositories to generate Kubernetes manifests, but it does not monitor for changes or sync. Option B is wrong because the API Server exposes the ArgoCD API and handles authentication, but it does not perform the sync. Option D is wrong because Redis is used for caching, not for monitoring or syncing.

Practice this question →

MCQmedium

A release manager asks how a GitOps controller such as Argo CD decides whether an application is in sync. Which statement accurately describes that behavior?

A.It watches container image registries and marks the application in sync whenever a newer image tag is published

B.It checks whether all Pods report Ready and marks the application in sync once every replica passes its readiness probe

C.It compares the manifests rendered from the Git repository against the live objects in the cluster and reports drift when they differ

D.It queries the Kubernetes API for the latest applied annotation and considers the application in sync when that annotation is present

AnswerC

Argo CD renders the desired manifests from Git and diffs them against the live cluster objects, marking the application OutOfSync when the two diverge. Depending on sync policy, it can surface the drift for review or automatically reconcile the cluster back to the Git-declared state.

Why this answer

GitOps defines the desired state in Git, so a controller determines sync by rendering that desired state and diffing it against the live cluster objects. Divergence produces an OutOfSync status that a human can review or an automated policy can reconcile, keeping the cluster aligned with the repository.

Exam trap

The trap here is confusing runtime health signals like image publication or Pod readiness with configuration agreement between Git and the live cluster.

Practice this question →

MCQmedium

A team uses Argo CD to manage a production cluster. A developer commits a change to the Git repository that declares a Deployment with three replicas, but someone later manually scales the Deployment to five replicas using kubectl. What does Argo CD report and do by default?

A.It reports the application as OutOfSync and, with auto-sync enabled, reverts the live Deployment to three replicas.

B.It updates the Git repository to record five replicas so the declared state matches the cluster.

C.It ignores the manual change until the next Git commit touches the same Deployment.

D.It reports the application as Synced because the Deployment still exists and is healthy.

AnswerA

Argo CD continuously compares the desired state in Git with the live state in the cluster. The manual scale to five replicas diverges from the declared three, so the app shows OutOfSync. If automated sync is enabled, Argo CD applies the Git state and scales the Deployment back to three replicas, enforcing Git as the source of truth.

Why this answer

Argo CD enforces Git as the single source of truth. A manual scale creates drift, which Argo CD detects as OutOfSync, and with automated sync enabled it applies the Git manifest to restore the declared replica count, undoing the out-of-band change.

Exam trap

The trap here is thinking Argo CD syncs the cluster to Git only when Git changes, when it also detects and corrects drift from manual cluster edits.

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

Mean time to restore is a DORA metric, measuring how quickly service is restored after an incident, satisfying the stem's requirement for a recognised DORA measure. DORA's four keys comprise deployment frequency, lead time for changes, change failure rate and time to restore, so MTTR qualifies directly.

Why this answer

The four DORA (DevOps Research and Assessment) metrics are deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate. Option A, mean time to restore (MTTR), is correct because it measures how quickly service is restored after an incident or failed deployment, one of the core DORA reliability metrics. Option B, lead time for changes, is correct because it measures the time from code commit to code running successfully in production, a core DORA throughput metric.

Option C, deployment frequency, is correct because it measures how often an organization successfully releases to production, the other core DORA throughput metric. Option D, code coverage, is not a DORA metric; it is a code-quality/testing metric that does not appear in the DORA set. Option E, number of deployments per developer, is not a DORA metric; DORA measures deployment frequency at the team/service level, not per individual developer.

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

ImagePullBackOff means the kubelet cannot pull the specified image, most commonly because the tag referenced in the chart does not exist in the registry. A Helm upgrade that changed the image tag would produce exactly this crash-looping symptom.

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

The vulnerability originates in the base image layer, so patching application code cannot remove it. Replacing the base image with a patched tag and rebuilding propagates the fix through every derived layer in one pass.

Why this answer

The most efficient remediation for a vulnerability in a base image layer is to update the base image to a patched version and rebuild the application image. This addresses the root cause by replacing the vulnerable layer with a fixed one, ensuring that all future deployments are secure. It also aligns with immutable infrastructure practices, where containers are rebuilt rather than patched at runtime.

Exam trap

KCNA often tests the misconception that runtime security or patching running containers can substitute for rebuilding images, but the exam expects understanding of immutable infrastructure and root-cause remediation.

How to eliminate wrong answers

Option B is wrong because runtime security tools can block exploitation but do not remediate the vulnerability itself; the vulnerable code remains in the image. Option C is wrong because applying a patch directly to a running container is not persistent and violates immutable infrastructure principles; the patch would be lost on container restart. Option D is wrong because ignoring the vulnerability based on application code assumptions is risky; the base image layer may be exploited through other vectors, and compliance requirements often mandate remediation.

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

With self-healing enabled, ArgoCD's reconciliation loop detects the live replica count diverging from the Git-declared manifest and syncs the cluster back, overwriting the manual kubectl change. Git stays authoritative, so the Deployment returns to its committed replica count.

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 →

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

Scanning inspects image layers and installed packages against vulnerability databases, flagging known CVEs before deployment. This directly satisfies the pipeline's need to catch insecure dependencies and base images early, preventing vulnerable artefacts from reaching the cluster.

Why this answer

Container image scanning in a CI/CD pipeline analyzes the image layers for known security vulnerabilities (CVEs) in OS packages, libraries, and application dependencies. It is a core DevSecOps practice that shifts security left, catching issues before the image is deployed to production.

Exam trap

KCNA often tests the confusion between image scanning (security vulnerability detection) and other pipeline steps like image optimization, tagging, or registry storage — candidates may pick a plausible-sounding but non-security answer.

How to eliminate wrong answers

Option A is wrong because ensuring the image is stored in a registry is a function of the push step in the pipeline, not scanning. Option B is wrong because measuring image size is an optimization concern, not a security scanning purpose — though some scanners report layer sizes, that is not their primary goal. Option C is wrong because verifying tag naming conventions is a policy enforcement or linting step, not vulnerability scanning.

Practice this question →

MCQhard

According to DORA metrics, which metric measures the percentage of deployments that fail in production?

A.Change Failure Rate

B.Mean Time to Restore (MTTR)

C.Deployment Frequency

D.Lead Time for Changes

AnswerA

Change Failure Rate measures the proportion of deployments to production that result in degraded service and require remediation, expressed as a percentage. It directly satisfies the metric definition requested, unlike deployment frequency, lead time for changes or mean time to restore.

Why this answer

Change Failure Rate (CFR) is the DORA metric that directly measures the percentage of deployments that result in a failure in production, such as a service outage or a bug requiring a hotfix. It is calculated as (number of failed deployments / total deployments) * 100. This metric reflects the quality and stability of the software delivery process, complementing speed metrics like Deployment Frequency and Lead Time for Changes.

Exam trap

KCNA often tests the confusion between Change Failure Rate and Mean Time to Restore, as both relate to failures but measure different aspects: CFR measures the frequency of failures, while MTTR measures the duration to recover.

How to eliminate wrong answers

Option B is wrong because Mean Time to Restore (MTTR) measures the average time it takes to recover from a failure, not the percentage of deployments that fail. Option C is wrong because Deployment Frequency measures how often an organization successfully releases to production, not the failure rate. Option D is wrong because Lead Time for Changes measures the time from code commit to code successfully running in production, not the proportion of failed deployments.

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

Kubernetes Secrets store credentials separately from the image and pod specification, and mounting them as volumes injects the data as files at runtime, so passwords never appear in container layers or environment variables. This satisfies the requirement to avoid exposing sensitive data.

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 →