Skip to main content

Final Lesson — Actuator, Observability, Production Diagnostics, and Spring Professional Final Review

Goal

This is the final lesson of the Spring Professional preparation book.

Today I want to understand:

  1. What is Spring Boot Actuator?
  2. What is observability?
  3. What are health checks?
  4. What is the info endpoint?
  5. What are metrics?
  6. What is Micrometer?
  7. What is Prometheus?
  8. What is tracing?
  9. What is logging correlation?
  10. Which Actuator endpoints are important?
  11. What should I expose in production?
  12. What are common security traps?
  13. What is enough for the Spring Professional exam?
  14. What are the final memory sentences for the whole book?

1. Big Picture

When an application runs in production, writing code is not enough.

I also need to answer:

Is the app running?
Is the database reachable?
Is the app slow?
Which endpoint is failing?
How many requests are coming in?
How much memory is used?
Are scheduled jobs running?
Which beans exist?
Which mappings exist?
Why did auto-configuration happen?
Which logs should I inspect?
Which request caused this error?

Spring Boot Actuator and observability help answer these questions.

Memory sentence:

Production code must be observable.


2. What Is Spring Boot Actuator?

Spring Boot Actuator adds production-ready monitoring and management features.

It provides endpoints such as:

/actuator/health
/actuator/info
/actuator/metrics
/actuator/prometheus
/actuator/loggers
/actuator/mappings
/actuator/beans
/actuator/conditions
/actuator/caches
/actuator/scheduledtasks

These endpoints help inspect and monitor the running application.

Memory sentence:

Actuator exposes production information about the running Spring Boot app.


3. Add Actuator Dependency

Gradle:

implementation("org.springframework.boot:spring-boot-starter-actuator")

Maven:

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

After adding Actuator, Spring Boot can expose management endpoints.

Memory sentence:

spring-boot-starter-actuator adds production-ready endpoints.


4. Actuator Base Path

By default, Actuator web endpoints are usually under:

/actuator

Examples:

/actuator/health
/actuator/info
/actuator/metrics

The endpoint ID becomes part of the URL.

Example:

health endpoint -> /actuator/health
metrics endpoint -> /actuator/metrics

Memory sentence:

Actuator endpoints usually live under /actuator.


5. Endpoint Exposure

Not every endpoint should be exposed over HTTP.

Example configuration:

management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus

This exposes only:

health
info
metrics
prometheus

Dangerous example:

management:
endpoints:
web:
exposure:
include: "*"

This exposes everything.

In production, this can be dangerous.

Memory sentence:

Expose only the Actuator endpoints you really need.


6. Important Production Rule

Actuator endpoints can reveal sensitive information.

Examples:

environment properties
beans
configuration properties
request mappings
logger configuration
database status
cache names
scheduled tasks

So production endpoints should be:

limited
secured
monitored
not publicly open

Memory sentence:

Actuator is powerful, so Actuator must be secured.


7. Health Endpoint

The most important endpoint is:

/actuator/health

It answers:

Is the application healthy?

Example response:

{
"status": "UP"
}

More detailed response may include components:

{
"status": "UP",
"components": {
"db": {
"status": "UP"
},
"diskSpace": {
"status": "UP"
}
}
}

Memory sentence:

/actuator/health shows whether the application is healthy.


8. Health Status

Common health statuses:

UP
DOWN
OUT_OF_SERVICE
UNKNOWN

Meaning:

StatusMeaning
UPcomponent is working
DOWNcomponent is failing
OUT_OF_SERVICEcomponent is intentionally unavailable
UNKNOWNstatus cannot be determined

Memory sentence:

Health status summarizes whether the app or dependency is usable.


9. Health Details

By default, health details may be hidden.

Configuration example:

management:
endpoint:
health:
show-details: when-authorized

Other possible styles:

management:
endpoint:
health:
show-details: always

Be careful with:

show-details: always

because it can expose infrastructure details.

Memory sentence:

Health details are useful but can reveal sensitive information.


10. Health Indicators

Spring Boot can auto-configure health indicators for common dependencies.

Examples:

database
disk space
Redis
MongoDB
RabbitMQ
Kafka
Elasticsearch
mail server

If the database is down, health may become:

{
"status": "DOWN"
}

Memory sentence:

Health indicators check important application dependencies.


11. Custom Health Indicator

