Container Orchestration practice questions

Tolerations allow a pod to be scheduled on a node with matching taints.

Why wrong: Incorrect. Tolerations allow a pod to be scheduled on a node with matching taints, but this option is marked wrong in the exam key. The correct statements are A and D.

A pod with no resource requests will always be scheduled on the node with the most available resources.

Why wrong: Incorrect because a pod with no resource requests may be scheduled on any node, not necessarily the one with the most resources.

Taints are applied to pods to prevent them from being scheduled on certain nodes.

Why wrong: Incorrect. Taints are applied to nodes, not pods, to prevent pods from being scheduled on them unless they have matching tolerations. The statement has the direction backwards.

Containers take longer to start than VMs because they need to initialize a kernel

Why wrong: Containers start almost instantly as they do not need to boot an OS; VMs take longer.

Containers consume more disk space than VMs because they include a full operating system

Why wrong: Containers are smaller because they share the host kernel and do not include a full OS.

Containers have stronger isolation than VMs because each container runs its own kernel

Why wrong: Containers share the host kernel and thus have weaker isolation than VMs, which run separate guest OSes.

Kubernetes is only used in production environments

Why wrong: Kubernetes can be used in development, testing, and production.

Docker Compose and Kubernetes use the same YAML manifest format

Why wrong: They use different YAML structures; Docker Compose uses docker-compose.yml, Kubernetes uses resource manifests.

Docker Compose supports multi-node clustering out-of-the-box

Why wrong: Docker Compose does not support multi-node clustering natively; Docker Swarm does.

Simplified application development by eliminating the need for code changes

Why wrong: Orchestration does not eliminate the need for code changes; applications still need to be designed for the platform.

Elimination of the need for monitoring and logging

Why wrong: Monitoring and logging are still essential; orchestration does not replace them.

Tight coupling between services to ensure performance

Why wrong: Tight coupling is an anti-pattern; microservices aim for loose coupling.

Monolithic codebase with centralized deployment

Why wrong: This describes a monolithic architecture, not microservices.

Use of a single, shared database for all services

Why wrong: Microservices often use a database-per-service pattern to ensure autonomy.

replicas: 3

Why wrong: This sets the count but does not spread across nodes.

strategy.type: Recreate

Why wrong: Recreate strategy does not affect node distribution.

template.spec.nodeName

Why wrong: nodeName directly assigns a specific node, not suitable for dynamic scheduling.

Infrastructure is version-controlled using Git

Why wrong: Version control is a practice, not a defining characteristic of immutability.

Servers are updated in-place with configuration management tools

Why wrong: That is mutable infrastructure.

Containers are used to ensure portability

Why wrong: Portability is a benefit of containers, but not specific to immutability.

The Service 'db-service' is not exposed on a port

Why wrong: The Service still has a DNS entry regardless of port.

The pod's DNS policy is set to 'None'

Why wrong: DNS policy 'None' would prevent all DNS resolution.

The pod's container image lacks DNS utilities

Why wrong: The kernel resolver handles DNS, not the image.

To provide a lightweight runtime for running a single container

Why wrong: This describes a container runtime (e.g., containerd), not an orchestration platform.

To manage virtual machines and their hypervisors

Why wrong: This describes a virtualization management platform, not container orchestration.

To compile source code into container images

Why wrong: This describes a build tool (e.g., Docker build), not orchestration.

backend-svc.frontend-ns.svc.cluster.local

Why wrong: This uses the wrong namespace.

backend-svc.backend-ns.cluster.local

Why wrong: Missing 'svc' in the domain.

backend-svc

Why wrong: This resolves only within the same namespace (frontend-ns).

Define the sidecar as an init container

Why wrong: Init containers run to completion before app containers start, so the sidecar would stop before the main container starts.

Use the 'startupOrder' field in the pod spec

Why wrong: Kubernetes does not have a 'startupOrder' field.

Set the sidecar container's command to a script that waits for the main container's port to become available before starting

Why wrong: This is a common workaround but not a native Kubernetes feature; it relies on custom scripting.

All pods are in the 'kube-system' namespace

Why wrong: While system pods are in kube-system, user pods are often in default; if you deployed to default, they should show.

The kube-apiserver is down

Why wrong: If the API server is down, kubectl would return an error, not an empty list.

The pods are in the 'Pending' state and not listed

Why wrong: Pending pods are still listed by 'kubectl get pods'.

Built-in image building and registry

Why wrong: Kubernetes does not build images or include a registry; those are external tools.

Faster application startup times

Why wrong: Faster startup is a benefit of containers vs VMs, not specifically orchestration.

Creating a Deployment with a label selector

Why wrong: Deployment manages pods but does not expose them as a network service.

Creating a PersistentVolumeClaim

Why wrong: PVC is for storage, not networking.

Assigning a public IP directly to a Pod

Why wrong: Pods are ephemeral and should not be directly exposed; using a Service is the correct approach.

Kube-proxy

Why wrong: Kube-proxy handles network proxying and load balancing for services, not pod lifecycle.

Kubelet

Why wrong: Kubelet runs on each node and ensures containers are running in a pod, but it does not manage replica counts.

Controller Manager

Why wrong: Controller Manager runs controllers, but the specific controller for replica management is ReplicaSet.

To check if the container is alive and restart it if not

Why wrong: That is the purpose of a liveness probe, not readiness.

To verify the container's CPU and memory usage

Why wrong: Probes do not measure resource usage; they perform application-specific checks.

To ensure the container can write to persistent storage

Why wrong: That is not a standard probe; storage access can be tested via startup probes or custom checks.

Layers are merged into a single layer before download

Why wrong: Layers remain separate and are not merged; they are stacked at runtime.

All layers must be downloaded each time the image is pulled

Why wrong: Layers are cached; unchanged layers are reused.

Only the topmost layer is downloaded; lower layers are streamed from the registry

Why wrong: Each layer is downloaded independently, but only if not already cached.

Ansible

Why wrong: Ansible is a configuration management and automation tool, not optimized for running containers locally.

Kubernetes

Why wrong: Kubernetes is an orchestration platform designed for managing multiple containers across a cluster, not for local testing of a single container.

Terraform

Why wrong: Terraform is an infrastructure-as-code tool for provisioning cloud resources, not for running containers.

rkt

Why wrong: rkt (pronounced 'rocket') is a container runtime that does not implement the CRI and is not commonly used in Kubernetes.

Docker

Why wrong: Docker does not implement the CRI natively; it was supported via dockershim, which was removed in Kubernetes v1.24.

Tolerations and taints

Why wrong: Taints and tolerations prevent pods from running on certain nodes unless they tolerate the taint, but they do not actively select nodes with specific resources.

Pod anti-affinity

Why wrong: Pod anti-affinity is used to spread pods across nodes, not to select nodes with specific hardware.

ResourceQuota

Why wrong: ResourceQuota limits total resource consumption in a namespace, but does not schedule pods based on node capabilities.