KCNA Cloud Native Application Delivery — 20 Questions

Question 1

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?

Accepted Answer

0. The deployment uses a RollingUpdate strategy configured with maxUnavailable=0 (as shown in the exhibit), meaning that during the update, no existing pods are terminated until new pods are ready. This ensures that the desired number of replicas is always maintained, resulting in zero unavailable pods at all times.

Answer

2

Answer

3

Answer

1

Question 2

In Flux CD, which component is responsible for reconciling the cluster state with the source of truth defined in a Git repository?

Accepted Answer

Kustomize controller. In Flux, the Kustomize controller is responsible for reconciling the cluster state with the desired state defined in a Git repository. It takes the artifacts fetched by the Source controller and applies Kustomize overlays to ensure the cluster matches the declared configuration. The Source controller only retrieves the source artifacts, not reconciliation.

Answer

Source controller

Answer

Helm controller

Answer

Notification controller

Question 3

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?

Accepted Answer

Patches. 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 (Generators) creates ConfigMaps/Secrets. Option C (Bases) is the common configuration. Option D (Components) is a newer feature for reusable pieces.

Answer

Generators

Answer

Bases

Answer

Components

Question 4

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?

Accepted Answer

Canary deployment. A canary deployment gradually shifts traffic from the old version to the new version, allowing monitoring before full rollout. This strategy typically requires a service mesh or ingress controller to manage traffic splitting. Option A (Rolling update) replaces pods incrementally but does not split traffic; it updates instances one by one. Option C (Blue-green deployment) switches traffic entirely between two identical environments (blue and green). Option D (Recreate) kills all old pods before creating new ones, causing downtime.

Answer

Rolling update

Answer

Blue-green deployment

Answer

Recreate

Question 5

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

Accepted Answer

Change Failure Rate. Change Failure Rate is the percentage of deployments causing a failure in production. Option A is correct. Option B (Mean Time to Restore) measures how long it takes to recover from a failure. Option C (Deployment Frequency) measures how often deployments occur. Option D (Lead Time for Changes) measures time from commit to production.

Answer

Mean Time to Restore (MTTR)

Answer

Deployment Frequency

Answer

Lead Time for Changes

Question 6

A startup wants to minimize downtime during application updates in Kubernetes. Which deployment strategy should they use?

Accepted Answer

RollingUpdate. 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.

Answer

Canary

Answer

Blue/Green

Answer

Recreate

Question 7

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

Accepted Answer

The Helm chart has a wrong image tag. 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.

Answer

The pod's liveness probe is misconfigured

Answer

The service account lacks permissions

Answer

The deployment's resource requests exceed node capacity

Question 8

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?

Accepted Answer

A monorepo with a directory per environment and overlays for differences. 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.

Answer

A single branch with all environment manifests in the same folder

Answer

Separate repositories per environment

Answer

Store all manifests in a single file with environment labels

Question 9

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?

Accepted Answer

Perform a rollout restart of the deployment. 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.

Answer

Delete and recreate the ConfigMap

Answer

Edit the deployment and change a label

Answer

Restart the kubelet on the nodes

Question 10

Which TWO of the following are benefits of using Helm for application delivery?

Accepted Answer

Ability to roll back to previous releases. 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.

Answer

Automatic scaling based on CPU usage

Answer

Automatic canary deployments

Answer

Built-in monitoring and alerting

Question 11

Which THREE of the following practices are essential for a secure cloud native CI/CD pipeline?

Accepted Answer

Sign container images and verify signatures during deployment. 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.

Answer

Store secrets in plain text in the pipeline configuration

Answer

Use a single long-lived service account for all pipeline steps

Question 12

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?

Accepted Answer

Reduce the CPU request of the inventory deployment to 1 CPU per pod to allow better packing on existing nodes while cluster autoscaler catches up.. 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.

Answer

Increase the cluster autoscaler max nodes to 20 and set a 0-second scale-up delay.

Answer

Set resource limits equal to requests for all microservices to guarantee resources.

Answer

Delete all pending pods and recreate them manually.

Question 13

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?

Accepted Answer

Store the secret in a Kubernetes Secret and mount it as a volume in the pod. 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.

Answer

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

Answer

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

Answer

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

Question 14

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?

Accepted Answer

Argo CD. 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.

Answer

Helm

Answer

Kustomize

Answer

Prometheus

Question 15

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?

Accepted Answer

Queue-based Load Leveling pattern. 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.

Answer

Bulkhead pattern

Answer

Circuit Breaker pattern

Answer

Retry pattern

Question 16

Which TWO statements are true about Kubernetes Deployments?

Accepted Answer

Deployments support rolling updates and rollbacks.. 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.

Answer

Deployments are the recommended controller for stateful applications.

Answer

Deployments can expose applications externally via a built-in load balancer.

Answer

Deployments are used to run a pod on every node in the cluster.

Question 17

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?

Accepted Answer

Increase the memory limit in the Deployment manifest to a higher value, such as 1Gi, and perform a rolling update.. 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.

Answer

Scale the Deployment to 5 replicas to distribute the memory load.

Answer

Remove the memory limit from the container spec to allow unlimited memory usage.

Answer

Revert the ConfigMap to the previous configuration and monitor memory usage.

Question 18

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?

Accepted Answer

Set spec.strategy.rollingUpdate.maxSurge=1 and maxUnavailable=0. Setting spec.strategy.rollingUpdate.maxSurge=1 and maxUnavailable=0 ensures that during a rolling update, new pods are created before old pods are terminated. This prevents downtime by maintaining the desired number of available pods at all times. Option B is incorrect because maxSurge=0 prevents creating new pods before terminating old ones, which can cause downtime if old pods are removed before new ones are ready. Option A is incorrect because minReadySeconds controls how long a pod must be ready before being considered available, not the order of creation/termination. Option C is incorrect because a liveness probe is for restarting unhealthy pods, not for controlling rollout behavior.

Answer

Set spec.strategy.rollingUpdate.minReadySeconds to 0

Answer

Set spec.strategy.rollingUpdate.maxSurge=0 and maxUnavailable=1

Answer

Add a liveness probe to the container spec

Question 19

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.)

Accepted Answer

Use an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) to inject secrets at runtime. 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.

Answer

Store secrets in a separate Git repository with restricted access

Answer

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

Answer

Use Helm's built-in encryption for values files

Question 20

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?

Accepted Answer

The readiness probe endpoint /health does not exist in the nginx container. 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.

Answer

The Service selector does not match the pod labels

Answer

The containerPort is set to 80, but the Service targetPort is 8080

Answer

The nginx:1.21 image is not available in the container registry