Why configuration matters in Spring Boot - Quick Recap

Recall & Review

beginner

What is the main purpose of configuration in Spring Boot?

Configuration in Spring Boot helps customize how the application behaves without changing the code. It allows easy setup of things like database connections, server ports, and security settings.

beginner

How does external configuration improve application flexibility?

External configuration lets you change settings like URLs or credentials without rebuilding the app. This means you can use the same code in different environments like development, testing, and production.

beginner

Why is it better to avoid hardcoding values in your Spring Boot app?

Hardcoding values makes it hard to update settings and can cause errors when moving between environments. Using configuration files or environment variables keeps your app adaptable and easier to maintain.

beginner

What are common ways to provide configuration in Spring Boot?

You can use application.properties or application.yml files, environment variables, or command-line arguments to provide configuration in Spring Boot.

intermediate

How does configuration help with security in Spring Boot?

Configuration allows you to keep sensitive data like passwords outside the code. This reduces risk and makes it easier to update secrets without changing the app itself.

Why should you use configuration files instead of hardcoding values in Spring Boot?

A To make the code run faster

B To reduce the size of the application

C To easily change settings without modifying code

D To avoid using environment variables

Configuration files let you change settings like ports or database URLs without changing the code, making the app flexible.

Which file is commonly used for configuration in Spring Boot?

A application.properties

B config.xml

C settings.json

D main.java

Spring Boot uses application.properties or application.yml files to hold configuration settings.

What is a benefit of externalizing configuration in Spring Boot?

A Allows using the same code in different environments

B Makes the app run without a JVM

C Automatically fixes bugs

D Removes the need for testing

External configuration lets you adjust settings per environment without changing the code.

How can sensitive data like passwords be managed in Spring Boot configuration?

A By hardcoding them in the source code

B By storing them in configuration files or environment variables

C By printing them in logs

D By embedding them in HTML files

Storing sensitive data in configuration files or environment variables keeps it separate from code and easier to update securely.

Which of these is NOT a way to provide configuration in Spring Boot?

A Command-line arguments

B Environment variables

C application.properties file

D Hardcoded values in Java methods

Hardcoded values are not recommended for configuration because they reduce flexibility.

Explain why configuration matters in Spring Boot applications.

Think about how apps need to behave differently in development and production.

Describe common methods to provide configuration in Spring Boot and why they are useful.

Consider where you can store settings outside the code.

Practice

1. Why is configuration important in a Spring Boot application?

easy

A. It allows changing app behavior without modifying the code.

B. It makes the app run faster by skipping code.

C. It automatically fixes bugs in the code.

D. It prevents the app from starting without internet.

Solution

1. Step 1: Understand the role of configuration

   Configuration controls how the app behaves without changing the source code.

2. Step 2: Identify the benefit in Spring Boot

   Spring Boot uses configuration files to adjust settings easily for different environments.

3. Final Answer:

   It allows changing app behavior without modifying the code. -> Option A

4. Quick Check:

   Configuration changes behavior without code edits [OK]

Hint: Think: config changes settings, not code [OK]

Common Mistakes:

• Confusing configuration with code changes
• Believing configuration speeds up app runtime
• Assuming configuration fixes bugs automatically

2. Which of the following is the correct way to specify a property in Spring Boot's application.properties file?

easy

A. server port = 8080

B. server-port: 8080

C. server.port=8080

D. serverPort=8080

Solution

1. Step 1: Recall Spring Boot property syntax

   Spring Boot uses key=value pairs in application.properties files.

2. Step 2: Match the correct syntax

   The correct syntax uses dots to separate words and equals sign to assign values, like server.port=8080.

3. Final Answer:

   server.port=8080 -> Option C

4. Quick Check:

   Properties use dot notation and equals sign [OK]

Hint: Properties use dot notation and equals sign [OK]

Common Mistakes:

• Using colon instead of equals sign
• Using camelCase instead of dot notation
• Adding spaces around equals sign

3. Given the following application.properties content:

spring.profiles.active=dev
server.port=9090

What will be the server port when running the app with the dev profile?

medium

A. 9090 (from properties file)

B. 8080 (default port)

C. Random port assigned at runtime

D. Application will fail to start

Solution

1. Step 1: Identify active profile and property

   The active profile is set to dev, and server.port=9090 is defined.

2. Step 2: Understand profile effect on configuration

   Since server.port is set in the active profile, the app uses port 9090.

3. Final Answer:

   9090 (from properties file) -> Option A

4. Quick Check:

   Active profile sets server.port to 9090 [OK]

Hint: Active profile properties override defaults [OK]

Common Mistakes:

• Assuming default port 8080 always applies
• Thinking profile disables server port setting
• Believing app fails without explicit port

4. You have two configuration files: application.properties and application-prod.properties. You want to run the app with the prod profile but the app still uses settings from application.properties. What is the likely cause?

medium

A. Spring Boot does not support multiple configuration files.

B. The application-prod.properties file is missing a required property.

C. The app needs to be restarted twice to apply profiles.

D. The spring.profiles.active property is not set to prod.

Solution

1. Step 1: Check profile activation

   Spring Boot uses spring.profiles.active to select which profile config to load.

2. Step 2: Identify cause of fallback

   If spring.profiles.active is not set to prod, the app uses default application.properties.

3. Final Answer:

   The spring.profiles.active property is not set to prod. -> Option D

4. Quick Check:

   Profile must be activated to load its config [OK]

Hint: Activate profile with spring.profiles.active [OK]

Common Mistakes:

• Assuming file presence auto-activates profile
• Thinking missing properties cause fallback
• Believing multiple config files are unsupported

5. You want to have different database URLs for dev and prod environments in Spring Boot. Which approach correctly manages this using configuration?

hard

A. Hardcode both URLs in the main code and use if-else to select at runtime.

B. Create application-dev.properties and application-prod.properties with respective URLs, then set spring.profiles.active accordingly.

C. Use environment variables only and ignore Spring Boot profiles.

D. Put both URLs in application.properties separated by commas.

Solution

1. Step 1: Understand profile-based configuration

   Spring Boot supports multiple config files for different profiles to separate environment settings.

2. Step 2: Apply correct method for environment URLs

   Creating application-dev.properties and application-prod.properties with URLs and activating profiles is the standard way.

3. Final Answer:

   Create application-dev.properties and application-prod.properties with respective URLs, then set spring.profiles.active accordingly. -> Option B

4. Quick Check:

   Profiles separate environment configs cleanly [OK]

Hint: Use profile-specific properties files for environments [OK]

Common Mistakes:

• Hardcoding URLs in code instead of config
• Ignoring profiles and mixing URLs in one file
• Using environment variables without profiles