View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps

 

Question 81.

A Kubernetes administrator wants to reduce the likelihood that one compromised namespace can affect workloads in other namespaces. Which combination of controls BEST supports this objective?

1. Namespace-scoped RBAC, NetworkPolicies, dedicated service accounts, and admission controls
2. A single shared service account for all namespaces
3. Cluster-admin access for every application
4. Unrestricted pod-to-pod networking

Correct Answer: 1. Namespace-scoped RBAC, NetworkPolicies, dedicated service accounts, and admission controls

Explanation:

Namespaces are useful organizational boundaries, but they do not provide complete security isolation on their own. Stronger separation requires several controls working together. Namespace-scoped RBAC can restrict which Kubernetes API resources users and workloads can access. Dedicated service accounts prevent unrelated applications from sharing the same identity. NetworkPolicies can limit communication between workloads and reduce lateral movement. Admission controls can prevent insecure pod configurations from being deployed. Additional safeguards may include resource quotas, separate Secrets, hardened containers, and runtime monitoring. Using cluster-wide administrative permissions or shared service accounts would substantially increase the blast radius of a compromise. A defense-in-depth model assumes that one control may fail and therefore uses multiple independent barriers to contain an attacker.

Question 82.

A security engineer wants to ensure that application pods cannot access Kubernetes API credentials unless they genuinely need them. Which configuration should be considered?

1. Increase pod memory limits
2. Disable automatic service account token mounting for workloads that do not need API access
3. Enable host networking
4. Use privileged containers

Correct Answer: 2. Disable automatic service account token mounting for workloads that do not need API access

Explanation:

Kubernetes workloads may receive service account credentials that allow them to authenticate to the API server. If an application never interacts with the Kubernetes API, automatically mounting those credentials creates unnecessary exposure. A compromised application could potentially steal the token and use whatever permissions are associated with the service account. Disabling automatic token mounting where it is not required supports least privilege and reduces credential exposure. Workloads that genuinely need Kubernetes API access should use dedicated service accounts with narrowly scoped RBAC permissions rather than broad shared identities. Organizations should also review token lifetimes, identity boundaries, logging, and access patterns. Host networking and privileged execution would increase the security risk rather than protect service account credentials.

Question 83.

Which Kubernetes security practice MOST directly reduces the risk that a container can modify critical files after an attacker gains code execution?

1. Increase the number of replicas
2. Add more labels
3. Configure a read-only root filesystem when compatible with the application
4. Use hostPID

Correct Answer: 3. Configure a read-only root filesystem when compatible with the application

Explanation:

A read-only root filesystem prevents a process from modifying most files included in the container image. This can make persistence, binary replacement, configuration tampering, and some forms of malware installation more difficult after a workload is compromised. Applications that require temporary or persistent writes can use explicitly defined writable volumes for only those locations that need modification. This reduces the writable attack surface while maintaining functionality. A read-only filesystem should be combined with other controls such as non-root execution, reduced Linux capabilities, allowPrivilegeEscalation: false, seccomp profiles, and NetworkPolicies. It does not prevent all attacks, because an application can still misuse network access or writable volumes, but it contributes meaningfully to container hardening and defense in depth.

Question 84.

A company wants to enforce a rule that production pods must not run as privileged containers. At what stage is it BEST to prevent this configuration from entering the cluster?

1. After the workload has been compromised
2. During manual log review
3. When the pod is deleted
4. During admission before the workload is persisted and scheduled

Correct Answer: 4. During admission before the workload is persisted and scheduled

Explanation:

Admission is an effective point for enforcing workload security because Kubernetes has already authenticated and authorized the request, but the resource has not yet been persisted and scheduled. An admission policy can reject privileged containers before they reach runtime. Similar rules can prevent host namespace access, unsafe volume mounts, root execution, missing security contexts, or images from unauthorized registries. Preventive enforcement is generally more effective than detecting a dangerous workload only after deployment. Runtime monitoring still remains important because malicious behavior can occur even in workloads that passed policy checks. A mature security strategy therefore combines CI/CD checks, admission controls, secure defaults, RBAC, network restrictions, image verification, and runtime monitoring.

