View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps

 

Question 381.

A Kubernetes application only needs to read a single ConfigMap in its namespace. Which authorization approach BEST follows least privilege?

1. Use a dedicated service account with a Role granting only the necessary read permission on that ConfigMap
2. Grant read access to all ConfigMaps and Secrets in the namespace so the application can adapt later
3. Bind the workload to a cluster-wide read-only role covering all namespaces
4. Use the namespace default service account with broad read access to application resources

Correct Answer: 1. Use a dedicated service account with a Role granting only the necessary read permission on that ConfigMap

Explanation:

A dedicated service account combined with narrowly scoped RBAC reduces the impact of credential theft or workload compromise. If the application only needs one ConfigMap, the Role can restrict access to the necessary resource and read-only verbs. Granting access to every ConfigMap or Secret creates unnecessary exposure, while a cluster-wide role significantly increases the blast radius. The default service account may also be shared by unrelated workloads, making permissions harder to reason about. Least privilege should consider identity, resource type, namespace, verbs, and individual resource names where appropriate. Audit logging and periodic permission reviews can confirm that the workload’s authorization remains aligned with its actual function as the application evolves.

Question 382.

A CI/CD deployment identity can create RoleBindings in production even though it only needs to update Deployments. What is the PRIMARY security concern?

1. The pipeline may increase the number of running replicas unexpectedly
2. The pipeline may be able to grant itself or another identity additional privileges
3. The pipeline may bypass readiness probes during rollout
4. The pipeline may force workloads onto specific nodes

Correct Answer: 2. The pipeline may be able to grant itself or another identity additional privileges

Explanation:

RoleBinding creation can become an indirect privilege-escalation path because a compromised pipeline may bind itself or another principal to a stronger Role or ClusterRole. A deployment identity should therefore receive only the permissions needed to update the specific resources it manages. Excessive authorization is dangerous even when the CI/CD system is otherwise trusted, because build systems and deployment pipelines are high-value targets. Readiness probes, replica counts, and node placement are important operational concerns but are not the central risk created by RoleBinding permissions. Stronger pipeline security uses dedicated identities, narrowly scoped RBAC, short-lived credentials where possible, protected configuration, artifact verification, and audit logging of sensitive API changes.

Question 383.

Which Kubernetes permission should receive especially careful review because it may let an identity act as another principal?

1. Permission to list Services
2. Permission to impersonate users, groups, or service accounts
3. Permission to watch Deployments
4. Permission to read Pod status

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

Explanation:

Impersonation allows one identity to submit Kubernetes API requests using the identity context of another user, group, or service account. If the impersonated identity has stronger privileges, this capability may create a direct escalation path. It should therefore be granted only to trusted components or administrators with a clear operational requirement. Listing Services, watching Deployments, or reading Pod status can reveal useful information but normally does not allow one principal to assume another principal’s permissions. Kubernetes audit logs should capture impersonation activity so unusual use can be investigated. RBAC reviews should consider indirect escalation paths such as impersonation, role binding creation, and the ability to create workloads that can access privileged identities or sensitive resources.

Question 384.

A company wants to prevent developers from deploying privileged containers, using hostPID, or mounting sensitive hostPath volumes. Which control is BEST suited for consistent preventive enforcement?

1. Runtime anomaly detection
2. NetworkPolicy enforcement
3. Namespace ResourceQuotas
4. Admission policy enforcement

Correct Answer: 4. Admission policy enforcement

Explanation:

Admission policies evaluate resource requests before workloads are persisted and scheduled, making them an ideal place to reject known-dangerous configurations. Policies can prohibit privileged mode, hostPID, hostIPC, hostNetwork, excessive capabilities, unsafe hostPath mounts, and other settings that violate organizational security standards. Runtime monitoring remains useful because it detects malicious behavior after deployment, but preventive blocking is preferable when the risk is visible in the workload specification. NetworkPolicies control communication rather than Linux privilege, while ResourceQuotas limit consumption. Admission controls can be aligned with Pod Security Standards or customized internal policies. Legitimate exceptions should be narrow, documented, monitored, and reviewed regularly so they do not become permanent security bypasses.

