Free VMware 2V0-72.22 Practice Test Questions 2026

Explanation:

According to REST principles, resources are identified by URIs that represent the resource itself, not actions. To update an existing resource (full replacement), the recommended HTTP method is PUT or PATCH (for partial update). The URI should be the resource identifier, e.g., /orders/1234. This clearly indicates that the client is updating the order with ID 1234.

B is correct – Sending a PUT request to /orders/1234 follows REST best practices:
The URI identifies the specific resource.
PUT indicates a full replacement of that resource.
The request body contains the updated representation.

❌ Why other options are incorrect:

A – PUT /orders/edit?id=1234 – Incorrect. The URI contains a verb (edit), which violates REST principles (URIs should represent nouns, not actions). Also, using query parameters to identify a resource for update is non-standard.

C – POST /orders/1234 – Incorrect.POST is typically used for creating a new resource (often to a collection URI like /orders) or submitting data to be processed. Using POST to update a specific resource is not RESTful when PUT or PATCH is appropriate.

D – POST /orders/edit?id=1234 – Incorrect for multiple reasons: URI contains a verb (edit), uses query parameters for resource identification, and uses POST instead of PUT/PATCH for update.

📚References:

REST Architectural Style (Roy Fielding) – Resource identification:
“A resource is a conceptual mapping to a set of entities. Resources are identified by URIs. PUT is used to update or replace a resource.”

RFC 7231 – HTTP Semantics:
“PUT replaces all current representations of the target resource with the request payload.” “POST is not idempotent and is not the intended method for full resource replacement.”

Explanation:

JdbcTemplate is Spring's core JDBC abstraction that simplifies database access by handling resource management (connections, statements, result sets) and exception translation. It provides a rich set of methods for both query execution (reading data) and updates (insert, update, delete).

B is correct – JdbcTemplate provides the ability to work with result sets via callbacks like RowMapper, ResultSetExtractor, and RowCallbackHandler. These allow mapping rows to objects or processing result sets directly.

D is correct – JdbcTemplate provides methods for query execution, including query(), queryForObject(), queryForList(), queryForMap(), and execute() for SELECT statements.

❌ Why other options are incorrect:

A – False.JdbcTemplate methods do not throw SQLException. Instead, they throw Spring's DataAccessException (unchecked). SQLException is caught internally and translated, relieving developers of mandatory try-catch handling.

C – False.JdbcTemplate can perform both updates (insert, update, delete) via update() method and queries via query() methods.

E – False. JdbcTemplate does not generate SQL statements. It executes SQL strings provided by the developer. SQL generation is the responsibility of higher-level frameworks like Spring Data JDBC, JPA, or QueryDSL.

📚References Spring Framework Documentation – JdbcTemplate:
“JdbcTemplate executes SQL queries and updates, iterates over result sets, catches JDBC exceptions and translates them to the generic DataAccessException hierarchy.”

Spring JDBC – Exception Translation:
“All SQLException are translated to unchecked DataAccessException subclasses.”

VMware 2V0-72.22 Exam Guide – Data Access:
“Understand the role of JdbcTemplate, its methods for querying and updating, and the absence of checked SQLException.”

Explanation:

RestTemplate is Spring's synchronous HTTP client for consuming RESTful services. It simplifies REST client development by providing convenience methods for common HTTP operations (GET, POST, PUT, DELETE, etc.) and automatically handles marshalling/unmarshalling between Java objects and HTTP messages (JSON/XML) using HttpMessageConverter.

B is correct – RestTemplate automatically supports sending and receiving Java objects. It uses HttpMessageConverter (e.g., MappingJackson2HttpMessageConverter) to convert request bodies to JSON/XML and responses back to Java objects without manual parsing.

C is correct – RestTemplate provides convenience methods for writing REST clients, such as getForObject(), getForEntity(), postForObject(), put(), delete(), exchange(), etc.

