Start here. This is the direct spoken answer to practice first.
Why this question matters
Explain why async void is usually dangerous outside event handlers and how exceptions behave differently. It matters in real backend work because load, cancellation, retries, and dependency latency decide whether the API stays predictable under pressure. The practical angle is async exception flow, event handlers, testability, unobserved failures, and API design, tied to a concrete production decision.
I avoid async void because callers cannot await it, compose it, or catch its exceptions in the normal Task-based way. Async void is mainly for event handlers where the delegate signature requires void. For normal async methods, I return Task or Task<T>. That lets the caller observe completion, handle errors, and test the method. I would keep cancellation, cleanup, and bounded concurrency in the answer, because async code that works in a demo can still overload a real service.