Question 385.

A containerized application requires writable access only to /var/app/data. Which configuration BEST limits filesystem modification?

1. Use a read-only root filesystem and mount a writable volume only at /var/app/data
2. Keep the full root filesystem writable but run the application as non-root
3. Mount a writable host directory at /var/app/data
4. Run the container as privileged but keep application binaries read-only

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

Explanation:

A read-only root filesystem reduces the ability of a compromised process to alter application binaries, packaged configuration, system libraries, or other files in the container image. If the application genuinely requires writes only to one location, mounting a dedicated writable volume there provides the minimum necessary filesystem access. Non-root execution is also valuable but does not prevent a process from changing files it is allowed to write. Mounting host directories unnecessarily exposes node resources, while privileged mode weakens container isolation significantly. This pattern applies least privilege to filesystem access and should be combined with capability reduction, allowPrivilegeEscalation: false, seccomp, and mandatory access control where compatible.

Question 386.

A service needs one specific Linux capability for a documented function. Which configuration BEST minimizes risk?

1. Keep the runtime’s default capability set to avoid compatibility problems
2. Drop unnecessary capabilities and add back only the required capability
3. Run the container as root but disable interactive shells
4. Enable privileged mode and compensate with restrictive NetworkPolicies

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

Explanation:

Linux capabilities divide traditional root privileges into smaller units. If only one capability is required, the safest design is to remove the others and explicitly restore only the necessary one. Keeping broad defaults exposes unnecessary privilege, while running as root increases authority available to an attacker. Privileged mode weakens many isolation mechanisms and cannot be made equivalent to least privilege through network restrictions. Capability minimization should be combined with non-root execution, disabled privilege escalation, seccomp, and mandatory access control. The workload should be tested with the reduced capability set so security improvements do not break legitimate functionality. Granting only what is required makes compromise harder to expand into broader container or host-level control.

Question 387.

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

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

Correct Answer: 2. allowPrivilegeEscalation: false

Explanation:

allowPrivilegeEscalation: false is specifically designed to prevent a process from gaining more privileges than its parent process. This can block privilege-gain paths involving setuid executables or file capabilities. A read-only root filesystem reduces file modification and some persistence opportunities, but it does not directly control process privilege transitions. Disabling service account token mounting protects Kubernetes API credentials, while avoiding host networking preserves network namespace isolation. These controls address different risk categories and are most effective when used together. A hardened workload typically combines non-root execution, capability reduction, disabled privilege escalation, seccomp, mandatory access control, and narrowly scoped writable storage to create overlapping defensive layers.

Question 388.

Which Linux security feature is specifically designed to filter the system calls available to a container process?

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

Correct Answer: 4. seccomp

Explanation:

seccomp filters Linux system calls and reduces the kernel interface available to a process. Many applications require only a subset of all available syscalls, so blocking unnecessary operations can reduce exposure to kernel attack paths and make certain exploit techniques more difficult. AppArmor is also valuable but provides mandatory access restrictions around files and other resources rather than functioning primarily as a syscall filter. Kubernetes RBAC controls API authorization, while NetworkPolicy controls network communication. seccomp profiles should be tested because denying a required system call can break legitimate application behavior. They work best alongside non-root execution, capability minimization, AppArmor or SELinux, read-only filesystems, and runtime security monitoring.

Question 389.

A security team wants an additional operating-system control that can restrict a container process from accessing sensitive files even when normal Unix permissions allow the operation. Which technology is MOST appropriate?

1. AppArmor or SELinux
2. ResourceQuota
3. ServiceAccount RBAC
4. PodDisruptionBudget

Correct Answer: 1. AppArmor or SELinux

Explanation:

AppArmor and SELinux provide mandatory access control at the Linux operating-system layer. They can restrict a process’s access to files, devices, paths, and other system resources even when traditional discretionary permissions would permit the action. This adds another containment layer for compromised workloads. Kubernetes RBAC controls access to API objects, not ordinary local filesystem access. ResourceQuotas manage resource consumption, and PodDisruptionBudgets help maintain availability. Mandatory access control profiles must be designed and tested carefully because overly restrictive policies can break legitimate applications. They are most effective when combined with seccomp, non-root execution, capability reduction, read-only root filesystems, and admission policies that ensure workloads use approved security settings.

Question 390.

A production image includes build-time compilers, package managers, source code, and diagnostic tools. Which change BEST reduces runtime attack surface?

1. Keep all tools but restrict outbound Internet access
2. Use a multi-stage build and include only required runtime artifacts in the final image
3. Keep the full image but configure a read-only root filesystem
4. Move build tools into a hidden directory inside the image

Correct Answer: 2. Use a multi-stage build and include only required runtime artifacts in the final image

Explanation:

Multi-stage builds allow build tools and source material to remain in an earlier image stage while the final production image includes only the application and required runtime dependencies. This reduces the number of potentially vulnerable packages and limits the utilities available to an attacker after compromise. Restricting egress or using a read-only filesystem is valuable but does not remove unnecessary binaries and libraries. Moving tools to another directory only obscures them and does not prevent execution. Minimal images should still be scanned, patched, signed, and associated with SBOM and provenance data. Reducing unnecessary software is stronger than relying solely on runtime restrictions after an attacker gains code execution.

Question 391.

Which artifact gives a security team the BEST component inventory for determining whether a container image includes a newly vulnerable library?

1. An SBOM tied to the exact image digest
2. Kubernetes audit logs
3. A NetworkPolicy manifest
4. A PodSecurity configuration

Correct Answer: 1. An SBOM tied to the exact image digest

Explanation:

A Software Bill of Materials lists the components and dependency versions included in an artifact. Linking the SBOM to an exact image digest ensures the inventory corresponds to the specific image rather than a mutable tag that may later point elsewhere. When a vulnerability is disclosed, the team can search the SBOM inventory to identify potentially affected images quickly. The SBOM does not prove exploitability, so exposure analysis, vulnerability scanning, and remediation remain necessary. Kubernetes audit logs, NetworkPolicies, and Pod Security settings describe API activity or runtime controls rather than software composition. Reliable SBOM generation is therefore a key capability for software supply chain visibility and efficient vulnerability response.

Question 392.

A Deployment references a mutable image tag such as approved-prod. Which practice BEST ensures the exact reviewed artifact is used?

1. Enable longer registry audit-log retention
2. Reference the approved image by immutable digest
3. Configure imagePullPolicy: Always
4. Limit pod deletion to administrators

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

Explanation:

An immutable image digest identifies exact artifact content. A mutable tag can be reassigned later, meaning a pod restart may retrieve different content without any modification to the Kubernetes manifest. Digest pinning eliminates this ambiguity and improves reproducibility, rollback confidence, and forensic investigation. Registry logging can show that a tag changed but does not stop altered content from being used. imagePullPolicy: Always may actually increase exposure because it retrieves the current tag content every time an image is pulled. Restricting pod deletion does not solve artifact identity. Digest-based deployments should be combined with protected registry writes, signatures, provenance, vulnerability scanning, and admission controls for stronger supply chain assurance.

Question 393.

A company wants production clusters to reject container images that were not generated by its approved CI/CD process. Which control BEST supports this objective?

1. Admission-time verification of trusted signatures or build provenance
2. Namespace ResourceQuotas
3. Runtime network monitoring
4. Pod anti-affinity rules

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

Explanation:

Trusted signatures and build provenance can provide evidence that an artifact was created or approved through an authorized build and release process. Verifying that evidence during admission allows the cluster to reject untrusted images before they execute. ResourceQuotas limit resource usage, network monitoring detects runtime communication, and anti-affinity influences scheduling. None of those controls verifies artifact origin. Trust infrastructure must itself be secured because compromised signing keys or build systems can make malicious artifacts appear legitimate. Strong supply chain assurance also includes protected source repositories, secure CI/CD credentials, trusted registries, immutable digests, vulnerability scanning, SBOMs, and tightly controlled artifact promotion.

Question 394.

A CI/CD pipeline only needs to update Deployments and Services in one namespace. Which authorization model BEST limits the blast radius if the pipeline is compromised?

1. Grant namespace-admin so the pipeline can handle future requirements
2. Grant only the required Deployment and Service permissions in that namespace
3. Permit RoleBinding creation but block ClusterRoleBinding creation
4. Grant cluster-wide write access but issue short-lived tokens

Correct Answer: 2. Grant only the required Deployment and Service permissions in that namespace

Explanation:

A deployment identity should receive only the verbs, resources, and scope required for its function. Namespace-admin provides far more authority than necessary, while RoleBinding creation may still allow privilege escalation depending on which roles are available. Short-lived tokens reduce credential lifetime but do not make broad cluster-wide permissions safe. Least privilege should be enforced at the authorization layer and supported by dedicated identities, protected pipeline configuration, audit logging, and artifact verification. If deployment requirements change later, permissions can be deliberately reviewed and expanded rather than granted in advance. This approach limits the damage an attacker can cause if the CI system, deployment job, or credentials are compromised.

Question 395.

A service account that normally reads application configuration suddenly starts creating Pods and reading Secrets. What should the security team investigate FIRST?

1. Possible credential misuse, an unexpected RBAC change, or workload compromise
2. Whether the namespace has reached its resource quota
3. Whether the scheduler changed node affinity decisions
4. Whether the application’s readiness probe was updated

Correct Answer: 1. Possible credential misuse, an unexpected RBAC change, or workload compromise

Explanation:

A dramatic change in an identity’s API behavior is an important security signal. A service account that normally reads configuration but suddenly creates Pods or accesses Secrets may have been compromised, granted new privileges, or misused by an attacker. Investigators should review Kubernetes audit logs, recent Role and RoleBinding changes, runtime process activity, deployment history, image identity, and network connections. Resource quotas, scheduling decisions, and readiness probes do not automatically grant API permissions. Ideally, least-privilege RBAC would prevent these operations entirely. Behavioral monitoring remains valuable because attackers frequently abuse valid credentials and technically authorized API paths rather than triggering obvious authentication failures.

Question 396.

A fixed-function production container unexpectedly launches a shell, downloads an executable, and starts communicating with an unfamiliar external address. Which response is MOST appropriate?

1. Increase the container’s CPU allocation to support observation
2. Add the external address to the egress allowlist temporarily
3. Restart the pod and remove its previous logs
4. Treat the behavior as a possible compromise, contain the workload, and preserve evidence

Correct Answer: 4. Treat the behavior as a possible compromise, contain the workload, and preserve evidence

Explanation:

Unexpected shell execution, downloaded binaries, and unfamiliar outbound communication are strong indicators of possible exploitation or command-and-control activity. Responders should follow established incident procedures and balance containment with evidence preservation. Actions may include isolating the workload, restricting network access, preserving Kubernetes audit and application logs, capturing process and network state, and identifying exposed credentials. Increasing resources or allowlisting the destination would enable suspicious behavior rather than contain it. Restarting and deleting logs can destroy useful evidence without addressing the underlying vulnerability. After containment, the team should determine root cause, rotate compromised credentials, rebuild from trusted artifacts, and validate remediation before returning the workload to normal service.

Question 397.

Which network design BEST limits lateral movement if a compromised front-end pod should never communicate directly with the database tier?

1. Use default-deny NetworkPolicies and explicitly permit only required front-end-to-backend communication
2. Permit all east-west traffic but require TLS
3. Place each tier in a separate Deployment
4. Use different DNS names for each application tier

