View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps

 

Question 161.

A platform team wants to reduce the risk that a compromised Kubernetes workload can access cloud-provider credentials available from the underlying node. Which security principle is MOST important?

1. Prevent unnecessary workload access to node-level metadata and host resources
2. Restrict application namespaces only through naming conventions
3. Increase node resource reservations to isolate system processes
4. Use separate Services for internal and external traffic

Correct Answer: 1. Prevent unnecessary workload access to node-level metadata and host resources

Explanation:

Workloads should not have unrestricted access to node-level resources or cloud metadata endpoints that may expose powerful infrastructure credentials. If a compromised pod obtains credentials inherited from the underlying node, the attacker may gain permissions far beyond the original application. Appropriate protections include workload-specific cloud identities, metadata-service restrictions, network controls, node hardening, and avoiding unnecessary host networking or privileged execution. Cloud permissions should also follow least privilege so a stolen identity has limited impact. Namespace organization and Service design can improve manageability, but they do not directly prevent a pod from obtaining sensitive node-level credentials. Protecting the boundary between workloads and underlying infrastructure is therefore the strongest answer.

Question 162.

A Kubernetes cluster contains applications owned by several development teams. Which approach BEST limits the damage if one team’s workload credentials are compromised?

1. Place all applications in one namespace but use different labels
2. Use a common service account while limiting container capabilities
3. Use separate namespaces, service accounts, RBAC permissions, Secrets, and NetworkPolicies
4. Use a shared cluster role with read access to all application namespaces

Correct Answer: 3. Use separate namespaces, service accounts, RBAC permissions, Secrets, and NetworkPolicies

Explanation:

Separating workloads across multiple security controls reduces the blast radius of a compromise. Dedicated service accounts prevent unrelated applications from sharing an identity. Namespace-scoped RBAC can limit Kubernetes API access, separate Secrets reduce credential reuse, and NetworkPolicies can restrict lateral communication between workloads. Namespaces by themselves are not complete security boundaries, so layering these mechanisms is important. A shared service account or broad cluster role creates unnecessary trust between teams and allows compromise in one application to affect others more easily. Labels help organization and policy selection, but they are not a substitute for identity, authorization, credential separation, and network segmentation. Defense in depth is the central principle behind the recommended design.

Question 163.

Which Kubernetes authorization practice is MOST appropriate for a monitoring application that only needs to list pods and read metrics-related resources?

1. Grant a reusable ClusterRole that also permits deployment updates
2. Grant only the required read permissions to a dedicated service account
3. Allow the monitoring application to read all Secrets for troubleshooting
4. Bind the monitoring application to an administrative role during startup

Correct Answer: 2. Grant only the required read permissions to a dedicated service account

Explanation:

A monitoring workload should receive only the permissions required for monitoring. If it needs to list pods and read metrics-related resources, its service account should receive narrowly scoped read permissions rather than write access or permissions to sensitive resources such as Secrets. The exact scope may be namespaced or cluster-wide depending on monitoring requirements, but the granted verbs and resources should remain minimal. Allowing deployment updates or administrative access would unnecessarily expand the impact of a compromised monitoring component. A dedicated service account also makes auditing and revocation easier. Kubernetes least privilege requires considering both the resource scope and permitted actions instead of giving applications broad permissions simply because they operate across many workloads.

Question 164.

An organization wants to make it difficult for users to grant themselves additional Kubernetes privileges. Which resource changes should be especially restricted and monitored?

1. Service selector updates that redirect application traffic
2. ConfigMap changes containing runtime configuration
3. Namespace label changes used by policy engines
4. RoleBindings and ClusterRoleBindings that grant privileged roles

Correct Answer: 4. RoleBindings and ClusterRoleBindings that grant privileged roles

Explanation:

RoleBindings and ClusterRoleBindings connect identities to RBAC permissions and can therefore provide a direct privilege-escalation path. A user who can create or alter a binding to a powerful ClusterRole may effectively grant themselves or another identity broad administrative privileges. Permissions to manage these resources should be limited to trusted administrators and monitored through Kubernetes audit logs. Configuration changes to Services, ConfigMaps, or namespace labels can also be security-sensitive in some environments, especially when policies depend on them, but privileged RBAC bindings provide the most direct authorization impact. Mature environments may additionally use approval processes or admission policies to control highly sensitive authorization changes and generate alerts when unexpected privileged bindings appear.

