Search the practice set
275 questions, 991 terms and 600 topics in 30 areas.
60 results for “Delivery & Release Engineering”
Pipeline Stage Contract
What each pipeline stage promises the next — an artifact of a stated shape plus a specific claim about it that has been verified.
Release Ring
An ordered cohort of users a change reaches before the next one, chosen so that early rings would notice a fault and tolerate it.
At-Least-Once Delivery
The guarantee that a message will be delivered, possibly more than once — the practical default in every distributed messaging system.
Automated Release Verification
A gate that compares the new version's live signals against the old one's and decides, on stated criteria, whether to continue or revert.
Best Effort Delivery
The guarantee push notification services actually offer — which is none — and the design consequences of building on a channel that may silently drop.
Canary Release
Routing a small fraction of traffic to a new version, watching its metrics, and expanding or rolling back based on what they show.
Chaos Engineering
Deliberately injecting failure into a system to discover, before an incident does, which of your resilience assumptions are false.
Content Delivery Network
A geographically distributed cache that serves content from a location near the user instead of from the origin.
Delivery vs Maintainability
Choosing where to take deliberate shortcuts, based on which kinds of debt are cheap to repay and which compound.
Fan-Out Delivery
Delivering one published message to many independent subscribers, each with its own copy, position and failure handling.
Delivery leadership says releases are too slow and wants the engineering team to "move faster". Lead time from commit to production is 21 days. How do you investigate, and what do you expect to find?
Do not accept the framing "Move faster" assumes the constraint is how fast code is written. That is almost never where the twenty one days went, and starting an
A release must rename a heavily used database column and ships tonight. The team proposes doing the rename in the deployment. What is wrong, and what do you propose?
What is wrong A rename is not additive. During a rolling deployment both versions of the application run simultaneously: one expects the old name, one the new.
Production is degraded after a release. The team tries to roll back and discovers a migration has already run. What do you do now, and what do you change afterwards?
Now: stop trying to roll back Reverting the deployment would run the previous code against a schema it does not know, which is a second and less understood fail
Delivery feels slow and leadership wants a productivity initiative. You propose mapping the value stream first. What will you map and what do you expect to find?
Map every step from request to delivered change, with two numbers each Work time — how long the step actually takes when someone is doing it. Wait time — how lo
Design a webhook delivery system for a platform with 10,000 customers. What are the hard parts?
Delivery, and its failure modes Persist the event first, deliver asynchronously. Delivery in the request path couples your latency and availability to every cus
Engineering says the codebase is full of technical debt. The business hears "we want to stop delivering and tidy up". How do you reframe it?
The word is the problem "Technical debt" means nothing to a business audience, and where it means something it sounds like tidying. It also covers three genuine
Finance wants a three-year commitment on cloud spend for the discount. Engineering is nervous. How do you advise?
Commit to the floor, not to the forecast The safe commitment is the portion of usage that will exist regardless of what happens: the steady baseline, evidenced
Leadership asks for "five nines" across the platform. Engineering says it is impossible. Design the response.
Reframe the request "Five nines" is almost never what the business actually wants. 26 seconds of downtime per month is a number chosen for its rhetorical weight
Partner integrations take four months from contract signature to production traffic. Engineering says the work is three days. Where does the time go and how do you cut it?
Map the elapsed time honestly The engineering estimate is correct and irrelevant. The four months are: Legal and contractual review. Security questionnaires and
Security requires default-deny egress across the estate. Engineering says it will cause constant outages. How do you deliver it?
Why security is right Inbound is default deny nearly everywhere. Outbound is usually wide open, on the reasoning that traffic originating inside is trusted. Tha
You have designed a system. Explain the same architecture to a CEO, an engineering manager and an engineer. What changes?
What the interviewer is testing Whether you can adapt to an audience, which is the skill that most often separates a senior engineer from an architect. It is al
You have to present the same architecture to the board on Tuesday and to the engineering teams on Wednesday. How do the two differ?
They are different artifacts, not the same one with different notes The common mistake is one deck with the technical slides skipped for the board. The board no
You inherit an enterprise architecture function that delivery teams route around and executives consider overhead. What do you change?
Diagnose the two failures separately Teams route around it because it is a queue that adds latency without adding value — decisions made by people distant from
You must get approval for a costly architectural change from a board that includes the CFO, the CISO and two engineering leads who disagree with your approach. How do you prepare?
Do the work before the meeting The meeting is where a decision is confirmed, not where it is made. Preparation is most of the outcome. Map the stakeholders by p
You need to ship a rewrite of the pricing engine. Same inputs, same expected outputs, completely new implementation. How do you release it?
What the interviewer is testing Whether you know that release strategy is part of architecture, and whether you reach for verification techniques beyond "test i
A codebase has 340 feature flags, most of them permanently on. What is the problem and how do you fix it?
The problem is combinatorial and it is not theoretical Every flag doubles the number of possible code paths. At 340, the number of configurations is unbounded a
A front-end lead proposes micro-frontends so four teams can deploy independently. The application is a single React SPA. What is your assessment?
Test the premise first The stated goal is independent deployment. Ask what currently prevents it, because the answer is frequently not the architecture. If the
Delivery & Release Engineering
General material on getting a change from commit to production safely and often.
Progressive Delivery
Separating deploy from release, and exposing a change to users in controlled increments.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Artifact Management
Immutable versioned outputs, promotion between repositories, and retention policy.
Branching Models
GitFlow, trunk and release branches as delivery constraints rather than Git preferences.
Build Reproducibility
Pinned inputs and hermetic builds, so one commit cannot produce two different artifacts.
Change Management vs CD
Reconciling CAB-era controls with continuous delivery without pretending either away.
Continuous Integration Discipline
Integrating to the mainline daily, and the test speed and review culture that requires.
Database Migration Under CD
Expand-contract, backwards-compatible schema change, and migrations that cannot roll back.
Deployment Gates
Automated verification between stages, and the difference between a gate and a delay.
Deployment Strategies
Rolling, blue-green, canary and shadow, and the traffic and state each one assumes.
Environment Strategy
How many environments earn their cost, what each proves, and what none of them prove.
Flow Metrics
Work in progress, flow time and flow efficiency — where a change waits rather than moves.
GitOps
Declared desired state in version control, with a reconciler closing the gap continuously.
IaC Modules & Drift
Reusable infrastructure modules, state ownership, and detecting what changed out of band.
Multi-Region Rollout
Ordering regions, bake time, and stopping a bad change before it becomes global.
Pipeline Architecture
Stages, fan-out, caching, and the difference between a pipeline and a long script.
Pipeline Secrets
Short-lived credentials, workload identity, and why the CI system is a prime target.
Policy as Code
Encoding standards as automated admission and plan-time checks instead of review comments.
Rollback & Forward Fix
When reversing is genuinely possible, and designing so that it usually is.
Supply-Chain Provenance
SBOMs, signed artifacts, attestation, and knowing what actually went into a build.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Feature Flags
Decoupling deploy from release, with an expiry date.
Chaos Engineering
Hypothesis-driven failure injection with a bounded blast radius.
Content Delivery Networks
Edge caching, origin offload, spike absorption and dynamic content.
Delivery vs Maintainability
Fast in the cheap places, careful in the expensive ones.
Mobile Release Strategy
Store review, staged rollout, and supporting versions you can never force off.
Platform Engineering
General material on internal platforms as products with users, adoption and lifecycles.
Privacy Engineering
Minimisation, purpose limitation, and erasure that is implementable.
Delivery & Release Engineering
How code becomes a running change in production, and what stops that path being frightening.
Performance & Capacity Engineering
If traffic becomes ten times larger, what breaks first?
Platform Engineering & Developer Experience
Building the product other engineers build on, and being judged on whether they use it.
Software Architecture & Engineering
Enough engineering depth to know whether the architecture is implementable.