Spring Boot Application Properties and YAML Configuration Quiz Quiz

Explore your understanding of configuring Spring Boot applications using properties files and YAML syntax. This quiz covers key concepts, default settings, format rules, and best practices for managing environment variables and application settings in Spring Boot using both YAML and properties files.

  1. Recognizing YAML Structure

    Which of the following lines shows the correct way to represent a nested property named 'server.port' inside an 'application.yml' file?

    1. server:n port: 8080
    2. server:port=8080
    3. server.port: 8080
    4. -server-port: 8080

    Explanation: The correct format for a nested property in YAML uses indentation and a colon, as in 'server:' followed by an indented 'port: 8080'. The option with 'server:port=8080' is not valid in YAML, and the dash in '-server-port: 8080' suggests a list item, not a property. 'server.port: 8080' is valid in properties files but not the preferred YAML format.

  2. Default Properties File

    By default, which file does a Spring Boot application look for to load configuration properties?

    1. config.txt
    2. boot.properties
    3. application.properties
    4. settings.yaml

    Explanation: Spring Boot automatically loads configuration values from application.properties in the classpath. 'boot.properties' and 'config.txt' are not recognized by default. While YAML files are supported, 'settings.yaml' is not the default and must specifically be named 'application.yml' or 'application.yaml'.

  3. Comments in Properties Files

    What character denotes a comment line in a standard Spring Boot application.properties file?

    1. --
    2. !
    3. //
    4. #

    Explanation: The hash symbol (#) at the start of a line is used for comments in .properties files. Double slashes (//) and double dashes (--) are not supported comment syntaxes in standard properties files. An exclamation mark (!) is sometimes used in other contexts but isn't typical for application.properties comments.

  4. Profile-Specific Configuration

    To apply settings only when the 'dev' profile is active, which file would you use in a Spring Boot project?

    1. dev-application.yml
    2. application-dev.properties
    3. application_profile_dev.properties
    4. profile-dev.config

    Explanation: The 'application-dev.properties' naming pattern allows for profile-specific configuration that is loaded only when the 'dev' profile is active. 'dev-application.yml' and 'application_profile_dev.properties' do not match the expected naming conventions. 'profile-dev.config' will not be recognized by the framework.

  5. Overriding Properties

    When both 'application.properties' and 'application.yml' provide a value for the same property, which file’s value does a Spring Boot application use?

    1. The application randomly picks one
    2. The value from application.yml
    3. Neither value is used
    4. The value from application.properties

    Explanation: If both files define the same property, values from application.properties will override those in application.yml by default due to higher precedence. The application does not choose randomly, and both files are used according to the framework's precedence rules. Ignoring both values is not the expected behavior.

  6. Array Syntax in YAML

    Which YAML syntax correctly represents a list of allowed hosts for a property named 'allowedHosts'?

    1. allowedHosts=[example.com, sample.org]
    2. allowedHosts: example.com, sample.org
    3. allowedHosts: - example.com, - sample.org
    4. allowedHosts:n - example.comn - sample.org

    Explanation: In YAML, a list is represented by a property followed by indented lines beginning with dashes. 'allowedHosts=[example.com, sample.org]' uses invalid YAML syntax that resembles properties files. The comma-separated value 'allowedHosts: example.com, sample.org' is not a YAML list. The last option misuses dashes within the value rather than as list indicators.

  7. Environment Variable Reference

    How can you refer to an environment variable called 'API_KEY' in application.properties for dynamic substitution?

    1. api.key=${API_KEY}
    2. api.key=@API_KEY@
    3. api.key: $ENV.API_KEY
    4. api.key=ENV{API_KEY}

    Explanation: The correct syntax uses curly braces and a dollar sign to substitute environment variables in properties files. '@API_KEY@', '$ENV.API_KEY', and 'ENV{API_KEY}' are not recognized patterns for variable substitution in properties files.

  8. Properties Format Rules

    In a typical 'application.properties' file, how are property names and values separated?

    1. By a colon (:)
    2. By an equals sign (=)
    3. By a double backslash (\)
    4. With a hyphen (-)

    Explanation: An equals sign (=) or sometimes a colon (:) is used to separate names and values in properties files, but the equals sign is most common and expected. Hyphens and double backslashes do not separate key-value pairs in this context. The colon option can sometimes work but is less universally used.

  9. Specifying Multiple Profiles

    Which way can you specify multiple active profiles in 'application.properties'?

    1. profile.active = dev prod
    2. spring.active.profiles=dev;prod
    3. spring.profiles.active=dev,prod
    4. profiles.active: dev+prod

    Explanation: The correct approach uses a comma-separated list in the 'spring.profiles.active' property. The other syntaxes, such as using colons, plus signs, semicolons, or spaces, are not valid for declaring multiple profiles in configuration files. The other options either use incorrect property names or invalid delimiters.

  10. Avoiding Common YAML Errors

    What is the most common cause of errors when writing YAML files for Spring Boot configuration?

    1. Forgetting double quotes around property names
    2. Placing comments after property values
    3. Using semicolons at the end of lines
    4. Incorrect indentation

    Explanation: YAML files are highly sensitive to indentation, and inconsistent use of spaces often leads to parsing issues. Semicolons at the end of lines and forgetting quotes are less likely to cause a problem, as YAML generally does not require quotes or semicolons. While placing comments after values can sometimes cause issues, indentation mistakes remain the top source of errors.