View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps

 

Question 281.

A security team wants to ensure that an application pod cannot use a service account token unless the application genuinely requires Kubernetes API access. Which approach BEST supports this goal?

1. Disable automatic service account token mounting for workloads that do not require the API
2. Allow the default service account to read all namespaced resources
3. Mount the namespace service account token through a projected volume in every pod
4. Grant a read-only ClusterRole to all application service accounts

Correct Answer: 1. Disable automatic service account token mounting for workloads that do not require the API

Explanation:

A service account token is a credential, and unnecessary credentials increase the attack surface of a workload. If an application does not communicate with the Kubernetes API, there is no reason to provide it with a token that an attacker could steal after compromising the container. Disabling automatic token mounting removes that unnecessary exposure. Granting read-only access still creates an avoidable API credential, while mounting projected tokens everywhere increases rather than reduces credential presence. Workloads that genuinely need API access should use dedicated service accounts with narrowly scoped RBAC. Short-lived credentials, explicit audience settings where appropriate, audit logging, and regular permission reviews can further reduce risk. The general principle is to avoid distributing authentication material unless it is required for a clearly defined function.

Question 282.

A user needs to inspect Pods and Events in one namespace but must not access Secrets or modify workloads. Which RBAC design is MOST appropriate?

1. Bind the user to a read-only ClusterRole across all namespaces
2. Create a namespace-scoped Role granting only the required read verbs on Pods and Events
3. Grant temporary namespace-admin access and rely on policy documentation
4. Allow the user to impersonate the namespace service account

Correct Answer: 2. Create a namespace-scoped Role granting only the required read verbs on Pods and Events

Explanation:

A namespace-scoped Role allows the organization to define exactly which resources and verbs the user needs without exposing unrelated resources such as Secrets or allowing write operations. The Role can include get, list, and watch on Pods and Events, and a RoleBinding can associate it with the user only in the required namespace. A cluster-wide read role exposes more information than necessary, while namespace-admin provides excessive modification authority. Impersonation can create an additional escalation risk if the impersonated identity has stronger permissions. Least privilege should be enforced at the platform level rather than relying on users to avoid actions they are technically authorized to perform. Kubernetes audit logs can then provide accountability for the read operations performed.

Question 283.

Which Kubernetes permission deserves particularly close scrutiny because it may allow a user to escalate privileges indirectly?

1. Permission to read Service endpoints
2. Permission to view Deployment status
3. Permission to create RoleBindings that can reference powerful roles
4. Permission to list Pods in a development namespace

Correct Answer: 3. Permission to create RoleBindings that can reference powerful roles

Explanation:

Authorization-management permissions can be more dangerous than they initially appear. A user who can create a RoleBinding that references a powerful ClusterRole may be able to grant themselves or another identity access that was not intended. This creates a potential privilege-escalation path even if the user does not initially possess broad permissions. Reading endpoints, viewing status, or listing Pods may expose operational information, but those actions do not usually provide the same direct path to expanded authorization. RBAC reviews should therefore examine how permissions can be combined, not just whether a user currently has cluster-admin. Sensitive binding and role changes should also be monitored through Kubernetes audit logs and, where appropriate, protected by policy or approval workflows.

Question 284.

A company wants to stop developers from deploying pods that run as privileged, use host namespaces, or mount sensitive host paths. Which control is BEST for consistent enforcement?

1. Runtime monitoring after the pods start
2. Namespace naming standards
3. NetworkPolicy rules
4. Admission policy enforcement with explicit workload-security requirements

Correct Answer: 4. Admission policy enforcement with explicit workload-security requirements

Explanation:

Admission enforcement provides a preventive control because workload specifications can be evaluated before Kubernetes accepts and schedules them. Policies can reject privileged containers, hostPID, hostIPC, hostNetwork, unsafe hostPath mounts, missing security contexts, or prohibited capabilities. Runtime monitoring remains valuable for behavior that cannot be predicted from configuration, but it is preferable to prevent known-dangerous settings from reaching runtime. Namespace naming and NetworkPolicies do not control Linux privilege or host resource access. Security policies should be aligned with an organization’s approved workload standards and include a carefully governed exception process for system components that genuinely require elevated access. Exceptions should be narrow, documented, monitored, and reviewed periodically rather than becoming permanent broad bypasses.

