View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps

 

Question 241.

A Kubernetes workload needs to read one Secret from its own namespace and nothing else from the Kubernetes API. Which authorization design BEST follows least privilege?

1. Create a dedicated service account with permission to read only the required Secret
2. Bind the workload to a namespace-wide read-only ClusterRole
3. Grant the default service account permission to read all Secrets in the namespace
4. Give the application temporary cluster-admin access during startup

Correct Answer: 1. Create a dedicated service account with permission to read only the required Secret

Explanation:

A dedicated service account with narrowly scoped permissions limits the workload to exactly the API access it needs. If the application requires one Secret, the corresponding Role can restrict access to that resource and the required verbs rather than exposing unrelated Secrets or Kubernetes objects. Namespace-wide read access can still reveal sensitive information and create unnecessary blast radius. Modifying the default service account also risks unintentionally granting access to other workloads that use it. Temporary cluster-admin access is far broader than the application’s requirement and creates severe exposure if credentials are stolen. Least privilege should be applied to both identity and resource scope. The service account should also be monitored through audit logs, and its token should not be mounted in unrelated containers or workloads.

Question 242.

A platform team discovers that several production pods use the default service account even though the applications never communicate with the Kubernetes API. Which change BEST reduces unnecessary credential exposure?

1. Create a read-only ClusterRole for the default service account
2. Disable automatic service account token mounting for those workloads
3. Rotate the default service account token more frequently
4. Move the applications to a separate namespace

Correct Answer: 2. Disable automatic service account token mounting for those workloads

Explanation:

If an application does not need Kubernetes API access, mounting a service account token provides no functional benefit and creates an additional credential that an attacker may steal after compromising the workload. Disabling token automounting removes that unnecessary authentication material. Creating a read-only role still leaves a usable API credential in the container, and rotating it more often reduces duration but does not eliminate unnecessary exposure. Moving the application to another namespace changes organization but does not automatically remove the token. Workloads that genuinely need API access should use dedicated service accounts with carefully scoped RBAC permissions. Credential minimization is an important cloud-native security principle because it reduces both the number of secrets inside workloads and the actions available to an attacker after compromise.

Question 243.

Which Kubernetes RBAC permission should receive especially careful review because it can allow a user to act as another identity?

1. Permission to list Pods
2. Permission to read ConfigMaps
3. Permission to impersonate users, groups, or service accounts
4. Permission to view Deployment status

Correct Answer: 3. Permission to impersonate users, groups, or service accounts

Explanation:

Impersonation is a powerful Kubernetes capability because it may allow an identity to submit requests as another user, group, or service account. If the impersonated identity has stronger permissions, the capability can become a privilege-escalation path. For this reason, impersonation permissions should be granted only to trusted components or administrators with a clear operational requirement. Listing Pods, reading ordinary ConfigMaps, or viewing Deployment status may reveal useful operational information, but they do not normally provide the same direct ability to assume another identity. Security teams should review not only obvious roles such as cluster-admin but also subtle permission combinations that can lead to escalation. Kubernetes audit logging is particularly valuable for detecting unexpected impersonation activity and identifying which principal initiated the request.

Question 244.

A company wants to prevent ordinary application teams from deploying containers that use hostPID, hostIPC, privileged mode, or unrestricted capabilities. Which control is MOST appropriate?

1. Runtime alerting after the container starts
2. Namespace ResourceQuotas
3. Cluster-wide read-only RBAC
4. Admission policy enforcement based on workload security requirements

Correct Answer: 4. Admission policy enforcement based on workload security requirements

Explanation:

Admission policies can evaluate pod specifications before workloads are accepted into the cluster. This makes them ideal for preventing known-dangerous settings such as privileged mode, hostPID, hostIPC, hostNetwork, unsafe hostPath volumes, or excessive Linux capabilities. Runtime alerts remain important, but they detect risky behavior only after the workload is already running. ResourceQuotas limit resource consumption rather than privilege, while read-only RBAC does not control container security settings. Admission policies can be aligned with Pod Security Standards or custom organizational requirements. Legitimate system components that require elevated privileges should follow a documented exception process and may need dedicated nodes, tighter RBAC, additional monitoring, or other compensating controls. Preventing insecure configurations at admission is stronger than relying only on post-deployment detection.

