Answer : B
Explanation: REST (Representational State Transfer) uses HTTP methods to perform CRUD operations on resources: GET — Read (retrieve resource), POST — Create (new resource), PUT — Update (replace resource), PATCH — Update (partial update), DELETE — Remove resource. REST principles: Stateless (each request is self-contained), Client-Server, Uniform Interface, Cacheable. Spring Boot REST implementation: @RestController combines @Controller + @ResponseBody — all method return values are automatically serialized to JSON (using Jackson). Example: @GetMapping(“/users/{id}”) returns a User object → Jackson serializes to JSON automatically. HTTP status codes: 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error. ResponseEntity<T> provides fine-grained control over status code and headers. @RequestBody deserializes incoming JSON to Java objects. Spring Boot auto-configures Jackson (JSON library) when spring-boot-starter-web is on the classpath. REST APIs are the dominant pattern for modern web application backend development.

Answer : B
Explanation: Spring Data JPA eliminates the need to write implementation code for common data access operations. Core interface: JpaRepository<T, ID> provides: save(), findById(), findAll(), deleteById(), count(), existsById(). Query derivation: Spring generates queries from method names automatically. findByEmailAndActive(String email, boolean active) → generates SELECT * FROM users WHERE email=? AND active=?. findByAgeGreaterThan(int age) → SELECT * FROM users WHERE age > ?. Custom JPQL queries: @Query(“SELECT u FROM User u WHERE u.status = :status”) List<User> findByStatus(@Param(“status”) String status). Pagination: PagingAndSortingRepository — findAll(Pageable pageable) returns Page<T> with content, total pages, current page info. Sorting: findAll(Sort.by(“lastName”).ascending()). Transactions: @Transactional annotation at service layer. Spring Data repositories are interfaces — no implementation needed. Spring generates the implementation at runtime. This reduces hundreds of lines of DAO boilerplate to just a few method declarations. Used with Hibernate as the JPA provider.

Answer : B
Explanation: Hibernate (ORM Framework) advantages over plain JDBC: No manual SQL: instead of writing INSERT INTO users VALUES(?,?,?), just session.save(user). Object-Relational Mapping: @Entity, @Table, @Column annotations map classes to tables automatically. HQL (Hibernate Query Language): object-oriented query language — “FROM User WHERE age > 18” instead of table-name SQL. Automatic DDL: hibernate.hbm2ddl.auto=update creates/updates tables from entity classes. Caching: First-level cache (Session level — automatic), Second-level cache (SessionFactory level — optional, using EHCache, Redis). Lazy Loading: @OneToMany(fetch=FetchType.LAZY) — related objects loaded only when accessed. Connection Pooling: built-in via C3P0, HikariCP. Transaction Management: session.beginTransaction() / transaction.commit(). Portability: change database just by changing the dialect (MySQL5Dialect → PostgreSQLDialect). When to use plain JDBC: complex, highly optimized queries, batch processing with millions of rows, scenarios where Hibernate’s overhead is unacceptable. In practice: Hibernate via Spring Data JPA is the default choice for most enterprise Java applications.

Answer : B
Explanation: Understanding Hibernate entity states is crucial for effective ORM usage: Transient: object created with new but not associated with any Hibernate Session and not in the database. Example: User user = new User(“John”). No ID assigned by Hibernate. Not tracked for changes. Persistent: object is associated with an open Hibernate Session and has a database record. Hibernate tracks all changes (dirty checking) — any modifications are automatically saved on session.flush() or transaction.commit(). Obtained via: session.save(), session.get(), session.load(), Query results. Detached: was previously persistent but the Session was closed or the object was evicted. Has a database record and an ID but Hibernate is NOT tracking changes. Can be reattached using session.update() or session.merge(). Removed (Deleted): object scheduled for deletion from the database. session.delete(entity) transitions to Removed. Deleted on flush/commit. State transitions: Transient → Persistent (save/persist), Persistent → Detached (session close), Detached → Persistent (update/merge), Persistent → Removed (delete). Understanding these states prevents common bugs like updating a detached entity without reattaching it.

Answer : B
Explanation: This is a commonly tested Hibernate distinction: session.get(): immediately hits the database (or first-level cache). Returns the actual entity object. Returns null if the entity with the given ID does not exist. Safe to use when you are not sure the entity exists. Example: User user = session.get(User.class, 1L); // null if not found. session.load(): returns a proxy object immediately (lazy loading) — does NOT hit the database right away. The proxy is a subclass of the entity class generated by Hibernate. Database is only hit when you access a property of the proxy. If the entity does not exist in the database, throws ObjectNotFoundException when the proxy is initialized. Use when you are sure the entity exists (e.g., setting a foreign key reference). Example: User user = session.load(User.class, 1L); // returns proxy. When to use each: get() — when you need the entity’s data immediately and it may not exist. load() — when you need a reference for setting a foreign key and you know the entity exists (saves a database round trip if you never access the data). In Spring Data JPA: findById() corresponds to get() behavior; getById()/getOne() corresponds to load() behavior.

