Master the terminology behind deploying features invisibly before exposing them to users.
0 / 5 completed
1 / 5
At standup, a dev describes deploying a new feature to production but keeping it invisible to users until it's ready to enable. What is this practice called?
A dark launch deploys new code to production while keeping the feature hidden or inactive for users, allowing the team to validate deployment mechanics and performance under real infrastructure before exposing it. This separates the risk of deploying code from the risk of exposing a feature. It is a common precursor to a gradual rollout.
2 / 5
During a design review, the team wants to verify the new backend logic performs correctly under real load before any UI exposes it. Which dark-launch technique fits?
Dark launching lets a team exercise new backend logic under real production load and data silently, without any user-visible entry point yet, surfacing performance or correctness issues in a realistic environment. This reduces surprises when the feature is later exposed. It complements, but differs from, purely synthetic pre-production testing.
3 / 5
In a code review, a dev gates a dark-launched feature behind a mechanism that can later reveal it gradually to users. Which mechanism fits?
A feature flag is the typical mechanism used to keep a dark-launched feature hidden initially and later reveal it gradually or fully once validated. Without a flag, exposing the feature would require another code deployment. Flags decouple the deploy event from the release/exposure event.
4 / 5
An incident report shows a dark-launched code path caused unexpected load on a shared database even though no users could see the feature. What does this reveal?
Even though a dark-launched feature is invisible to users, its underlying code still runs and can consume real infrastructure resources, such as database load, that affect other services sharing that infrastructure. Dark launching reduces user-facing risk but doesn't eliminate operational risk. Monitoring resource impact during a dark launch is still necessary.
5 / 5
During a PR review, a teammate asks how a dark launch differs from a canary release. What is the distinction?
A dark launch deploys code while keeping the feature hidden from all users, focused on validating infrastructure and performance, whereas a canary release deliberately exposes the feature to a small subset of real users to validate actual user-facing behavior. Teams often dark launch first, then canary, as sequential steps in a cautious rollout. The two techniques address different layers of risk.