❌ Why other options are incorrect:

A – False. RestTemplate is synchronous and blocking. It waits for the response before proceeding. For non-blocking asynchronous HTTP clients, Spring provides WebClient (part of Spring WebFlux).

D – False. RestTemplate is for clients, not for writing REST services. Writing REST services is done using @RestController, @RequestMapping, etc. The phrase "convenience methods for writing REST services" describes Spring MVC on the server side.

E – False. RestTemplate does support custom headers. You can use HttpHeaders together with HttpEntity and pass to methods like exchange() or postForEntity() to set custom headers (e.g., authentication, content-type, custom keys).

📚 References

Spring Framework Documentation – RestTemplate:
“RestTemplate is a synchronous HTTP client that simplifies communication with RESTful services. It automatically converts between Java objects and HTTP messages.”

Spring Boot – REST Clients:
“RestTemplate provides methods like getForObject, postForLocation, and exchange for common HTTP interactions. Custom headers are supported via HttpEntity.”

Explanation:

Custom Status Values (Option C): Spring Boot Actuator's health architecture is highly extensible. Developers are not limited to the default statuses and can define completely custom status values (e.g., FATAL or DEGRADED) by instantiating a new Status object with a unique code string.

Built-in Statuses & Severity (Option D):
Out of the box, Spring Boot Actuator defines four core health statuses. They are ordered strictly by default severity to determine the aggregate health of the system: DOWN (highest severity), OUT_OF_SERVICE, UNKNOWN, and UP (lowest severity).

Why the Other Options Are Incorrect

A is incorrect: The first status in the sorted list of severity is selected as the overall system status, not the last. The aggregate health reflects the worst-case scenario present among the component metrics.

B is incorrect:The status with the highest severity (the most critical failure) is bubbling up to become the top-level aggregate status of the application.

E is incorrect: The default severity order is fully customizable. Developers can reconfigure the hierarchy using the application property management.endpoint.health.status.order to change the priority or include custom status values.

References

Spring Boot Production-ready Features Documentation:Section: Auto-configured HealthIndicators & Writing Custom HealthIndicators – Explains the default status severity ranking, how aggregation works, and how to define custom codes.

Explanation:

Component Scanning (Option B): The @Component annotation is a stereotype marker indicating that a class is a candidate for auto-detection. However, Spring will not scan the classpath or instantiate the bean on its own. A configuration class must explicitly declare the @ComponentScan annotation (or use @SpringBootApplication, which implicitly includes it) and specify the base packages to search. This instructs the IoC container to scan the defined packages, locate the @Component classes, and automatically register them as beans.

Why the Other Options Are Incorrect

A is incorrect: Specifying an explicit bean name inside @Component("myBean") is optional. If left blank, Spring's BeanNameGenerator automatically derives a valid default name using the uncapitalized non-qualified class name.

C is incorrect: Explicitly declaring a @Scope is unnecessary. If omitted, Spring automatically assigns the default singleton scope to the auto-detected bean.

D is incorrect: The @Bean annotation is used inside @Configuration classes for explicit, manual bean registration. Combining @Component on a class with a separate @Bean factory method for that same class is redundant and incorrect for auto-detection.

References

Spring Framework Core Documentation: Section 1.10: Classpath Scanning and Managed Components – States that classpath scanning requires @ComponentScan alongside stereotype annotations like @Component to discover and register beans.

Spring Framework Core Documentation: Section 1.10.3: Automatically Detecting Classes and Registering Bean Definitions – Details how @ComponentScan triggers the parsing of components within specified packages.

Explanation:

Custom Storage (Option C):
Spring Security allows complete decoupling from any specific storage medium. By creating a custom class that implements the UserDetailsService interface and overriding its single loadUserByUsername(String username) method, developers can retrieve user authentication details from any proprietary system, external API, or non-relational database.