Question 245.

An application needs to write only to /tmp while the rest of the container filesystem should remain unchanged. Which configuration BEST supports this requirement securely?

1. Use a read-only root filesystem and mount a writable volume only at /tmp
2. Keep the entire root filesystem writable but run the container as non-root
3. Mount the host filesystem read-write at /tmp
4. Run the pod as privileged and restrict its egress traffic

Correct Answer: 1. Use a read-only root filesystem and mount a writable volume only at /tmp

Explanation:

A read-only root filesystem limits the ability of a compromised process to modify application binaries, system libraries, packaged configuration, and other image content. If the workload only needs temporary writable storage, a narrowly scoped volume at /tmp provides the required functionality without making the entire image filesystem writable. Running as non-root is also useful but does not prevent modification of files the process owns or can access. Mounting a host directory introduces node-level exposure and is unnecessary for temporary application storage. Privileged mode dramatically weakens container isolation and cannot be compensated for simply by restricting network traffic. Secure workload design should make only the minimum required resources writable, privileged, reachable, or accessible, thereby limiting what an attacker can change after gaining code execution.

Question 246.

A containerized application must bind to a low-numbered network port but otherwise does not require elevated privileges. Which approach BEST follows least privilege?

1. Run the entire container as root
2. Grant only the specific required capability if necessary and drop the rest
3. Enable privileged mode during application startup
4. Add SYS_ADMIN so future networking changes do not require reconfiguration

Correct Answer: 2. Grant only the specific required capability if necessary and drop the rest

Explanation:

Linux capabilities allow individual privileges to be granted without giving a process the full authority associated with root or privileged mode. If an application genuinely requires one capability, the safer approach is to drop unnecessary capabilities and add back only the specific capability required for the function. Running the entire workload as root exposes more privilege than necessary, while privileged mode substantially weakens multiple container isolation mechanisms. SYS_ADMIN is particularly powerful and should not be granted merely for convenience or anticipated future needs. In some environments, application design can avoid low-numbered ports entirely by using a higher internal port and mapping traffic through a Service or proxy. The overall objective is to reduce the privilege available to the process while still satisfying its legitimate operational requirements.

Question 247.

Which security mechanism is MOST directly responsible for limiting which Linux system calls a container process can use?

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

Correct Answer: 3. seccomp

Explanation:

seccomp filters system calls made by Linux processes. A container may need only a subset of all available kernel system calls, so restricting the rest reduces the attack surface exposed to a compromised application. Kubernetes can apply seccomp profiles to workloads, including standard runtime defaults or custom policies where needed. AppArmor is also a useful host-level security control but generally focuses on mandatory access restrictions around files and process behavior rather than functioning primarily as a syscall filter. RBAC governs access to Kubernetes API resources, while NetworkPolicy controls network communication. seccomp should be used alongside non-root execution, reduced Linux capabilities, AppArmor or SELinux, read-only filesystems, and runtime monitoring. Profiles require testing because an application may fail if a legitimately required syscall is blocked.

Question 248.

A security engineer wants an additional operating-system control that can restrict a container process from reading sensitive files even if normal Unix permissions would permit access. Which technology is MOST appropriate?

1. NetworkPolicy
2. ResourceQuota
3. seccomp alone
4. AppArmor or SELinux**

Correct Answer: 4. AppArmor or SELinux

Explanation:

AppArmor and SELinux provide mandatory access control at the Linux operating-system layer. They can restrict which files, paths, devices, and other resources a process may access even when traditional permissions would otherwise allow the operation. This makes them valuable additional containment controls for compromised applications. seccomp restricts system calls rather than defining general file-access policy, so it solves a different problem. NetworkPolicy controls network communication, and ResourceQuota manages resource consumption. Mandatory access control should be layered with non-root execution, capability reduction, read-only filesystems, and seccomp. Profiles must be tested and maintained carefully because an overly restrictive policy may break legitimate application behavior, while an overly permissive policy may provide little real protection. These controls strengthen host-level isolation without replacing Kubernetes-layer authorization.

Question 249.

