Spring Boot Spring Cloud Interview Questions and Answers

Spring Cloud is where a Spring Boot interview shifts from a single service to a system of them. Once you claim microservices experience, interviewers probe the infrastructure pieces — discovery, gateway, config, resilience — and, critically, whether you know which components are current. Several famous Netflix pieces are retired, and naming the replacement is often the real test. This set covers the Spring Cloud questions asked in intermediate rounds, with correct, current components.

What does Spring Cloud provide for microservices?

Spring Cloud packages the cross-cutting infrastructure that microservices need but that Spring Boot alone does not: service discovery, client-side load balancing, an API gateway, centralised configuration, declarative REST clients, circuit breakers and distributed tracing. Each is a starter you add and configure.

The framing to give is that Spring Boot builds one service well, while Spring Cloud helps many services find, call, configure and observe each other. It does not reinvent these concerns from scratch; it integrates proven tools (Eureka, Resilience4j, Micrometer) behind consistent Spring abstractions so you configure rather than code them.

What is service discovery and how does Eureka work?

Service discovery lets services register themselves and lets callers find healthy instances by logical name instead of hard-coded hosts. Eureka is a discovery server: each service registers on startup and sends heartbeats; callers query Eureka (or use a cached registry) to resolve a service name to a live instance.

In a container or cloud environment, instances come and go and their addresses change, so a hard-coded URL is a liability. With Eureka, a caller asks for order-service and gets a currently-registered, healthy instance. The heartbeat mechanism means an instance that dies stops being handed out after it misses its renewals.

Interview note: Follow-up: "what if the Eureka server is down?" Clients cache the registry locally, so short outages do not immediately break lookups. Eureka favours availability over strict consistency — a design choice worth naming.

How does client-side load balancing work now that Ribbon is gone?

Spring Cloud LoadBalancer replaced Netflix Ribbon, which was removed. It runs on the client side: the caller holds the list of instances for a service (from discovery) and picks one per request, typically round-robin. There is no separate load-balancer hop — the choice happens in the calling service.

The contrast with a server-side load balancer is the point. A server-side balancer is a network component all traffic passes through; client-side balancing distributes the decision into each caller, which removes a hop and pairs naturally with discovery. Spring Cloud LoadBalancer integrates with RestClient, WebClient and OpenFeign so a @LoadBalanced client resolves service names automatically.

Interview note: Trap: mentioning Ribbon as the current load balancer. It is deprecated and removed; the current answer is Spring Cloud LoadBalancer. This is one of the most common "are you up to date?" checks in Spring Cloud interviews.

What is Spring Cloud Gateway?

Spring Cloud Gateway is the API gateway for Spring microservices — a single entry point that routes inbound requests to backend services and applies cross-cutting filters like auth, rate limiting and header rewriting. It is built on reactive Spring WebFlux and Netty, so it is non-blocking.

A gateway centralises concerns you do not want duplicated in every service: authentication, CORS, rate limiting, and consistent routing. Routes are typically defined in YAML with predicates (match by path, header, method) and filters (transform the request or response).

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service        # lb:// resolves via discovery + load balancer
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1

The lb:// scheme is the interview detail: it tells the gateway to resolve order-service through discovery and client-side load balancing rather than a fixed URL.

What is Spring Cloud Config Server and how does @RefreshScope work?

Spring Cloud Config Server centralises externalised configuration: services fetch their properties from the server, which reads them from a backing store like a Git repository. @RefreshScope lets a bean pick up changed configuration at runtime — after the config changes, hitting the /actuator/refresh endpoint re-creates refresh-scoped beans with the new values without a restart.

Centralised config solves the problem of the same property drifting across dozens of services and environments. One repository, versioned, is the source of truth, and per-service/per-profile files layer on top.

The refresh mechanism is what interviewers dig into: normal singletons are created once at startup, so a config change would not reach them. Marking a bean @RefreshScope proxies it so that on a refresh event it is rebuilt, letting you change, say, a feature flag or a timeout live.

