TL;DR: Zero trust means no implicit trust from network position. In a cluster that decomposes into four things: cryptographic workload identity rather than IP, authenticated and encrypted service-to-service traffic, explicit authorization policy that is default-deny, and admission control preventing workloads that would bypass the model. mTLS is one of the four.
How to approach it
Define the principle in one line, then decompose. The reason interviewers like this question is that "zero trust" is marketing vocabulary, and the decomposition is what shows you have implemented rather than repeated it.
A strong answer
The principle is that being on the network grants nothing. Every request is authenticated and authorized on its own merits, regardless of where it came from. Inside a cluster, the default posture is the opposite: pod networking that does not itself require application authentication. Workloads can already use service-account tokens or application credentials; reachability alone does not establish who called.
Identity. A pod needs a verifiable workload identity because addresses can be reassigned. A short-lived workload certificate, such as a SPIFFE X.509-SVID bound to an attested workload, is one option. Choose the granularity deliberately: sharing a service account may mean sharing an identity. Everything else depends on this, which is why it comes first.
Transport. With identity, mTLS becomes meaningful: peers authenticate and encrypt traffic between the TLS endpoints. This protects traffic on the path, but a compromised node hosting an endpoint may read its plaintext or credentials. A mesh can provide this transport. Cilium’s out-of-band mutual authentication and its WireGuard/IPsec encryption are separate features; enabling authentication alone does not encrypt application traffic. Check the deployed version’s maturity and coverage in the Cilium mutual-authentication reference.
Authorization. This is the half that gets skipped. mTLS proves who is calling; it does not decide whether they may. You need a default-deny policy and explicit allows in terms of identity: the checkout service account may call payments on POST /charge, and nothing else may. Two enforcement points, and both matter. Standard NetworkPolicy selects pods and namespaces by labels or uses IP blocks, then restricts layer 3/4 flows. It does not verify a cryptographic caller identity or authorize HTTP methods. Add application or mesh policy for those decisions. Also RBAC against the API server itself, scoped so a service account cannot list secrets across namespaces, and restrict who can create pods under more powerful service accounts.
Admission. A privileged pod or writable host mount can compromise the node and workload credentials. Host networking can bypass some pod-network restrictions, depending on the implementation. Use Pod Security Admission to enforce an appropriate Pod Security Standard, with reviewed exemptions and version-pinned labels. Baseline and Restricted prohibit privileged containers and host namespaces. Restricted adds Linux controls including non-root execution, restricted capabilities and seccomp. It does not require readOnlyRootFilesystem, forbid latest tags or require application labels. Enforce those additional rules with a separate admission policy, such as ValidatingAdmissionPolicy, Kyverno or Gatekeeper. The Pod Security Standards define the built-in scope; Linux-specific checks also depend on the pod OS and policy version.
Around it: secrets from an external manager with short leases rather than long-lived Kubernetes Secrets, and audit logging of both the API server and the service-to-service authorization decisions, because in a regulated environment "we denied it" is only useful if you can prove it later.
The order matters and it is the part worth stating. Start with admission control and RBAC, because they are cheap and stop the worst outcomes. Then default-deny NetworkPolicy per namespace. Then identity and mTLS, which is the most invasive. Teams that start with the mesh spend six months on transport encryption while a service account with cluster-admin sits untouched.
What interviewers probe next
"Is NetworkPolicy enough on its own?" No. It can select workloads by pod/namespace labels and constrain addresses and ports, but cannot establish cryptographic identity or express “may call this HTTP endpoint but not that one.” Those require additional enforcement.
"How do humans reach production under this model?" Short-lived credentials brokered through an identity provider, with API audit logs and, where supported, interactive session recording. Standing kubeconfigs with long-lived certificates are the thing this model exists to remove.
"What is the operational cost?" Certificate rotation you must monitor, a policy set that grows with every service, and a new failure mode where a misissued policy denies legitimate traffic. Budget for the day the CA expires.
Common mistakes
Answering "mTLS" and stopping. It is the most visible quarter of the answer.
Omitting admission and RBAC controls that prevent workloads or users from gaining access outside the intended policy boundary.
Proposing default-deny everywhere on day one. Done without a staged rollout and traffic observation first, it causes an outage and the initiative gets cancelled.