A production container image contains a compiler, package manager, source code, and debugging utilities that are used only during the build process. Which improvement BEST reduces runtime attack surface?

1. Use a multi-stage build and copy only required runtime artifacts into the final image
2. Keep the tools but remove the package repository configuration
3. Protect the container with a namespace ResourceQuota
4. Retain the full image and rely on runtime monitoring to detect misuse

Correct Answer: 1. Use a multi-stage build and copy only required runtime artifacts into the final image

Explanation:

Multi-stage builds allow build-time tools and source files to remain in an earlier build stage while the final production image contains only the application and required runtime dependencies. This reduces the number of packages that may contain vulnerabilities and limits the utilities available to an attacker after compromise. Removing repository configuration does not remove installed binaries or libraries, and ResourceQuotas do not reduce software attack surface. Runtime monitoring is an important detective control but should complement preventive image hardening rather than replace it. The final image should still be scanned, signed, patched, and associated with provenance and an SBOM. Minimal production images improve both security and maintainability by reducing unnecessary software and making the expected runtime environment easier to understand.

Question 250.

A newly disclosed vulnerability affects a specific version of a widely used library. Which asset provides the MOST direct way to identify container images that include that version?

1. Kubernetes audit logs
2. Software Bill of Materials records associated with image digests
3. Network flow logs
4. Pod Security Admission configuration

Correct Answer: 2. Software Bill of Materials records associated with image digests

Explanation:

An SBOM provides an inventory of components and versions included in a software artifact. If the SBOM is associated with an exact image digest, a security team can quickly search for the vulnerable library version and identify potentially affected images. This is especially useful when a common dependency is used across many applications. An SBOM does not automatically establish exploitability, so security teams must still assess whether the vulnerable code is reachable, how exposed the application is, and what remediation is required. Kubernetes audit logs show API activity, network flow logs describe communications, and Pod Security Admission governs workload configuration. None of those sources provides the same direct software composition inventory. Reliable SBOM generation is therefore an important part of mature software supply chain visibility.

Question 251.

A security team approves a container image after testing, but the deployment manifest references a mutable tag. Which change BEST ensures that the exact approved artifact is deployed?

1. Reference the image by its immutable digest
2. Set imagePullPolicy: Always for the mutable tag
3. Increase registry audit logging
4. Allow only administrators to restart the Deployment

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

Explanation:

A digest uniquely identifies the content of a container image. A mutable tag may later be reassigned to different content, meaning a restart could retrieve an artifact that was never reviewed. Referencing the approved digest eliminates that ambiguity and improves reproducibility, rollback confidence, and incident investigation. imagePullPolicy: Always can actually increase exposure to tag replacement because each pull may retrieve whatever content the tag currently references. Registry audit logging is valuable for detection but does not ensure that the original artifact continues to be deployed. Restricting restarts also does not solve the underlying artifact identity problem. Digest pinning should be combined with restricted registry writes, image signatures, provenance verification, vulnerability scanning, and admission controls for stronger supply chain assurance.

Question 252.

Which control BEST verifies that a container image was approved by a trusted organization before Kubernetes allows it to run?

1. An egress NetworkPolicy
2. A ResourceQuota
3. Signature verification during admission
4. A readiness probe

Correct Answer: 3. Signature verification during admission

Explanation:

Image signature verification can establish that an artifact was signed by a trusted identity and has not been altered since signing. Performing this verification during admission prevents untrusted or unsigned images from reaching runtime. The signing process itself must also be protected because a compromised signing key could allow an attacker to make malicious artifacts appear legitimate. Signature verification works best with image digests, trusted provenance, protected registries, vulnerability scanning, and secure CI/CD systems. Egress NetworkPolicies limit outbound communication, ResourceQuotas manage consumption, and readiness probes determine whether a pod should receive traffic. Those controls do not establish artifact authenticity. Admission-time signature verification provides a preventive supply chain control at the point where workloads enter the cluster.

Question 253.

A CI pipeline is authorized to deploy applications into one production namespace. Which credential design BEST reduces risk if the pipeline is compromised?

