Docker & Kubernetes quiz

Ten questions at a time, drawn from 120. Every answer is explained. Nothing is saved and no account is needed.

Question 1 of 10Score 0

When you execute 'docker run', what is the specific role of the Docker Daemon?

All Docker & Kubernetes quiz questions and answers

When you execute 'docker run', what is the specific role of the Docker Daemon?
- It acts as a graphical user interface for managing images.
- It receives instructions from the CLI, pulls images if missing, and manages container lifecycles.
- It translates the container code into machine-readable kernel bytecode.
- It provides a persistent database for storing container metadata outside of the host OS.
Answer: It receives instructions from the CLI, pulls images if missing, and manages container lifecycles.. The Daemon acts as the server-side API handler. Option 0 is wrong because the daemon is headless. Option 2 is wrong because Docker uses native host features. Option 3 is wrong because Docker manages its own local storage for metadata.
From lesson: Docker Architecture — Images, Containers, Daemon
What happens to the changes made to the filesystem during the execution of a container?
- They are permanently saved to the original image.
- They are discarded immediately when the container process stops.
- They are stored in a thin writable layer on top of the image layers.
- They are synced automatically to a central registry.
Answer: They are stored in a thin writable layer on top of the image layers.. The writable layer is the defining feature of a running container. Option 0 is wrong because images are immutable. Option 1 is wrong because data persists until the container is removed. Option 3 is wrong because synchronization is a manual 'docker push' process.
From lesson: Docker Architecture — Images, Containers, Daemon
Why does a Docker container usually start much faster than a Virtual Machine?
- Containers use a specialized faster programming language for execution.
- Containers do not need to boot a full guest operating system kernel.
- The Docker Daemon pre-allocates RAM for every possible container.
- Containers bypass the host network stack entirely.
Answer: Containers do not need to boot a full guest operating system kernel.. Containers share the host kernel, skipping the 'hardware initialization' phase of a VM boot. Option 0 is irrelevant. Option 2 is false as resources are allocated on demand. Option 3 is false as containers typically use virtualized network interfaces.
From lesson: Docker Architecture — Images, Containers, Daemon
How are Docker image layers utilized during the build process?
- Each command in a Dockerfile creates a new read-only layer cached for future builds.
- Layers are merged into a single compressed binary file once the build is finished.
- Layers are only used to separate the application code from the operating system.
- Layers are random segments of the image used to increase download speeds.
Answer: Each command in a Dockerfile creates a new read-only layer cached for future builds.. Docker uses a union filesystem where each instruction adds a layer. Option 1 is wrong because layers remain separate entities. Option 2 is wrong as layer separation is granular. Option 3 is wrong as layers are not random.
From lesson: Docker Architecture — Images, Containers, Daemon
If you need to persist a database's data beyond the container's lifecycle, what is the best practice?
- Copy the data to the image using the COPY instruction.
- Mount a volume or bind mount to map a host directory to the container path.
- Enable the 'persistent' flag in the Docker Daemon configuration.
- Save the container state as a new image using 'docker commit'.
Answer: Mount a volume or bind mount to map a host directory to the container path.. Volumes bypass the container's ephemeral writable layer. Option 0 is wrong as image layers are read-only. Option 2 is wrong as no such flag exists. Option 3 is bad practice as it creates large, unmanageable images.
From lesson: Docker Architecture — Images, Containers, Daemon
Why is it recommended to combine multiple RUN commands into one using the '&&' operator?
- It significantly increases the build speed by running commands in parallel.
- It reduces the number of intermediate image layers created, which saves disk space.
- It prevents the Docker daemon from needing to pull a base image.
- It automatically optimizes the CPU usage of the container at runtime.
Answer: It reduces the number of intermediate image layers created, which saves disk space.. Each RUN instruction creates a new layer. Combining commands reduces the layer count. Parallelism is not improved, it does not stop pulls, and it has no effect on runtime CPU usage.
From lesson: Dockerfile — Writing and Best Practices
What is the primary benefit of using a multi-stage build in a Dockerfile?
- It allows a container to run multiple applications simultaneously.
- It automatically deploys the application to a Kubernetes cluster.
- It produces a final image that excludes build tools and temporary source code.
- It creates multiple containers from a single Dockerfile.
Answer: It produces a final image that excludes build tools and temporary source code.. Multi-stage builds allow you to use a heavy 'build' image for compilation, then copy only the required artifacts to a minimal 'runtime' image. It does not control deployments, run multiple apps, or create multiple containers.
From lesson: Dockerfile — Writing and Best Practices
When should you use COPY instead of ADD in a Dockerfile?
- When you need to extract a local tarball automatically into the container.
- When you need to download a remote file from a URL.
- When you are simply moving local files from the build context into the image.
- When you need to copy files from a different Kubernetes node.
Answer: When you are simply moving local files from the build context into the image.. COPY is the best practice for local file movement as it is predictable. ADD has special behavior for tarballs and URLs, which can be unexpected. Neither can copy from other nodes.
From lesson: Dockerfile — Writing and Best Practices
How does the order of lines in a Dockerfile affect the build process?
- It has no impact; Docker reorders instructions to maximize efficiency.
- It dictates the priority of network requests during the build.
- It affects layer caching, where changing an early line invalidates the cache for all later lines.
- It determines which process ID the container starts with.
Answer: It affects layer caching, where changing an early line invalidates the cache for all later lines.. Docker uses cache based on instruction order. If a layer's contents change, all downstream layers must be rebuilt. Docker does not reorder for you, nor does it impact networking or PID assignment.
From lesson: Dockerfile — Writing and Best Practices
What is the purpose of the USER instruction in a Dockerfile?
- It defines which user in the Kubernetes cluster can access the logs.
- It sets the UID or GID for subsequent instructions and the final runtime process.
- It forces the container to prompt for credentials on every startup.
- It restricts the container to only run on nodes where that specific user exists.
Answer: It sets the UID or GID for subsequent instructions and the final runtime process.. USER sets the security context for the container runtime process, adhering to the principle of least privilege. It has no relation to cluster-level log access, interactive prompts, or specific node constraints.
From lesson: Dockerfile — Writing and Best Practices
A developer wants to inspect the output of a background container that keeps crashing immediately. Which command is most appropriate?
- docker run -it my-container
- docker logs my-container
- docker exec my-container tail -f /var/log/app.log
- docker build --no-cache .
Answer: docker logs my-container. docker logs captures the standard output and error of the container process. Option 0 starts a new container, option 2 assumes a log file exists inside the container (which might not be the case), and option 3 builds an image, which is unrelated to existing container state.
From lesson: docker build, run, exec, logs
What is the primary difference between 'docker run' and 'docker exec'?
- run creates a new container; exec runs a command in an existing container.
- run executes a command in the background; exec runs it in the foreground.
- run requires an image; exec requires a container ID.
- run is for building images; exec is for running them.
Answer: run creates a new container; exec runs a command in an existing container.. docker run initializes a container from an image. docker exec operates on an already running container instance. The other options misstate the fundamental purposes of the lifecycle commands.
From lesson: docker build, run, exec, logs
During a build, your image is unnecessarily large. What is the most effective way to optimize the 'docker build' output?
- Use docker exec to delete files after the container starts.
- Use a .dockerignore file to exclude local files from the build context.
- Always use the --no-cache flag.
- Use docker logs to check for file bloat.
Answer: Use a .dockerignore file to exclude local files from the build context.. .dockerignore prevents unnecessary files from being sent to the Docker daemon. Deleting files after the container starts (option 0) doesn't reduce the image size (layers), and the other options do not address the build context size.
From lesson: docker build, run, exec, logs
You have a running web server in a container. You need to verify the internal network configuration. Which command is correct?
- docker run -it <container_id> /bin/bash
- docker build -t net-debug .
- docker exec -it <container_id> ip addr show
- docker logs -f <container_id>
Answer: docker exec -it <container_id> ip addr show. docker exec allows you to run a diagnostic command inside an existing, running container. Option 0 would start a duplicate server, option 1 builds an image, and option 3 displays logs, not network configuration.
From lesson: docker build, run, exec, logs
What happens if you run 'docker run -d my-app' and the container process exits immediately after starting?
- Docker automatically restarts the container indefinitely.
- The container stays in a 'running' state with no active processes.
- The container enters an 'exited' state, and you must check the logs to debug the exit code.
- The host machine will crash.
Answer: The container enters an 'exited' state, and you must check the logs to debug the exit code.. Containers exit when the primary process (PID 1) exits. To diagnose why, you look at the logs. Option 0 only happens if restart policies are configured; option 1 is impossible as a container requires a PID 1; option 3 is incorrect as Docker isolates processes.
From lesson: docker build, run, exec, logs
Which of the following scenarios best justifies the use of a bind mount over a named volume?
- Persisting database data for a production deployment
- Sharing a local source code directory into a container for real-time development feedback
- Ensuring data remains available after a container is deleted in a swarm cluster
- Isolating container storage from the host's underlying file system structure
Answer: Sharing a local source code directory into a container for real-time development feedback. Bind mounts map a specific host path to the container, making them ideal for development loops. Named volumes are better for the other options because they abstract away the host path for portability and security, which is critical for databases and cluster persistence.
From lesson: Docker Volumes — Bind Mounts vs Named Volumes
What happens when you mount an empty host directory to a container path that already contains data?
- The container data is merged with the host directory
- The host directory remains empty while the container keeps its original files
- The container data is hidden (shadowed) by the host directory mount
- Docker throws an error and refuses to start the container
Answer: The container data is hidden (shadowed) by the host directory mount. Bind mounts take precedence; the contents of the container's mount point are hidden by the contents of the host directory. Merging does not happen automatically, and Docker will not prevent this action or ignore the contents of the container's path.
From lesson: Docker Volumes — Bind Mounts vs Named Volumes
How do named volumes improve the portability of your Dockerized application?
- By allowing the container to access any file on the host machine
- By strictly requiring the host to have a directory at /var/lib/docker
- By abstracting the storage location away from specific host filesystem paths
- By automatically copying the host's entire file system into the volume
Answer: By abstracting the storage location away from specific host filesystem paths. Named volumes are managed by the Docker engine rather than the user's file system, allowing the application to run on any OS without changing mount paths. The other options describe insecure practices or misconceptions about how Docker handles abstraction.
From lesson: Docker Volumes — Bind Mounts vs Named Volumes
Why is it generally recommended to use named volumes instead of bind mounts for database containers in production?
- Named volumes provide faster read/write speeds than bind mounts on all operating systems
- Named volumes allow for easier backup and management via Docker CLI commands like 'docker volume ls'
- Bind mounts cannot be used for storing database files because of file locking issues
- Named volumes automatically encrypt all data stored within them
Answer: Named volumes allow for easier backup and management via Docker CLI commands like 'docker volume ls'. Docker CLI commands provide lifecycle management for named volumes, which is cleaner than tracking host paths. Bind mounts can technically store data, but they lack the management abstraction and security benefits offered by named volumes.
From lesson: Docker Volumes — Bind Mounts vs Named Volumes
If you delete a container that was started with a named volume, what happens to the data in that volume?
- The data is deleted immediately along with the container
- The data is archived in the Docker local cache
- The data persists in the Docker managed volume area until explicitly removed
- The data is moved to the host's temporary storage folder
Answer: The data persists in the Docker managed volume area until explicitly removed. Named volumes are decoupled from container lifecycles. They persist even after the container is deleted to prevent data loss. The other options are incorrect as they imply auto-deletion or moving data to locations Docker does not manage.
From lesson: Docker Volumes — Bind Mounts vs Named Volumes
Why is it recommended to use a user-defined bridge network instead of the default bridge network?
- It provides significantly better raw performance for disk I/O.
- It enables automatic DNS resolution for containers using their names.
- It automatically encrypts all traffic between containers without configuration.
- It allows containers to access the host file system directly.
Answer: It enables automatic DNS resolution for containers using their names.. User-defined bridges enable embedded DNS, allowing containers to resolve each other by name. The default bridge does not support this. Performance is similar, encryption is not automatic, and file system access is unrelated to network type.
From lesson: Docker Networks
What happens when you run a container with '--network host'?
- The container is assigned a random private IP from the host's pool.
- The container gains full root access to the host's kernel modules.
- The container shares the network namespace of the host machine.
- The container is isolated from all external network traffic.
Answer: The container shares the network namespace of the host machine.. The host network driver removes network isolation; the container uses the host's IP and ports directly. Option 1 is false because it doesn't get a separate IP; 2 is a security misunderstanding, and 4 is the opposite of the truth.
From lesson: Docker Networks
Two containers are on different user-defined bridge networks. How can they communicate?
- By using the host's IP address and published port.
- They can communicate automatically by default via the Docker daemon.
- By modifying the routing table on the host to bridge the two subnets.
- They can only communicate if one container is disconnected from its current network.
Answer: By using the host's IP address and published port.. Containers on different networks are isolated. They can only interact via the host's IP on a published port. They don't communicate automatically (2), modifying routing tables (3) is not the correct Docker practice, and disconnecting (4) is a workaround, not a method of communication.
From lesson: Docker Networks
When using an overlay network in a Swarm cluster, what is the primary purpose of the 'control plane' traffic?
- To sync container logs across different nodes.
- To manage network configuration, discovery, and load balancing state across nodes.
- To ensure all container images are pre-pulled on every node.
- To bypass the need for an external load balancer.
Answer: To manage network configuration, discovery, and load balancing state across nodes.. The control plane in an overlay network maintains the distributed state of the network. Logs (1), image pulling (3), and load balancing (4) are separate concerns managed by other Docker/Swarm components.
From lesson: Docker Networks
Which command would you use to verify which containers are attached to a specific user-defined network?
- docker inspect <network_name>
- docker network list <network_name>
- docker container ls --network
- docker network connect <network_name>
Answer: docker inspect <network_name>. The 'docker inspect' command provides a detailed JSON output including a 'Containers' map. 'List' only shows network metadata, 'ls --network' is not a valid flag combination, and 'connect' is used to modify the network, not query it.
From lesson: Docker Networks
When defining a service, what is the effect of using 'restart: always' compared to 'restart: unless-stopped'?
- Always attempts to restart regardless of manual intervention.
- Only restarts if the container exited with a non-zero code.
- Unless-stopped requires an explicit docker stop command to prevent restart on daemon startup.
- Always restarts only if the host machine reboots.
Answer: Always attempts to restart regardless of manual intervention.. 'restart: always' will always restart the container after it stops, regardless of manual intervention. 'unless-stopped' will not restart the container if it was manually stopped before the daemon restarted. The other options are incorrect because they mischaracterize the daemon's behavior.
From lesson: docker-compose.yml Syntax
Which of the following describes the correct behavior of the 'extends' keyword in Docker Compose?
- It downloads a remote service configuration from Docker Hub.
- It allows reusing a service configuration from another file to maintain DRY principles.
- It merges two images into a single container instance.
- It forces two services to run on the same virtual network bridge.
Answer: It allows reusing a service configuration from another file to maintain DRY principles.. The 'extends' keyword is specifically designed for sharing common configuration across services or different compose files. It does not pull remote files, merge images, or define network topology.
From lesson: docker-compose.yml Syntax
In a docker-compose.yml file, why would you prefer 'secrets' over environment variables for sensitive data?
- Secrets are faster to load than environment variables.
- Secrets are encrypted at rest and mounted as files, reducing exposure in logs or process lists.
- Secrets allow for automatic rotation every 24 hours.
- Environment variables are deprecated in modern Docker versions.
Answer: Secrets are encrypted at rest and mounted as files, reducing exposure in logs or process lists.. Secrets are mounted into the container as files in /run/secrets, which prevents them from appearing in shell histories or 'docker inspect' output. Environment variables are often leaked. The other claims regarding performance, rotation, and deprecation are false.
From lesson: docker-compose.yml Syntax
What is the primary purpose of the 'deploy' key in a compose file?
- To define the base operating system for the service.
- To configure orchestration options like replicas and resource limits when using Swarm.
- To specify which storage driver the volume uses.
- To force the build of an image before deployment.
Answer: To configure orchestration options like replicas and resource limits when using Swarm.. The 'deploy' key is used for cluster-level configuration (like replicas or CPU limits) compatible with Swarm mode. It is not for image building, base OS definition, or storage driver configuration.
From lesson: docker-compose.yml Syntax
If you define 'ports: - "8080:80"', what is the specific network behavior?
- The container maps port 8080 on the host to port 80 inside the container.
- The container maps port 80 on the host to port 8080 inside the container.
- Both the host and container open port 8080 for internal communication.
- The container blocks all external traffic on port 80.
Answer: The container maps port 8080 on the host to port 80 inside the container.. In 'host:container' syntax, the left side is the host port and the right side is the container port. Option 1 is inverted, option 3 is invalid syntax for port mapping, and option 4 is incorrect as this mapping exposes the container.
From lesson: docker-compose.yml Syntax
When deploying a multi-service application in Kubernetes, why should you use Services rather than direct Pod-to-Pod networking?
- To provide a permanent virtual IP and DNS name that abstracts away the volatility of Pod lifecycles
- Because Pods are physically located on different nodes and cannot communicate directly
- To ensure that all traffic between containers is encrypted by default
- Because services automatically scale the number of underlying Pods based on CPU usage
Answer: To provide a permanent virtual IP and DNS name that abstracts away the volatility of Pod lifecycles. Services provide a stable endpoint because Pod IPs change frequently during restarts (right). Pods can talk directly, so option 1 is false. Services do not handle encryption natively (option 2 is false). Scaling is the job of Deployment controllers, not Services (option 3 is false).
From lesson: Multi-service Applications
What is the primary advantage of using a multi-container Pod in Kubernetes (e.g., sidecar pattern) over running two separate Pods?
- It ensures that both containers are billed as a single unit by the cloud provider
- It allows both containers to share the same local network interface (localhost) and volumes
- It prevents either container from crashing if the other consumes too much memory
- It forces both containers to be deployed on different nodes for high availability
Answer: It allows both containers to share the same local network interface (localhost) and volumes. Containers in the same Pod share the same IPC, network namespace, and storage volumes, facilitating close communication (right). Billing is resource-based, not pod-based (false). Multi-container pods do not inherently prevent crashes (false) and they are co-located on the same node, not spread out (false).
From lesson: Multi-service Applications
How does Docker networking facilitate communication between two containers running on the same host?
- By assigning each container a unique public IP address from the host's subnet
- By mounting the host's kernel into both container filesystems
- By creating a virtual bridge (e.g., docker0) that allows containers to communicate via their private IP addresses
- By utilizing a shared memory space that automatically synchronizes all data files
Answer: By creating a virtual bridge (e.g., docker0) that allows containers to communicate via their private IP addresses. Docker uses virtual bridges to connect container network interfaces, allowing communication through internal IPs (right). Containers do not get public IPs by default (false), sharing the kernel is a security risk/imprecise (false), and shared memory is not a native networking mechanism (false).
From lesson: Multi-service Applications
In a microservices architecture, what is the purpose of a 'Readiness Probe' in Kubernetes?
- To kill a container if it has exceeded its memory limit
- To signal that a container has finished initializing and is prepared to accept user traffic
- To restart a container automatically if it exits with a non-zero status code
- To detect if a container is currently blocked by a network firewall
Answer: To signal that a container has finished initializing and is prepared to accept user traffic. Readiness probes control traffic flow, ensuring the Load Balancer doesn't route traffic to an unready container (right). Liveness probes handle restarts (false), and resource management is handled by limits, not probes (false). Network detection is not the specific goal of a readiness check (false).
From lesson: Multi-service Applications
What happens if you don't use volumes in a containerized multi-service application?
- The application will automatically fail to start because containers require volumes to run
- All data written by the application will be lost when the container is deleted or recreated
- The application will be unable to connect to any external network services
- Kubernetes will automatically create temporary storage that persists across deployments
Answer: All data written by the application will be lost when the container is deleted or recreated. Docker containers have ephemeral storage; once removed, data is gone (right). Containers don't require volumes to boot (false), networking is separate from filesystem persistence (false), and Kubernetes does not create persistent storage without an explicit volume declaration (false).
From lesson: Multi-service Applications
When deploying to Kubernetes, why should you prefer ConfigMaps over building environment variables directly into your Docker image?
- ConfigMaps are encrypted by default, whereas Docker images are not.
- ConfigMaps allow you to update configuration without rebuilding or redeploying the container image.
- Docker images cannot store environment variables, so ConfigMaps are the only option.
- ConfigMaps automatically sync with local .env files on the developer's machine.
Answer: ConfigMaps allow you to update configuration without rebuilding or redeploying the container image.. ConfigMaps decouple configuration from the image, allowing for environment-specific adjustments without recompiling the image. Option 0 is false as ConfigMaps are plain text; option 2 is false as images can have ENV; option 3 is false as there is no automatic local sync.
From lesson: Environment Variables and .env Files
What happens if you define an environment variable in a Dockerfile using ENV and then try to override it using the --env flag during docker run?
- The container fails to start due to a conflict.
- The Dockerfile value takes precedence and cannot be changed.
- The --env flag value overrides the value defined in the Dockerfile.
- Both values are concatenated together into a single string.
Answer: The --env flag value overrides the value defined in the Dockerfile.. Runtime environment variables passed via the command line or container orchestration layers take precedence over values baked into the image via ENV. The other options describe incorrect behaviors regarding variable priority.
From lesson: Environment Variables and .env Files
Which is the most secure method for handling sensitive database credentials when using Kubernetes?
- Hardcoding them as ENV variables in the Dockerfile.
- Storing them in a .env file and copying it into the image during the build process.
- Using Kubernetes Secret objects mounted as environment variables or volumes.
- Passing them as plain text arguments in the docker run command history.
Answer: Using Kubernetes Secret objects mounted as environment variables or volumes.. Kubernetes Secrets are designed to handle sensitive data with better access control and management than hardcoding or including files in images. Hardcoding or copying .env files leaks credentials into the image layer history.
From lesson: Environment Variables and .env Files
Why does using the --env-file flag in Docker not automatically make your application secure?
- The file is only read at image build time, not container start time.
- The environment variables are still injected into the container's environment, where they can be inspected by any process with sufficient permissions.
- Docker automatically uploads the .env file contents to a public registry.
- Environment variables are converted to clear-text logs immediately upon container startup.
Answer: The environment variables are still injected into the container's environment, where they can be inspected by any process with sufficient permissions.. Environment variables are accessible to the process tree and often visible via system tools, which is why they shouldn't be used for highly sensitive secrets if more secure alternatives are available. Other options are technically incorrect regarding how Docker handles those files.
From lesson: Environment Variables and .env Files
If you have a multi-stage Docker build, what is the best way to handle environment variables intended only for the build process?
- Use ENV to set them, so they persist in the final image.
- Use ARG, as these are not persisted in the final image layers.
- Create a temporary .env file and delete it in the same RUN command.
- Inject them via Kubernetes ConfigMaps during the build.
Answer: Use ARG, as these are not persisted in the final image layers.. ARG variables are specifically designed for build-time configuration and do not persist in the final container image, unlike ENV. The other methods either leak data or are functionally incapable of passing build arguments correctly.
From lesson: Environment Variables and .env Files
What is the primary difference between a Liveness probe and a Readiness probe in Kubernetes?
- Liveness probes manage traffic flow, while Readiness probes manage container restarts.
- Liveness probes handle application crashes, while Readiness probes determine when a container is ready to receive traffic.
- Readiness probes are used only for sidecars, while Liveness probes are used for main applications.
- There is no functional difference; they are interchangeable.
Answer: Liveness probes handle application crashes, while Readiness probes determine when a container is ready to receive traffic.. Liveness probes are intended to restart containers that have hung or crashed. Readiness probes control whether the load balancer should send traffic to the pod. Option 0 is backwards. Option 2 is incorrect because both are used for both. Option 3 is false as they have distinct operational purposes.
From lesson: Health Checks
You have a Spring Boot application that takes 45 seconds to initialize. What is the best strategy for health checks?
- Set initialDelaySeconds to 60 in the Liveness probe.
- Use a Startup probe with a successThreshold of 1.
- Use a Readiness probe with a periodSeconds of 60.
- Disable all health checks.
Answer: Use a Startup probe with a successThreshold of 1.. A Startup probe is designed specifically to protect slow-starting containers by disabling Liveness checks until initialization completes. Option 0 is a fragile 'guess-and-check' approach. Option 2 does not prevent the Liveness probe from killing the container. Option 3 is dangerous.
From lesson: Health Checks
When should you use a 'tcpSocket' probe instead of an 'httpGet' probe?
- When the application does not have an HTTP interface but needs to verify a port is listening.
- When you want to check the specific status code of an API response.
- When the application requires authentication headers.
- When the container is running a shell script instead of a binary.
Answer: When the application does not have an HTTP interface but needs to verify a port is listening.. TCP socket probes verify connectivity by opening a connection to a specific port. HTTP probes are required for status codes (Option 1) and headers (Option 2). Shell scripts (Option 3) are typically checked with 'exec' probes.
From lesson: Health Checks
If a container's Readiness probe fails, what does Kubernetes do?
- It restarts the container immediately.
- It stops the container and marks it as 'Failed'.
- It removes the Pod's IP address from the Service's endpoints list.
- It ignores the failure if the Liveness probe is passing.
Answer: It removes the Pod's IP address from the Service's endpoints list.. Readiness failures prevent traffic from reaching the pod, which is achieved by removing the pod from the Service load balancer. Option 0 describes a Liveness probe action. Option 1 is incorrect as the pod remains running. Option 3 is wrong because the two probes act independently.
From lesson: Health Checks
Why is it important to set the 'timeoutSeconds' field in a health probe?
- To define how long the container takes to start up.
- To limit how long the probe waits for a response before considering it a failure.
- To determine how often the probe runs.
- To set the maximum number of restarts allowed.
Answer: To limit how long the probe waits for a response before considering it a failure.. The timeout determines the maximum time allowed for the probe to respond before Kubernetes marks it as failed. Options 0, 2, and 3 correspond to 'initialDelaySeconds', 'periodSeconds', and 'restartPolicy' or 'failureThreshold', respectively.
From lesson: Health Checks
If the etcd component fails, what is the immediate impact on the Kubernetes cluster functionality?
- Existing pods on worker nodes stop running immediately
- The cluster becomes read-only and state changes cannot be persisted
- The kubelet automatically restarts the etcd service
- The API server continues to schedule new pods normally
Answer: The cluster becomes read-only and state changes cannot be persisted. The API server relies on etcd for state; if etcd is down, the cluster state cannot be updated, making it read-only. Pods continue running (A is wrong), kubelet manages nodes, not etcd (C is wrong), and scheduling requires state updates (D is wrong).
From lesson: Kubernetes Architecture — Master and Worker Nodes
Which component is primarily responsible for ensuring that the desired state of the cluster matches the current state?
- Kube-scheduler
- Kube-proxy
- Controller Manager
- Container Runtime
Answer: Controller Manager. The Controller Manager runs control loops that watch the state and make changes to reach the desired state. Scheduler just assigns nodes (A), proxy handles networking (B), and runtime manages containers (D), not cluster state.
From lesson: Kubernetes Architecture — Master and Worker Nodes
What is the primary role of the Kubelet on a Worker Node?
- Directing traffic between services
- Managing the lifecycle of containers based on pod specifications
- Storing the configuration of the entire cluster
- Communicating with other worker nodes to share memory
Answer: Managing the lifecycle of containers based on pod specifications. The Kubelet ensures containers described in PodSpecs are running and healthy. Traffic routing is Kube-proxy (A), cluster configuration is in etcd (C), and memory sharing is not a standard Kubernetes feature (D).
From lesson: Kubernetes Architecture — Master and Worker Nodes
Why does the Kubernetes architecture separate the Control Plane from Worker Nodes?
- To allow workers to run different operating systems than the master
- To isolate management processes from application workloads for security and stability
- To enable the master node to host the container runtime interface
- To reduce the number of IP addresses required for the cluster
Answer: To isolate management processes from application workloads for security and stability. Separation prevents application crashes or resource exhaustion from affecting the cluster management. Masters don't have to use different OS (A), runtime is for workers (C), and IP count isn't the architectural driver (D).
From lesson: Kubernetes Architecture — Master and Worker Nodes
When a user submits a manifest to the API Server, what is the sequence of events?
- API Server updates etcd, then Scheduler assigns a node, then Kubelet executes
- Kube-proxy assigns the node, then API Server updates etcd
- Container Runtime creates the pod, then API Server updates etcd
- Controller Manager deploys the pod, then Scheduler updates the API Server
Answer: API Server updates etcd, then Scheduler assigns a node, then Kubelet executes. The API Server validates the request and writes to etcd; the Scheduler notices the new pod and assigns it to a node; the Kubelet on that node sees the assignment and starts the container. Others (B, C, D) incorrectly assign responsibilities.
From lesson: Kubernetes Architecture — Master and Worker Nodes
Why is it generally discouraged to create a standalone Pod instead of using a ReplicaSet?
- Standalone Pods require more storage space on the cluster
- Standalone Pods lack the ability to handle network traffic
- Standalone Pods do not recover automatically if the node hosting them terminates
- Standalone Pods cannot be assigned an IP address within the cluster
Answer: Standalone Pods do not recover automatically if the node hosting them terminates. A standalone Pod is not managed by a controller, so if the node dies, the Pod is gone. ReplicaSets provide self-healing by replacing failed Pods. The other options are incorrect because Pods can handle traffic, have IPs, and do not inherently consume more storage.
From lesson: Pods and ReplicaSets
A ReplicaSet is configured with 3 replicas. If you manually delete one of the Pods it manages, what is the immediate behavior of the Kubernetes controller?
- It will wait for a periodic resync to notice the change
- It will detect the deficit and immediately schedule a new Pod to reach the desired count
- It will lock the namespace to prevent further deletions
- It will terminate the remaining two Pods to maintain consistency
Answer: It will detect the deficit and immediately schedule a new Pod to reach the desired count. The ReplicaSet controller continuously monitors the cluster state; upon detecting a discrepancy between actual and desired replicas, it immediately creates a new Pod. The other options describe non-existent or incorrect reconciliation logic.
From lesson: Pods and ReplicaSets
What is the primary purpose of the 'selector' field in a ReplicaSet definition?
- To define which container image the Pod should use
- To specify which node in the cluster should host the Pods
- To identify which existing Pods fall under the management of this ReplicaSet
- To set the security context for the Pod's environment
Answer: To identify which existing Pods fall under the management of this ReplicaSet. The selector tells the controller which Pods it is responsible for by matching their labels. It does not select nodes, set container images, or define security contexts.
From lesson: Pods and ReplicaSets
If you update the container image in a ReplicaSet's Pod template, what happens to the currently running Pods?
- They are immediately updated in place without downtime
- They continue to run using the old image until they are manually deleted
- The ReplicaSet automatically restarts the container process
- The ReplicaSet kills all Pods and replaces them with new ones simultaneously
Answer: They continue to run using the old image until they are manually deleted. ReplicaSets do not perform rolling updates; existing Pods are immutable and continue running until deleted. The other options describe features of Deployments or incorrect behavior regarding Pod lifecycle.
From lesson: Pods and ReplicaSets
What happens if a Pod's labels are changed so they no longer match the ReplicaSet selector?
- The ReplicaSet will immediately terminate the Pod
- The ReplicaSet loses ownership of that Pod and creates a new one to replace it
- The Pod will be automatically re-labeled to match the selector
- The ReplicaSet will ignore the change and continue managing the Pod
Answer: The ReplicaSet loses ownership of that Pod and creates a new one to replace it. Once the labels no longer match, the ReplicaSet no longer considers that Pod part of its managed set; seeing the count drop below the target, it will spin up a new Pod. The other options are incorrect as the controller does not auto-modify existing objects.
From lesson: Pods and ReplicaSets
If you have 10 replicas and set 'maxSurge' to 2 and 'maxUnavailable' to 0, what is the behavior during a rolling update?
- It will scale down to 8 and then up to 10
- It will create 2 new pods before terminating any old pods
- It will terminate 2 pods and then create 2 new pods
- It will update all 10 pods simultaneously
Answer: It will create 2 new pods before terminating any old pods. With maxSurge=2 and maxUnavailable=0, K8s creates new pods first, ensuring capacity never drops below 10. The other options describe scenarios where capacity drops (violating maxUnavailable=0) or where no surge occurs.
From lesson: Deployments — Rolling Updates and Rollbacks
What is the primary purpose of a Deployment Revision in Kubernetes?
- To record the history of changes for rollback purposes
- To enable high availability across multiple clusters
- To store the secrets used by the container images
- To define the network policies for the pods
Answer: To record the history of changes for rollback purposes. Revisions allow users to track changes and perform rollbacks to a specific previous configuration. The other options refer to networking, security, or multi-cluster architecture, not the rollout mechanism.
From lesson: Deployments — Rolling Updates and Rollbacks
Why would a rolling update stop and stay in a 'progressing' state indefinitely?
- The Deployment reached the maxSurge limit
- The new pods are failing their readiness probes
- The cluster has reached its maximum pod count
- The old pods are still processing incoming traffic
Answer: The new pods are failing their readiness probes. If readiness probes fail, the Deployment controller will not consider the new pods 'Ready' and will not proceed with terminating old pods. The other options do not prevent a deployment from progressing toward its target state.
From lesson: Deployments — Rolling Updates and Rollbacks
What happens when you run 'kubectl rollout undo' on a deployment that is currently updating?
- It stops the deployment and leaves it in an inconsistent state
- It pauses the update and waits for manual intervention
- It reverts the deployment to the previous revision
- It immediately deletes all existing pods
Answer: It reverts the deployment to the previous revision. Rolling undo reverts the deployment configuration to the state recorded in the previous revision. The other options suggest either errors or destructive actions that don't align with K8s' declarative nature.
From lesson: Deployments — Rolling Updates and Rollbacks
When performing a rolling update, how does the Service object know which pods to send traffic to?
- By identifying the specific Pod IDs in the Deployment
- By tracking the Pod creation timestamps
- By matching the Pod labels to the Service selector
- By communicating directly with the Container Runtime
Answer: By matching the Pod labels to the Service selector. Services use label selectors to dynamically discover pods. As old pods are terminated and new ones created, they all share the same labels, allowing for seamless traffic shifting. The other methods are not how Services discover pods.
From lesson: Deployments — Rolling Updates and Rollbacks
Which of the following best describes the fundamental difference between ClusterIP and NodePort?
- ClusterIP provides a stable internal IP; NodePort opens a static port on every node in the cluster.
- ClusterIP routes traffic from the internet; NodePort is only for local processes.
- ClusterIP requires an external IP; NodePort is restricted to inter-pod communication.
- ClusterIP manages LoadBalancer settings; NodePort is only used for debugging.
Answer: ClusterIP provides a stable internal IP; NodePort opens a static port on every node in the cluster.. ClusterIP is the default and provides an internal IP only accessible within the cluster. NodePort extends this by opening a port on every node, allowing traffic from outside the cluster. The other options reverse these roles or assign incorrect purposes.
From lesson: Services — ClusterIP, NodePort, LoadBalancer
When is it most appropriate to use a LoadBalancer service type?
- When you want to enable service discovery between pods in the same namespace.
- When you need a cloud provider to provision a dedicated external IP for your application.
- When you are running a cluster on a local machine without network access.
- When you want to prevent all external traffic from hitting your containers.
Answer: When you need a cloud provider to provision a dedicated external IP for your application.. LoadBalancer is designed to request an external IP from the cloud provider, which automatically configures the infrastructure to route traffic to the pods. ClusterIP is for internal discovery, and local clusters rarely support LoadBalancer without extra configuration.
From lesson: Services — ClusterIP, NodePort, LoadBalancer
You have a frontend service that needs to talk to a backend service. Which service type is the most efficient choice?
- NodePort, because it is more secure.
- LoadBalancer, because it provides a public IP.
- ClusterIP, because it provides internal load balancing without exposing the service externally.
- ExternalName, because it automatically scales the pods.
Answer: ClusterIP, because it provides internal load balancing without exposing the service externally.. ClusterIP is the standard for service-to-service communication because it is internal, performant, and secure. NodePort and LoadBalancer expose services to the network, increasing attack surface unnecessarily. ExternalName is used for CNAME aliasing.
From lesson: Services — ClusterIP, NodePort, LoadBalancer
What happens if you delete a Pod that is currently being targeted by a Service?
- The Service automatically updates its endpoint list to stop sending traffic to that deleted pod.
- The Service stops working entirely and must be redeployed.
- The Service continues trying to send traffic to the dead IP address until manually updated.
- The NodePort closes automatically to prevent errors.
Answer: The Service automatically updates its endpoint list to stop sending traffic to that deleted pod.. The Kubernetes control plane continuously monitors Pod labels and the Service's selector. When a pod is deleted, its endpoint is removed from the service automatically. The other options imply a static configuration that does not reflect Kubernetes dynamic nature.
From lesson: Services — ClusterIP, NodePort, LoadBalancer
Why might a LoadBalancer service stay in a 'Pending' state indefinitely?
- Because the pods are running too fast.
- Because the cluster has too many internal services.
- Because the underlying infrastructure lacks a controller capable of provisioning an external IP.
- Because the NodePort range is full.
Answer: Because the underlying infrastructure lacks a controller capable of provisioning an external IP.. LoadBalancer 'Pending' usually means no cloud-controller-manager or compatible solution (like MetalLB) is present to interact with the infrastructure to fetch an IP. Pod speed, number of services, and NodePort ranges are unrelated to external IP provisioning.
From lesson: Services — ClusterIP, NodePort, LoadBalancer
If you define an Ingress resource in a namespace, what happens if no Ingress Controller is running in your cluster?
- The cluster automatically assigns a default controller.
- The Ingress resource remains created, but no traffic routing occurs.
- Kubernetes will throw an error and refuse to create the Ingress resource.
- Traffic is routed to all services in the cluster by default.
Answer: The Ingress resource remains created, but no traffic routing occurs.. Ingress objects are declarative configuration. Without a controller process to watch the API server and update routing logic (like NGINX config), the Ingress resource is merely stored data. Option 0 and 3 are false as there is no implicit routing, and option 2 is false because the API server accepts valid manifests regardless of available controllers.
From lesson: Ingress and Ingress Controllers
Which of the following best describes the relationship between an Ingress Controller and an Ingress Resource?
- The Ingress Controller is the data, and the Ingress Resource is the application logic.
- The Ingress Resource is the physical load balancer hardware.
- The Ingress Controller is the implementation, while the Ingress Resource is the configuration.
- They are redundant components that perform identical tasks.
Answer: The Ingress Controller is the implementation, while the Ingress Resource is the configuration.. The Ingress resource defines the desired state (routing rules, paths), while the controller acts as the control loop that reconciles that state by configuring a reverse proxy. Option 0 is backwards, option 1 is false because it's software-defined, and option 3 is incorrect because they serve distinct roles.
From lesson: Ingress and Ingress Controllers
When configuring multiple paths for the same host in an Ingress, why is order sometimes significant?
- The Ingress Controller processes rules based on their alphabetical order.
- Longer, more specific paths must be evaluated before shorter, prefix-based paths to prevent routing conflicts.
- Kubernetes requires path length to be even to avoid parsing errors.
- The controller always defaults to the first path defined in the YAML.
Answer: Longer, more specific paths must be evaluated before shorter, prefix-based paths to prevent routing conflicts.. Because many controllers use prefix matching, if you place a generic root path ('/') before a specific path ('/api'), the root path will match everything, effectively shadowing the '/api' rule. The other options describe non-existent behaviors.
From lesson: Ingress and Ingress Controllers
Why must an Ingress Controller typically have a service type of LoadBalancer or be exposed via NodePort?
- To allow the Ingress resource to automatically create a new database connection.
- To provide a stable external entry point for traffic to reach the cluster from outside.
- To allow the Ingress Controller to communicate with the Kubernetes API server.
- To bypass the need for Pod IP addresses in the cluster.
Answer: To provide a stable external entry point for traffic to reach the cluster from outside.. An Ingress Controller resides inside the cluster; to receive requests from the internet, it must be exposed. Options 0, 2, and 3 are unrelated to the primary function of exposing the controller for external ingress.
From lesson: Ingress and Ingress Controllers
What is the primary purpose of the 'host' field in an Ingress rule?
- To specify the physical machine where the service is running.
- To implement virtual hosting, allowing one controller to route traffic based on the domain name.
- To limit which users can access the service.
- To define the port number the container listens on internally.
Answer: To implement virtual hosting, allowing one controller to route traffic based on the domain name.. The host field enables Name-Based Virtual Hosting, allowing you to host multiple websites or services on a single LoadBalancer IP. It does not control physical placement (0), user permissions (2), or internal container ports (3).
From lesson: Ingress and Ingress Controllers
If you need to update a configuration file managed by a ConfigMap mounted as a volume, what is the best way to ensure the application picks up the change?
- Delete and recreate the deployment
- Wait for the kubelet to sync the volume and ensure the application watches the file for changes
- Restart the Kubernetes API server
- Update the ConfigMap and manually execute a kill command on the process inside the container
Answer: Wait for the kubelet to sync the volume and ensure the application watches the file for changes. Mounting as a volume allows for atomic updates via symbolic link swapping. If the application is designed to watch the file, it will refresh without a restart. Option 0 and 3 are invasive, and option 2 is not necessary for configuration sync.
From lesson: ConfigMaps and Secrets
Why is a Kubernetes Secret not considered a 'vault' or 'encryption-at-rest' solution by default?
- Secrets are only stored in memory
- Secrets are base64 encoded by default, not encrypted
- Secrets are only available to the namespace creator
- Secrets do not support RBAC policies
Answer: Secrets are base64 encoded by default, not encrypted. Kubernetes Secrets are base64 encoded, which is encoding, not encryption. Anyone with etcd access can decode them. Option 0 is false, option 2 is false as they can be shared across namespaces if needed, and option 3 is false because RBAC is the primary way to secure them.
From lesson: ConfigMaps and Secrets
What happens to a pod if you update a ConfigMap that is being consumed strictly as an environment variable?
- The environment variable in the pod updates automatically after a short delay
- The pod will automatically restart to pick up the new value
- The pod will continue to use the original value until the pod is recreated
- The container process will crash due to a mismatch in configuration
Answer: The pod will continue to use the original value until the pod is recreated. Environment variables are injected at pod creation time. Changes to the source ConfigMap do not reflect in existing pods. Option 0 is false, option 1 does not happen automatically, and option 3 is incorrect as the process has no way of knowing the config changed.
From lesson: ConfigMaps and Secrets
Which of the following is the most secure way to consume a Secret containing a TLS private key in a pod?
- Injecting it as an environment variable
- Mounting the secret as a volume at a specific path
- Passing it as an argument in the command list
- Storing it directly in the Dockerfile as a build argument
Answer: Mounting the secret as a volume at a specific path. Mounting as a volume keeps sensitive files off the process environment and logs. Environment variables (0) and command arguments (2) can be logged or inspected by unauthorized users. Option 3 is a major security vulnerability.
From lesson: ConfigMaps and Secrets
When defining a ConfigMap, what is the significance of the 'data' versus the 'binaryData' field?
- data is for JSON, binaryData is for YAML
- data is for UTF-8 encoded strings, binaryData is for base64 encoded binary blobs
- binaryData allows for larger files than the data field
- data is encrypted, while binaryData is not
Answer: data is for UTF-8 encoded strings, binaryData is for base64 encoded binary blobs. ConfigMaps use 'data' for standard string-based key-value pairs, while 'binaryData' is intended for non-textual data like images or certificates. The other options misrepresent the structural intent of the fields.
From lesson: ConfigMaps and Secrets
A developer needs a volume that can be shared across multiple nodes in a Kubernetes cluster for a web application. Which access mode must the PersistentVolume support?
- ReadWriteOnce
- ReadOnlyMany
- ReadWriteMany
- ReadWriteOncePod
Answer: ReadWriteMany. ReadWriteMany is the only mode that allows multiple nodes to mount the volume in read-write mode. ReadWriteOnce is limited to one node, ReadOnlyMany does not allow writing, and ReadWriteOncePod is restricted to a single specific pod instance.
From lesson: Persistent Volumes and Claims
What is the primary benefit of using a StorageClass in a Kubernetes environment?
- It forces all pods to use the same storage backend.
- It enables dynamic provisioning of PVs based on PVC requests.
- It provides a way to backup volumes to off-site storage.
- It allows manual mounting of local host paths without permissions.
Answer: It enables dynamic provisioning of PVs based on PVC requests.. StorageClasses allow for dynamic provisioning, meaning admins don't need to pre-create PVs. The other options are incorrect because storage classes do not mandate backend uniformity for the whole cluster, are not backup tools, and are distinct from local path mounting.
From lesson: Persistent Volumes and Claims
If a PersistentVolume has a Reclaim Policy of 'Retain', what happens to the data when the corresponding PVC is deleted?
- The data is automatically wiped to ensure security.
- The PV is deleted immediately, but the data remains on the disk.
- The PV object is released from the claim, but the data is preserved for manual recovery.
- The PV enters a 'Pending' state until a new PVC is created.
Answer: The PV object is released from the claim, but the data is preserved for manual recovery.. Retain means the PV object and the physical data remain intact, allowing an admin to recover it. It is not wiped automatically (Delete policy does that), the PV object is not deleted, and it does not enter a pending state for re-assignment automatically.
From lesson: Persistent Volumes and Claims
Why would a pod using a PersistentVolumeClaim remain in a 'Pending' state indefinitely?
- The node has insufficient RAM for the volume.
- No available PersistentVolume matches the requirements of the PVC.
- The Pod is running in the 'kube-system' namespace.
- The image pull secret is missing from the volume spec.
Answer: No available PersistentVolume matches the requirements of the PVC.. A PVC remains pending if it cannot bind to a PV (e.g., storage class mismatch, size requirement). RAM usage is unrelated to volume binding, namespace location does not affect binding, and image secrets are for container images, not volume provisioning.
From lesson: Persistent Volumes and Claims
How does Kubernetes ensure that a specific Pod is attached to the correct PersistentVolume?
- By matching the labels and selectors defined in the PVC and PV.
- By mounting the volume based on the Pod's name.
- By verifying the UID of the container process.
- By randomly assigning available volumes during startup.
Answer: By matching the labels and selectors defined in the PVC and PV.. Kubernetes uses labels and selectors (or capacity requirements) to bind PVCs to compatible PVs. Pod names, UIDs, and random assignment are not mechanisms used for storage binding logic.
From lesson: Persistent Volumes and Claims
What happens to a pod if the container exceeds its memory limit?
- The kernel throttles the CPU usage until memory usage drops
- Kubernetes automatically increases the memory limit
- The container is terminated and potentially restarted with an OOMKilled status
- The pod is evicted to another node with more memory
Answer: The container is terminated and potentially restarted with an OOMKilled status. Memory is a non-compressible resource; the kernel cannot 'throttle' it, so it must terminate the process. Throttling only applies to CPU. Kubernetes does not auto-scale limits, and eviction is triggered by node-level pressure, not single-container limits.
From lesson: Resource Requests and Limits
If a pod requests 500m CPU and sets a limit of 1000m, what does this guarantee?
- The pod will always get 1000m CPU at all times
- The pod is guaranteed 500m CPU, and can burst up to 1000m if available
- The pod will be throttled if it exceeds 500m CPU
- The pod can use all available CPU on the node regardless of the 1000m limit
Answer: The pod is guaranteed 500m CPU, and can burst up to 1000m if available. Requests are reserved resources. Limits define the maximum cap. The container is guaranteed its request, but may access unused node CPU up to the limit. Throttling only occurs when exceeding the 1000m limit.
From lesson: Resource Requests and Limits
Which of the following describes the 'Burstable' Quality of Service class?
- Requests are equal to limits for all containers in the pod
- No requests or limits are set for any container in the pod
- The pod has at least one request/limit set, but they are not equal
- The pod is only assigned to nodes with unlimited CPU resources
Answer: The pod has at least one request/limit set, but they are not equal. Burstable occurs when requests are defined but not equal to limits. 'Guaranteed' requires all requests to equal limits. 'BestEffort' is when no requests or limits exist. Nodes do not have 'unlimited' resources.
From lesson: Resource Requests and Limits
Why is it recommended to set CPU requests even if you don't strictly require a minimum amount?
- To allow the Kubernetes scheduler to place the pod on a node with sufficient capacity
- To prevent the node from entering a 'Ready' state
- To ensure the application uses more CPU than it actually needs
- To bypass the need for memory requests
Answer: To allow the Kubernetes scheduler to place the pod on a node with sufficient capacity. The scheduler uses requests to calculate the remaining capacity of a node. Without requests, the scheduler cannot account for the pod's footprint, leading to node overloading. This has no effect on node state or CPU consumption efficiency.
From lesson: Resource Requests and Limits
What is the primary difference between how CPU and memory are managed when limits are reached?
- CPU is a compressible resource that can be throttled; memory is incompressible and leads to termination
- Memory is a compressible resource; CPU is incompressible
- Both are managed by terminating the process when the limit is reached
- Neither resource is actually enforced by the kernel
Answer: CPU is a compressible resource that can be throttled; memory is incompressible and leads to termination. CPU can be restricted by time-slicing (throttling), while memory cannot be partially allocated or throttled without crashing the process. Termination is the standard outcome for memory, but not for CPU.
From lesson: Resource Requests and Limits
If you deploy a Pod into 'namespace-a', how can a Service in 'namespace-b' connect to it?
- It cannot connect because namespaces provide strict network isolation.
- It must use the FQDN including the namespace suffix.
- It can connect using just the Pod's local name because DNS is cluster-wide.
- It can connect only if the Pod is assigned a LoadBalancer service type.
Answer: It must use the FQDN including the namespace suffix.. Option 2 is correct because Kubernetes DNS uses a specific schema (service.namespace.svc.cluster.local) to locate resources outside the current namespace. Option 1 is wrong because namespaces don't block traffic by default; Option 3 is wrong because short names resolve only within the current namespace; Option 4 is wrong because internal traffic uses ClusterIP services, not external LoadBalancers.
From lesson: Namespaces
Which of the following resources is NOT scoped to a specific namespace in Kubernetes?
- ConfigMap
- PersistentVolumeClaim
- PersistentVolume
- Secret
Answer: PersistentVolume. Option 3 is correct because PersistentVolumes (PVs) represent cluster-level storage resources, while PersistentVolumeClaims (PVCs) are the namespaced requests for that storage. The other options (ConfigMaps, PVCs, and Secrets) are all namespaced resources.
From lesson: Namespaces
What is the primary benefit of using multiple namespaces in a shared Kubernetes cluster?
- To improve the physical security of the underlying hardware nodes.
- To enable resource quota management for different teams or environments.
- To increase the speed at which Pods boot up on a node.
- To bypass the need for separate Ingress Controllers.
Answer: To enable resource quota management for different teams or environments.. Option 2 is correct because namespaces allow admins to apply ResourceQuotas to limit CPU and memory usage per project. Option 1 is wrong as namespaces are logical, not physical; Option 3 is wrong because they do not impact scheduling speed; Option 4 is wrong because namespaces usually require their own Ingress rules.
From lesson: Namespaces
You attempt to delete a namespace, but it remains stuck in the 'Terminating' state. What is the most likely cause?
- There are still cluster-wide resources like Nodes registered to that namespace.
- A finalizer is preventing the deletion because dependent objects exist.
- The namespace has too many labels to be deleted immediately.
- The API server is currently configured for a single namespace per cluster.
Answer: A finalizer is preventing the deletion because dependent objects exist.. Option 2 is correct; finalizers ensure dependent resources are cleaned up before the parent namespace object is removed. Option 1 is wrong because Nodes are not namespaced; Option 3 is wrong because labels do not prevent deletion; Option 4 is wrong because Kubernetes supports multiple namespaces by default.
From lesson: Namespaces
When configuring ResourceQuotas, what happens if you do not set a limit on a specific namespace?
- The namespace will automatically consume the cluster's entire capacity.
- The namespace will be unable to run any Pods.
- The Kubernetes scheduler will reject all new deployment requests to that namespace.
- The namespace will be limited only by the total resources available on the nodes.
Answer: The namespace will be limited only by the total resources available on the nodes.. Option 4 is correct; quotas are optional constraints, and without them, a namespace is only limited by the total hardware capacity of the cluster nodes. Option 1 is false because it competes with other namespaces; Option 2 and 3 are false because Kubernetes does not enforce empty quotas by default.
From lesson: Namespaces
Which command allows you to view the logs of a pod that has multiple containers?
- kubectl logs <pod-name>
- kubectl logs <pod-name> --all-containers
- kubectl logs <pod-name> -c <container-name>
- kubectl describe pod <pod-name> --logs
Answer: kubectl logs <pod-name> -c <container-name>. You must specify the container name with -c because logs are stream-specific. The first option fails if there are multiple containers, the second is not a valid flag, and the fourth describes the pod metadata rather than outputting application logs.
From lesson: kubectl Cheat Sheet
What is the primary difference between 'kubectl apply' and 'kubectl create'?
- Create is for YAML, apply is for JSON
- Apply is declarative, create is imperative
- Create allows live patching, apply does not
- Apply automatically restarts the cluster
Answer: Apply is declarative, create is imperative. Apply manages the resource state declaratively by comparing the current live state with the manifest; create forces the creation of a resource and fails if it already exists. The other options are incorrect interpretations of their functional purpose.
From lesson: kubectl Cheat Sheet
You have a deployment, but changes to your Docker image tag are not reflecting. What is the most efficient command to force a redeploy?
- kubectl rollout restart deployment <name>
- kubectl delete deployment <name>
- kubectl update deployment <name>
- kubectl scale deployment <name> --replicas=0
Answer: kubectl rollout restart deployment <name>. Rollout restart triggers a rolling update, effectively forcing pods to pull the new image. Deleting the deployment is destructive, 'update' is not a native command, and scaling to zero destroys the pods without ensuring the new image is pulled upon scaling back up.
From lesson: kubectl Cheat Sheet
If you need to execute a command inside a running pod to troubleshoot, which command is correct?
- kubectl run <pod-name> -- <command>
- kubectl exec -it <pod-name> -- <command>
- kubectl attach <pod-name> -c <command>
- kubectl debug <pod-name> -- <command>
Answer: kubectl exec -it <pod-name> -- <command>. Exec is designed to run a process in an existing container. 'Run' creates a new pod, 'attach' connects to the main process, and 'debug' is for ephemeral containers, not standard command execution in the main container.
From lesson: kubectl Cheat Sheet
How do you temporarily expose a pod to the internet for testing purposes without creating a formal Service manifest?
- kubectl port-forward pod/<name> 8080:80
- kubectl expose pod/<name> --type=LoadBalancer
- kubectl proxy <name>
- kubectl map pod/<name> 80:8080
Answer: kubectl port-forward pod/<name> 8080:80. Port-forwarding creates a tunnel from your local machine to the pod, ideal for quick testing. Expose creates a persistent Service object, proxy is for API access, and 'map' is not a valid kubectl command.
From lesson: kubectl Cheat Sheet
What is the primary role of the 'values.yaml' file in a Helm chart?
- To define the static deployment manifest structure
- To provide default configuration values that can be overridden
- To list the container image registry credentials
- To execute post-installation hook scripts
Answer: To provide default configuration values that can be overridden. The values.yaml file provides the default settings that are injected into templates. The other options are incorrect because static structures are in templates, registry credentials are handled by secrets, and hooks are defined in manifest metadata, not as core values.
From lesson: Helm Charts — Packaging K8s Apps
Why is the 'helm template' command commonly used during development?
- To install the chart into a staging namespace
- To verify how manifests render without communicating with the Tiller or K8s API
- To automatically upgrade an existing release in the cluster
- To generate a Dockerfile for the application
Answer: To verify how manifests render without communicating with the Tiller or K8s API. Helm template allows developers to inspect the rendered YAML output locally. It does not install anything (wrong), is not an upgrade tool (wrong), and does not build container images (wrong).
From lesson: Helm Charts — Packaging K8s Apps
When defining a dependency in a Helm chart, what is the purpose of the 'alias' field?
- To rename the dependency to avoid namespace collisions
- To specify the image tag version of the dependency
- To bypass the need for a Chart.lock file
- To allow multiple instances of the same subchart with different configurations
Answer: To allow multiple instances of the same subchart with different configurations. Aliases allow you to include the same subchart multiple times under different names, each with unique values. It is not for renaming for collisions (wrong), not for versioning (wrong), and does not bypass locking (wrong).
From lesson: Helm Charts — Packaging K8s Apps
What happens if a Helm release fails during an 'upgrade' process?
- The cluster automatically deletes all pods in the namespace
- The release remains in a 'failed' state, and changes are not automatically rolled back unless specified
- The entire Kubernetes cluster is reset to its factory state
- The system ignores the error and continues to the next manifest
Answer: The release remains in a 'failed' state, and changes are not automatically rolled back unless specified. Helm keeps track of release history; a failed upgrade stops the process to prevent corruption. The other options describe catastrophic outcomes that do not happen in K8s/Helm workflows.
From lesson: Helm Charts — Packaging K8s Apps
Which component of a Helm chart is used to include custom logic for clean-up or initialization during a deployment lifecycle?
- Chart.yaml metadata
- The _helpers.tpl file
- Helm Hooks
- The values-schema.json file
Answer: Helm Hooks. Hooks allow you to run code at specific lifecycle points. Metadata is for identification, helpers are for template code reuse, and schema files are for validation, none of which manage lifecycle execution.
From lesson: Helm Charts — Packaging K8s Apps
If you have a deployment with 2 pods and an HPA target CPU utilization of 50%, what happens if the current average CPU utilization is 80%?
- The HPA terminates both pods and recreates them.
- The HPA increases the replica count to approximately 3 or 4 pods.
- The HPA keeps the replica count at 2 because the threshold is not exceeded.
- The HPA immediately scales the deployment to the maximum configured replicas.
Answer: The HPA increases the replica count to approximately 3 or 4 pods.. The formula used is (currentMetricValue / targetMetricValue) * currentReplicas. (80/50) * 2 = 3.2, so HPA scales to 4. Option 0 is incorrect because HPA modifies replicas, not restarts pods. Option 2 is incorrect because 80% is above the 50% threshold. Option 3 is incorrect because HPA rarely jumps straight to max unless the calculation dictates it.
From lesson: Horizontal Pod Autoscaling
Why is it mandatory to define resource requests in a Pod spec when using HPA?
- To ensure the Pod has enough memory to start.
- Because HPA calculates 'percentage of utilization' based on the requested resource value.
- To provide a hard limit on how many pods the cluster can run.
- To allow the Kubernetes scheduler to place pods on the correct nodes.
Answer: Because HPA calculates 'percentage of utilization' based on the requested resource value.. HPA defines 'utilization' as a percentage of the requested capacity. If no requests are set, the HPA cannot determine what '100% utilization' means. Options 0, 2, and 3 describe scheduling or operational benefits, but they are not the reason the HPA controller requires requests for its logic.
From lesson: Horizontal Pod Autoscaling
What is the role of the 'stabilization window' in HPA downscaling?
- It speeds up the creation of new pods during a traffic spike.
- It prevents rapid 'flapping' of replica counts by waiting before scaling down.
- It forces the cluster to stay at minimum replicas during high load.
- It forces the cluster to use only the most efficient nodes for the pods.
Answer: It prevents rapid 'flapping' of replica counts by waiting before scaling down.. The stabilization window ensures the system does not scale down too quickly if metrics fluctuate briefly. It keeps the higher number of replicas for a set duration. Option 0 is wrong because it applies to scaling down, not up. Options 2 and 3 are incorrect as they do not relate to the purpose of the stabilization window.
From lesson: Horizontal Pod Autoscaling
What happens if the Metrics Server is missing from your Kubernetes cluster?
- HPA will default to scaling based on node disk usage.
- HPA will fail to fetch metrics and the replica count will remain unchanged.
- The cluster will automatically restart to install the missing component.
- Pods will be deleted to save resources.
Answer: HPA will fail to fetch metrics and the replica count will remain unchanged.. Without the Metrics Server, the HPA controller cannot retrieve the metrics required for its scaling algorithm, so it cannot calculate replica changes. It does not auto-install (0), change to disk metrics (0), or delete pods (3).
From lesson: Horizontal Pod Autoscaling
Which of the following is true regarding scaling based on custom metrics?
- It is possible using an adapter that connects the Metrics Server to external monitoring systems.
- It is not supported in any version of Kubernetes.
- It only works if the pod is written in a specific language.
- It requires editing the kube-apiserver source code.
Answer: It is possible using an adapter that connects the Metrics Server to external monitoring systems.. Custom metrics require a custom metrics API server (adapter) to expose data from external sources. Option 1 is wrong because it is supported. Option 2 is wrong because scaling is independent of the application language. Option 3 is wrong because configuration is done via resources, not code changes.
From lesson: Horizontal Pod Autoscaling
When configuring Prometheus to monitor a Kubernetes cluster, why is it preferred to use service discovery rather than static target lists?
- It reduces the total number of metrics collected by the server.
- Pods are ephemeral and their IP addresses change frequently when replaced or scaled.
- Static lists increase the CPU overhead of the Prometheus pod significantly.
- Service discovery automatically generates Grafana dashboards for new services.
Answer: Pods are ephemeral and their IP addresses change frequently when replaced or scaled.. Service discovery is essential because Kubernetes continuously destroys and recreates pods; static IP lists would become stale immediately. Option 0 is wrong as it does not affect volume, option 2 is incorrect regarding performance, and option 3 is false as discovery does not automate dashboard creation.
From lesson: Monitoring with Prometheus and Grafana
Which mechanism ensures that Prometheus can query metrics from pods that are not directly exposed to the external network?
- Configuring a LoadBalancer service for every single pod.
- Using the Kubernetes API server as a proxy for all metric requests.
- Exposing pods through a ClusterIP service and letting Prometheus scrape them via the internal network.
- Enabling external access in the Docker daemon settings.
Answer: Exposing pods through a ClusterIP service and letting Prometheus scrape them via the internal network.. Prometheus runs inside the cluster and accesses pods via the internal virtual network using ClusterIP services. Option 0 is unnecessary and inefficient; option 1 is not how Prometheus communicates; option 3 is irrelevant to internal cluster communication.
From lesson: Monitoring with Prometheus and Grafana
What is the primary function of a 'relabel_config' block in a Prometheus scrape configuration?
- To define which alerts should be sent to the Alertmanager.
- To modify, drop, or add metadata labels to targets before they are scraped.
- To increase the retention period of the stored time-series data.
- To authenticate the Prometheus server against the Kubernetes API.
Answer: To modify, drop, or add metadata labels to targets before they are scraped.. Relabeling allows administrators to normalize or filter metadata labels dynamically before the scrape occurs. Option 0 belongs to alerting rules, option 2 belongs to storage configuration, and option 3 relates to RBAC.
From lesson: Monitoring with Prometheus and Grafana
In a Grafana dashboard monitoring Kubernetes, what does a 'rate(http_requests_total[5m])' query represent?
- The cumulative total of requests since the container started.
- The total number of requests in the last 5 minutes.
- The per-second average rate of requests over a 5-minute sliding window.
- The maximum number of requests processed by a single pod.
Answer: The per-second average rate of requests over a 5-minute sliding window.. The rate function calculates the per-second increase over the specified time range, which is critical for seeing throughput trends. Option 0 is just a counter, option 1 is an increase() calculation, and option 3 is a max() function.
From lesson: Monitoring with Prometheus and Grafana
Why should you use persistent storage for Prometheus in a production Kubernetes environment?
- To allow multiple Prometheus replicas to share the same metrics database.
- To prevent loss of metric history when a pod is rescheduled or updated.
- To increase the scraping speed of the underlying disk subsystem.
- To enable the use of non-standard Prometheus metric formats.
Answer: To prevent loss of metric history when a pod is rescheduled or updated.. Since pods in Kubernetes are ephemeral, any data not on persistent storage is wiped upon termination. Option 0 is incorrect as Prometheus doesn't support shared write access to the same storage; option 2 is false as disks don't speed up scraping; option 3 is unrelated to data format.
From lesson: Monitoring with Prometheus and Grafana
What is the primary advantage of using a multi-stage Docker build in a production environment?
- It speeds up the process of building the Dockerfile layers.
- It allows for the creation of smaller images by excluding build-time dependencies.
- It enables the container to run on both Docker and Kubernetes simultaneously.
- It automatically configures the networking bridge for the container.
Answer: It allows for the creation of smaller images by excluding build-time dependencies.. Multi-stage builds allow you to use a heavy image to compile code and copy only the final binary to a small runtime image. The other options are incorrect because multi-stage builds don't necessarily speed up layer caching, are not related to orchestration compatibility, and do not influence container networking.
From lesson: Docker Interview Questions
When you run 'docker build', how does Docker determine whether to use a cached layer?
- By checking if the file modification time has changed on the host.
- By comparing the command string in the Dockerfile with previously executed steps.
- By performing a checksum of the files in the context directory.
- By checking if the container registry has a newer version of the base image.
Answer: By comparing the command string in the Dockerfile with previously executed steps.. Docker compares the instruction string of the current step with existing layers. If the instruction and the layers preceding it match, it uses the cache. The other options are wrong because Docker does not primarily rely on file modification times, checksums of the entire context, or remote registry versioning for layer cache validation.
From lesson: Docker Interview Questions
Which of the following best describes the difference between CMD and ENTRYPOINT?
- CMD is for running tasks, while ENTRYPOINT is only for defining metadata.
- CMD provides default arguments that can be easily overridden, while ENTRYPOINT defines the executable.
- ENTRYPOINT allows multiple commands to be run simultaneously, while CMD only allows one.
- CMD is executed during the build phase, whereas ENTRYPOINT is executed during the runtime phase.
Answer: CMD provides default arguments that can be easily overridden, while ENTRYPOINT defines the executable.. ENTRYPOINT sets the primary command that always runs, while CMD provides parameters that can be overridden at runtime. The other options are incorrect as they misstate the roles or the timing of execution for these instructions.
From lesson: Docker Interview Questions
In a Kubernetes environment, why is it considered a best practice to use a Readiness Probe?
- To restart the container if it crashes due to an out-of-memory error.
- To inform the Load Balancer that the application is fully started and ready to receive traffic.
- To check if the container has sufficient CPU resources to run the process.
- To secure the container from external unauthorized access.
Answer: To inform the Load Balancer that the application is fully started and ready to receive traffic.. Readiness probes tell the service that the container is ready to accept requests. Liveness probes handle restarts (option 1), Resource quotas handle CPU limits (option 3), and Network policies handle security (option 4), making those incorrect.
From lesson: Docker Interview Questions
What is the result of using the 'ADD' instruction instead of 'COPY' in a Dockerfile?
- ADD allows the source to be a URL and can automatically extract tar archives.
- ADD always creates a more secure layer than COPY.
- COPY is strictly for local files, while ADD is strictly for remote networking.
- ADD is the newer, more efficient instruction that replaces COPY entirely.
Answer: ADD allows the source to be a URL and can automatically extract tar archives.. ADD has the added functionality of fetching files from URLs and unpacking tar files automatically, while COPY is more explicit and secure for local files. The other options are incorrect because ADD is not more secure, COPY can also handle local files, and COPY is preferred over ADD when extraction/URLs aren't needed.
From lesson: Docker Interview Questions
When a Deployment is updated to a new container image, how does Kubernetes ensure there is no downtime during the transition?
- It deletes all old pods and replaces them with new ones simultaneously.
- It uses a RollingUpdate strategy to incrementally replace pods while maintaining readiness.
- It pauses all incoming traffic until the new pods are fully operational.
- It uses a Recreate strategy to perform a seamless swap of existing processes.
Answer: It uses a RollingUpdate strategy to incrementally replace pods while maintaining readiness.. The RollingUpdate strategy ensures availability by spinning up new pods before removing old ones. Simultaneous deletion leads to downtime, pausing traffic is not a native behavior, and Recreate shuts down all instances before starting new ones.
From lesson: Kubernetes Interview Questions
What is the primary role of a Service in a Kubernetes cluster?
- To provide a persistent storage volume for containers.
- To monitor the CPU and memory usage of the nodes.
- To provide a stable network endpoint for a group of dynamic Pods.
- To manage the authentication of users accessing the cluster API.
Answer: To provide a stable network endpoint for a group of dynamic Pods.. Services abstract the ephemeral nature of Pod IPs by providing a single stable DNS name and IP. Storage is handled by PersistentVolumes, monitoring by metrics-server, and authentication by RBAC, not Services.
From lesson: Kubernetes Interview Questions
Why is it generally better to use a ConfigMap rather than hardcoding environment variables in a Deployment manifest?
- ConfigMaps allow for automatic container image rebuilding.
- ConfigMaps decouple configuration from the application image, allowing the same image to run in different environments.
- ConfigMaps are the only way to store encrypted credentials.
- ConfigMaps allow the Pod to automatically restart when a configuration change is detected.
Answer: ConfigMaps decouple configuration from the application image, allowing the same image to run in different environments.. Decoupling configuration enables the same image to be promoted across environments. Rebuilding is not a function of ConfigMaps, secrets (not ConfigMaps) store credentials, and Pods do not automatically restart on ConfigMap changes.
From lesson: Kubernetes Interview Questions
If a Pod is stuck in a 'CrashLoopBackOff' state, what is the most logical first step for troubleshooting?
- Restart the entire Kubernetes cluster.
- Check the container logs using kubectl logs to identify the application error.
- Increase the resource limits for the node.
- Change the container runtime from Docker to a different engine.
Answer: Check the container logs using kubectl logs to identify the application error.. Checking application logs reveals why the process inside the container is failing immediately. Restarting the cluster is destructive, resource limits rarely cause crash loops, and the runtime engine is usually not the culprit for basic crashes.
From lesson: Kubernetes Interview Questions
What is the purpose of a Readiness Probe in a Pod specification?
- To kill the container if it uses too much memory.
- To signal to the Service that the Pod is ready to accept network traffic.
- To restart the container if the application process exits with an error.
- To ensure the container has finished downloading all external dependencies.
Answer: To signal to the Service that the Pod is ready to accept network traffic.. Readiness probes prevent traffic from being routed to a Pod that isn't ready. Liveness probes handle restarting failed containers, and resource limits manage memory usage; dependency management is an application-level concern.
From lesson: Kubernetes Interview Questions