Question 285.

An application requires writable storage only for a temporary cache directory. Which configuration BEST minimizes filesystem risk?

1. Use a read-only root filesystem with a dedicated writable volume for the cache
2. Keep the root filesystem writable and run the container as non-root
3. Mount a writable directory from the Kubernetes node for cache storage
4. Enable privileged mode but restrict the application’s network access

Correct Answer: 1. Use a read-only root filesystem with a dedicated writable volume for the cache

Explanation:

A read-only root filesystem reduces the ability of a compromised process to alter application binaries, system files, packaged configuration, or other content in the image. If the application only needs a writable cache, a dedicated volume mounted at that path provides the minimum required write access. Running as non-root is also valuable but does not prevent modification of files the process owns or can access. A host-mounted directory introduces unnecessary node exposure, while privileged mode significantly weakens container isolation. This pattern applies least privilege to filesystem access: only the location that genuinely requires writes is writable. Stronger hardening also includes capability reduction, allowPrivilegeEscalation: false, seccomp, mandatory access control, and controlled temporary storage lifecycle.

Question 286.

A service requires one specific Linux capability but no other elevated privileges. Which configuration is MOST secure?

1. Keep the default capability set because the application may need it later
2. Drop unnecessary capabilities and add back only the specific capability required
3. Run as root and remove the package manager from the image
4. Use privileged mode with a default-deny NetworkPolicy

Correct Answer: 2. Drop unnecessary capabilities and add back only the specific capability required

Explanation:

Linux capabilities allow individual privileged operations to be granted without giving a process the full authority associated with root or privileged mode. If the application requires only one capability, a secure design removes unnecessary capabilities and explicitly adds back the single required one. Retaining a broad default set creates avoidable privilege that an attacker may exploit after compromise. Running as root provides additional authority and does not solve the capability problem. Privileged mode bypasses or weakens many container isolation mechanisms and cannot be made equivalent to least privilege simply by restricting network traffic. Capability management should be combined with non-root execution, seccomp, disabled privilege escalation, and appropriate mandatory access control.

Question 287.

Which pod security setting MOST directly prevents a container process from gaining additional privileges through mechanisms such as setuid executables?

1. allowPrivilegeEscalation: false
2. readOnlyRootFilesystem: true
3. automountServiceAccountToken: false
4. hostNetwork: false

Correct Answer: 1. allowPrivilegeEscalation: false

Explanation:

The allowPrivilegeEscalation setting controls whether a process can gain more privileges than its parent. Setting it to false can block common privilege-gain mechanisms such as setuid binaries or file capabilities. A read-only root filesystem helps prevent tampering and persistence but does not specifically prevent privilege escalation. Disabling service account token mounting protects Kubernetes API credentials, and avoiding host networking preserves network namespace isolation. These are all useful controls, but they address different risks. A secure workload typically combines several restrictions: non-root execution, capability minimization, disabled privilege escalation, seccomp, mandatory access control, and limited writable storage. Layered controls reduce the chance that a single application vulnerability can become a larger container or node compromise.

Question 288.

Which Linux feature is specifically intended to restrict the system calls a containerized process can invoke?

1. AppArmor
2. Kubernetes RBAC
3. NetworkPolicy
4. seccomp

Correct Answer: 4. seccomp

Explanation:

seccomp filters Linux system calls and can reduce the set of kernel operations available to a container process. This lowers attack surface because many applications do not need access to the full syscall interface. Kubernetes supports applying seccomp profiles to workloads, including runtime-default and custom profiles depending on requirements. AppArmor is also a strong Linux security control, but it focuses more broadly on mandatory access rules for process interactions with files and other resources. Kubernetes RBAC governs API authorization, while NetworkPolicy manages network communication. seccomp should be tested carefully because blocking a syscall that an application legitimately requires can cause failures. It works best alongside non-root execution, capability reduction, mandatory access control, and runtime monitoring.

Question 289.

A production image includes build tools, source code, shells, and package managers that are unnecessary at runtime. Which improvement BEST reduces attack surface?

