Spring Boot Actuator — Endpoints and Security
Fast recall
Quick revision
Core answer
/health, /info, /metrics, /env, /beans, /heapdump, /threaddump — without writing custom monitoring code. By default only `/health` and `/info` are exposed over HTTP; everything else requires explicit opt-in via management.endpoints.web.exposure.include. In production, layer four defenses: expose only what monitoring needs, secure with Spring Security role-based access, isolate on a separate `management.server.port`, and split health into liveness/readiness groups for Kubernetes probes. Setting exposure.include=* in production is the most common Actuator security incident.Whether you know Actuator endpoints are a security risk if left open and can describe a layered defence strategy
Exposing `management.endpoints.web.exposure.include=*` in production without authentication, leaking environment variables, heap dumps, and internal metrics
Describe using a separate `management.server.port` with a firewall rule so only internal services reach Actuator, plus `/actuator/health` groups for liveness and readiness probes in Kubernetes
Interview-ready guide
Interview answer
Spring Boot Actuator gives you production observability — health, metrics, environment, thread dumps — without deploying a separate monitoring agent. The defaults are safe for development; exposing it fully in production is a security incident.
The four hardening layers
- Exposure control:
management.endpoints.web.exposure.include=health,info,metrics,prometheus— never* - Spring Security with
EndpointRequest.toAnyEndpoint()— keep/healthand/infopublic, requireACTUATORrole for everything else - Separate management port:
management.server.port=9090— moves Actuator off the public port; combine with a NetworkPolicy so only monitoring can reach it - Health groups: split
liveness(minimal ping) fromreadiness(DB, Redis, Kafka) so Kubernetes restarts only when the process is genuinely broken
Why exposure matters
/envleaks every property including passwords if injected as env vars/heapdumpreturns the full JVM memory — secrets, session tokens, decrypted credentials/beansand/conditionsreveal the architecture and let attackers plan further probes
Health detail control
management.endpoint.health.show-details=when-authorized—UP/DOWNfor the load balancer, component details for authenticated callers- Custom
HealthIndicatorbeans add app-specific checks — external API reachability, queue depth — and integrate into the same response monitoring already watches
In an interview, I'd emphasize that the strongest defence is network isolation, not authentication. Authentication is a layer; an isolated management port behind a NetworkPolicy is a moat.
Spring Boot Actuator — Endpoints and Security
Direct Answer
Spring Boot Actuator exposes operational HTTP and JMX endpoints — /health, /info, /metrics, /env, /beans, /heapdump, /threaddump — without writing custom monitoring code. By default only /health and /info are exposed over HTTP; everything else requires explicit opt-in via management.endpoints.web.exposure.include. In production, layer four defenses: expose only what monitoring needs, secure with Spring Security role-based access, isolate on a separate management.server.port, and split health into liveness/readiness groups for Kubernetes probes. Setting exposure.include=* in production is the most common Actuator security incident.
Common Mistakes & Pitfalls
Exposing management.endpoints.web.exposure.include=* in production without authentication, leaking environment variables, heap dumps, and internal metrics
Check your understanding
Answer these without looking back at the article.
- How do you configure separate liveness and readiness health groups for Kubernetes?
- How would you add a custom health indicator that checks an external dependency?
- What is the difference between `/actuator/metrics` and `/actuator/prometheus`?
- How do you protect the `/actuator/loggers` endpoint that allows runtime log-level changes?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.