Debug Spring Boot Profiles: Missing-Credential Exception and Unapplied Default Value

The Spring Boot backend section of a full-stack online assessment gives you a small Spring Boot service together with its tests. The section tests how Spring Boot loads configuration, how profiles select and override properties, and how configuration values reach beans through dependency injection. When you run the suite, the test cases report as passing, but the console log contains red error output: test cases that run under a `staging` profile are failing. Two of those failures are reported: 1. A staging test expects the service to throw a specific exception, named in the task, when a user credential is missing. That behaviour has not been implemented. 2. Another staging test fails for a reason related to a default value that is missing or is not being applied correctly. The candidate ran out of time before finding the root cause, so treat it as an open diagnosis. Fix both failures so that the staging cases pass without breaking the default run. The configuration may be written as `application.properties` or as YAML, and you should be able to choose the active profile both in the application's `main` method and on the command line, for example: ```java public static void main(String[] args) { new SpringApplicationBuilder(MyApplication.class) .profiles("dev") // activates the "dev" profile .run(args); } ``` ```bash java -jar app.jar --spring.profiles.active=dev ``` An AI assistant is available in the environment for syntax questions. ### Clarifying Questions - Is the missing credential a configuration property that the staging profile is expected to supply, or a value that arrives with each request? - Should the specified exception be thrown when the application context starts, or when the credential is first used? - Does a property that is present but empty or blank count as missing? - Where is the staging configuration defined: a separate `application-staging.properties` or `application-staging.yml` file, or a profile-specific section of one multi-document YAML file? - How do the staging tests activate their profile: `@ActiveProfiles`, a test property, or an environment variable? ### Part 1 — Find out what the staging run actually sees Explain how Spring Boot decides which profiles are active and which property source wins when the same key is defined in several places. Then describe how you would reproduce the staging failures locally and confirm the value each failing key resolves to. ```hint Green is not the whole story Ask which cases the pass/fail summary reflects, and where a failure in a profile-specific run would show up instead. ``` #### What This Part Should Cover - The ways to activate a profile (in `main`, on the command line, in tests) and how they combine - Property-source precedence, including how profile-specific files override the base file - A concrete way to see the resolved value of a key and the source that supplied it ### Part 2 — Throw the required exception for a missing credential Implement the behaviour the first staging test expects: when the user credential is missing, the service throws the exception the task specifies. ```hint Who throws first Consider what Spring itself throws when a placeholder with no default cannot be resolved, and whether that is the exception the test asserts. ``` #### What This Part Should Cover - Where the check lives (startup or first use) and why - How "missing" is defined, including empty and blank values - A test under the staging profile that asserts the exact exception type ### Part 3 — Make the default value apply Diagnose and fix the second staging failure, in which a default value is missing or is not applied correctly. ```hint When a default is skipped List the situations in which a field ends up without the intended value even though a default appears somewhere in the code or the configuration. ``` #### What This Part Should Cover - The exact semantics of `@Value` placeholder defaults - Override and format pitfalls in profile-specific `.properties` and YAML files - Injection pitfalls that leave a field unset regardless of configuration ### What a Strong Answer Covers - Reads the full console log instead of trusting the pass/fail summary, and reproduces the staging run deliberately - Explains profile activation and property precedence precisely enough to predict which value wins - Uses correct placeholder syntax and distinguishes a missing key from an empty value - Throws the specified exception at a deliberate point, covered by a staging-profile test - Verifies both the default and the staging runs after the fix and leaves no hard-coded credentials or debugging code behind ### Follow-up Questions - How would you move these settings from `@Value` fields to a `@ConfigurationProperties` class with validation, and what would change in the failure messages? - Two profiles, `staging` and `local`, are active and both define the same key. Which value wins, and how would you check? - How do environment variables such as `SPRING_PROFILES_ACTIVE`, or an upper-case form of a property name, interact with the properties files? - How would you keep a real staging credential out of the repository while still running the staging tests in CI?