Sometimes I want custom health logic.

Example:

@Component
public class ExternalApiHealthIndicator implements HealthIndicator {

private final ExternalApiClient externalApiClient;

public ExternalApiHealthIndicator(ExternalApiClient externalApiClient) {
this.externalApiClient = externalApiClient;
}

@Override
public Health health() {
boolean reachable = externalApiClient.isReachable();

if (reachable) {
return Health.up()
.withDetail("externalApi", "reachable")
.build();
}

return Health.down()
.withDetail("externalApi", "not reachable")
.build();
}
}

Memory sentence:

Custom health indicators add application-specific health checks.


12. Liveness and Readiness

In container platforms like Kubernetes, two health ideas are common:

liveness
readiness

Liveness

Question:

Should the container be restarted?

Example:

The app is stuck and cannot recover.

Readiness

Question:

Should traffic be sent to this instance?

Example:

The app is starting, database migration is running, or dependency is not ready.

Memory sentence:

Liveness is about restart; readiness is about receiving traffic.


13. Info Endpoint

Endpoint:

/actuator/info

It can expose general application information.

Example configuration:

info:
app:
name: klarsync
description: Tax workflow platform
version: 1.0.0

Example response:

{
"app": {
"name": "klarsync",
"description": "Tax workflow platform",
"version": "1.0.0"
}
}

Memory sentence:

/actuator/info exposes application metadata.


14. Metrics Endpoint

Endpoint:

/actuator/metrics

It shows available metric names.

Example metric names:

http.server.requests
jvm.memory.used
jvm.threads.live
process.cpu.usage
system.cpu.usage
hikaricp.connections.active
logback.events

To inspect one metric:

/actuator/metrics/http.server.requests

Memory sentence:

/actuator/metrics shows numeric measurements about the running app.


15. What Are Metrics?

Metrics are numeric measurements over time.

Examples:

request count
request duration
error count
memory usage
CPU usage
active database connections
cache hits
cache misses
queue size
scheduled job duration

Metrics answer:

How much?
How often?
How slow?
How many errors?

Memory sentence:

Metrics turn application behavior into numbers.


16. Micrometer

Micrometer is the metrics facade used by Spring Boot.

Simple idea:

Application code records metrics with Micrometer.
Micrometer sends metrics to monitoring systems.

Monitoring systems can include:

Prometheus
Datadog
New Relic
Graphite
OTLP/OpenTelemetry

Memory sentence:

Micrometer is a vendor-neutral facade for application metrics.


17. Prometheus

Prometheus is a monitoring system that scrapes metrics.

Spring Boot can expose:

/actuator/prometheus

Prometheus reads this endpoint regularly.

Example dependency:

implementation("io.micrometer:micrometer-registry-prometheus")

Example exposure:

management:
endpoints:
web:
exposure:
include: health,info,prometheus

Memory sentence:

Prometheus scrapes /actuator/prometheus.


18. Prometheus Flow

Spring Boot app
↓ exposes
/actuator/prometheus
↓ scraped by
Prometheus
↓ visualized by
Grafana

Common setup:

Spring Boot + Actuator + Micrometer + Prometheus + Grafana

Memory sentence:

Prometheus collects metrics; Grafana visualizes them.


19. Custom Metrics

Sometimes built-in metrics are not enough.

Example:

@Service
public class InvoiceService {

private final Counter invoiceCreatedCounter;

public InvoiceService(MeterRegistry meterRegistry) {
this.invoiceCreatedCounter = Counter.builder("invoices.created")
.description("Number of created invoices")
.register(meterRegistry);
}

public void createInvoice() {
// business logic
invoiceCreatedCounter.increment();
}
}

This creates a custom metric:

invoices.created

Memory sentence:

Custom metrics measure business-specific behavior.


20. Timer Metric

Use a timer for duration.

Example:

@Service
public class ReportService {

private final Timer reportTimer;

public ReportService(MeterRegistry meterRegistry) {
this.reportTimer = Timer.builder("reports.generation.duration")
.description("Time to generate reports")
.register(meterRegistry);
}

public Report generateReport() {
return reportTimer.record(() -> {
// generate report
return new Report();
});
}
}

Memory sentence:

Timers measure how long operations take.


21. Metric Tags

Tags add dimensions.

Example:

