TL;DR: Base the release decision on the change, its recovery path and available support. Recommend a bounded deployment only when the required evidence and authorization hold; otherwise propose a specific way to meet or revise the customer commitment.
How to approach it
Clarify what must be delivered tonight and whether the request concerns a demonstration or production use. Ask what changed since the last successful rehearsal. Explain the decision you would make under the stated facts before listing exceptional cases.
A strong answer
Start with the actual release. A configuration change can still affect every request or expose sensitive data, while a database change may have been carefully rehearsed and designed for mixed versions. Size and reversibility require evidence about behavior, not a label such as “config-only.”
Check who is available to detect and respond to failure. On a distributed services team, Friday evening in one location may overlap another team's working day. Confirm a named handoff and that team's ability to operate the affected service; a person being online does not establish access, context or authority to recover it.
Consider a fictional exercise. A customer needs address validation enabled for a named pilot group. The exact artifact passed its acceptance checks, the flag is restricted to that group, and a rehearsal showed that disabling it restores the previous request path without changing persisted data. The application owner and on-call responder can observe the pilot and execute the agreed recovery. Under those assumptions, a limited release can be defensible.
State the observation rule before exposure grows. Check the pilot's valid and invalid address cases, errors and latency against its baseline. Include a correctness check because HTTP success does not prove the returned address is right. A fixed thirty-minute wait is insufficient if the relevant behavior receives no traffic during that period. Choose duration and sample coverage based on the failure you need to detect, then retain support for delayed effects.
The conversation could be: “I can enable the rehearsed version for the agreed pilot tonight. The service owner will check those requests and the responder owns disabling the flag if validation or latency fails its release threshold. We will keep wider exposure off until those checks complete.” Replace the exercise conditions with the facts you can verify.
Now change one condition: enabling the feature also rewrites stored addresses, and the reverse migration has never been rehearsed. Turning the flag off no longer restores the data. Recommend holding that production change. Offer a demonstration using approved test data if it meets the customer's purpose, or a new slot after a recovery rehearsal and support handoff. Describe the proposed slot as conditional on those checks, not as a guaranteed Monday release.
What interviewers probe next
“Your manager insists.” Restate the specific missing evidence and involve the authorized release or risk owner. An accepted, permitted tradeoff can proceed with its controls; a manager's insistence does not itself satisfy a mandatory freeze or access rule.
“Would you ever deploy without rollback?” Explain the forward-recovery method, its rehearsal and the acceptable exposure before making that recommendation. A risky reverse migration may be worse than forward recovery, but having neither plan is an unresolved release risk.
“What goes in the handoff?” Record the artifact and configuration, exposed cohort, current checks, recovery action and responder. Include the next decision time and any temporary override that must expire.
Common mistakes
Treating the calendar as the only risk factor leaves the same weak process available on Tuesday. Explain the recovery and coverage facts that determine your call.
A flag or small traffic percentage does not automatically contain shared database effects. Trace the changed state before promising a bounded impact.
Rehearse the conversation twice: once with the pilot's verified recovery and once with the unrehearsed data rewrite. Your recommendation should change for an explicit reason.