Spring Boot's essentially your lazy developer best friend. Remember the old XML configuration hell? Boot kills that. It's all about convention over configuration. You get sensible defaults so you can focus on business logic instead of plumbing code. Companies love it because projects launch faster – I've seen teams cut setup time by 70% using starters.

Spring Boot sits on top of Spring Framework like a turbocharger. While Spring gives you components, Boot adds:

• Auto-configuration (no more manual bean setups)
• Embedded servers (Tomcat/Jetty out the box)
• Opinionated starter POMs (dependency management that actually works)
• Production-ready features like metrics and health checks

Last year, I migrated a legacy Spring app to Boot. The config files alone shrunk from 1,200 lines to 200. Magic.

It’s all about conditional beans. Boot scans your classpath and says: "Hey, I see H2 in dependencies? Must be testing mode". It checks:

• What libraries you included (@ConditionalOnClass)
• Whether you defined your own beans (@ConditionalOnMissingBean)
• Your environment properties (@ConditionalOnProperty)

Once at a fintech startup, auto-configuration broke because someone added Redis JAR accidentally. Took us two days to debug. Lesson: understand the magic.

You're basically pulling in an entire universe:

• Embedded Tomcat (default server)
• Spring MVC (for web layers)
• Jackson (JSON serialization)
• Validation API
• Logback logging

The dark side? Dependency creep. I’ve seen bloated WAR files because teams didn’t realize starters bundle optional libraries.

Personal rant: I hate YAML. Indentation errors ruin lives. But technically:

• .properties: Simpler, harder to mess up
• .yml: Supports hierarchies (great for complex setups)

Interviewers care about hierarchical binding. For example, in YAML:

server:
  port: 8080
  tomcat:
    max-threads: 200

Versus flat properties: server.port=8080, server.tomcat.max-threads=200

Beyond dev/prod, create profiles like us-east, eu-central. In code:

@Configuration
@Profile("us-east")
public class USConfig {
    // AWS specific beans
}

Then activate via: spring.profiles.active=us-east,cloud

At my last gig, we used this for region-specific API keys. Works like a charm.

JPA repositories are great for CRUD:

• Automatic queries from method names
• Pagination/sorting out-of-box
• But... N+1 problems everywhere

JDBC Template gives control:

• Handcrafted SQL for complex joins
• Better performance in bulk ops
• Steeper learning curve

I default to JPA but drop to JDBC Template for reporting queries. Hybrid approach wins.

Classic! Two culprits:

1. Checked exceptions: By default, Spring rolls back only on unchecked exceptions. Fix: @Transactional(rollbackFor = IOException.class)
2. Self-invocation: Calling method within same class bypasses proxy. Fix: Use AspectJ weaving or externalize call

I debugged this once where a payment service didn't rollback. The client was furious. Learn from my pain.

Step-by-step:

1. Add spring-boot-starter-security
2. Create JwtUtil class for token generation/parsing
3. Extend OncePerRequestFilter to validate tokens
4. Configure WebSecurityConfigurerAdapter:

   @Configuration
   public class SecurityConfig extends WebSecurityConfigurerAdapter {
       protected void configure(HttpSecurity http) throws Exception {
           http
             .csrf().disable()
             .addFilterBefore(jwtFilter(), UsernamePasswordAuthenticationFilter.class)
             .authorizeRequests()
             .antMatchers("/login").permitAll()
             .anyRequest().authenticated();
       }
   }
   

Tip: Never store unencrypted secrets in properties files. Use environment variables.

Authorization Code Flow:

• For user logins (web apps)
• Redirects to auth provider (Google/GitHub)
• Gets code, exchanges for token

• Machine-to-machine (microservices)
• Uses client ID/secret directly
• No user involvement

I prefer client creds for service-to-service calls. Fewer moving parts.

Two main approaches:

• @WebMvcTest: Slices only web layer. Faster. Use for controller logic:

  @WebMvcTest(UserController.class)
  public class UserControllerTest {
      @Autowired MockMvc mvc;
      
      @Test
      void returns404ForInvalidUser() throws Exception {
          mvc.perform(get("/users/999"))
             .andExpect(status().isNotFound());
      }
  }
  

• @SpringBootTest: Full context startup. Better for integration tests but slower.

Pro tip: Avoid full context tests when possible. They're slow and fragile.

• @Mock (Mockito): Plain mock for unit tests without Spring
• @MockBean (Spring Boot): Replaces/injects mock into Spring context

Translation: Use @Mock in plain unit tests. Use @MockBean when testing Spring components needing mocked dependencies.

I once spent hours debugging because someone used @Mock instead of @MockBean in an integration test. Don't be that person.

Never expose all endpoints! Sensible defaults:

• /health: Liveness/readiness probes
• /info: Build version details
• /metrics: Performance counters (behind auth)
• Block: env, beans, configmaps (security risks!)

Configure in application.properties:

management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=when_authorized

• JAR (executable): Default. Contains embedded server. Run via java -jar app.jar. Perfect for microservices.
• WAR: Deploys to external servers like Tomcat. Use ONLY for legacy environments or shared hosting.

Fun fact: I once converted a 2GB WAR to executable JAR. Startup time dropped from 4 minutes to 25 seconds.

Layer caching is key:

# Stage 1: Build with Maven
FROM maven:3-jdk-11 AS build
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src/ ./src/
RUN mvn package

# Stage 2: Slim runtime
FROM openjdk:11-jre-slim
COPY --from=build /target/app.jar /app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

Notice the dependency caching? That trick saved my CI pipeline 8 minutes per build.

1. Check Actuator /heapdump (download HPROF file)
2. Analyze in Eclipse MAT or VisualVM
3. Suspects: Caching libraries (Ehcache), thread locals, poor session cleanup
4. Enable GC logging: -Xlog:gc*:file=gc.log

Last production fire I fought? Leaking MongoDB connection pool. Never again.

• Auto-configuration internals
• Starter dependencies vs manual setup
• Profiles and configuration hierarchy
• Spring Boot Actuator usage
• Testing strategies for controllers/services

Override in pom.xml:

    com.fasterxml.jackson.core
    jackson-databind
    2.12.3

@SpringBootApplication(exclude = {
    SecurityAutoConfiguration.class
})

But really – don't. Secure your apps properly.