Docker & Kubernetes quiz

Ten questions at a time, drawn from 120. Every answer is explained. Nothing is saved and no account is needed.

Question 1 of 10Score 0

When you execute 'docker run', what is the specific role of the Docker Daemon?

All Docker & Kubernetes quiz questions and answers

When you execute 'docker run', what is the specific role of the Docker Daemon?

It acts as a graphical user interface for managing images.
It receives instructions from the CLI, pulls images if missing, and manages container lifecycles.
It translates the container code into machine-readable kernel bytecode.
It provides a persistent database for storing container metadata outside of the host OS.

Answer: It receives instructions from the CLI, pulls images if missing, and manages container lifecycles.. The Daemon acts as the server-side API handler. Option 0 is wrong because the daemon is headless. Option 2 is wrong because Docker uses native host features. Option 3 is wrong because Docker manages its own local storage for metadata.

From lesson: Docker Architecture — Images, Containers, Daemon

What happens to the changes made to the filesystem during the execution of a container?

They are permanently saved to the original image.
They are discarded immediately when the container process stops.
They are stored in a thin writable layer on top of the image layers.
They are synced automatically to a central registry.

Answer: They are stored in a thin writable layer on top of the image layers.. The writable layer is the defining feature of a running container. Option 0 is wrong because images are immutable. Option 1 is wrong because data persists until the container is removed. Option 3 is wrong because synchronization is a manual 'docker push' process.