1. Give the pipeline a dedicated identity limited to the required namespace and deployment actions
2. Use a shared cluster-admin credential but rotate it every month
3. Allow the pipeline to modify RBAC in case deployment permissions need expansion
4. Use the same credential for development, staging, and production clusters

Correct Answer: 1. Give the pipeline a dedicated identity limited to the required namespace and deployment actions

Explanation:

A dedicated pipeline identity with tightly scoped permissions limits the actions an attacker can perform if CI/CD credentials are stolen. If the pipeline only deploys selected workload resources in one production namespace, it should not have cluster-wide access, RBAC administration, or permissions in unrelated environments. Monthly rotation reduces credential lifetime but does not compensate for excessive privilege. Allowing RBAC modification creates a potential escalation path, and reusing the same credential across environments increases blast radius. Stronger designs may use short-lived credentials, separate build and deployment identities, environment-specific trust, and detailed audit logging. CI/CD systems are high-value attack targets because a compromised pipeline can deliver malicious software through trusted automation, making least-privilege authorization especially important.

Question 254.

A pipeline log accidentally contains a production registry credential. Which action is MOST appropriate?

1. Delete the log entry and continue using the credential
2. Move the log to restricted storage without changing the credential
3. Rebuild the container images but leave the credential active
4. Revoke or rotate the credential and investigate its potential exposure**

Correct Answer: 4. Revoke or rotate the credential and investigate its potential exposure

Explanation:

Once a credential has appeared in a build log, it should be considered potentially exposed because logs may be retained, downloaded, replicated, indexed, or accessible to more users than the secret-management system itself. Rotating or revoking the credential invalidates copies that may already have been obtained. The organization should also determine who could access the log, review registry activity for misuse, and correct the pipeline behavior that printed the secret. Secret masking, secure injection, and reduced logging of sensitive environment data can help prevent recurrence. Simply deleting one visible entry does not guarantee that backups or cached copies are gone. Rebuilding images does not address compromise of registry authentication unless the credential was also embedded in the images themselves.

Question 255.

Which runtime behavior would be MOST suspicious for a production container that normally executes only a single web-server process?

1. Launching an interactive shell followed by a network enumeration tool
2. Receiving a normal liveness probe request
3. Reopening a rotated application log file
4. Resolving the DNS name of its configured backend service

Correct Answer: 1. Launching an interactive shell followed by a network enumeration tool

Explanation:

A fixed-function production web container should not normally launch an interactive shell or network scanning utility. Such activity can indicate successful exploitation, unauthorized administrative access, reconnaissance, or preparation for lateral movement. Runtime security systems can detect unexpected processes, shell execution, suspicious system calls, filesystem modification, and network behavior. The event should trigger investigation of the process tree, image digest, network destinations, recent deployments, service account permissions, and Kubernetes audit logs. Health probes, log rotation, and DNS resolution for known dependencies are expected operational behaviors in many environments. Runtime monitoring is valuable because even a properly signed and scanned image may later execute malicious actions if the application is exploited through a runtime vulnerability.

Question 256.

A node begins making unexpected outbound connections shortly after a privileged workload is deployed. Which response BEST follows incident-response principles?

1. Restart the privileged pod and continue scheduling workloads to the node
2. Isolate the node and workload, preserve evidence, and investigate before returning the node to service
3. Rotate only the application’s service account token
4. Add the outbound destinations to the firewall allowlist until troubleshooting is complete

Correct Answer: 2. Isolate the node and workload, preserve evidence, and investigate before returning the node to service

Explanation:

Privileged containers can interact with host resources and may create node-level compromise paths that ordinary containers cannot. Unexpected node traffic after privileged workload deployment therefore warrants careful investigation. The response may involve cordoning or isolating the node, restricting network access, preserving host and Kubernetes logs, capturing relevant runtime state, identifying the exact image, and reviewing credentials used by the workload. Simply restarting the pod may destroy useful evidence and does not prove that host-level changes have been removed. Rotating one service account token may be insufficient if broader credentials or node secrets were exposed. Depending on findings, rebuilding the node from a known-good state may be safer than returning a potentially compromised system to production.

Question 257.

A front-end pod should communicate only with an API backend and should never connect directly to a database. Which design BEST enforces this architecture?