Question 165.

Which practice BEST protects Kubernetes administrator credentials stored on an engineer’s workstation?

1. Use strong endpoint security, restricted file permissions, short-lived credentials where practical, and secure identity mechanisms
2. Store a long-lived kubeconfig in a team-shared encrypted folder
3. Use a dedicated cluster-admin credential that never expires but requires VPN access
4. Copy administrator tokens into local shell profiles to simplify access

Correct Answer: 1. Use strong endpoint security, restricted file permissions, short-lived credentials where practical, and secure identity mechanisms

Explanation:

Administrative credentials are highly valuable because they may allow significant control over a Kubernetes cluster. Workstations using those credentials should have strong local security, encrypted storage, current patches, restricted file permissions, and secure authentication. Short-lived credentials obtained through a centralized identity provider can reduce exposure compared with long-lived static tokens. Multi-factor authentication and controlled privilege elevation can further strengthen protection. A shared credential, even in an encrypted folder, weakens individual accountability and complicates revocation. Long-lived cluster-admin tokens remain dangerous if stolen, even behind a VPN. Embedding tokens in shell profiles also increases the chance of accidental exposure through backups, debugging, or local compromise.

Question 166.

A company wants to reduce the security risk from containers that include package managers, shells, and debugging tools not required at runtime. Which action should be taken?

1. Keep debugging tools but restrict them through RBAC
2. Use admission policies to prevent shell execution after deployment
3. Build smaller production images containing only required runtime components
4. Place debugging utilities on a writable persistent volume

Correct Answer: 3. Build smaller production images containing only required runtime components

Explanation:

Minimal production images reduce attack surface by excluding unnecessary packages, shells, compilers, and debugging utilities. Every additional component may introduce vulnerabilities or provide an attacker with useful tools after compromise. Multi-stage builds are commonly used so build-time dependencies remain in an earlier stage while only required runtime files are copied into the final image. RBAC does not control whether binaries inside a container can execute, and moving debugging tools to a writable volume still makes them available. Admission policies may restrict some workload settings but cannot generally replace good image construction. Minimal images should still be scanned, patched, signed, and monitored because reducing image size does not guarantee that the remaining application is secure.

Question 167.

Which security benefit is provided by pinning application dependencies to known versions during a controlled build process?

1. It prevents runtime containers from making outbound connections
2. It improves reproducibility and reduces unexpected dependency changes
3. It guarantees that pinned dependencies are free of vulnerabilities
4. It removes the need to verify artifact provenance

Correct Answer: 2. It improves reproducibility and reduces unexpected dependency changes

Explanation:

Pinning dependencies allows teams to build software from known component versions instead of unexpectedly receiving a newer or modified dependency during a build. This improves reproducibility, troubleshooting, auditability, and supply chain control. However, pinned software can become vulnerable over time, so organizations still need continuous vulnerability monitoring and controlled dependency updates. Lock files, checksums, trusted package repositories, signatures, and provenance can further strengthen confidence in the build process. Pinning does not control runtime network behavior, nor does it guarantee that a selected version is secure. It also does not replace artifact provenance. Instead, it provides a predictable software composition that security teams can evaluate and reproduce reliably.

Question 168.

A security team wants to ensure that a container image cannot be silently changed after it has passed security review. Which combination is MOST effective?

1. Protected tags and a private registry without signature verification
2. Vulnerability scanning combined with periodic registry backups
3. Admission checks based only on repository name
4. Image digests, restricted registry writes, and signature verification

Correct Answer: 4. Image digests, restricted registry writes, and signature verification

Explanation:

Image digests identify exact artifact contents and eliminate ambiguity associated with mutable tags. Restricting registry write permissions reduces the chance that unauthorized users can replace approved artifacts, while signature verification provides evidence that an image was produced or approved by a trusted signing identity. These controls work best with build provenance, SBOMs, vulnerability scanning, and admission enforcement. Private registries provide useful access control but do not by themselves prove that stored content has not been altered. Repository-name checks are also weaker because an attacker with write access could place malicious content in an approved repository. Combining immutable identity, controlled publication, and cryptographic verification offers stronger protection against silent artifact substitution.

