Spring Boot Annotations Interview Questions and Answers

Annotations are where a Spring Boot interview stops being vague and gets specific. Naming an annotation is easy; explaining what it instructs the container to do — and what breaks when it is missing — is what earns marks. This set covers the thirteen annotation questions that come up across fresher and experienced rounds, each with a spoken answer, a code line and the follow-up trap.

Why interviewers ask about Spring Boot annotations

Spring Boot is configured almost entirely through annotations, so they are the most direct window into whether you understand the framework or just pattern-matched a tutorial. Every annotation is really an instruction to the IoC container, and interviewers want to hear that translation.

The same annotation names scale across experience levels. A fresher explains that @Autowired injects a dependency; a mid-level developer explains how Spring resolves which bean to inject and what happens when two candidates match. Knowing the resolution rules, not just the vocabulary, is what moves you up the difficulty dial.

How to answer in an interview

For each annotation, state the target (class, method, field), the instruction it gives the container, and one consequence of removing it. "@RestController marks a controller" is weak; "@RestController is @Controller plus @ResponseBody, so every method serialises its return value to the response body instead of resolving a view" is an answer.

Keep a runnable example for each. If a concept feels thin, revisit the Spring Boot annotations tutorial and the Spring beans guide before drilling.

Q1. What does @SpringBootApplication combine?

Three annotations: @Configuration (this class may define @Bean methods), @EnableAutoConfiguration (activate classpath-driven auto-configuration), and @ComponentScan (scan this package and below for components).

@SpringBootApplication  // = @Configuration + @EnableAutoConfiguration + @ComponentScan
public class App {
    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

Being able to split it into the three parts is the whole point of the question. It also explains a common bug: components outside the main class's package are never scanned.

Interview note: Follow-up: "how do you exclude an auto-configuration?" @SpringBootApplication(exclude = DataSourceAutoConfiguration.class) — useful when you have no database but the JPA starter is on the classpath.

Q2. What is @Component and how does component scanning use it?

@Component marks a class as a container-managed bean. During startup @ComponentScan walks the base package, finds every @Component (and its specialisations), and registers one instance in the application context.

The container, not your code, instantiates the class — that is the inversion at work. Without a stereotype annotation or an explicit @Bean method, the class is invisible to Spring and cannot be injected.

Interview note: Trap: "you added @Component but the bean isn't found — why?" The class sits outside the scanned package tree, or you forgot to run through SpringApplication.run on a class whose package is an ancestor.

Q3. What is the difference between @Component and @Bean?

@Component is class-level and auto-detected by scanning — Spring constructs the object. @Bean is method-level inside a @Configuration class where you construct and return the object. Use @Bean for custom construction logic or for third-party types you cannot annotate.

@Configuration
public class AppConfig {
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();   // you build it; library class, can't annotate
    }
}

The decision rule is ownership: your class, annotate it with @Component; someone else's class or conditional construction, define a @Bean.

Interview note: Follow-up: "can a @Bean method call another @Bean method?" Yes, and inside a @Configuration class Spring intercepts that call so you still get the singleton, not a fresh object each time.

Q4. What are the stereotype annotations and how do they differ?

@Controller, @Service and @Repository are all specialisations of @Component. Functionally each registers a bean; they differ in the layer they document. @Repository additionally translates persistence exceptions into Spring's DataAccessException hierarchy.

Using the correct stereotype is about communication and, for @Repository, behaviour. A reviewer reading @Service knows the class holds business logic without opening it.

Interview note: Trap: "if they're all @Component, why not just use @Component everywhere?" You lose the documented intent and the repository exception translation. It works, but it is poorer code.

Q5. How does @Autowired resolve which bean to inject?

@Autowired tells the container to supply a matching bean. Spring resolves first by type; if several beans share that type, it narrows by the field or parameter name, and if that is still ambiguous it throws NoUniqueBeanDefinitionException unless you disambiguate.

@Service
public class NotificationService {
    private final MessageSender sender;
    public NotificationService(MessageSender sender) {  // @Autowired optional here
        this.sender = sender;
    }
}

Since Spring 4.3, a single constructor needs no explicit @Autowired. Stating the by-type-then-by-name resolution order is what separates a rote answer from an understood one. See the @Autowired tutorial for the edge cases.

Interview note: Follow-up: "what if no bean matches at all?" Startup fails with NoSuchBeanDefinitionException unless you set @Autowired(required = false) or make the dependency Optional.

Q6. When two beans match, how do @Qualifier and @Primary resolve it?

@Primary marks one bean as the default winner when multiple candidates match. @Qualifier("name") picks a specific bean by name at the injection point. @Qualifier is targeted and overrides @Primary where both apply.

@Bean @Primary
public PaymentGateway razorpay() { ... }

@Bean
public PaymentGateway stripe() { ... }

public Checkout(@Qualifier("stripe") PaymentGateway gateway) { ... }  // gets stripe

The mental model: @Primary is a global default, @Qualifier is a local override. Both exist because real applications often have two implementations of one interface.

Interview note: Trap: "which wins if a field has @Qualifier and another bean is @Primary?" The @Qualifier — the explicit local choice always beats the global default.