Correct Answer: 1. Use default-deny NetworkPolicies and explicitly permit only required front-end-to-backend communication

Explanation:

A default-deny network posture blocks communication unless an explicit policy allows it. This lets the organization enforce the intended architecture, such as front end to API and API to database, while preventing direct front-end database access. TLS protects confidentiality and authenticates endpoints but does not stop unauthorized connection attempts when network reachability remains broad. Separate Deployments and DNS names provide organizational separation rather than enforceable network isolation. Network segmentation should be layered with service authentication, separate credentials, workload identities, and runtime monitoring. Assuming any workload can become compromised and limiting what it can reach afterward is a core defense-in-depth and zero-trust principle.

Question 398.

A sensitive workload should make outbound connections only to DNS and a small set of approved external APIs. Which control BEST limits unnecessary egress?

1. A dedicated Kubernetes ServiceAccount
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 controls directly determine which destinations a workload may contact. If the workload only needs DNS and a few approved APIs, unrestricted Internet access creates unnecessary opportunities for command-and-control communication, data exfiltration, malicious downloads, or external scanning. Kubernetes NetworkPolicy can provide this functionality when the networking implementation supports it, while dynamic external destinations may require egress gateways or firewalls. A dedicated service account restricts Kubernetes API authorization, a read-only filesystem limits local modification, and a PodDisruptionBudget supports availability. None of those controls limits outbound destinations. Egress filtering should be complemented by runtime network monitoring so unexpected connection attempts remain visible even when they are blocked.

Question 399.

Which logging architecture BEST supports forensic investigation when compromised pods may be deleted, rescheduled, or replaced before responders inspect them?

1. Forward Kubernetes audit, application, node, and runtime security logs to protected centralized storage
2. Keep all evidence inside each pod’s filesystem
3. Retain only Kubernetes Events
4. Disable long-term logging to minimize sensitive-data retention

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

Explanation:

Pods are ephemeral, and local evidence can disappear through restarts, scaling, rescheduling, containment actions, or attacker behavior. Centralized logging preserves telemetry independently of the pod lifecycle and enables correlation across multiple layers. Kubernetes audit logs show API activity, runtime telemetry captures suspicious processes and network behavior, application logs provide workload context, and node logs may reveal host-level compromise. Kubernetes Events are useful but usually insufficient for full forensic reconstruction. Centralized storage should be secured with strong authorization, encryption, integrity protections, retention policies, and monitoring because it contains sensitive and valuable evidence. Effective incident readiness requires collecting important data before compromise occurs, since missing evidence cannot be recreated later.

Question 400.

Which approach BEST represents a mature Kubernetes and cloud-native security program across development, deployment, and runtime?

1. Focus primarily on perimeter controls and pre-deployment image scanning
2. Use RBAC and NetworkPolicies while granting CI/CD systems broad permissions for efficiency
3. Enforce strong admission policies and assume admitted workloads remain trustworthy afterward
4. Continuously combine identity security, least privilege, workload hardening, software supply chain controls, network segmentation, policy enforcement, vulnerability management, runtime monitoring, centralized logging, and incident response

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

Explanation:

A mature Kubernetes security program uses defense in depth throughout the entire cloud-native lifecycle. Identity controls and RBAC protect API access. Workload hardening reduces process privilege, writable attack surface, and unnecessary kernel access. Supply chain controls protect source repositories, dependencies, build systems, registries, signatures, provenance, and artifact promotion. Admission policies block known-insecure configurations before execution, while network segmentation limits lateral movement and unnecessary egress. Continuous vulnerability management is necessary because new weaknesses may emerge after deployment. Runtime monitoring, Kubernetes audit logs, and centralized telemetry provide detection and investigative visibility when preventive controls fail. Tested incident-response procedures help teams contain compromise, rotate credentials, preserve evidence, eradicate root causes, and recover safely.