Built-In Providers (Option D):
Out of the box, Spring Security provides native implementations for common credential stores. These include InMemoryUserDetailsManager (for testing/simple apps), JdbcDaoImpl (for relational databases using SQL queries), and LDAP-backed storage engines.

Why the Other Options Are Incorrect

A is incorrect: Spring Boot's auto-configuration acts as a fallback. If it detects any custom bean that implements UserDetailsService or AuthenticationManager within the ApplicationContext, it backs off and will not generate the default, random auto-generated security password on startup.

B is incorrect: Modern versions of Spring Security mandate secure cryptographic hashing using a PasswordEncoder bean (such as BCryptPasswordEncoder). Insecure algorithms like MD5 are deprecated and not used by default.

E is incorrect: The standard UserDetails object contracts heavily require security authorities (roles/permissions). The interface includes the getAuthorities() method, and omitting them during user creation will fail runtime authorization checks.

References

Spring Security Reference Documentation: Section: Architecture - UserDetailsService – Explains how custom database or repository Lookups are implemented via UserDetailsService.

Spring Security Reference Documentation: Section: Authentication - Password Storage – Discusses the delegation of secure password hashing mechanisms (like BCrypt and Argon2) and the deprecation of legacy MD5 hashes.

Explanation:

Self-Contained Dependencies (Option C): A Spring Boot "fat" JAR (also known as an executable JAR) packages your application's compiled .class files along with all of its third-party library dependencies (nested inside the BOOT-INF/lib/ directory). This creates an autonomous, self-contained unit of deployment.

Build Plugins (Option E):
Standard Java tools do not natively support nesting library JARs inside another JAR. The specialized Spring Boot Maven Plugin or Spring Boot Gradle Plugin intercepts the normal build process to repackage the application, injecting Spring Boot's custom class loader required to read nested dependencies.

Why the Other Options Are Incorrect

A is incorrect: The executable "fat" JAR only contains compiled bytecode (.class files) and packaged resources. It does not contain the original Java source files (.java), as they are not needed for production execution.

B is incorrect: One of the main advantages of a "fat" JAR is that it does not require an external Servlet container (like standalone Tomcat or WildFly). It embeds the server runtime (Tomcat by default) directly inside the artifact.

D is incorrect:A standard Spring Boot executable archive is engineered to bootstrap and run exactly one embedded application server instance per execution lifecycle, not multiple.

References

Spring Boot Reference Guide: Section: Executable JARs – Explains the executable layout format, how nested dependencies are structured inside BOOT-INF/lib/, and how the archive launches.

Spring Boot Build Tool Plugins: Section: Spring Boot Maven/Gradle Plugin Documentation – Details how the repackage goal converts a standard archive into an executable "fat" JAR.

Explanation:

@AfterReturning Behavior (Option A): In Spring AOP, @AfterReturning advice is specifically designed to execute only after a matched method successfully completes its execution and returns a value without throwing any errors. It gives you access to the returned value (if needed) using the returning attribute within the annotation. If the target method encounters a runtime exception during execution, this advice is completely bypassed.

Why the Other Options Are Incorrect

B is incorrect: This describes the behavior of @After (After Finally) advice, which executes regardless of whether the method finishes successfully or exits abruptly with an exception.

C is incorrect: This describes @Around advice. @Around advice wraps the entire method invocation and uses a ProceedingJoinPoint object to manually control when—and if—the target method is executed.

D is incorrect: The @AfterReturning advice cannot intercept or swallow exceptions because it never triggers if an exception occurs. Catching and suppressing exceptions from propagating up the call stack can only be achieved using @Around advice.

References

Spring Framework Core Documentation: Section 5.4.3: Declaring Advice - After Returning Advice – Confirms that @AfterReturning advice runs only when a matched method execution returns normally.

Spring Framework Core Documentation: Section 5.2.1: AOP Concepts – Distinguishes the specific execution lifecycle triggers for @After, @AfterReturning, and @Around advice types.