Question 85.

Which action BEST follows the principle of least privilege for a service account used by a pod that only needs to read one ConfigMap in its namespace?

1. Grant read access only to the required resource in that namespace
2. Grant cluster-admin privileges
3. Bind the service account to every ClusterRole
4. Share an administrator token with the pod

Correct Answer: 1. Grant read access only to the required resource in that namespace

Explanation:

Least privilege means granting only the exact permissions required for a workload to function. If a pod only needs to read a ConfigMap in its own namespace, the service account should receive narrowly scoped read permissions rather than broad cluster-wide authority. A Role can define the required access and a RoleBinding can associate that Role with the workload’s service account. This minimizes the impact if the pod is compromised because the stolen identity cannot automatically modify unrelated workloads, read Secrets, or administer the cluster. Administrators should avoid defaulting to overly broad roles for convenience. Permissions should also be reviewed periodically, especially when application functionality changes, because unnecessary access frequently accumulates over time and increases the potential blast radius of credential compromise.

Question 86.

A security team wants to prevent a container from acquiring additional privileges through mechanisms such as setuid binaries. Which security context setting should be used where appropriate?

1. hostNetwork: true
2. allowPrivilegeEscalation: false
3. privileged: true
4. hostIPC: true

Correct Answer: 2. allowPrivilegeEscalation: false

Explanation:

Setting allowPrivilegeEscalation to false helps prevent a process from gaining privileges beyond those of its parent process. This is a useful workload-hardening control because some privilege-escalation techniques rely on mechanisms such as setuid binaries or file capabilities. The setting is most effective when combined with running containers as non-root, dropping unnecessary Linux capabilities, applying seccomp profiles, and avoiding privileged mode. Workloads should also minimize host namespace and host filesystem access. No single security context setting eliminates every privilege escalation path, but limiting the ability to gain additional privileges meaningfully reduces risk. By contrast, enabling privileged mode or host namespaces would expand the workload’s access to sensitive host resources.

Question 87.

Which Linux security feature can reduce container attack surface by filtering the system calls available to a process?

1. Ingress
2. ConfigMap
3. seccomp
4. Horizontal Pod Autoscaler

Correct Answer: 3. seccomp

Explanation:

seccomp is a Linux kernel security mechanism that can restrict which system calls a process is allowed to invoke. Containers often require only a subset of the kernel’s available system calls, so blocking unnecessary calls can reduce exposure to kernel attack paths. Kubernetes can apply seccomp profiles through pod security configuration. A restrictive but compatible profile can help prevent compromised applications from performing dangerous low-level operations. seccomp should be used together with non-root execution, reduced capabilities, AppArmor or SELinux where appropriate, read-only filesystems, and strong runtime monitoring. It is not a substitute for patching the kernel or container runtime. Ingress, ConfigMaps, and autoscaling features do not provide syscall-level process restrictions.

Question 88.

An organization needs a mandatory access control mechanism that can restrict how container processes interact with files and system resources on supported Linux nodes. Which technology should it consider?

1. Service discovery
2. Pod affinity
3. ReplicaSets
4. AppArmor or SELinux

Correct Answer: 4. AppArmor or SELinux

Explanation:

AppArmor and SELinux are Linux mandatory access control technologies that can impose restrictions beyond normal Unix file permissions. They can constrain which files, devices, capabilities, or other system resources a process may access even if the process would otherwise have permission. In containerized environments, these mechanisms add an important layer of defense when workloads are compromised. Policies should be carefully designed and tested because overly restrictive profiles can break legitimate application behavior. Mandatory access control works best alongside seccomp, non-root execution, capability reduction, admission policies, and restricted host access. Pod affinity and ReplicaSets affect scheduling and availability rather than process access control, while service discovery helps workloads locate network endpoints.

Question 89.

