Pods

Pods Quiz

Quiz

Question 1 of 24 (0 answered)

Question 1

What is the smallest and most basic deployable unit in Kubernetes?

Container Pod Deployment Service

✓

Correct!

A Pod is the smallest and most basic deployable unit in Kubernetes. It represents a single instance of a running process in your cluster and can contain one or more containers.

✗

Incorrect

A Pod is the smallest and most basic deployable unit in Kubernetes. It represents a single instance of a running process in your cluster and can contain one or more containers.

Think about what wraps containers in Kubernetes.

Question 2

Which resources are shared by all containers within a Pod?

Network namespace (IP address) Process ID namespace Volumes IPC namespace User namespace

✓

Correct!

Containers in a Pod share the network namespace (same IP), volumes, and IPC namespace. Process namespace is optional. User namespace is typically not shared.

✗

Incorrect

Containers in a Pod share the network namespace (same IP), volumes, and IPC namespace. Process namespace is optional. User namespace is typically not shared.

Consider what allows containers to communicate via localhost and share files.

Question 3

Containers within the same Pod must use different ports to avoid conflicts.

True False

✓

Correct!

Since all containers in a Pod share the same network namespace and IP address, they must use different ports to avoid port conflicts. For example, if nginx uses port 80, a metrics container must use a different port like 9090.

✗

Incorrect

Think about what happens when multiple processes share the same IP address.

Question 4

Containers in a Pod can communicate with each other using which hostname?

✓

Correct!

Since containers in a Pod share the same network namespace, they can communicate with each other using localhost. For example, Container A can reach Container B at localhost:port.

✗

Incorrect

Since containers in a Pod share the same network namespace, they can communicate with each other using localhost. For example, Container A can reach Container B at localhost:port.

It’s the same address you’d use to access services on your own machine.

Question 5

Given this Pod configuration, what will happen when you try to access the writer container’s file from the reader container?

containers:
- name: writer
  image: busybox
  command: ["/bin/sh", "-c", "echo hello > /data/message.txt"]
  volumeMounts:
  - name: shared-data
    mountPath: /data

- name: reader
  image: busybox
  command: ["/bin/sh", "-c", "cat /data/message.txt"]
  volumeMounts:
  - name: shared-data
    mountPath: /data

volumes:
- name: shared-data
  emptyDir: {}

What will this code output?

The reader will successfully read "hello" The reader will get a file not found error Both containers will fail to start Only the writer can access the volume

✓

Correct!

Both containers mount the same volume (shared-data) at /data. The writer creates the file, and the reader can access it because they share the same emptyDir volume. This is a common pattern for data sharing between containers in a Pod.

Key concept: volumes define WHAT storage exists (Pod-level), while volumeMounts define WHERE that storage appears inside each container. The name field is the glue that connects them.

✗

Incorrect

Key concept: volumes define WHAT storage exists (Pod-level), while volumeMounts define WHERE that storage appears inside each container. The name field is the glue that connects them.

Consider what emptyDir volumes are designed for.

Question 6

What is the Sidecar Pattern?

Sidecar Pattern

A multi-container pod pattern where auxiliary containers enhance the primary container’s functionality.

Common Use Cases:

Log aggregation (Fluentd, Filebeat)
Service mesh proxies (Envoy, Istio)
Configuration reloaders
Monitoring agents

Key Characteristic: The sidecar extends or enhances the main container without modifying its code.

Did you get it right?

✓

Correct!

✗

Incorrect

Question 7

Arrange these container lifecycle events in the correct execution order:

Drag to arrange from first to last

⋮⋮ Init Container 1 starts

⋮⋮ Init Container 2 starts

⋮⋮ Init Container 1 completes

⋮⋮ Init Container 2 completes

⋮⋮ Application containers start

✓

Correct!

Init containers run sequentially (serially) before application containers. Each init container must complete successfully before the next one starts. Only after all init containers complete do the application containers start in parallel.

✗

Incorrect

Question 8

Complete the Pod manifest to make the log-aggregator a proper sidecar container (Kubernetes 1.28+):

Fill in the missing field and value

spec:
  initContainers:
  - name: setup
    image: busybox
    command: ['sh', '-c', 'echo Setup complete']
  
  - name: log-aggregator
    image: fluentd
    _____: _____  # Makes it a sidecar
  
  containers:
  - name: app
    image: nginx

Your answer:

✓

Correct!

