• Breaking change? (if so, please describe the impact and migration path for existing application instances)

What changes did you make?

Added comprehensive configuration validation with health check integration. The implementation includes:

• ConfigValidationHealthIndicator: A reactive health indicator that validates application configuration and reports health status via /actuator/health endpoint
• ConfigValidator: A component that performs configuration validation on application startup
• Failure-fast validation: Strict type checking and validation of all configuration sections (auth, kafka, rbac) with clear error messages
• No breaking changes: Maintains backward compatibility while adding validation capabilities

Is there anything you'd like reviewers to focus on?

• The reactive health indicator pattern implementation
• Failure-fast validation semantics without using reflection
• Proper separation of concerns between health checking and validation logic
• Use of existing Spring Boot mechanisms instead of direct file parsing

How Has This Been Tested?

• No need to
• Manually (please, describe, if necessary)
• Unit checks
• Integration checks
• Covered by existing automation

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
• My changes generate no new warnings (e.g. Sonar is happy)
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged

Check out Contributing and Code of Conduct

A picture of a cute animal (not mandatory but encouraged)

🦊 (A fox carefully checking configuration files!)