Counter.builder("tasks.created")
.tag("tenant", tenantId.toString())
.tag("status", "success")
.register(meterRegistry)
.increment();

But be careful.

Bad tags:

userId
email
requestId
full URL with IDs
random UUID

Why?

too many unique tag values
high cardinality
monitoring system overload
high memory usage
expensive queries

Memory sentence:

Metric tags should be low-cardinality.


22. High Cardinality Trap

Bad metric:

http.request.user.email=user123@example.com
http.request.user.email=user456@example.com
http.request.user.email=user789@example.com

Problem:

too many unique time series
large memory usage
slow monitoring queries
expensive monitoring

Better:

status=success/failure
method=GET/POST
endpoint=/api/tasks/{id}
tenant_type=small/large

Memory sentence:

Never put user IDs, emails, or random IDs into metric tags.


23. Logging

Logs answer:

What happened?

Example log:

2026-07-07 10:15:30 INFO TaskService - Created task id=123 tenant=5

Good logs help debug:

errors
business events
slow operations
external API failures
security events
background job failures

Memory sentence:

Logs explain what happened.


24. Good Logging

Good log:

log.info("Created task id={} tenantId={}", taskId, tenantId);

Bad log:

log.info("Created task " + task);

Why bad?

may log too much
may expose sensitive data
harder to search
can trigger lazy loading

Memory sentence:

Log important facts, not huge objects.


25. Do Not Log Secrets

Never log:

passwords
JWT tokens
refresh tokens
API keys
credit card data
private personal data
session cookies
reset tokens
authorization headers

Bad:

log.info("Login request: {}", request);

If request contains password, this is dangerous.

Memory sentence:

Logs are production data; never log secrets.


26. Log Levels

Common log levels:

LevelMeaning
TRACEvery detailed diagnostic info
DEBUGdevelopment/debug information
INFOnormal important events
WARNunexpected but recoverable problem
ERRORfailure that needs attention

Memory sentence:

Use log levels to show severity.


27. Loggers Endpoint

Actuator endpoint:

/actuator/loggers

It can show and sometimes modify logger levels at runtime.

Example:

/actuator/loggers/com.example.TaskService

This is useful when debugging production issues.

But it must be secured.

Memory sentence:

/actuator/loggers can help debug production, but it is sensitive.


28. Tracing

Metrics answer:

How many? How slow?

Logs answer:

What happened?

Traces answer:

Where did this request go?

In microservices, one request may travel through many services:

frontend

backend API

user service

task service

database

external API

Tracing connects these steps.

Memory sentence:

Tracing follows one request across components.


29. Span and Trace

A trace represents one end-to-end operation.

A span represents one step inside that trace.

Example:

Trace: Create task request
Span 1: HTTP POST /api/tasks
Span 2: validate request
Span 3: save task to database
Span 4: publish event
Span 5: send notification

Memory sentence:

A trace contains spans.


30. Correlation ID

A correlation ID is an ID used to connect logs for the same request.

Example:

traceId=abc123 POST /api/tasks started
traceId=abc123 validating request
traceId=abc123 saved task id=55
traceId=abc123 POST /api/tasks finished

This helps find all logs for one request.

Memory sentence:

Correlation IDs connect logs belonging to the same request.


31. Micrometer Tracing

Spring Boot supports Micrometer Tracing.

It can integrate with tracing systems such as:

OpenTelemetry
Zipkin

Tracing can help answer:

Which service is slow?
Where did the request fail?
Which database call was expensive?
Which downstream call caused latency?

Memory sentence:

Micrometer Tracing connects request flow across components.


32. Observability: Logs, Metrics, Traces

The three common observability pillars:

logs
metrics
traces
ToolAnswers
LogsWhat happened?
MetricsHow many, how slow, how often?
TracesWhere did the request go?

Memory sentence:

Logs tell stories, metrics show numbers, traces show paths.


33. Actuator Mappings Endpoint

Endpoint:

/actuator/mappings

It shows request mappings.

Useful for debugging:

Which endpoints exist?
Which controller handles this path?
Why is my endpoint not reachable?
Which HTTP method is mapped?

Memory sentence:

/actuator/mappings shows controller route mappings.


34. Actuator Beans Endpoint

Endpoint:

/actuator/beans

It shows Spring beans in the application context.

Useful for debugging:

