Spring Boot Actuator Exam Guide (2V0-72.22)

What Is Spring Boot Actuator

Spring Boot Actuator is a sub-project of Spring Boot that provides production-ready monitoring and management capabilities for your application. It exposes a set of built-in HTTP endpoints (and JMX MBeans) that let you inspect application state, health, metrics, environment properties, and more — without writing any custom code.

Think of Actuator as a window into your running application. Operations teams use it to check whether the app is healthy, developers use it to debug configuration issues, and monitoring systems use it to collect metrics.

On the 2V0-72.22 exam, Actuator falls under the Spring Boot section, which carries approximately 28% of all questions. You will encounter questions about which endpoints are exposed by default, how to configure exposure, health indicator behavior, custom endpoints, and security configuration.

Getting Started

To add Actuator to your Spring Boot application, include the starter dependency:

Maven:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Gradle:

implementation 'org.springframework.boot:spring-boot-starter-actuator'

Once on the classpath, Actuator auto-configures a set of endpoints. However, by default only the /health endpoint is exposed over HTTP. All other endpoints exist but are not accessible via web requests until you explicitly configure their exposure.

You can verify it works by starting your application and navigating to http://localhost:8080/actuator/health. You should see:

{
  "status": "UP"
}

The base path for all actuator endpoints is /actuator by default. You can change it with management.endpoints.web.base-path.

Exam tip: Simply adding the spring-boot-starter-actuator dependency does not expose all endpoints over HTTP. By default, only /health is exposed via HTTP. This is one of the most commonly tested facts about Actuator.

Built-in Endpoints

Actuator ships with a comprehensive set of built-in endpoints. The exam expects you to know the important ones and their default state.

Exam tip: The /shutdown endpoint is the only built-in endpoint that is disabled by default. All others are enabled but simply not exposed over HTTP. You must explicitly enable it with management.endpoint.shutdown.enabled=true.

Configuring Endpoint Exposure

This is a critical distinction for the exam: enabled and exposed are not the same thing.

• Enabled means the endpoint exists and can be used. Controlled by management.endpoint.<id>.enabled.
• Exposed means the endpoint is accessible via a specific technology (HTTP or JMX). Controlled by management.endpoints.web.exposure or management.endpoints.jmx.exposure.

An endpoint must be both enabled and exposed to be accessible.

Default Exposure

Exam tip: In Spring Boot 2.0–2.4, both /health and /info were exposed over HTTP by default. Starting with Spring Boot 2.5, /info was removed from the default HTTP exposure for security reasons. Since the 2V0-72.22 exam targets Spring Boot 2.5+, the correct answer is: only /health. However, some older study materials may still reference the old default — be aware of this version difference.

Configuring HTTP Exposure

application.properties:

# Expose specific endpoints
management.endpoints.web.exposure.include=health,info,metrics,env
 
# Expose all endpoints
management.endpoints.web.exposure.include=*
 
# Expose all except env and beans
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=env,beans

application.yml:

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,env
        # Or expose all:
        # include: "*"
        exclude: beans

Exam tip: When using include=* in YAML, you must quote the asterisk as "*" because * has special meaning in YAML. In .properties files, no quoting is needed.

Enabling or Disabling Individual Endpoints

# Enable the shutdown endpoint (disabled by default)
management.endpoint.shutdown.enabled=true
 
# Disable the env endpoint entirely
management.endpoint.env.enabled=false

Disable-All-Then-Enable Pattern

For production environments, a common approach is to disable all endpoints by default and then selectively enable only the ones you need:

# Disable all endpoints
management.endpoints.enabled-by-default=false
 
# Selectively enable only what you need
management.endpoint.health.enabled=true
management.endpoint.info.enabled=true
management.endpoint.metrics.enabled=true
 
# And expose them over HTTP
management.endpoints.web.exposure.include=health,info,metrics

Exam tip: The management.endpoints.enabled-by-default=false property disables all endpoints. You must then explicitly enable each endpoint you want. This is different from just controlling exposure — a disabled endpoint does not exist at all, even over JMX.

Note the property path difference: management.endpoint.<id>.enabled (singular endpoint) controls whether the endpoint exists, while management.endpoints.web.exposure.include (plural endpoints) controls HTTP visibility.

Runtime Log Level Changes with /loggers

