Back to the course
Test yourself

Zero-trust & workload identity

Final exam · 60 questions · answers explained as you pick
Zero-trust foundations
12 questions
01The core principle of zero trust is…
Incorrect — That is the perimeter model zero trust replaces.
Correct — Every request is authenticated and authorized on its own merits.
Incorrect — Zero trust covers east-west too.
Incorrect — The opposite — it authenticates everything.
02In zero trust, the new perimeter is…
Correct — Identity, not IP or subnet, gates access.
Incorrect — A network appliance, not the zero-trust perimeter.
Incorrect — Physical/network boundaries are what zero trust stops trusting.
Incorrect — Not the basis for trust decisions.
03The "assume breach" mindset means…
Incorrect — It drives stronger controls, not surrender.
Correct — Least privilege, segmentation, and verification everywhere.
Incorrect — You log more, not less.
Incorrect — Assume-breach explicitly distrusts internal traffic.
04Google BeyondCorp is significant because it…
Correct — A landmark zero-trust implementation for user access.
Incorrect — It eliminated reliance on the VPN/perimeter.
Incorrect — Far broader than that.
Incorrect — It is an access architecture, not a firewall.
05Why does the perimeter model fail for modern architectures?
Incorrect — Cost is not the core failure.
Correct — East-west movement is unchecked once inside.
Incorrect — They can; the model itself is the problem.
Incorrect — Performance is not the reason.
06Workload identity means giving a service…
Correct — The service proves who it is, not merely where it sits.
Incorrect — IPs are exactly what zero trust stops trusting.
Incorrect — Shared secrets are the opposite of per-workload identity.
Incorrect — A network control, not an identity.
07Identity-based controls beat IP-based controls because…
Incorrect — Not a security consideration.
Correct — Policy stays correct as the network changes.
Incorrect — They are not; that is not the difference.
Incorrect — Identity is precisely what you verify.
08A zero-trust network posture typically starts from…
Correct — Nothing talks until identity + policy permit it.
Incorrect — That is the permissive model zero trust rejects.
Incorrect — Zero trust is policy-heavy by design.
Incorrect — A namespace is not a trust boundary here.
09Continuous verification means…
Incorrect — That is the standing-trust model zero trust avoids.
Correct — Trust is re-evaluated, not granted permanently.
Incorrect — The opposite.
Incorrect — Unrelated to continuous verification.
10Zero trust for workloads and for users share the principle that…
Correct — Same model: identity and policy, whether the principal is a person or a service.
Incorrect — Workloads need strong identity too.
Incorrect — Users need it as well.
Incorrect — Location is exactly what is not trusted.
11The three pillars often cited for zero trust are identities, devices/workloads, and…
Incorrect — Not a zero-trust pillar.
Correct — Verify identity, verify the device/workload, grant minimal access.
Incorrect — A narrow control, not a pillar.
Incorrect — Static trust zones are what it replaces.
12Adopting zero trust is best approached as…
Correct — A big-bang cutover risks outages; roll out in stages.
Incorrect — That risks breaking everything at once.
Incorrect — It is an architecture, not a product.
Incorrect — The goal is verified access, not no access.
12 questions · explanations appear as you answer
SPIFFE & SPIRE
12 questions
01SPIFFE is…
Correct — It defines the ID format and identity documents.
Incorrect — Unrelated to SPIFFE.
Incorrect — Not a network filter.
Incorrect — It issues identity, not stores secrets.
02A SPIFFE ID looks like…
Incorrect — It is a URI, not an email.
Correct — A URI naming the trust domain and the workload.
Incorrect — It is a structured URI, not a bare UUID.
Incorrect — Identity is deliberately not an IP.
03An SVID (SPIFFE Verifiable Identity Document) is…
Correct — The workload presents an SVID to prove who it is.
Incorrect — Not a policy object.
Incorrect — Unrelated to images.
Incorrect — It is a credential, not a log.
04A trust domain is…
Incorrect — Related idea but not the SPIFFE concept.
Correct — All IDs in the domain share a trust anchor.
Incorrect — Not a network range.
Incorrect — It is an identity trust boundary, not a group.
05SPIRE is…
Correct — SPIRE Server + Agent deliver identities via the Workload API.
Incorrect — Unrelated.
Incorrect — Not a pipeline tool.
Incorrect — It issues identity, not metrics.
06Node attestation in SPIRE proves…
Incorrect — Irrelevant to attestation.
Correct — Establishes the node before workloads on it are trusted.
Incorrect — That is closer to workload attestation, and node attestation is about the node.
Incorrect — Not a credential check.
07Workload attestation determines a workload’s identity using…
Correct — The agent verifies the calling workload matches a registration entry.
Incorrect — Selectors are richer and harder to spoof than IP.
Incorrect — Not how SPIRE attests workloads.
Incorrect — Attestation uses selectors, not DNS.
08The SPIFFE Workload API lets a workload…
Incorrect — Unrelated to identity.
Correct — No key handling in app code; the agent delivers and rotates identity.
Incorrect — Not its function.
Incorrect — It provides identity, not networking.
09A major benefit of SPIRE-issued SVIDs is that they are…
Correct — No long-lived key to manage; rotation is continuous.
Incorrect — That is the anti-pattern SPIFFE avoids.
Incorrect — They are fetched at runtime, not baked in.
Incorrect — Each workload gets its own identity.
10X.509-SVIDs vs JWT-SVIDs differ in that…
Incorrect — They suit different transports.
Correct — Pick the document type to match how identity is presented.
Incorrect — They are short-lived like X.509-SVIDs.
Incorrect — They are certificates, not passwords.
11SPIFFE gives platform teams a way to…
Correct — A common identity plane independent of any single platform.
Incorrect — It provides identity, not networking.
Incorrect — It underpins authorization; it does not remove it.
Incorrect — Not its purpose.
12A registration entry in SPIRE maps…
Incorrect — Not what a registration entry does.
Correct — It is the policy that says "a workload with these selectors gets this identity".
Incorrect — Not credential storage.
Incorrect — Not a networking mapping.
12 questions · explanations appear as you answer
Service mesh & mTLS
12 questions
01A service mesh provides workload-to-workload security by…
Correct — The app is unchanged; the mesh owns mTLS and policy.
Incorrect — It secures traffic in transit, not storage.
Incorrect — Not a mesh function.
Incorrect — It adds service-to-service authz, distinct from K8s RBAC.
02mTLS (mutual TLS) means…
Incorrect — That is ordinary TLS; mutual means both sides.
Correct — A service proves who it is, not merely that it is on the network.
Incorrect — mTLS is certificate-based.
Incorrect — It uses certificates, not passwords.
03Istio PeerAuthentication in STRICT mode…
Correct — No cleartext east-west traffic is accepted.
Incorrect — That is PERMISSIVE mode, used during migration.
Incorrect — The opposite — it mandates it.
Incorrect — It governs service-to-service (east-west) traffic.
04Mesh workload identities are typically expressed as…
Incorrect — They use a structured identity.
Correct — Meshes issue certs bound to the workload’s SPIFFE identity.
Incorrect — Identity is deliberately not the IP.
Incorrect — Not used for mesh identity.
05The mesh CA (e.g. istiod, Linkerd identity) is responsible for…
Correct — Certs are minted per workload and refreshed without app involvement.
Incorrect — That is a secrets manager.
Incorrect — A separate mesh function, not the CA.
Incorrect — Unrelated to the CA.
06Short-lived mesh certificates matter because…
Incorrect — Size is not the security property.
Correct — Automatic rotation shrinks the value of theft.
Incorrect — They are issued by the mesh CA.
Incorrect — They are the basis of mTLS.
07Migrating to STRICT mTLS safely uses…
Correct — Avoids breaking not-yet-migrated clients on day one.
Incorrect — That can break plaintext clients abruptly.
Incorrect — That removes the security you want.
Incorrect — Contrary to the goal.
08Ambient mesh (sidecar-less) changes the model by…
Incorrect — It keeps mTLS/identity, just without per-pod sidecars.
Correct — A newer architecture trading sidecars for node-level handling.
Incorrect — It still secures east-west.
Incorrect — It remains transparent to apps.
09Edge-only TLS (terminate at the ingress, plaintext inside) is a problem because…
Correct — Zero trust requires encrypting service-to-service too.
Incorrect — Performance is not the issue.
Incorrect — Trusting the interior is the classic mistake.
Incorrect — Not the concern.
10The mesh authenticates a caller by…
Incorrect — IP is spoofable and churns; the mesh uses identity.
Correct — Cryptographic proof of the calling workload’s identity.
Incorrect — Not the mesh identity mechanism.
Incorrect — Names are not a cryptographic identity.
11A benefit of the mesh owning mTLS is that…
Correct — Consistent, transparent security across polyglot services.
Incorrect — The mesh removes that burden.
Incorrect — It enables identity-based authz.
Incorrect — It is language-agnostic.
12Linkerd and Istio both anchor identity in…
Incorrect — Not the identity basis.
Correct — Identity derives from the K8s service account, cryptographically.
Incorrect — No shared secret; per-workload certs.
Incorrect — Deliberately not the IP.
12 questions · explanations appear as you answer
Identity-based authorization
12 questions
01An Istio AuthorizationPolicy decides access based on…
Correct — Allow/deny by who the caller cryptographically is.
Incorrect — Identity-based authz avoids relying on IP.
Incorrect — Irrelevant to authorization.
Incorrect — Not an authz input.
02A default-deny AuthorizationPolicy means…
Incorrect — That is default-allow, the opposite.
Correct — Zero-trust authz: open only the declared flows.
Incorrect — Unrelated to encryption.
Incorrect — It governs east-west authz.
03Least privilege for service-to-service authz means…
Correct — A compromised service can reach little beyond its declared calls.
Incorrect — That maximizes lateral movement.
Incorrect — Too coarse; scope per workload.
Incorrect — Contrary to zero trust.
04L7 authorization in the mesh can restrict…
Incorrect — That is L4; L7 goes further.
Correct — Application-aware, per-request authorization.
Incorrect — Not an authz dimension.
Incorrect — Irrelevant to authz.
05RequestAuthentication (JWT) in a mesh validates…
Correct — Adds request-level identity on top of workload mTLS identity.
Incorrect — Not a JWT concern.
Incorrect — Unrelated to JWT validation.
Incorrect — Not a request auth input.
06Combining workload identity (mTLS) with request identity (JWT) gives you…
Incorrect — They authorize different things and compose.
Correct — Defense in depth across service and user identity.
Incorrect — The value is security, not speed.
Incorrect — Unrelated.
07Authorization policy should be managed as…
Correct — Policy-as-code with a safe rollout, like every policy in the course.
Incorrect — Error-prone and unauditable.
Incorrect — Defeats the purpose.
Incorrect — Not reproducible or reviewable.
08Identity-based authz stays correct as pods reschedule because…
Incorrect — IP-based rules break as pods churn.
Correct — The policy follows the identity, not the pod IP.
Incorrect — It does not control scheduling.
Incorrect — That would be stale and wrong.
09Rolling out a default-deny authz policy safely means…
Correct — Avoid cutting legitimate service-to-service traffic on day one.
Incorrect — That breaks every undocumented flow at once.
Incorrect — Default-deny is the zero-trust target.
Incorrect — Testing is exactly what prevents the outage.
10Mesh authorization complements Kubernetes RBAC by governing…
Incorrect — They operate at different layers.
Correct — Two distinct authorization planes; you want both.
Incorrect — That is RBAC; the mesh governs data-plane traffic.
Incorrect — It is a key east-west control.
11A compromised workload under identity-based authz is contained because…
Correct — The blast radius is what the policy explicitly allowed, nothing more.
Incorrect — That would be the no-policy case.
Incorrect — Not an automatic effect of authz.
Incorrect — The mesh keeps enforcing, not shutting down.
12The end goal of identity-based authz is…
Incorrect — Encryption (mTLS) is necessary but not sufficient; you also authorize.
Correct — Verify who is calling and whether they may — the zero-trust data plane.
Incorrect — Co-location is not a trust basis.
Incorrect — Namespaces are not a trust boundary.
12 questions · explanations appear as you answer
Federation & egress
12 questions
01SPIFFE federation lets two trust domains…
Correct — Workloads in domain A can authenticate workloads in domain B.
Incorrect — Federation exchanges public trust bundles, not private keys.
Incorrect — Federation keeps domains separate but interoperable.
Incorrect — It extends authentication across domains.
02Trust-domain federation is useful for…
Incorrect — Federation is for spanning multiple domains.
Correct — Identity that works across administrative boundaries.
Incorrect — Unrelated to federation.
Incorrect — Not its purpose.
03When federating, you exchange…
Correct — Each domain keeps its CA private; only trust anchors are shared.
Incorrect — Sharing private keys would break the trust model.
Incorrect — SVIDs are issued per workload, not bulk-shared.
Incorrect — Irrelevant to federation.
04Egress control in a zero-trust mesh means…
Incorrect — That is the open-egress risk zero trust closes.
Correct — Outbound is authorized like everything else.
Incorrect — Egress is about outbound control.
Incorrect — Not what egress control does.
05An egress gateway lets you…
Correct — Approve and monitor what leaves, instead of open egress.
Incorrect — That is an ingress gateway.
Incorrect — Not its function.
Incorrect — Unrelated.
06Why does zero trust care about east-west and egress, not just north-south?
Incorrect — Lateral movement and exfiltration are east-west/egress.
Correct — Internal and outbound flows are where post-compromise activity lives.
Incorrect — Assume-breach says otherwise.
Incorrect — It can, via gateways and policy.
07Continuous verification with short-lived SVIDs handles revocation by…
Correct — No complex CRL/OCSP; rotation is the revocation mechanism.
Incorrect — Short lifetimes largely obviate CRLs.
Incorrect — Expiry is exactly how it revokes.
Incorrect — Not required for revocation.
08Federating a service mesh across clusters typically requires…
Incorrect — Federation connects them without merging.
Correct — Common trust anchor enables cross-cluster mTLS.
Incorrect — The opposite — you extend mTLS across them.
Incorrect — Contrary to zero trust.
09Device/workload posture in a mature zero-trust model can gate access on…
Correct — Access adapts to current posture, not a one-time grant.
Incorrect — Posture is broader than a schedule.
Incorrect — A weak, spoofable signal alone.
Incorrect — Posture adds important context to identity.
10The relationship between SPIFFE and a service mesh is that…
Incorrect — They align; meshes use SPIFFE-style identity.
Correct — SPIFFE is the identity foundation the mesh builds on.
Incorrect — They are complementary layers.
Incorrect — Identity is what the mesh enforces.
11Zero trust across organizations (B2B) benefits from federation because…
Correct — Cross-org calls use identity, not shared network trust.
Incorrect — Only public trust bundles are exchanged.
Incorrect — Unnecessary and undesirable.
Incorrect — A flat network is the perimeter model zero trust rejects.
12The unifying theme of zero-trust workload identity is…
Incorrect — Zero trust stops trusting the network.
Correct — Identity + mTLS + least-privilege authz + rotation, end to end.
Incorrect — The perimeter model is what this replaces.
Incorrect — Encryption plus identity and authorization is the point.
12 questions · explanations appear as you answer