KCNA Cloud Native Application Delivery — Timed 10 Questions

Question 1

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 2

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 3

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

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 4

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 5

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 6

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 7

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. Option B is correct because the deployment strategy defaults to RollingUpdate with a maxUnavailable setting of 25% (rounded up), which for a deployment with 4 replicas allows 1 pod to be unavailable. However, the question states that during the rollout the maximum number of pods that will be unavailable at any given time is 0, which implies the deployment uses a maxSurge and maxUnavailable configuration that ensures no pods are taken down until new ones are ready—this is achieved by setting maxUnavailable to 0 and maxSurge to 1 or more, so the deployment creates a new pod before terminating an old one, guaranteeing zero downtime.

Answer

2

Answer

3

Answer

1

Question 8

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.. Option C is correct because 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 9

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

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 10

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