The /loggers endpoint deserves special mention because it supports both GET (read current levels) and POST (change levels at runtime) — without restarting the application:

GET  /actuator/loggers/com.example.service
POST /actuator/loggers/com.example.service
     {"configuredLevel": "DEBUG"}

This is a frequently tested capability — the exam may ask which endpoint allows runtime configuration changes.

Health Endpoint Deep Dive

The /health endpoint is the most important Actuator endpoint — both in production and on the exam. It aggregates the status of multiple health indicators to report the overall health of your application.

Auto-Configured Health Indicators

Spring Boot auto-configures health indicators based on your classpath dependencies:

Health Status Values

The health endpoint returns one of these status values:

When multiple health indicators are present, Spring Boot aggregates them into a single overall status. The worst status wins — if any indicator reports DOWN, the aggregate status is DOWN regardless of other indicators. The default severity order is: DOWN > OUT_OF_SERVICE > UP > UNKNOWN.

Controlling Detail Visibility

By default, the /health endpoint only shows the aggregate status. You can control how much detail is revealed with management.endpoint.health.show-details:

application.properties:

management.endpoint.health.show-details=always

With show-details=always, the response includes individual indicator results:

{
  "status": "UP",
  "components": {
    "db": {
      "status": "UP",
      "details": {
        "database": "PostgreSQL",
        "validationQuery": "isValid()"
      }
    },
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 499963174912,
        "free": 250881069056,
        "threshold": 10485760
      }
    }
  }
}

Health Groups

Spring Boot supports health groups to organize indicators for different purposes — most commonly for Kubernetes readiness and liveness probes:

management.endpoint.health.group.readiness.include=db,redis
management.endpoint.health.group.liveness.include=ping
 
# Access at /actuator/health/readiness and /actuator/health/liveness

Exam tip: The default value of show-details is never. Many candidates mistakenly assume health details are visible by default. Remember: out of the box, you only see {"status": "UP"} — nothing more.

Info Endpoint

The /info endpoint displays arbitrary application information gathered from multiple sources.

Static Properties

Any property prefixed with info. is automatically exposed. Note that since Spring Boot 2.6, the environment info contributor is disabled by default — you must set management.info.env.enabled=true to see info.* properties in the response:

info.app.name=My Application
info.app.version=2.1.0
info.app.description=Order management system

This produces:

{
  "app": {
    "name": "My Application",
    "version": "2.1.0",
    "description": "Order management system"
  }
}

Git Information

If a git.properties file exists on the classpath (generated by the git-commit-id-maven-plugin), the info endpoint automatically includes Git commit information:

<plugin>
    <groupId>io.github.git-commit-id</groupId>
    <artifactId>git-commit-id-maven-plugin</artifactId>
</plugin>

This adds commit ID, branch, and timestamp to the /info response.

Build Information

If META-INF/build-info.properties exists (generated by the Spring Boot Maven/Gradle plugin), build metadata is included automatically:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>build-info</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Custom InfoContributor

For dynamic information, implement the InfoContributor interface:

@Component
public class AppInfoContributor implements InfoContributor {
 
    @Override
    public void contribute(Info.Builder builder) {
        builder.withDetail("activeUsers", getUserCount());
        builder.withDetail("serverTime", Instant.now().toString());
    }
 
    private long getUserCount() {
        // query database or cache
        return 42;
    }
}

Exam tip: The /info endpoint aggregates data from multiple sources: info.* properties, git.properties, build-info.properties, and any InfoContributor beans. You do not need to write code to expose static info.* properties — they are picked up automatically.

Metrics with Micrometer

Spring Boot Actuator uses Micrometer as its metrics facade. Micrometer is to metrics what SLF4J is to logging — it provides a vendor-neutral API that can export to many monitoring systems (Prometheus, Datadog, New Relic, CloudWatch, etc.).

Auto-Configured Metrics

Spring Boot auto-configures a rich set of metrics out of the box:

Access metrics via the /metrics endpoint:

GET /actuator/metrics
GET /actuator/metrics/jvm.memory.used
GET /actuator/metrics/http.server.requests?tag=uri:/api/orders

Custom Metrics

Inject MeterRegistry to create custom metrics:

@Service
public class OrderService {
 
    private final Counter orderCounter;
    private final Timer orderTimer;
 