Was my bean created?
Which bean name exists?
Which dependencies are wired?
Why is auto-configuration creating this bean?

But it can expose internal structure.

Memory sentence:

/actuator/beans shows the Spring application context structure.


35. Actuator Conditions Endpoint

Endpoint:

/actuator/conditions

It shows auto-configuration condition evaluation.

Useful for debugging:

Why was this auto-configuration applied?
Why was this auto-configuration not applied?
Which condition matched?
Which condition did not match?

Memory sentence:

/actuator/conditions helps debug auto-configuration.


36. Actuator Caches Endpoint

Endpoint:

/actuator/caches

It shows cache managers and caches.

Useful for:

checking cache names
debugging cache configuration
clearing caches if enabled

Memory sentence:

/actuator/caches helps inspect cache infrastructure.


37. Actuator Scheduled Tasks Endpoint

Endpoint:

/actuator/scheduledtasks

It shows scheduled tasks.

Useful for:

checking cron jobs
checking fixed delay jobs
checking fixed rate jobs
debugging missing scheduled methods

Memory sentence:

/actuator/scheduledtasks helps inspect scheduled jobs.


38. Actuator Metrics Endpoint

Endpoint:

/actuator/metrics

Useful examples:

/actuator/metrics/http.server.requests
/actuator/metrics/jvm.memory.used
/actuator/metrics/hikaricp.connections.active
/actuator/metrics/cache.gets

It helps answer:

Is the app slow?
Are requests failing?
Is memory growing?
Are database connections exhausted?
Is cache working?

Memory sentence:

Metrics help diagnose performance and resource problems.


39. HTTP Request Metrics

Important metric:

http.server.requests

It can show:

request count
response status
HTTP method
URI pattern
duration
exceptions

Useful questions:

Which endpoint is slow?
Which endpoint returns many 500 errors?
How many requests hit this API?

Memory sentence:

HTTP metrics show request volume, latency, and errors.


40. Database Pool Metrics

If using HikariCP, useful metrics can include:

hikaricp.connections.active
hikaricp.connections.idle
hikaricp.connections.pending
hikaricp.connections.max

These help answer:

Are database connections exhausted?
Are requests waiting for a connection?
Is the pool too small?
Is there a connection leak?

Memory sentence:

Database pool metrics help diagnose database pressure.


41. JVM Metrics

Common JVM metrics:

jvm.memory.used
jvm.memory.max
jvm.threads.live
jvm.gc.pause
process.cpu.usage
system.cpu.usage

They help answer:

Is memory too high?
Is garbage collection expensive?
Are too many threads running?
Is CPU overloaded?

Memory sentence:

JVM metrics show application runtime health.


42. Production Diagnostic Flow

When a production issue happens, ask:

Is the app UP?
Are dependencies healthy?
Are errors increasing?
Which endpoint is slow?
Is database pool exhausted?
Is memory high?
Are logs showing exceptions?
Can I find the trace?
Did deployment change recently?

A good investigation order:

1. health
2. logs
3. metrics
4. traces
5. recent deployment/config changes
6. database/external dependency checks

Memory sentence:

Diagnose production with health, logs, metrics, and traces together.


43. Example: API Is Slow

Symptoms:

Users say /api/tasks is slow.

Check:

/actuator/health
/actuator/metrics/http.server.requests
/actuator/metrics/hikaricp.connections.active
application logs
traces for /api/tasks
database query logs

Possible causes:

slow database query
N+1 problem
database connection pool exhausted
external API slow
too much CPU usage
large response payload
cache not working

Memory sentence:

Slow APIs need metrics plus traces plus logs.


44. Example: App Is DOWN

Check:

/actuator/health

Possible component:

db DOWN
redis DOWN
diskSpace DOWN
external dependency DOWN

Then check logs.

Memory sentence:

Health tells what is broken; logs explain why.


45. Example: Endpoint Missing

Problem:

GET /api/tasks returns 404.

Check:

/actuator/mappings

Possible causes:

wrong path
wrong HTTP method
controller bean not loaded
wrong profile
security blocking request
context path mismatch

Memory sentence:

/actuator/mappings helps debug missing endpoints.


46. Example: Bean Missing

Problem:

Application does not create MyService bean.

Check:

/actuator/beans
/actuator/conditions
logs at startup

Possible causes:

package not scanned
profile mismatch
conditional bean did not match
missing dependency
configuration property missing

Memory sentence:

Beans and conditions endpoints help debug Spring context problems.


47. Actuator Security

Production recommendation:

Expose only safe endpoints.
Secure sensitive endpoints.
Do not expose env/beans/conditions publicly.
Use authentication and authorization.
Use network restrictions if possible.
Do not leak secrets.

Example:

management:
endpoints:
web:
exposure:
include: health,info,prometheus

For internal debugging, expose more only in protected environments.

Memory sentence:

Never leave sensitive Actuator endpoints open to the public internet.


48. Separate Management Port

Sometimes management endpoints use a separate port.

Example:

management:
server:
port: 8081

Then app endpoints might run on:

8080

and management endpoints on:

8081

Useful for:

network-level restrictions
internal-only monitoring
separate firewall rules

Memory sentence:

A separate management port can help isolate Actuator endpoints.


49. Kubernetes Health Checks

In Kubernetes-like systems, health endpoints are commonly used for probes.

Readiness probe:

Should this pod receive traffic?

Liveness probe:

Should this pod be restarted?

Bad readiness can cause traffic to broken instances.

Bad liveness can cause restart loops.

Memory sentence:

Health checks directly affect deployment behavior.


50. Common Observability Mistakes

Mistake examples:

no Actuator in production
too many Actuator endpoints exposed
no metrics dashboard
no alerts
logs contain secrets
logs do not include useful IDs
high-cardinality metric tags
no correlation ID
no tracing in distributed systems
health checks depend on too many external systems
liveness and readiness are confused
debug endpoints exposed publicly

Memory sentence:

Observability must be useful and safe.


51. What Is Enough for Spring Professional Exam?

For the exam, I should understand:

Actuator purpose
starter-actuator dependency
/actuator base path
health endpoint
info endpoint
metrics endpoint
prometheus endpoint
loggers endpoint
mappings endpoint
beans endpoint
conditions endpoint
caches endpoint
scheduledtasks endpoint
endpoint exposure
endpoint security
health indicators
custom health indicators
Micrometer
metrics
Prometheus
logs
traces
correlation IDs
liveness vs readiness
production diagnostics

Memory sentence:

For the exam, know what Actuator exposes and why it matters.


52. Actuator Endpoint Exam Table

EndpointPurpose
healthapplication health
infoapplication information
metricsapplication metrics
prometheusPrometheus scrape format
loggersinspect/change log levels
mappingsrequest mappings
beansSpring beans
conditionsauto-configuration condition report
cachescache information
scheduledtasksscheduled job information
envenvironment properties
configpropsconfiguration properties
threaddumpthread dump
heapdumpheap dump

Memory sentence:

Know the main Actuator endpoints and what each one helps diagnose.


53. Real Exam Question: Actuator

Question:

What is Spring Boot Actuator?

Answer:

Spring Boot Actuator provides production-ready features for monitoring and managing a running Spring Boot application, usually through endpoints such as health, info, metrics, loggers, mappings, and more.


54. Real Exam Question: Health

Question:

What does /actuator/health show?

Answer:

It shows the health status of the application and, depending on configuration, the health of components such as database, disk space, or other dependencies.


55. Real Exam Question: Info

Question:

What does /actuator/info show?

Answer:

It shows arbitrary application information, such as application name, version, description, build data, or Git information if configured.


56. Real Exam Question: Metrics

Question:

What does /actuator/metrics show?

Answer:

It shows available application metrics and lets me inspect specific metric values such as HTTP requests, JVM memory, CPU usage, database connection pool metrics, and cache metrics.


57. Real Exam Question: Prometheus

Question:

What is /actuator/prometheus used for?

Answer:

It exposes application metrics in a format that Prometheus can scrape.


58. Real Exam Question: Micrometer

Question:

What is Micrometer?

Answer:

Micrometer is a metrics facade used by Spring Boot to record and export metrics to monitoring systems such as Prometheus, Datadog, New Relic, or OTLP-compatible systems.


59. Real Exam Question: Observability

Question:

What are the three common pillars of observability?

Answer:

Logs, metrics, and traces.


60. Real Exam Question: Tracing

Question:

What does tracing help with?

Answer:

Tracing helps follow a request across components or services, showing where time was spent and where failures happened.


61. Real Exam Question: Securing Actuator

