A strong answer
I would identify the exact source revision and build an immutable artifact with traceable inputs. Before deployment, I would run tests appropriate to the change and verify observability and rollback procedures. For a high-risk change, I would expose it gradually using a canary or another controlled rollout strategy.
Promotion criteria should use user impact: error rate, latency distribution, saturation, and relevant business outcomes. If a guardrail fails, stop promotion and roll back or disable the feature. A feature flag can reduce exposure but is not a substitute for a safe data contract.
I would check database changes for compatibility across old and new application versions. An expand-and-contract migration can let both versions run during a rollout, but the exact sequence depends on the schema and workload. Rollback of a binary does not reverse external side effects or data transformations automatically.
Follow-up direction
Describe the evidence you would preserve after a failed release and how you would distinguish a release regression from an unrelated incident.