CKS Complete Exam Reference: Zero-Gap Pointer Guide

CKS (Certified Kubernetes Security Specialist) — Complete Exam Theory Guide

1. Exam Blueprint & Strategy

Domain Weight Focus Areas Cluster Setup 10% Network policies, CIS benchmarks, ingress hardening, node security Cluster Hardening 15% RBAC, authN/authZ, admission controllers, secrets encryption System Hardening 15% Kernel params, AppArmor, Seccomp, capabilities, SELinux Microservice Vulnerabilities 20% Security contexts, OPA/Gatekeeper, mTLS, pod security Supply Chain Security 20% Image scanning, signing, SBOM, private registries Monitoring & Runtime Security 20% Audit logs, Falco, runtime detection, incident response

• Exam constraints: 2 hours, 16–20 tasks, 67% passing score, CKA prerequisite required.
• Time strategy: allocate 5 minutes per task; flag complex ones and return later.

---

1. Cluster Setup & Hardening

2.1 Network Policies

• NetworkPolicy is a namespaced resource enforcing L3/L4 traffic rules; default-deny is implicit once any policy selects a pod.
• Three pillars: podSelector (target), policyTypes (Ingress/Egress), and rules (from/to, namespaceSelector, ipBlock).

Default Deny Pattern:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Field Purpose Example podSelector Targets pods by labels app: frontend namespaceSelector Filters source/dest namespaces team: dev ipBlock CIDR-based allow/deny cidr: 10.0.0.0/8 except 10.0.1.0/24 ports Protocol & port tuples protocol: TCP, port: 443

• Egress policies prevent data exfiltration; without them, pods reach any cluster or external IP unrestricted.
• CNI must support NetworkPolicy: Calico, Cilium, Weave work; Flannel does not.

flowchart LR
    A[External Traffic] -->|TLS| B[Ingress Controller]
    B --> C{NetworkPolicy}
    C -->|Allow| D[Frontend Pod]
    C -->|Deny| E[Untrusted Pod]
    D -->|Allow| F[Database]
    E -.->|Blocked| F

2.2 CIS Benchmarks

• CIS (Center for Internet Security) publishes hardened configuration standards; kube-bench automates checks against Kubernetes CIS benchmarks.
• Run kube-bench as a Job or DaemonSet; it audits API server, etcd, kubelet, controller-manager, scheduler, and file permissions.

Component Critical CIS Checks API Server --anonymous-auth=false, --authorization-mode=RBAC, audit policy configured etcd Peer TLS, client cert auth, data-dir permissions 700 Kubelet --read-only-port=0, cert-based auth, strong crypto ciphers Controller Manager --use-service-account-credentials, --root-ca-file set