Q7. What does @Configuration do and why is it special?

@Configuration marks a class as a source of bean definitions. Spring proxies it (CGLIB) so that inter-bean method calls return the shared singleton instead of a new object each time — enforcing singleton semantics even when you call one @Bean method from another.

That proxying is the detail interviewers probe. A plain class with @Bean-style methods would create a new instance on every internal call; @Configuration guarantees the container's single instance.

Interview note: Follow-up: "difference between @Configuration and @Component for holding @Bean methods?" @Bean methods work in both, but only @Configuration applies the CGLIB proxy that preserves singletons across internal calls ("full" vs "lite" mode).

Q8. What do @RestController and the mapping annotations do?

@RestController is @Controller plus @ResponseBody, so every handler returns data serialised to the response body (JSON via Jackson) rather than a view name. @GetMapping, @PostMapping and friends map an HTTP method and path to a handler.

@RestController
@RequestMapping("/api/users")
public class UserController {
    @GetMapping("/{id}")
    public User byId(@PathVariable Long id) { ... }
}

@RequestMapping at class level sets a base path; the method-level mappings append to it. This is the backbone of every REST endpoint, covered further in the REST API interview set.

Interview note: Trap: "difference between @Controller and @RestController?" @Controller returns view names for server-side rendering; @RestController returns response bodies. Mix them up and you get the whitelabel error page.

Q9. How do @PathVariable, @RequestParam and @RequestBody differ?

@PathVariable binds a value from the URL path (/users/5). @RequestParam binds a query parameter (/users?active=true). @RequestBody binds and deserialises the request body (JSON) into an object.

@GetMapping("/search")
public List<User> search(@RequestParam String city) { ... }

@PostMapping
public User create(@RequestBody User user) { ... }

Knowing which binds from where is a frequent hands-on check. @RequestBody is the one that involves Jackson deserialisation and validation.

Interview note: Follow-up: "how do you validate the @RequestBody?" Add @Valid before it and bean-validation annotations on the DTO. Explored in request validation.

Q10. What does @Transactional do and where does it apply?

@Transactional wraps a method in a database transaction: it begins on entry, commits on normal return, and rolls back on a runtime exception. Spring implements it with an AOP proxy around the bean.

Because it works through a proxy, two rules matter: it only applies to public methods called from outside the bean, and by default it rolls back on unchecked exceptions, not checked ones. Both are common traps.

Interview note: Trap: "why did my @Transactional method not roll back / not start a transaction when called from another method in the same class?" Self-invocation bypasses the proxy — the call never crosses the proxy boundary, so no transaction is applied.

Q11. What is the difference between @Autowired field injection and constructor injection?

Field injection sets the dependency via reflection directly on the field; constructor injection passes it through the constructor. Constructor injection is preferred because it allows final fields, fails fast at startup if a dependency is missing, and needs no Spring to unit-test.

// preferred
private final Repo repo;
public Service(Repo repo) { this.repo = repo; }

Stating the testability and immutability advantages is what interviewers listen for. Field injection hides dependencies and forces reflection-based tests.

Interview note: Follow-up: "any case where field injection is acceptable?" Rarely — in test classes or where a circular dependency forces it, though a circular dependency is itself a design smell to fix.

Q12. What does @Value do?

@Value injects a value from configuration — a property, an expression, or a default — into a field or parameter. It binds a single value, unlike @ConfigurationProperties, which binds a whole group of related properties into a typed object.

@Value("${server.port:8080}")   // default 8080 if property absent
private int port;

The :default syntax is worth showing unprompted. For anything more than a handful of values, mention that @ConfigurationProperties is the cleaner, type-safe choice.

Interview note: Trap: "@Value vs @ConfigurationProperties?" @Value for one-off values with SpEL support; @ConfigurationProperties for structured, validated, grouped binding.

Q13. What is @Conditional and how does auto-configuration use it?

@Conditional and its Boot variants like @ConditionalOnClass and @ConditionalOnMissingBean register a bean only when a condition holds. Auto-configuration is built on them: a default DataSource is created only if a JDBC driver is on the classpath and you have not defined your own.

This is the mechanism behind "Spring Boot backs off when you configure something yourself." @ConditionalOnMissingBean is why your bean always overrides the auto-configured default.

Interview note: Follow-up: "how would you make your own conditional bean?" Implement Condition or use @ConditionalOnProperty to switch a bean on via a config flag — a clean feature-toggle pattern.

How to prepare

Take one small project and, for each annotation above, remove it and read the failure: delete @Component and watch the injection fail, drop @ResponseBody and get an HTML error, call a @Transactional method from within the same class and see the rollback silently not happen. Watching the mechanism break fixes it in memory far better than the definition.

Rehearse the three-part breakdown of @SpringBootApplication (Q1), the @Component vs @Bean decision (Q3), and the @Transactional self-invocation trap (Q10) — all three are asked constantly. Then move on to the Spring Boot freshers set for the broader fundamentals and the Spring Boot interview questions 2026 roundup. Candidates who can defend every annotation in their own code are exactly what our Java Full Stack with AI program builds.