Practice vocabulary for service mesh security: mTLS enforcement, authorization policies, certificate rotation, SPIFFE/SPIRE workload identity, and zero-trust networking.
0 / 5 completed
1 / 5
When an Istio PeerAuthentication policy requires all service-to-service communication to use mutual TLS with no plaintext fallback, it is described as:
The PeerAuthentication enforces mTLS in STRICT mode — STRICT means plaintext connections are rejected; PERMISSIVE allows both (used during migration).
2 / 5
When a mesh policy controls which services are permitted to call a specific service, this policy is called:
The AuthorizationPolicy allows only service A to call service B — Istio AuthorizationPolicy grants access at L7, going beyond IP-based network policies.
3 / 5
When workload certificates are automatically replaced on a regular schedule to limit exposure if a certificate is compromised, this is called:
The certificate is rotated every 24 hours — short-lived certificates reduce the window of exposure if a private key is ever compromised.
4 / 5
The framework used by Istio to issue cryptographic workload identities based on the SPIFFE standard is called:
The mesh issues workload certificates via SPIFFE/SPIRE — SPIFFE defines the identity standard; SPIRE is the implementation that issues SVIDs (workload certificates).
5 / 5
The security model where no service trusts another by default and all communication must be authenticated — even inside the cluster — is called:
The zero-trust network inside the mesh — service mesh enables zero-trust by providing mTLS and AuthorizationPolicies for every service-to-service call.