Answer : B
Explanation: The N+1 Problem is the most common Hibernate performance issue. Example: fetching 10 Orders, each with lazy-loaded OrderItems. 1 query: SELECT * FROM orders (returns 10 orders). 10 queries: SELECT * FROM order_items WHERE order_id = ? (one for each order). Total: 11 queries (1+N) instead of the optimal 1-2. Solutions: JOIN FETCH in JPQL: @Query(“SELECT o FROM Order o JOIN FETCH o.orderItems”). Fetches orders and items in one SQL JOIN query. @EntityGraph: @EntityGraph(attributePaths = {“orderItems”}) on repository method — tells JPA to eagerly load specified associations. @BatchSize: @OneToMany @BatchSize(size=10) — loads child collections in batches of 10 using IN clause (10 queries → 2 queries for 10 orders). @Fetch(FetchMode.SUBSELECT): loads all children in one subselect query. DTO Projections: select only needed fields using JPQL constructor expressions or Spring Data Projections — avoids loading full entity graphs. Best practice: use LAZY loading as default, apply JOIN FETCH or EntityGraph only when you know you’ll need the association. Tools like Hibernate Statistics or p6spy help detect N+1 issues.

Answer : B
Explanation: Spring Security is the de-facto standard for securing Spring applications. Core concepts: Authentication: verifying identity. Supports: form login, HTTP Basic, OAuth2, SAML, LDAP, JWT. AuthenticationManager — processes authentication requests. UserDetailsService — loads user details from database. Authorization: controlling access. Method-level: @PreAuthorize(“hasRole(‘ADMIN’)”), @Secured(“ROLE_ADMIN”). URL-based: http.authorizeRequests().antMatchers(“/admin/**”).hasRole(“ADMIN”). Security Filter Chain: Spring Security is implemented as a chain of servlet filters. Every request passes through these filters (authentication, authorization, CSRF check). Common filters: UsernamePasswordAuthenticationFilter, JwtAuthenticationFilter (custom), BasicAuthenticationFilter. SecurityContext: stores the current authenticated user (Authentication object) — accessible via SecurityContextHolder.getContext().getAuthentication(). CSRF Protection: prevents cross-site request forgery — enabled by default for state-changing requests. Stateless REST APIs typically disable CSRF (using JWT tokens instead). JWT (JSON Web Token): for stateless REST authentication — validate token on each request without server-side session. Spring Boot auto-configures basic security when spring-boot-starter-security is on the classpath.

Answer : B
Explanation: AOP addresses the “cross-cutting concerns” problem — functionality needed across many components (logging every service method, applying @Transactional, checking security). Without AOP: you’d add the same logging/transaction code to every method. With AOP: define the behavior once, Spring applies it automatically. Key AOP concepts: Aspect: a class containing cross-cutting logic. @Aspect annotation. Advice: the action to take. Types: @Before (runs before method), @After (runs after), @AfterReturning (after successful return), @AfterThrowing (after exception), @Around (wraps method, most powerful). Join Point: the point in program execution where an aspect can be applied (method call). Pointcut: expression defining WHICH join points to apply advice to. Example: @Pointcut(“execution(* com.example.service.*.*(..))” — all methods in service package. Weaving: applying aspects to target objects — Spring AOP uses runtime proxies (JDK dynamic proxy or CGLIB). Example use: @Transactional works through Spring AOP — the transaction advice wraps the method. @Around for logging: log method name, parameters, execution time, return value. Custom security checks: verify user has correct role before method executes. AOP reduces code duplication and keeps business methods clean.

Answer : B
Explanation: @Transactional replaces manual transaction management (session.beginTransaction() / transaction.commit() / transaction.rollback()). How it works (Spring AOP): when a @Transactional method is called, Spring’s proxy intercepts the call, begins a transaction, calls the actual method, and commits (success) or rolls back (RuntimeException). Important behaviors: Rollback rules: by default, rolls back on RuntimeException and Error, but NOT on checked exceptions. Override: @Transactional(rollbackFor = Exception.class). Propagation: @Transactional(propagation = Propagation.REQUIRED) — default: joins existing transaction or creates new one. Propagation.REQUIRES_NEW — always creates a new transaction. Propagation.NESTED — nested transaction. Read-Only: @Transactional(readOnly = true) — optimizes read-only operations. Timeout: @Transactional(timeout = 30). Isolation levels: controls concurrent access. Self-invocation problem: calling a @Transactional method from within the same class bypasses the proxy — the transaction doesn’t apply. Solution: inject the bean and call through the proxy, or use AopContext.currentProxy(). Best practice: put @Transactional on service methods, not repository methods or controller methods.

Answer : B
Explanation: Both extract request data but from different parts of the URL: @PathVariable: extracts values from URI template variables enclosed in {}. The value is part of the URL path itself. Example: @GetMapping(“/users/{id}”) + @PathVariable Long id — URL: /users/123 → id = 123. REST API convention: use for resource identifiers (e.g., /products/456, /orders/789). Multiple path variables: /users/{userId}/orders/{orderId}. @RequestParam: extracts query string parameters (after ? in URL). Example: @GetMapping(“/users”) + @RequestParam String name — URL: /users?name=John → name = “John”. Required by default — missing parameter causes 400 Bad Request. Make optional: @RequestParam(required = false) or @RequestParam Optional<String> name. Default values: @RequestParam(defaultValue = “0”) int page. Multiple values: /search?tags=java&tags=spring → @RequestParam List<String> tags. REST conventions: @PathVariable for resource identification (/users/{id}), @RequestParam for filtering/pagination (/users?status=active&page=0&size=20). @RequestBody is a third option — for JSON in request body (POST/PUT requests).