1. Use default-deny NetworkPolicies and explicitly allow the required front-end-to-backend path
2. Place the database and front end in different Deployments
3. Use separate DNS names for each application tier
4. Encrypt database traffic but permit connectivity from all pods

Correct Answer: 1. Use default-deny NetworkPolicies and explicitly allow the required front-end-to-backend path

Explanation:

Default-deny NetworkPolicies establish a restrictive baseline in which communication is blocked unless explicitly permitted. The front end can be allowed to communicate with the API backend while direct access to the database remains denied. This reduces lateral movement opportunities if the front-end application is compromised. Separate Deployments and DNS names help organize application architecture but do not themselves prevent network communication. Encryption protects data in transit but does not stop unauthorized workloads from establishing connections. Network segmentation should be complemented by service authentication, database authorization, separate credentials, workload identity, and runtime monitoring. The objective is to enforce the intended communication graph rather than trusting every workload simply because it is located inside the same Kubernetes cluster.

Question 258.

A pod requires outbound access only to DNS, an internal API, and one approved external service. Which control BEST limits unnecessary Internet connectivity?

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

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

Explanation:

Egress controls can restrict a workload to the destinations it legitimately needs, reducing the attacker’s ability to download malicious tools, communicate with command-and-control systems, scan external networks, or exfiltrate data. Kubernetes NetworkPolicy can provide this capability when supported by the cluster networking implementation. Dynamic external services may require additional gateways, firewalls, or domain-aware controls depending on the environment. A read-only filesystem limits local modification but does not prevent network connections. ResourceQuotas and PodDisruptionBudgets address capacity and availability rather than outbound traffic. Strong egress controls should be combined with runtime network monitoring so blocked or unusual connection attempts become visible. Sensitive workloads benefit from both prevention and detection rather than relying solely on one layer.

Question 259.

Which logging strategy BEST preserves evidence if a compromised pod is deleted before responders begin their investigation?

1. Forward application, Kubernetes audit, node, and runtime security logs to protected centralized storage
2. Keep logs only inside the container to maintain data locality
3. Retain only Kubernetes Events because they are generated by the control plane
4. Disable long-term log retention to reduce exposure of sensitive information

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

Explanation:

Pods are ephemeral and may be restarted, rescheduled, scaled down, or deliberately deleted by an attacker. Evidence stored only inside the workload can disappear before responders collect it. Centralized logging preserves data independently of pod lifecycle and supports correlation across multiple layers. Kubernetes audit logs show API activity, application logs provide service context, node logs reveal host events, and runtime telemetry can capture suspicious processes and network behavior. Kubernetes Events are useful but generally not detailed enough for full forensic reconstruction. Centralized systems should have strong authorization, integrity protection, encryption, retention policies, and monitoring because security logs may contain sensitive information. Incident readiness depends on collecting and protecting evidence before a compromise occurs.

Question 260.

Which approach BEST represents a mature cloud-native security program for Kubernetes workloads?

1. Concentrate on image scanning and treat a successfully scanned artifact as trusted for its full lifetime
2. Secure the cluster perimeter and allow broad internal workload communication
3. Use RBAC and NetworkPolicies but trust CI/CD pipelines without additional supply chain controls
4. Continuously integrate identity security, least privilege, workload hardening, supply chain assurance, policy enforcement, network segmentation, monitoring, vulnerability management, logging, and incident response**

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

Explanation:

Kubernetes security must cover the entire cloud-native lifecycle. Strong identities and RBAC reduce unauthorized API access. Hardened containers limit process privilege and writable attack surface. Software supply chain controls protect source code, dependencies, build systems, signatures, provenance, registries, and artifact promotion. Admission policies prevent known insecure configurations from reaching runtime, while NetworkPolicies reduce lateral movement and unnecessary egress. Continuous vulnerability management is necessary because new weaknesses may appear after deployment. Runtime monitoring, Kubernetes audit logs, and centralized telemetry help detect activity preventive controls miss. Tested incident-response procedures prepare teams to contain affected workloads, rotate credentials, preserve evidence, eradicate root causes, and recover safely. No single control can address all cloud-native threats, so sustainable security requires continuously maintained defense in depth.