Properties, Profiles & SpEL practice questions

Worked examples for Properties, Profiles & SpEL

1. Question 1

   Which TWO statements about activating Spring profiles are correct? Select TWO.

   1. A. Several profiles can be active at once, e.g. spring.profiles.active=dev,db-h2Correct answer

      Spring places no limit on the number of active profiles; several are commonly activated together as a comma-separated list in spring.profiles.active.

   2. B. Profiles can be activated programmatically, e.g. environment.setActiveProfiles("dev", "db-h2")Correct answer

      Besides property-based activation, profiles can be set in code by calling Environment.setActiveProfiles(...) before the context refreshes, which likewise accepts one or more profile names.

   3. C. Exactly one profile may be active at a time

      There is no single-active-profile limit in Spring; several profiles may be active simultaneously, so restricting activation to exactly one is wrong.

   4. D. At most two profiles can be active

      Spring imposes no cap of two active profiles; the number of simultaneously active profiles is unbounded.

   Explanation

   Spring places no limit on how many profiles may be active at the same time. They are commonly activated together as a comma-separated list via the spring.profiles.active property, and they can equally be activated in code by calling Environment.setActiveProfiles(...) before the context is refreshed. Claims that only one profile, or at most two, may be active are simply false.

2. Question 2

   Which Spring Expression Language expression correctly invokes the static method Math.max to compute the larger of 1 and 2?

   1. A. #{java.lang.Math.max(1, 2)}

      SpEL does not treat a bare fully-qualified class name as a type reference; a static method call requires the T(...) type operator, so this form fails to resolve Math.

   2. B. #{T(java.lang.Math).max(1, 2)}Correct answer

      SpEL accesses static members through the T() type operator: T(java.lang.Math) yields the Class, on which the static max method is then invoked.

   3. C. ${T(java.lang.Math).max(1, 2)}

      The ${...} syntax is a property placeholder resolved against the Environment, not a SpEL expression, so it never evaluates a method call.

   4. D. #{@Math.max(1, 2)}

      The @ prefix references a container bean named Math, not the java.lang.Math class, so this would look up a (non-existent) bean rather than call a static method.

   Explanation

   Static access in SpEL goes through the T() type operator: T(java.lang.Math) resolves the class and max is then called on it. A bare class name is not a type reference, ${...} is property-placeholder syntax rather than SpEL, and the @ prefix denotes a container bean reference rather than a Java type.

3. Question 3

   A bean is annotated @Profile("dev"). Under what condition is it registered in the container?

   1. A. Only when no profile is active at all

      This describes the opposite of the actual activation logic. The bean requires 'dev' to be active, not the absence of any active profile.

   2. B. Always — but it is only injected into other dev-profiled beans

      Misconception that the bean is always registered but restricted in visibility. When 'dev' is inactive the bean definition is skipped entirely, not registered-but-restricted.

   3. C. Only when the 'dev' profile is among the active profiles (e.g. spring.profiles.active=dev)Correct answer

      Correct: @Profile("dev") makes the bean definition conditional on 'dev' being among the active profiles; otherwise the definition is skipped.

   4. D. Whenever any profile other than 'dev' is active

      This describes the opposite of the actual activation logic. The bean requires 'dev' itself to be active, not the activation of some other profile.

   Explanation

   @Profile makes a bean definition conditional on the named profile being active. Activation is positive: the bean is registered precisely when its profile is among the active set, and if that profile is not active the definition is skipped entirely rather than registered with restricted visibility.

4. Question 4

   In a @Value annotation, what is the difference between ${...} and #{...}?

   1. A. #{...} resolves a property placeholder; ${...} evaluates a SpEL expression

      This reverses the two syntaxes — the most common confusion. In fact ${...} is the property placeholder and #{...} is the SpEL expression, not the other way around.

   2. B. ${...} only works in XML configuration; #{...} only works in annotations

      Incorrect: both syntaxes work in annotations and in XML. Neither is restricted to a particular configuration style.

   3. C. They are interchangeable syntaxes that both perform a property lookup

      They are not equivalent. Only ${...} performs a property lookup; #{...} evaluates a SpEL expression, so the two are not interchangeable.

   4. D. ${...} resolves a property placeholder from the Environment; #{...} evaluates a SpEL expressionCorrect answer

      Correct: ${...} is property-placeholder syntax resolved against the Environment/PropertySources, while #{...} is the Spring Expression Language and evaluates an expression such as a bean reference or arithmetic.

   Explanation

   The ${...} syntax is a property placeholder resolved against the Environment and its PropertySources, whereas #{...} is the Spring Expression Language and evaluates an expression such as a bean reference or arithmetic. These are two distinct mechanisms, not interchangeable ways to look up a property, and both forms are usable in annotations and in XML.

