The Kubernetes and Cloud Native Security Associate (KCSA) assesses foundational security knowledge for cloud native environments. This guide connects cluster components, workload controls, and security risks through resolved examples. Each concept explains a specific distinction or decision and identifies a mistake that can weaken your assessment of a Kubernetes environment.
Cloud Native Security Foundations
1. The four layers of cloud native security
The four Cs are cloud, cluster, container, and code. Each layer introduces security responsibilities and dependencies. Infrastructure protection supports the cluster, cluster controls constrain workloads, container settings limit execution privileges, and application code determines how requests and data are handled. A strong control at one layer cannot automatically repair a weakness at another.
Worked example: A payment service has restrictive container privileges but an application authorization flaw. Container hardening limits execution privileges; fixing the authorization logic addresses the exposed customer records.
Mistake to avoid: Treating a hardened cluster as proof that application code is secure.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
2. Shared responsibility in cloud environments
Cloud security responsibilities depend on the service and its documented boundaries. A provider may operate physical infrastructure and selected managed components, while customers still configure identities, workload access, and application data protection. Evaluate each responsibility explicitly because moving to a managed service changes ownership without eliminating security work.
Worked example: A provider manages a cluster's control plane, but a customer grants a workload excessive API permissions. Reviewing that permission grant remains a customer responsibility.
Mistake to avoid: Assuming managed Kubernetes transfers every security responsibility to the provider.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
3. Confidentiality, integrity, and availability
Confidentiality protects information from unauthorized disclosure, integrity protects against unauthorized alteration, and availability preserves usable service. A threat can affect several objectives, but identifying its primary effect helps choose a suitable control. Encryption, access restrictions, integrity verification, and resource protections address different failure modes rather than providing interchangeable protection.
Worked example: An unauthorized configuration edit changes the destination for customer exports. The immediate integrity failure can then cause a confidentiality failure when records reach the wrong destination.
Mistake to avoid: Classifying every security incident as a confidentiality problem.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
4. Preventive, detective, and corrective controls
Preventive controls reduce the chance of an unwanted action, detective controls reveal activity or conditions, and corrective controls support recovery or remediation. Their value depends on placement and operation. Defense in depth combines controls that address different stages of a failure, while recognizing that several controls can share the same underlying dependency.
Worked example: Admission rejects an unsafe workload, monitoring detects an unexpected privileged Pod, and a reviewed deployment restores the approved configuration. These controls serve different purposes.
Mistake to avoid: Counting an alert as a control that blocks the reported action.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
5. Isolation mechanisms and their limits
On Linux, namespaces separate process views of resources, while control groups account for and constrain resource consumption. Containers commonly share the host kernel, whereas virtual machines introduce a guest operating system boundary. Isolation strength depends on the complete configuration, including privileges and host access; a container boundary alone does not establish equivalent protection to every other isolation technique.
Worked example: Two containers see separate process lists but still compete for node memory. Process isolation does not replace appropriate memory controls.
Mistake to avoid: Assuming isolated resource views also guarantee bounded resource consumption.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
6. Artifacts and repositories as trust boundaries
An artifact repository distributes deployable content such as container images. Security assessment must distinguish the artifact's origin, its contents, and the permissions controlling publication and retrieval. A trusted repository can contain an unsafe artifact, and a well-built artifact can become difficult to trust if an attacker can replace its published reference.
Worked example: A private registry accepts images from every developer account. Its private location restricts public access, but broad publishing rights still permit unauthorized replacements.
Mistake to avoid: Equating a private repository with trustworthy contents.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
7. Application input and authorization boundaries
Application security includes validating input, applying authorization to requested actions, and avoiding unsafe interpretation of user-controlled data. Infrastructure controls cannot determine every business permission. Parameterized data access helps separate input from executable queries, while object-level authorization verifies whether the authenticated caller may access the specific requested record.
Worked example: A user changes an invoice identifier in a request. Checking ownership before returning the invoice prevents access to another customer's data.
Mistake to avoid: Assuming successful login authorizes access to every application object.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
8. Image contents and running container state
An image packages filesystem content and execution configuration. A running container adds runtime state and may receive mounted files, credentials, or other configuration. Image inspection therefore describes only part of the deployed security posture. Changes inside a running container also do not automatically update the image used to create its replacement.
Worked example: An approved image runs with a sensitive host directory mounted into it. The additional exposure comes from deployment configuration, despite the image remaining unchanged.
Mistake to avoid: Assessing workload security exclusively from the image.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
Securing Kubernetes Cluster Components
9. The API server's request control sequence
The API server is the management entry point for Kubernetes resources. Authentication establishes the caller, authorization evaluates permission, and applicable admission checks evaluate proposed changes before persistence. These stages answer different questions. Permission to create a resource does not guarantee that its configuration will satisfy admission rules or successfully run.
Worked example: An authenticated developer may create Pods, but admission rejects a Pod requesting prohibited host access. Identity and permission checks succeeded; the configuration check failed.
Mistake to avoid: Treating every rejected API request as an authentication failure.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
10. Controller permissions and reconciliation
Controllers repeatedly act to bring observed state toward desired state. Their credentials need permissions appropriate to the resources they manage. A compromised controller can misuse those permissions, and an unsafe desired configuration can be recreated after manual removal. Assess both controller authority and the source of the state it reconciles.
Worked example: Deleting an unsafe Pod does not resolve exposure when its Deployment still requests the same configuration. The controller creates a replacement from that template.
Mistake to avoid: Removing a managed object without correcting its owning configuration.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
11. Scheduling and security-sensitive placement
The scheduler selects nodes for unassigned Pods using resource requirements and placement constraints. Security-sensitive workloads may need separation from less trusted workloads or specific node capabilities. Placement labels must have trustworthy administration because a rule based on an attacker-controlled label provides weak assurance. Scheduling also does not remove a workload's dangerous privileges.
Worked example: A confidential workload targets a restricted node group. That placement is meaningful only if unauthorized identities cannot relabel ordinary nodes as members of the group.
Mistake to avoid: Treating a descriptive node label as an independently trusted security boundary.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
12. The kubelet as a node execution boundary
The kubelet manages assigned Pod execution on a node and reports status to the control plane. Its interfaces and credentials are security-sensitive because they relate directly to running workloads. Protecting access requires appropriate authentication, authorization, and network restrictions. Compromise of a node component can expose workloads beyond the attacker's original application.
Worked example: A monitoring client needs limited node information. Granting broad kubelet access could expose additional workload operations that the monitoring function does not require.
Mistake to avoid: Treating kubelet interfaces as harmless because they are outside normal application traffic.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
13. Container runtimes and privileged control sockets
The container runtime performs operations such as starting containers under kubelet direction. Kubernetes communicates with compatible runtimes through the Container Runtime Interface. Runtime control interfaces are highly privileged and should not be exposed to ordinary workloads. Image format compatibility concerns packaging; access to the runtime concerns authority over execution on a node.
Worked example: A build helper requests access to a node's runtime socket. That access would cross from application activity into privileged container management and needs a different security assessment.
Mistake to avoid: Treating a runtime socket as an ordinary shared file.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
14. Service forwarding and kube-proxy
In clusters using kube-proxy, it implements Service traffic forwarding through node networking mechanisms. Other networking implementations may provide equivalent Service handling differently. A Service offers a stable access path to backends; it does not inherently authenticate clients or encrypt traffic. Assess forwarding behavior separately from policies and application security.
Worked example: A Service accepts connections on port 443 and forwards to backend port 8080. The port number alone does not prove that either connection uses TLS.
Mistake to avoid: Inferring encryption from a Service port or from Service existence.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
15. Pods as shared security contexts
Containers within a Pod share a network namespace and can share declared volumes. This close relationship matters when assigning trust: an auxiliary container may reach local application ports or read shared files. Separating containers into one Pod is an operational arrangement, but does not provide the same boundaries as placing independently trusted workloads in separate Pods.
Worked example: An application listens on localhost without authentication. A logging sidecar in the same Pod can reach that listener through the shared network namespace.
Mistake to avoid: Assuming each container in a Pod has an independent network boundary.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
16. etcd and the sensitivity of cluster state
etcd stores Kubernetes cluster state, including resource definitions and potentially sensitive information. Direct access can bypass the ordinary API access path, making its network exposure, authentication, storage protection, and backups important. Application data stored in external databases or volumes has a separate lifecycle and is not automatically recovered by restoring cluster state.
Worked example: An operator protects live etcd access but leaves its backup broadly readable. The backup can disclose sensitive cluster information despite the live service's restrictions.
Mistake to avoid: Applying weaker protection to backups than to the stored state they contain.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
17. Container networking and enforcement capabilities
Cluster networking connects Pods and supports communication with Services and external destinations. NetworkPolicy enforcement depends on the installed networking implementation and its capabilities. Basic connectivity does not prove that security policies are enforced. Evaluate the networking layer's supported controls and verify intended allowed and blocked paths using controlled observations.
Worked example: An application remains reachable after a restrictive NetworkPolicy is created. A networking implementation without policy enforcement can explain the unchanged reachability.
Mistake to avoid: Assuming API acceptance of a policy proves data-plane enforcement.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
18. Client configuration and credential safety
Kubernetes client configuration identifies clusters, credentials, and contexts. A context determines the target environment and identity for requests. Client configuration can also reference credential helpers, so configuration obtained from an untrusted source needs inspection before use. Protect credential files and verify server trust rather than weakening certificate verification to resolve connection problems.
Worked example: A user selects a production context while intending to inspect a development cluster. Checking the context reveals the wrong target before any change is submitted.
Mistake to avoid: Treating externally obtained client configuration as inert connection information.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
19. Storage lifecycle and data retention
Persistent storage can outlive individual Pods, while ephemeral storage commonly follows a Pod's lifecycle. Deleting a workload therefore does not establish that its data has been removed. PersistentVolume reclaim behavior and backend retention determine what happens after claims are released or deleted. Security assessment must include residual data and approved retention requirements.
Worked example: A temporary analysis Pod is deleted, but its persistent volume remains retained. Sensitive exports still require controlled handling under the storage retention policy.
Mistake to avoid: Using workload deletion as evidence that stored data no longer exists.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
20. Storage permissions and data protection
Storage access involves several controls: API permission to configure volumes, backend authorization, filesystem permissions, and encryption where required. Access modes describe supported mounting arrangements and do not establish data confidentiality or safe concurrent application access. Restrict the entire path by which identities can attach, mount, read, or recover sensitive storage.
Worked example: A volume mounted read-only still exposes its records to the consuming process. Read-only access protects against writes through that mount, not against disclosure.
Mistake to avoid: Interpreting a storage access mode as a complete confidentiality control.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
21. Component credentials and trust relationships
Cluster components authenticate to one another using credentials appropriate to their roles. Distinct identities support limited permissions, attribution, and independent credential replacement. Protect private keys and tokens, and assess what each identity can do if compromised. Encrypted communication protects a connection but does not justify excessive privileges for its authenticated participant.
Worked example: Two controllers share a broad credential. Separating their identities allows one controller's access to be restricted and replaced without granting the other unnecessary authority.
Mistake to avoid: Assuming a trusted component needs unrestricted cluster access.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
Kubernetes Security Controls
22. Pod Security Standards
Pod Security Standards define Privileged, Baseline, and Restricted policy profiles. They express progressively different constraints on Pod configuration. Privileged permits unrestricted configurations; it does not itself enable privileges in every Pod. Restricted aims for stronger workload constraints, with applicable requirements depending on factors such as operating system and the selected policy version.
Worked example: A Pod passes Baseline but requests a setting disallowed by Restricted. Passing one profile does not demonstrate compliance with the stricter profile.
Mistake to avoid: Treating the profile name as an automatic grant of container privileges.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
23. Pod Security Admission modes
Pod Security Admission applies Pod Security Standards through enforce, audit, and warn modes. Enforce can reject violating Pod requests, audit records violations, and warn returns warnings. Namespace configuration selects the applicable modes, levels, and versions; exemptions also matter. Observing a warning alone does not establish that deployment was blocked.
Worked example: A namespace warns about Restricted violations while enforcing Baseline. A Baseline-compliant Pod can be admitted even when it receives a Restricted warning.
Mistake to avoid: Assuming warn mode provides the same prevention as enforce mode.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
24. Authentication establishes an API identity
Authentication determines who or what is making an API request. Kubernetes can accept different configured credential mechanisms, including certificates and tokens. A valid credential establishes an identity, while subsequent authorization determines permitted actions. Credential protection, expiry, and replacement need separate consideration because possession of a usable credential can enable impersonation of its owner.
Worked example: A valid workload token identifies a service account, but a request to list Secrets is denied because that identity lacks the required permission.
Mistake to avoid: Treating credential validity as permission to perform the requested operation.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
25. Authorization evaluates the requested action
Authorization evaluates whether an authenticated identity may perform an action on a resource or API path. Resource type, verb, namespace, and sometimes resource name influence the decision. Reading, listing, creating, and deleting are distinct permissions. Diagnose authorization by identifying the complete requested action rather than considering only whether the caller can access the cluster.
Worked example: An analyst can get one named ConfigMap but cannot list ConfigMaps. Permission for a specific read does not automatically allow collection-wide discovery.
Mistake to avoid: Using one successful API operation to infer unrelated permissions.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
26. Roles and ClusterRoles
A Role defines permissions within a namespace. A ClusterRole can describe cluster-scoped permissions or permissions usable across namespaces, depending on its rules and binding. RBAC rules are additive grants rather than explicit denials. Define the smallest useful set of resources and verbs, paying attention to collection reads and sensitive resources.
Worked example: A support role grants reading Pods in a team namespace. It need not include reading Secrets or modifying Deployments to perform that task.
Mistake to avoid: Adding wildcard resources or verbs merely to avoid investigating missing permissions.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
27. RoleBinding and ClusterRoleBinding scope
Bindings connect subjects to roles. A RoleBinding grants permissions within its namespace and can reference either a Role there or a ClusterRole. A ClusterRoleBinding grants the referenced ClusterRole's permissions cluster-wide. The scope follows the binding as well as the role's rules, so reusing a ClusterRole does not always require a cluster-wide grant.
Worked example: A RoleBinding references a Pod-reading ClusterRole in the analytics namespace. The resulting grant does not extend Pod reading to every other namespace.
Mistake to avoid: Assuming every reference to a ClusterRole creates cluster-wide access.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
28. Indirect privilege through workload creation
API permissions can provide indirect access beyond the resource directly named in a rule. Creating workloads may allow use of service accounts, mounted Secrets, or available storage, subject to admission and other controls. Assess the resulting execution capabilities rather than assuming that lack of direct Secret-read permission prevents every path to sensitive values.
Worked example: A user cannot read Secrets directly but can create a Pod that mounts an available Secret. Without additional restrictions, the workload can expose its contents.
Mistake to avoid: Evaluating permissions independently without considering capabilities they enable together.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
29. Service accounts and workload API access
Service accounts identify workloads to the Kubernetes API. Select an identity with permissions appropriate to the workload rather than sharing a broadly privileged account. If an application does not need API access, disabling automatic service account token mounting reduces credential exposure. Token presence, token validity, and RBAC permissions remain separate security questions.
Worked example: A static web server makes no Kubernetes API calls. Omitting its automatically mounted API token removes a credential that a compromised server could otherwise try to use.
Mistake to avoid: Granting every workload the same administrative service account.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
30. Secret encoding and encryption at rest
Secret data is commonly represented using base64, which is an encoding rather than encryption. Confidentiality also depends on API authorization and configured protection of stored data. Encryption at rest protects stored representations under its configured scheme; it does not prevent an authorized API caller or consuming workload from receiving the Secret's usable value.
Worked example: A Secret value remains available to an authorized application even when its stored representation is encrypted. The application needs the plaintext value to use the credential.
Mistake to avoid: Treating base64 or storage encryption as a substitute for access control.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
31. Secret exposure and credential replacement
Sensitive values can escape through application logs, diagnostic output, environment inspection, or shared files. Limit which workloads receive each Secret and avoid recording its contents. Replacing a Secret object does not necessarily revoke the old credential at its issuing system, and consumers may need an appropriate reload or restart mechanism to use the replacement.
Worked example: A database password appears in logs. Recovery requires revoking or replacing that database credential and updating consumers, not merely deleting the log entry.
Mistake to avoid: Assuming a Kubernetes Secret update automatically invalidates the old external credential.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
32. Namespaces and layered segmentation
Namespaces scope many resource names and policies, helping organize permissions, quotas, and workload management. They do not automatically isolate network traffic or eliminate shared-node risks. Effective segmentation combines appropriate RBAC, networking controls, workload restrictions, and infrastructure boundaries according to the trust relationship between tenants or applications.
Worked example: Two teams use different namespaces but can still connect between Pods when networking allows it. Namespace separation alone does not establish traffic isolation.
Mistake to avoid: Calling a namespace a complete security boundary without assessing supporting controls.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
33. Audit logging and sensitive event content
Kubernetes audit logging records API activity according to the configured audit policy and backend. Events can support attribution by showing identity, action, target, and outcome. Detailed request or response capture may include sensitive content, so select appropriate logging levels, protect access, and preserve useful evidence without unnecessarily duplicating Secrets into logs.
Worked example: An investigation needs to identify who changed a Deployment. Audit metadata can attribute the change without requiring every sensitive API response to be retained.
Mistake to avoid: Collecting maximum detail everywhere without considering sensitive log contents.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
34. NetworkPolicy selection and additive allowances
With a supporting network implementation, NetworkPolicy isolates selected Pods for the directions covered by applicable policies. Allowed traffic is the union of applicable allowances. When source egress and destination ingress are both isolated, both must permit a connection. Standard NetworkPolicy does not provide application authentication, encryption, or HTTP-level authorization.
Worked example: A destination allows incoming API traffic, but the source's egress policy blocks that destination. The connection remains blocked because both directional requirements must be satisfied.
Mistake to avoid: Assuming one restrictive policy overrides a broader allowance in another applicable policy.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
Threats and Workload Hardening
35. Trust boundaries and data flow
A trust boundary marks a change in authority, ownership, or assumptions about data. Map how requests, credentials, and artifacts move between users, services, cluster components, and external systems. At each crossing, ask which identity is accepted, which data is validated, and which authority is granted. Internal location alone does not establish trust.
Worked example: A frontend forwards a user-provided account identifier to a backend. The backend must validate authorization because crossing an internal network does not make that identifier trustworthy.
Mistake to avoid: Trusting every request originating from inside the cluster.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
36. Persistence across workload replacement
Persistence lets an attacker retain influence after a process or container is replaced. Relevant locations include workload templates, stored credentials, scheduled workloads, persistent storage, and deployment sources. Recreating a container addresses its transient state, but cannot remove an attacker's changes that are reintroduced by controllers or external configuration systems.
Worked example: A replaced container returns with the same malicious startup configuration because its Deployment template was altered. The durable configuration is the persistence mechanism.
Mistake to avoid: Treating a container restart as proof that attacker persistence has ended.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
37. Denial of service and resource controls
Denial of service can arise from resource exhaustion at workload, node, namespace, or control-plane boundaries. Requests inform scheduling, limits constrain supported resource consumption, and quotas restrict aggregate namespace usage or object counts. These controls address different problems and must be assessed together with actual capacity and critical service dependencies.
Worked example: Three Pods requesting 600 millicores each total 1,800 millicores. A namespace request quota of 1,500 millicores cannot accommodate all three under those requests.
Mistake to avoid: Assuming namespace quota creates additional node capacity.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
38. Compromised applications and blast radius
Malicious code executing inside an application inherits the resources and credentials available to that process. Its reach depends on service account permissions, mounted data, network access, and operating-system privileges. Assess these capabilities to estimate blast radius. Application compromise does not necessarily imply node compromise, but excessive privileges can connect those boundaries.
Worked example: A compromised reporting service can read its mounted export files but lacks API credentials and access to the payment network. Those restrictions limit additional exposure.
Mistake to avoid: Assuming application compromise either exposes nothing else or automatically exposes everything.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
39. Attackers on the network
A network attacker may observe, redirect, or interfere with traffic where available controls permit it. Encryption with correct peer verification protects communication against important interception risks, while network restrictions limit reachable paths. Neither control replaces application authorization. A permitted connection can still carry an unauthorized request or malicious payload.
Worked example: TLS protects a connection to a verified service, but that service still checks whether the caller may download the requested customer record.
Mistake to avoid: Treating encrypted transport as authorization for application actions.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
40. Sensitive data exposure paths
Sensitive data can appear in API objects, mounted volumes, process memory, backups, application responses, and telemetry. Threat assessment follows each copy and access path rather than focusing only on the primary database. Controls should minimize unnecessary duplication and restrict readers while considering legitimate operational needs such as recovery and investigation.
Worked example: A restricted database feeds a diagnostic report stored in a broadly readable volume. The report creates a separate disclosure path despite strong database access controls.
Mistake to avoid: Assessing only the original location of sensitive information.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
41. Host access and privilege escalation
Privileged execution, host namespace sharing, and host filesystem mounts can weaken the boundary between a workload and its node. Evaluate each requested capability against a concrete function and the data or interfaces it exposes. Running as a non-root user helps in suitable environments, but does not compensate for every powerful host access grant.
Worked example: A non-root container receives access to a sensitive host control interface. Its user identifier alone does not neutralize the authority available through that interface.
Mistake to avoid: Using non-root execution as the sole measure of workload isolation.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
42. Linux capabilities and privilege growth
Linux capabilities divide selected privileged operations into more specific authorities. Dropping unnecessary capabilities reduces what a compromised process can do. Preventing privilege escalation addresses certain ways a process can gain additional privileges during execution. These controls complement the configured user identity and require compatibility with the application's legitimate operating-system needs.
Worked example: A service performs ordinary file processing and needs no special kernel privileges. Removing unnecessary capabilities narrows its authority without changing its business function.
Mistake to avoid: Adding broad capabilities to solve an unexplained permission error.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
43. Read-only filesystems and writable data paths
A read-only container root filesystem limits writes to the image-backed filesystem and can reduce opportunities for modification. Applications that require temporary or persistent writes need explicitly designed writable locations. Writable mounts remain writable according to their own configuration. The control does not prevent memory-only malicious activity or unauthorized reads.
Worked example: A document converter uses a read-only root filesystem and a dedicated temporary volume. It can create working files there while leaving image-backed paths protected from writes.
Mistake to avoid: Assuming a read-only root filesystem makes every mounted volume read-only.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
44. System-call filtering with seccomp
On supported Linux environments, seccomp restricts which system calls a process can invoke. This can reduce exposed kernel functionality, but does not repair application vulnerabilities or replace access controls. A suitable profile must allow legitimate workload behavior. Compatibility assessment distinguishes expected application needs from attempts to use prohibited operating-system operations.
Worked example: A service fails when a required operation is blocked by its seccomp profile. Reviewing the profile against the service's genuine needs resolves the mismatch without disabling every restriction.
Mistake to avoid: Assuming system-call filtering makes vulnerable application logic safe.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
Platform and Supply Chain Security
45. Build provenance and artifact traceability
Provenance records how an artifact was produced, including relevant source, builder, and inputs. It helps connect deployed content to an expected build process. Useful assessment requires checking the provenance's authenticity and whether its claims satisfy policy. A documented build history cannot establish trust if the builder or evidence can be altered without detection.
Worked example: An image claims to originate from an approved repository, but its provenance identifies an unexpected builder. The mismatch requires review before the artifact is trusted.
Mistake to avoid: Accepting provenance claims without checking who produced and authenticated them.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
46. Software inventories and vulnerability findings
A software bill of materials describes components in an artifact and supports dependency analysis. Vulnerability scanning compares detected components with known findings. Evaluate applicability using the affected component, version, usage, and available remediation evidence. Inventories can be incomplete, and a clean scan reflects the scanner's knowledge and coverage rather than proving absence of vulnerabilities.
Worked example: A scan flags a library included in an image. Assessment checks whether the affected functionality is used and identifies an appropriate fixed dependency or compensating control.
Mistake to avoid: Treating either an SBOM or a clean scan as a security guarantee.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
47. Artifact signatures and signer trust
An artifact signature connects content to a signing identity under a verification scheme. Trust requires verifying the signature and deciding whether the signer is authorized for that artifact and purpose. Signing does not inspect application behavior or remove vulnerabilities. Protect signing authority because misuse can authenticate harmful artifacts as originating from a trusted publisher.
Worked example: An image has a valid signature from an unrelated team. Verification succeeds cryptographically, but the signer does not satisfy the deployment's approved publisher policy.
Mistake to avoid: Equating a valid signature with approval for every environment.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
48. Registry pull and publication permissions
Registry permissions should distinguish downloading artifacts from publishing, replacing, or deleting them. A workload that only pulls images does not need publication rights. Restrict credentials to appropriate repositories and operations, and consider how compromised build systems could affect release content. Repository access control protects distribution authority separately from artifact inspection.
Worked example: A production workload receives read-only access to its release repository. Compromise of that credential cannot directly publish a replacement image through the same permission grant.
Mistake to avoid: Reusing a broad publishing credential for routine workload image pulls.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
49. Image tags, digests, and reproducible selection
A tag is a readable image reference that can be moved to different content. A digest identifies particular image content and improves reproducible artifact selection. Digest pinning does not establish publisher trust or vulnerability status. A pinned deployment also needs an intentional update process so reproducibility does not become indefinite retention of a known unsafe artifact.
Worked example: Two deployments use the same movable tag but pull different releases. Selecting the reviewed digest makes the intended content explicit for both deployments.
Mistake to avoid: Assuming a stable-looking tag identifies immutable image content.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
50. Security observability and evidence correlation
Metrics summarize behavior, logs describe events, and traces connect operations across components. Security investigation combines these signals with identities, resource identifiers, and timestamps. A symptom such as elevated errors does not establish an attack without context. Protect telemetry access because collected request details and operational metadata can themselves contain sensitive information.
Worked example: A burst of denied API requests is correlated with one workload identity and a recent deployment change. The combined evidence supports a focused investigation of that workload.
Mistake to avoid: Inferring malicious activity from a single unexplained metric increase.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
51. Service mesh identity and mutual TLS
A service mesh can provide workload identity, traffic policy, and telemetry, depending on its implementation and configuration. Mutual TLS authenticates both connection peers and encrypts their communication. Assess coverage because traffic outside the mesh's protected paths may have different properties. Peer authentication still needs authorization rules governing which service interactions are permitted.
Worked example: Two meshed services establish mutual TLS, but a policy must still determine whether the reporting service may call the administrative endpoint.
Mistake to avoid: Assuming mutual TLS automatically authorizes every authenticated service to communicate.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
52. PKI validation and private-key protection
Public key infrastructure supports identity verification through certificates and trust relationships. Certificate validation checks relevant conditions such as the trust chain, intended peer identity, and validity period. Private-key possession enables use of the associated identity, so keys need controlled access and replacement when compromised. Encryption without proper peer validation can connect securely to the wrong party.
Worked example: A certificate chains to a trusted authority but identifies a different server name. The client should reject it for the intended connection.
Mistake to avoid: Checking certificate trust while ignoring whether it identifies the expected peer.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
53. Diagnosing connectivity by boundary
Connectivity diagnosis separates name resolution, routing, policy enforcement, transport establishment, TLS verification, and application authorization. Evidence from one stage does not establish success at the next. Identify the first failing boundary and assess its controls before changing unrelated settings. This prevents broad security exceptions from becoming an accidental troubleshooting method.
Worked example: A service name resolves correctly, but TLS rejects the certificate's identity. DNS works; the remaining failure concerns peer verification rather than name resolution.
Mistake to avoid: Disabling security controls before identifying which connection stage failed.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
54. Admission policy as a deployment gate
Admission controls evaluate applicable API changes before they are persisted. Mutating admission can alter requests, while validating admission can reject configurations that violate policy. Assessment includes policy scope, exemptions, dependencies, and configured failure behavior. Admission governs entry into the system; it does not continuously prove that runtime behavior remains safe.
Worked example: A policy rejects images from unapproved repositories. An admitted application can still contain a logic flaw, so repository enforcement is only one part of its security assessment.
Mistake to avoid: Treating successful admission as continuing verification of runtime behavior.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
Security Frameworks and Evidence
55. Mapping framework requirements to controls
A security or compliance framework organizes requirements and assessment expectations. Translate each applicable requirement into concrete controls, responsible owners, and evidence. A framework label does not establish compliance by itself, and technical implementation must match the defined scope. Avoid assuming that one framework's terminology or assessment results automatically satisfy another.
Worked example: An access-control requirement maps to reviewed RBAC grants, an approval process, and retained review records. The Role objects alone do not demonstrate the complete process.
Mistake to avoid: Treating deployment of a security tool as proof of framework compliance.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
56. Structured threat modeling
Threat modeling systematically relates assets, data flows, trust boundaries, and attacker capabilities to plausible failures. A framework such as STRIDE prompts consideration of spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Categories guide analysis, but useful findings identify a specific path, consequence, and mitigation rather than merely assigning a label.
Worked example: A build identity can overwrite release artifacts. The model identifies a tampering path and recommends restricting publication authority and verifying approved artifact provenance.
Mistake to avoid: Listing threat categories without connecting them to the actual architecture.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
57. Supply chain compliance evidence
Supply chain compliance connects software acquisition and delivery to applicable organizational requirements. Evidence may include approved dependencies, license information, provenance, review records, and vulnerability dispositions. Preserve the relationship between evidence and the exact released artifact. An assessment of one build cannot automatically demonstrate the status of a later build with changed inputs.
Worked example: A release adds a new dependency after its previous review. The earlier approval does not cover the changed component inventory, so updated evidence is required.
Mistake to avoid: Applying an old artifact review to every subsequent release.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
58. Automated checks and configuration drift
Automation can evaluate configuration against defined requirements and repeatedly detect departures from approved state. Its conclusions depend on rule quality, coverage, available permissions, and current observations. Drift detection identifies a difference; deciding whether that difference is acceptable requires context. Remediation should preserve legitimate changes and avoid blindly imposing outdated desired state.
Worked example: A check detects a newly added RBAC grant. Review finds that it bypassed approval, so the grant is corrected and its origin investigated.
Mistake to avoid: Assuming an automated pass covers requirements the tool never evaluated.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
59. Control design, operation, and evidence scope
A control can be well designed yet fail to operate consistently. Assessment distinguishes intended policy, actual configuration, and observed operation over the relevant scope and period. Evidence must support the claim being made: a screenshot of one namespace cannot establish cluster-wide enforcement. Exceptions need explicit scope and rationale rather than disappearing from the assessment.
Worked example: One namespace enforces Restricted Pod settings while another is exempt. Evidence supports the first namespace's enforcement, not an unqualified claim covering every workload.
Mistake to avoid: Generalizing a narrow sample into an unsupported system-wide conclusion.
Source reference: Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
60. Incident evidence and controlled containment
Incident response balances limiting ongoing harm with preserving information needed to understand the event. Kubernetes audit records, workload logs, deployment history, and relevant timestamps can help reconstruct activity. Follow the organization's authorized response process, record actions, and protect collected evidence. Restarting or replacing resources may remove transient evidence without resolving the underlying exposure.
Worked example: Unexpected API activity involves a workload identity. Responders preserve relevant records and document an authorized access restriction before investigating how the credential was exposed.
Mistake to avoid: Deleting affected resources immediately without considering evidence loss or continued access.
Source reference: Kubernetes and Cloud Security Associate (KCSA) | CNCF; Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
Sources
Exam identity and scope verified:
- Kubernetes and Cloud Native Security Associate (KCSA) - Linux Foundation - Education
- Kubernetes and Cloud Security Associate (KCSA) | CNCF