Health checks in containers in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Liveness and Readiness Probes

In container orchestration systems like Kubernetes, what is the main difference between a liveness probe and a readiness probe?

A Liveness probes check if the container is alive and should be restarted if failed; readiness probes check if the container is ready to accept traffic.

B Liveness probes check network connectivity; readiness probes check disk space availability.

C Liveness probes verify CPU usage; readiness probes verify memory usage.

D Liveness probes are used only during startup; readiness probes are used only during shutdown.

💡 Hint

Think about what happens when a container is unhealthy versus when it is not ready to serve requests.

Liveness probes detect if a container is stuck or dead and need restarting. Readiness probes determine if a container can receive traffic. They serve different purposes in container lifecycle management.

❓ Architecture

intermediate

Designing Health Checks for a Microservice

You have a microservice that depends on a database and a cache. Which health check design best ensures the service is only marked ready when both dependencies are available?

A Use no health checks and rely on external monitoring tools.

B Implement a readiness probe that checks connectivity to both the database and cache before marking the service ready.

C Use only a liveness probe that checks if the service process is running.

D Implement a readiness probe that checks only the database connectivity.

💡 Hint

Consider what readiness means for a service that depends on multiple components.

Readiness probes should verify all critical dependencies are available before the service receives traffic. Checking only the process or partial dependencies risks sending requests to a non-functional service.

❓ scaling

advanced

Impact of Health Checks on Auto-Scaling

How can improperly configured health checks affect the auto-scaling behavior of a containerized microservice?

A If health checks fail frequently, the orchestrator may kill and restart containers unnecessarily, causing scaling instability.

B Health checks have no effect on auto-scaling since scaling depends only on CPU usage metrics.

C Health checks speed up scaling by automatically increasing container memory limits.

D Improper health checks cause the orchestrator to ignore scaling policies and keep the number of containers fixed.

💡 Hint

Think about what happens when containers are repeatedly marked unhealthy.

Failing health checks cause container restarts, which can interfere with scaling decisions and cause instability. Proper health checks help maintain stable scaling behavior.

❓ tradeoff

advanced

Tradeoffs in Health Check Frequency

What is a key tradeoff when choosing how often to run health checks on containers?

A Health check frequency does not affect system performance or reliability.

B Less frequent health checks reduce resource usage but cause containers to restart unnecessarily.

C Frequent health checks improve container startup time but reduce security.

D More frequent health checks detect failures faster but increase resource usage and network traffic.

💡 Hint

Consider the balance between responsiveness and overhead.

Running health checks too often uses more CPU and network resources, but helps detect problems quickly. Running them too rarely saves resources but delays failure detection.

❓ estimation

expert

Estimating Health Check Load in a Large Cluster

You manage a cluster with 1000 containers. Each container runs a health check every 10 seconds, and each check sends a 1 KB request and receives a 1 KB response. Estimate the total network bandwidth used by health checks per minute.

A Approximately 2000 KB per minute

B Approximately 200 KB per minute

C Approximately 20000 KB per minute

D Approximately 200000 KB per minute

💡 Hint

Calculate requests per minute and multiply by request and response size.

Each container sends 6 checks per minute (60/10). Each check uses 2 KB (1 KB request + 1 KB response). Total = 1000 containers * 6 checks * 2 KB = 12000 KB = 12 MB per minute. Closest option is 20000 KB (20 MB) which accounts for overhead and rounding.

Practice

1. What is the main purpose of health checks in containers?

easy

A. To log all container network traffic

B. To increase the container's memory allocation

C. To update the container's software automatically

D. To verify if the container is running and responsive

Solution

1. Step 1: Understand container health checks

   Health checks are used to confirm if a container is alive and working properly.

2. Step 2: Identify the main goal

   The main goal is to detect if the container is responsive and healthy, so it can be restarted if needed.

3. Final Answer:

   To verify if the container is running and responsive -> Option D

4. Quick Check:

   Health checks = verify container health [OK]

Hint: Health checks confirm container responsiveness [OK]

Common Mistakes:

• Confusing health checks with resource allocation
• Thinking health checks update software
• Assuming health checks log network data

2. Which of the following is the correct syntax to define a simple HTTP health check in a Docker container?

easy

