▸case-01 We are updating our production service on AWS using two ALB target groups (tg-blue and tg-green). Currently 100% of production traffic goes to tg-blue via an ALB listener rule. We have deployed version 2.0 to tg-green and verified green health. A junior engineer suggests modifying the CNAME record of our public domain to point to a new ALB instance created for green. Explain the standard AWS ALB mechanism for switching traffic to tg-green without DNS TTL delays or creating second ALB resources. | pass→pass | 10,448 | 10,824 | +4% | 1 | 1 | 0% | 2,001 | 2,051 | +2% | 0 | 0 | — |
▸case-02 We are releasing a breaking database change (renaming column user_phone to phone_number) as part of a blue/green deployment switch on a PostgreSQL database. A developer proposes running 'ALTER TABLE users RENAME COLUMN user_phone TO phone_number;' right before switching live traffic from Blue to Green. Explain why this breaks Blue and state the multi-phase pattern required to execute this safely. | pass→pass | 10,695 | 10,363 | -3% | 1 | 1 | 0% | 2,029 | 1,897 | -7% | 0 | 0 | — |
▸case-03 We have deployed our new Green environment behind an NGINX reverse proxy. Live traffic is currently routed to Blue. The QA team wants to run automated smoke tests against the Green nodes before switching the production upstream. A developer suggests opening public port 8080 on the Green application nodes directly to the internet for testing. Provide the standard NGINX / HTTP header approach to test Green through the existing load balancer without exposing internal ports. | pass→pass | 11,448 | 9,171 | -20% | 1 | 1 | 0% | 2,218 | 1,866 | -16% | 0 | 0 | — |
▸case-04 Our web application stores HTTP user session data in node local memory using the default express-session memory store. We are preparing to switch traffic from Blue to Green using a load balancer cutover. The lead developer assumes sticky sessions on the load balancer will seamlessly transition existing logged-in users to the Green nodes without data loss. Explain the flaw in this assumption and specify how session state must be handled. | pass→pass | 13,237 | 11,070 | -16% | 1 | 1 | 0% | 2,380 | 2,058 | -14% | 0 | 0 | — |
▸case-05 During a blue/green deployment cutover on AWS Target Groups, immediately after switching 100% weight to tg-green, an engineer recommends immediately terminating all EC2 instances in tg-blue to minimize AWS compute costs. What issue does this cause for inflight requests, and what setting prevents it? | pass→pass | 6,371 | 8,088 | +27% | 1 | 1 | 0% | 1,211 | 1,207 | -0% | 0 | 0 | — |
▸case-06 We run two separate Kubernetes Deployments in the same namespace: app-blue (running v1) and app-green (running v2). A single Kubernetes Service app-service routes traffic to app-blue using the selector 'version: v1'. What specific manifest edit changes app-service to immediately direct traffic to app-green? | pass→pass | 3,661 | 3,504 | -4% | 1 | 1 | 0% | 690 | 674 | -2% | 0 | 0 | — |
▸case-07 After switching production traffic to Green, our APM alerts indicate a spike in 500 error rates on the Green environment. A team member suggests running a git revert on the main repository and re-executing the full CI/CD build and container image publish pipeline. Explain why this approach is flawed for a blue/green strategy and state the correct rollback procedure. | pass→pass | 10,337 | 10,118 | -2% | 1 | 1 | 0% | 1,727 | 1,665 | -4% | 0 | 0 | — |
▸case-08 Our architecture includes a web tier and asynchronous background worker tier processing jobs from RabbitMQ. During a blue/green cutover, we launch worker-green connected to the same queue as worker-blue. worker-green consumes a message formatted with a new schema payload that worker-blue cannot parse. How should asynchronous worker deployments be ordered relative to DB and API schema updates in a blue/green deployment? | fail→fail | 15,292 | 13,290 | -13% | 1 | 1 | 0% | 2,586 | 2,327 | -10% | 0 | 0 | — |
▸case-09 Our legacy application writes user uploaded profile photos to the local filesystem path /var/www/uploads on application servers. We are migrating to a blue/green deployment model. A developer suggests using rsync post-cutover to sync uploaded photos from Blue instances to Green instances. What is the fundamental problem with this design and what storage solution should be used? | pass→pass | 11,159 | 9,216 | -17% | 1 | 1 | 0% | 1,981 | 1,602 | -19% | 0 | 0 | — |
▸case-10 A finance manager asks why cloud infrastructure costs increase during blue/green deployment windows, and suggests reducing the Green environment's node count to 10% capacity during traffic cutover to save money. Explain the operational risk of this cost-saving proposal during cutover. | pass→pass | 15,072 | 12,105 | -20% | 1 | 1 | 0% | 2,178 | 2,060 | -5% | 0 | 0 | — |
▸case-11 We have a PostgreSQL database configured with max_connections = 200. During a blue/green deployment cutover, both Blue (running 100 instance tasks with 2 pool connections each) and Green (running 100 instance tasks with 2 pool connections each) are active simultaneously. Application startup fails on Green with connection errors. What database connection management issue occurred and how should it be mitigated? | pass→pass | 9,889 | 8,796 | -11% | 1 | 1 | 0% | 1,855 | 1,797 | -3% | 0 | 0 | — |
▸case-12 An engineer is configuring a blue/green deployment architecture on AWS. They propose installing distinct Let's Encrypt TLS certificates and managing HTTPS handshake termination directly on individual EC2 application instances inside both Blue and Green target groups. Explain why this approach complicates blue/green cutover and where TLS should be terminated. | pass→pass | 14,843 | 14,752 | -1% | 1 | 1 | 0% | 2,483 | 2,535 | +2% | 0 | 0 | — |
▸case-13 During a blue/green deployment cutover, Datadog dashboard shows elevated HTTP 5xx errors across the system, but engineers cannot distinguish whether errors originate from the Blue stack or the Green stack. What logging and metrics configuration was missing from the deployment design? | pass→pass | 10,467 | 10,677 | +2% | 1 | 1 | 0% | 1,808 | 1,897 | +5% | 0 | 0 | — |
▸case-14 We are executing an expand-contract database migration pattern during a blue/green deployment. The migration includes dropping a deprecated database column legacy_token. At what exact phase in the blue/green deployment lifecycle is it safe to execute the ALTER TABLE ... DROP COLUMN script? | pass→pass | 9,451 | 9,453 | +0% | 1 | 1 | 0% | 1,688 | 1,613 | -4% | 0 | 0 | — |
▸case-15 A team plans to perform blue/green deployments by maintaining two separate public IP addresses (one for Blue stack, one for Green stack) and modifying the A record in AWS Route53 from Blue IP to Green IP with a 300-second TTL. Why is DNS-based cutover inadequate for instant zero-downtime blue/green deployment compared to load balancer weighted routing? | pass→pass | 11,712 | 12,153 | +4% | 1 | 1 | 0% | 1,982 | 2,133 | +8% | 0 | 0 | — |
▸case-16 We use NGINX as our primary reverse proxy for a blue/green deployment. We want to gradually split traffic 90% to Blue (10.0.1.10:8080) and 10% to Green (10.0.2.10:8080) before doing full cutover. Write the NGINX upstream block configuration snippet that achieves this 90/10 weight distribution. | pass→fail | 4,959 | 3,860 | -22% | 1 | 1 | 0% | 1,053 | 910 | -14% | 0 | 0 | — |
▸case-17 Before routing customer traffic to the Green environment, an automated CI/CD step must verify application readiness. A developer suggests using the standard shallow endpoint /health (which returns HTTP 200 if the web process is running). Why is a shallow health check insufficient for validating the Green environment before cutover, and what should be checked instead? | pass→pass | 11,993 | 10,648 | -11% | 1 | 1 | 0% | 1,972 | 1,916 | -3% | 0 | 0 | — |
▸case-18 Our blue/green deployment pipeline automatically deletes the AWS CloudFormation stack for the Blue environment 5 seconds after updating the load balancer listener rule to point to Green. What operational risk does this immediate stack deletion create? | pass→pass | 11,737 | 11,049 | -6% | 1 | 1 | 0% | 1,973 | 1,767 | -10% | 0 | 0 | — |
▸case-19 Our legacy web app uses load-balancer generated HTTP cookies for sticky sessions. During a blue/green cutover, we set tg-blue weight to 0 and tg-green weight to 100. However, existing active users continue hitting tg-blue for hours. What load balancer behavior causes this? | pass→pass | 10,722 | 8,942 | -17% | 1 | 1 | 0% | 1,897 | 1,528 | -19% | 0 | 0 | — |
▸case-20 We are configuring a Kubernetes Deployment for our microservice catalog-api. We do not have separate blue/green environments; instead, we want Kubernetes to perform an in-place rolling update where max 2 extra pods are created and max 0 pods are unavailable during the deployment. Write the relevant strategy block for the Deployment spec. | pass→pass | 3,432 | 3,919 | +14% | 1 | 1 | 0% | 609 | 598 | -2% | 0 | 0 | — |
▸case-21 We are implementing a progressive canary rollout using Istio VirtualService on Kubernetes. We want to split incoming HTTP traffic for host api.example.com between destination catalog-service subset v1 (90% weight) and subset v2 (10% weight). Write the Istio VirtualService spec. | pass→pass | 4,632 | 5,451 | +18% | 1 | 1 | 0% | 963 | 1,139 | +18% | 0 | 0 | — |
▸case-22 Write a Terraform HCL block to create an aws_vpc resource named main with a CIDR block of 10.0.0.0/16 and DNS hostnames enabled. | pass→pass | 1,819 | 1,953 | +7% | 1 | 1 | 0% | 403 | 429 | +6% | 0 | 0 | — |