View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps

 

Question 141.

A Kubernetes security team wants to ensure that only approved workloads can run with access to the host network namespace. Which approach BEST supports this requirement?

1. Enforce an admission policy that denies hostNetwork except for explicitly approved workloads
2. Increase pod replicas
3. Add more ConfigMaps
4. Disable audit logging

Correct Answer: 1. Enforce an admission policy that denies hostNetwork except for explicitly approved workloads

Explanation:

Using hostNetwork places a pod in the node’s network namespace and therefore reduces normal network isolation between the workload and the host. Ordinary application workloads rarely require this level of access. An admission policy can reject requests that enable host networking unless they match a narrowly controlled exception. This provides preventive enforcement before the workload reaches runtime. Approved exceptions should still receive additional review because host-level networking can expose sensitive ports, interfaces, or node services. The organization should also apply least-privilege RBAC, capability reduction, runtime monitoring, and restrictive network controls where practical. Increasing replicas or ConfigMaps does not address host namespace risk, while disabling audit logs would reduce visibility into attempts to deploy unsafe configurations.

Question 142.

A production application does not require access to processes running on the Kubernetes node. Which pod setting should generally remain disabled?

1. runAsNonRoot
2. hostPID
3. readOnlyRootFilesystem
4. allowPrivilegeEscalation: false

Correct Answer: 2. hostPID

Explanation:

Enabling hostPID allows processes in the pod to share the node’s process namespace. This can expose information about host processes and other workloads and may provide useful information to an attacker attempting privilege escalation or lateral movement. Most ordinary applications have no need to inspect node-level processes, so hostPID should generally remain disabled. Workloads that legitimately require host process visibility, such as certain monitoring or security tools, should be treated as privileged exceptions and tightly controlled. By contrast, runAsNonRoot, readOnlyRootFilesystem, and allowPrivilegeEscalation: false are generally hardening measures rather than risky host-access settings. The goal is to minimize unnecessary interaction between application containers and the underlying Kubernetes node.

Question 143.

Which control can MOST directly prevent a workload from mounting arbitrary directories from the Kubernetes node into a pod?

1. A policy restricting or denying unsafe hostPath volumes
2. Horizontal Pod Autoscaling
3. Service discovery
4. ReplicaSets

Correct Answer: 1. A policy restricting or denying unsafe hostPath volumes

Explanation:

A hostPath volume exposes a directory or file from the Kubernetes node directly inside a pod. Depending on the mounted path and permissions, this can expose sensitive host files, runtime sockets, configuration, credentials, or device interfaces. A compromised container may then be able to read or modify node resources. Admission policies can restrict hostPath entirely or allow only narrowly approved paths for trusted system workloads. Where hostPath access is unavoidable, read-only mounts, restricted privileges, dedicated nodes, and enhanced monitoring may reduce risk. Autoscaling, service discovery, and ReplicaSets do not govern which host filesystem paths workloads can access and therefore do not mitigate this class of exposure.

Question 144.

A security team wants to reject Kubernetes workloads that fail to define required container security settings. Which mechanism is BEST suited to enforce this consistently?

1. Ingress
2. PersistentVolumeClaims
3. Admission policy enforcement
4. Horizontal Pod Autoscaling

Correct Answer: 3. Admission policy enforcement

Explanation:

Admission policies can examine Kubernetes workload specifications before they are accepted into the cluster. They can require settings such as non-root execution, blocked privilege escalation, approved seccomp profiles, restricted capabilities, read-only filesystems, or trusted image sources. This approach creates centralized and consistent enforcement instead of relying on each developer to remember every hardening requirement manually. CI/CD checks can provide an earlier feedback layer, but admission remains valuable as a cluster-side control because requests may come from multiple deployment paths. Runtime monitoring is also necessary for behavior that configuration policies cannot predict. Ingress, storage claims, and autoscaling manage unrelated networking, storage, and capacity concerns and do not enforce workload security requirements.

Question 145.

Which Kubernetes security concept defines standardized pod security profiles such as Baseline and Restricted?

1. Pod Security Standards
2. ServiceAccounts
3. NetworkPolicies
4. StorageClasses

Correct Answer: 1. Pod Security Standards

Explanation:

Kubernetes Pod Security Standards define commonly understood security profiles for workload configuration. The Baseline profile prevents many known privilege-escalation techniques while remaining broadly compatible with common applications. The Restricted profile is more stringent and reflects current pod-hardening practices, including stronger controls around privilege, capabilities, and non-root execution. These standards provide a consistent vocabulary for workload security and can be enforced through supported admission mechanisms. They do not replace image scanning, RBAC, NetworkPolicies, supply chain protections, or runtime detection. Security teams should also consider how exceptions are approved and monitored because some system-level workloads may legitimately require settings that ordinary application pods should not use.

