How would you instrument CI/CD to measure a DORA metric accurately?

WHAT THIS TESTS: This question tests whether you understand that DORA metrics are operational definitions, not dashboard fantasies. The interviewer wants to see if you can decompose an abstract metric like Change Failure Rate into discrete events that a CI/CD system can actually emit, and whether you understand data integrity problems like duplicate events, clock skew, and semantic ambiguity. Senior candidates should demonstrate that they have shipped measurement systems, not just read about them.

A GOOD ANSWER COVERS: First, pick a single metric and define it precisely. For Change Failure Rate, define it as the percentage of production deployments that cause an incident requiring remediation. Second, identify the two event streams you need: deployment events and incident events. Third, explain the instrumentation mechanism, such as emitting a structured deployment event from your CD pipeline when a canary reaches 100 percent traffic, and emitting an incident event from your paging system when a Severity-1 is triggered. Fourth, explain correlation logic, such as attributing an incident to the most recent deployment if it starts within one hour and affects the same service. Fifth, mention data quality guards, like deduplicating retries in your event handler and excluding rollbacks from the numerator but including them in the denominator.

COMMON WRONG ANSWERS: Treating every Git push or pull request merge as a deployment. Measuring Lead Time for Changes from ticket creation rather than commit merge. Using build failure counts in the Change Failure Rate numerator, which actually measures build reliability, not production stability. Proposing to poll GitHub instead of using event-driven webhooks, which introduces lag and misses events. Suggesting manual spreadsheets or surveys instead of automated pipeline instrumentation.

LIKELY FOLLOW-UPS: How do you handle deployments that are rolled back automatically by a canary analysis tool before they reach full traffic? How do you compare a monorepo with hundreds of services against a polyrepo when calculating deployment frequency? What happens if your incident management tool and deployment tool disagree on timestamps due to timezone or clock skew? How would you validate that your metric is actually predicting business outcomes?

ONE CONCRETE EXAMPLE: Imagine you choose Lead Time for Changes. You would instrument by capturing the merge commit timestamp from the GitHub push webhook payload when a PR lands in main. You capture the deployment timestamp from a custom event fired by ArgoCD when an Application sync succeeds and the new image tag matches the merge commit SHA. You store both events in a warehouse table keyed by commit SHA and service name. Lead time is calculated as deployment timestamp minus merge commit timestamp, filtered to the first successful deployment of that commit to production. You exclude hotfix branches and filter out commits that only change documentation by checking file paths in the webhook payload.