DevOps Fundamentals

Blue/green deployment with traffic shifting set to all-at-once after validation completes is the correct answer.

This deployment strategy perfectly matches all the requirements stated in the question:

1. Complete second set of tasks: Blue/green deployments create an entirely new task set (green) alongside the existing one (blue), which satisfies the requirement to deploy a complete second set of tasks running the new code.

2. Internal validation: Blue/green deployments allow you to perform health checks and synthetic transactions on the new task set before any traffic is redirected to it.

3. Single operation traffic redirect: The all-at-once traffic shifting option redirects 100% of production traffic from the original task set to the new task set in one operation, exactly as specified in the question.

4. Quick reversion capability: The original task set remains running and available, allowing for rapid rollback if issues are discovered after the cutover.

The rolling deployment option is incorrect because it performs in-place updates by gradually replacing tasks rather than creating a complete parallel environment. This approach updates existing tasks incrementally and does not maintain two complete task sets simultaneously.

The canary deployment with linear traffic shifting is incorrect because it gradually increases traffic over time in linear increments rather than performing an all-at-once cutover after validation.

The blue/green deployment with canary intervals is incorrect because it uses gradual traffic shifting with incrementally increasing percentages before full cutover, rather than redirecting all traffic in a single operation after validation completes.

Shadow testing for validation followed by canary deployment for gradual traffic migration is the correct answer.

The scenario describes two distinct phases:

Phase 1 - Validation: The team needs to run both versions simultaneously where the old version handles ALL user traffic while the new version receives MIRRORED requests. This is the exact definition of shadow testing (also called traffic mirroring or dark launching). In shadow testing, production traffic is duplicated and sent to the new version for testing purposes, but responses from the new version are not returned to users. This allows real-world testing with zero risk to users.

Phase 2 - Traffic Shifting: After validation, they want to GRADUALLY shift real user traffic to the new version. Canary deployment is designed for exactly this purpose - it allows you to route a small percentage of traffic to the new version initially, then incrementally increase the percentage as confidence grows.

Why the other options are incorrect:

Blue-green deployment for validation followed by rolling update: Blue-green deployment does not mirror traffic - it involves running two identical production environments and switching traffic between them. It does not allow the old version to handle all traffic while the new version receives mirrored requests.

Canary deployment for validation followed by blue-green switching: Canary deployment sends a portion of real user traffic to the new version, not mirrored traffic. Users would actually receive responses from the new version during canary testing, which contradicts the requirement that the old version handles all user traffic during validation.

A/B testing with feature flags followed by canary deployment: A/B testing is used to compare different features or user experiences and involves real users interacting with different versions. It does not provide traffic mirroring where users only interact with the old version while the new version is tested in the background.

The Horizontal Pod Autoscaler (HPA) configured with CPU utilization thresholds is the correct answer for this scenario.

The Horizontal Pod Autoscaler is specifically designed to automatically scale the number of pod replicas in a deployment, replica set, or stateful set based on observed metrics such as CPU utilization. When CPU usage exceeds the configured threshold, HPA increases the number of pods to handle the increased load. Conversely, when CPU usage drops below the threshold, HPA reduces the number of pods to conserve resources. This matches exactly what the question describes - scaling pods up during high demand and down during low activity.

The Vertical Pod Autoscaler is incorrect because it adjusts the resource requests and limits (CPU and memory) for individual pods rather than changing the number of replicas. Additionally, the question specifically asks about CPU utilization, not memory.

The ReplicaSet controller with manual scaling policies does not provide automatic scaling capabilities. ReplicaSets maintain a specified number of pod replicas but require manual intervention or external automation to change that number. The question explicitly asks for an automatic solution.

The Cluster Autoscaler operates at a different level - it manages the number of nodes in the cluster, not the number of pods. While it does respond to resource demands, it adds or removes worker nodes from the cluster rather than adjusting pod replicas. This is useful when the cluster lacks capacity to schedule pods, but it doesn't address the specific requirement of scaling pod replicas based on CPU metrics.