11 Spring Boot Interview Questions That Make You Think

The statement is false.

When it comes to web applications, Spring Boot works with a variety of servlet containers. The default one is Apache Tomcat, but you can also use it with Jetty, Undertow, or without an embedded servlet container at all.

What’s more, Spring Boot isn’t tied to just web applications, though one might get that impression by using the spring-boot-starter-web dependency and thus Spring Boot’s web autoconfiguration. You can write all kinds of services with it, from batch jobs and command-line services, over to messaging backends and reactive web applications.

Spring Boot builds on top of Spring Framework and Spring MVC.

Example: Spring Framework offers you the ability to read in .properties files from a variety of places, e.g. with the help of @PropertySource annotations. It also offers you the ability to write JSON REST controllers with the help of its Web MVC framework.

The issue is, you have to tell Spring from where to read in your properties and properly configure its web framework for e.g. JSON support. Spring Boot, on the other hand, takes these individual pieces and pre-configures them for you. Example:

You can create new Spring Boot projects through the Spring Initializr web application or the Spring Boot CLI. Interestingly enough, Spring Initializr is not just a website where you can generate project skeleton .zip files. It is also an API, that you can programmatically call. All major IDEs (Spring Tool Suite, IntelliJ IDEA Ultimate, Netbeans and VSCode) directly integrate with it, so that you can create new Spring Boot projects right out of your IDE.

As for starters, you need to read the documentation and have a bit of experience. If working with a web application, you will start with spring-boot-starter-web and then add the appropriate starter from the documentation, once you want to include a certain technology. After a while, you will get a good feel for what starters you need for which technologies.

This is because Spring Boot does some dependency management for you.

On a high-level, Spring Boot starters pull-in a parent pom.xml file (or a build.gradle file) which has all the dependencies and respective versions defined that a specific Spring Boot version supports - a so-called bill of materials. You can then simply use those pre-defined versions, or override the version numbers in your own build scripts.

You can find the list of all currently supported 3rd party libraries and versions in the spring-boot-dependencies project.

By default, Spring Boot pulls in properties from almost 20 locations, from environment variables and command-line arguments to configuration files (application.properties).
These locations are also ordered, so that the locations lower in the list, override earlier ones. You can, for example, put a default application.properties inside your deployable .jar file, whereas your ops colleagues only override some of them by supplying their own application.properties file on the deployment machine.

It is essential to understand these locations and the default behavior, as to not re-implement Spring Boot’s properties functionality with a custom PropertySourceProvider or use more heavyweight options like spring-cloud configuration server.

You also need to make sure to understand Spring’s relaxed properties binding concept, in that you can bind properties from those locations to configuration bean properties, without an explicit name match.

The statement is false.

Spring Boot works with a variety of HTML template engines, and while Thymeleaf is a popular choice and fully integrated with Spring, you can also use many others, like Freemarker, Velocity or even JSP (though not strictly a templating engine).

It is usually recommended to go with the option you are most comfortable with / that is being used in your company as the default.

Spring Boot integrates with plenty of Java database access libraries (see a comprehensive list here). The majority of users will probably go with spring-boot-starter-jpa, spring-boot-starter-jdbc or one of the corresponding spring-data projects.

There are also more lightweight alternatives, such as jOOQ or myBatis. Finally, you can always go with NoSQL options, such as MongoDB etc.

First off, it is always a good idea to properly understand the Java logging ecosystem and then read the corresponding Spring Boot chapter on logging.

There are various options when it comes to configuring your output:

The two popular, modern logging libraries, Logback and Log4j2, also support hot reloading of the logging configuration, without having to bounce your application

The simplest way to deploy your Spring Boot application is as a .jar file with an embedded servlet container, to any server or platform that has a JRE installed.
For organizational and historical reasons, you can also deploy your Spring Boot application as a .war file, into an existing servlet container or application server.

Last but not least, you can, of course, also put your .jar file into a Docker image and even deploy those with Kubernetes.

This is a bit of a trick question. Adding the Spring Security Starter to your app, will suddenly prompt you with a login every time you try to access your application. Also, form submissions/REST endpoints will work differently or are outright blocked.

The gist is, that you "do not simply enable" security on a Spring Boot application, you need a solid understanding of what you are doing.

Luckily, I wrote a comprehensive guide on Spring Security, that explains all the gory aspects of security in the easiest way possible.

Spring Boot Actuator can provide that information, through HTTP or JMX endpoints. Alternatively, you can start-up your Spring Boot application with the "--debug" flag.

Do note, that the information on evaluated conditions is a bit "raw" and not easily digested. For that, read this guide to make sure you understand how Spring Boot’s auto-configurations work.

There is obviously no guarantee that you will meet these questions in your own Spring Boot interview, though knowing (and understanding) the answers to them should prove as a solid foundation for any interview.

If you want to get a deeper understanding of the entire Spring ecosystem, you might also want to check out the other Spring articles on my blog and the Confident Spring Developer course.

Do you have any other questions you think might be useful for interviews? Let me know in the comment section.

Enjoy!