Scenario practice questions

A user creates a Deployment with 'replicas: 3'. After applying the manifest, only 2 pods are running. What is the most likely cause?

Trap 1: The Deployment's YAML had a syntax error

A YAML syntax error would cause kubectl apply to reject the manifest outright, so no Deployment would exist and no pods would run. It is tempting because malformed manifests do block creation, but the stem states the Deployment was applied and two pods are running, proving parsing succeeded.

Trap 2: The container image name is misspelled

A misspelled image name produces ImagePullBackOff on affected pods, leaving them in Pending or waiting states rather than running. It is tempting because bad image references are a common cause of missing pods, but here two pods are actually running, indicating scheduling or resource constraints instead.

Trap 3: The ReplicaSet controller is not running

The ReplicaSet controller runs inside the kube-controller-manager, which also manages Deployments; if it were down, no ReplicaSet would exist and zero pods would run, not two. It is tempting because controller failures do stall reconciliation, but that scenario presents as total absence of pods.

A
The Deployment's YAML had a syntax error
Why it fails: A YAML syntax error would cause kubectl apply to reject the manifest outright, so no Deployment would exist and no pods would run. It is tempting because malformed manifests do block creation, but the stem states the Deployment was applied and two pods are running, proving parsing succeeded.
B
There is insufficient node capacity to schedule the third pod
The ReplicaSet controller has created three pods, but the scheduler leaves one Pending because no node has sufficient allocatable CPU or memory. Replica count and scheduling are separate concerns, so insufficient node capacity is the most likely cause.
C
The container image name is misspelled
Why it fails: A misspelled image name produces ImagePullBackOff on affected pods, leaving them in Pending or waiting states rather than running. It is tempting because bad image references are a common cause of missing pods, but here two pods are actually running, indicating scheduling or resource constraints instead.
D
The ReplicaSet controller is not running
Why it fails: The ReplicaSet controller runs inside the kube-controller-manager, which also manages Deployments; if it were down, no ReplicaSet would exist and zero pods would run, not two. It is tempting because controller failures do stall reconciliation, but that scenario presents as total absence of pods.

Question 2mediummultiple choice

A team is deploying a microservices application on Kubernetes. They want to ensure that each microservice can be updated independently without affecting others, and that the application can tolerate the failure of a single microservice. Which cloud-native architecture principle are they applying?

Trap 1: Monolithic architecture

Monolithic architecture bundles all functionality into a single deployable unit, which makes independent updates difficult and increases the blast radius of failures. This contradicts the goal of independent updates and fault tolerance. The scenario describes a microservices approach, not a monolith.

Trap 2: Serverless architecture

Serverless architecture abstracts away infrastructure and scales automatically, but it does not inherently enforce independent updates per microservice in the way described. While serverless functions can be independently deployed, the scenario focuses on microservices and their independent lifecycle, which is a defining trait of microservices architecture.

Trap 3: Service mesh

A service mesh provides traffic management, security, and observability between services, but it is not the architectural principle that enables independent deployment and fault tolerance. The principle being applied is the decomposition into microservices, not the infrastructure layer that manages their communication.

A
Monolithic architecture
Why it fails: Monolithic architecture bundles all functionality into a single deployable unit, which makes independent updates difficult and increases the blast radius of failures. This contradicts the goal of independent updates and fault tolerance. The scenario describes a microservices approach, not a monolith.
B
Microservices architecture
Microservices architecture decomposes an application into small, independent services that can be developed, deployed, and scaled independently. This enables independent updates and fault isolation, as a failure in one service does not necessarily bring down the entire application. The scenario explicitly describes these characteristics, making microservices the correct principle.
C
Serverless architecture
Why it fails: Serverless architecture abstracts away infrastructure and scales automatically, but it does not inherently enforce independent updates per microservice in the way described. While serverless functions can be independently deployed, the scenario focuses on microservices and their independent lifecycle, which is a defining trait of microservices architecture.
D
Service mesh
Why it fails: A service mesh provides traffic management, security, and observability between services, but it is not the architectural principle that enables independent deployment and fault tolerance. The principle being applied is the decomposition into microservices, not the infrastructure layer that manages their communication.

Question 3easymultiple choice

A development team wants to package and deploy a multi-tier application to Kubernetes. They need to template Kubernetes manifests with environment-specific values and manage releases with versioning and rollback capabilities. Which tool is purpose-built for this?

Trap 1: Argo CD