In Kubernetes 1.28+, sidecar containers are defined in the initContainers section with restartPolicy: Always. This makes them start before app containers but continue running alongside them, unlike regular init containers which terminate after completion.

✗

Incorrect

Question 9

What is the primary purpose of the Ambassador Pattern in multi-container Pods?

To normalize output formats for monitoring To proxy connections to/from the main container To collect and aggregate logs To enhance security through encryption

✓

Correct!

The Ambassador Pattern uses a sidecar container to proxy connections to/from the main container. Common uses include database connection pooling (pgbouncer), service mesh proxies (Envoy), and cloud service proxies. This simplifies the main application by offloading connection management.

✗

Incorrect

Think about what an ambassador does in diplomacy—they represent and facilitate communication.

Question 10

Init containers and application containers within the same Pod run in parallel.

True False

✓

Correct!

Init containers run serially (one after another) and must all complete successfully before application containers start. Application containers then run in parallel. This sequential execution ensures that prerequisites are met before the main application starts.

✗

Incorrect

Consider the purpose of init containers—they prepare the environment.

Question 11

What type of volume is commonly used for sharing data between containers in a Pod when the data doesn’t need to persist beyond the Pod’s lifetime?

✓

Correct!

An emptyDir volume is created when a Pod is assigned to a node and exists as long as the Pod runs. It’s initially empty and is commonly used for sharing data between containers in a Pod. When the Pod is removed, the data in the emptyDir is deleted.

✗

Incorrect

The name describes its initial state.

Question 12

A Pod has two containers: nginx (port 80) and a metrics exporter (port 9090). If you want the metrics exporter to scrape nginx metrics, what address should it use?

The Pod’s IP address (e.g., 10.244.1.5:80) localhost:80 nginx:80 The Service name

✓

Correct!

Containers within the same Pod share the same network namespace, so they can communicate using localhost. The metrics exporter would connect to localhost:80 to access nginx.

✗

Incorrect

Containers within the same Pod share the same network namespace, so they can communicate using localhost. The metrics exporter would connect to localhost:80 to access nginx.

Remember that containers in a Pod share the network namespace.

Question 13

Which statements about Pod characteristics are correct?

Pods are ephemeral and disposable Each Pod has its own unique IP address Containers within a Pod can be split across multiple nodes Pods are the atomic unit of deployment Pods can only contain one container

✓

Correct!

Pods are ephemeral (disposable), have one IP address per Pod, and are atomic units (cannot be split across nodes). Pods commonly contain a single container but can have multiple containers. The atomic nature means all containers in a Pod must run on the same node.

✗

Incorrect

Think about what makes Pods the fundamental building block in Kubernetes.

Question 14

What is the Adapter Pattern in multi-container Pods?

Adapter Pattern (translates)

A multi-container pattern where a sidecar container standardizes or normalizes the output/interface of the main container.

Example Use Case: An application produces custom metrics format → Adapter container converts to Prometheus format → Monitoring system scrapes standardized metrics

Why Use It: Allows legacy or third-party applications to integrate with standardized systems without modifying the original application.

Did you get it right?

✓

Correct!

✗

Incorrect

Question 15

What will be the result of this Pod configuration?

spec:
  initContainers:
  - name: check-db
    image: busybox
    command: ['sh', '-c', 'exit 1']  # Fails
  
  - name: setup-config
    image: busybox
    command: ['sh', '-c', 'echo config > /config/app.conf']
  
  containers:
  - name: app
    image: myapp

What will this code output?

All containers will run successfully The app container will start, but check-db will restart The Pod will fail and app container will never start Only setup-config and app will run

✓

Correct!

Init containers run sequentially and must complete successfully. Since check-db exits with code 1 (failure), the Pod initialization fails. The second init container (setup-config) never runs, and the application container never starts. Kubernetes will retry based on the Pod’s restart policy.

✗

Incorrect

What happens when a prerequisite check fails?

Question 16

Arrange these descriptions to match the patterns in order: Adapter Pattern → Sidecar Pattern → Ambassador Pattern

Drag to match each description to its pattern (Adapter → Sidecar → Ambassador)

⋮⋮ Enhances the main container with auxiliary functionality (e.g., logging, config sync)

⋮⋮ Proxies external network connections on behalf of the main container

⋮⋮ Normalizes or transforms the main container’s output to a standard format

✓

Correct!

