C1000-155 Sample Questions & Answers

False. The 'zero migration' principle applies to the Liberty runtime itself, meaning you can update the runtime without changing your application or its configuration. However, it does not apply to major specification changes like the move from Jakarta EE 8 to Jakarta EE 10. This move involves a package name change from javax.* to jakarta.*, which requires significant code changes. The application would need to be recompiled against the new Jakarta EE 10 APIs.

Liberty dev mode relies on detecting changes to compiled .class files. If the Integrated Development Environment (IDE) is not automatically compiling the Java source files upon saving, dev mode will not detect any changes and will not trigger a hot reload.

If the code change introduced a compilation error, the .class file will not be updated. Since dev mode monitors the compiled output directory, it will not see a new file and therefore will not reload the application. The developer would need to check their IDE's problem view or run a manual build to see the error.

Factor III, 'Config', states that configuration should be stored in the environment and strictly separated from the code. Hardcoding connection details in server.xml violates this principle because the configuration is bundled with the deployable artifact. The correct approach is to externalize this configuration using environment variables or a configuration service, which can then be injected into the application at runtime via MicroProfile Config.

Jakarta Bean Validation is the standard specification for this purpose. By annotating the fields of the payload model class (POJO) with constraints like @Size(min=12) and @Pattern(regexp=...), the validation logic is kept declarative and separate from the business logic. When the JAX-RS method is annotated with @Valid, the Liberty runtime will automatically trigger the validation and return a 400 Bad Request if the constraints are violated.

The correct and simplest method to enable structured JSON logging in Open Liberty is to add the attribute messageSource="json" to the element in server.xml. This instructs Liberty to write log records for messages.log and trace.log in JSON format, which includes fields like timestamp, log level, message, thread ID, and other context, making them easily parsable by log aggregation tools.

A @Gauge is the correct metric type for measuring a value that can arbitrarily go up and down, such as the number of active sessions, CPU temperature, or items in a queue. A @Counted metric is a simple monotonically increasing counter, which is not suitable for this scenario as it cannot decrease. @Timed measures duration, and @Metered measures the rate of events.

The openidConnectClient-1.0 feature is specifically designed to configure Liberty as an OpenID Connect Relying Party (Client). Enabling this feature allows the server to redirect users to an external OIDC Provider for authentication and to process the resulting ID token to establish a security context. mpJwt-2.0 is for validating JWTs for API security, not for handling the OIDC browser-based login flow. appSecurity-2.0 is a prerequisite but does not provide the OIDC client capability itself.

The correct way to make an asynchronous call that returns a CompletionStage with the JAX-RS client API is to first invoke the async() method on the Invocation.Builder instance. This returns an AsyncInvoker, which has methods like get(), post(), etc., that return a CompletionStage. The other options are either synchronous or use incorrect syntax.

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.