A. HEALTHCHECK EXECUTE curl -f http://localhost/

B. HEALTHCHECK RUN curl http://localhost/

C. HEALTHCHECK CMD curl -f http://localhost/ || exit 1

D. HEALTHCHECK CHECK curl http://localhost/

Solution

1. Step 1: Recall Docker health check syntax

   The correct Dockerfile syntax uses HEALTHCHECK CMD followed by a command that returns 0 on success.

2. Step 2: Identify the correct command

   HEALTHCHECK CMD curl -f http://localhost/ || exit 1 uses 'curl -f' which fails on HTTP errors and 'exit 1' on failure, matching best practice.

3. Final Answer:

   HEALTHCHECK CMD curl -f http://localhost/ || exit 1 -> Option C

4. Quick Check:

   Docker healthcheck syntax = HEALTHCHECK CMD [OK]

Hint: Docker healthchecks use 'HEALTHCHECK CMD' syntax [OK]

Common Mistakes:

• Using RUN instead of CMD in HEALTHCHECK
• Using EXECUTE or CHECK which are invalid keywords
• Not handling failure with exit codes

3. Consider this Kubernetes liveness probe configuration snippet:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

What happens if the container's /health endpoint returns HTTP 500 continuously?

medium

A. Kubernetes restarts the container after failing the liveness probe

B. Kubernetes ignores the failure and keeps the container running

C. Kubernetes scales up the number of containers

D. Kubernetes shuts down the entire pod immediately

Solution

1. Step 1: Understand liveness probe behavior

   Liveness probes check if a container is alive; failure triggers a restart of that container.

2. Step 2: Analyze the HTTP 500 response effect

   HTTP 500 means the endpoint is unhealthy, so Kubernetes marks the probe as failed and restarts the container.

3. Final Answer:

   Kubernetes restarts the container after failing the liveness probe -> Option A

4. Quick Check:

   Liveness probe failure = container restart [OK]

Hint: Liveness failure triggers container restart [OK]

Common Mistakes:

• Thinking Kubernetes ignores liveness failures
• Confusing liveness probe with scaling behavior
• Assuming pod shutdown instead of container restart

4. You have this Dockerfile snippet:

HEALTHCHECK CMD curl -f http://localhost:5000/health || exit 1

But the container never restarts even when the service is down. What is the likely issue?

medium

A. The container restart policy is not set to restart on failure

B. The container does not expose port 5000

C. The health check command is missing the --interval option

D. The HEALTHCHECK CMD syntax is incorrect

Solution

1. Step 1: Check health check command correctness

   The command syntax is correct and uses curl -f with exit 1 on failure.

2. Step 2: Consider container restart policy

   If the container restart policy is not set to restart on failure, the container won't restart despite health check failures.

3. Final Answer:

   The container restart policy is not set to restart on failure -> Option A

4. Quick Check:

   Restart policy controls container restart on health failure [OK]

Hint: Check restart policy if container doesn't restart [OK]

Common Mistakes:

• Assuming health check command syntax is wrong
• Ignoring restart policy settings
• Thinking missing --interval causes no restart

5. You want to design a microservice container that uses both readiness and liveness probes. Which of the following best describes their combined use?

hard

A. Both probes only log health status without affecting container state

B. Liveness probe restarts unhealthy containers; readiness probe controls traffic routing to only ready containers

C. Both probes restart containers on failure

D. Readiness probe restarts containers; liveness probe controls traffic routing

Solution

1. Step 1: Understand liveness probe role

   Liveness probes detect if a container is alive; failure triggers container restart.

2. Step 2: Understand readiness probe role

   Readiness probes check if a container is ready to serve traffic; failure removes it from load balancer routing.

3. Step 3: Combine their functions

   Liveness restarts unhealthy containers; readiness controls traffic flow to only healthy containers.

4. Final Answer:

   Liveness probe restarts unhealthy containers; readiness probe controls traffic routing to only ready containers -> Option B

5. Quick Check:

   Liveness = restart, Readiness = traffic control [OK]

Hint: Liveness restarts; readiness controls traffic [OK]

Common Mistakes:

• Mixing up readiness and liveness roles
• Thinking readiness probe restarts containers
• Assuming probes only log status without action