How do you test a default-deny NetworkPolicy rollout before enforcing it?

A default-deny policy is easy to write and hard to introduce safely in a cluster with undocumented east-west traffic. Static manifests show intended connections, but they miss runtime DNS, webhooks, metrics scraping, leader election, jobs, and rarely used recovery paths. Applying the deny first and adding exceptions from incidents is not an acceptable discovery method.

What pre-enforcement workflow gives useful coverage? I am considering flow logs from the CNI, grouping observed traffic by namespace and service account, generating candidate allow rules, and then running synthetic checks for known dependencies. The difficult part is proving the observation window covered scheduled jobs and infrequent operational paths without turning every observed destination into a permanent allow rule.

Do Cilium, Calico, or another tool provide a practical audit or shadow mode for this? How do you handle DNS and external FQDN access, and what rollback signal do you watch during a staged namespace-by-namespace rollout?