A security engineer finds that an application container is running as UID 0 even though the application does not require root privileges. Which remediation is MOST appropriate?

1. Configure the workload and image to run as a non-root user
2. Enable privileged mode
3. Mount the host root filesystem
4. Grant additional capabilities

Correct Answer: 1. Configure the workload and image to run as a non-root user

Explanation:

Running containers as non-root reduces the privileges available to an attacker if the application is compromised. The image should be built so the application can function with an unprivileged user, and Kubernetes security context settings such as runAsNonRoot or an explicit non-root user ID can help enforce the requirement. File permissions and writable directories may need to be adjusted during image development. Non-root execution does not guarantee isolation, but it removes a common source of unnecessary privilege. The workload should also avoid privileged mode, drop unnecessary Linux capabilities, use a read-only root filesystem where practical, and prevent privilege escalation. Mounting host filesystems or granting more capabilities would increase the risk.

Question 90.

A containerized application requires only one specific Linux capability. Which approach BEST follows secure container design?

1. Grant all capabilities to avoid application errors
2. Drop unnecessary capabilities and add back only the required capability
3. Run the pod as privileged
4. Enable hostPID and hostIPC

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

Explanation:

Linux capabilities break traditional root authority into smaller privileges. A secure container should receive only the capabilities it actually needs. Dropping broad capability sets and adding back a narrowly required capability reduces the number of privileged operations a compromised process can perform. This principle is especially important in production because excessive capabilities can facilitate privilege escalation, network manipulation, or host interaction. Capability configuration should be tested carefully so the application still functions correctly. It should also be combined with non-root execution, allowPrivilegeEscalation: false, seccomp profiles, restricted host access, and admission policies. Privileged mode effectively bypasses many isolation controls and is therefore inappropriate when a narrowly scoped capability can satisfy the application requirement.

Question 91.

Why should hostPID generally be avoided for ordinary application pods?

1. It exposes the host process namespace and can weaken workload isolation
2. It prevents pods from using storage
3. It disables DNS
4. It automatically rotates Secrets

Correct Answer: 1. It exposes the host process namespace and can weaken workload isolation

Explanation:

When a pod uses the host PID namespace, processes inside the pod can observe processes running on the Kubernetes node. Depending on other permissions and vulnerabilities, this additional visibility may facilitate attacks against host processes or other workloads. Ordinary applications rarely require access to the node’s process namespace, so enabling hostPID creates unnecessary risk. Security policies should generally prohibit hostPID except for carefully reviewed system components that have a legitimate operational need. Similar caution should apply to hostNetwork, hostIPC, hostPath volumes, and privileged containers. When host-level access is unavoidable, administrators should apply compensating controls such as restricted capabilities, strong RBAC, node isolation, admission controls, and enhanced runtime monitoring.

Question 92.

A security team wants to detect if an attacker starts a cryptocurrency miner inside a compromised application pod. Which capability is MOST useful?

1. Resource labels
2. Runtime process and behavioral monitoring
3. PersistentVolumeClaims
4. Service selectors

Correct Answer: 2. Runtime process and behavioral monitoring

Explanation:

Runtime monitoring can observe processes, system calls, file changes, network behavior, and resource consumption while a workload is executing. A cryptocurrency miner may appear as an unexpected process, unusual CPU utilization, suspicious outbound connections, or execution of binaries not normally used by the application. Static image scanning cannot detect malicious activity introduced after deployment, so runtime visibility is an important complementary control. Security teams should establish expected workload behavior and investigate anomalies in context. Runtime detection should be paired with hardened containers, restrictive network access, admission controls, image verification, and centralized logging. Persistent volumes and service selectors manage storage and networking relationships but do not detect suspicious process execution.

Question 93.

A production pod starts executing an unexpected shell command that has never appeared during normal operation. What does this MOST likely represent from a security monitoring perspective?

1. A potential runtime anomaly requiring investigation
2. A normal Kubernetes scheduling event
3. A storage provisioning event
4. A DNS configuration update