Argo CD is a GitOps continuous delivery tool that syncs Kubernetes manifests from Git. It excels at declarative deployments and drift detection but does not template manifests or provide package versioning. It relies on external tools like Helm or Kustomize for templating. Argo CD alone cannot satisfy the need for templating with environment-specific values and release versioning.

Trap 2: kubectl

kubectl is the Kubernetes command-line tool for applying manifests and managing resources. It does not provide templating, environment-specific value injection, or release versioning. While it can apply YAML files, it lacks the higher-level packaging and lifecycle management features required. Thus, kubectl is not purpose-built for packaging and release management.

Trap 3: Kustomize

Kustomize is a template-free customization tool that overlays patches on base YAML. While it handles environment-specific configurations, it lacks built-in release versioning and rollback capabilities. Kustomize is often used with kubectl apply, but it does not manage releases or provide atomic upgrades. Therefore, it does not fulfill the requirement for release management with versioning and rollback.

A
Argo CD
Why it fails: Argo CD is a GitOps continuous delivery tool that syncs Kubernetes manifests from Git. It excels at declarative deployments and drift detection but does not template manifests or provide package versioning. It relies on external tools like Helm or Kustomize for templating. Argo CD alone cannot satisfy the need for templating with environment-specific values and release versioning.
B
kubectl
Why it fails: kubectl is the Kubernetes command-line tool for applying manifests and managing resources. It does not provide templating, environment-specific value injection, or release versioning. While it can apply YAML files, it lacks the higher-level packaging and lifecycle management features required. Thus, kubectl is not purpose-built for packaging and release management.
C
Kustomize
Why it fails: Kustomize is a template-free customization tool that overlays patches on base YAML. While it handles environment-specific configurations, it lacks built-in release versioning and rollback capabilities. Kustomize is often used with kubectl apply, but it does not manage releases or provide atomic upgrades. Therefore, it does not fulfill the requirement for release management with versioning and rollback.
D
Helm
Helm is the package manager for Kubernetes, designed to template manifests using values files and manage releases with versioning, rollback, and atomic upgrades. It allows teams to define a chart with templates and override values per environment, exactly matching the requirement for environment-specific values and release management. Other tools may assist with deployment but do not provide Helm's integrated packaging and release lifecycle.

Question 4hardmulti select

Which two scenarios would benefit from using a StatefulSet instead of a Deployment? (Choose two.)

Trap 1: A batch job that runs once and exits

Batch jobs require a finite execution lifecycle where pods terminate upon completion, whereas StatefulSets maintain stable network identities and persistent storage bindings for long-running, stateful instances. This scenario is tempting because both manage workloads on Kubernetes; however, Jobs are the correct mechanism for one-off tasks that exit, while StatefulSets provide the ordinal index and persistent volume retention required by distributed databases.

Trap 2: A stateless web application that can scale horizontally

A stateless web application scales horizontally by adding replicas with no need for stable network identities or persistent storage per instance, which a Deployment handles through its default replica management. StatefulSet is tempting because it is designed for workloads requiring ordered startup, unique network identifiers, and persistent volumes—scenarios like databases or message queues where each pod must maintain its own state across rescheduling.

Trap 3: A microservice that can use any available node

Scheduling across any available node is exactly what a Deployment provides, since pods are interchangeable and stateless. StatefulSets are for workloads needing stable network identities and persistent per-pod storage, such as databases or clustered systems with ordered startup and durable volume claims.

A
An application that requires persistent storage unique to each instance
StatefulSet assigns each replica a stable, ordinal identity and its own PersistentVolumeClaim via volumeClaimTemplates, so storage survives rescheduling and remains bound to that pod. A Deployment's replicas share no such per-instance identity, making it unsuitable when each instance needs persistent storage unique to itself.
B
A database cluster that requires stable network identities
StatefulSets assign each pod a stable, ordinal hostname via a headless Service, so cluster members keep predictable DNS names across restarts and rescheduling. A Deployment's pods receive random names and shared load-balanced addressing, which breaks peer discovery and replication. This satisfies the database cluster's requirement for stable network identities.
C
A batch job that runs once and exits
Why it fails: Batch jobs require a finite execution lifecycle where pods terminate upon completion, whereas StatefulSets maintain stable network identities and persistent storage bindings for long-running, stateful instances. This scenario is tempting because both manage workloads on Kubernetes; however, Jobs are the correct mechanism for one-off tasks that exit, while StatefulSets provide the ordinal index and persistent volume retention required by distributed databases.
D
A stateless web application that can scale horizontally
Why it fails: A stateless web application scales horizontally by adding replicas with no need for stable network identities or persistent storage per instance, which a Deployment handles through its default replica management. StatefulSet is tempting because it is designed for workloads requiring ordered startup, unique network identifiers, and persistent volumes—scenarios like databases or message queues where each pod must maintain its own state across rescheduling.
E
A microservice that can use any available node
Why it fails: Scheduling across any available node is exactly what a Deployment provides, since pods are interchangeable and stateless. StatefulSets are for workloads needing stable network identities and persistent per-pod storage, such as databases or clustered systems with ordered startup and durable volume claims.

