Your services currently trust anything inside the VPC. A security review says move to zero trust. What changes, and what will it cost you?

What the interviewer is testing

Whether "zero trust" is a concrete set of changes to you, or a slogan.

What actually changes

Workload identity. Every service gets a cryptographic identity, not an IP address. In practice: SPIFFE/SPIRE, a cloud provider's workload identity, or a service mesh issuing short-lived certificates. The identity must be issued to the workload rather than configured into it, or you have replaced network trust with a shared secret.

Authenticated transport. Mutual TLS between services, so both ends verify. This is what removes "anything in the VPC can call anything".

Per-request authorisation. Not just "is this a valid service" but "may this service call this endpoint". A policy engine — mesh authorisation policy, OPA — evaluated per request.

End-user context propagation. The hard part. Service B needs to know which user the request is for, not just that it came from service A, or every service becomes a confused deputy that can be asked to fetch anyone's data. Usually a signed token propagated through the call chain and validated at each hop.

Short-lived credentials. Certificates measured in hours, database credentials issued per session, no long-lived keys in configuration.

What it costs

• Certificate lifecycle becomes critical infrastructure. Rotation failure is now an outage mode, and it is one that arrives all at once.
• Latency and resource overhead from the handshakes and the sidecars — real, though usually a few milliseconds and a few hundred MB per pod.
• Debugging difficulty. "Connection refused" becomes "which of identity, policy, certificate validity or trust bundle is wrong?"
• Platform capability. A service mesh is a significant thing to operate. Adopting one to get mTLS, without the team to run it, trades a security risk for an availability risk.

The pragmatic sequencing

Zero trust is not a project with an end date, and trying to do it in one is how it stalls. A defensible order:

1. Segment the network first — the cheapest large reduction in blast radius, and it does not need any of the above.
2. Remove long-lived credentials. Move to workload identity for cloud resources and dynamic database credentials. Largest risk reduction per unit of effort.
3. mTLS on the highest-value paths — anything touching the crown-jewel data store — rather than everywhere at once.
4. Per-request authorisation for those same paths.
5. Expand as the platform capability matures.

What a strong answer adds

Saying plainly that zero trust reduces blast radius rather than preventing compromise, and that the honest measure of success is "how far can an attacker who owns one workload get?" — which is a question you can test, unlike "are we zero trust?"