19 of 94 questions · Page 2/2 · Kcna App Delivery topic · Answers revealed
Which THREE are common features of progressive delivery?
Feature flags allow toggling functionality without redeployment.
Why this answer
Progressive delivery uses gradual rollout, feature flags, and analysis to reduce risk.
A team wants to implement a canary deployment strategy for their Kubernetes application. Which tool is specifically designed for progressive delivery and can be used to automate canary rollouts?
Argo Rollouts is purpose-built for progressive delivery with canary and blue-green deployments.
Why this answer
Argo Rollouts is a Kubernetes controller and set of CRDs that provides advanced deployment capabilities such as blue-green and canary deployments with automated promotion and rollback.
In Flux CD, which component is responsible for reconciling the cluster state with the source of truth defined in a Git repository?
The source controller watches Git repositories and other sources for changes.
Why this answer
The source controller fetches artifacts (e.g., from Git, Helm repos) and the kustomize controller applies manifests, but the reconciliation of desired state from Git is primarily managed by the source controller and kustomize controller working together. However, the source controller is the one that monitors sources.
A developer runs 'helm upgrade --install myapp ./mychart' and sees the release status is 'failed'. What is the most likely cause?
Invalid manifests cause the API server to reject them, failing the release.
Why this answer
A failed Helm upgrade usually means the Kubernetes API rejected the manifests (e.g., invalid YAML, resource conflict).
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?
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.
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.)
External secrets operators fetch secrets from external stores and create Kubernetes Secrets without exposing them in the chart.
Why this answer
Option A is correct because 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.
Match each Kubernetes resource to its primary purpose.
Drag a concept onto its matching description — or click a concept then click the description.
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
These are fundamental Kubernetes objects with distinct roles.
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?
Standard GitOps pattern; clear separation with shared base and overlays.
Why this answer
Option D is correct because 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.
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?
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.
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?
Why this answer
The Source Controller fetches artifacts (like Helm charts or Kustomize overlays) from sources (Git, OCI, etc.). The Kustomize Controller applies Kustomize overlays. The Helm Controller manages Helm releases.
The Notification Controller handles events. The question asks for the component that reconciles cluster state, but in Flux, multiple controllers work together. However, the Kustomize Controller is responsible for applying Kubernetes manifests (including Kustomize overlays) to the cluster.
Option B (Kustomize Controller) is the correct answer as it applies the desired state. Option A (Source Controller) fetches sources. Option C (Helm Controller) manages Helm releases.
Option D (Notification Controller) handles notifications.
Which THREE of the following are DORA metrics?
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.
A DevOps engineer notices that after a Helm upgrade, the new pods are crash looping with 'ImagePullBackOff'. What is the most likely cause?
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.
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?
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.
Which THREE of the following are core components of Flux?
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).
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?
Self-healing ensures the cluster state matches Git, so it undoes the manual change.
Why this answer
With self-healing enabled, ArgoCD will detect the drift and revert the change to match the desired state defined in Git.
Match each Kubernetes networking concept to its description.
Drag a concept onto its matching description — or click a concept then click the description.
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
These are fundamental networking options for exposing services.
What is the purpose of container image scanning in a CI/CD pipeline?
Why this answer
Image scanning checks for known vulnerabilities in container images before deployment, improving security. Option A is correct. Option B is about performance testing.
Option C is about image storage. Option D is about image tags.
According to DORA metrics, which metric measures the percentage of deployments that fail in production?
Why this answer
Change Failure Rate is the percentage of deployments causing a failure in production. Option A is correct. Option B (Deployment Frequency) measures how often deployments occur.
Option C (Lead Time for Changes) measures time from commit to production. Option D (Mean Time to Restore) measures how long it takes to recover from a failure.
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?
Secrets are designed for sensitive data; volume mounts reduce exposure.
Why this answer
Option C is correct because 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.
Ready to test yourself?
Try a timed practice session using only Kcna App Delivery questions.