Kubernetes Deployments in CI/CD Quiz Quiz

Challenge your understanding of Kubernetes deployments within CI/CD pipelines, covering core concepts, deployment strategies, YAML configurations, and best practices. This quiz helps users grasp essential Kubernetes deployment topics relevant to continuous integration and continuous delivery environments.

1. Understanding Deployment Purpose

   In a Kubernetes-based CI/CD pipeline, what is the main purpose of a Deployment resource?

   1. To manage the scaling and rolling updates of application pods
   2. To create persistent storage volumes for applications
   3. To store secret configuration values securely
   4. To monitor and log application performance

   Explanation: A Deployment in Kubernetes is designed to manage the lifecycle of application pods, ensuring the desired number of replicas and enabling smooth rolling updates. It is not used for storing secrets—that function belongs to Secrets. Monitoring and logging are handled by different components, and persistent storage is configured through PersistentVolume or PersistentVolumeClaim resources.

2. Basic YAML Understanding

   Which field in a Kubernetes Deployment YAML specifies the number of desired application pod replicas?

   1. volumes
   2. service
   3. metadata
   4. replicas

   Explanation: The 'replicas' field in the Deployment YAML defines how many pod instances you want running. 'Service' is a separate resource and cannot directly set replica count. 'Volumes' configures storage, and 'metadata' is used for names and labels, not for controlling the number of replicas.

3. Rolling Update Strategy

   What does configuring 'strategy.type' as 'RollingUpdate' in a Deployment ensure during CI/CD-driven releases?

   1. Deployment stops pods from scaling up
   2. All existing pods are deleted at once before new pods are created
   3. Only one pod runs at any given time
   4. New pods are incrementally updated while old pods are terminated

   Explanation: A 'RollingUpdate' strategy gradually replaces old pods with new ones, maintaining service availability during updates. Deleting all pods at once describes the 'Recreate' strategy. Preventing scaling up is not related to deployment strategy, and the configuration does not limit the deployment to a single pod.

4. Container Image Tagging

   Why is it considered best practice to avoid using the 'latest' tag for container images in Kubernetes Deployments within CI/CD?

   1. It automatically increases storage usage
   2. It prevents manual scaling of pods
   3. It disables health checks for pods
   4. Using 'latest' makes deployments unpredictable and harder to roll back

   Explanation: The 'latest' tag refers to the most recently built image, which can change over time, making deployments non-repeatable and rollback complicated. Storage usage is not directly affected by the tag, manual scaling is unrelated, and health checks function regardless of the tag used.

5. Readiness Probes Role

   In a CI/CD pipeline deploying to Kubernetes, why would you add a readiness probe to your application's Deployment manifest?

   1. To permanently delete failed pods
   2. To schedule backups of application data
   3. To ensure traffic is only sent to pods after they are ready to serve requests
   4. To automatically update the Deployment's version

   Explanation: A readiness probe allows Kubernetes to know when a pod is ready to receive traffic, reducing downtime during deployments. Probes do not update versions, delete pods, or handle data backups, which are managed by other resources and configurations.

6. Automating Deployment Triggers

   How can CI/CD pipelines typically automate the rollout of a new Deployment in Kubernetes after a code change?

   1. By manually editing each pod's configuration on the server
   2. By restarting the entire Kubernetes cluster
   3. By applying an updated Deployment YAML file using a deployment command
   4. By changing the cluster's network settings

   Explanation: CI/CD tools often apply updated Deployment YAML manifests (using commands like apply or deploy) to trigger Kubernetes to update resources. Manually editing pods is inefficient and bypasses Deployment management. Restarting clusters or modifying network settings is unnecessary for rolling out new code.

7. Rollback Functionality

   If a recent automated deployment causes errors, which Kubernetes feature allows for a quick rollback to a previous ReplicaSet version?

   1. Namespace isolation
   2. Service account management
   3. PersistentVolumeClaim resizing
   4. Deployment revision history

   Explanation: Kubernetes Deployments keep a revision history, enabling rollbacks to previous versions if an update fails. Service account management handles permissions, namespace isolation deals with resource separation, and PersistentVolumeClaim resizing changes storage capacity and is unrelated to rollbacks.

8. Declarative Configuration

   What is the benefit of using declarative Deployment configurations (YAML files) in CI/CD over imperative commands?

   1. They fully automate database schema migrations
   2. They enable version control, repeatability, and easier audits
   3. They directly execute shell scripts inside pods
   4. They guarantee zero downtime for all rolling updates

   Explanation: Declarative configurations can be tracked in version control systems, enabling audits and repeatable deployments. They do not automatically handle database migrations or run scripts inside pods. While declarative configs help minimize downtime, they cannot guarantee zero downtime in every scenario.

9. Label Selectors in Deployments

   Why are label selectors important in a Kubernetes Deployment’s pod template?

   1. They define the resource limits of pods
   2. They set up user access control for resources
   3. They ensure the Deployment manages only its own pods by matching specific labels
   4. They configure how storage volumes are mounted

   Explanation: Label selectors connect Deployments with their corresponding pods, ensuring resource management is precise. Labels do not affect storage configurations, access permissions, or resource limits, which have separate configurations in Kubernetes.

10. Environment Variables Setup

    In a CI/CD-driven Kubernetes Deployment, how can you pass application configuration settings into pods?

    1. By placing them in the pod's metadata section
    2. By modifying the cluster control plane
    3. By changing the image pull policy
    4. By defining environment variables in the Deployment spec under the 'env' section

    Explanation: Environment variables are set within the 'env' section of the Deployment spec, making configuration values available to containerized applications. The metadata field is used for identification, image pull policy influences image fetching, and the control plane is unrelated to pod-level environment variables.