5 exercises — choose the best-structured answer to common platform security interview questions. Focus on zero trust design, workload identity, secrets management, service mesh policies, and supply chain security.
Structure for platform security interview answers
Name the principle before the tool: "never trust, always verify" before naming SPIFFE or Istio
Explain bootstrapping: how does identity get established from scratch — attestation chains matter
Cover pitfalls explicitly: PERMISSIVE mode, unnamed ports, default-allow — interviewers want to see failure-mode awareness
Give implementation order: identity first, then mTLS, then network policy, then continuous verification
0 / 5 completed
1 / 5
The interviewer asks: "Describe how you would design a zero trust network architecture for a cloud-native platform — what are the core principles and implementation pillars?" Which answer best captures zero trust depth?
Option B covers all seven pillars: the core "never trust, always verify" principle, workload identity via SPIFFE/SVID with the exact URI format, human identity with short-lived tokens, microsegmentation via mTLS + service mesh + NetworkPolicy at L3/L4 and L7, device health checks, OPA policy engine, continuous re-verification with short JWT TTLs, and an implementation order. Options C and D each name 2-3 correct components but don't cover device trust, continuous re-verification, or the implementation sequence. Option A conflates VPN with zero trust.
2 / 5
The interviewer asks: "Explain the SPIFFE/SPIRE architecture — how does a workload obtain its identity, and how is that identity used for mTLS?" Which answer best explains the identity bootstrapping flow?
Option B is the complete answer: it covers SPIFFE SVID format (URI SAN structure), SPIRE topology (server + agent DaemonSet), node attestation with two concrete attestor examples (AWS IID, k8s-psat), workload attestation mechanics (Unix socket, kubelet API check), the CSR/signing flow, mTLS handshake with both-party verification and authorisation via SPIFFE ID matching, and automatic short-lived rotation. Options A, C, D each describe the end state but none explain how a workload bootstraps its identity (the attestation chain) or how rotation works automatically.
3 / 5
The interviewer asks: "Compare AWS IAM roles (for EC2/EKS workloads) with HashiCorp Vault AppRole for secrets management — when would you choose each?" Which answer best covers the comparison?
Option B covers all six dimensions: IAM role credential delivery mechanics (STS + metadata service), IRSA implementation detail (OIDC federation, projected SA token → AssumeRoleWithWebIdentity), Vault AppRole two-component auth (RoleID + SecretID with the non-secret/secret split), dynamic secret generation per backend, decision criteria for each (pure AWS vs multi-cloud), and the combination pattern (IRSA + Vault together). Options C and D state the conclusion correctly but don't explain IRSA mechanics, the RoleID/SecretID split, dynamic secret rotation, or the combination pattern.
4 / 5
The interviewer asks: "How do you implement service-to-service authorisation policies in a service mesh — what Istio primitives do you use and what are common misconfiguration pitfalls?" Which answer best covers mesh security policy?
Option B covers all five areas: PeerAuthentication STRICT vs PERMISSIVE with the migration/danger nuance, AuthorizationPolicy structure (selector + from + to + when with SPIFFE ID source), RequestAuthentication for JWT validation, three specific misconfiguration pitfalls (PERMISSIVE left on, unnamed port L7 bypass, default-allow misunderstanding), and debugging commands (`istioctl`, `curl` with cert, access log config). Options A, C, D each describe the policies correctly but don't cover the unnamed port pitfall, default-allow assumption, or debugging methodology.
5 / 5
The interviewer asks: "Explain SLSA (Supply chain Levels for Software Artifacts) — what do the four levels require, and how would you implement SLSA Level 3 for a production CI/CD pipeline?" Which answer best covers supply chain security depth?
Option B covers all five implementation layers: SLSA level requirements with the specific protections each provides (workstation compromise vs malicious build script), Sigstore toolchain (cosign, Rekor transparency log), the complete signing workflow with `slsa-github-generator`, deployment-time verification via admission controller with the policy logic, and SBOM generation + CVE scanning for dependency supply chain. Options C and D each describe 2-3 correct steps but don't explain what each SLSA level protects against, the Rekor transparency log's role, or the full SBOM workflow.