You propose egress filtering. Engineering says it will break builds and slow delivery. How do you proceed?
Show the full answer Hide the answer
What the interviewer is testing
Whether you can introduce a genuinely disruptive control without it being rejected.
Why it is worth the friction
Inbound filtering gets the attention; outbound is where the damage happens. An attacker who has compromised a workload needs to reach a command-and-control endpoint and to exfiltrate data, and in the default cloud configuration — unrestricted outbound — both are trivial.
It also stops a compromised build step from pulling a malicious payload, which is the supply-chain case.
Acknowledging the objection honestly
They are right that it is awkward. Applications reach many external services, dependency resolution pulls from registries, cloud service endpoints are numerous and change, and a broken egress rule presents as a mysterious application failure rather than as a security event — which is what makes teams resistant.
The approach that gets it adopted
Log-only mode first. Deploy the policy in observation mode and collect the actual destination set for several weeks. This produces the allowlist from evidence rather than from guesswork, and it shows teams exactly what will be affected before anything breaks.
Remove whole categories of need: private endpoints for cloud services so that traffic never traverses the internet, and an internal artifact mirror or proxy as the single permitted path for package downloads. This eliminates most of the friction rather than managing it.
DNS-based policy rather than IP for services with changing addresses.
Start where the case is strongest: workloads handling regulated data, and CI runners, which execute untrusted third-party code by design. Prove it there, then extend.
Make failures diagnosable: denied connections must produce a clear, discoverable log entry naming the destination and the policy, with a fast self-service path to request an addition.
What a strong answer adds
The cost saving as a supporting argument: private endpoints frequently avoid NAT gateway and internet egress charges, which for high-volume storage or database traffic can be substantial. A security control that reduces the bill is much easier to fund.
Common weak answers
Mandating it estate-wide from day one. Abandoning it because of the objection.