Spring Boot Interview Questions and Answers (Microservices, Data, Security)

They don’t want Spring logo trivia.

They want the 2 a.m. version. Why a bean didn’t wire. Why @Transactional rolled back on a checked exception you forgot existed. How you’d split a monolith without turning every hop into an outage.

That’s Spring Boot interview questions on an experienced backend loop. Core Java still sits underneath: Java interview questions for experienced developers. Boundaries and failure modes: microservices design, microservices architecture.

Samples are made up. Say them out loud. Green checks on a quiz site don’t kill the “um, basically.”

Auto-config, starters, beans

What does auto-configuration actually do?

Boot peeks at your classpath and application properties. Then it flips conditional config so web, JPA, Actuator show up without a 400-line XML file.

Go one level deeper in the room. @ConditionalOnClass. @ConditionalOnMissingBean. @ConditionalOnProperty. You don’t need every condition memorized. You need: if you already defined the bean, Boot backs off. If the jar isn’t there, the feature stays off.

Spoken: “Opinionated defaults with gates. DataSource on the classpath and I didn’t define one? It wires from spring.datasource.*. Default fighting me? I exclude that auto-config class.”

Starters vs plain jars

Starters (starter-web, starter-data-jpa, starter-security) are curated sets so you’re not hand-picking servlet and Jackson versions. Starter = convenience. Plain jar when the starter is too heavy. That’s the contrast they want.

Wiring failures that sound real

@Component / @Service / @Repository / @Configuration + @Bean. Singleton vs prototype. Prefer constructor injection in new code.

Stuff that shows up at 2 a.m.:

• Constructor cycles (redesign first; @Lazy isn’t a lifestyle)
• Component scan missed a package after a move
• Two beans, same type, no @Qualifier / @Primary
• Calling a @Configuration method like a normal method outside the proxy (older code especially)

Sample (illustrative)

Q: Field @Autowired passes unit tests but hurts design. Why?

A: “Hides the mess. In a unit test I reflect-set fields and never notice six collaborators. Constructor injection makes the graph obvious and keeps fields final. Boot allows both. I default to constructors unless the framework forces something weird.”

REST, JPA, transactions

Controllers they trust

Validation (@Valid). Consistent errors (@ControllerAdvice). Idempotent PUTs. Pagination instead of dumping 50k rows. Content negotiation only if they ask.

Q: Breaking API change. How do you version?

A: “Prefer additive. When I must break, I’ve used /v2/... with a sunset window, or headers if the team already standardized that. Less about fashion. More about: how clients find out, how long v1 lives, how you watch traffic on each.”

JPA / Spring Data

EntityManager vs repositories. Lazy vs eager. N+1. @EntityGraph. Projections. When you drop to JDBC on a hot path.

N+1: “Logs: one query for parents, then N for kids. Join-fetch or entity graph for that path, or a DTO query that only selects what the API returns. I don’t flip everything to EAGER. That hides the bill until production.”

Transactions

@Transactional: default rollback on unchecked. Checked exceptions don’t roll back unless rollbackFor. Self-invocation skips the proxy. Propagation (REQUIRED, REQUIRES_NEW) when payment and audit writes nest.

Q: Expected commit, got rollback. Where first?

A: “Exception type. Proxy self-call. readOnly flag. Did the call cross a bean boundary? Then isolation, and whether a nested REQUIRES_NEW already committed side effects.”

Interview walkthrough: REST/JPA boxes on paper, laptop open, no faces.

Microservices: config, discovery, resilience

Boot alone isn’t a platform. Interviewers want the surrounding pieces.

Config

Central store or Spring Cloud Config. Profiles. Secrets not in git. What happens on a bad config push.

Discovery and routing

Register, heartbeat, stale instance. Gateway for auth and routing. Explain the problem each piece solves. Don’t sell a specific Netflix-OSS year.

Resilience

Timeouts. Retries with jitter. Circuit breakers. Bulkheads. Idempotent consumers. Async angles: message queues / event-driven.

Story (illustrative): “Catalog called inventory with a 30-second HTTP timeout and zero breaker. Inventory hiccuped. Catalog threads stacked. Storefront looked dead. We cut the timeout, added a breaker that served cached availability, let the UI say check stock at checkout for that SKU class. Spring Boot didn’t cause it. Missing resilience did.”

Security (practical)

Filter chain. Authn vs authz. JWT resource-server patterns. @PreAuthorize. CSRF for browser sessions vs stateless APIs. Don’t dump the whole filter order unless they dig.

Q: Public read, privileged write?

A: “Separate matchers. Public GET with rate limiting at the gateway. Writes need a principal plus a role or scope. Keys from a vault, rotated, never baked into the image.”

Concurrency under the web layer: concurrency interview questions.

Testing

Gold answer: slices, not @SpringBootTest for everything.

• @WebMvcTest for controllers
• @DataJpaTest for repos (embedded or Testcontainers)
• @SpringBootTest for a few vertical paths
• @MockBean carefully (hides wiring bugs)
• Testcontainers when Kafka/Postgres fakes lie
• Contract tests if you own both sides

Spoken: “Fast unit tests for domain logic. Slice tests for Spring boundaries. Thin full-context set for wiring. If every test boots the world, people stop running the suite.”

Voice practice with architecture notes nearby. Prep tool on the desk, not in a live interview.

Topic map: auto-config → REST/JPA/TX → microservices → testing.

Behavioral add-ons

Backend loops still want stories. Keep STAR ready for:

• Carving a monolith module into a Boot service
• Pool exhaustion (Hikari defaults matter)
• Eventual consistency on checkout

Quick drill list I’d run the night before:

• Explain @ConditionalOnMissingBean without reading docs
• Draw a request path: filter chain → controller → service → repo
• Name three ways you’ve killed an N+1 in real code
• Walk a rollback that surprised you
• One resilience failure you owned (timeouts, retries, or breakers)

If the interviewer goes deep on connection pools, say the pool size, the timeout, what the wait queue did under load, and what metric told you. Vague “we tuned Hikari” scores flat.

Practicing with OfferBull

Spring prep dies in browser tabs. You need to hear yourself explain @Transactional with no notes.

OfferBull is an AI mock interview app for iOS and Android. Voice interviewer. You speak. Paste a Spring Boot JD or upload a resume. Follow-ups based on what you said. Suggestions and STAR while you practice. English and Chinese.

Before the interview. Not during.

Start an AI mock interview

FAQ

Need Spring Cloud every time? No. Core Boot, data, testing first. Cloud when the JD is microservices-heavy.

XML or Java config? Modern answers assume Java / @Configuration and Boot auto-config. XML only for legacy.

WebFlux? Only if the role lists it. Don’t force Mono into a servlet interview.

How deep on Hibernate? N+1, flush/commit, dirty checking at a practical level. Rare internals unless they push.

Kotlin? If the JD says so. Otherwise Java examples unless they invite Kotlin.

Practice This Out Loud

Tonight: auto-config in 60 seconds, an N+1 fix, a @Transactional rollback surprise, one resilience story. Record it. Then a voice mock with follow-ups. → Practice Now