From lesson: Docker Architecture — Images, Containers, Daemon

Why does a Docker container usually start much faster than a Virtual Machine?

Containers use a specialized faster programming language for execution.
Containers do not need to boot a full guest operating system kernel.
The Docker Daemon pre-allocates RAM for every possible container.
Containers bypass the host network stack entirely.

Answer: Containers do not need to boot a full guest operating system kernel.. Containers share the host kernel, skipping the 'hardware initialization' phase of a VM boot. Option 0 is irrelevant. Option 2 is false as resources are allocated on demand. Option 3 is false as containers typically use virtualized network interfaces.

From lesson: Docker Architecture — Images, Containers, Daemon

How are Docker image layers utilized during the build process?

Each command in a Dockerfile creates a new read-only layer cached for future builds.
Layers are merged into a single compressed binary file once the build is finished.
Layers are only used to separate the application code from the operating system.
Layers are random segments of the image used to increase download speeds.

Answer: Each command in a Dockerfile creates a new read-only layer cached for future builds.. Docker uses a union filesystem where each instruction adds a layer. Option 1 is wrong because layers remain separate entities. Option 2 is wrong as layer separation is granular. Option 3 is wrong as layers are not random.

From lesson: Docker Architecture — Images, Containers, Daemon

If you need to persist a database's data beyond the container's lifecycle, what is the best practice?