    public OrderService(MeterRegistry registry) {
        this.orderCounter = registry.counter("orders.placed", "type", "online");
        this.orderTimer = registry.timer("orders.processing.time");
    }
 
    public Order placeOrder(Order order) {
        return orderTimer.record(() -> {
            // process order
            orderCounter.increment();
            return saveOrder(order);
        });
    }
}

The @Timed Annotation

For method-level timing without manual instrumentation:

@Service
public class PaymentService {
 
    @Timed(value = "payments.process", description = "Time to process payment")
    public PaymentResult processPayment(Payment payment) {
        // process payment
        return new PaymentResult("SUCCESS");
    }
}

Note: @Timed requires a TimedAspect bean to be registered. Spring Boot does not auto-configure it:

@Configuration
public class MetricsConfig {
 
    @Bean
    public TimedAspect timedAspect(MeterRegistry registry) {
        return new TimedAspect(registry);
    }
}

Exam tip: Micrometer supports multiple meter types: Counter (monotonically increasing value), Gauge (value that can go up and down), Timer (measures duration and count), and DistributionSummary (measures distribution of values). The exam may ask you to choose the right meter type for a given scenario.

Custom Endpoints

You can create custom Actuator endpoints using annotations. This is useful when you need to expose application-specific operational data.

@Component
@Endpoint(id = "features")
public class FeaturesEndpoint {
 
    private final Map<String, Boolean> features = new ConcurrentHashMap<>();
 
    @ReadOperation  // GET /actuator/features — returns all features
    public Map<String, Boolean> getAllFeatures() {
        return features;
    }
 
    @ReadOperation  // GET /actuator/features/{name} — @Selector adds a path variable
    public boolean getFeature(@Selector String name) {
        return features.getOrDefault(name, false);
    }
 
    @WriteOperation  // Maps to HTTP POST
    public void setFeature(@Selector String name, boolean enabled) {
        features.put(name, enabled);
    }
 
    @DeleteOperation  // Maps to HTTP DELETE
    public void deleteFeature(@Selector String name) {
        features.remove(name);
    }
}

This creates an endpoint at /actuator/features that supports GET, POST, and DELETE operations.

Operation Annotations

Web-Only Endpoints

If your endpoint should only be accessible via HTTP (not JMX), use @WebEndpoint instead of @Endpoint:

@Component
@WebEndpoint(id = "webapp-status")
public class WebAppStatusEndpoint {
 
    @ReadOperation
    public Map<String, String> getStatus() {
        return Map.of(
            "status", "running",
            "version", "2.1.0"
        );
    }
}

Exam tip: Custom endpoints follow the same exposure rules as built-in endpoints. Creating an @Endpoint bean does not automatically make it accessible over HTTP — you still need to include it in management.endpoints.web.exposure.include.

Securing Actuator Endpoints

Actuator endpoints can expose sensitive information. Securing them properly is critical in production and a common exam topic.

Spring Security Integration

When Spring Security is on the classpath, actuator endpoints are secured by default. You can configure access rules with a SecurityFilterChain.

Spring Boot provides EndpointRequest — a dedicated request matcher that works regardless of the actuator base path:

import org.springframework.boot.actuate.autoconfigure.security.servlet.EndpointRequest;
 
@Configuration
public class ActuatorSecurityConfig {
 
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                // Allow unauthenticated access to health and info
                .requestMatchers(EndpointRequest.to("health", "info")).permitAll()
                // Require ADMIN role for all other actuator endpoints
                .requestMatchers(EndpointRequest.toAnyEndpoint()).hasRole("ADMIN")
                // All other requests
                .anyRequest().authenticated()
            .and()
            .httpBasic();
 
        return http.build();
    }
}

Separate Management Port

You can run actuator endpoints on a different port from your main application, which is useful for isolating management traffic behind a firewall:

# Main app on port 8080, actuator on port 9090
server.port=8080
management.server.port=9090

With this configuration, actuator endpoints are available at http://localhost:9090/actuator/* while the application serves traffic on port 8080.

You can also disable HTTP exposure entirely and rely only on JMX:

management.server.port=-1

Exam tip: Setting management.server.port to a different value runs actuator endpoints in a separate embedded server. Setting it to -1 disables the management HTTP server entirely. The exam may test whether you know that management endpoints can run on a separate port.