• Remediation path: edit static pod manifests in /etc/kubernetes/manifests/*.yaml; kubelet auto-restarts them.
• kube-bench outputs [PASS], [FAIL], [WARN]; automate fixes via Ansible or shell scripts where possible.

2.3 Ingress Security

• Ingress exposes HTTP/HTTPS routes; IngressClass defines the controller (NGINX, Traefik, HAProxy).
• TLS termination occurs at the ingress controller; reference certificates via spec.tls[].secretName pointing to TLS Secrets.

Annotation / Config Security Purpose nginx.ingress.kubernetes.io/force-ssl-redirect Enforces HTTPS only nginx.ingress.kubernetes.io/limit-rps Rate limiting per second nginx.ingress.kubernetes.io/whitelist-source-range IP allowlisting cert-manager.io/cluster-issuer Automated TLS via Let’s Encrypt

• Always use networking.k8s.io/v1; extensions/v1beta1 is removed.
• Ingress controllers are pods too — harden with security contexts, dedicated SAs, and NetworkPolicies.

2.4 Node Security

• Nodes run kubelet, container runtime, and OS processes; node compromise equals cluster compromise.
• SSH hardening: disable root login, enforce key-based auth, use fail2ban, change default port.

Layer Hardening Action OS Minimal image, unattended upgrades, AIDE/Tripwire for integrity Kernel Enable SELinux/AppArmor, apply sysctl hardening Kubelet Disable anonymous auth, enable cert rotation, restrict API access Runtime Use containerd/CRI-O, enable user namespaces where supported

• Critical file permissions: /var/lib/etcd → 700; /etc/kubernetes/admin.conf → 600.
• Audit with: find /etc/kubernetes /var/lib/kubelet -type f -perm /o+w.

2.5 API Server Security

• API server is the cluster front door; every request traverses Authentication → Authorization → Admission Control.

flowchart LR
    A[Client Request] --> B[Authentication<br/>X509/OIDC/Token]
    B --> C[Authorization<br/>RBAC/ABAC/Webhook]
    C --> D[Admission Controllers]
    D --> E[etcd Persistence]
    F[Audit Log] -->|Records| B
    F -->|Records| C
    F -->|Records| D

Flag Secure Value Purpose --anonymous-auth false Blocks unauthenticated requests --authorization-mode RBAC,Node Enables RBAC + Node authorizer --enable-admission-plugins NodeRestriction,PodSecurity,... Enforces security policies --audit-log-path /var/log/audit.log Forensics & compliance --request-timeout 300s Limits long-running requests --service-account-issuer Valid OIDC URL Enables workload identity

• API server runs as a static pod; modify /etc/kubernetes/manifests/kube-apiserver.yaml and kubelet restarts it automatically.

2.6 etcd Security

• etcd stores entire cluster state; backup via etcdctl snapshot save; restore via etcdctl snapshot restore.
• Enable peer & client TLS: --peer-client-cert-auth, --client-cert-auth, --auto-tls=false.

Control Implementation Encryption at rest --encryption-provider-config with aescbc or kms Encryption in transit mTLS between etcd members & clients Access control API server is the ONLY etcd client; firewall ports 2379/2380 Backups Encrypt backups, store offsite, test restore procedures quarterly

• Data directory (--data-dir) ownership: root, mode 700.
• Rotate encryption keys by adding a new provider first, restarting API server, rewriting all secrets, then removing the old key.

2.7 Kubelet Security

• Kubelet exposes port 10250 (HTTPS) and deprecated 10255 (HTTP read-only).
• Hardening mandate: --anonymous-auth=false, --authorization-mode=Webhook, --rotate-certificates, --read-only-port=0.

Config / Flag Secure Setting authentication.webhook.enabled true authorization.mode Webhook tlsCertFile / tlsPrivateKeyFile Valid kubelet server certs rotateCertificates true serverTLSBootstrap true

• NodeRestriction admission controller limits each kubelet to modifying only its own Node object and bound Pods.

---

1. Cluster Hardening

3.1 RBAC

• RBAC uses four objects: Role, ClusterRole, RoleBinding, ClusterRoleBinding.
• Role is namespaced; ClusterRole is cluster-scoped; bindings link subjects (Users, Groups, SAs) to roles.

flowchart TD
    A[User/ServiceAccount] -->|RoleBinding| B[Role]
    A -->|ClusterRoleBinding| C[ClusterRole]
    B --> D[Namespace Scoped]
    C --> E[Cluster Scoped]

Verb Description get, list, watch Read-only operations create, update, patch Write operations delete Remove single resource deletecollection Bulk deletion * All verbs — avoid in production

• Least privilege: grant minimal verbs on specific resources; never use wildcard * for resources in production roles.
• impersonate verb enables privilege escalation; restrict to break-glass SAs only.
• Verify access: kubectl auth can-i <verb> <resource> --as <user> --namespace <ns>.

3.2 Service Accounts

• Every pod receives a ServiceAccount (default: default); automounts a token at /var/run/secrets/kubernetes.io/serviceaccount/token.
• Disable automounting when unnecessary: automountServiceAccountToken: false in SA or Pod spec.

Scenario Recommendation App does not call K8s API automountServiceAccountToken: false Pod needs API access Dedicated SA with minimal RBAC Cross-cluster access Use OIDC/workload identity, not long-lived tokens Legacy tokens Migrate to bound service account tokens

• Bound tokens (v1.22+): audience-scoped, time-bound, object-linked; enabled via --service-account-issuer.
• TokenRequestProjection mounts short-lived tokens as projected volumes with explicit expiration.

3.3 Admission Controllers

• Admission controllers intercept requests post-authN/authZ; mutating vs. validating types.
• Enable via --enable-admission-plugins; execution order matters for mutating controllers.

Controller Type Purpose NodeRestriction Validating Limits kubelet to own node/pods PodSecurity Validating Enforces Pod Security Standards LimitRanger Mutating+Validating Applies default resource limits ResourceQuota Validating Caps namespace consumption ServiceAccount Mutating Auto-injects SA and tokens AlwaysPullImages Mutating Forces image pull on every start ImagePolicyWebhook Validating External image admission decision

• Custom admission: MutatingWebhookConfiguration / ValidatingWebhookConfiguration call external webhooks (OPA, Kyverno).
• Webhooks require CA bundle, timeout, and failurePolicy (Fail or Ignore).

3.4 Pod Security Standards

• Replaces PodSecurityPolicy (PSP deprecated 1.21, removed 1.25).
• Three levels: privileged (unrestricted), baseline (minimal restrictions), restricted (hardened).

Profile Key Restrictions Privileged None; unrestricted Baseline No hostNetwork, hostPID, hostIPC, no privileged, no dangerous volume types Restricted Baseline + runAsNonRoot, drop ALL capabilities, no seccomp unconfined, restricted volumes

• Enforced via PodSecurity admission controller; configure per namespace:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

• Modes: enforce (reject), audit (log to audit log), warn (user-facing warning).
• Dry-run check: kubectl label namespace <ns> pod-security.kubernetes.io/enforce=restricted --dry-run=server.

3.5 Secrets Management

• Secrets are base64-encoded, not encrypted by default; enable encryption at rest via EncryptionConfiguration.
• Providers: identity (none), aescbc, aesgcm, secretbox, kms (recommended for cloud key management).

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - kms:
        name: myKMSPlugin
        endpoint: unix:///var/run/kms-plugin/socket.sock
        cachesize: 1000
        timeout: 3s
    - aescbc:
        keys:
        - name: key1
          secret: <base64-32-byte-key>
    - identity: {}

• Key rotation: add new provider first, restart API server, run kubectl get secrets --all-namespaces to rewrite, then remove old key.
• External secret managers: Vault (Agent Injector), AWS Secrets Manager, Azure Key Vault, GCP Secret Manager; integrate via CSI drivers.
• Never commit secrets to Git; use SealedSecrets, SOPS, or External Secrets Operator.

---

1. System Hardening

4.1 Kernel Hardening & Sysctls

• Sysctls tune kernel parameters; unsafe sysctls are blocked by default unless kubelet allows them.
• Safe sysctls: kernel.shm*, net.ipv4.ip_local_port_range; set via Pod securityContext.sysctls.

Sysctl Security Purpose net.ipv4.ip_forward Controls pod IP forwarding kernel.keys.root_maxbytes Limits keyring memory vm.overcommit_memory Memory allocation behavior

• Unsafe sysctls require kubelet --allowed-unsafe-sysctls flag; avoid in production clusters.
• Blacklist unnecessary kernel modules (dccp, sctp, rds, tipc) via /etc/modprobe.d/.

4.2 AppArmor

• AppArmor is a Linux MAC system; profiles define file, network, and capability access per path.
• Kubernetes integration: annotate pods with container.apparmor.security.beta.kubernetes.io/<container>: <profile>.

Profile Behavior runtime/default Container runtime default profile localhost/<profile> Custom profile loaded on the node unconfined No restrictions — avoid

• Load profiles on every node: apparmor_parser /etc/apparmor.d/<profile>.
• Verify: aa-status lists loaded profiles; cat /proc/<pid>/attr/current shows active profile.
• AppArmor is path-based; does not protect against path traversal if executable paths change.

4.3 Seccomp

• Seccomp filters syscalls using JSON profiles; reduces kernel attack surface significantly.
• RuntimeDefault blocks 44 dangerous syscalls; strongly preferred over Unconfined.

securityContext:
  seccompProfile:
    type: RuntimeDefault
    localhostProfile: profiles/custom.json

Profile Type Description RuntimeDefault Container runtime’s default filter Localhost Custom JSON profile stored on node (/var/lib/kubelet/seccomp/) Unconfined No filtering — avoid

• Custom profiles: JSON whitelist/blacklist of syscalls; test with strace or syscall-tracer.
• Distribute profiles via DaemonSet or node provisioning; reference via localhostProfile.

4.4 Linux Capabilities

• Capabilities divide root privileges; containers should drop ALL and add back only explicitly required ones.

Capability Risk When Needed CAP_SYS_ADMIN Container escape Almost never CAP_NET_RAW Spoofing, raw sockets Rarely; replace with user-space ping CAP_SYS_PTRACE Process injection Debug only CAP_MKNOD Arbitrary device creation Almost never CAP_NET_BIND_SERVICE Bind ports <1024 Web servers on low ports

securityContext:
  capabilities:
    drop:
      - ALL
    add:
      - NET_BIND_SERVICE

• NET_RAW is especially dangerous; drop it unless absolutely required.
• Inspect container capabilities: docker inspect <container> | grep -i Cap or check /proc/<pid>/status.

4.5 SELinux

• SELinux enforces MAC via labels (user:role:type:level); requires --selinux-enabled in container runtime.
• Kubernetes: seLinuxOptions in securityContext sets type, level, role, user.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"
    type: "container_t"

Option Purpose level MLS/MCS categories type Domain transition target role SELinux role user SELinux user

• Requires SELinux enforcing on host; check with getenforce.
• Volume relabeling: Docker uses :z (shared) or :Z (private); Kubernetes handles via seLinuxOptions.

4.6 Container Runtime Security

• Prefer containerd or CRI-O over Docker; smaller attack surface, native CRI, no daemon bloat.
• Enable user namespaces (graduating to GA) to map container root to non-root host UID.

Runtime Security Feature containerd Seccomp, AppArmor, user namespace support CRI-O Minimal footprint, OCI-native, production-hardened Docker Larger surface; additional shim layer

• RuntimeClass enables alternative runtimes: gVisor (user-space kernel), Kata Containers (lightweight VM).
• Both gVisor and Kata provide isolation beyond standard Linux namespaces.

---

1. Minimize Microservice Vulnerabilities

5.1 Security Contexts

• securityContext exists at Pod and Container levels; container settings override pod-level settings.

Field Level Purpose runAsNonRoot Pod/Container Prevents UID 0 execution runAsUser / runAsGroup Pod/Container Fixed UID/GID readOnlyRootFilesystem Container Immutable root filesystem allowPrivilegeEscalation Container Blocks setuid escalation privileged Container Full host access — never in production seccompProfile Pod/Container Syscall filtering seLinuxOptions Pod/Container MAC labeling

• Immutable root FS: mount emptyDir or volumes for writable paths (/tmp, logs).
• allowPrivilegeEscalation: false prevents processes from gaining more privileges via SUID binaries.

5.2 Network Security

• Defense in depth: NetworkPolicies + Service mesh + Ingress TLS + Host firewalling.
• Default-deny all ingress and egress, then explicitly allow required communication paths.

flowchart TD
    A[Internet] -->|TLS| B[Ingress]
    B --> C[Service Mesh<br/>mTLS]
    C --> D{NetworkPolicy}
    D -->|Allow| E[Frontend Pod]
    D -->|Allow| F[Backend Pod]
    E -->|Allow| G[Database]
    F -.->|Deny| H[External API]

• Egress policies are critical; they prevent lateral movement and data exfiltration.
• Allow DNS: egress to CoreDNS (port 53 UDP/TCP) must be explicitly permitted.

5.3 Pod-to-Pod Communication

• Services expose pods via ClusterIP, NodePort, LoadBalancer, ExternalName.
• Headless services (clusterIP: None) allow direct pod-to-pod discovery without kube-proxy load balancing.

Service Type Exposure Risk Mitigation ClusterIP Internal only NetworkPolicy for intra-cluster segmentation NodePort Host port exposure Firewall node ports; avoid if possible LoadBalancer External exposure Whitelist IPs, use cloud-native firewalls ExternalName DNS CNAME redirect Validate external endpoints

• EndpointSlice replaces Endpoints for scalable pod IP tracking; preferred in modern clusters.

5.4 Service Mesh & mTLS

• Service mesh (Istio, Linkerd, Consul) provides automatic mTLS, traffic policies, and observability.
• mTLS encrypts pod-to-pod traffic; prevents sniffing and identity spoofing inside the cluster.

Feature Istio Linkerd mTLS Automatic strict/permissive Automatic always-on Sidecar Envoy Linkerd-proxy Overhead Higher latency Lower resource footprint Complexity High Medium

• Istio strict mTLS: PeerAuthentication resource with mtls.mode: STRICT.
• Without a mesh, implement mTLS manually via sidecars or application-layer TLS.

5.5 OPA / Gatekeeper

• OPA (Open Policy Agent) is a general-purpose policy engine; Gatekeeper integrates it into Kubernetes via webhooks.

flowchart LR
    A[API Request] --> B[Gatekeeper<br/>Validating Webhook]
    B --> C[OPA Engine]
    C --> D[Rego Policy]
    D -->|Allow/Deny| E[Response]

Object Purpose ConstraintTemplate Defines Rego logic + OpenAPI schema Constraint Instantiates template for enforcement Assign / AssignMetadata Mutations (Gatekeeper v3.4+)

• Rego is declarative; test policies with opa test or conftest.
• Common constraints: required labels, block latest tag, enforce resource limits, require readiness probes.
• Alternative: Kyverno — native Kubernetes policies, no new language, mutating + validating.

---

1. Supply Chain Security

6.1 Image Scanning

• Scan images for CVEs at build time and before deployment; integrate into CI/CD gates.
• Tools: Trivy, Clair, Snyk, Anchore, Grype.

Scanner Output Formats Integration Trivy Table, SARIF, JSON, CycloneDX CLI, CI, K8s operator Clair Layer-by-layer CVE Harbor, Quay registries Grype CycloneDX, SPDX Syft companion tool Snyk Priority score IDE, CI, registry scanning

• Scan OS packages, language dependencies, and base images.
• Fail pipelines on HIGH/CRITICAL CVEs; maintain exception lists with documented risk acceptance.

6.2 Image Signing & Verification

• Sign images at build time; verify at deployment time before pod creation.
• Cosign (Sigstore): keyless signing via OIDC + Fulcio certificate authority + Rekor transparency log.

sequenceDiagram
    participant D as Developer
    participant C as Cosign
    participant F as Fulcio
    participant R as Rekor
    participant K as Cluster Admission
    D->>C: Build & Sign Image
    C->>F: Request Signing Cert (OIDC)
    F-->>C: Short-lived Certificate
    C->>R: Upload Signature to TLog
    K->>C: Verify Signature + TLog Entry
    C-->>K: Valid / Invalid

• Admission verification: use policy-controller (Sigstore) or Kyverno image verification rules.
• Docker Content Trust (Notary v1) exists but is largely superseded by Sigstore/Cosign.

6.3 Private Registries & Image Pull Secrets

• Use private registries to control image provenance; authenticate via imagePullSecrets.

Method Use Case imagePullSecrets Pod-level registry authentication ServiceAccount integration Attach secret to SA for all pods in namespace Node-level runtime config Runtime configured with registry credentials Cloud IAM integration ECR/GCR/ACR workload identity

• Create secret: kubectl create secret docker-registry <name> --docker-server=<server> --docker-username=<user> --docker-password=<pass>.
• Never embed registry credentials inside container images.

6.4 Static Analysis & Policy

• Lint manifests before applying: kube-score, kubeval, Polaris, Checkov.
• Detect missing resource limits, privileged containers, missing probes, and latest tags.

Tool Focus Polaris Best practices, security, reliability checks Checkov IaC security across K8s, Terraform, CloudFormation kube-score General manifest quality and standard compliance Kubesec Security-specific manifest risk scoring

• Integrate into GitOps pre-sync hooks or CI quality gates.

6.5 SBOM

• SBOM (Software Bill of Materials) lists all components in an image; essential for compliance and incident response.
• Standard formats: SPDX, CycloneDX, SWID.

Tool SBOM Format Notes Syft SPDX, CycloneDX, JSON Fast, comprehensive component inventory Trivy CycloneDX, SPDX Includes linked vulnerability data BOM SPDX Kubernetes-native BOM generation

• Store SBOMs alongside image metadata; regenerate on every build.
• Rekor (Sigstore) can index SBOMs for supply chain transparency and verification.

---

1. Monitoring, Logging & Runtime Security

7.1 Audit Logging

• Kubernetes audit logs record every API server request; configured via --audit-policy-file.

Level Description None Do not log Metadata Request metadata only (user, timestamp, resource, verb) Request Metadata + request body RequestResponse Metadata + request body + response body

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods", "secrets"]
  - level: Metadata
    omitStages:
      - RequestReceived

• Stages: RequestReceived, ResponseStarted, ResponseComplete, Panic.
• Backends: log file (--audit-log-path) or webhook (--audit-webhook-config-file).
• Protect audit logs: immutable storage, forward to SIEM, restrict file access.

7.2 Falco

• Falco is a CNCF runtime security tool detecting anomalous behavior via system calls and K8s audit events.

Data Source Detection Examples System calls execve, open, connect, setns K8s audit logs Privileged pod creation, exec into pod Internal events Container starts, unexpected shell execution

• Falco rules use sysdig-like conditions; output alerts to stdout, file, or Falcosidekick.

- rule: Terminal Shell in Container
  desc: Detect shell execution inside containers
  condition: spawned_process and container and shell_procs
  output: "Shell in container (user=%user.name container=%container.name)"
  priority: WARNING

• Falcosidekick forwards alerts to Slack, Teams, webhooks, or Falco Talon for automated response.

7.3 Runtime Threat Detection

• Beyond Falco: Sysdig Secure, Aqua, Prisma Cloud, NeuVector.

Capability Description Behavioral baseline Machine-learned normal pod behavior; alerts on deviation Drift prevention Blocks execution of new binaries written at runtime Network micro-segmentation Auto-generates policies from observed traffic patterns Vulnerability shield Virtual patching based on runtime CVE context

• Drift prevention is powerful: if an attacker drops a crypto-miner, execution is denied immediately.
• Combine runtime detection with admission control for layered defense.

7.4 Log Aggregation & SIEM

• Centralize logs: Fluent Bit / Fluentd → Elasticsearch / Loki / Grafana; or cloud-native (CloudWatch, Stackdriver, Azure Monitor).

Component Log Source Collection Tool API Server Audit logs Fluent Bit DaemonSet Nodes Kernel, kubelet, runtime logs Node exporter, Promtail Workloads Application stdout/stderr Sidecar or node agent Falco Security events Falcosidekick

• Correlate API audit logs with Falco runtime alerts and application logs for full traceability.
• Retention: comply with organizational and regulatory requirements; protect against tampering.

7.5 Incident Response

• Preparation: maintain runbooks, contact lists, and an isolated forensics namespace or node.

Phase Kubernetes Actions Detection Falco alert, audit log anomaly, IDS trigger Containment Cordon node, isolate pod via NetworkPolicy, scale deployment to 0 Eradication Delete compromised resources, rotate all credentials, patch CVE Recovery Restore from verified clean backup, check SBOM, redeploy Lessons Learned Update policies, improve detection, conduct tabletop exercises

• Forensics: capture pod filesystem using ephemeral containers, collect network packets via tcpdump sidecar, dump memory if tooling permits.
• Ephemeral containers: kubectl debug -it <pod> --image=busybox --target=<container>; requires EphemeralContainers feature gate enabled.

---

1. Key Exam Commands & Shortcuts

Task Command Verify RBAC permissions kubectl auth can-i <verb> <resource> --as <user> --namespace <ns> Decode a secret kubectl get secret <name> -o jsonpath='{.data.key}' \| base64 -d Inspect API server flags cat /etc/kubernetes/manifests/kube-apiserver.yaml Inspect kubelet config cat /var/lib/kubelet/config.yaml Run kube-bench kubectl apply -f <kube-bench-job.yaml> Check container capabilities docker inspect <id> \| grep -i Cap Check seccomp profile grep Seccomp /proc/<pid>/status Check AppArmor profile cat /proc/<pid>/attr/current Monitor audit logs tail -f /var/log/audit.log Backup etcd ETCDCTL_API=3 etcdctl snapshot save <path>

---

1. Quick Reference Diagrams

9.1 Defense in Depth

flowchart TD
    A[External User] -->|mTLS| B[Ingress]
    B -->|NetworkPolicy| C[Service Mesh]
    C -->|mTLS| D[Pod]
    D -->|Seccomp/AppArmor| E[Container]
    E -->|readOnlyRootFS| F[Filesystem]
    F -->|Encryption| G[etcd]

9.2 API Request Lifecycle

flowchart LR
    A[Client] -->|X509/OIDC/Token| B[Authentication]
    B -->|RBAC/ABAC/Webhook| C[Authorization]
    C -->|Mutating| D[Admission]
    D -->|Validating| E[Admission]
    E --> F[etcd]
    G[Audit Log] -->|Records| B
    G -->|Records| C
    G -->|Records| D
    G -->|Records| E

---

1. Exam Day Checklist

• Context switching: Use kubectl config use-context <context> immediately for every task.
• YAML generation: Use --dry-run=client -o yaml to generate templates; edit minimally.
• Documentation: Bookmark official Kubernetes docs, Falco rules reference, and CIS benchmarks.
• Verification: Always validate with kubectl get, describe, and auth can-i.
• Time discipline: 2 minutes per task average; skip and flag complex tasks, return later.
• Cleanliness: Delete debug pods and temporary resources before finishing.

---

🚀 Ready to get hands-on? Spin up an interactive AI or Kubernetes Sandbox at Aicademy Labs for free.