A health response is one diagnostic signal, not proof that every user operation works. Spring Boot Actuator can expose health and management information, but endpoint access and the meaning of each health group require deliberate configuration.

These Spring Boot interview questions use fictional observations from a dependency outage. They are a reasoning exercise, not a report of a real incident or measured production behavior.

What is the difference between liveness and readiness?

Liveness asks whether the process should continue running. Readiness asks whether this instance should receive traffic. A dependency outage may make an instance unable to serve useful requests without making repeated restarts helpful.

Choose which dependencies belong in readiness according to the service's behavior. A shared database outage affecting every instance can produce a very different operational result from one unhealthy local connection. Do not include every remote system in liveness by habit.

How can exposure stay narrow?

management.endpoints.web.exposure.include=health
management.endpoint.health.show-details=never

This configuration illustrates intentionally narrow HTTP exposure and hidden detail. The application still needs Actuator and appropriate network and security controls. Endpoint availability, exposure and authorization are related controls; setting one property is not a complete security review.

Do not expose environment, heap or configuration endpoints publicly to make diagnosis convenient. Inspect management access through the actual deployment path, including any separate port, firewall or proxy rules.

How would you read these observations?

Fictional exercise:
10:02: article requests begin returning 503
10:03: process remains live
10:03: readiness reports unavailable
10:04: dependency connection failures increase
10:04: another service using that dependency also fails

The observations support investigating the shared dependency. They do not yet prove its root cause. A network change, expired credential, service limit or dependency incident could produce similar symptoms. State the hypothesis and the next piece of evidence needed.

What should you check next?

  1. Confirm the affected operation, start time and instance scope.
  2. Compare failures with successful requests and recent changes.
  3. Inspect authorized logs using correlation identifiers.
  4. Check dependency reachability and error categories.
  5. Inspect latency, saturation and connection-pool evidence.
  6. Apply the smallest justified recovery and verify user operations afterward.

A restart can erase useful evidence and increase load during a shared outage. It may still be appropriate for a specific local failure, but explain why the evidence supports it.

What does a green health result miss?

A shallow check may confirm the process responds while a particular write path, permission or query is broken. Use representative synthetic or application checks where appropriate. Keep them safe and distinguish read-only probes from operations that create data.

Health results can also be stale from a caller's point of view. Check the timestamp, instance and route. A response from one healthy instance does not prove every instance behind a load balancer is ready.

How do you close the exercise?

Verify the failing operation, error rate and readiness behavior after recovery. Record the confirmed cause separately from earlier hypotheses. In an interview, this sequence shows that you use health, metrics and logs together instead of treating one endpoint as a universal pass certificate.

References and next practice

docs.spring.io — spring actuator

spring-boot question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud