Spring Boot Actuator practice questions

Worked examples for Spring Boot Actuator

1. Question 1

   A gateway in front of a Spring Boot 2.7 service already routes `/actuator` to a different system, so the team must publish the application's Actuator endpoints under `/manage` instead — for example `/manage/health`. Which Actuator setting is intended for this?

   1. A. `management.endpoints.web.exposure.include`, which controls both which endpoints are visible and the URL prefix they are served under

      Overloads the exposure property. Exposure decides *which* endpoints a technology may serve; it carries no path information and cannot relocate them.

   2. B. `management.endpoints.web.base-path`, which changes the common prefix under which all web endpoints are served (default `/actuator`)Correct answer

      Correct: this is the documented property for customizing the management base path, with `/actuator` as the default; setting it to `/manage` serves the health endpoint at `/manage/health`.

   3. C. `management.server.port`, which relocates the management endpoints away from the application's main path space

      Confuses port with path. This property moves the endpoints onto a separate HTTP port for isolation, but they keep the same base path on that port.

   4. D. `management.endpoints.web.path-mapping.<id>`, applied once with the id `*` to move every endpoint at the same time

      Misuses path-mapping, which remaps one endpoint id to one path (for example `health` to `healthcheck`) and does not accept a wildcard id; the shared prefix is the base path's job.

   Explanation

   Actuator serves all web endpoints beneath a configurable common prefix, `management.endpoints.web.base-path`, whose default is `/actuator`; changing it to `/manage` relocates the whole set. Exposure properties only decide which endpoints a technology may serve and encode no path, `management.server.port` isolates endpoints on a different port rather than a different path, and `path-mapping` renames one endpoint id at a time rather than the shared prefix.

2. Question 2

   A team wants a `readiness` health group reachable at `/actuator/health/readiness` that aggregates only the `readinessState` and `db` indicators. Which configuration defines that group?

   1. A. management.endpoints.web.exposure.include=readiness

      This is an HTTP exposure setting for endpoint ids, not a health-group definition; there is no endpoint id named 'readiness' to expose, and it does not select which indicators the group aggregates.

   2. B. management.endpoint.health.group.readiness.include=readinessState,dbCorrect answer

      A health group is declared under management.endpoint.health.group.<name>.include, so naming the group 'readiness' with these members creates a subset reachable at /actuator/health/readiness.

   3. C. Register a bean of type HealthGroup annotated with @HealthGroup("readiness")

      Health groups are configured through properties, not by declaring a bean or applying an invented @HealthGroup annotation.

   4. D. management.endpoint.health.readiness.include=readinessState,db

      This omits the required .group. segment; without it the key does not define a health group and the members are not aggregated under /actuator/health/readiness.

   Explanation

   Health groups are defined with the property management.endpoint.health.group.<name>.include, so a readiness group listing readinessState and db becomes reachable at /actuator/health/readiness. Exposure properties control which endpoint ids are served rather than grouping indicators, groups are configured via properties rather than a bean or annotation, and dropping the .group. segment leaves the group undefined.

3. Question 3

   In Spring Boot 2.x, which TWO statements about the default HTTP exposure of Actuator endpoints are correct? Select TWO.

   1. A. All actuator endpoints are exposed over HTTP by default

      Exposing every actuator endpoint over HTTP by default would be a security risk, which is precisely why Boot does not do this; endpoints beyond the minimal set must be opted in explicitly.

   2. B. No endpoints are ever exposed over HTTP, regardless of configuration

      Endpoints can certainly be exposed over HTTP; this overstates the restriction, since additional endpoints are enabled through management.endpoints.web.exposure.include.

   3. C. Only a limited set (notably /health); others must be opted in via management.endpoints.web.exposure.includeCorrect answer

      Boot 2.x deliberately exposes only a minimal set over HTTP (notably health) for safety, and everything else is enabled explicitly through management.endpoints.web.exposure.include.

   4. D. The shutdown endpoint is disabled by default, so it is not reachable over HTTP out of the boxCorrect answer

      shutdown is the one endpoint disabled by default (all other endpoints are enabled), and it is not part of the default web exposure set either, so it stays unreachable over HTTP until you both enable it and add it to management.endpoints.web.exposure.include.

   Explanation

   Boot 2.x is secure-by-default over HTTP: of all the actuator endpoints, only health is exposed out of the box, and every other endpoint (metrics, env, beans, and so on) must be opted in through management.endpoints.web.exposure.include. Separately, shutdown is the single endpoint that is disabled by default, so it is not reachable over HTTP without being both enabled and explicitly exposed. Claiming that every endpoint is exposed automatically, or that no endpoint can ever be exposed, both contradict the documented defaults.

4. Question 4

   A value that only ever increases (e.g. total orders placed) is best represented in Micrometer as a:

   1. A. Timer

      A Timer measures durations and counts of timed events, not a simple ever-increasing total.

   2. B. A plain log statement

      A log line is not a metric instrument at all, so it cannot be aggregated or exported as a metric.

   3. C. Gauge

      A Gauge samples a value that can go up or down (for example queue size), which does not fit a value that only ever increases.

   4. D. CounterCorrect answer

      A Counter models a monotonically increasing total, which is exactly the right instrument for a value that only ever goes up.

   Explanation

   Micrometer offers distinct instrument types matched to the shape of the value being tracked. A quantity that only ever increases is a cumulative total, which is precisely what a Counter represents; instruments that can decrease or that measure durations do not model that behavior.

5. Question 5

   A nightly batch import can run for many minutes. The team instruments it with a Micrometer `Timer` and discovers that while an import is in progress, the dashboard shows nothing about it — the timer's count and total only move once a job finishes, so a job that hangs for an hour is invisible. Which meter type addresses this, and why?

   1. A. A `DistributionSummary`, because it records a distribution of values rather than a single duration and therefore reports partial progress.

      Misreads DistributionSummary's purpose: it tracks the distribution of non-time measurements (such as payload sizes) and, like a Timer, only records an event after it has been observed. It reveals nothing about in-flight work.

   2. B. A `LongTaskTimer`, because it measures tasks that are still running — publishing the number of active tasks and their current durations while they are in flight, instead of recording only on completion.Correct answer

      Correct: LongTaskTimer exists precisely for long-running tasks, reporting active task count and elapsed duration of in-flight tasks so a hung or slow job is visible before it ends (Micrometer 'Long Task Timers').

   3. C. A `Counter` incremented when the job starts, because the registry samples counters continuously and will therefore show elapsed time.

      Assumes counters are continuously sampled and carry timing information. A Counter only reports a cumulative count that changes when application code increments it; it holds no duration.

   4. D. The same `Timer`, with a percentile histogram enabled so intermediate durations are published while the task is still running.

      Confuses distribution statistics with when a sample is recorded. Histogram and percentile configuration only changes how *completed* samples are summarised; a Timer still records nothing until the task ends.

   Explanation

   A regular Timer records a sample only when the timed operation completes, so long-running work contributes no data — and no alerting signal — while it is in progress. Micrometer provides LongTaskTimer for exactly this case: it tracks tasks that are currently executing, publishing the active task count and the duration of in-flight tasks so a stalled job becomes visible immediately. DistributionSummary is for non-time measurements and likewise records only observed events, a Counter carries no duration and changes only when incremented, and percentile/histogram configuration affects how completed samples are summarised rather than when they are recorded (Micrometer reference, 'Timers — Long Task Timers').

6. Question 6

   Which built-in Spring Boot 2.7 Actuator endpoint returns the collated list of `@RequestMapping` / route paths handled by the application?

   1. A. beans

      The beans endpoint lists the beans in the application context, not the request mappings that route HTTP calls to handlers.

   2. B. mappingsCorrect answer

      The mappings endpoint collates the application's @RequestMapping and other route paths, showing which handler serves each path.

   3. C. env

      The env endpoint reports properties from the ConfigurableEnvironment; it says nothing about request routing.

   4. D. info

      The info endpoint exposes arbitrary application information such as build and git details, not the controller mappings.

   Explanation

   The mappings endpoint is the one that collates route paths, listing every @RequestMapping (and equivalent) together with the handler it dispatches to. The other endpoints report different concerns: beans lists context beans, env reports properties, and info exposes general application metadata.

7. Question 7

   A developer wants to record a custom Micrometer metric in a Spring Boot 2.7 application that has `spring-boot-starter-actuator` on the classpath. What is the standard way to obtain the registry the meters are created against?

   1. A. Inject the auto-configured MeterRegistry bean and create counters, gauges, or timers on itCorrect answer

      Actuator auto-configures a MeterRegistry bean, so a component simply injects it and registers instruments against it, which then surface through the metrics endpoint and any configured backend.

   2. B. Construct a new SimpleMeterRegistry in each component and register meters on that instance

      Creating your own detached registry per component means the meters are not the ones Actuator publishes; you should register against the shared auto-configured registry, not a private instance.

   3. C. Add @EnableMetrics to a configuration class to activate a registry before meters can be created

      No such enabling annotation is required; the MeterRegistry is auto-configured by the actuator starter, so the registry already exists to be injected.

   4. D. Declare the metric names and values under management.metrics in application.properties

      Meters are created and updated in code against a registry; you cannot declare a live metric's value as a static property.

   Explanation

   The actuator starter auto-configures a MeterRegistry, so the idiomatic approach is to inject that bean and build Counter/Gauge/Timer instruments on it — those meters then appear on the metrics endpoint and export to any backend. Spinning up a private registry detaches your meters from what Actuator publishes, no enabling annotation is needed, and metric values are recorded programmatically rather than declared in properties.

8. Question 8

   Spring Security is on the classpath with its default configuration. A monitoring client sends `POST /actuator/loggers/com.example` to change a log level and receives `403 Forbidden`, even though the caller authenticates successfully and the endpoint is exposed. What is the documented explanation, and the recommended response?

   1. A. The `loggers` endpoint is read-only over HTTP; changing a log level at runtime is possible only through the JMX endpoint.

      Denies a write operation that exists. The loggers endpoint supports a write operation over HTTP; the 403 is a security-layer rejection, not a missing capability.

   2. B. Spring Security's CSRF protection is enabled by default, so Actuator operations issued with POST, PUT, or DELETE are rejected unless the request carries a CSRF token; CSRF should be turned off only for a service consumed exclusively by non-browser clients.Correct answer

      This is the documented cause: because Spring Boot relies on Spring Security's defaults, CSRF protection is on, and write-style Actuator operations such as `shutdown` and `loggers` return 403 until a token is supplied.

   3. C. Spring Boot requires the `ENDPOINT_ADMIN` role for Actuator write operations by default, so the authenticated user must be granted that role.

      Treats a role name that appears in documentation examples as a built-in rule. Actuator auto-configures no role requirements; any role-based rule is one the application author writes.

   4. D. The endpoint is exposed but not enabled, and write operations require `management.endpoint.loggers.enabled=true` in addition to exposure.

      Confuses the enablement gate with an authorization failure. A non-enabled endpoint is not mapped at all and would yield 404, not 403 — and `loggers` is enabled by default.

   Explanation

   Because Spring Boot leans on Spring Security's own defaults rather than weakening them, CSRF protection is active whenever Spring Security is configured, and Actuator operations that use POST, PUT, or DELETE — such as `shutdown` and the log-level write on `loggers` — are refused with 403 until the request includes a valid CSRF token. The guidance is to send the token; disabling CSRF wholesale is appropriate only for a service whose clients are never browsers. The failure is not a missing capability (the loggers write operation exists over HTTP), not a built-in role requirement (Actuator auto-configures none), and not an enablement problem — a disabled or unexposed endpoint is unmapped and answers 404 rather than 403.