Question:

Why should Actuator endpoints be secured?

Answer:

Because they can expose sensitive operational information such as beans, environment properties, mappings, cache names, logger configuration, and system details.


62. Interview Answer

Question:

How do you monitor a Spring Boot application?

Good answer:

I usually add Spring Boot Actuator and expose safe endpoints such as health, info, metrics, and Prometheus. I use /actuator/health for health checks, /actuator/metrics for runtime metrics, and /actuator/prometheus for Prometheus scraping. I also collect logs and, in distributed systems, use tracing with correlation IDs so I can connect requests across services.


63. Interview Answer

Question:

What is the difference between logs, metrics, and traces?

Good answer:

Logs describe what happened as events or messages. Metrics provide numeric measurements over time, such as request count, latency, memory, and error rates. Traces show the path of a single request across components or services. In production, I use all three together because each answers a different diagnostic question.


64. Interview Answer

Question:

Which Actuator endpoints are safe to expose?

Good answer:

It depends on the environment, but in production I usually expose only limited endpoints such as health, info, and Prometheus, and I secure them properly. Sensitive endpoints such as env, beans, conditions, mappings, loggers, heapdump, and threaddump should not be publicly exposed because they can reveal internal details or sensitive information.


65. Interview Answer

Question:

How would you debug a slow endpoint in Spring Boot?

Good answer:

I would first check health to ensure dependencies are available. Then I would look at HTTP request metrics, especially latency and error rate for the endpoint. I would check database pool metrics, JVM metrics, and application logs. If tracing is available, I would inspect the trace for a slow request to see whether the time is spent in the controller, service, database, or external API.


66. Tiny Code Practice 1

Add Actuator.

Gradle:

implementation("org.springframework.boot:spring-boot-starter-actuator")

Expose safe endpoints:

management:
endpoints:
web:
exposure:
include: health,info,metrics,prometheus

Question:

Why not expose all endpoints?

Answer:

Because some endpoints reveal sensitive internal application information.

67. Tiny Code Practice 2

Add app info.

info:
app:
name: klarsync
version: 1.0.0
description: Tax workflow platform

Endpoint:

/actuator/info

Memory sentence:

The info endpoint can expose application metadata.


68. Tiny Code Practice 3

Create a custom health indicator.

@Component
public class SearchServiceHealthIndicator implements HealthIndicator {

private final SearchClient searchClient;

public SearchServiceHealthIndicator(SearchClient searchClient) {
this.searchClient = searchClient;
}

@Override
public Health health() {
if (searchClient.isAvailable()) {
return Health.up()
.withDetail("search", "available")
.build();
}

return Health.down()
.withDetail("search", "unavailable")
.build();
}
}

Question:

When is this useful?

Answer:

When my application depends on an important component that Spring Boot does not check automatically.

69. Tiny Code Practice 4

Create a custom counter.

@Service
public class TaskMetricsService {

private final Counter createdTasksCounter;

public TaskMetricsService(MeterRegistry meterRegistry) {
this.createdTasksCounter = Counter.builder("tasks.created")
.description("Number of created tasks")
.register(meterRegistry);
}

public void recordTaskCreated() {
createdTasksCounter.increment();
}
}

Memory sentence:

Custom metrics measure business events.


70. Tiny Bug Practice 1

Problem:

management:
endpoints:
web:
exposure:
include: "*"

Question:

What is dangerous?

Answer:

This exposes all Actuator endpoints over HTTP. Sensitive endpoints may reveal internal information. Expose only needed endpoints and secure them.


71. Tiny Bug Practice 2

Problem:

Counter.builder("login.attempts")
.tag("email", email)
.register(meterRegistry)
.increment();

Question:

What is wrong?

Answer:

Email is high-cardinality and sensitive. It can create too many metric series and expose private data. Use low-cardinality tags like status=success/failure.


72. Tiny Bug Practice 3

Problem:

log.info("Authorization header: {}", authorizationHeader);

Question:

What is wrong?

Answer:

Authorization headers may contain bearer tokens or credentials. Never log secrets.


73. Tiny Bug Practice 4

Problem:

Liveness probe checks database.
Database has short outage.
Kubernetes restarts all app pods.

Question:

What is wrong?

Answer:

Database availability is usually a readiness concern, not necessarily a liveness concern. Bad liveness checks can cause unnecessary restart loops.