Question 169.

A CI pipeline uses a token that can deploy to every production namespace and modify cluster-wide RBAC. What is the primary security concern?

1. The token has excessive privileges and creates a large blast radius if compromised
2. The token may cause deployment conflicts between namespaces
3. The pipeline may bypass application NetworkPolicies during deployment
4. The token cannot be rotated while workloads are running

Correct Answer: 1. The token has excessive privileges and creates a large blast radius if compromised

Explanation:

A deployment pipeline should receive only the permissions required for its intended applications and environments. A token that can deploy everywhere and modify cluster-wide RBAC is highly privileged and creates a serious escalation path if stolen. An attacker could deploy malicious workloads, alter authorization policies, access unrelated namespaces, or establish persistent privileged identities. Pipeline permissions should therefore be narrowed by namespace, environment, and resource type where practical. Short-lived credentials and separate identities for different stages can further reduce risk. NetworkPolicies normally regulate workload traffic rather than the pipeline’s Kubernetes API authorization. Rotation is also possible with appropriate design. The central issue is excessive authorization and the resulting blast radius.

Question 170.

Which practice BEST protects CI/CD secrets from accidental exposure in build logs?

1. Store credentials in pipeline environment variables and print them only during failed jobs
2. Write secrets to temporary files that remain in build artifacts
3. Use secret-masking and secure credential injection while preventing unnecessary logging of secret values
4. Use one shared build token so fewer secret values need to be managed

Correct Answer: 3. Use secret-masking and secure credential injection while preventing unnecessary logging of secret values

Explanation:

Build logs may be retained for long periods and visible to people who do not have direct access to the underlying secret store. CI/CD platforms should therefore inject credentials through supported secure mechanisms, mask sensitive output, and ensure scripts do not echo secrets during normal or error handling. Temporary files must also be removed securely and excluded from artifacts. Shared credentials increase the blast radius and weaken accountability. Even environment variables can leak through debug output, process inspection, or poorly designed scripts if they are not handled carefully. If a credential appears in logs, it should generally be treated as exposed and rotated. Secure pipeline secret handling is an essential part of software supply chain protection.

Question 171.

A security team wants to detect whether an attacker modifies Kubernetes RBAC to grant cluster-admin access to a new user. Which telemetry is MOST valuable?

1. Container runtime CPU metrics
2. Kubernetes audit logs
3. Network flow logs between application pods
4. Image vulnerability scan reports

Correct Answer: 2. Kubernetes audit logs

Explanation:

Kubernetes audit logs can record API requests that create or modify RBAC resources such as ClusterRoleBindings. They can show which authenticated identity performed the operation, which resource was affected, when it happened, and whether it succeeded. Security teams can alert on creation of bindings to cluster-admin or other highly privileged roles, particularly when the actor or timing is unusual. Runtime metrics and network flow logs provide useful security context but do not directly capture RBAC API changes. Vulnerability scan results describe software weaknesses rather than administrative activity. Audit logs should be forwarded to protected centralized storage so an attacker who gains cluster control cannot easily erase the evidence needed for investigation.

Question 172.

Which activity would MOST likely indicate possible credential theft or unauthorized Kubernetes API use?

1. A service account reading the same ConfigMap during every startup
2. A Deployment controller maintaining the desired replica count
3. A normal application resolving an internal Service through DNS
4. A service account suddenly accessing Secrets it has never accessed before

Correct Answer: 4. A service account suddenly accessing Secrets it has never accessed before

Explanation:

A sudden change in resource-access behavior can indicate compromised credentials or misuse, even if the requested action is technically authorized. If a service account historically reads only ConfigMaps and unexpectedly begins retrieving Secrets, security teams should investigate whether the application’s requirements legitimately changed or whether the identity has been stolen. Kubernetes audit logs can reveal the requests and source identity, while runtime and network telemetry provide additional context. Strong preventive RBAC should ideally stop the access entirely when it is unnecessary. Expected DNS queries, controller behavior, and repeated reads of known configuration are typically normal. Behavioral monitoring is valuable because attackers frequently misuse valid credentials rather than generating obviously invalid requests.

Question 173.

A production workload starts creating new pods even though its normal function does not require Kubernetes API access. What should the security team investigate FIRST?

