Cloud Architecture

Virtualization technology that abstracts physical hardware into multiple isolated virtual instances is the correct answer.

Virtualization is the foundational technology that enables public cloud providers to offer elastic resource allocation. This technology creates a layer of abstraction between physical hardware and the computing resources delivered to customers. Through hypervisors, a single physical server can host multiple virtual machines (VMs), each with its own allocated CPU, memory, and storage resources.

This abstraction is what makes elasticity possible because:
- Resources can be dynamically allocated and deallocated to virtual instances
- Multiple tenants can share the same physical infrastructure while remaining isolated
- Workloads can be moved between physical hosts for load balancing
- New virtual instances can be provisioned rapidly from available physical capacity

The other options, while important cloud technologies, are not the fundamental enabler of elastic resource allocation:

Distributed storage systems provide data redundancy and improved performance through replication, but they address data availability and durability rather than the core mechanism for scaling compute resources up and down.

Containerization platforms are valuable for application portability and efficient resource usage, but containers themselves run on top of virtualized or physical infrastructure. Containerization is a higher-level abstraction that depends on the underlying virtualization or host operating system.

Software-defined networking enables flexible network configuration and management, but it addresses network connectivity and segmentation rather than the fundamental ability to create and scale computing resources on demand.

The least connections algorithm is the most appropriate choice for this scenario.

In a microservices architecture where backend services have varying processing times, the least connections algorithm dynamically routes incoming requests to the server with the fewest active connections at any given moment. This approach naturally accounts for services that take longer to process requests - those slower services will accumulate connections and receive fewer new requests, while faster services that complete requests quickly will have their connection counts drop and receive more traffic.

This creates a self-balancing effect that prevents slower services from becoming overwhelmed while ensuring faster services are properly utilized.

The round-robin algorithm distributes requests sequentially and evenly across all servers, treating each request identically. This approach does not consider processing time differences, meaning slower services would receive the same number of requests as faster ones, leading to the exact problem described - slower services becoming overwhelmed.

The weighted least connections algorithm with equal weights would function essentially the same as regular least connections. The weighted version is typically used when servers have different capacities, and assigning equal weights defeats the purpose of using the weighted variant.

The IP hash algorithm provides session persistence by routing requests from the same client IP to the same backend server. This is useful for maintaining session state but does nothing to address the varying processing times of different services - it would still potentially overwhelm slower services if many clients happen to be hashed to them.

The correct answer is enabling sticky sessions to bind client requests to the same backend server using cookies or source IP.

Sticky sessions (also known as session affinity or session persistence) solve the exact problem described in this scenario. When users authenticate to a web application, their session data is typically stored on the specific backend server that handled the login. If subsequent requests are routed to different servers, those servers don't have the session information, causing the user to appear logged out.

Sticky sessions work by identifying the client (through cookies, source IP address, or other identifiers) and ensuring all requests from that client are consistently routed to the same backend server for the duration of their session. This maintains session state and prevents random logouts.

The other options do not address the core issue:

• Health check intervals verify that backend servers are operational and responding correctly. While important for overall system reliability, health checks do not control which server handles a specific user's requests. They only remove unhealthy servers from the pool.

• Weighted distribution controls how traffic is proportionally divided among servers based on their capacity. It determines the percentage of new connections each server receives but does not ensure the same user consistently reaches the same server.

• Connection draining is used during server maintenance or decommissioning to allow existing connections to complete before removing a server from the pool. This prevents abrupt disconnections during planned changes but does not address the ongoing issue of requests being randomly distributed across servers during normal operation.