Adapter Pattern normalizes/transforms output to a standard format (data transformation). Sidecar Pattern enhances the main container with auxiliary functionality (general purpose helper). Ambassador Pattern proxies external network connections on behalf of the main container (connection management).

✗

Incorrect

Question 17

When should you use a multi-container Pod instead of separate Pods?

When you want to scale containers independently When containers need to communicate frequently and share resources When containers are developed by different teams When you want to reduce resource usage

✓

Correct!

Multi-container Pods should be used when containers must share data, communicate frequently via localhost, scale together, and be co-located on the same node. If containers need independent scaling or are loosely coupled, use separate Pods instead.

✗

Incorrect

Think about tight coupling vs. loose coupling.

Question 18

A Pod’s IP address persists even if the Pod is rescheduled to a different node.

True False

✓

Correct!

Pods are ephemeral, and their IP addresses are not persistent. When a Pod is deleted and recreated (even by a controller like Deployment), it gets a new IP address. This is why you use Services for stable networking.

✗

Incorrect

Consider what ’ephemeral’ means for Pod lifecycle.

Question 19

Complete the init container configuration to wait for the database service db-service on port 5432 to be ready before starting the application:

Fill in the missing command

spec:
  initContainers:
  - name: wait-for-db
    image: busybox:1.36
    command: ['sh', '-c', '_____']
  
  containers:
  - name: app
    image: myapp

Your answer:

✓

Correct!

This command uses nc -z (netcat) to check if port 5432 on db-service is accepting connections. The -z flag performs a zero-I/O scan (just checks if port is open). This is more reliable than DNS checks like nslookup because it verifies the database port is actually ready to accept connections, not just that the service name resolves.

✗

Incorrect

Think about network connectivity testing commands that check if a specific port is open.

Question 20

What field distinguishes a sidecar container from a regular init container in Kubernetes 1.28+?

✓

Correct!

In Kubernetes 1.28+, native sidecar containers are defined in the initContainers section with restartPolicy: Always. This tells Kubernetes to keep the container running alongside application containers, unlike regular init containers which terminate after completion.

✗

Incorrect

It’s about how the container behaves after starting.

Question 21

In a production web service Pod with nginx, fluentd, and Istio proxy, what is the primary role of the Istio proxy?

Collecting and shipping nginx logs Serving web traffic to external users Intercepting and managing all network traffic to/from the Pod Monitoring container health

✓

Correct!

The Istio proxy (Envoy) intercepts all network traffic entering and leaving the Pod. It provides traffic management, security (mTLS), load balancing, and observability without modifying the nginx code. This is the Ambassador/Service Mesh pattern in action.

✗

Incorrect

Service mesh proxies control the network layer.

Question 22

What are valid use cases for init containers?

Waiting for dependencies to become available Continuously collecting logs from the application Pre-populating data or configuration files Setting up file permissions before app starts Proxying traffic to external services

✓

Correct!

Init containers are designed for one-time setup tasks that must complete before the application starts: waiting for dependencies, pre-populating data, setting permissions, etc. Continuous tasks like log collection and traffic proxying should use sidecar containers instead.

✗

Incorrect

Init containers complete and terminate—they’re not for ongoing tasks.

Question 23

Why can’t containers within a Pod be split across different nodes?

Pods are Atomic Units

Pods are the smallest schedulable unit in Kubernetes. All containers in a Pod must run on the same node because:

Shared namespaces and resources: Containers share network namespace and local volumes, requiring co-location on a single node
Localhost communication: Containers communicate over localhost using a shared IP address (only works within same node)
Scheduling semantics: Kubernetes schedules Pods—not individual containers—ensuring tightly coupled containers are co-located

Result: All containers in a Pod always run on the same node, enabling low-latency communication and shared resource access.

Did you get it right?

✓

Correct!

✗

Incorrect

Question 24

The CNI (Container Network Interface) plugin is responsible for assigning IP addresses to Pods and creating the Pod network.

True False

✓

Correct!

CNI plugins implement Pod networking in Kubernetes. They create a unified Pod network across nodes, assign IP addresses to Pods, and enable direct Pod-to-Pod communication without NAT. Examples include Calico, Flannel, and Cilium.

✗

Incorrect

Think about what creates the network layer for Pods.

Quiz Results

Score

0/0

Accuracy

Right

Wrong

Skipped

Last updated on February 23, 2026

Networking Pod Lifecycle