Spring Boot Runners, Servers & Configuration — Interview Questions

How to use this lesson

These questions check that you've actually run Spring Boot applications: changed ports, fixed dependency conflicts, run start-up tasks. Give the exact property names. That's what makes the answers credible.

Q1. What is ApplicationRunner?

Short answer: A callback interface. Any ApplicationRunner bean's run(ApplicationArguments args) method executes once, after the application context has started, and just before the app is reported as ready. It's used for start-up tasks: seeding reference data, warming caches, validating configuration.

@Component
class CacheWarmer implements ApplicationRunner {
    private final ProductCatalog catalog;
    CacheWarmer(ProductCatalog catalog) { this.catalog = catalog; }

    @Override public void run(ApplicationArguments args) {
        if (args.containsOption("skip-warmup")) return;       // --skip-warmup
        catalog.loadTopSellers();
    }
}

Q2. What is CommandLineRunner, and how does it differ from ApplicationRunner?

Short answer: It serves the same purpose. The difference is the arguments: CommandLineRunner.run(String... args) receives the raw argument strings, while ApplicationRunner receives parsed ApplicationArguments, where you can query options (--name=value) separately from non-option arguments.

Key points to cover:

• Order several runners with @Order, or by implementing Ordered.
• An exception thrown from a runner fails the startup. That's good for validation, but wrap optional work in try/catch.
• For long-running work, don't block startup. Kick off an async task, or react to ApplicationReadyEvent instead.

Q3. What is the Spring Boot CLI, and what commands are commonly used?

Short answer: A command-line tool for bootstrapping Spring Boot projects:

• spring init: generate a project from Spring Initializr, for example spring init --dependencies=web,data-jpa demo.
• spring help.
• spring encodepassword: create a hashed password for Spring Security.

Key points to cover:

• Older answers mention spring run app.groovy and spring test for running Groovy scripts. That script-running support was removed in Spring Boot 3. Today the CLI is mainly a project generator, and most developers use start.spring.io or their IDE instead.

Q4. What is Spring Boot dependency management?

Short answer: Spring Boot publishes a bill of materials (spring-boot-dependencies) that pins compatible versions of hundreds of libraries: Hibernate, Jackson, Tomcat, Kafka clients and more. When you inherit spring-boot-starter-parent, or import the BOM, you declare dependencies without versions, and they're guaranteed to work together.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.4.1</version>
</parent>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>   <!-- no version: managed -->
</dependency>

Key points to cover:

• To override a managed version, set the property the BOM uses, for example <jackson-bom.version>, rather than hard-coding a version on one artifact.

Q5. What happens when a starter brings in a library version that conflicts with another dependency?

Short answer: Maven and Gradle each put only one version of an artifact on the classpath:

• Maven picks the nearest declaration in the dependency tree ("nearest wins"). A tie goes to the first declared.
• Gradle picks the highest version by default.
• Spring Boot's dependency management pins its managed libraries, so the BOM version usually decides.

If the chosen version is incompatible with some library, you get runtime errors such as NoSuchMethodError or ClassNotFoundException.

Key points to cover:

• Diagnose it with mvn dependency:tree -Dverbose or gradle dependencyInsight --dependency jackson-databind.
• Fix it by aligning on the BOM version, adding <exclusions>, or pinning a version in <dependencyManagement>.

Common trap: saying the build tool "picks the most compatible version". It doesn't check compatibility at all. It applies mechanical rules.

Q6. How do you change the embedded Tomcat port?

Short answer: Set server.port:

server:
  port: 9090          # application.yml

Or override it at launch: java -jar app.jar --server.port=9090, or with the environment variable SERVER_PORT=9090.

Key points to cover:

• server.port=0 picks a random free port. That's useful in tests, together with @LocalServerPort.
• For programmatic control, use a WebServerFactoryCustomizer<ConfigurableServletWebServerFactory>.

Q7. What is the default embedded server port?

Short answer: 8080, for Tomcat, and also for Jetty, Undertow, and Netty in WebFlux. The management (Actuator) endpoints use the same port unless you set management.server.port.

Q8. Can you disable the embedded web server?

Short answer: Yes. Set spring.main.web-application-type=none, and Spring Boot starts a plain application context with no web server. That's useful for batch jobs, Kafka consumers or CLI tools. You can also leave the web starter out entirely.

new SpringApplicationBuilder(BatchApp.class).web(WebApplicationType.NONE).run(args);

Q9. How do you disable a specific auto-configuration class?

Short answer: Use the exclude attribute, or a property:

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
public class App { }

spring:
  autoconfigure:
    exclude: org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

Key points to cover:

• A typical case: a JDBC driver is on the classpath (pulled in by another library), but this service has no database. Boot would fail at startup with "Failed to configure a DataSource: 'url' attribute is not specified".

Q10. Can you build a non-web application with Spring Boot?

Short answer: Absolutely. Batch jobs, schedulers, message consumers and command-line tools all benefit from Boot's DI, configuration and auto-configuration without needing a web server. Leave out the web starter, or set web-application-type=none, and put your logic in a CommandLineRunner, @Scheduled methods or @KafkaListeners.

Q11. Describe the flow of an HTTPS request through a Spring Boot application.

Short answer:

1. TLS handshake and decryption: at the embedded server's HTTPS connector, or, often in production, at a load balancer or ingress in front of the app.
2. Tomcat parses the HTTP request, and hands it to the servlet filter chain. That includes the Spring Security filters (authentication, CSRF, CORS).
3. The DispatcherServlet asks the HandlerMapping for the matching controller method.
4. Argument resolution: @PathVariable, @RequestParam, and @RequestBody JSON deserialised by Jackson, plus @Valid validation.
5. The controller calls a service (business logic, @Transactional), which calls a repository (database).
6. The return value is serialised to JSON by an HttpMessageConverter, and exceptions go through @ControllerAdvice handlers.
7. The response travels back through the filters, and is encrypted on the way out.

Key points to cover:

• Enable TLS in Boot with server.ssl.* properties, or SSL bundles (spring.ssl.bundle.*, Boot 3.1+).
• When TLS is terminated at the load balancer, configure server.forward-headers-strategy=framework, so that redirects and generated links still use https.

Learn it in depth → REST Controllers

Follow-up questions this topic invites — and their answers

Q: What is the order of precedence for configuration sources? A: From highest to lowest (simplified):

1. Command-line arguments.
2. Environment variables and system properties.
3. Profile-specific files (application-prod.yml).
4. application.yml.
5. Defaults in code.

Later sources override earlier ones for the same key.

Q: How do you switch from Tomcat to Jetty or Undertow? A: Exclude spring-boot-starter-tomcat from spring-boot-starter-web, and add spring-boot-starter-jetty (or -undertow). Auto-configuration detects the server on the classpath.

Q: What is graceful shutdown? A: With server.shutdown=graceful, the server stops accepting new requests on SIGTERM, and lets in-flight requests finish within spring.lifecycle.timeout-per-shutdown-phase. That matters for zero-downtime deployments on Kubernetes.

Q: application.properties or application.yml? A: They're functionally equivalent. YAML is more readable for nested and list configuration, and supports multi-document files. Pick one per project, and stay consistent.