Exam Tips and Common Pitfalls

The 2V0-72.22 exam tests Actuator heavily. Here are the most frequently tested scenarios and the traps candidates fall into:

1. Only /health is exposed over HTTP by default This is the single most tested Actuator fact. All endpoints are enabled by default (except /shutdown), but only /health is exposed over HTTP. JMX exposes all endpoints by default. To expose more, configure management.endpoints.web.exposure.include.

2. "Enabled" and "exposed" are different things An endpoint can be enabled (it exists) but not exposed (not accessible via HTTP). Many candidates confuse these. An endpoint must be both enabled and exposed to be reachable. The property paths reflect this: management.endpoint.<id>.enabled (singular) controls existence, management.endpoints.web.exposure.include (plural) controls HTTP visibility.

3. /shutdown is the only endpoint disabled by default Every other built-in endpoint is enabled. To use /shutdown, you must both enable it (management.endpoint.shutdown.enabled=true) and expose it over HTTP.

4. Health details default to never Out of the box, /health returns only {"status": "UP"}. To see individual indicator details, set management.endpoint.health.show-details to always or when-authorized. The worst status wins when aggregating: if any indicator is DOWN, the overall status is DOWN.

5. YAML requires quoting * for wildcard exposure include: * in YAML may be parsed as a special character. You must write include: "*" with quotes. In .properties files, no quoting is needed.

6. Custom endpoints need explicit exposure Creating an @Endpoint bean registers it, but it is not exposed over HTTP by default. You must add its ID to management.endpoints.web.exposure.include.

7. How do you expose all endpoints? → management.endpoints.web.exposure.include=*

8. How do you create a custom endpoint? → @Component + @Endpoint(id = "name") with @ReadOperation, @WriteOperation, or @DeleteOperation methods.

9. How do you run Actuator on a separate port? → management.server.port=9090. This creates a separate embedded server. Setting it to -1 disables the management HTTP server entirely.

10. Micrometer is the metrics facade — Spring Boot does not implement its own metrics. It uses Micrometer (vendor-neutral, like SLF4J for logging). The exam may reference Micrometer by name.

Summary

Actuator is one of the most practical topics on the exam — it tests your understanding of how Spring Boot applications are monitored and managed in production. The key insight is the distinction between enabled and exposed: just because an endpoint exists does not mean it is accessible over HTTP.

Frequently Asked Questions

Which Actuator endpoints are exposed over HTTP by default?

Only /health is exposed over HTTP by default in Spring Boot 2.5+. All other endpoints are enabled but not exposed via HTTP — you must configure management.endpoints.web.exposure.include to make them accessible. Over JMX, all endpoints are exposed by default. In Spring Boot 2.0–2.4, both /health and /info were exposed by default.

How do I expose all Actuator endpoints over HTTP?

Set management.endpoints.web.exposure.include=* in application.properties. In YAML, you must quote the asterisk: include: "*". You can exclude specific endpoints with management.endpoints.web.exposure.exclude=env,beans. Remember that /shutdown must also be explicitly enabled with management.endpoint.shutdown.enabled=true.

What is the difference between enabled and exposed in Actuator?

Enabled means the endpoint exists in the application and can process requests. Exposed means the endpoint is accessible via a specific technology (HTTP or JMX). An endpoint must be both enabled AND exposed to be reachable. For example, /metrics is enabled by default but not exposed over HTTP. The /shutdown endpoint is neither enabled nor exposed by default — it requires both management.endpoint.shutdown.enabled=true and inclusion in management.endpoints.web.exposure.include.

How do I create a custom Actuator endpoint?

Create a Spring bean annotated with @Endpoint(id = "your-name") and define methods annotated with @ReadOperation (GET), @WriteOperation (POST), or @DeleteOperation (DELETE). The endpoint is automatically registered but follows the same exposure rules as built-in endpoints — you must include it in management.endpoints.web.exposure.include. See our auto-configuration guide for how Actuator's auto-configuration works under the hood.

→ Test your Actuator knowledge with practice questions — 10 exam-style questions with detailed explanations

→ Spring Boot Auto-configuration explained — how Actuator auto-configures based on your classpath

→ How to prepare for the Spring Professional exam — complete 8-week study plan

→ View 970+ Questions on Udemy — full practice exam bank with video explanations