1. Whether the node’s kubelet is using excessive CPU
2. Whether its service account credentials or permissions have been misused
3. Whether a new StorageClass was recently installed
4. Whether the workload’s readiness probe is failing

Correct Answer: 2. Whether its service account credentials or permissions have been misused

Explanation:

Unexpected pod creation by an ordinary application workload strongly suggests that its Kubernetes identity and RBAC permissions deserve immediate review. If the workload possesses a service account token and has permission to create pods, an attacker may be using those credentials to expand control or deploy additional malicious workloads. Investigators should examine Kubernetes audit logs, service account permissions, runtime process activity, new pod specifications, recent application changes, and network behavior. Containment may include revoking or restricting the identity and isolating the original workload while preserving evidence. This scenario also demonstrates why workloads that do not require API access should not receive unnecessary service account tokens or permissions in the first place.

Question 174.

Which approach BEST reduces the risk that a newly compromised pod can scan every internal service in the cluster?

1. Require mutual TLS between only Internet-facing services
2. Place the pod in a namespace with a resource quota
3. Use restrictive NetworkPolicies to limit the pod’s permitted communication paths
4. Reduce the pod’s memory limit

Correct Answer: 3. Use restrictive NetworkPolicies to limit the pod’s permitted communication paths

Explanation:

A compromised pod with broad east-west connectivity can scan internal IP addresses, discover services, probe management interfaces, and attempt lateral movement. NetworkPolicies can restrict the workload to the communication paths it genuinely requires. For example, a front-end service might be allowed to contact one API service and DNS but not internal databases or unrelated namespaces. Resource quotas limit consumption rather than connectivity, while memory limits do not prevent scanning. Mutual TLS is valuable for authentication and encryption but only on the connections where it is deployed; it does not prevent the pod from attempting connections to other targets. Restrictive network policy is therefore the most direct control for limiting internal reachability.

Question 175.

An organization wants to detect sensitive data leaving a compromised application through an unexpected outbound connection. Which security capabilities are MOST useful?

1. Admission control combined with container image signing
2. Resource quotas combined with PodDisruptionBudgets
3. Secret encryption at rest combined with RBAC
4. Runtime network monitoring combined with egress controls

Correct Answer: 4. Runtime network monitoring combined with egress controls

Explanation:

Egress restrictions provide a preventive layer by limiting which external destinations a workload may contact, while runtime network monitoring helps identify unusual destinations, unexpected traffic volumes, or communication patterns associated with exfiltration and command-and-control activity. Combining prevention and detection is stronger than either control alone. Image signing and admission policies help establish trust before deployment but cannot fully predict runtime behavior. Secret encryption protects data stored in the Kubernetes datastore, not arbitrary application data leaving over the network. Resource quotas manage consumption. For sensitive workloads, teams may also use data-loss prevention technologies, TLS inspection where appropriate and lawful, and application-level monitoring to provide additional context around outbound data movement.

Question 176.

A cluster runs a sensitive database service that should receive connections only from one backend application. Which design is MOST secure?

1. Allow connections from the namespace but require database authentication
2. Apply a NetworkPolicy allowing only the approved backend and require strong database authentication
3. Use a ClusterIP Service and rely on it as the only security boundary
4. Permit all internal traffic but encrypt connections with TLS

Correct Answer: 2. Apply a NetworkPolicy allowing only the approved backend and require strong database authentication

Explanation:

A strong design uses multiple controls. NetworkPolicy restricts which workloads can reach the database, while database authentication and authorization verify that the connecting workload has legitimate access. TLS can additionally protect sensitive data in transit. Merely using a ClusterIP Service does not create a security boundary, and allowing an entire namespace may still be broader than necessary if multiple workloads share that namespace. Encryption alone protects traffic confidentiality but does not prevent unauthorized workloads from attempting to connect. Layering network segmentation with application authentication follows zero-trust principles because neither network location nor cluster membership is treated as sufficient proof of authorization.

Question 177.

Which security practice BEST supports reliable forensic investigation after a Kubernetes workload is deleted during an incident?

1. Centralize audit, application, node, and runtime security logs outside the workload
2. Store only application stdout logs on the node
3. Increase container log rotation frequency without forwarding logs
4. Depend exclusively on Kubernetes Events for evidence