Question 146.

A container image defines a root user, but the application is capable of running without root privileges. Which change BEST improves its security posture?

1. Enable privileged mode
2. Rebuild or configure the image to run as a non-root user
3. Mount / from the host
4. Add all Linux capabilities

Correct Answer: 2. Rebuild or configure the image to run as a non-root user

Explanation:

Running applications as a non-root user reduces the authority available to a compromised process. The image should be designed so its files, directories, and application ports work correctly without UID 0. Kubernetes can reinforce this with security context settings such as runAsNonRoot and an explicit user ID. Non-root execution should be combined with capability reduction, allowPrivilegeEscalation: false, seccomp, and read-only filesystem configuration where practical. Although container isolation separates processes from the host, root inside a container can still increase the impact of vulnerabilities or unsafe configuration. Privileged mode, host filesystem mounts, and adding capabilities all increase privilege and therefore move in the opposite direction from secure container design.

Question 147.

A security architect wants to reduce the number of kernel operations available to compromised container processes. Which control is MOST appropriate?

1. seccomp profiles
2. Service selectors
3. Deployment labels
4. ConfigMaps

Correct Answer: 1. seccomp profiles

Explanation:

seccomp restricts which Linux system calls a process may invoke. Containers frequently need only a subset of the kernel’s available system calls, so reducing that set can decrease exposure to dangerous or unnecessary kernel functionality. A default or custom seccomp profile can prevent operations that the application never legitimately requires. Profiles should be tested carefully because overly restrictive rules can break valid application behavior. seccomp is most effective as part of layered hardening that also includes non-root execution, restricted Linux capabilities, AppArmor or SELinux, read-only filesystems, and strong runtime monitoring. Kubernetes labels, selectors, and ConfigMaps do not restrict system calls and therefore cannot provide the same kernel-level protection.

Question 148.

Which security mechanism can enforce additional restrictions on container access to files and system resources even when normal Unix permissions would allow access?

1. Horizontal Pod Autoscaler
2. AppArmor or SELinux
3. CoreDNS
4. ReplicaSet

Correct Answer: 2. AppArmor or SELinux

Explanation:

AppArmor and SELinux implement mandatory access control on supported Linux systems. They can constrain which files, devices, capabilities, and operations a process may access even when ordinary discretionary permissions might permit them. This creates an additional containment layer for compromised workloads. AppArmor generally uses path-oriented profiles, while SELinux uses labels and policy rules, but both can significantly restrict process behavior when configured correctly. Policies should be tested because incorrect rules can interfere with legitimate application functionality. Mandatory access control complements seccomp, Linux capability reduction, non-root execution, and admission policies. Autoscaling, DNS, and ReplicaSets are operational Kubernetes features and do not enforce process-level mandatory access restrictions.

Question 149.

A security team wants to stop production workloads from receiving unnecessary Linux capabilities by default. Which configuration strategy is BEST?

1. Drop broad capability sets and add back only capabilities explicitly required
2. Grant every container SYS_ADMIN
3. Run all workloads as privileged
4. Enable hostIPC

Correct Answer: 1. Drop broad capability sets and add back only capabilities explicitly required

Explanation:

Linux capabilities divide traditional root authority into smaller privileges. Some capabilities can still provide powerful control over networking, processes, filesystems, or kernel behavior, so applications should not receive them unless necessary. A secure design starts from a minimal capability set and adds back only those permissions that have a documented functional requirement. The resulting configuration should be tested in development and enforced through workload policy where possible. Capability reduction helps contain attackers after application compromise and supports least privilege. Granting SYS_ADMIN, privileged mode, or host namespace access would significantly expand the attack surface and could create pathways toward host compromise.

Question 150.

A company wants to stop application pods from communicating directly with the database unless they belong to an approved backend tier. Which control is MOST appropriate?

1. Additional ConfigMaps
2. NetworkPolicy
3. More node labels
4. PersistentVolumeClaims

Correct Answer: 2. NetworkPolicy

Explanation:

NetworkPolicies can define which pods or namespaces are allowed to communicate with selected workloads when the cluster networking implementation supports policy enforcement. The database tier can be configured to accept ingress only from approved backend pods rather than from every workload in the cluster. This limits lateral movement and reduces the chance that a compromised front-end or unrelated pod can connect directly to sensitive services. Strong database authentication and authorization should still be used because network position alone should not establish trust. Administrators should test policies carefully and consider DNS, monitoring, and required maintenance traffic. ConfigMaps, node labels, and storage claims do not provide network-level authorization between application tiers.

Question 151.

Which network security strategy BEST follows a zero-trust approach inside a Kubernetes cluster?

