Spring Cloud Risk Assessment & Management 4 — Questions and Answers
Question 1: A Resilience4j TimeLimiter is configured but no circuit breaker is applied to the same operation. What residual risk remains?
- Calls will never time out despite the TimeLimiter config
- Repeated timeouts still accumulate and can exhaust thread resources without circuit breaking (Correct answer)
- The TimeLimiter will conflict with Spring's @Transactional annotation
- Eureka service discovery will be bypassed
Correct answer: Repeated timeouts still accumulate and can exhaust thread resources without circuit breaking
TimeLimiter cancels individual slow calls but without a circuit breaker, each new call still attempts the downstream service, allowing thread accumulation during prolonged outages.
Question 2: In Spring Cloud, what is the security risk of exposing the Spring Boot Actuator /actuator/env endpoint without authentication?
- Triggers automatic config refresh without authorization
- Leaks all environment variables and configuration properties including potential secrets (Correct answer)
- Causes Eureka to deregister the service
- Resets circuit breaker state unintentionally
Correct answer: Leaks all environment variables and configuration properties including potential secrets
The /actuator/env endpoint exposes all configuration properties and environment variables, which may include database passwords, API keys, and other sensitive values.
Question 3: Which Spring Cloud Gateway feature helps mitigate the risk of downstream services receiving oversized request payloads?
- RouteLocator bean configuration
- RequestSize GatewayFilter with a max size limit (Correct answer)
- LoadBalancerClient filter
- SetPath GatewayFilter
Correct answer: RequestSize GatewayFilter with a max size limit
The RequestSize GatewayFilter rejects requests exceeding a configured byte limit with a 413 status, protecting downstream services from large payload attacks.
Question 4: What risk does Spring Cloud Stream's consumer group configuration mitigate in an event-driven microservices architecture?
- Message schema evolution incompatibility
- Duplicate message processing when multiple instances of the same service run (Correct answer)
- Dead letter queue overflow
- Kafka partition rebalancing delays
Correct answer: Duplicate message processing when multiple instances of the same service run
Consumer groups ensure only one instance within a group processes each message, preventing duplicate processing side effects when horizontally scaled services consume from the same topic.
Question 5: A team notices that Spring Cloud Config clients cache configuration for 0 seconds (no cache). What risk does this introduce?
- Stale configuration being served after a code deployment
- Config server becoming a single point of failure bottleneck under high request load (Correct answer)
- JWT tokens expiring before config is refreshed
- Circuit breaker thresholds being ignored
Correct answer: Config server becoming a single point of failure bottleneck under high request load
With no config caching, every property access triggers a config server call, making the config server a high-traffic bottleneck and single point of failure for all property reads.
Question 6: Which risk is introduced when Spring Cloud Kubernetes ConfigMap-based configuration is used without RBAC restrictions?
- ConfigMaps cannot be refreshed without pod restart
- Any pod in the cluster can read or modify ConfigMaps containing sensitive service configuration (Correct answer)
- Spring profiles cannot be activated via ConfigMap
- Kubernetes liveness probes conflict with config refresh
Correct answer: Any pod in the cluster can read or modify ConfigMaps containing sensitive service configuration
Without RBAC, any workload in the namespace can read ConfigMaps, potentially exposing connection strings, feature flags, or other sensitive configuration to unauthorized pods.
Question 7: When using Resilience4j Retry with Spring Cloud, what risk does setting maxAttempts too high introduce for non-idempotent operations?
- Circuit breaker opens prematurely due to retry metrics pollution
- Duplicate side effects such as multiple payments or order submissions (Correct answer)
- Retry exhaustion logs filling disk storage
- Eureka re-registration on every retry
Correct answer: Duplicate side effects such as multiple payments or order submissions
Retrying non-idempotent operations like POST to create a payment can cause the same action to execute multiple times, resulting in duplicate transactions or data corruption.
Spring Cloud Risk Assessment & Management 4
A Resilience4j TimeLimiter is configured but no circuit breaker is applied to the same operation.
What residual risk remains?