Correct Answer: 1. A potential runtime anomaly requiring investigation

Explanation:

Unexpected shell execution inside a production container can be a meaningful sign of exploitation or unauthorized administration, particularly when the application normally runs a fixed process without interactive shell activity. Security teams should investigate the process tree, image identity, network connections, Kubernetes audit activity, recent deployments, and associated credentials. The event may have a legitimate operational explanation, so context matters, but it should not be ignored simply because the workload continues functioning. Mature runtime security relies on baselining expected behavior and identifying deviations such as shells, package managers, unusual binaries, privilege changes, or unexpected outbound traffic. Logs and forensic evidence should be preserved before remediation when practical.

Question 94.

Which security practice BEST protects sensitive Kubernetes API data stored in etcd?

1. Use plain-text backups stored publicly
2. Enable encryption at rest and tightly control access to encryption keys and etcd
3. Grant every administrator direct etcd access
4. Disable authentication to simplify recovery

Correct Answer: 2. Enable encryption at rest and tightly control access to encryption keys and etcd

Explanation:

etcd stores critical Kubernetes cluster state, including objects that may contain sensitive data. Encryption at rest can protect selected API data if underlying storage or backups are exposed. The encryption keys themselves become highly sensitive assets and must be protected carefully. Direct access to etcd should also be tightly restricted because bypassing the Kubernetes API can bypass normal authorization controls. Backups require similar protection because they may contain the same sensitive cluster data as the live datastore. Encryption at rest should be combined with secure transport, strong access controls, RBAC, audit logging, Secret-management practices, and tested key-rotation procedures. Public or unauthenticated access to etcd would create severe cluster compromise risk.

Question 95.

A company backs up etcd regularly. Which security consideration is MOST important for those backups?

1. Treat them as sensitive because they may contain cluster configuration and Secrets
2. Publish them for easier recovery
3. Disable backup encryption
4. Store them in application container images

Correct Answer: 1. Treat them as sensitive because they may contain cluster configuration and Secrets

Explanation:

An etcd backup can contain much of the same sensitive information as the live Kubernetes datastore. If an attacker obtains the backup, they may gain access to configuration, credentials, Secrets, workload definitions, and other operational data. Backups should therefore be encrypted, access-controlled, logged, and stored in a secure location. Recovery permissions should be limited to authorized personnel, and backup integrity should be verified. Retention policies should reflect business and security requirements rather than keeping unnecessary copies indefinitely. Organizations should also test restoration procedures so backups remain useful during an incident or disaster. A backup is not harmless simply because it is offline; in many environments it represents a highly valuable collection of cluster secrets and configuration.

Question 96.

A company wants to prevent unauthorized users from reading Kubernetes Secrets while still allowing them to view Pods in a namespace. Which control should be used?

1. Disable networking
2. Configure RBAC permissions that allow Pod access but not Secret access
3. Use larger nodes
4. Increase pod replicas

Correct Answer: 2. Configure RBAC permissions that allow Pod access but not Secret access

Explanation:

Kubernetes RBAC allows permissions to be defined by resource type and action. A Role can allow users to get, list, or watch Pods while omitting permissions to access Secrets. This supports least privilege and reduces unnecessary exposure of credentials. Secret access is particularly sensitive because reading a Secret may enable authentication to databases, external APIs, or other infrastructure. Administrators should also consider indirect ways users might obtain Secrets, such as creating pods that mount them, and design permissions accordingly. RBAC should therefore be reviewed holistically rather than treating each verb in isolation. Node size and replica counts are operational concerns and do not provide authorization control over Kubernetes API resources.

Question 97.

Which practice BEST protects Kubernetes administrative access in an organization with many platform engineers?

1. Use individual identities, strong authentication, narrowly scoped roles, and audit logging
2. Share a single cluster-admin kubeconfig
3. Disable API audit logs
4. Store administrator credentials in a public repository

Correct Answer: 1. Use individual identities, strong authentication, narrowly scoped roles, and audit logging

Explanation:

Individual identities improve accountability and allow permissions to be tailored to each engineer’s actual responsibilities. Strong authentication reduces the likelihood that stolen passwords alone are sufficient for access, while narrowly scoped RBAC limits what a compromised identity can do. Kubernetes audit logs provide evidence of administrative actions and can support alerting on unusual privilege changes or destructive operations. Shared cluster-admin credentials make attribution difficult and create a single high-value credential that may remain valid after personnel changes. Privileged access should also be reviewed regularly and removed promptly when no longer needed. Mature environments may additionally use short-lived credentials, privileged access workflows, centralized identity providers, and alerts for sensitive administrative operations.

Question 98.

A security team wants an alert whenever a user unexpectedly creates a privileged pod in a production namespace. Which combination provides the BEST visibility and prevention?

1. More replicas and larger nodes
2. Admission policy enforcement plus Kubernetes audit monitoring
3. A ConfigMap and Service
4. A PersistentVolume and Ingress

Correct Answer: 2. Admission policy enforcement plus Kubernetes audit monitoring

Explanation:

Admission policies can prevent privileged pods from being accepted into the cluster, while Kubernetes audit logs can record who attempted to create the workload and what the request contained. Combining prevention with visibility is stronger than relying on either approach alone. If the request is denied, the audit record can still support investigation of whether the attempt was accidental or malicious. Security teams can alert on repeated violations, unusual users, or attempts from unexpected locations. CI/CD checks can provide an earlier layer, while runtime monitoring protects against behaviors not caught during admission. Storage, networking, and scaling resources do not directly prevent or track privileged workload creation.

Question 99.

An organization wants to reduce lateral movement if an attacker compromises a front-end pod. Which architecture BEST supports this objective?

1. Restrictive NetworkPolicies that allow the front end to reach only the services it requires
2. Allow the front end to communicate with every pod and node
3. Give the front-end service account cluster-admin permissions
4. Mount all application Secrets into the front-end pod

Correct Answer: 1. Restrictive NetworkPolicies that allow the front end to reach only the services it requires

Explanation:

Lateral movement occurs when an attacker uses one compromised workload as a stepping stone to reach additional systems. Restrictive NetworkPolicies can reduce this opportunity by permitting the front end to communicate only with necessary back-end services and required infrastructure such as DNS. The workload should also have a dedicated service account with minimal RBAC permissions and access only to Secrets it genuinely requires. Egress restrictions can further limit communication with unexpected external destinations. NetworkPolicy does not replace application authentication or authorization, but it adds an independent containment layer. Unrestricted communication, cluster-admin privileges, and broadly mounted credentials would all make it substantially easier for an attacker to expand control after compromising the front-end application.

Question 100.

Which approach BEST represents a complete security strategy for a Kubernetes production environment?

1. Rely exclusively on a network firewall at the cluster perimeter
2. Scan images before deployment and assume runtime behavior will remain safe
3. Combine secure identities, least-privilege RBAC, hardened workloads, NetworkPolicies, supply chain protections, admission enforcement, encryption, monitoring, and incident response
4. Grant broad permissions to simplify administration

Correct Answer: 3. Combine secure identities, least-privilege RBAC, hardened workloads, NetworkPolicies, supply chain protections, admission enforcement, encryption, monitoring, and incident response

Explanation:

Kubernetes security requires multiple coordinated layers because no single control can address every threat. Identity and RBAC limit administrative and workload permissions. Container hardening reduces privilege and attack surface. NetworkPolicies limit communication paths. Supply chain controls help establish trust in source code and images, while admission policies prevent unsafe configurations from entering production. Encryption protects sensitive information in transit and at rest where appropriate. Centralized logging, audit records, and runtime monitoring help detect suspicious activity, and tested incident-response procedures prepare the organization to contain and recover from compromise. Continuous vulnerability management and periodic access reviews are also essential because environments and threats change over time. This defense-in-depth approach provides substantially stronger resilience than relying only on perimeter controls or one-time image scanning.