Correct Answer: 1. Centralize audit, application, node, and runtime security logs outside the workload

Explanation:

Pods are ephemeral, and deleting or restarting them can remove local runtime state and logs. Centralized logging preserves evidence independently of the workload lifecycle and allows security teams to correlate multiple sources. Kubernetes audit logs show API activity, application logs may reveal exploitation attempts, node logs provide host context, and runtime security telemetry can record suspicious processes or network behavior. Kubernetes Events are useful operational signals but generally do not provide enough detail for complete forensic reconstruction. Central logging platforms should have strong access controls, integrity protections, and retention policies because their data is sensitive. Organizations should also preserve exact image digests, deployment manifests, identity logs, and relevant cloud-provider telemetry when investigating serious incidents.

Question 178.

A Kubernetes node is suspected of compromise after a privileged workload accessed sensitive host files. Which response is MOST appropriate?

1. Reschedule the privileged pod and immediately return the node to normal use
2. Rotate only the application’s Secret and continue scheduling workloads
3. Delete the privileged pod and assume the host is unaffected
4. Isolate the node according to incident-response procedures and investigate before returning it to service

Correct Answer: 4. Isolate the node according to incident-response procedures and investigate before returning it to service

Explanation:

Privileged workloads can interact with host resources in ways ordinary containers cannot, so suspicious access to sensitive host files may indicate node-level compromise. The node should be contained according to the organization’s incident-response plan, potentially cordoned, isolated from sensitive networks, and removed from normal workload scheduling while evidence is preserved. Investigators should review node processes, files, credentials, network activity, Kubernetes audit logs, and the privileged workload’s image and behavior. Simply deleting the pod does not prove that changes to the host were undone. Depending on the severity and available evidence, rebuilding the node from a known-good image may be safer than attempting to clean it manually.

Question 179.

Which practice BEST improves Kubernetes incident readiness before a real security event occurs?

1. Grant security responders permanent cluster-admin permissions to every cluster
2. Define and regularly test playbooks for containment, credential rotation, evidence preservation, and recovery
3. Keep response procedures informal so teams can adapt during incidents
4. Retain only application logs because Kubernetes audit logs are too detailed

Correct Answer: 2. Define and regularly test playbooks for containment, credential rotation, evidence preservation, and recovery

Explanation:

Effective incident response depends on preparation. Teams should know who can isolate workloads or nodes, how to preserve evidence, how to revoke or rotate compromised credentials, and how clean recovery will be performed. Tabletop exercises and technical simulations expose gaps before a real incident creates time pressure. Permanent cluster-admin access is not necessary for every responder and can itself create risk; controlled emergency access is preferable in many environments. Response procedures should allow judgment but still provide tested guidance for common scenarios. Audit, runtime, identity, application, and infrastructure logs should be available before an incident because information that was never collected cannot be reconstructed later.

Question 180.

Which approach BEST represents a comprehensive Kubernetes security architecture for a business-critical environment?

1. Secure the Kubernetes API strongly and rely on default workload settings
2. Focus primarily on container vulnerability scanning and registry access control
3. Use network segmentation and runtime detection while trusting the CI/CD pipeline by default
4. Integrate identity security, RBAC, workload hardening, network segmentation, software supply chain controls, secret protection, admission policies, runtime detection, logging, and incident response

Correct Answer: 4. Integrate identity security, RBAC, workload hardening, network segmentation, software supply chain controls, secret protection, admission policies, runtime detection, logging, and incident response

Explanation:

Business-critical Kubernetes environments require defense in depth across the entire application and infrastructure lifecycle. Strong identity and RBAC protect control-plane access. Hardened containers reduce privileges, while NetworkPolicies and service authentication limit lateral movement. Supply chain controls protect source code, dependencies, CI/CD systems, images, signing processes, and registries. Secret protection reduces credential exposure, and admission policies stop insecure configurations before execution. Runtime monitoring, Kubernetes audit logs, and centralized telemetry provide visibility into behavior that preventive controls may miss. Finally, tested incident-response procedures support containment, credential rotation, evidence preservation, eradication, and recovery. No single layer—including API security, scanning, networking, or runtime monitoring—can address every cloud-native threat on its own.