C1000-155 IBM Certified Developer - Cloud Native Java with IBM Liberty Practice Questions

The sessionCache-1.0 feature, which implements JCache (JSR 107), is the standard Liberty solution for distributed session management. By configuring it with a distributed in-memory data grid like Hazelcast or Infinispan, session data is replicated across the cluster. If one pod fails, another pod can retrieve the session data from the distributed cache, providing seamless failover. Session affinity does not provide failover, and database-backed sessions typically have higher latency.

The kernel-slim image is the minimal base image for Open Liberty. It contains only the server kernel and does not pre-install any features. The developer would then use a multi-stage Docker build to add only the specific features their application requires (in this case, MicroProfile features). This results in the smallest possible final image with the minimum number of libraries, significantly reducing the attack surface, which is ideal for production deployments.

False. The Open Liberty Operator manages the deployment and lifecycle of a Liberty application within Kubernetes. It automates tasks like creating Deployments, Services, and Routes based on a custom resource definition (OpenLibertyApplication). However, it still requires a pre-built container image to deploy. The developer is responsible for creating the Dockerfile, building the image containing the application, and pushing it to a container registry that the Kubernetes cluster can access.

The standard and most idiomatic MicroProfile approach is to implement the ClientHeadersFactory interface. This interface allows you to programmatically generate or modify headers for outgoing requests. The factory can then be associated with a REST client interface using the @RegisterClientHeaders annotation. This separates the concern of header manipulation from the client definition and business logic.

For an OutOfMemoryError, a heap dump is the most critical artifact. Loading it into a tool like Eclipse MAT allows the team to analyze object retention, identify large object graphs, and run automated leak suspect reports. This will pinpoint which objects are consuming the most memory and what is preventing them from being garbage collected, directly leading to the root cause of the leak. While thread dumps are useful for hangs and deadlocks, they are less effective for memory leaks. Increasing memory only postpones the problem.

Using a JOIN FETCH in a JPQL query (e.g., SELECT c FROM Customer c JOIN FETCH c.orders WHERE c.id = :id) is the most effective way to solve the N+1 problem. It instructs the persistence provider to retrieve the associated collection (orders) in the same SQL query that retrieves the parent entity (Customer), thus avoiding the extra 'N' queries that would otherwise be executed when accessing the lazy-loaded collection.

The correct and most structured way to provide a detailed example is to use the @APIResponse annotation on the method. Inside it, you define the media type using @Content, and within @Content, you provide one or more @ExampleObject annotations. The value attribute of @ExampleObject contains the string representation of the example JSON.

The @CircuitBreaker annotation is designed specifically for this use case. It follows the circuit breaker pattern, where after a configured number of consecutive failures (requestVolumeThreshold), the circuit 'opens' and subsequent calls fail immediately without attempting to contact the failing service. After a delay (delay), it enters a 'half-open' state to test if the service has recovered. @Retry would repeatedly call the failing service, potentially worsening the problem. @Timeout only limits the duration of a single call, it does not prevent future calls. @Fallback provides an alternative execution path on failure but does not stop calls to the original service.

The bootstrap.properties file is specifically designed for setting properties that are needed before the main server.xml configuration is processed. It has a higher precedence for system properties than server.xml. This makes it ideal for setting early-stage configuration, such as properties that control the configuration parsing itself or sensitive values that should be externalized from the main configuration file.

MicroShed Testing is a framework built on top of Testcontainers and JUnit 5, specifically for testing Jakarta EE and MicroProfile applications. It excels at starting the application in a Docker container alongside its dependencies (like databases or other services), creating a true-to-production test environment. Mockito is for mocking objects (unit tests), Pact is for contract testing, and JUnit 5 is a general testing framework that does not inherently manage containerized dependencies.