Copy the data to the image using the COPY instruction.
Mount a volume or bind mount to map a host directory to the container path.
Enable the 'persistent' flag in the Docker Daemon configuration.
Save the container state as a new image using 'docker commit'.

Answer: Mount a volume or bind mount to map a host directory to the container path.. Volumes bypass the container's ephemeral writable layer. Option 0 is wrong as image layers are read-only. Option 2 is wrong as no such flag exists. Option 3 is bad practice as it creates large, unmanageable images.

From lesson: Docker Architecture — Images, Containers, Daemon

Why is it recommended to combine multiple RUN commands into one using the '&&' operator?

It significantly increases the build speed by running commands in parallel.
It reduces the number of intermediate image layers created, which saves disk space.
It prevents the Docker daemon from needing to pull a base image.
It automatically optimizes the CPU usage of the container at runtime.

Answer: It reduces the number of intermediate image layers created, which saves disk space.. Each RUN instruction creates a new layer. Combining commands reduces the layer count. Parallelism is not improved, it does not stop pulls, and it has no effect on runtime CPU usage.

From lesson: Dockerfile — Writing and Best Practices

What is the primary benefit of using a multi-stage build in a Dockerfile?

It allows a container to run multiple applications simultaneously.
It automatically deploys the application to a Kubernetes cluster.
It produces a final image that excludes build tools and temporary source code.
It creates multiple containers from a single Dockerfile.