1. Allow all pod traffic because it is internal
2. Start with restrictive defaults and explicitly allow only required communication paths
3. Disable authentication between services
4. Share one credential across all applications

Correct Answer: 2. Start with restrictive defaults and explicitly allow only required communication paths

Explanation:

A zero-trust approach does not assume that traffic is safe simply because it originates inside the cluster. Restrictive default network policies can deny unexpected communication and permit only the flows required by the application’s architecture. Workload identity, service authentication, encryption, and authorization should complement the network layer because network policy alone does not verify application identity or intent. This model reduces lateral movement if one workload is compromised and makes expected communication paths easier to understand. Allow-all networking and shared credentials create broad trust relationships and greatly increase the blast radius of compromise. Zero trust is therefore a combination of explicit access decisions, strong identities, limited connectivity, and continuous monitoring.

Question 152.

A workload only needs to access one external payment API. Which configuration BEST reduces unnecessary outbound network access?

1. Allow unrestricted Internet egress
2. Restrict egress to required destinations where technically feasible
3. Add more pod replicas
4. Increase memory limits

Correct Answer: 2. Restrict egress to required destinations where technically feasible

Explanation:

Restrictive egress controls reduce the ability of a compromised workload to download malicious tools, contact command-and-control infrastructure, scan external systems, or exfiltrate data. If an application only requires access to one payment API and necessary infrastructure such as DNS, outbound connectivity can be narrowed accordingly where the networking platform supports it. Dynamic IP addresses and external service dependencies may require additional design considerations, so egress policy must be tested carefully. Network controls should be combined with application authentication, TLS, runtime detection, and secret protection. Replica counts and memory limits affect availability or performance but do not constrain where compromised application processes can send network traffic.

Question 153.

Why is TLS important for service-to-service communication that carries sensitive information?

1. It can protect confidentiality and integrity of data in transit
2. It automatically patches vulnerable containers
3. It replaces RBAC
4. It prevents every application-level attack

Correct Answer: 1. It can protect confidentiality and integrity of data in transit

Explanation:

TLS encrypts network traffic so sensitive data is less likely to be exposed to passive interception. It also provides integrity protection and can authenticate the server endpoint through certificates. In architectures using mutual TLS, both sides of the connection can authenticate each other. However, TLS does not decide whether a service is authorized to perform a particular business action, so application authorization and workload identity controls remain necessary. Certificate issuance, rotation, trust stores, expiration, and revocation must also be managed securely. Encryption in transit should be combined with NetworkPolicies, least privilege, secure Secrets, monitoring, and application-level controls rather than being treated as a complete security solution by itself.

Question 154.

A company wants to reduce the chance that an attacker can replace a trusted image tag with a malicious image in the registry. Which practice BEST addresses this risk?

1. Permit anonymous image pushes
2. Use protected or immutable image references and tightly restrict registry write permissions
3. Disable authentication
4. Store registry credentials in public manifests

Correct Answer: 2. Use protected or immutable image references and tightly restrict registry write permissions

Explanation:

Mutable tags can be reassigned to different image contents. If an attacker obtains registry write access, they may replace an apparently trusted tag with a malicious artifact. Restricting push and delete permissions reduces the chance of unauthorized changes, while immutable tags or digest-based references improve reproducibility and make unexpected replacement more difficult. Image signatures and provenance provide additional trust signals, and admission policies can require approved images. Registry actions should be audited so sensitive changes can be investigated. Anonymous writes, disabled authentication, and publicly stored registry credentials undermine artifact integrity and can compromise an otherwise secure Kubernetes deployment pipeline.

Question 155.

A company wants to determine whether a production image came from an approved build pipeline rather than an employee workstation. Which information is MOST useful?

1. Build provenance
2. Service IP address
3. Pod restart count
4. Node hostname

Correct Answer: 1. Build provenance

Explanation:

Build provenance provides metadata about how an artifact was produced, including information that can identify the source repository, build system, workflow, and other relevant build context. This allows security teams to establish whether a deployed image came from an authorized pipeline rather than an uncontrolled environment. Provenance is stronger when it is generated by trusted infrastructure and protected against tampering. It should be connected to exact image digests and combined with signatures, trusted registries, SBOMs, and vulnerability scan results. Service IPs, restart counts, and node hostnames describe runtime state but do not explain the origin or build process of a container artifact.

Question 156.

A container vulnerability scanner reports a severe vulnerability, but the affected package is not used by the running application. What should the security team do?

1. Automatically assume there is no risk
2. Assess exploitability, exposure, package usage, and business impact before determining remediation priority
3. Disable scanning
4. Grant the application more privileges

