Design a CI/CD pipeline for ephemeral feature branch environments

WHAT THIS TESTS: The interviewer wants to see if you can model ephemeral infrastructure as a first-class CI/CD concern rather than an afterthought. They care about the full lifecycle: provisioning, routing, monitoring, and guaranteed cleanup. This separates seniors who think in systems from those who only know how to deploy to static targets.

A GOOD ANSWER COVERS: First, trigger logic: pipelines should fire on feature branch pushes and use dynamic environment names like review-$CI_COMMIT_REF_SLUG so each branch gets an isolated namespace. Second, provisioning: use infrastructure as code in the pipeline to spin up containers, databases, or namespaces, injecting branch-specific variables and secrets. Third, routing: expose the environment via a predictable URL pattern so QA and product can access it, optionally using path-based or subdomain routing. Fourth, de-provisioning: implement automatic cleanup using on_stop jobs or pipeline rules that destroy resources when branches are merged or deleted, plus TTL policies to catch abandoned branches. Fifth, guardrails: cost controls, resource quotas, and environment-specific secrets rotation so ephemeral environments do not become security debt or budget drains.

COMMON WRONG ANSWERS: Proposing manual teardown tickets or expecting developers to clean up their own branches. Suggesting a permanent environment per branch that accumulates over time. Ignoring database state or shared storage cleanup, which leads to cross-contamination between branches. Failing to address secret rotation or using production credentials in ephemeral environments. Overlooking URL routing and forcing testers to look up IP addresses manually.

LIKELY FOLLOW-UPS: How do you handle long-lived feature branches that accumulate cost? What happens if the stop job fails and resources leak? How do you manage database migrations or seed data for ephemeral environments? How would you route traffic if you have hundreds of active review apps? How do you prevent ephemeral environments from accessing production services?

ONE CONCRETE EXAMPLE: In GitLab, you define a deploy_review_app job with environment name set to review/CI_COMMIT_REF_SLUG and url set to https://CI_ENVIRONMENT_SLUG.example.com, plus an on_stop keyword pointing to a teardown job. The stop_review_app job sets environment action to stop and can use when manual for optional cleanup or run automatically on branch deletion. It executes terraform destroy or kubectl delete namespace. You add a weekly scheduled pipeline that finds environments older than three days and force-stops them to prevent cost leakage.