Interview note: Follow-up: "how do you refresh many services at once?" With Spring Cloud Bus, which broadcasts a refresh event over a message broker so all instances refresh together, rather than calling each /actuator/refresh by hand.

What is OpenFeign and why use it?

OpenFeign is a declarative REST client: you define a Java interface with request-mapping annotations, and Spring generates the HTTP-calling implementation. It removes the boilerplate of building requests by hand and integrates with discovery and load balancing so you call by service name.

@FeignClient(name = "inventory-service")
public interface InventoryClient {

    @GetMapping("/api/inventory/{sku}")
    StockLevel getStock(@PathVariable String sku);
}

You then inject InventoryClient and call getStock("ABC") like a local method; Feign turns it into an HTTP GET to a resolved inventory-service instance. The value is readability and consistency — the client reads like the API contract, and cross-cutting concerns (load balancing, error decoding, resilience) attach to it declaratively.

Interview note: Trap: "does Feign make the call synchronous or is it non-blocking?" OpenFeign is a blocking client. For reactive, non-blocking calls you use WebClient (or the newer declarative HTTP interface clients). Knowing Feign blocks matters for capacity planning.

How does Resilience4j provide resilience?

Resilience4j is the circuit-breaker and fault-tolerance library that replaced the end-of-life Hystrix. It provides circuit breaker, retry, rate limiter, bulkhead and time limiter patterns as lightweight, composable decorators. The circuit breaker opens after a failure threshold, short-circuits to a fallback, then half-opens to test recovery.

The circuit-breaker state machine is the core interview topic. Closed = calls pass through; too many failures trip it to Open = calls fail fast to a fallback without hitting the dependency; after a wait it goes Half-Open = a few trial calls decide whether to close again or re-open. This is what stops a single slow dependency from exhausting threads and cascading across the system.

@Service
public class PricingService {

    @CircuitBreaker(name = "pricing", fallbackMethod = "cachedPrice")
    public Price fetch(String sku) {
        return remotePricingClient.get(sku);   // may fail or time out
    }

    private Price cachedPrice(String sku, Throwable t) {
        return Price.lastKnown(sku);            // graceful fallback
    }
}

Pair the circuit breaker with a time limiter and a retry, and you get a dependency call that fails fast, degrades gracefully, and recovers automatically.

Interview note: Follow-up: "why not Hystrix?" It is in maintenance/end-of-life and no longer developed. Resilience4j is the current, actively maintained choice and is designed for Java 8+ functional composition.

How do you trace requests across services?

With Micrometer Tracing, which replaced Spring Cloud Sleuth. It assigns each incoming request a trace id and each hop a span id, propagates them across service calls (via headers), and exports the spans to a backend like Zipkin or an OpenTelemetry collector so you can follow a single request through many services.

Distributed tracing answers the microservices question "where did the 3 seconds go?" A trace id ties together the gateway, the order service, the inventory call and the database span, so a slow request is attributable to a specific hop rather than guessed at. Micrometer Tracing plugs into the same Micrometer Observation API used for metrics, so tracing and metrics share instrumentation.

Interview note: Trap: naming Sleuth as the current tracer. Sleuth was superseded by Micrometer Tracing; mentioning the migration signals you have worked with a recent Spring Cloud version.

What interviewers really test

Spring Cloud questions are as much a currency check as a knowledge check: interviewers want to hear Spring Cloud LoadBalancer, Resilience4j and Micrometer Tracing rather than Ribbon, Hystrix and Sleuth, and they want you to connect the pieces — discovery feeds load balancing, the gateway routes through lb://, config is centralised and refreshable, and resilience wraps the cross-service calls. Reciting components in isolation is weaker than showing how a request flows through them.

To prepare, stand up a minimal system: two services registered in Eureka, a gateway routing to them, a Feign client between them wrapped in a Resilience4j circuit breaker, and config pulled from a Config Server. The Spring Boot learning path covers the single-service foundations, and this pairs naturally with the Actuator interview set, since health, metrics and the refresh endpoint are how you operate these services. A mock interview is the fastest way to practise explaining the request path across services under follow-up pressure.