Spring Cloud Case Studies & Practical Application 3 — Questions and Answers
Question 1: A healthcare API gateway must enforce JWT authentication for all downstream services without modifying each service. Which Spring Cloud Gateway capability handles this centrally?
- Global filters applying a custom JWT validation filter (Correct answer)
- Eureka metadata propagation
- Spring Cloud Bus JWT broadcast
- Resilience4j rate limiter per JWT claim
Correct answer: Global filters applying a custom JWT validation filter
A Global GatewayFilter applied to all routes can validate JWTs at the gateway boundary before forwarding requests, keeping downstream services auth-agnostic.
Question 2: After enabling Spring Cloud Sleuth, a team finds trace IDs are not propagating through Kafka messages between services. What must they add?
- A custom Eureka metadata propagator
- Spring Cloud Sleuth Kafka binder instrumentation or Micrometer Tracing Kafka propagation (Correct answer)
- Spring Cloud Bus Kafka topic configuration
- A Feign RequestInterceptor for Kafka headers
Correct answer: Spring Cloud Sleuth Kafka binder instrumentation or Micrometer Tracing Kafka propagation
Sleuth/Micrometer Tracing requires messaging-specific instrumentation to inject and extract trace context in Kafka message headers.
Question 3: A SaaS platform serves multiple tenants, each needing isolated configuration. How can Spring Cloud Config Server support per-tenant configuration?
- Use separate Config Server instances per tenant
- Use profile-based naming (e.g., application-{tenant}.yml) with tenant profile activation (Correct answer)
- Store all tenant configs in a single properties file with prefixes
- Use Spring Cloud Bus with tenant-specific topics
Correct answer: Use profile-based naming (e.g., application-{tenant}.yml) with tenant profile activation
Config Server resolves files by application name and profile, so naming files with tenant identifiers as profiles enables clean per-tenant configuration isolation.
Question 4: A team's Feign client calls fail intermittently due to transient network issues. They want automatic retries only on idempotent GET requests. How should they configure this?
- Enable Resilience4j Retry globally for all HTTP methods
- Configure a Feign Retryer or Resilience4j Retry with a custom predicate excluding non-idempotent methods (Correct answer)
- Increase Feign connection timeout to avoid retries
- Disable Feign error decoder and add manual retry logic
Correct answer: Configure a Feign Retryer or Resilience4j Retry with a custom predicate excluding non-idempotent methods
A custom Resilience4j Retry predicate or Feign Retryer can be scoped to idempotent operations, avoiding dangerous duplicate side effects on POST/PUT.
Question 5: A company migrates from Zuul 1 to Spring Cloud Gateway. Their Zuul filters used blocking I/O with ThreadLocal. What must developers change?
- Replace ThreadLocal state with reactive context (Reactor Context) since Gateway is non-blocking (Correct answer)
- Add @EnableZuul to Spring Cloud Gateway
- Convert Zuul pre-filters to Gateway post-filters
- Enable virtual threads in the Gateway JVM
Correct answer: Replace ThreadLocal state with reactive context (Reactor Context) since Gateway is non-blocking
Spring Cloud Gateway is built on Project Reactor and Netty (non-blocking), so ThreadLocal-based state does not propagate across async boundaries and must be replaced with Reactor Context.
Question 6: An operations team wants to refresh configuration across 50 microservice instances simultaneously without calling /actuator/refresh on each. What is the correct Spring Cloud approach?
- Restart all instances via Kubernetes rolling update
- Use Spring Cloud Bus to broadcast a RefreshRemoteApplicationEvent via a message broker (Correct answer)
- Poll Config Server every minute with a cron job
- Use Spring Cloud Config Client automatic polling feature
Correct answer: Use Spring Cloud Bus to broadcast a RefreshRemoteApplicationEvent via a message broker
Spring Cloud Bus propagates refresh events through a message broker so a single /actuator/bus-refresh call triggers refresh across all subscribed instances.
Question 7: A team uses Spring Cloud Contract to test the interface between a producer (order service) and consumer (shipping service). The producer changes the response schema without updating contracts. What happens?
- The shipping service's consumer tests pass because they test against stubs
- The producer's contract verification test fails, catching the breaking change before deployment (Correct answer)
- Eureka removes the producer from the registry
- The API Gateway returns a 502 error automatically
Correct answer: The producer's contract verification test fails, catching the breaking change before deployment
Spring Cloud Contract generates server-side verification tests on the producer; a schema change not reflected in the contract causes these tests to fail in CI.
Spring Cloud Case Studies & Practical Application 3
A healthcare API gateway must enforce JWT authentication for all downstream services without modifying each service.
Which Spring Cloud Gateway capability handles this centrally?