1. Use a multi-stage build and create a minimal final runtime image
2. Keep the tools but block outbound Internet access
3. Keep the full image and rely on a read-only root filesystem
4. Store development tools in a separate directory inside the image

Correct Answer: 1. Use a multi-stage build and create a minimal final runtime image

Explanation:

A multi-stage build allows compilers, package managers, source files, and debugging utilities to remain in an earlier stage while only the application and necessary runtime dependencies are copied into the final image. This reduces both the number of potentially vulnerable components and the tools available to an attacker after compromise. Blocking Internet access or making the filesystem read-only provides useful protection but does not remove unnecessary binaries and libraries. Moving development tools to another directory also leaves them present and potentially usable. Minimal runtime images should still be scanned, signed, patched, and tied to trusted provenance and SBOM data. Image minimization is a preventive supply chain and runtime hardening practice that complements, rather than replaces, other security controls.

Question 290.

Which artifact BEST helps a security team identify all production images containing a specific vulnerable library version?

1. Kubernetes audit logs
2. An SBOM associated with each exact image digest
3. NetworkPolicy manifests
4. Pod readiness status

Correct Answer: 2. An SBOM associated with each exact image digest

Explanation:

An SBOM provides a structured inventory of components and dependency versions included in an artifact. When linked to an exact image digest, it enables security teams to identify which production images contain a newly vulnerable package. This is particularly useful for widely used open-source libraries that may appear across many applications. An SBOM does not automatically determine whether the vulnerability is exploitable, so teams must still assess reachability, exposure, business impact, and available fixes. Audit logs record API activity, NetworkPolicies describe communication rules, and readiness status indicates workload health. None of those sources provides detailed software composition. Accurate SBOM generation and association with immutable artifacts are important components of mature vulnerability and supply chain management.

Question 291.

A deployment references the mutable tag release. Which change BEST ensures that Kubernetes runs the exact image that was approved during security review?

1. Reference the approved image by immutable digest
2. Keep the tag but configure imagePullPolicy: Always
3. Require developers to document every tag update
4. Increase the retention period for registry logs

Correct Answer: 1. Reference the approved image by immutable digest

Explanation:

An immutable digest identifies the exact contents of an image, whereas a mutable tag may later be reassigned to another artifact. If the Deployment references only the tag, a restart may pull different content without any change to the Kubernetes manifest. Digest pinning avoids this ambiguity and strengthens reproducibility, rollback confidence, and incident investigation. imagePullPolicy: Always does not protect integrity when a tag is mutable; it can make the workload more likely to retrieve changed content. Documentation and registry logs improve governance and visibility but do not guarantee artifact identity. Strong supply chain security combines digests with controlled registry writes, signature verification, trusted provenance, vulnerability scanning, and admission policies that enforce approved artifact sources.

Question 292.

Which control BEST verifies that a production image came from an approved build process before it is allowed to run?

1. A PodDisruptionBudget
2. A default-deny NetworkPolicy
3. Admission-time verification of trusted signatures or provenance
4. A namespace ResourceQuota

Correct Answer: 3. Admission-time verification of trusted signatures or provenance

Explanation:

Trusted signatures and build provenance can provide evidence that a container image came from an approved build and release process. Verifying that evidence during admission lets Kubernetes reject workloads that reference artifacts lacking the required trust signals. A PodDisruptionBudget protects availability, a NetworkPolicy controls runtime communication, and a ResourceQuota limits resource consumption. None of those verifies artifact origin. Signature systems are only as trustworthy as the signing keys and workflows behind them, so those assets must be strongly protected. Provenance should also be linked to immutable image identifiers. Admission verification works best when combined with protected source repositories, secure CI/CD systems, trusted registries, SBOMs, vulnerability scanning, and least-privilege release credentials.

Question 293.

A deployment pipeline only needs to update Deployments and Services in one namespace. Which authorization model BEST limits supply chain risk?

1. Give the pipeline a dedicated identity with permissions only for the required resources and namespace
2. Use cluster-admin but require manual approval for each deployment
3. Grant write access to all namespaced resources so future changes do not need RBAC updates
4. Allow the pipeline to create RoleBindings but not ClusterRoleBindings