Correct Answer: 2. Assess exploitability, exposure, package usage, and business impact before determining remediation priority

Explanation:

Vulnerability severity is important, but effective risk management also considers whether the vulnerable code is reachable, whether exploitation requires specific conditions, how exposed the workload is, and what business impact successful exploitation would cause. A critical vulnerability in an unused package may represent a different risk than the same vulnerability in an Internet-facing service that actively invokes the affected code. However, unused packages are themselves a reason to consider removing unnecessary components and reducing image attack surface. The team should document its assessment, apply compensating controls where needed, and patch or rebuild according to risk. Disabling scanners removes valuable visibility, while granting more privilege would increase the potential impact of exploitation.

Question 157.

Which supply chain practice can help a team quickly identify all images containing a particular vulnerable library version?

1. Maintain accurate SBOMs associated with exact image versions
2. Use only mutable tags
3. Disable artifact metadata
4. Delete vulnerability reports

Correct Answer: 1. Maintain accurate SBOMs associated with exact image versions

Explanation:

A Software Bill of Materials lists the components and dependencies included in an artifact. When associated with exact image digests or versions, SBOM data can help security teams search quickly for every image that contains an affected package. This is especially valuable during widespread vulnerability disclosures involving common open-source libraries. SBOMs should be produced through trusted processes and kept aligned with the software actually deployed. They do not determine automatically whether a vulnerability is exploitable, so runtime exposure and application behavior still need assessment. Accurate SBOMs complement vulnerability scanners, asset inventories, signed artifacts, provenance, and secure CI/CD processes to provide a clearer picture of software supply chain risk.

Question 158.

A runtime monitoring platform detects that a web container unexpectedly launches curl, downloads a binary, and executes it. What is the BEST interpretation?

1. It is necessarily a normal deployment action
2. It is a high-value runtime anomaly that should be investigated immediately
3. It proves NetworkPolicy is disabled
4. It indicates a storage resize operation

Correct Answer: 2. It is a high-value runtime anomaly that should be investigated immediately

Explanation:

A production web workload that unexpectedly downloads and executes a binary may be experiencing exploitation or unauthorized administrative activity. The team should investigate process ancestry, command execution, outbound network destinations, image identity, recent deployments, associated service account activity, and Kubernetes audit logs. Containment may involve isolating the workload or restricting its egress while preserving evidence according to incident-response procedures. Minimal images and restricted egress can make this attack pattern more difficult, while runtime monitoring helps detect it when preventive controls fail. The event should not be dismissed merely because the application continues serving traffic. Rapid investigation is important because downloaded code may steal credentials, scan the environment, establish persistence, or move laterally.

Question 159.

Which logging source is MOST useful for determining whether an attacker used stolen credentials to create a new Kubernetes Secret?

1. Kubernetes audit logs
2. CPU utilization metrics
3. Container image size
4. Storage capacity reports

Correct Answer: 1. Kubernetes audit logs

Explanation:

Kubernetes audit logs can record API operations and include information such as the authenticated identity, action, resource, namespace, timestamp, and request outcome. If stolen credentials are used to create a Secret through the API server, properly configured audit logging can provide evidence of that action. Security teams can correlate this information with identity provider logs, network telemetry, and runtime events to understand the broader incident. Sensitive log fields should be handled carefully because audit data can itself contain security-relevant information. Logs should be forwarded to protected centralized storage so attackers cannot easily erase evidence. CPU and storage metrics are useful operationally but do not show which identity performed a Kubernetes API operation.

Question 160.

Which approach BEST represents a sustainable Kubernetes security program as applications, clusters, and development teams grow?

1. Depend on the default configuration and avoid policy changes
2. Focus only on vulnerability scanning
3. Continuously govern identity, RBAC, workload hardening, network policy, supply chain controls, admission enforcement, logging, runtime monitoring, and incident response
4. Grant broad permissions to reduce support requests

Correct Answer: 3. Continuously govern identity, RBAC, workload hardening, network policy, supply chain controls, admission enforcement, logging, runtime monitoring, and incident response

Explanation:

Kubernetes security is an ongoing operational discipline rather than a one-time configuration task. As teams and clusters grow, identities change, new workloads appear, dependencies evolve, and security controls can drift. Organizations should routinely review RBAC, service accounts, privileged access, workload policies, network communication paths, image provenance, vulnerability status, and registry permissions. Admission controls should enforce secure deployment requirements consistently, while audit logs and runtime monitoring provide detection and investigation capabilities. Incident-response procedures should be practiced so teams know how to contain workloads, protect evidence, rotate credentials, and recover safely. Continuous governance also includes tracking exceptions and retiring unnecessary access. This layered, recurring approach scales much better than relying on defaults, broad permissions, or one isolated security tool.