Your KYC verification vendor is down for six hours. Customer onboarding stops. The board asks why a vendor outage became your outage.

What the interviewer is testing

Whether you designed for the vendor's failure, and whether you can distinguish the vendor risk assessment from the architectural response.

The honest answer

The vendor's availability was accepted as your availability. Vendor assurance questionnaires assess whether the vendor is well-run; they do not make your system survive their outage. That is architecture, and it was not done.

What should have existed

A degraded mode agreed with the business in advance. For KYC, the options are: queue applications for later verification and allow limited functionality; apply a risk-based rule permitting low-value onboarding with verification within a defined window; or fail closed. All three are legitimate — the failure is not having chosen, so the outcome was decided by the code's default.

This is a business and compliance decision, not an engineering one, and it must be made before the outage.

A secondary provider for a critical path dependency, with the integration built and periodically exercised. A fallback that has never run does not work when needed.

Asynchronous decoupling where the flow permits: accept the application, verify asynchronously, notify on completion. This converts a hard synchronous dependency into a delay and is frequently possible where the user experience was designed around an assumption of instant response.

Circuit breakers and timeouts so the vendor's slowness does not exhaust your connection pools and take down unrelated functionality — degradation is worse than outage, and six hours of timeouts can cascade.

What to tell the board

The distinction between vendor risk management (which assesses the vendor) and resilience design (which assumes the vendor fails). The first was done, the second was not, and the second is where the investment should go — with the degraded-mode decision as the first deliverable because it is cheap and it bounds the impact.

What a strong answer adds

The concrete review question to apply to every third-party integration: what precisely can this vendor read, and what happens to us at 09:00 on a Monday if they are down for six hours? Asking it routinely at design time is what prevents this class of incident.

Common weak answers

Blaming the vendor's SLA. Proposing a second vendor without addressing the degraded mode, which is cheaper and faster.