KCSA Exam Preparation

Cloud, cluster, container, and code form four connected security boundaries. You distinguish the responsibilities of the cloud provider, platform team, and application team and compare IAM, network segmentation, images, and workload configuration by their protective roles. Using a prepared architecture, you mark assumptions, existing controls, and open checks across all four layers.

A scan result is not yet approval for a container image. You scan prepared images with Trivy, assess CVE findings in context, and compare approved base images. You then verify a signature with Cosign and distinguish registry controls, signature trust, and remaining runtime risks in the lab.

The API server, etcd, controller manager, and scheduler form central control plane trust boundaries. You inspect authentication, authorization, TLS, and encryption at rest and examine key management and access permissions. A prepared configuration in the lab demonstrates why individual flags never replace the complete security model.

On worker nodes, the kubelet, container runtime, and network path meet. You inspect kubelet authentication and authorization, selected containerd settings, and the role of kube-proxy in the Service path. Using a prepared node configuration, you map findings to a concrete control or an open operational decision.

Container networking, storage, and client security protect different access paths: traffic between Pods, persistent data, and administrative cluster access. In a prepared scenario, you trace one Pod connection, inspect the StorageClass and claim to distinguish provisioning from access boundaries, and use a kubeconfig context whose identity is limited to necessary permissions through RBAC. The review shows which control protects each boundary.

Kubernetes defines three Pod Security Standards profiles: Privileged, Baseline, and Restricted. You configure Pod Security Admission in the cluster and test how the enforce, audit, and warn modes respond to non-compliant pods. In the lab, you compare the profiles on prepared workloads and plan an incremental rollout.

Who is allowed to do what in the cluster? You compare X.509 certificates, bearer tokens, and OIDC as authentication paths, then create RBAC Roles and RoleBindings. Using an overly broad ClusterRole and the system:masters group in the prepared lab cluster, you inspect how identity, scope and the specific binding can grant unnecessary permissions.

Kubernetes Secrets are API objects; Base64 encoding does not protect their contents, whereas encryption at rest protects the raw value stored in etcd. In a prepared control plane, you configure encryption at rest and examine how it interacts with namespace isolation and audit logging. You observe how storage protection, RBAC bindings, and audit policy address different boundaries.

Without a NetworkPolicy selecting them, Pods are non-isolated by default for the relevant direction; enforcement requires a supporting network plugin. For prepared workloads, you develop a default-deny strategy and selectively open ingress and egress paths. In a microservice scenario, you observe how policy selection, the network plugin, and connection tests work together.

Where are the trust boundaries in a Kubernetes cluster, and how can an attacker progress after initial access? You analyse prepared threat scenarios involving privilege escalation through overprivileged service accounts, malicious code execution through tampered container images, and lateral movement in the cluster network. You then assess persistence as a separate attack phase and map RBAC, NetworkPolicy, and Pod Security to the respective attack vectors.

Falco processes runtime events from configured event sources and evaluates them against rules. The DevNinjas Dojo, our cloud learning environment, provides the lab cluster where you install Falco with Helm and inspect event processing through to an alert using an existing rule. The exercise separates installation, event source, rule matching and output without covering complete Falco operations.

Admission control can reject or change applicable API requests before persistence. You install OPA Gatekeeper with Helm, create a ConstraintTemplate and a Constraint, and inspect their effect on prepared workloads. You then examine Rego and the enforcement point and compare the model with Kyverno's YAML-based policy approach without treating both implementations as equivalent.

Software supply-chain controls answer different questions from transport encryption inside a cluster. You inspect a prepared SBOM, verify an image signature with Cosign, and relate the SBOM contents, signature, and trust anchor to the delivery path. You then distinguish PKI, TLS/mTLS, and a service mesh as controls for communication paths without treating both security areas as equivalent.

A technical check does not prove complete compliance. You map selected requirements from NIST, PCI DSS, and privacy contexts to concrete Kubernetes controls and document missing organizational evidence. With kube-bench, you compare the lab against CIS recommendations and distinguish that result from STRIDE and OCTAVE as threat-modelling approaches.

KCSA is an online-proctored multiple-choice exam with a duration of 90 minutes. You review the weighting of all six domains, mark personal uncertainties, and answer sample questions from every area. You then relate open topics and time management to your further learning path; the exercise replaces neither independent study nor an assessment of individual exam readiness.