Six teams share one staging environment. Booking it is a bottleneck and it is permanently broken by whoever deployed last. Design a way out.

What the interviewer is testing

Whether you attack the queue or eliminate it, and whether you have thought about the data problem that determines whether the answer is affordable.

The diagnosis

A shared long-lived environment has two structural problems that no amount of process fixes. It is a contended resource, so its wait time grows with the number of teams. And it accumulates state and drift, so its condition is a function of everything anyone has done to it, which makes a test result uninterpretable.

Improving the booking system optimises a model that does not scale.

The design

Ephemeral per-branch environments, created from infrastructure code when a pull request opens and destroyed on merge. No contention, no drift, and the environment is built from the same code as production rather than having diverged for three years.

Two problems decide feasibility:

Data. An environment with no realistic data proves nothing; one with a copy of production has multiplied the compliance surface. The answer is generated or masked datasets with production-like cardinality and distribution, seeded automatically. This is the work item that usually blocks the whole idea and should be planned first.

Cost. Dozens of full-stack environments are only affordable if they scale to zero when idle and are destroyed reliably. A leaked environment nobody deletes is where the budget goes, so a hard TTL with automatic teardown is mandatory rather than a refinement.

For large systems, spin up only the services under change and bind the rest to a shared dependency tier or virtualised contracts, or the per-environment cost and startup time become prohibitive.

What remains shared

Keep one production-like environment for the things that genuinely need it — a full performance test at scale, a disaster recovery rehearsal, partner integration testing against real third parties. That environment is now used for a defined purpose on a schedule rather than being a queue.

What a strong answer adds

Pairing this with progressive delivery: once ephemeral environments handle functional verification, the remaining production risk is best managed by canary and flags rather than by another static tier. And measuring the outcome — time from pull request to verified — rather than declaring victory on having built it.

Common weak answers

More staging environments, which multiplies the drift problem. A stricter booking process, which optimises the bottleneck instead of removing it.