5. Question 5

   Which TWO are valid ways to obtain configuration values in code, rather than via @Value injection? Select TWO.

   1. A. Inject the Environment abstraction and call environment.getProperty("some.key")Correct answer

      Correct: this is one of the two valid approaches -- the Environment abstraction unifies all configured property sources and exposes getProperty(...) for programmatic lookups honoring active profiles and resolved sources.

   2. B. Bind a group of properties onto a typed POJO with @ConfigurationProperties and read the bound values from its gettersCorrect answer

      Correct: this is the second valid approach -- @ConfigurationProperties performs type-safe binding of a prefixed group of properties onto a POJO (with relaxed binding and validation), and the code then reads the values from the bean's getters instead of using @Value.

   3. C. @Value is the only supported mechanism; programmatic access is impossible

      @Value is not the only option; the Environment abstraction provides first-class programmatic access to properties.

   4. D. Call new Properties().load() against application.properties manually

      Manually loading the file bypasses Spring's resolved property sources and profile handling, so it does not reflect the effective configuration.

   Explanation

   Two approaches are valid. Spring's Environment abstraction aggregates every configured property source and exposes getProperty(...) for reading configuration in code, respecting active profiles and source precedence; and @ConfigurationProperties binds a prefixed group of properties onto a typed POJO whose getters the code then reads. Neither of these is @Value. Claiming @Value is the only mechanism is false, and manually loading application.properties bypasses Spring's resolved sources and profile handling so it does not reflect the effective configuration.

6. Question 6

   An application starts with no profile explicitly activated (spring.profiles.active is unset and nothing calls setActiveProfiles). With respect to profiles, which beans are registered?

   1. A. Only beans annotated @Profile("default"); every bean without a @Profile is skipped until some profile is activated.

      A bean with no @Profile is always registered regardless of active profiles, so unannotated beans are not skipped when nothing is active.

   2. B. No profile-conditional beans at all; the container refuses to start until an active profile is set.

      Spring does not require an active profile to start; when none is active the default profile applies rather than the context failing.

   3. C. Every bean regardless of its @Profile, because with no active profiles all profile conditions are treated as satisfied.

      Profile conditions are not universally satisfied when nothing is active; a bean tied to a named profile such as @Profile("dev") stays unregistered until that profile is active.

   4. D. Beans with no @Profile, plus beans annotated @Profile("default"); as soon as any profile is activated, the default-profile beans are skipped.Correct answer

      Unannotated beans are always registered, and when no profile is active the default profile applies so @Profile("default") beans register too; activating any profile then causes those default-only beans to be skipped.

   Explanation

   A bean with no @Profile is always registered. When no profile is explicitly active, the default profile (named 'default' unless overridden) applies, so beans marked @Profile("default") also register. The moment any profile is activated, the default-profile beans are skipped, while beans tied to other named profiles register only when their own profile is active.

7. Question 7

   A field is annotated @Value("#{systemProperties['db.pool'] ?: 10}"). What value is injected when the db.pool system property is not set?

   1. A. Startup fails, because the Elvis operator ?: is not valid SpEL syntax.

      The Elvis operator is a supported SpEL operator for null-defaulting, so the expression is well-formed and evaluates rather than failing.

   2. B. The literal string 'db.pool' is injected unchanged.

      Text inside #{...} is evaluated as an expression, not treated as a literal; systemProperties['db.pool'] is a map lookup, so the key name is never injected verbatim.

   3. C. 10, because the Elvis operator returns its right-hand operand when the left-hand side evaluates to null.Correct answer

      systemProperties['db.pool'] resolves to null when the property is absent, and the Elvis operator (a ?: b) returns b when a is null, so the default 10 is injected.

   4. D. null, because safe-navigation suppresses the fallback when the property is missing.

      This confuses the Elvis operator with safe navigation (?.). Elvis explicitly substitutes the right-hand value on null, so the result is 10, not null.

   Explanation

   Inside a #{...} SpEL expression, systemProperties['db.pool'] is a map lookup that yields null when the property is unset. The Elvis operator (a ?: b) returns its right-hand operand whenever the left-hand side is null, so the expression defaults to 10. This is distinct from safe navigation (?.), which guards against calling members on a null reference rather than supplying a default value.

8. Question 8

   A standalone (non-Boot) Spring application uses a StandardEnvironment. The key db.host is defined in three places at once: as an OS environment variable, as a JVM system property passed with a -D flag, and in a file contributed via @PropertySource. Which value does the Environment resolve for db.host?

   1. A. The JVM system property value, because system properties outrank OS environment variables, and both outrank a source added later via @PropertySource.Correct answer

      In a StandardEnvironment the built-in sources are ordered so JVM system properties take precedence over OS environment variables, and both are consulted before a source added afterward such as an @PropertySource file. The first match in precedence order wins.

   2. B. The OS environment variable value, because environment variables always take the highest precedence in a StandardEnvironment.

      This inverts the documented order. OS environment variables are outranked by JVM system properties in a StandardEnvironment, so the system property, not the environment variable, wins.

   3. C. The @PropertySource file value, because the most recently added property source is checked first.

      Sources added later, such as an @PropertySource file, sit below the built-in system-property and environment-variable sources, so they are consulted last rather than first.

   4. D. Startup fails with an ambiguous-property error because the same key is defined in three sources.

      Multiple sources defining the same key is normal and expected; resolution simply walks the sources in precedence order and returns the first match rather than failing.

   Explanation

   A property is looked up across all registered sources in precedence order and the first match wins. For a standalone StandardEnvironment, JVM system properties outrank OS environment variables, and both outrank sources added later such as an @PropertySource file. This ordering is exactly what lets a -D flag override file-based config at deploy time without a startup error.