Answer: It produces a final image that excludes build tools and temporary source code.. Multi-stage builds allow you to use a heavy 'build' image for compilation, then copy only the required artifacts to a minimal 'runtime' image. It does not control deployments, run multiple apps, or create multiple containers.

From lesson: Dockerfile — Writing and Best Practices

When should you use COPY instead of ADD in a Dockerfile?

When you need to extract a local tarball automatically into the container.
When you need to download a remote file from a URL.
When you are simply moving local files from the build context into the image.
When you need to copy files from a different Kubernetes node.

Answer: When you are simply moving local files from the build context into the image.. COPY is the best practice for local file movement as it is predictable. ADD has special behavior for tarballs and URLs, which can be unexpected. Neither can copy from other nodes.

From lesson: Dockerfile — Writing and Best Practices

How does the order of lines in a Dockerfile affect the build process?

It has no impact; Docker reorders instructions to maximize efficiency.
It dictates the priority of network requests during the build.
It affects layer caching, where changing an early line invalidates the cache for all later lines.
It determines which process ID the container starts with.

Answer: It affects layer caching, where changing an early line invalidates the cache for all later lines.. Docker uses cache based on instruction order. If a layer's contents change, all downstream layers must be rebuilt. Docker does not reorder for you, nor does it impact networking or PID assignment.

From lesson: Dockerfile — Writing and Best Practices

What is the purpose of the USER instruction in a Dockerfile?

It defines which user in the Kubernetes cluster can access the logs.
It sets the UID or GID for subsequent instructions and the final runtime process.
It forces the container to prompt for credentials on every startup.
It restricts the container to only run on nodes where that specific user exists.

Answer: It sets the UID or GID for subsequent instructions and the final runtime process.. USER sets the security context for the container runtime process, adhering to the principle of least privilege. It has no relation to cluster-level log access, interactive prompts, or specific node constraints.

From lesson: Dockerfile — Writing and Best Practices

A developer wants to inspect the output of a background container that keeps crashing immediately. Which command is most appropriate?

docker run -it my-container
docker logs my-container
docker exec my-container tail -f /var/log/app.log
docker build --no-cache .

Answer: docker logs my-container. docker logs captures the standard output and error of the container process. Option 0 starts a new container, option 2 assumes a log file exists inside the container (which might not be the case), and option 3 builds an image, which is unrelated to existing container state.

From lesson: docker build, run, exec, logs

What is the primary difference between 'docker run' and 'docker exec'?

run creates a new container; exec runs a command in an existing container.
run executes a command in the background; exec runs it in the foreground.
run requires an image; exec requires a container ID.
run is for building images; exec is for running them.

Answer: run creates a new container; exec runs a command in an existing container.. docker run initializes a container from an image. docker exec operates on an already running container instance. The other options misstate the fundamental purposes of the lifecycle commands.

From lesson: docker build, run, exec, logs

During a build, your image is unnecessarily large. What is the most effective way to optimize the 'docker build' output?

Use docker exec to delete files after the container starts.
Use a .dockerignore file to exclude local files from the build context.
Always use the --no-cache flag.
Use docker logs to check for file bloat.

Answer: Use a .dockerignore file to exclude local files from the build context.. .dockerignore prevents unnecessary files from being sent to the Docker daemon. Deleting files after the container starts (option 0) doesn't reduce the image size (layers), and the other options do not address the build context size.

From lesson: docker build, run, exec, logs

You have a running web server in a container. You need to verify the internal network configuration. Which command is correct?

docker run -it <container_id> /bin/bash
docker build -t net-debug .
docker exec -it <container_id> ip addr show
docker logs -f <container_id>

Answer: docker exec -it <container_id> ip addr show. docker exec allows you to run a diagnostic command inside an existing, running container. Option 0 would start a duplicate server, option 1 builds an image, and option 3 displays logs, not network configuration.

From lesson: docker build, run, exec, logs

What happens if you run 'docker run -d my-app' and the container process exits immediately after starting?

Docker automatically restarts the container indefinitely.
The container stays in a 'running' state with no active processes.
The container enters an 'exited' state, and you must check the logs to debug the exit code.
The host machine will crash.

Answer: The container enters an 'exited' state, and you must check the logs to debug the exit code.. Containers exit when the primary process (PID 1) exits. To diagnose why, you look at the logs. Option 0 only happens if restart policies are configured; option 1 is impossible as a container requires a PID 1; option 3 is incorrect as Docker isolates processes.

From lesson: docker build, run, exec, logs

Which of the following scenarios best justifies the use of a bind mount over a named volume?

Persisting database data for a production deployment
Sharing a local source code directory into a container for real-time development feedback
Ensuring data remains available after a container is deleted in a swarm cluster
Isolating container storage from the host's underlying file system structure

Answer: Sharing a local source code directory into a container for real-time development feedback. Bind mounts map a specific host path to the container, making them ideal for development loops. Named volumes are better for the other options because they abstract away the host path for portability and security, which is critical for databases and cluster persistence.

From lesson: Docker Volumes — Bind Mounts vs Named Volumes

What happens when you mount an empty host directory to a container path that already contains data?

The container data is merged with the host directory
The host directory remains empty while the container keeps its original files
The container data is hidden (shadowed) by the host directory mount
Docker throws an error and refuses to start the container

Answer: The container data is hidden (shadowed) by the host directory mount. Bind mounts take precedence; the contents of the container's mount point are hidden by the contents of the host directory. Merging does not happen automatically, and Docker will not prevent this action or ignore the contents of the container's path.

From lesson: Docker Volumes — Bind Mounts vs Named Volumes

How do named volumes improve the portability of your Dockerized application?

By allowing the container to access any file on the host machine
By strictly requiring the host to have a directory at /var/lib/docker
By abstracting the storage location away from specific host filesystem paths
By automatically copying the host's entire file system into the volume

Answer: By abstracting the storage location away from specific host filesystem paths. Named volumes are managed by the Docker engine rather than the user's file system, allowing the application to run on any OS without changing mount paths. The other options describe insecure practices or misconceptions about how Docker handles abstraction.

From lesson: Docker Volumes — Bind Mounts vs Named Volumes

Why is it generally recommended to use named volumes instead of bind mounts for database containers in production?

Named volumes provide faster read/write speeds than bind mounts on all operating systems
Named volumes allow for easier backup and management via Docker CLI commands like 'docker volume ls'
Bind mounts cannot be used for storing database files because of file locking issues
Named volumes automatically encrypt all data stored within them

Answer: Named volumes allow for easier backup and management via Docker CLI commands like 'docker volume ls'. Docker CLI commands provide lifecycle management for named volumes, which is cleaner than tracking host paths. Bind mounts can technically store data, but they lack the management abstraction and security benefits offered by named volumes.

From lesson: Docker Volumes — Bind Mounts vs Named Volumes

If you delete a container that was started with a named volume, what happens to the data in that volume?

The data is deleted immediately along with the container
The data is archived in the Docker local cache
The data persists in the Docker managed volume area until explicitly removed
The data is moved to the host's temporary storage folder

Answer: The data persists in the Docker managed volume area until explicitly removed. Named volumes are decoupled from container lifecycles. They persist even after the container is deleted to prevent data loss. The other options are incorrect as they imply auto-deletion or moving data to locations Docker does not manage.

From lesson: Docker Volumes — Bind Mounts vs Named Volumes

Why is it recommended to use a user-defined bridge network instead of the default bridge network?

It provides significantly better raw performance for disk I/O.
It enables automatic DNS resolution for containers using their names.
It automatically encrypts all traffic between containers without configuration.
It allows containers to access the host file system directly.

Answer: It enables automatic DNS resolution for containers using their names.. User-defined bridges enable embedded DNS, allowing containers to resolve each other by name. The default bridge does not support this. Performance is similar, encryption is not automatic, and file system access is unrelated to network type.

From lesson: Docker Networks

What happens when you run a container with '--network host'?

The container is assigned a random private IP from the host's pool.
The container gains full root access to the host's kernel modules.
The container shares the network namespace of the host machine.
The container is isolated from all external network traffic.

Answer: The container shares the network namespace of the host machine.. The host network driver removes network isolation; the container uses the host's IP and ports directly. Option 1 is false because it doesn't get a separate IP; 2 is a security misunderstanding, and 4 is the opposite of the truth.

From lesson: Docker Networks

Two containers are on different user-defined bridge networks. How can they communicate?

By using the host's IP address and published port.
They can communicate automatically by default via the Docker daemon.
By modifying the routing table on the host to bridge the two subnets.
They can only communicate if one container is disconnected from its current network.

Answer: By using the host's IP address and published port.. Containers on different networks are isolated. They can only interact via the host's IP on a published port. They don't communicate automatically (2), modifying routing tables (3) is not the correct Docker practice, and disconnecting (4) is a workaround, not a method of communication.

From lesson: Docker Networks

When using an overlay network in a Swarm cluster, what is the primary purpose of the 'control plane' traffic?

To sync container logs across different nodes.
To manage network configuration, discovery, and load balancing state across nodes.
To ensure all container images are pre-pulled on every node.
To bypass the need for an external load balancer.

Answer: To manage network configuration, discovery, and load balancing state across nodes.. The control plane in an overlay network maintains the distributed state of the network. Logs (1), image pulling (3), and load balancing (4) are separate concerns managed by other Docker/Swarm components.

From lesson: Docker Networks

Which command would you use to verify which containers are attached to a specific user-defined network?

docker inspect <network_name>
docker network list <network_name>
docker container ls --network
docker network connect <network_name>

Answer: docker inspect <network_name>. The 'docker inspect' command provides a detailed JSON output including a 'Containers' map. 'List' only shows network metadata, 'ls --network' is not a valid flag combination, and 'connect' is used to modify the network, not query it.

From lesson: Docker Networks

When defining a service, what is the effect of using 'restart: always' compared to 'restart: unless-stopped'?

Always attempts to restart regardless of manual intervention.
Only restarts if the container exited with a non-zero code.
Unless-stopped requires an explicit docker stop command to prevent restart on daemon startup.
Always restarts only if the host machine reboots.

Answer: Always attempts to restart regardless of manual intervention.. 'restart: always' will always restart the container after it stops, regardless of manual intervention. 'unless-stopped' will not restart the container if it was manually stopped before the daemon restarted. The other options are incorrect because they mischaracterize the daemon's behavior.

From lesson: docker-compose.yml Syntax

Which of the following describes the correct behavior of the 'extends' keyword in Docker Compose?

It downloads a remote service configuration from Docker Hub.
It allows reusing a service configuration from another file to maintain DRY principles.
It merges two images into a single container instance.
It forces two services to run on the same virtual network bridge.

Answer: It allows reusing a service configuration from another file to maintain DRY principles.. The 'extends' keyword is specifically designed for sharing common configuration across services or different compose files. It does not pull remote files, merge images, or define network topology.

From lesson: docker-compose.yml Syntax

In a docker-compose.yml file, why would you prefer 'secrets' over environment variables for sensitive data?

Secrets are faster to load than environment variables.
Secrets are encrypted at rest and mounted as files, reducing exposure in logs or process lists.
Secrets allow for automatic rotation every 24 hours.
Environment variables are deprecated in modern Docker versions.

Answer: Secrets are encrypted at rest and mounted as files, reducing exposure in logs or process lists.. Secrets are mounted into the container as files in /run/secrets, which prevents them from appearing in shell histories or 'docker inspect' output. Environment variables are often leaked. The other claims regarding performance, rotation, and deprecation are false.

From lesson: docker-compose.yml Syntax

What is the primary purpose of the 'deploy' key in a compose file?

To define the base operating system for the service.
To configure orchestration options like replicas and resource limits when using Swarm.
To specify which storage driver the volume uses.
To force the build of an image before deployment.

Answer: To configure orchestration options like replicas and resource limits when using Swarm.. The 'deploy' key is used for cluster-level configuration (like replicas or CPU limits) compatible with Swarm mode. It is not for image building, base OS definition, or storage driver configuration.

From lesson: docker-compose.yml Syntax

If you define 'ports: - "8080:80"', what is the specific network behavior?

The container maps port 8080 on the host to port 80 inside the container.
The container maps port 80 on the host to port 8080 inside the container.
Both the host and container open port 8080 for internal communication.
The container blocks all external traffic on port 80.

Answer: The container maps port 8080 on the host to port 80 inside the container.. In 'host:container' syntax, the left side is the host port and the right side is the container port. Option 1 is inverted, option 3 is invalid syntax for port mapping, and option 4 is incorrect as this mapping exposes the container.

From lesson: docker-compose.yml Syntax

When deploying a multi-service application in Kubernetes, why should you use Services rather than direct Pod-to-Pod networking?

To provide a permanent virtual IP and DNS name that abstracts away the volatility of Pod lifecycles
Because Pods are physically located on different nodes and cannot communicate directly
To ensure that all traffic between containers is encrypted by default
Because services automatically scale the number of underlying Pods based on CPU usage

