PART 1 — FOUNDATIONS
Spring Framework vs Spring Boot (WHY Spring Boot EXISTS)
Target after this part
You should not lose even 1 MCQ related to:
• definitions
• differences
• advantages
• false statements
• “best describes” / “correct option” questions
What exactly is the Spring Framework? (MCQ-READY)
Spring Framework is:
• A Java application framework
• Used to build enterprise Java applications
• Based fundamentally on:
o IoC (Inversion of Control)
o Dependency Injection
Characteristics:
• Modular (Core, MVC, Data, Security, AOP, etc.)
• Flexible
• Powerful
What Spring Framework does NOT provide by default:
• Auto-configuration
• Embedded server
• Starter dependencies
• Convention-based setup
Very common MCQ
Spring Framework is primarily used for: Managing application components and
dependencies
Running a server
Auto-configuring applications
[SpringBoot…9390500490 | PowerPoint]
Problems with Traditional Spring (WHY Spring Boot was created)
Spring Boot exists only because Spring was powerful but painful.
Problem 1: Configuration Overhead
• Excessive:
o XML configuration
o Manual bean wiring
Problem 2: Boilerplate Code
• Same setup repeated in every project
Problem 3: External Server Required
• You must:
o Install Tomcat / JBoss / WebLogic
o Deploy WAR files
Problem 4: Dependency Management
• Manually manage:
o Dependency versions
o Compatibility
MCQ TRAP:
Which is NOT a drawback of Spring Framework? Correct answers must not include IoC
or DI (those are strengths)
[SpringBoot…9390500490 | PowerPoint]
What is Spring Boot? (LOCK THIS DEFINITION)
Spring Boot is:
A framework built on top of the Spring Framework that simplifies Spring application
development by reducing configuration and enabling rapid development.
How it does this:
• Convention over Configuration
• Auto-Configuration
• Starter Dependencies
• Embedded Server
• Production-ready features
Spring Boot is NOT:
• A replacement for Spring
• A web server
• A programming language
Very common MCQ:
Spring Boot is best described as: An extension of Spring Framework
A replacement of Spring Framework
[SpringBoot…9390500490 | PowerPoint]
Spring vs Spring Boot (EXAM TABLE)
Spring Framework Spring Boot
Manual configuration Auto-configuration
XML-heavy Minimal configuration
External server Embedded server
No starters Starter dependencies
Slower setup Rapid development
MCQ wording tricks:
• “Traditional Spring” = without Boot
• “Ease of configuration” → Boot
• “Enterprise framework” → Spring
Convention over Configuration (VERY HIGH MCQ WEIGHT)
Meaning:
Spring Boot:
• Assumes sensible default configuration
• Requires configuration only when deviating
Result:
• Less boilerplate
• Faster development
• Cleaner projects
Wrong MCQ option:
Convention over configuration removes flexibility (FALSE)
MCQ classic:
Convention over Configuration helps in: Reducing configuration effort
Limiting developer control
[SpringBoot…9390500490 | PowerPoint]
Embedded Server (KEY CONCEPT)
Spring Boot provides:
• Embedded web servers
• Application runs as a standalone JAR
Default embedded server:
• Apache Tomcat
Other supported:
• Jetty
• Undertow
MCQ signals:
• “Self-contained application”
• “Standalone execution”
• “No WAR deployment”
Correct → Embedded server
[SpringBoot…9390500490 | PowerPoint]
Starter Dependencies (DO NOT MISS THIS)
A starter dependency is:
• A predefined group of compatible dependencies
• Simplifies dependency management
Examples:
• spring-boot-starter-web
• spring-boot-starter-data-jpa
Solves:
• Version conflicts
• Manual dependency selection
Wrong MCQ assumption:
Starters increase application complexity
[SpringBoot…9390500490 | PowerPoint]
Advantages of Spring Boot (MCQs LOVE THESE)
Advantages:
• Rapid application development
• Reduced configuration
• Embedded server
• Production-ready features
• Microservices friendly
NOT an advantage:
• Removing Spring concepts
• Eliminating Dependency Injection
HIGH-RISK MCQ FALSE STATEMENTS (MEMORIZE)
“Spring Boot does not use Spring Framework”
“Spring Boot removes IoC”
“Spring Boot applications cannot be customized”
“Spring Boot simplifies Spring application development”
PART 1 — FINAL CHECK
You are now fully covered for MCQs on:
• Why Spring Boot exists
• Differences between Spring & Spring Boot
• Embedded servers
• Starter dependencies
• Convention over configuration
• False-statement traps
Perfect. We now lock into PART 2 and go deep enough that no MCQ from this area
can surprise you.
Everything below is grounded in internal Spring Boot training material and official
Spring Boot behavior explicitly referenced in enterprise documents such as\
SpringBoot_Overview_1719390500490.pptx and code examples from\ Spring-Batch-
Creation-Steps-With-Code_1719473865825.pdf [SpringBoot…9390500490 |
PowerPoint], [Spring-Bat…9473865825 | PDF]
PART 2 — SPRING BOOT APPLICATION STRUCTURE & BOOTSTRAPPING
(Very high MCQ probability + “which is correct / incorrect” traps)
After this part, you should answer 100% of MCQs about:
• Project structure
• Main class
• @SpringBootApplication
• Application startup flow
• Standalone nature of Spring Boot apps
What is a Spring Boot Application (MCQ definition)
A Spring Boot application is:
• A standalone Java application
• Bootstrapped using a main method
• Started via [Link](...)
Key idea:
Spring Boot apps do NOT require an external container to run
MCQ trap: “Spring Boot applications must be deployed as WAR files”
[Spring-Bat…9473865825 | PDF]
Entry Point of a Spring Boot Application (VERY COMMON MCQ)
Entry point = main() method
public static void main(String[] args) {
[Link]([Link], args);
Purpose of [Link]():
• Bootstraps Spring context
• Starts embedded server (if web app)
• Performs auto-configuration
MCQ pattern:
What method is responsible for launching a Spring Boot application?
[Link]()
[Spring-Bat…9473865825 | PDF]
The Main Application Class (STRUCTURAL MCQs)
Every Spring Boot app has ONE primary class:
• Annotated with @SpringBootApplication
• Contains main() method
Example from internal training docs:
@SpringBootApplication
public class BatchProcessingApplication {
public static void main(String[] args) {
[Link]([Link], args);
MCQ trap: Multiple main Spring Boot application classes (FALSE)
[Spring-Bat…9473865825 | PDF]
@SpringBootApplication (CRITICAL – many MCQs)
@SpringBootApplication is a convenience annotation.
It COMBINES three annotations:
1. @Configuration
2. @EnableAutoConfiguration
3. @ComponentScan
Meaning:
One annotation = complete bootstrapping
MCQ classic:
Which annotation enables auto-configuration indirectly?
@SpringBootApplication
[Spring-Bat…9473865825 | PDF]
Role of Each Meta-Annotation (EXAM READY)
@Configuration
• Marks class as bean definition source
@EnableAutoConfiguration
• Enables Spring Boot’s auto-configuration mechanism
• Based on:
o Classpath
o Existing beans
o Property settings
@ComponentScan
• Scans current package and sub-packages
• Detects:
o @Component
o @Service
o @Repository
o @Controller
MCQ TRAP:
Component scanning happens: From package of main class downward\ From
root of project (FALSE)
[Spring-Bat…9473865825 | PDF]
Application Startup Flow (Conceptual MCQs)
When you run a Spring Boot app:
1. JVM starts
2. main() executes
3. [Link]() is called
4. ApplicationContext is created
5. Auto-configuration happens
6. Embedded server starts (if applicable)
MCQ wording:
When does embedded Tomcat start? During application startup via
SpringApplication
[Spring-Bat…9473865825 | PDF]
Standalone Nature of Spring Boot Apps
Spring Boot applications:
• Run as JAR files
• Can run using: java -jar [Link]
WAR deployment:
• Optional
• Not mandatory
MCQ trap: “Spring Boot only supports WAR deployment”
[Spring Fra…pplication | Viva Learning]
Important MCQ FALSE STATEMENTS (MEMORIZE)
@SpringBootApplication replaces Spring Framework\ [Link]()
only loads beans\ Spring Boot apps cannot run without a web server
Spring Boot apps can run with or without web layer
PART 2 — FINAL CHECKPOINT
You are now covered for all MCQs related to:
• Entry point of Spring Boot app
• Role of main() method
• @SpringBootApplication and its internals
• Startup lifecycle
• Standalone nature of apps
Excellent. We now lock into PART 3 — this is one of the highest-yield MCQ sections in
Spring Boot.
I’ll make this annotation-complete, trap-proof, and exam-ready so you won’t miss a
single question from this area.
All facts below are grounded in internal Spring Boot training material and official
code examples used in your program, especially:
• [SpringBoot_Overview_1719390500490.pptx]([Link]
m/sites/KnowledgeHub/_layouts/15/[Link]?sourcedoc=%7B3CA87A19-
B35C-43B4-ADC4-
BDEE74DC27D0%7D&file=SpringBoot_Overview_1719390500490.pptx&action=
edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=5cc7dd
1a-f653-4dcd-8c3f-4c5d2bc8936e)
• [Spring-Batch-Creation-Steps-With-
Code_1719473865825.pdf]([Link]
Hub/BankingAndFinancialServices/Public/Spring-Batch-Creation-Steps-With-
Code_1719473865825.pdf?web=1&EntityRepresentationId=ae230953-3a04-
46b7-9250-6310a28cf795) [CREW LFO -…4074264603 | PDF],
[Kundan_Ith…SpringBoot | Word]
PART 3 — CORE SPRING BOOT & SPRING ANNOTATIONS
(MCQ HEAVY • TRUE/FALSE • “Which annotation…” • TRAPS)
After this part, you should answer 100% of MCQs related to:
• Purpose of annotations
• Differences between similar annotations
• Where annotations are used
• False / misleading annotation statements
Why Annotations exist in Spring Boot (FOUNDATION MCQ)
Annotations in Spring Boot are used to:
• Replace XML configuration
• Enable declarative programming
• Reduce boilerplate code
Key idea:
Spring Boot is annotation-driven, not XML-driven
MCQ trap: “Spring Boot primarily uses XML configuration” → FALSE
[CREW LFO -…4074264603 | PDF]
@SpringBootApplication (RECAP + TRAPS)
You already saw this, but MCQs repeat it with twists.
@SpringBootApplication:
• Marks the main class
• Combines:
o @Configuration
o @EnableAutoConfiguration
o @ComponentScan
Purpose:
Complete bootstrapping of the application
MCQ classic:
Which annotation enables component scanning implicitly?
@SpringBootApplication
[Kundan_Ith…SpringBoot | Word]
@Configuration
Meaning:
• Marks a class as a source of bean definitions
Used for:
• Java-based configuration
• Replacing XML config
MCQ TRAP: @Configuration is used only in XML-based apps → FALSE
@EnableAutoConfiguration (VERY TRICKY MCQs)
Purpose:
• Enables Spring Boot’s auto-configuration
• Automatically configures beans based on:
o Classpath
o Existing beans
o Property values
Example logic:
• If spring-webmvc is present → configure DispatcherServlet automatically
MCQ trap:
Auto-configuration happens: At application startup
At compile time
[Kundan_Ith…SpringBoot | Word]
@ComponentScan (COMMON CONFUSION AREA)
Purpose:
• Scans packages to detect Spring components
Detects:
• @Component
• @Service
• @Repository
• @Controller
• @RestController
Default scan scope:
• Package of main class
• All sub-packages
VERY COMMON MCQ:
Where does component scanning start by default? From the package of the main
application class
[Kundan_Ith…SpringBoot | Word]
@Component (BASE STEREOTYPE)
Meaning:
• Marks a class as a Spring-managed bean
Generic annotation
Parent of other stereotype annotations
MCQ TRAP:
@Component is mandatory for every Spring class FALSE
@Service
Meaning:
• Specialization of @Component
• Used for business logic layer
Functionally same as @Component Semantically different (for readability &
design)
MCQ classic:
Which annotation is best suited for business logic? @Service
@Repository (EXAM FAVORITE)
Meaning:
• Used for data access layer
Extra benefit:
• Enables exception translation (unchecked exceptions)
TRICK MCQ:
Which annotation enables persistence exception translation? @Repository
@Controller vs @RestController (VERY HIGH MCQ WEIGHT)
@Controller
• Used in MVC
• Returns view names
@RestController
• Combination of:
o @Controller
o @ResponseBody
• Returns data (JSON/XML)
MCQ trap:
@RestController returns views FALSE
@ResponseBody
Meaning:
• Converts return value directly to HTTP response body
Automatically applied in:
• @RestController
MCQ:
Which annotation converts Java objects to JSON? @ResponseBody (via message
converters)
@Autowired (Dependency Injection MCQs)
Purpose:
• Injects dependencies automatically
Can be used on:
• Constructor
• Field
• Setter
MCQ trap: @Autowired works only on fields → FALSE
HIGH-RISK FALSE STATEMENTS (MEMORIZE)
@Service and @Component behave differently at runtime
@ComponentScan scans entire classpath
@EnableAutoConfiguration replaces @Configuration
All stereotype annotations are detected via component scanning
Excellent. We now lock into PART 4, which is the trickiest conceptual area in Spring /
Spring Boot MCQs.\ If people lose marks here, it’s usually because of wording traps,
not lack of knowledge.
Everything below is strictly aligned with internal Spring Boot training content,
especially:
• [SpringBoot_Overview_1719390500490.pptx]([Link]
m/sites/KnowledgeHub/_layouts/15/[Link]?sourcedoc=%7B3CA87A19-
B35C-43B4-ADC4-
BDEE74DC27D0%7D&file=SpringBoot_Overview_1719390500490.pptx&action=
edit&mobileredirect=true&DefaultItemOpen=1&EntityRepresentationId=5cc7dd
1a-f653-4dcd-8c3f-4c5d2bc8936e) [SpringBoot…9390500490 | PowerPoint]
PART 4 — INVERSION OF CONTROL (IoC) & DEPENDENCY INJECTION (DI)
(CONCEPTUAL • TRICKY • VERY HIGH MCQ WEIGHT)
After this part, you should be able to answer ANY MCQ on:
• What IoC really means
• What DI really means
• Difference between IoC and DI
• How Spring Boot implements DI
• All common false statements & traps
What is Inversion of Control (IoC)? (DEFINE IT PERFECTLY)
Definition (MCQ-safe):
Inversion of Control is a principle where the control of object creation and lifecycle
is transferred from the programmer to the Spring container.
Key idea:
You do not create objects manually → Spring does
MCQ TRAP: “IoC means automatic dependency injection”\ → FALSE (DI is a way
to achieve IoC)
[SpringBoot…9390500490 | PowerPoint]
What problem does IoC solve?
Without IoC:
• Classes create their own dependencies
• Tight coupling
• Hard to test & maintain
With IoC:
• Loose coupling
• Cleaner design
• Centralized object management
MCQ:
IoC improves: Loose coupling\ Testability\ Performance (generally not the
goal)
What is Dependency Injection (DI)? (EXAM-READY)
Definition:
Dependency Injection is a design pattern where dependencies are provided to a
class instead of the class creating them itself.
In Spring:
• Dependencies are injected by the Spring container
MCQ TRAP: “DI means one class depends on another”\ → FALSE (dependency
already exists; injection is about how it is given)
[SpringBoot…9390500490 | PowerPoint]
Relationship Between IoC and DI (VERY COMMON MCQ)
IoC is the principle\ DI is the technique
Correct understanding:
• Spring achieves IoC using DI
MCQ classic:
Which is true? Dependency Injection is a way to implement IoC\ IoC is a type of
DI
How Spring Boot Supports Dependency Injection
Spring Boot uses Spring Core DI mechanism:
• Beans are created by Spring container
• Dependencies injected automatically
Common DI Annotations:
• @Autowired
• @Component
• @Service
• @Repository
MCQ trap: DI is new in Spring Boot\ → FALSE (exists since Spring Core)
[SpringBoot…9390500490 | PowerPoint]
Types of Dependency Injection in Spring (VERY IMPORTANT)
1. Constructor Injection (BEST PRACTICE)
public class Service {
private Repo repo;
public Service(Repo repo) {
[Link] = repo;
Advantages:
• Mandatory dependencies
• Immutable
• Easier testing
MCQ:
Recommended type of DI in Spring Boot? Constructor Injection
2. Setter Injection
public void setRepo(Repo repo) {
[Link] = repo;
Used when:
• Dependency is optional
MCQ trap: Setter injection ensures immutability → FALSE
3. Field Injection (NOT recommended, but asked)
@Autowired
private Repo repo;
Works\ Not recommended (hard to test)
MCQ classic:
Which DI type is NOT recommended? Field injection
@Autowired (TRAP-HEAVY)
What it does:
• Tells Spring to inject a matching bean
Resolution:
• By type (default)
• By name (if required)
MCQ traps: @Autowired creates objects\ Spring Container creates objects
IoC Container (TERMINOLOGY MCQs)
IoC Container in Spring:
• ApplicationContext
• (older: BeanFactory)
Responsible for:
• Creating beans
• Injecting dependencies
• Managing lifecycle
MCQ:
Which is the IoC container? ApplicationContext
VERY HIGH-RISK FALSE STATEMENTS (MEMORIZE)
DI and IoC mean the same\ Developer controls object lifecycle in IoC\
@Autowired creates beans\ Field injection is recommended
Spring container manages object creation\ DI promotes loose coupling
Continuing exactly as planned — PART 5 starts now.
This part is one of the HIGHEST SCORING areas in Spring Boot MCQs. Many
questions look simple but are designed to trap you on how / when / why things happen.
Everything below is strictly aligned with the Spring Boot syllabus topics mentioned
in your training, especially the internal Spring Boot overview material that explicitly lists
Auto-Configuration and Starter Dependencies as core Spring Boot features. [Copilot
CoE | Teams]
PART 5 — AUTO-CONFIGURATION & STARTER DEPENDENCIES
(VERY HIGH MCQ YIELD • LOGIC-BASED • TRAP-PRONE)
After this part, you should be able to answer ANY MCQ on:
• What auto-configuration really is
• When it happens
• What it depends on
• What starters do / do not do
• All common false statements and trick options
What is Auto-Configuration? (LOCK THIS DEFINITION)
MCQ-SAFE definition:
Auto-configuration is a Spring Boot feature that automatically configures application
components based on the classpath, existing beans, and configuration properties.
Core idea:
You do NOT explicitly configure most things — Spring Boot does it for you
MCQ trap: “Auto-configuration means no configuration at all” → FALSE
[Copilot CoE | Teams]
When Does Auto-Configuration Happen?
Auto-configuration happens:
• At application startup
• When [Link]() is executed
It does NOT happen:
• At compile time
• At build time
MCQ classic:
Auto-configuration occurs during: Application startup
Compilation
[Copilot CoE | Teams]
What Controls Auto-Configuration? (VERY IMPORTANT)
Spring Boot auto-configuration is based on THREE things:
1. Classpath
• Presence of certain libraries triggers configuration
Example:
• spring-webmvc present → MVC auto-configuration enabled
2. Existing Beans
• If you define a bean manually, Spring Boot backs off
3. Properties
• Values in [Link] / [Link]
MCQ trap: Auto-configuration ignores user-defined beans → FALSE
[Copilot CoE | Teams]
@EnableAutoConfiguration (UNMISSABLE MCQs)
Purpose:
• Enables auto-configuration mechanism in Spring Boot
Usually NOT used directly because:
• Included inside @SpringBootApplication
MCQ:
Which annotation activates auto-configuration? @EnableAutoConfiguration
(Indirectly) @SpringBootApplication
[Copilot CoE | Teams]
Auto-Configuration “Backing Off” Rule (TRICKY MCQs)
Rule:
Spring Boot auto-configures only if you have NOT configured it yourself
Example:
• You define your own DataSource → Boot does NOT create another one
MCQ trap: Spring Boot always overrides user configuration → FALSE
What Are Starter Dependencies? (DEFINITION MCQs)
Definition:
A starter dependency is a predefined collection of compatible dependencies that
simplifies dependency management.
Purpose:
• Avoid version conflicts
• Avoid manual dependency selection
• Speed up development
MCQ trap: Starters are required for every Spring Boot app → FALSE
[Copilot CoE | Teams]
Common Spring Boot Starters (MUST RECOGNIZE)
You don’t need internals, but you must recognize names.
Examples:
• spring-boot-starter-web
• spring-boot-starter-data-jpa
• spring-boot-starter-security
• spring-boot-starter-test
MCQ pattern:
Which of the following is a Spring Boot starter? spring-boot-starter-web
spring-web (not a starter)
Relation Between Starters & Auto-Configuration (VERY TRICKY)
Key relationship:
• Starters bring dependencies
• Auto-configuration configures them
MCQ classic:
Starter dependencies: Enable auto-configuration by adding libraries
Perform auto-configuration themselves
What Starter Dependencies DO NOT Do
Starters do NOT: Start the server
Configure beans at runtime
Replace Spring Framework
Write application code
They only:
Add correct dependencies to the classpath
HIGH-RISK FALSE STATEMENTS (MEMORIZE)
Auto-configuration happens before application starts
Starters automatically create business logic
Auto-configuration ignores classpath
@EnableAutoConfiguration replaces @ComponentScan
Auto-configuration depends on classpath
Starters + auto-config work together
PART 5 — FINAL CHECKPOINT
You are now fully safe for MCQs on:
• Meaning and timing of auto-configuration
• What controls auto-configuration
• Role of @EnableAutoConfiguration
• Starter dependency purpose
• Starter vs auto-configuration relationship
• All common false traps
Excellent — PART 6 starts now.
This section is guaranteed MCQ territory because Embedded Server is literally one of
the headline Spring Boot features listed in your internal training deck
SpringBoot_Overview_1719390500490.pptx. Any milestone exam will test this.
[SpringBoot…9390500490 | PowerPoint]
PART 6 — EMBEDDED SERVER & APPLICATION LIFECYCLE
(VERY HIGH MCQ WEIGHT • DIRECT + TRICK QUESTIONS)
After this part, you should be able to answer 100% MCQs on:
• What an embedded server is
• Why Spring Boot uses it
• Default server behavior
• When the server starts/stops
• Application lifecycle traps
What is an Embedded Server? (LOCK THIS)
MCQ-SAFE Definition:
An embedded server is a web server packaged inside the Spring Boot application,
allowing it to run as a standalone application without external deployment.
Key implication:
Spring Boot applications do not require external application servers.
MCQ trap: “Embedded server is optional in Spring Boot web apps” → FALSE
[SpringBoot…9390500490 | PowerPoint]
Default Embedded Server in Spring Boot
Default embedded server:
• Apache Tomcat
Alternatives supported:
• Jetty
• Undertow
MCQ:
Which server is used by default in Spring Boot? Apache Tomcat
[SpringBoot…9390500490 | PowerPoint]
Why Embedded Server Was Introduced (VERY IMPORTANT)
Embedded servers solve these problems:
No need to:
• Install Tomcat separately
• Configure server manually
• Deploy WAR files
Enables:
• java -jar [Link]
• Microservices-friendly deployment
• Easier CI/CD
MCQ trap: Embedded server improves JVM performance → FALSE
[SpringBoot…9390500490 | PowerPoint]
Web vs Non-Web Spring Boot Applications
If your app has:
• spring-boot-starter-web
➡ Embedded server STARTS automatically
If your app has:
• No web starter
➡ Embedded server DOES NOT START
MCQ classic:
When does embedded Tomcat start? Only when web dependencies are present
[SpringBoot…9390500490 | PowerPoint]
Application Startup Lifecycle (EXAM FAVORITE)
Correct startup sequence:
1. JVM starts
2. main() executes
3. [Link]() executes
4. ApplicationContext created
5. Auto-configuration happens
6. Embedded server starts
7. Application listens for requests
MCQ TRAP: Embedded server starts before ApplicationContext → FALSE
How Application Stops
Application stops when:
• JVM exits
• Application context closes
MCQ:
What stops the embedded server? Application shutdown / JVM exit
Standalone JAR vs WAR (VERY COMMON MCQs)
Default Spring Boot packaging:
• Executable JAR
WAR packaging:
• Optional
• Used only if deploying to external server
MCQ trap: Spring Boot must be packaged as WAR → FALSE
[SpringBoot…9390500490 | PowerPoint]
Embedded Server ≠ Servlet Container Confusion
Apache Tomcat in Spring Boot:
• Works as embedded servlet container
• Managed internally by Spring Boot
MCQ trap:
Embedded server and Spring Boot container are the same
Embedded server runs inside the Spring Boot app
VERY HIGH-RISK FALSE STATEMENTS (MEMORIZE)
Embedded server is started manually
Embedded server replaces Spring Core
Embedded server always runs, even without web starter
Spring Boot uses multiple embedded servers simultaneously
Embedded server starts automatically for web apps
Default is Tomcat
Spring Boot apps are standalone
PART 6 — FINAL CHECKPOINT
You are now fully protected against MCQs on:
• Embedded server definition
• Default server behavior
• Startup lifecycle sequence
• JAR vs WAR packaging
• Web vs non-web behavior
• All common trap statements
Perfect — PART 7 starts now.\ This part looks simple, but it’s where MCQs quietly test
priority rules, defaults, and false assumptions. If someone hasn’t revised this cleanly,
they lose easy marks.
Everything below is explicitly aligned with Spring Boot training topics and the internal
overview deck that highlights configuration and profiles as core Spring Boot features.
[LTIM-GeethikaResume | Word]
PART 7 — CONFIGURATION: [Link], YAML & PROFILES
(DIRECT MCQs • TRICKY PRIORITY QUESTIONS • TRUE/FALSE TRAPS)
After this part, you should confidently answer ANY MCQ on:
• Configuration files
• File naming & formats
• Property loading rules
• Profiles & their purpose
• Common incorrect assumptions
Why Configuration Exists in Spring Boot
Spring Boot applications require configuration to define:
• Application behavior
• Environment-specific values
• Infrastructure settings (ports, DB URLs, etc.)
Spring Boot supports externalized configuration, meaning:
Configuration is separated from code
MCQ trap: Configuration must be hardcoded → FALSE
[LTIM-GeethikaResume | Word]
[Link] (CORE MCQ TOPIC)
What it is:
• Default configuration file in Spring Boot
Location:
• src/main/resources
Format:
[Link]=8080
[Link]=myapp
MCQ classic:
What is the default configuration file name? [Link]
[Link] / [Link] (EQUAL IMPORTANCE)
YAML is an alternative to properties\ Used for hierarchical configuration
Example:
server:
port: 8080
spring:
application:
name: myapp
MCQ trap: YAML files are mandatory → FALSE\ YAML has higher priority by
default → FALSE
Both formats are functionally equivalent
Properties vs YAML — What MCQs Expect
Aspect .properties .yml
Syntax key=value hierarchical
Supported Yes Yes
Priority Same Same
MCQ:
Which statement is true? YAML and properties provide same functionality\ YAML
replaces properties
Externalized Configuration (VERY COMMON)
Spring Boot allows configuration from:
• Files
• Environment variables
• Command-line arguments
Purpose:
• Change behavior without recompiling
MCQ trap: Application must be rebuilt to change config → FALSE
Spring Profiles (VERY HIGH MCQ WEIGHT)
Definition:
Profiles allow you to group configuration for specific environments (dev, test, prod).
Common profiles:
• dev
• test
• prod
MCQ:
Why profiles are used? Environment-specific configuration
Profile-Specific Configuration Files (EXAM FAVORITE)
Naming convention:
• [Link]
• [Link]
• [Link]
MCQ trap: Profile file replaces main file → FALSE
Main + profile file both load
Activating a Profile
Profiles can be activated using:
• [Link]=dev
MCQ:
How does Spring Boot know which profile to use? [Link]
Configuration Loading Behavior (IMPORTANT)
Spring Boot:
• Loads [Link] first
• Loads active profile configuration afterward
• Profile-specific values override defaults
MCQ trap: Default config overrides profile config → FALSE
HIGH-RISK FALSE STATEMENTS (MEMORIZE)
YAML has higher priority than properties\ Only one configuration file can exist\
Profiles are mandatory\ Config values must be defined only in code
Spring Boot supports multiple config sources\ Profile-specific config overrides
default config
PART 7 — FINAL CHECKPOINT
You are now fully prepared to answer MCQs on:
• Configuration files & formats
• [Link] vs YAML
• Externalized configuration
• Profiles & activation
• Override rules & traps
Perfect — PART 8 begins now.
This is the last content-heavy section before we move to the MCQ kill-zone (Part 9).
Actuator questions are usually easy marks if you know exactly what it is, what it
exposes, and what it does NOT do.
Everything below is grounded in Spring Boot training scope and the internal overview
that explicitly mentions “Built-in Metrics and Monitoring” as a core Spring Boot
feature. [LTIM-GeethikaResume | Word]
PART 8 — ACTUATOR & PRODUCTION-READY FEATURES
(LOW EFFORT • HIGH ACCURACY • DIRECT MCQs + FALSE STATEMENT TRAPS)
After this part, you should be able to answer ANY MCQ on:
• What Spring Boot Actuator is
• Why it exists
• What it provides
• Whether it affects business logic
• Common misconceptions
What is Spring Boot Actuator? (LOCK THIS)
MCQ-SAFE definition:
Spring Boot Actuator is a feature that provides production-ready endpoints to help
monitor and manage Spring Boot applications.
Key purpose:
Monitoring, health checks, and metrics
MCQ trap: Actuator is used to develop business logic → FALSE
[LTIM-GeethikaResume | Word]
Why Actuator Exists (VERY COMMON)
Actuator helps:
• Monitor application health
• Expose application metrics
• Manage applications in production
Especially useful for:
• Microservices
• Cloud-native applications
MCQ:
Actuator is mainly used in: Production environments
Application development logic
What Actuator Provides (MCQ-TARGETED)
Actuator provides:
• Health information
• Metrics
• Application info
• Runtime insights
It does NOT:
• Create REST APIs for business logic
• Replace logging frameworks
• Handle security automatically
Actuator Endpoints (RECOGNITION MCQs)
Actuator exposes management endpoints such as:
• /actuator/health
• /actuator/info
• /actuator/metrics
MCQ trap: Actuator endpoints handle user requests → FALSE
Actuator & Starter Dependency
Actuator is enabled using:
• spring-boot-starter-actuator
MCQ:
How is Actuator added to a Spring Boot project? Via starter dependency
Health Endpoint (VERY COMMON MCQ)
/actuator/health:
• Shows application health status
• Example statuses:
o UP
o DOWN
MCQ trap: Health endpoint modifies application state → FALSE
Actuator vs Logging (CONFUSION TRAPS)
Actuator:
• Provides monitoring endpoints
Logging:
• Records application events
MCQ:
Actuator replaces logging frameworks FALSE
Performance Impact (MCQ WARNING)
Actuator is:
• Lightweight
• Safe for production when properly configured
MCQ trap:
Actuator significantly degrades performance → FALSE
HIGH-RISK FALSE STATEMENTS (MEMORIZE)
Actuator is mandatory for all Spring Boot apps
Actuator adds business endpoints
Actuator replaces monitoring tools
Actuator works without Spring Boot
Actuator is optional
Actuator is for monitoring
Actuator exposes management endpoints
PART 8 — FINAL CHECKPOINT
You are now fully covered for MCQs on:
• Purpose of Actuator
• What it exposes
• What it does NOT do
• Actuator vs business logic
• Actuator vs logging
• Starter dependency usage
Perfect. This is the final and most important part.
What follows is PART 9 — the MCQ KILL-ZONE.
This is not new syllabus. This is where we convert your knowledge from Parts 1–8 into
guaranteed marks by eliminating traps, spotting patterns, and answering confidently.
If you internalize this part, 40/40 is realistic, not aspirational.
PART 9 — FINAL MCQ KILL-ZONE
(ELIMINATION RULES • TRICK PATTERNS • MUST-MEMORIZE STATEMENTS)
Objective of Part 9
Make you immune to:
• Confusing wording
• “Looks correct but isn’t” options
• Time pressure
• Overthinking
FIRST PRINCIPLE: HOW THESE MCQs ARE DESIGNED
Spring Boot milestone MCQs are NOT testing: Deep internals
Framework source code
Production edge cases
They ARE testing: Conceptual clarity
Correct terminology
Understanding of “why”
Ability to reject almost-true statements
Golden rule:
If an option sounds too absolute, it’s usually wrong.
ABSOLUTE WORDS = DANGER
Immediately be suspicious if an option contains:
• always
• never
• only
• must
• cannot
• completely
Example traps:
“Spring Boot always starts an embedded server”
“Auto-configuration never allows customization”
“Profiles must be used in all applications”
Spring Boot prefers flexibility, not absolutes.
THE “FALSE STATEMENT” PATTERN (VERY COMMON)
If the question asks:
Which of the following is FALSE?
3 options will be generally correct
1 option will:
• Over-generalize
• Mix two correct ideas incorrectly
• Use wrong timing (startup vs compile)
Strategy:
• Don’t hunt for the “most wrong”
• Hunt for the least defensible
TIMING TRAPS (EXTREMELY COMMON)
These come up repeatedly:
Concept Correct Timing
Auto-configuration Application startup
Embedded server start After context creation
Component scanning Startup
DI injection Context initialization
Trap examples:
“Auto-configuration happens at compile time”
“Embedded server starts before ApplicationContext”
SCOPE CONFUSION TRAPS
MCQs love to confuse what does what.
Remember these boundaries:
• Spring Framework
o IoC, DI, core container
• Spring Boot
o Auto-configuration
o Embedded server
o Starters
o Actuator
If an option credits Spring Boot with core Spring features, it’s wrong.
“WORKS VS RECOMMENDED” TRAP
Spring Boot MCQs often mix:
• What works
• What is recommended
Example:
• Field injection works
• Field injection recommended
If the question says:
Best practice / recommended / preferred
Always choose:
• Constructor injection
STARERS & AUTO-CONFIG — FINAL CONFUSION CLARITY
Lock this mentally:
• Starters
o Add dependencies ONLY
• Auto-configuration
o Configures based on classpath
Therefore:
Starters do NOT configure beans
Auto-configuration does NOT add dependencies
This single confusion causes many wrong answers.
EMBEDDED SERVER — QUICK DECISION RULE
If the option says:
• “Standalone”
• “No external server”
• “Executable JAR”
• “java -jar”
Embedded server
If it says:
• “WAR required”
• “Manual deployment”
• “External Tomcat mandatory”
Wrong for Spring Boot
PROFILES — THE OVERRIDE RULE (MUST REMEMBER)
Default config loads
Profile config loads AFTER
Profile config overrides default
Therefore: Default never overrides profile
Profile does not replace default
ACTUATOR — ONE-LINE FILTER
Ask yourself:
“Is this about monitoring, or business logic?”
• Monitoring → Actuator
• Business logic → Not Actuator
This instantly kills most Actuator traps.
15 MUST-MEMORIZE TRUE STATEMENTS
These will save you under pressure:
1. Spring Boot is built on top of Spring Framework
2. Auto-configuration happens at startup
3. @SpringBootApplication combines 3 annotations
4. Embedded Tomcat is default
5. Spring Boot apps are standalone
6. DI implements IoC
7. Constructor injection is recommended
8. Starters manage dependencies
9. Auto-config backs off if user config exists
10. Profiles support environment-specific config
11. Profile config overrides default config
12. YAML and properties are equivalent
13. Actuator is for monitoring
14. Actuator is optional
15. Spring Boot does not replace Spring
Excellent request — this is exactly what separates 38/40 from 40/40.
Below is a “What You Might Miss” IMPORTANT POINTS SHEET.
These are not repetitions of what we already covered in detail — these are the edge
points, subtle clarifications, and high-probability MCQ nuggets that usually escape
attention even after good preparation.
Think of this as your final polish layer
SPRING BOOT – IMPORTANT POINTS YOU MIGHT HAVE MISSED
(READ BEFORE EXAM — HIGH RETURN)
@SpringBootApplication — Placement Matters
The package where your main class exists determines:
• The component scanning root
MCQ trap: Spring scans entire project automatically
Truth:
Spring scans only the main class package and sub-packages
You Can Disable Auto-Configuration (They love this)
Auto-configuration is not forced
It can be:
• Disabled entirely
• Excluded for specific classes
MCQ angle:
Auto-configuration is flexible, not mandatory
Auto-Configuration is Conditional (Very subtle)
Spring Boot auto-configures using conditions, such as:
• Class present
• Bean missing
• Property set
MCQ trick: Auto-configuration blindly configures everything
Truth:
Auto-configuration is conditional, not blind
@ComponentScan Does NOT Scan JAR Dependencies
Component scanning:
• Finds Spring beans in project packages
It does NOT:
• Scan third-party JAR code automatically
MCQ trap:
Component scanning scans entire classpath
Beans vs Components (Subtle wording trap)
A component:
• Is a bean detected by scanning
A bean:
• Is any object managed by Spring
MCQ direction:
All components are beans
All beans are not necessarily scanned components
@RestController ≠ REST Only Application
@RestController:
• Indicates response body behavior
It does NOT mandate:
• Microservices
• REST-only architecture
MCQ trap:
RestController means microservice
Dependency Injection ≠ Loose Coupling Automatically
DI supports loose coupling
DI does NOT guarantee loose coupling
MCQ nuance:
Loose coupling depends on design, not annotation alone
Constructor Injection Works Without @Autowired (Very common trick)
If only one constructor exists:
• @Autowired is optional
MCQ:
Constructor injection always requires @Autowired
IoC Container Lifetime = Application Lifetime
Spring IoC container:
• Lives as long as the application runs
MCQ trap: Container is destroyed after injection
Embedded Server Starts ONLY for Web Applications
Not because of:
• Spring Boot itself
But because of:
• spring-boot-starter-web
MCQ wording:
Embedded server starts when web dependency exists
Spring Boot Can Run WITHOUT Web Layer
Valid Spring Boot applications:
• CLI apps
• Batch apps
• Background jobs
MCQ trap:
Spring Boot always creates web endpoints
[Link] is NOT Mandatory
Spring Boot runs even if:
• No config file exists
MCQ:
[Link] is compulsory
Multiple Configuration Files Can Exist
Valid:
• properties + YAML together
• default + profile configs
MCQ trap:
Only one config file allowed
Profiles Affect Only What Matches
Profile config:
• Overrides only defined properties
MCQ nuance:
Profile config does NOT wipe entire default file
Actuator is NOT Enabled by Default
Actuator endpoints are available:
• Only if starter is added
MCQ trap:
Actuator always active in Spring Boot
Actuator Does NOT Auto-Expose Everything
By default:
• Only limited endpoints are exposed
MCQ angle:
Actuator endpoints are configurable
Starters Are a Naming Convention
Pattern:
spring-boot-starter-*
Not every dependency follows this
MCQ:
Starters follow strict naming pattern
Starters Do NOT Add Duplicate Dependencies
Starters:
• Pull transitive dependencies smartly
• Avoid duplication
MCQ trap:
Starters increase classpath clutter
Spring Boot Philosophy (Highest-level MCQs)
If confused, choose options aligned with:
• Convention over configuration
• Defaults with override
• Flexibility
• Reduced boilerplate
Avoid options suggesting rigidity or enforcement
FINAL 10-SECOND CHECKLIST (MENTAL)
Before selecting an answer, ask:
1. Is this too absolute?
2. Does this confuse Spring with Spring Boot?
3. Is this about startup vs compile time?
4. Does this violate convention over configuration?
5. Does Spring Boot prefer default + override?
If yes → likely wrong option.