74. Final Exercise

Question 1

What is Spring Boot Actuator?

My answer:


Question 2

What does /actuator/health show?

My answer:


Question 3

What does /actuator/info show?

My answer:


Question 4

What does /actuator/metrics show?

My answer:


Question 5

What is /actuator/prometheus used for?

My answer:


Question 6

What is Micrometer?

My answer:


Question 7

What are logs?

My answer:


Question 8

What are metrics?

My answer:


Question 9

What are traces?

My answer:


Question 10

What is a correlation ID?

My answer:


Question 11

What is the difference between liveness and readiness?

My answer:


Question 12

Why should Actuator endpoints be secured?

My answer:


Question 13

Why are high-cardinality metric tags dangerous?

My answer:


Question 14

Which endpoints help debug missing routes?

My answer:


Question 15

Which endpoints help debug auto-configuration?

My answer:


Question 16

Which endpoint helps inspect scheduled jobs?

My answer:


Question 17

Which endpoint helps inspect cache infrastructure?

My answer:


Question 18

What should I never log?

My answer:


Question 19

How would I debug a slow API?

My answer:


Question 20

What are the three pillars of observability?

My answer:


75. Model Answers

Answer 1

Spring Boot Actuator provides production-ready monitoring and management endpoints for a running Spring Boot application.


Answer 2

It shows the health status of the application and its components.


Answer 3

It shows application metadata such as name, version, description, build info, or Git info if configured.


Answer 4

It shows runtime metrics such as HTTP requests, JVM memory, CPU usage, database connection pool metrics, and cache metrics.


Answer 5

It exposes metrics in Prometheus scrape format.


Answer 6

Micrometer is a metrics facade used by Spring Boot to record and export metrics to monitoring systems.


Answer 7

Logs are event messages that explain what happened in the application.


Answer 8

Metrics are numeric measurements over time.


Answer 9

Traces show the path of one request across components or services.


Answer 10

A correlation ID connects logs and traces that belong to the same request.


Answer 11

Liveness asks whether the app should be restarted. Readiness asks whether the app should receive traffic.


Answer 12

Because they can reveal sensitive internal information about the application and infrastructure.


Answer 13

They create too many unique time series, increase memory usage, slow monitoring queries, and may expose sensitive data.


Answer 14

/actuator/mappings.


Answer 15

/actuator/conditions.


Answer 16

/actuator/scheduledtasks.


Answer 17

/actuator/caches.


Answer 18

Passwords, tokens, API keys, session cookies, authorization headers, reset tokens, credit card data, and sensitive personal data.


Answer 19

Check health, HTTP metrics, database pool metrics, JVM metrics, logs, traces, and recent deployment/config changes.


Answer 20

Logs, metrics, and traces.


76. Final Spring Professional Review

This book covered the most important Spring Professional topics.

Spring Core

IoC container
ApplicationContext
BeanFactory
beans
dependency injection
component scanning
@Configuration
@Bean
profiles
external configuration
bean scopes
bean lifecycle

Memory sentence:

Spring creates and wires objects so the application is loosely coupled.


Spring Boot

@SpringBootApplication
auto-configuration
starters
dependency management
externalized configuration
Actuator
application startup
runners
events
production features

Memory sentence:

Spring Boot makes Spring applications faster to configure and production-ready.


Spring MVC

DispatcherServlet
controllers
@RequestMapping
@GetMapping
@PostMapping
@RequestBody
@ResponseBody
ResponseEntity
validation
exception handling
@ControllerAdvice
REST APIs

Memory sentence:

Spring MVC maps HTTP requests to controller methods.


Spring Data JPA

JPA
Hibernate
entities
repositories
EntityManager
transactions
persistence context
dirty checking
relationships
lazy loading
fetch joins
projections
N+1 problem
@DataJpaTest

Memory sentence:

Spring Data JPA simplifies database access, but I still need to understand JPA behavior.


Transactions

@Transactional
rollback rules
runtime exceptions
checked exceptions
readOnly
propagation
isolation
persistence context
dirty checking
self-invocation
proxy-based behavior

Memory sentence:

Transactions are usually applied through Spring proxies.


Spring Security

SecurityFilterChain
authentication
authorization
UserDetailsService
PasswordEncoder
AuthenticationManager
roles
authorities
method security
@PreAuthorize
CSRF
CORS
sessions
stateless APIs
JWT
security testing