Answer: To provide a permanent virtual IP and DNS name that abstracts away the volatility of Pod lifecycles. Services provide a stable endpoint because Pod IPs change frequently during restarts (right). Pods can talk directly, so option 1 is false. Services do not handle encryption natively (option 2 is false). Scaling is the job of Deployment controllers, not Services (option 3 is false).

From lesson: Multi-service Applications

What is the primary advantage of using a multi-container Pod in Kubernetes (e.g., sidecar pattern) over running two separate Pods?

It ensures that both containers are billed as a single unit by the cloud provider
It allows both containers to share the same local network interface (localhost) and volumes
It prevents either container from crashing if the other consumes too much memory
It forces both containers to be deployed on different nodes for high availability

Answer: It allows both containers to share the same local network interface (localhost) and volumes. Containers in the same Pod share the same IPC, network namespace, and storage volumes, facilitating close communication (right). Billing is resource-based, not pod-based (false). Multi-container pods do not inherently prevent crashes (false) and they are co-located on the same node, not spread out (false).

From lesson: Multi-service Applications

How does Docker networking facilitate communication between two containers running on the same host?

By assigning each container a unique public IP address from the host's subnet
By mounting the host's kernel into both container filesystems
By creating a virtual bridge (e.g., docker0) that allows containers to communicate via their private IP addresses
By utilizing a shared memory space that automatically synchronizes all data files

Answer: By creating a virtual bridge (e.g., docker0) that allows containers to communicate via their private IP addresses. Docker uses virtual bridges to connect container network interfaces, allowing communication through internal IPs (right). Containers do not get public IPs by default (false), sharing the kernel is a security risk/imprecise (false), and shared memory is not a native networking mechanism (false).

From lesson: Multi-service Applications

In a microservices architecture, what is the purpose of a 'Readiness Probe' in Kubernetes?

To kill a container if it has exceeded its memory limit
To signal that a container has finished initializing and is prepared to accept user traffic
To restart a container automatically if it exits with a non-zero status code
To detect if a container is currently blocked by a network firewall

Answer: To signal that a container has finished initializing and is prepared to accept user traffic. Readiness probes control traffic flow, ensuring the Load Balancer doesn't route traffic to an unready container (right). Liveness probes handle restarts (false), and resource management is handled by limits, not probes (false). Network detection is not the specific goal of a readiness check (false).

From lesson: Multi-service Applications

What happens if you don't use volumes in a containerized multi-service application?

The application will automatically fail to start because containers require volumes to run
All data written by the application will be lost when the container is deleted or recreated
The application will be unable to connect to any external network services
Kubernetes will automatically create temporary storage that persists across deployments

Answer: All data written by the application will be lost when the container is deleted or recreated. Docker containers have ephemeral storage; once removed, data is gone (right). Containers don't require volumes to boot (false), networking is separate from filesystem persistence (false), and Kubernetes does not create persistent storage without an explicit volume declaration (false).

From lesson: Multi-service Applications

When deploying to Kubernetes, why should you prefer ConfigMaps over building environment variables directly into your Docker image?

ConfigMaps are encrypted by default, whereas Docker images are not.
ConfigMaps allow you to update configuration without rebuilding or redeploying the container image.
Docker images cannot store environment variables, so ConfigMaps are the only option.
ConfigMaps automatically sync with local .env files on the developer's machine.

Answer: ConfigMaps allow you to update configuration without rebuilding or redeploying the container image.. ConfigMaps decouple configuration from the image, allowing for environment-specific adjustments without recompiling the image. Option 0 is false as ConfigMaps are plain text; option 2 is false as images can have ENV; option 3 is false as there is no automatic local sync.

From lesson: Environment Variables and .env Files

What happens if you define an environment variable in a Dockerfile using ENV and then try to override it using the --env flag during docker run?

The container fails to start due to a conflict.
The Dockerfile value takes precedence and cannot be changed.
The --env flag value overrides the value defined in the Dockerfile.
Both values are concatenated together into a single string.

Answer: The --env flag value overrides the value defined in the Dockerfile.. Runtime environment variables passed via the command line or container orchestration layers take precedence over values baked into the image via ENV. The other options describe incorrect behaviors regarding variable priority.

From lesson: Environment Variables and .env Files

Which is the most secure method for handling sensitive database credentials when using Kubernetes?

Hardcoding them as ENV variables in the Dockerfile.
Storing them in a .env file and copying it into the image during the build process.
Using Kubernetes Secret objects mounted as environment variables or volumes.
Passing them as plain text arguments in the docker run command history.

Answer: Using Kubernetes Secret objects mounted as environment variables or volumes.. Kubernetes Secrets are designed to handle sensitive data with better access control and management than hardcoding or including files in images. Hardcoding or copying .env files leaks credentials into the image layer history.

From lesson: Environment Variables and .env Files

Why does using the --env-file flag in Docker not automatically make your application secure?

The file is only read at image build time, not container start time.
The environment variables are still injected into the container's environment, where they can be inspected by any process with sufficient permissions.
Docker automatically uploads the .env file contents to a public registry.
Environment variables are converted to clear-text logs immediately upon container startup.

Answer: The environment variables are still injected into the container's environment, where they can be inspected by any process with sufficient permissions.. Environment variables are accessible to the process tree and often visible via system tools, which is why they shouldn't be used for highly sensitive secrets if more secure alternatives are available. Other options are technically incorrect regarding how Docker handles those files.

From lesson: Environment Variables and .env Files

If you have a multi-stage Docker build, what is the best way to handle environment variables intended only for the build process?

Use ENV to set them, so they persist in the final image.
Use ARG, as these are not persisted in the final image layers.
Create a temporary .env file and delete it in the same RUN command.
Inject them via Kubernetes ConfigMaps during the build.

Answer: Use ARG, as these are not persisted in the final image layers.. ARG variables are specifically designed for build-time configuration and do not persist in the final container image, unlike ENV. The other methods either leak data or are functionally incapable of passing build arguments correctly.

From lesson: Environment Variables and .env Files

What is the primary difference between a Liveness probe and a Readiness probe in Kubernetes?

Liveness probes manage traffic flow, while Readiness probes manage container restarts.
Liveness probes handle application crashes, while Readiness probes determine when a container is ready to receive traffic.
Readiness probes are used only for sidecars, while Liveness probes are used for main applications.
There is no functional difference; they are interchangeable.

Answer: Liveness probes handle application crashes, while Readiness probes determine when a container is ready to receive traffic.. Liveness probes are intended to restart containers that have hung or crashed. Readiness probes control whether the load balancer should send traffic to the pod. Option 0 is backwards. Option 2 is incorrect because both are used for both. Option 3 is false as they have distinct operational purposes.

From lesson: Health Checks

You have a Spring Boot application that takes 45 seconds to initialize. What is the best strategy for health checks?

Set initialDelaySeconds to 60 in the Liveness probe.
Use a Startup probe with a successThreshold of 1.
Use a Readiness probe with a periodSeconds of 60.
Disable all health checks.

Answer: Use a Startup probe with a successThreshold of 1.. A Startup probe is designed specifically to protect slow-starting containers by disabling Liveness checks until initialization completes. Option 0 is a fragile 'guess-and-check' approach. Option 2 does not prevent the Liveness probe from killing the container. Option 3 is dangerous.

From lesson: Health Checks

When should you use a 'tcpSocket' probe instead of an 'httpGet' probe?

When the application does not have an HTTP interface but needs to verify a port is listening.
When you want to check the specific status code of an API response.
When the application requires authentication headers.
When the container is running a shell script instead of a binary.

Answer: When the application does not have an HTTP interface but needs to verify a port is listening.. TCP socket probes verify connectivity by opening a connection to a specific port. HTTP probes are required for status codes (Option 1) and headers (Option 2). Shell scripts (Option 3) are typically checked with 'exec' probes.

From lesson: Health Checks

If a container's Readiness probe fails, what does Kubernetes do?

It restarts the container immediately.
It stops the container and marks it as 'Failed'.
It removes the Pod's IP address from the Service's endpoints list.
It ignores the failure if the Liveness probe is passing.

Answer: It removes the Pod's IP address from the Service's endpoints list.. Readiness failures prevent traffic from reaching the pod, which is achieved by removing the pod from the Service load balancer. Option 0 describes a Liveness probe action. Option 1 is incorrect as the pod remains running. Option 3 is wrong because the two probes act independently.

From lesson: Health Checks

Why is it important to set the 'timeoutSeconds' field in a health probe?

To define how long the container takes to start up.
To limit how long the probe waits for a response before considering it a failure.
To determine how often the probe runs.
To set the maximum number of restarts allowed.

Answer: To limit how long the probe waits for a response before considering it a failure.. The timeout determines the maximum time allowed for the probe to respond before Kubernetes marks it as failed. Options 0, 2, and 3 correspond to 'initialDelaySeconds', 'periodSeconds', and 'restartPolicy' or 'failureThreshold', respectively.

From lesson: Health Checks

If the etcd component fails, what is the immediate impact on the Kubernetes cluster functionality?

Existing pods on worker nodes stop running immediately
The cluster becomes read-only and state changes cannot be persisted
The kubelet automatically restarts the etcd service
The API server continues to schedule new pods normally

Answer: The cluster becomes read-only and state changes cannot be persisted. The API server relies on etcd for state; if etcd is down, the cluster state cannot be updated, making it read-only. Pods continue running (A is wrong), kubelet manages nodes, not etcd (C is wrong), and scheduling requires state updates (D is wrong).

From lesson: Kubernetes Architecture — Master and Worker Nodes

Which component is primarily responsible for ensuring that the desired state of the cluster matches the current state?

Kube-scheduler
Kube-proxy
Controller Manager
Container Runtime

Answer: Controller Manager. The Controller Manager runs control loops that watch the state and make changes to reach the desired state. Scheduler just assigns nodes (A), proxy handles networking (B), and runtime manages containers (D), not cluster state.

From lesson: Kubernetes Architecture — Master and Worker Nodes

What is the primary role of the Kubelet on a Worker Node?

Directing traffic between services
Managing the lifecycle of containers based on pod specifications
Storing the configuration of the entire cluster
Communicating with other worker nodes to share memory

Answer: Managing the lifecycle of containers based on pod specifications. The Kubelet ensures containers described in PodSpecs are running and healthy. Traffic routing is Kube-proxy (A), cluster configuration is in etcd (C), and memory sharing is not a standard Kubernetes feature (D).

From lesson: Kubernetes Architecture — Master and Worker Nodes

Why does the Kubernetes architecture separate the Control Plane from Worker Nodes?

To allow workers to run different operating systems than the master
To isolate management processes from application workloads for security and stability
To enable the master node to host the container runtime interface
To reduce the number of IP addresses required for the cluster

Answer: To isolate management processes from application workloads for security and stability. Separation prevents application crashes or resource exhaustion from affecting the cluster management. Masters don't have to use different OS (A), runtime is for workers (C), and IP count isn't the architectural driver (D).

From lesson: Kubernetes Architecture — Master and Worker Nodes

When a user submits a manifest to the API Server, what is the sequence of events?

API Server updates etcd, then Scheduler assigns a node, then Kubelet executes
Kube-proxy assigns the node, then API Server updates etcd
Container Runtime creates the pod, then API Server updates etcd
Controller Manager deploys the pod, then Scheduler updates the API Server

Answer: API Server updates etcd, then Scheduler assigns a node, then Kubelet executes. The API Server validates the request and writes to etcd; the Scheduler notices the new pod and assigns it to a node; the Kubelet on that node sees the assignment and starts the container. Others (B, C, D) incorrectly assign responsibilities.

From lesson: Kubernetes Architecture — Master and Worker Nodes

Why is it generally discouraged to create a standalone Pod instead of using a ReplicaSet?

Standalone Pods require more storage space on the cluster
Standalone Pods lack the ability to handle network traffic
Standalone Pods do not recover automatically if the node hosting them terminates
Standalone Pods cannot be assigned an IP address within the cluster

Answer: Standalone Pods do not recover automatically if the node hosting them terminates. A standalone Pod is not managed by a controller, so if the node dies, the Pod is gone. ReplicaSets provide self-healing by replacing failed Pods. The other options are incorrect because Pods can handle traffic, have IPs, and do not inherently consume more storage.

From lesson: Pods and ReplicaSets

A ReplicaSet is configured with 3 replicas. If you manually delete one of the Pods it manages, what is the immediate behavior of the Kubernetes controller?

It will wait for a periodic resync to notice the change
It will detect the deficit and immediately schedule a new Pod to reach the desired count
It will lock the namespace to prevent further deletions
It will terminate the remaining two Pods to maintain consistency

Answer: It will detect the deficit and immediately schedule a new Pod to reach the desired count. The ReplicaSet controller continuously monitors the cluster state; upon detecting a discrepancy between actual and desired replicas, it immediately creates a new Pod. The other options describe non-existent or incorrect reconciliation logic.

From lesson: Pods and ReplicaSets

What is the primary purpose of the 'selector' field in a ReplicaSet definition?

To define which container image the Pod should use
To specify which node in the cluster should host the Pods
To identify which existing Pods fall under the management of this ReplicaSet
To set the security context for the Pod's environment

Answer: To identify which existing Pods fall under the management of this ReplicaSet. The selector tells the controller which Pods it is responsible for by matching their labels. It does not select nodes, set container images, or define security contexts.

From lesson: Pods and ReplicaSets

If you update the container image in a ReplicaSet's Pod template, what happens to the currently running Pods?

They are immediately updated in place without downtime
They continue to run using the old image until they are manually deleted
The ReplicaSet automatically restarts the container process
The ReplicaSet kills all Pods and replaces them with new ones simultaneously

Answer: They continue to run using the old image until they are manually deleted. ReplicaSets do not perform rolling updates; existing Pods are immutable and continue running until deleted. The other options describe features of Deployments or incorrect behavior regarding Pod lifecycle.

From lesson: Pods and ReplicaSets

What happens if a Pod's labels are changed so they no longer match the ReplicaSet selector?

The ReplicaSet will immediately terminate the Pod
The ReplicaSet loses ownership of that Pod and creates a new one to replace it
The Pod will be automatically re-labeled to match the selector
The ReplicaSet will ignore the change and continue managing the Pod

Answer: The ReplicaSet loses ownership of that Pod and creates a new one to replace it. Once the labels no longer match, the ReplicaSet no longer considers that Pod part of its managed set; seeing the count drop below the target, it will spin up a new Pod. The other options are incorrect as the controller does not auto-modify existing objects.

From lesson: Pods and ReplicaSets

If you have 10 replicas and set 'maxSurge' to 2 and 'maxUnavailable' to 0, what is the behavior during a rolling update?

It will scale down to 8 and then up to 10
It will create 2 new pods before terminating any old pods
It will terminate 2 pods and then create 2 new pods
It will update all 10 pods simultaneously

Answer: It will create 2 new pods before terminating any old pods. With maxSurge=2 and maxUnavailable=0, K8s creates new pods first, ensuring capacity never drops below 10. The other options describe scenarios where capacity drops (violating maxUnavailable=0) or where no surge occurs.

From lesson: Deployments — Rolling Updates and Rollbacks

What is the primary purpose of a Deployment Revision in Kubernetes?

To record the history of changes for rollback purposes
To enable high availability across multiple clusters
To store the secrets used by the container images
To define the network policies for the pods

Answer: To record the history of changes for rollback purposes. Revisions allow users to track changes and perform rollbacks to a specific previous configuration. The other options refer to networking, security, or multi-cluster architecture, not the rollout mechanism.

From lesson: Deployments — Rolling Updates and Rollbacks

Why would a rolling update stop and stay in a 'progressing' state indefinitely?

The Deployment reached the maxSurge limit
The new pods are failing their readiness probes
The cluster has reached its maximum pod count
The old pods are still processing incoming traffic

Answer: The new pods are failing their readiness probes. If readiness probes fail, the Deployment controller will not consider the new pods 'Ready' and will not proceed with terminating old pods. The other options do not prevent a deployment from progressing toward its target state.

From lesson: Deployments — Rolling Updates and Rollbacks

What happens when you run 'kubectl rollout undo' on a deployment that is currently updating?

It stops the deployment and leaves it in an inconsistent state
It pauses the update and waits for manual intervention
It reverts the deployment to the previous revision
It immediately deletes all existing pods

Answer: It reverts the deployment to the previous revision. Rolling undo reverts the deployment configuration to the state recorded in the previous revision. The other options suggest either errors or destructive actions that don't align with K8s' declarative nature.

From lesson: Deployments — Rolling Updates and Rollbacks

When performing a rolling update, how does the Service object know which pods to send traffic to?

By identifying the specific Pod IDs in the Deployment
By tracking the Pod creation timestamps
By matching the Pod labels to the Service selector
By communicating directly with the Container Runtime

Answer: By matching the Pod labels to the Service selector. Services use label selectors to dynamically discover pods. As old pods are terminated and new ones created, they all share the same labels, allowing for seamless traffic shifting. The other methods are not how Services discover pods.

From lesson: Deployments — Rolling Updates and Rollbacks

Which of the following best describes the fundamental difference between ClusterIP and NodePort?

ClusterIP provides a stable internal IP; NodePort opens a static port on every node in the cluster.
ClusterIP routes traffic from the internet; NodePort is only for local processes.
ClusterIP requires an external IP; NodePort is restricted to inter-pod communication.
ClusterIP manages LoadBalancer settings; NodePort is only used for debugging.

Answer: ClusterIP provides a stable internal IP; NodePort opens a static port on every node in the cluster.. ClusterIP is the default and provides an internal IP only accessible within the cluster. NodePort extends this by opening a port on every node, allowing traffic from outside the cluster. The other options reverse these roles or assign incorrect purposes.