Question 5mediummultiple choice

A user runs 'kubectl get pods -n production' and sees no output. What is the most likely reason?

Trap 1: The kube-apiserver is down

An unavailable kube-apiserver makes kubectl fail with a connection-refused or timeout error, not silent empty output. It is tempting because API server outages do break kubectl commands; the observed behaviour instead matches a reachable cluster whose production namespace simply contains no pods.

Trap 2: The user does not have permissions to list pods

Insufficient RBAC permissions cause kubectl to return a 'forbidden' error, not empty output, so the command would display an explicit authorisation failure. It is tempting because restricted access does hide pods; the scenario's silent result instead points to the namespace containing no pods or a cluster connectivity problem.

Trap 3: The namespace does not exist

If the namespace doesn't exist, kubectl would return an error.

A
The kube-apiserver is down
Why it fails: An unavailable kube-apiserver makes kubectl fail with a connection-refused or timeout error, not silent empty output. It is tempting because API server outages do break kubectl commands; the observed behaviour instead matches a reachable cluster whose production namespace simply contains no pods.
B
There are no pods in the 'production' namespace
An empty result from `kubectl get pods -n production` means the API server returned zero matching objects, not an error. Since the namespace exists and the query succeeded, the production namespace simply contains no pods, satisfying the stem's observation of no output.
C
The user does not have permissions to list pods
Why it fails: Insufficient RBAC permissions cause kubectl to return a 'forbidden' error, not empty output, so the command would display an explicit authorisation failure. It is tempting because restricted access does hide pods; the scenario's silent result instead points to the namespace containing no pods or a cluster connectivity problem.
D
The namespace does not exist
Why it fails: If the namespace doesn't exist, kubectl would return an error.

Question 6mediummultiple choice

In a multi-cloud scenario, an organization wants to avoid vendor lock-in by abstracting infrastructure provisioning. Which tool is specifically designed to manage infrastructure as code across multiple cloud providers?

Trap 1: Helm

Helm packages and templates Kubernetes manifests into charts; it deploys workloads into a cluster rather than provisioning cloud infrastructure across providers. It is tempting because charts are declarative and reusable, but they target the Kubernetes API, not provider resource APIs, so vendor lock-in at the infrastructure layer remains.

Trap 2: Istio

Istio is a service mesh handling traffic routing, mTLS and observability between workloads; it provisions no cloud infrastructure and abstracts no provider APIs. It is tempting because it spans clusters, but that span is network policy, not resource provisioning, so it cannot deliver the multi-cloud IaC abstraction required.

Trap 3: ArgoCD

ArgoCD is a GitOps continuous delivery controller that synchronises Kubernetes manifests into clusters; it does not provision cloud infrastructure across providers. It is tempting because it manages declarative desired state, but that state covers workloads, not multi-cloud resources, which Terraform handles via provider plugins.

A
Helm
Why it fails: Helm packages and templates Kubernetes manifests into charts; it deploys workloads into a cluster rather than provisioning cloud infrastructure across providers. It is tempting because charts are declarative and reusable, but they target the Kubernetes API, not provider resource APIs, so vendor lock-in at the infrastructure layer remains.
B
Istio
Why it fails: Istio is a service mesh handling traffic routing, mTLS and observability between workloads; it provisions no cloud infrastructure and abstracts no provider APIs. It is tempting because it spans clusters, but that span is network policy, not resource provisioning, so it cannot deliver the multi-cloud IaC abstraction required.
C
Terraform
Terraform uses provider plugins to translate a single HCL configuration into each cloud's native API calls, managing state across AWS, Azure and GCP. This provider abstraction lets the organisation provision identical infrastructure on multiple clouds, directly avoiding vendor lock-in.
D
ArgoCD
Why it fails: ArgoCD is a GitOps continuous delivery controller that synchronises Kubernetes manifests into clusters; it does not provision cloud infrastructure across providers. It is tempting because it manages declarative desired state, but that state covers workloads, not multi-cloud resources, which Terraform handles via provider plugins.