Memory sentence:

Authentication proves identity; authorization checks permission.


Testing

unit tests
JUnit
AssertJ
Mockito
@WebMvcTest
MockMvc
@DataJpaTest
TestEntityManager
@SpringBootTest
Testcontainers
spring-security-test
@WithMockUser
csrf()
jwt()

Memory sentence:

Choose the smallest test that proves the behavior.


AOP

aspects
advice
pointcuts
join points
proxies
JDK dynamic proxy
CGLIB proxy
self-invocation
@Transactional
@Async
@Cacheable
method security

Memory sentence:

Spring AOP works when calls go through the proxy.


Events

ApplicationEventPublisher
@EventListener
@TransactionalEventListener
AFTER_COMMIT
async event listeners
in-process events
event design
domain events

Memory sentence:

Events say that something happened.


Scheduling and Async

@Scheduled
@EnableScheduling
fixedRate
fixedDelay
cron
@Async
@EnableAsync
executors
thread pools
multi-instance scheduled jobs
idempotency

Memory sentence:

Scheduling is about time; async is about threads.


Caching

@EnableCaching
@Cacheable
@CachePut
@CacheEvict
cache names
cache keys
condition
unless
TTL
CacheManager
local cache
distributed cache
self-invocation

Memory sentence:

Cache keys must include everything that affects the result.


Observability and Actuator

Actuator
health
info
metrics
Prometheus
Micrometer
logs
traces
correlation IDs
mappings
beans
conditions
scheduledtasks
caches
endpoint security

Memory sentence:

Production applications need health, logs, metrics, and traces.


77. Final Exam Mindset

For Spring Professional exam, do not only memorize annotations.

Understand:

What problem does this feature solve?
Which Spring component enables it?
Is it proxy-based?
Does self-invocation matter?
Does it require a Spring bean?
Does it happen before or after the controller?
Does it happen inside or outside a transaction?
Is it synchronous or asynchronous?
Is it local or distributed?
What is the production trap?

Memory sentence:

Spring exam questions often test behavior, not only annotation names.


78. Final Master Memory Sentences

Memorize these:

Spring manages beans in the ApplicationContext.

Dependency injection reduces coupling.

@Configuration and @Bean define beans manually.

@Component scanning discovers beans automatically.

Profiles select environment-specific beans and configuration.

External configuration should not be hardcoded.

Spring Boot auto-configuration configures beans based on classpath and properties.

DispatcherServlet is the front controller in Spring MVC.

@ControllerAdvice centralizes exception handling.

Bean Validation protects request boundaries.

JPA is the specification; Hibernate is the implementation.

Spring Data JPA creates repository implementations.

@Transactional is proxy-based in default Spring mode.

Runtime exceptions roll back by default.

Persistence context tracks managed entities.

Dirty checking updates changed managed entities.

Lazy loading needs an open persistence context.

N+1 happens when many lazy associations are loaded one by one.

Spring Security runs before controllers.

Authentication means who are you.

Authorization means what can you do.

401 means not authenticated.

403 means authenticated but forbidden.

PasswordEncoder hashes and verifies passwords.

hasRole("ADMIN") checks ROLE_ADMIN.

CSRF protects browser cookie-based state-changing requests.

CORS controls browser cross-origin access.

JWT is signed, not necessarily encrypted.

Unit tests do not start Spring.

@WebMvcTest tests controllers.

@DataJpaTest tests repositories.

@SpringBootTest loads the full application context.

Spring AOP is proxy-based.

Self-invocation bypasses proxy advice.

Events decouple reactions from main actions.

@Scheduled runs jobs by time.

@Async runs work in another thread.

@Cacheable may skip method execution.

Actuator exposes production diagnostics.

Logs tell what happened.

Metrics show numbers over time.

Traces show request paths.

79. Final Result

If I understand this book, I can explain the core Spring Professional topics:

Spring Core
Spring Boot
Spring MVC
Spring Data JPA
Transactions
Spring Security
Testing
AOP
Events
Scheduling
Async
Caching
Actuator
Observability

This is a strong foundation for the Spring Professional exam and for real Spring Boot backend work.

Final sentence:

I do not just know Spring annotations.
I understand how Spring works behind them.