From lesson: Services — ClusterIP, NodePort, LoadBalancer

When is it most appropriate to use a LoadBalancer service type?

When you want to enable service discovery between pods in the same namespace.
When you need a cloud provider to provision a dedicated external IP for your application.
When you are running a cluster on a local machine without network access.
When you want to prevent all external traffic from hitting your containers.

Answer: When you need a cloud provider to provision a dedicated external IP for your application.. LoadBalancer is designed to request an external IP from the cloud provider, which automatically configures the infrastructure to route traffic to the pods. ClusterIP is for internal discovery, and local clusters rarely support LoadBalancer without extra configuration.

From lesson: Services — ClusterIP, NodePort, LoadBalancer

You have a frontend service that needs to talk to a backend service. Which service type is the most efficient choice?

NodePort, because it is more secure.
LoadBalancer, because it provides a public IP.
ClusterIP, because it provides internal load balancing without exposing the service externally.
ExternalName, because it automatically scales the pods.

Answer: ClusterIP, because it provides internal load balancing without exposing the service externally.. ClusterIP is the standard for service-to-service communication because it is internal, performant, and secure. NodePort and LoadBalancer expose services to the network, increasing attack surface unnecessarily. ExternalName is used for CNAME aliasing.

From lesson: Services — ClusterIP, NodePort, LoadBalancer

What happens if you delete a Pod that is currently being targeted by a Service?

The Service automatically updates its endpoint list to stop sending traffic to that deleted pod.
The Service stops working entirely and must be redeployed.
The Service continues trying to send traffic to the dead IP address until manually updated.
The NodePort closes automatically to prevent errors.

Answer: The Service automatically updates its endpoint list to stop sending traffic to that deleted pod.. The Kubernetes control plane continuously monitors Pod labels and the Service's selector. When a pod is deleted, its endpoint is removed from the service automatically. The other options imply a static configuration that does not reflect Kubernetes dynamic nature.

From lesson: Services — ClusterIP, NodePort, LoadBalancer

Why might a LoadBalancer service stay in a 'Pending' state indefinitely?

Because the pods are running too fast.
Because the cluster has too many internal services.
Because the underlying infrastructure lacks a controller capable of provisioning an external IP.
Because the NodePort range is full.

Answer: Because the underlying infrastructure lacks a controller capable of provisioning an external IP.. LoadBalancer 'Pending' usually means no cloud-controller-manager or compatible solution (like MetalLB) is present to interact with the infrastructure to fetch an IP. Pod speed, number of services, and NodePort ranges are unrelated to external IP provisioning.

From lesson: Services — ClusterIP, NodePort, LoadBalancer

If you define an Ingress resource in a namespace, what happens if no Ingress Controller is running in your cluster?

The cluster automatically assigns a default controller.
The Ingress resource remains created, but no traffic routing occurs.
Kubernetes will throw an error and refuse to create the Ingress resource.
Traffic is routed to all services in the cluster by default.

Answer: The Ingress resource remains created, but no traffic routing occurs.. Ingress objects are declarative configuration. Without a controller process to watch the API server and update routing logic (like NGINX config), the Ingress resource is merely stored data. Option 0 and 3 are false as there is no implicit routing, and option 2 is false because the API server accepts valid manifests regardless of available controllers.

From lesson: Ingress and Ingress Controllers

Which of the following best describes the relationship between an Ingress Controller and an Ingress Resource?

The Ingress Controller is the data, and the Ingress Resource is the application logic.
The Ingress Resource is the physical load balancer hardware.
The Ingress Controller is the implementation, while the Ingress Resource is the configuration.
They are redundant components that perform identical tasks.

Answer: The Ingress Controller is the implementation, while the Ingress Resource is the configuration.. The Ingress resource defines the desired state (routing rules, paths), while the controller acts as the control loop that reconciles that state by configuring a reverse proxy. Option 0 is backwards, option 1 is false because it's software-defined, and option 3 is incorrect because they serve distinct roles.

From lesson: Ingress and Ingress Controllers

When configuring multiple paths for the same host in an Ingress, why is order sometimes significant?

The Ingress Controller processes rules based on their alphabetical order.
Longer, more specific paths must be evaluated before shorter, prefix-based paths to prevent routing conflicts.
Kubernetes requires path length to be even to avoid parsing errors.
The controller always defaults to the first path defined in the YAML.

Answer: Longer, more specific paths must be evaluated before shorter, prefix-based paths to prevent routing conflicts.. Because many controllers use prefix matching, if you place a generic root path ('/') before a specific path ('/api'), the root path will match everything, effectively shadowing the '/api' rule. The other options describe non-existent behaviors.

From lesson: Ingress and Ingress Controllers

Why must an Ingress Controller typically have a service type of LoadBalancer or be exposed via NodePort?

To allow the Ingress resource to automatically create a new database connection.
To provide a stable external entry point for traffic to reach the cluster from outside.
To allow the Ingress Controller to communicate with the Kubernetes API server.
To bypass the need for Pod IP addresses in the cluster.

Answer: To provide a stable external entry point for traffic to reach the cluster from outside.. An Ingress Controller resides inside the cluster; to receive requests from the internet, it must be exposed. Options 0, 2, and 3 are unrelated to the primary function of exposing the controller for external ingress.

From lesson: Ingress and Ingress Controllers

What is the primary purpose of the 'host' field in an Ingress rule?

To specify the physical machine where the service is running.
To implement virtual hosting, allowing one controller to route traffic based on the domain name.
To limit which users can access the service.
To define the port number the container listens on internally.

Answer: To implement virtual hosting, allowing one controller to route traffic based on the domain name.. The host field enables Name-Based Virtual Hosting, allowing you to host multiple websites or services on a single LoadBalancer IP. It does not control physical placement (0), user permissions (2), or internal container ports (3).

From lesson: Ingress and Ingress Controllers

If you need to update a configuration file managed by a ConfigMap mounted as a volume, what is the best way to ensure the application picks up the change?

Delete and recreate the deployment
Wait for the kubelet to sync the volume and ensure the application watches the file for changes
Restart the Kubernetes API server
Update the ConfigMap and manually execute a kill command on the process inside the container

Answer: Wait for the kubelet to sync the volume and ensure the application watches the file for changes. Mounting as a volume allows for atomic updates via symbolic link swapping. If the application is designed to watch the file, it will refresh without a restart. Option 0 and 3 are invasive, and option 2 is not necessary for configuration sync.

From lesson: ConfigMaps and Secrets

Why is a Kubernetes Secret not considered a 'vault' or 'encryption-at-rest' solution by default?

Secrets are only stored in memory
Secrets are base64 encoded by default, not encrypted
Secrets are only available to the namespace creator
Secrets do not support RBAC policies

Answer: Secrets are base64 encoded by default, not encrypted. Kubernetes Secrets are base64 encoded, which is encoding, not encryption. Anyone with etcd access can decode them. Option 0 is false, option 2 is false as they can be shared across namespaces if needed, and option 3 is false because RBAC is the primary way to secure them.

From lesson: ConfigMaps and Secrets

What happens to a pod if you update a ConfigMap that is being consumed strictly as an environment variable?

The environment variable in the pod updates automatically after a short delay
The pod will automatically restart to pick up the new value
The pod will continue to use the original value until the pod is recreated
The container process will crash due to a mismatch in configuration

Answer: The pod will continue to use the original value until the pod is recreated. Environment variables are injected at pod creation time. Changes to the source ConfigMap do not reflect in existing pods. Option 0 is false, option 1 does not happen automatically, and option 3 is incorrect as the process has no way of knowing the config changed.

From lesson: ConfigMaps and Secrets

Which of the following is the most secure way to consume a Secret containing a TLS private key in a pod?

Injecting it as an environment variable
Mounting the secret as a volume at a specific path
Passing it as an argument in the command list
Storing it directly in the Dockerfile as a build argument

Answer: Mounting the secret as a volume at a specific path. Mounting as a volume keeps sensitive files off the process environment and logs. Environment variables (0) and command arguments (2) can be logged or inspected by unauthorized users. Option 3 is a major security vulnerability.

From lesson: ConfigMaps and Secrets

When defining a ConfigMap, what is the significance of the 'data' versus the 'binaryData' field?

data is for JSON, binaryData is for YAML
data is for UTF-8 encoded strings, binaryData is for base64 encoded binary blobs
binaryData allows for larger files than the data field
data is encrypted, while binaryData is not

Answer: data is for UTF-8 encoded strings, binaryData is for base64 encoded binary blobs. ConfigMaps use 'data' for standard string-based key-value pairs, while 'binaryData' is intended for non-textual data like images or certificates. The other options misrepresent the structural intent of the fields.

From lesson: ConfigMaps and Secrets

A developer needs a volume that can be shared across multiple nodes in a Kubernetes cluster for a web application. Which access mode must the PersistentVolume support?

ReadWriteOnce
ReadOnlyMany
ReadWriteMany
ReadWriteOncePod

Answer: ReadWriteMany. ReadWriteMany is the only mode that allows multiple nodes to mount the volume in read-write mode. ReadWriteOnce is limited to one node, ReadOnlyMany does not allow writing, and ReadWriteOncePod is restricted to a single specific pod instance.

From lesson: Persistent Volumes and Claims

What is the primary benefit of using a StorageClass in a Kubernetes environment?

It forces all pods to use the same storage backend.
It enables dynamic provisioning of PVs based on PVC requests.
It provides a way to backup volumes to off-site storage.
It allows manual mounting of local host paths without permissions.

Answer: It enables dynamic provisioning of PVs based on PVC requests.. StorageClasses allow for dynamic provisioning, meaning admins don't need to pre-create PVs. The other options are incorrect because storage classes do not mandate backend uniformity for the whole cluster, are not backup tools, and are distinct from local path mounting.

From lesson: Persistent Volumes and Claims

If a PersistentVolume has a Reclaim Policy of 'Retain', what happens to the data when the corresponding PVC is deleted?

The data is automatically wiped to ensure security.
The PV is deleted immediately, but the data remains on the disk.
The PV object is released from the claim, but the data is preserved for manual recovery.
The PV enters a 'Pending' state until a new PVC is created.

Answer: The PV object is released from the claim, but the data is preserved for manual recovery.. Retain means the PV object and the physical data remain intact, allowing an admin to recover it. It is not wiped automatically (Delete policy does that), the PV object is not deleted, and it does not enter a pending state for re-assignment automatically.

From lesson: Persistent Volumes and Claims

Why would a pod using a PersistentVolumeClaim remain in a 'Pending' state indefinitely?

The node has insufficient RAM for the volume.
No available PersistentVolume matches the requirements of the PVC.
The Pod is running in the 'kube-system' namespace.
The image pull secret is missing from the volume spec.

Answer: No available PersistentVolume matches the requirements of the PVC.. A PVC remains pending if it cannot bind to a PV (e.g., storage class mismatch, size requirement). RAM usage is unrelated to volume binding, namespace location does not affect binding, and image secrets are for container images, not volume provisioning.

From lesson: Persistent Volumes and Claims

How does Kubernetes ensure that a specific Pod is attached to the correct PersistentVolume?

By matching the labels and selectors defined in the PVC and PV.
By mounting the volume based on the Pod's name.
By verifying the UID of the container process.
By randomly assigning available volumes during startup.

Answer: By matching the labels and selectors defined in the PVC and PV.. Kubernetes uses labels and selectors (or capacity requirements) to bind PVCs to compatible PVs. Pod names, UIDs, and random assignment are not mechanisms used for storage binding logic.

From lesson: Persistent Volumes and Claims

What happens to a pod if the container exceeds its memory limit?

The kernel throttles the CPU usage until memory usage drops
Kubernetes automatically increases the memory limit
The container is terminated and potentially restarted with an OOMKilled status
The pod is evicted to another node with more memory

Answer: The container is terminated and potentially restarted with an OOMKilled status. Memory is a non-compressible resource; the kernel cannot 'throttle' it, so it must terminate the process. Throttling only applies to CPU. Kubernetes does not auto-scale limits, and eviction is triggered by node-level pressure, not single-container limits.

From lesson: Resource Requests and Limits

If a pod requests 500m CPU and sets a limit of 1000m, what does this guarantee?

The pod will always get 1000m CPU at all times
The pod is guaranteed 500m CPU, and can burst up to 1000m if available
The pod will be throttled if it exceeds 500m CPU
The pod can use all available CPU on the node regardless of the 1000m limit

Answer: The pod is guaranteed 500m CPU, and can burst up to 1000m if available. Requests are reserved resources. Limits define the maximum cap. The container is guaranteed its request, but may access unused node CPU up to the limit. Throttling only occurs when exceeding the 1000m limit.

From lesson: Resource Requests and Limits

Which of the following describes the 'Burstable' Quality of Service class?

Requests are equal to limits for all containers in the pod
No requests or limits are set for any container in the pod
The pod has at least one request/limit set, but they are not equal
The pod is only assigned to nodes with unlimited CPU resources

Answer: The pod has at least one request/limit set, but they are not equal. Burstable occurs when requests are defined but not equal to limits. 'Guaranteed' requires all requests to equal limits. 'BestEffort' is when no requests or limits exist. Nodes do not have 'unlimited' resources.

From lesson: Resource Requests and Limits

Why is it recommended to set CPU requests even if you don't strictly require a minimum amount?

To allow the Kubernetes scheduler to place the pod on a node with sufficient capacity
To prevent the node from entering a 'Ready' state
To ensure the application uses more CPU than it actually needs
To bypass the need for memory requests

Answer: To allow the Kubernetes scheduler to place the pod on a node with sufficient capacity. The scheduler uses requests to calculate the remaining capacity of a node. Without requests, the scheduler cannot account for the pod's footprint, leading to node overloading. This has no effect on node state or CPU consumption efficiency.

From lesson: Resource Requests and Limits

What is the primary difference between how CPU and memory are managed when limits are reached?

CPU is a compressible resource that can be throttled; memory is incompressible and leads to termination
Memory is a compressible resource; CPU is incompressible
Both are managed by terminating the process when the limit is reached
Neither resource is actually enforced by the kernel

Answer: CPU is a compressible resource that can be throttled; memory is incompressible and leads to termination. CPU can be restricted by time-slicing (throttling), while memory cannot be partially allocated or throttled without crashing the process. Termination is the standard outcome for memory, but not for CPU.

From lesson: Resource Requests and Limits

If you deploy a Pod into 'namespace-a', how can a Service in 'namespace-b' connect to it?

It cannot connect because namespaces provide strict network isolation.
It must use the FQDN including the namespace suffix.
It can connect using just the Pod's local name because DNS is cluster-wide.
It can connect only if the Pod is assigned a LoadBalancer service type.

Answer: It must use the FQDN including the namespace suffix.. Option 2 is correct because Kubernetes DNS uses a specific schema (service.namespace.svc.cluster.local) to locate resources outside the current namespace. Option 1 is wrong because namespaces don't block traffic by default; Option 3 is wrong because short names resolve only within the current namespace; Option 4 is wrong because internal traffic uses ClusterIP services, not external LoadBalancers.

From lesson: Namespaces

Which of the following resources is NOT scoped to a specific namespace in Kubernetes?

ConfigMap
PersistentVolumeClaim
PersistentVolume
Secret

Answer: PersistentVolume. Option 3 is correct because PersistentVolumes (PVs) represent cluster-level storage resources, while PersistentVolumeClaims (PVCs) are the namespaced requests for that storage. The other options (ConfigMaps, PVCs, and Secrets) are all namespaced resources.

From lesson: Namespaces

What is the primary benefit of using multiple namespaces in a shared Kubernetes cluster?

To improve the physical security of the underlying hardware nodes.
To enable resource quota management for different teams or environments.
To increase the speed at which Pods boot up on a node.
To bypass the need for separate Ingress Controllers.

Answer: To enable resource quota management for different teams or environments.. Option 2 is correct because namespaces allow admins to apply ResourceQuotas to limit CPU and memory usage per project. Option 1 is wrong as namespaces are logical, not physical; Option 3 is wrong because they do not impact scheduling speed; Option 4 is wrong because namespaces usually require their own Ingress rules.

From lesson: Namespaces

You attempt to delete a namespace, but it remains stuck in the 'Terminating' state. What is the most likely cause?

There are still cluster-wide resources like Nodes registered to that namespace.
A finalizer is preventing the deletion because dependent objects exist.
The namespace has too many labels to be deleted immediately.
The API server is currently configured for a single namespace per cluster.

Answer: A finalizer is preventing the deletion because dependent objects exist.. Option 2 is correct; finalizers ensure dependent resources are cleaned up before the parent namespace object is removed. Option 1 is wrong because Nodes are not namespaced; Option 3 is wrong because labels do not prevent deletion; Option 4 is wrong because Kubernetes supports multiple namespaces by default.

From lesson: Namespaces

When configuring ResourceQuotas, what happens if you do not set a limit on a specific namespace?

The namespace will automatically consume the cluster's entire capacity.
The namespace will be unable to run any Pods.
The Kubernetes scheduler will reject all new deployment requests to that namespace.
The namespace will be limited only by the total resources available on the nodes.

Answer: The namespace will be limited only by the total resources available on the nodes.. Option 4 is correct; quotas are optional constraints, and without them, a namespace is only limited by the total hardware capacity of the cluster nodes. Option 1 is false because it competes with other namespaces; Option 2 and 3 are false because Kubernetes does not enforce empty quotas by default.

From lesson: Namespaces

Which command allows you to view the logs of a pod that has multiple containers?

kubectl logs <pod-name>
kubectl logs <pod-name> --all-containers
kubectl logs <pod-name> -c <container-name>
kubectl describe pod <pod-name> --logs