Correct Answer: 1. Give the pipeline a dedicated identity with permissions only for the required resources and namespace

Explanation:

A pipeline identity should be scoped to the exact resources and environment it manages. If the pipeline only updates Deployments and Services in one namespace, those should be the only relevant permissions. Cluster-admin creates a large blast radius even if manual approval is required. Broad write access increases the damage possible after pipeline compromise, and permission to create RoleBindings may enable indirect privilege escalation depending on which roles can be referenced. Dedicated, narrowly scoped identities also improve auditability and simplify revocation. Short-lived credentials, separate identities for build and deployment stages, protected CI configuration, and audit logging can further reduce supply chain risk. CI/CD should be treated as sensitive infrastructure because it can deliver software through trusted operational paths.

Question 294.

A pipeline credential is accidentally printed in a build log. Which response is MOST appropriate?

1. Delete the current log file and continue using the credential
2. Restrict log access but keep the credential unchanged
3. Rebuild the application image
4. Revoke or rotate the exposed credential and investigate access to the log

Correct Answer: 4. Revoke or rotate the exposed credential and investigate access to the log

Explanation:

A credential exposed in a build log should be treated as potentially compromised because logs may be retained, downloaded, cached, indexed, or replicated. Restricting or deleting the visible log does not guarantee that all copies are gone. Rotating or revoking the credential invalidates any leaked copies. The organization should also review who could access the log, examine authentication or registry activity for suspicious use, and correct the pipeline so secrets are no longer printed. Secret masking, secure credential injection, and careful handling of debug output can reduce recurrence. Rebuilding the application image is necessary only if the credential was also embedded in the artifact; it does not by itself address exposure of the pipeline credential.

Question 295.

A production web container unexpectedly starts a shell and launches a port-scanning tool. How should this behavior be interpreted?

1. As a suspicious runtime anomaly that requires investigation
2. As expected Kubernetes service discovery
3. As evidence that liveness probes are working
4. As a normal effect of image signature verification

Correct Answer: 1. As a suspicious runtime anomaly that requires investigation

Explanation:

A fixed-function production web container should not normally start an interactive shell or perform network scanning. Such behavior may indicate exploitation, unauthorized debugging, credential theft, or lateral movement. Runtime security tools can identify unexpected processes, system calls, network connections, and filesystem changes that differ from the application’s normal behavior. Investigators should review process ancestry, recent deployment changes, service account permissions, image identity, network destinations, and Kubernetes audit logs. Kubernetes service discovery does not require arbitrary port scanning, and health probes do not normally spawn shells. Image signatures confirm artifact authenticity but do not guarantee safe behavior after deployment. Runtime detection is therefore an essential complement to preventive image and workload controls.

Question 296.

A compromised pod is actively communicating with an unknown external server. Which incident-response step is MOST appropriate?

1. Scale the pod to more replicas so traffic can be analyzed across instances
2. Contain or isolate the workload while preserving relevant evidence for investigation
3. Add the server to an allowlist so the application remains available
4. Restart the pod and delete existing logs to remove malicious state

Correct Answer: 2. Contain or isolate the workload while preserving relevant evidence for investigation

Explanation:

Active communication with an unknown external destination may indicate command-and-control activity or data exfiltration. The immediate priority is to contain the workload and limit further damage while preserving evidence. Depending on the environment, responders may apply restrictive network controls, remove the workload from service, record process and network state, preserve audit and application logs, and identify affected credentials. Scaling the workload could replicate malicious behavior. Allowlisting the destination would increase exposure, while restarting and deleting logs can destroy evidence without addressing the root cause. Incident-response procedures should define containment actions in advance and balance operational impact with investigative needs. After containment, the team can eradicate the cause, rotate credentials, rebuild affected workloads, and recover safely.

Question 297.

Which network strategy BEST reduces lateral movement between Kubernetes application tiers?

1. Use default-deny NetworkPolicies and permit only required communication paths
2. Allow all internal traffic but require TLS
3. Put each tier in a separate Deployment without network restrictions
4. Use unique DNS names for each tier

Correct Answer: 1. Use default-deny NetworkPolicies and permit only required communication paths

Explanation:

A default-deny network posture limits communication unless a specific policy permits it. This allows the organization to model expected application flows, such as front end to API and API to database, while preventing unrelated direct connections. TLS is valuable for confidentiality and authentication but does not prevent an unauthorized workload from attempting to connect. Separate Deployments and DNS names organize workloads but are not network security boundaries. Network segmentation reduces the attacker’s options after compromising one service and should be combined with workload identity, application authentication, separate credentials, and runtime monitoring. Effective east-west security assumes that internal traffic is not automatically trustworthy and that each communication path should be explicitly justified.

Question 298.

A pod should communicate externally only with DNS and two approved APIs. Which control BEST limits its outbound reachability?

1. A namespace-scoped Role
2. An egress NetworkPolicy or equivalent outbound filtering mechanism
3. A read-only root filesystem
4. A PodDisruptionBudget

Correct Answer: 2. An egress NetworkPolicy or equivalent outbound filtering mechanism

Explanation:

Egress filtering directly controls which destinations a workload can contact. If a pod requires only DNS and two external APIs, unrestricted Internet access creates unnecessary opportunities for command-and-control communication, malware downloads, scanning, and data exfiltration after compromise. Kubernetes NetworkPolicy can provide egress restrictions when supported by the networking implementation, while more advanced environments may use egress gateways or firewalls for external services with dynamic addressing. RBAC controls Kubernetes API access, read-only filesystems restrict local modification, and PodDisruptionBudgets support availability. These controls do not constrain outbound destinations. Egress rules should be paired with runtime network monitoring so unusual or blocked communication attempts generate useful security visibility.

Question 299.

Which logging strategy BEST supports forensic investigation when compromised pods may disappear before responders begin analysis?

1. Forward application, Kubernetes audit, node, and runtime security telemetry to protected centralized storage
2. Keep all logs in container filesystems to preserve workload context
3. Retain only Kubernetes Events because they are generated centrally
4. Disable long-term retention to reduce storage overhead

Correct Answer: 1. Forward application, Kubernetes audit, node, and runtime security telemetry to protected centralized storage

Explanation:

Containers and pods are ephemeral, so local evidence may disappear when workloads restart, reschedule, scale down, or are deleted by an attacker. Centralized storage preserves telemetry outside the workload lifecycle and enables correlation across multiple sources. Kubernetes audit logs reveal API operations, runtime telemetry captures suspicious processes and network behavior, application logs provide service-level context, and node logs may show host compromise indicators. Kubernetes Events are useful but generally insufficient for detailed forensic reconstruction. Central logging platforms should have strong authorization, encryption, integrity protections, retention policies, and monitoring because they contain sensitive evidence. Effective incident readiness depends on collecting important telemetry before an incident, since evidence that was never retained cannot be recreated afterward.

Question 300.

Which approach BEST represents a mature Kubernetes security program across the complete cloud-native lifecycle?

1. Focus on image scanning and trust artifacts after they pass the initial review
2. Secure the cluster perimeter and permit broad internal access for operational simplicity
3. Use strong RBAC and monitoring but allow CI/CD identities broad privileges
4. Continuously combine identity security, least privilege, workload hardening, software supply chain assurance, network segmentation, policy enforcement, vulnerability management, runtime detection, logging, and incident response

Correct Answer: 4. Continuously combine identity security, least privilege, workload hardening, software supply chain assurance, network segmentation, policy enforcement, vulnerability management, runtime detection, logging, and incident response

Explanation:

A mature Kubernetes security program addresses threats before, during, and after deployment. Identity controls and RBAC limit API access. Workload hardening reduces container privilege and writable attack surface. Supply chain security protects source code, dependencies, build infrastructure, registries, signatures, provenance, and artifact promotion. Admission controls stop known-insecure configurations before execution, while NetworkPolicies restrict lateral movement and unnecessary egress. Continuous vulnerability management is required because new issues may be discovered after deployment. Runtime monitoring and centralized logging provide detection and investigative capabilities when preventive controls fail. Tested incident-response procedures support containment, credential rotation, evidence preservation, eradication, and recovery. Sustainable security depends on continuously maintaining these layers as applications, infrastructure, teams, and threats evolve.