Answer: kubectl logs <pod-name> -c <container-name>. You must specify the container name with -c because logs are stream-specific. The first option fails if there are multiple containers, the second is not a valid flag, and the fourth describes the pod metadata rather than outputting application logs.

From lesson: kubectl Cheat Sheet

What is the primary difference between 'kubectl apply' and 'kubectl create'?

Create is for YAML, apply is for JSON
Apply is declarative, create is imperative
Create allows live patching, apply does not
Apply automatically restarts the cluster

Answer: Apply is declarative, create is imperative. Apply manages the resource state declaratively by comparing the current live state with the manifest; create forces the creation of a resource and fails if it already exists. The other options are incorrect interpretations of their functional purpose.

From lesson: kubectl Cheat Sheet

You have a deployment, but changes to your Docker image tag are not reflecting. What is the most efficient command to force a redeploy?

kubectl rollout restart deployment <name>
kubectl delete deployment <name>
kubectl update deployment <name>
kubectl scale deployment <name> --replicas=0

Answer: kubectl rollout restart deployment <name>. Rollout restart triggers a rolling update, effectively forcing pods to pull the new image. Deleting the deployment is destructive, 'update' is not a native command, and scaling to zero destroys the pods without ensuring the new image is pulled upon scaling back up.

From lesson: kubectl Cheat Sheet

If you need to execute a command inside a running pod to troubleshoot, which command is correct?

kubectl run <pod-name> -- <command>
kubectl exec -it <pod-name> -- <command>
kubectl attach <pod-name> -c <command>
kubectl debug <pod-name> -- <command>

Answer: kubectl exec -it <pod-name> -- <command>. Exec is designed to run a process in an existing container. 'Run' creates a new pod, 'attach' connects to the main process, and 'debug' is for ephemeral containers, not standard command execution in the main container.

From lesson: kubectl Cheat Sheet

How do you temporarily expose a pod to the internet for testing purposes without creating a formal Service manifest?

kubectl port-forward pod/<name> 8080:80
kubectl expose pod/<name> --type=LoadBalancer
kubectl proxy <name>
kubectl map pod/<name> 80:8080

Answer: kubectl port-forward pod/<name> 8080:80. Port-forwarding creates a tunnel from your local machine to the pod, ideal for quick testing. Expose creates a persistent Service object, proxy is for API access, and 'map' is not a valid kubectl command.

From lesson: kubectl Cheat Sheet

What is the primary role of the 'values.yaml' file in a Helm chart?

To define the static deployment manifest structure
To provide default configuration values that can be overridden
To list the container image registry credentials
To execute post-installation hook scripts

Answer: To provide default configuration values that can be overridden. The values.yaml file provides the default settings that are injected into templates. The other options are incorrect because static structures are in templates, registry credentials are handled by secrets, and hooks are defined in manifest metadata, not as core values.

From lesson: Helm Charts — Packaging K8s Apps

Why is the 'helm template' command commonly used during development?

To install the chart into a staging namespace
To verify how manifests render without communicating with the Tiller or K8s API
To automatically upgrade an existing release in the cluster
To generate a Dockerfile for the application

Answer: To verify how manifests render without communicating with the Tiller or K8s API. Helm template allows developers to inspect the rendered YAML output locally. It does not install anything (wrong), is not an upgrade tool (wrong), and does not build container images (wrong).

From lesson: Helm Charts — Packaging K8s Apps

When defining a dependency in a Helm chart, what is the purpose of the 'alias' field?

To rename the dependency to avoid namespace collisions
To specify the image tag version of the dependency
To bypass the need for a Chart.lock file
To allow multiple instances of the same subchart with different configurations

Answer: To allow multiple instances of the same subchart with different configurations. Aliases allow you to include the same subchart multiple times under different names, each with unique values. It is not for renaming for collisions (wrong), not for versioning (wrong), and does not bypass locking (wrong).

From lesson: Helm Charts — Packaging K8s Apps

What happens if a Helm release fails during an 'upgrade' process?

The cluster automatically deletes all pods in the namespace
The release remains in a 'failed' state, and changes are not automatically rolled back unless specified
The entire Kubernetes cluster is reset to its factory state
The system ignores the error and continues to the next manifest

Answer: The release remains in a 'failed' state, and changes are not automatically rolled back unless specified. Helm keeps track of release history; a failed upgrade stops the process to prevent corruption. The other options describe catastrophic outcomes that do not happen in K8s/Helm workflows.

From lesson: Helm Charts — Packaging K8s Apps

Which component of a Helm chart is used to include custom logic for clean-up or initialization during a deployment lifecycle?

Chart.yaml metadata
The _helpers.tpl file
Helm Hooks
The values-schema.json file

Answer: Helm Hooks. Hooks allow you to run code at specific lifecycle points. Metadata is for identification, helpers are for template code reuse, and schema files are for validation, none of which manage lifecycle execution.

From lesson: Helm Charts — Packaging K8s Apps

If you have a deployment with 2 pods and an HPA target CPU utilization of 50%, what happens if the current average CPU utilization is 80%?

The HPA terminates both pods and recreates them.
The HPA increases the replica count to approximately 3 or 4 pods.
The HPA keeps the replica count at 2 because the threshold is not exceeded.
The HPA immediately scales the deployment to the maximum configured replicas.

Answer: The HPA increases the replica count to approximately 3 or 4 pods.. The formula used is (currentMetricValue / targetMetricValue) * currentReplicas. (80/50) * 2 = 3.2, so HPA scales to 4. Option 0 is incorrect because HPA modifies replicas, not restarts pods. Option 2 is incorrect because 80% is above the 50% threshold. Option 3 is incorrect because HPA rarely jumps straight to max unless the calculation dictates it.

From lesson: Horizontal Pod Autoscaling

Why is it mandatory to define resource requests in a Pod spec when using HPA?

To ensure the Pod has enough memory to start.
Because HPA calculates 'percentage of utilization' based on the requested resource value.
To provide a hard limit on how many pods the cluster can run.
To allow the Kubernetes scheduler to place pods on the correct nodes.

Answer: Because HPA calculates 'percentage of utilization' based on the requested resource value.. HPA defines 'utilization' as a percentage of the requested capacity. If no requests are set, the HPA cannot determine what '100% utilization' means. Options 0, 2, and 3 describe scheduling or operational benefits, but they are not the reason the HPA controller requires requests for its logic.

From lesson: Horizontal Pod Autoscaling

What is the role of the 'stabilization window' in HPA downscaling?

It speeds up the creation of new pods during a traffic spike.
It prevents rapid 'flapping' of replica counts by waiting before scaling down.
It forces the cluster to stay at minimum replicas during high load.
It forces the cluster to use only the most efficient nodes for the pods.

Answer: It prevents rapid 'flapping' of replica counts by waiting before scaling down.. The stabilization window ensures the system does not scale down too quickly if metrics fluctuate briefly. It keeps the higher number of replicas for a set duration. Option 0 is wrong because it applies to scaling down, not up. Options 2 and 3 are incorrect as they do not relate to the purpose of the stabilization window.

From lesson: Horizontal Pod Autoscaling

What happens if the Metrics Server is missing from your Kubernetes cluster?

HPA will default to scaling based on node disk usage.
HPA will fail to fetch metrics and the replica count will remain unchanged.
The cluster will automatically restart to install the missing component.
Pods will be deleted to save resources.

Answer: HPA will fail to fetch metrics and the replica count will remain unchanged.. Without the Metrics Server, the HPA controller cannot retrieve the metrics required for its scaling algorithm, so it cannot calculate replica changes. It does not auto-install (0), change to disk metrics (0), or delete pods (3).

From lesson: Horizontal Pod Autoscaling

Which of the following is true regarding scaling based on custom metrics?

It is possible using an adapter that connects the Metrics Server to external monitoring systems.
It is not supported in any version of Kubernetes.
It only works if the pod is written in a specific language.
It requires editing the kube-apiserver source code.

Answer: It is possible using an adapter that connects the Metrics Server to external monitoring systems.. Custom metrics require a custom metrics API server (adapter) to expose data from external sources. Option 1 is wrong because it is supported. Option 2 is wrong because scaling is independent of the application language. Option 3 is wrong because configuration is done via resources, not code changes.

From lesson: Horizontal Pod Autoscaling

When configuring Prometheus to monitor a Kubernetes cluster, why is it preferred to use service discovery rather than static target lists?

It reduces the total number of metrics collected by the server.
Pods are ephemeral and their IP addresses change frequently when replaced or scaled.
Static lists increase the CPU overhead of the Prometheus pod significantly.
Service discovery automatically generates Grafana dashboards for new services.

Answer: Pods are ephemeral and their IP addresses change frequently when replaced or scaled.. Service discovery is essential because Kubernetes continuously destroys and recreates pods; static IP lists would become stale immediately. Option 0 is wrong as it does not affect volume, option 2 is incorrect regarding performance, and option 3 is false as discovery does not automate dashboard creation.

From lesson: Monitoring with Prometheus and Grafana

Which mechanism ensures that Prometheus can query metrics from pods that are not directly exposed to the external network?

Configuring a LoadBalancer service for every single pod.
Using the Kubernetes API server as a proxy for all metric requests.
Exposing pods through a ClusterIP service and letting Prometheus scrape them via the internal network.
Enabling external access in the Docker daemon settings.

Answer: Exposing pods through a ClusterIP service and letting Prometheus scrape them via the internal network.. Prometheus runs inside the cluster and accesses pods via the internal virtual network using ClusterIP services. Option 0 is unnecessary and inefficient; option 1 is not how Prometheus communicates; option 3 is irrelevant to internal cluster communication.

From lesson: Monitoring with Prometheus and Grafana

What is the primary function of a 'relabel_config' block in a Prometheus scrape configuration?

To define which alerts should be sent to the Alertmanager.
To modify, drop, or add metadata labels to targets before they are scraped.
To increase the retention period of the stored time-series data.
To authenticate the Prometheus server against the Kubernetes API.

Answer: To modify, drop, or add metadata labels to targets before they are scraped.. Relabeling allows administrators to normalize or filter metadata labels dynamically before the scrape occurs. Option 0 belongs to alerting rules, option 2 belongs to storage configuration, and option 3 relates to RBAC.

From lesson: Monitoring with Prometheus and Grafana

In a Grafana dashboard monitoring Kubernetes, what does a 'rate(http_requests_total[5m])' query represent?

The cumulative total of requests since the container started.
The total number of requests in the last 5 minutes.
The per-second average rate of requests over a 5-minute sliding window.
The maximum number of requests processed by a single pod.

Answer: The per-second average rate of requests over a 5-minute sliding window.. The rate function calculates the per-second increase over the specified time range, which is critical for seeing throughput trends. Option 0 is just a counter, option 1 is an increase() calculation, and option 3 is a max() function.

From lesson: Monitoring with Prometheus and Grafana

Why should you use persistent storage for Prometheus in a production Kubernetes environment?

To allow multiple Prometheus replicas to share the same metrics database.
To prevent loss of metric history when a pod is rescheduled or updated.
To increase the scraping speed of the underlying disk subsystem.
To enable the use of non-standard Prometheus metric formats.

Answer: To prevent loss of metric history when a pod is rescheduled or updated.. Since pods in Kubernetes are ephemeral, any data not on persistent storage is wiped upon termination. Option 0 is incorrect as Prometheus doesn't support shared write access to the same storage; option 2 is false as disks don't speed up scraping; option 3 is unrelated to data format.

From lesson: Monitoring with Prometheus and Grafana

What is the primary advantage of using a multi-stage Docker build in a production environment?

It speeds up the process of building the Dockerfile layers.
It allows for the creation of smaller images by excluding build-time dependencies.
It enables the container to run on both Docker and Kubernetes simultaneously.
It automatically configures the networking bridge for the container.

Answer: It allows for the creation of smaller images by excluding build-time dependencies.. Multi-stage builds allow you to use a heavy image to compile code and copy only the final binary to a small runtime image. The other options are incorrect because multi-stage builds don't necessarily speed up layer caching, are not related to orchestration compatibility, and do not influence container networking.

From lesson: Docker Interview Questions

When you run 'docker build', how does Docker determine whether to use a cached layer?

By checking if the file modification time has changed on the host.
By comparing the command string in the Dockerfile with previously executed steps.
By performing a checksum of the files in the context directory.
By checking if the container registry has a newer version of the base image.

Answer: By comparing the command string in the Dockerfile with previously executed steps.. Docker compares the instruction string of the current step with existing layers. If the instruction and the layers preceding it match, it uses the cache. The other options are wrong because Docker does not primarily rely on file modification times, checksums of the entire context, or remote registry versioning for layer cache validation.

From lesson: Docker Interview Questions

Which of the following best describes the difference between CMD and ENTRYPOINT?

CMD is for running tasks, while ENTRYPOINT is only for defining metadata.
CMD provides default arguments that can be easily overridden, while ENTRYPOINT defines the executable.
ENTRYPOINT allows multiple commands to be run simultaneously, while CMD only allows one.
CMD is executed during the build phase, whereas ENTRYPOINT is executed during the runtime phase.

Answer: CMD provides default arguments that can be easily overridden, while ENTRYPOINT defines the executable.. ENTRYPOINT sets the primary command that always runs, while CMD provides parameters that can be overridden at runtime. The other options are incorrect as they misstate the roles or the timing of execution for these instructions.

From lesson: Docker Interview Questions

In a Kubernetes environment, why is it considered a best practice to use a Readiness Probe?

To restart the container if it crashes due to an out-of-memory error.
To inform the Load Balancer that the application is fully started and ready to receive traffic.
To check if the container has sufficient CPU resources to run the process.
To secure the container from external unauthorized access.

Answer: To inform the Load Balancer that the application is fully started and ready to receive traffic.. Readiness probes tell the service that the container is ready to accept requests. Liveness probes handle restarts (option 1), Resource quotas handle CPU limits (option 3), and Network policies handle security (option 4), making those incorrect.

From lesson: Docker Interview Questions

What is the result of using the 'ADD' instruction instead of 'COPY' in a Dockerfile?

ADD allows the source to be a URL and can automatically extract tar archives.
ADD always creates a more secure layer than COPY.
COPY is strictly for local files, while ADD is strictly for remote networking.
ADD is the newer, more efficient instruction that replaces COPY entirely.

Answer: ADD allows the source to be a URL and can automatically extract tar archives.. ADD has the added functionality of fetching files from URLs and unpacking tar files automatically, while COPY is more explicit and secure for local files. The other options are incorrect because ADD is not more secure, COPY can also handle local files, and COPY is preferred over ADD when extraction/URLs aren't needed.

From lesson: Docker Interview Questions

When a Deployment is updated to a new container image, how does Kubernetes ensure there is no downtime during the transition?

It deletes all old pods and replaces them with new ones simultaneously.
It uses a RollingUpdate strategy to incrementally replace pods while maintaining readiness.
It pauses all incoming traffic until the new pods are fully operational.
It uses a Recreate strategy to perform a seamless swap of existing processes.

Answer: It uses a RollingUpdate strategy to incrementally replace pods while maintaining readiness.. The RollingUpdate strategy ensures availability by spinning up new pods before removing old ones. Simultaneous deletion leads to downtime, pausing traffic is not a native behavior, and Recreate shuts down all instances before starting new ones.

From lesson: Kubernetes Interview Questions

What is the primary role of a Service in a Kubernetes cluster?

To provide a persistent storage volume for containers.
To monitor the CPU and memory usage of the nodes.
To provide a stable network endpoint for a group of dynamic Pods.
To manage the authentication of users accessing the cluster API.

Answer: To provide a stable network endpoint for a group of dynamic Pods.. Services abstract the ephemeral nature of Pod IPs by providing a single stable DNS name and IP. Storage is handled by PersistentVolumes, monitoring by metrics-server, and authentication by RBAC, not Services.

From lesson: Kubernetes Interview Questions

Why is it generally better to use a ConfigMap rather than hardcoding environment variables in a Deployment manifest?

ConfigMaps allow for automatic container image rebuilding.
ConfigMaps decouple configuration from the application image, allowing the same image to run in different environments.
ConfigMaps are the only way to store encrypted credentials.
ConfigMaps allow the Pod to automatically restart when a configuration change is detected.

Answer: ConfigMaps decouple configuration from the application image, allowing the same image to run in different environments.. Decoupling configuration enables the same image to be promoted across environments. Rebuilding is not a function of ConfigMaps, secrets (not ConfigMaps) store credentials, and Pods do not automatically restart on ConfigMap changes.

From lesson: Kubernetes Interview Questions

If a Pod is stuck in a 'CrashLoopBackOff' state, what is the most logical first step for troubleshooting?

Restart the entire Kubernetes cluster.
Check the container logs using kubectl logs to identify the application error.
Increase the resource limits for the node.
Change the container runtime from Docker to a different engine.

Answer: Check the container logs using kubectl logs to identify the application error.. Checking application logs reveals why the process inside the container is failing immediately. Restarting the cluster is destructive, resource limits rarely cause crash loops, and the runtime engine is usually not the culprit for basic crashes.

From lesson: Kubernetes Interview Questions

What is the purpose of a Readiness Probe in a Pod specification?

To kill the container if it uses too much memory.
To signal to the Service that the Pod is ready to accept network traffic.
To restart the container if the application process exits with an error.
To ensure the container has finished downloading all external dependencies.

Answer: To signal to the Service that the Pod is ready to accept network traffic.. Readiness probes prevent traffic from being routed to a Pod that isn't ready. Liveness probes handle restarting failed containers, and resource limits manage memory usage; dependency management is an application-level concern.

From lesson: Kubernetes Interview Questions