{"id":21322,"date":"2026-09-24T12:04:58","date_gmt":"2026-09-24T12:04:58","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21322"},"modified":"2026-09-24T12:04:58","modified_gmt":"2026-09-24T12:04:58","slug":"linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part14-q261-280","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part14-q261-280\/","title":{"rendered":"Linux Foundation KCSA Practice Test Questions and Exam Dumps Part14 Q261-280"},"content":{"rendered":"

View Full <\/b>Linux Foundation KCSA Exam Dumps<\/b><\/a> and Practice Test Dumps<\/b><\/h2>\n

 <\/p>\n

Question 261.<\/b><\/p>\n

A Kubernetes workload needs to read ConfigMaps in its own namespace but does not require access to Secrets or write operations. Which RBAC configuration BEST follows least privilege?<\/b><\/p>\n

    \n
  1. <\/b> Create a dedicated service account with a namespaced Role allowing only the required read verbs on ConfigMaps<\/span><\/li>\n
  2. <\/b> Bind the workload to a ClusterRole that provides read access to all namespaced resources<\/span><\/li>\n
  3. <\/b> Use the default service account and allow read access to ConfigMaps and Secrets for operational flexibility<\/span><\/li>\n
  4. <\/b> Grant the workload temporary namespace-admin privileges and rely on application logic to avoid misuse<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1. Create a dedicated service account with a namespaced Role allowing only the required read verbs on ConfigMaps<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    A dedicated service account combined with a namespaced Role provides precise control over both identity and permissions. If the workload only needs to read ConfigMaps, the Role can include only the required verbs such as <\/span>get<\/span>, <\/span>list<\/span>, or <\/span>watch<\/span> on that resource type. A broader ClusterRole would expose additional resources or namespaces unnecessarily. Allowing Secret access for convenience creates additional risk because Secrets often contain credentials or tokens. Temporary namespace administration is also excessive because an attacker who compromises the workload could perform unrelated actions before the elevated access is removed. Kubernetes security is strongest when authorization reflects the application’s actual requirements rather than anticipated future needs. The service account’s permissions should also be reviewed periodically and monitored through audit logs.<\/span><\/p>\n

    Question 262.<\/b><\/p>\n

    A platform engineer discovers that a CI deployment identity can create RoleBindings that reference any ClusterRole. What is the PRIMARY security concern?<\/b><\/p>\n

      \n
    1. <\/b> The pipeline may deploy workloads to the wrong node pool<\/span><\/li>\n
    2. <\/b> The identity may be able to grant itself or another principal additional privileges<\/span><\/li>\n
    3. <\/b> The pipeline may bypass container image caching<\/span><\/li>\n
    4. <\/b> The identity may consume excessive namespace resources<\/span><\/li>\n<\/ol>\n

      Correct Answer: 2. The identity may be able to grant itself or another principal additional privileges<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      The ability to create RoleBindings or ClusterRoleBindings can become a privilege-escalation path when the identity is allowed to reference powerful roles. A compromised CI pipeline could bind itself, a service account, or another attacker-controlled principal to permissions that were never intended for the deployment process. This makes authorization-management permissions highly sensitive. CI\/CD identities should normally have narrowly scoped permissions to create or update only the workload resources they need. RBAC administration should be separated and controlled by trusted administrative workflows. Node selection, image caching, and resource consumption are operational issues but do not represent the same direct privilege-escalation risk. Audit logs should also monitor unexpected RBAC changes, especially bindings involving highly privileged ClusterRoles.<\/span><\/p>\n

      Question 263.<\/b><\/p>\n

      Which control BEST limits the damage if an attacker steals a service account token from a compromised application pod?<\/b><\/p>\n

        \n
      1. <\/b> Increase the service account token rotation interval<\/span><\/li>\n
      2. <\/b> Place the pod behind a ClusterIP Service<\/span><\/li>\n
      3. <\/b> Assign the service account only the minimum RBAC permissions required by the application<\/span><\/li>\n
      4. <\/b> Configure a higher pod restart limit<\/span><\/li>\n<\/ol>\n

        Correct Answer: 3. Assign the service account only the minimum RBAC permissions required by the application<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        If a service account token is stolen, the attacker’s effective Kubernetes API access is generally constrained by the permissions granted to that service account. Narrow RBAC therefore directly limits the blast radius. A workload that only needs to read a small set of resources should not be able to create pods, modify Deployments, read unrelated Secrets, or change authorization policies. Token lifetime and rotation are also important, but reducing privilege provides protection even while the stolen token remains valid. A ClusterIP Service affects network exposure rather than Kubernetes API authorization, and restart limits do not restrict credentials. Dedicated service accounts, short-lived tokens where supported, disabled token automounting when API access is unnecessary, and audit monitoring provide additional layers of protection.<\/span><\/p>\n

        Question 264.<\/b><\/p>\n

        An organization wants to prevent application teams from deploying pods that request hostPID, hostIPC, hostNetwork, or privileged mode unless an approved exception exists. Which mechanism is MOST appropriate?<\/b><\/p>\n

          \n
        1. <\/b> Runtime behavioral monitoring<\/span><\/li>\n
        2. <\/b> NetworkPolicy enforcement<\/span><\/li>\n
        3. <\/b> Namespace ResourceQuotas<\/span><\/li>\n
        4. <\/b> Admission policy enforcement with explicit security rules<\/span><\/li>\n<\/ol>\n

          Correct Answer: 4. Admission policy enforcement with explicit security rules<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          Admission enforcement can evaluate pod specifications before they are accepted into the cluster, making it the strongest preventive control for known-insecure workload settings. Policies can reject privileged containers, host namespace access, unsafe hostPath mounts, missing security contexts, or excessive capabilities. Runtime monitoring is still important because it detects suspicious behavior after deployment, but it is less effective for configurations that can be blocked before execution. NetworkPolicies govern traffic, while ResourceQuotas control consumption. A mature environment should define an exception process for trusted system workloads that legitimately require elevated access. Such exceptions should be narrow, documented, periodically reviewed, and combined with stronger monitoring or node isolation. Preventing insecure configuration at admission is more reliable than expecting every application team to apply hardening correctly.<\/span><\/p>\n

          Question 265.<\/b><\/p>\n

          A containerized service writes only temporary data to <\/b>\/cache<\/b>. Which filesystem configuration BEST minimizes writable attack surface?<\/b><\/p>\n

            \n
          1. <\/b> Set the root filesystem to read-only and mount a dedicated writable volume only at <\/span>\/cache<\/span><\/li>\n
          2. <\/b> Keep the root filesystem writable but restrict container CPU and memory<\/span><\/li>\n
          3. <\/b> Mount the node’s <\/span>\/var\/tmp<\/span> directory into <\/span>\/cache<\/span><\/li>\n
          4. <\/b> Run the container as privileged but use a read-only application directory<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. Set the root filesystem to read-only and mount a dedicated writable volume only at <\/b>\/cache<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            A read-only root filesystem prevents the application process, and therefore an attacker who compromises it, from modifying most binaries, libraries, and packaged configuration. If only <\/span>\/cache<\/span> needs to be writable, a dedicated volume at that location provides the necessary functionality without making the entire filesystem mutable. CPU and memory controls are valuable for resource management but do not prevent file tampering. Mounting a host directory exposes node-level storage and may create unnecessary host risk. Privileged mode weakens several isolation controls and is inappropriate for a simple writable-cache requirement. This design follows least privilege by allowing write access only where the application truly needs it. It should be combined with non-root execution, reduced capabilities, seccomp, and <\/span>allowPrivilegeEscalation: false<\/span>.<\/span><\/p>\n

            Question 266.<\/b><\/p>\n

            A container must use one specific Linux capability for a legitimate function but requires no other elevated privileges. Which configuration is MOST secure?<\/b><\/p>\n

              \n
            1. <\/b> Keep the runtime’s default capability set because removing capabilities may cause compatibility issues<\/span><\/li>\n
            2. <\/b> Drop unnecessary capabilities and add back only the one explicitly required<\/span><\/li>\n
            3. <\/b> Run as root but disable shell access<\/span><\/li>\n
            4. <\/b> Enable privileged mode and restrict network egress<\/span><\/li>\n<\/ol>\n

              Correct Answer: 2. Drop unnecessary capabilities and add back only the one explicitly required<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              Linux capabilities split traditional root privileges into smaller units, allowing applications to receive only the specific powers they need. If one capability is required, a secure configuration should remove unnecessary capabilities and explicitly add back only the required one. Keeping broad defaults increases the actions available to an attacker after compromise. Running as root does not solve the capability problem and may increase privilege further. Privileged mode grants extensive host-related power and cannot be made safe simply by restricting network access. Capability minimization should be combined with non-root execution, seccomp, mandatory access control, and disabled privilege escalation where compatible. The application should be tested with the reduced capability set so functionality is preserved without retaining unnecessary kernel-level privileges.<\/span><\/p>\n

              Question 267.<\/b><\/p>\n

              Which Kubernetes workload-hardening control MOST directly prevents a process from acquiring additional privileges through setuid binaries or file capabilities?<\/b><\/p>\n

                \n
              1. <\/b> readOnlyRootFilesystem: true<\/span><\/li>\n
              2. <\/b> runAsNonRoot: true<\/span><\/li>\n
              3. <\/b> allowPrivilegeEscalation: false<\/span><\/li>\n
              4. <\/b> automountServiceAccountToken: false<\/span><\/li>\n<\/ol>\n

                Correct Answer: 3. <\/b>allowPrivilegeEscalation: false<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                allowPrivilegeEscalation: false<\/span> specifically prevents a process from gaining more privileges than its parent process, limiting mechanisms such as setuid binaries and certain file capabilities. Running as non-root is also an important hardening measure, but a non-root process may still encounter privilege-escalation paths if they are not otherwise blocked. A read-only root filesystem reduces tampering and persistence opportunities but does not directly prevent a process from gaining higher privileges. Disabling service account token mounting protects Kubernetes API credentials rather than Linux process privilege. These controls are strongest when used together: non-root execution, capability reduction, disabled privilege escalation, seccomp, mandatory access control, and restricted filesystem writes create overlapping barriers that make container escape or host compromise more difficult.<\/span><\/p>\n

                Question 268.<\/b><\/p>\n

                Which Linux security mechanism is specifically designed to filter the system calls a container process may invoke?<\/b><\/p>\n

                  \n
                1. <\/b> AppArmor<\/span><\/li>\n
                2. <\/b> Kubernetes RBAC<\/span><\/li>\n
                3. <\/b> SELinux labels<\/span><\/li>\n
                4. <\/b> seccomp**<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 4. seccomp<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  seccomp allows the operating system to restrict the set of Linux system calls available to a process. Because many applications need only a subset of the kernel’s syscall interface, filtering unnecessary calls can reduce exposure to dangerous kernel functionality and limit some exploit techniques. AppArmor and SELinux are also important host-level security mechanisms, but they primarily provide mandatory access control rather than serving specifically as syscall filters. Kubernetes RBAC controls API authorization and does not regulate process interactions with the kernel. seccomp should be combined with non-root execution, capability reduction, AppArmor or SELinux, and runtime monitoring. Profiles must be tested carefully because blocking legitimate syscalls can cause application failures. The objective is to reduce kernel attack surface without disrupting required application behavior.<\/span><\/p>\n

                  Question 269.<\/b><\/p>\n

                  A production container includes package managers, compilers, debugging tools, and source code that are not required after the application is built. Which improvement BEST reduces attack surface?<\/b><\/p>\n

                    \n
                  1. <\/b> Use a multi-stage build and copy only necessary runtime artifacts into the final image<\/span><\/li>\n
                  2. <\/b> Keep the tools but restrict access to the container through NetworkPolicies<\/span><\/li>\n
                  3. <\/b> Retain the full image and use a read-only root filesystem<\/span><\/li>\n
                  4. <\/b> Store the debugging tools on a persistent volume instead of in the image<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1. Use a multi-stage build and copy only necessary runtime artifacts into the final image<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    Multi-stage builds separate build-time tools from runtime components. Compilers, package managers, source code, and debugging utilities can remain in an earlier stage, while the final production image contains only the application and required runtime libraries. This reduces the number of vulnerable packages and limits the tools available to an attacker after compromise. NetworkPolicies restrict communication but do not remove software from the image. A read-only root filesystem is useful but still leaves unnecessary binaries present and potentially executable. Moving tools to a persistent volume does not eliminate their availability. Minimal images should still be scanned, patched, signed, and associated with trusted provenance and SBOM data. Attack surface reduction is strongest when unnecessary software is removed rather than merely hidden or restricted.<\/span><\/p>\n

                    Question 270.<\/b><\/p>\n

                    Which artifact provides the MOST useful inventory for determining whether a container image includes a vulnerable open-source package?<\/b><\/p>\n

                      \n
                    1. <\/b> Kubernetes audit policy<\/span><\/li>\n
                    2. <\/b> Software Bill of Materials associated with the exact image artifact<\/span><\/li>\n
                    3. <\/b> PodDisruptionBudget<\/span><\/li>\n
                    4. <\/b> Network flow record<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2. Software Bill of Materials associated with the exact image artifact<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      An SBOM records the software components, libraries, and dependency versions contained in an artifact. When tied to an exact image digest, it gives security teams a reliable inventory of what is actually included in that specific image. During a vulnerability disclosure, the SBOM can be searched for the affected package to identify potentially impacted workloads quickly. It does not determine automatically whether the vulnerability is exploitable, so teams still need exposure analysis, vulnerability scanning, and remediation. Kubernetes audit policies record API activity, PodDisruptionBudgets support availability, and network flow data describes communication patterns. None of those sources provides detailed software composition. Accurate SBOMs are therefore a key supply chain capability for vulnerability response, compliance, and artifact transparency.<\/span><\/p>\n

                      Question 271.<\/b><\/p>\n

                      A container image passes security review, but the deployment references a mutable tag such as <\/b>stable<\/b>. Which change BEST preserves the exact approved artifact?<\/b><\/p>\n

                        \n
                      1. <\/b> Increase registry audit logging for the tag<\/span><\/li>\n
                      2. <\/b> Require the tag to be used only in production namespaces<\/span><\/li>\n
                      3. <\/b> Reference the approved image by immutable digest<\/span><\/li>\n
                      4. <\/b> Set the image pull policy to always retrieve the latest tag content<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 3. Reference the approved image by immutable digest<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        A mutable tag can be changed to reference different image content without altering the deployment manifest. An immutable digest, by contrast, identifies the exact image content that passed security review. Deploying by digest improves reproducibility, rollback confidence, forensic investigation, and supply chain assurance. Registry audit logging is valuable for detecting changes but does not ensure that the original image remains referenced. Limiting the tag to production does not stop it from being overwritten. <\/span>imagePullPolicy: Always<\/span> can actually make tag replacement more dangerous because restarted pods may pull new content under the same tag. Digest pinning should be combined with restricted registry writes, signature verification, provenance, vulnerability scanning, and admission policies for stronger artifact integrity.<\/span><\/p>\n

                        Question 272.<\/b><\/p>\n

                        Which control BEST prevents an unsigned or unapproved container image from running in a production cluster?<\/b><\/p>\n

                          \n
                        1. <\/b> A default-deny NetworkPolicy<\/span><\/li>\n
                        2. <\/b> A namespace ResourceQuota<\/span><\/li>\n
                        3. <\/b> Runtime process monitoring<\/span><\/li>\n
                        4. <\/b> Admission-time image signature or provenance verification**<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 4. Admission-time image signature or provenance verification<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          Admission-time verification can block workloads before execution when their images fail organizational trust requirements. Policies may require a valid signature from an approved authority, trusted provenance, an approved registry, or a known image digest. This creates a strong preventive supply chain control at the point of deployment. NetworkPolicies restrict runtime communication, ResourceQuotas manage consumption, and runtime monitoring detects suspicious behavior after workloads start. Those controls remain important but do not establish whether an artifact was approved before execution. Signing keys and provenance systems must themselves be protected because compromised trust infrastructure can allow malicious artifacts to appear legitimate. Verification should be layered with vulnerability scanning, registry access control, protected CI\/CD systems, SBOMs, and immutable references.<\/span><\/p>\n

                          Question 273.<\/b><\/p>\n

                          A CI system builds images, publishes them to a registry, and deploys them to Kubernetes. Which identity design BEST reduces the blast radius if one pipeline stage is compromised?<\/b><\/p>\n

                            \n
                          1. <\/b> Use separate narrowly scoped identities for build, registry publication, and deployment functions<\/span><\/li>\n
                          2. <\/b> Use one cluster-admin identity so every stage can complete without permission issues<\/span><\/li>\n
                          3. <\/b> Use a shared registry administrator token and a shared Kubernetes token for all environments<\/span><\/li>\n
                          4. <\/b> Store one encrypted master credential in the CI system and decrypt it only during jobs<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 1. Use separate narrowly scoped identities for build, registry publication, and deployment functions<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            Separating identities by function reduces the privileges exposed when one part of the pipeline is compromised. The build stage may need source and dependency access, the publication stage may require limited push access to specific repositories, and the deployment stage may need narrowly scoped Kubernetes permissions. A single powerful credential creates unnecessary coupling and a large blast radius. Encryption protects a credential while stored but does not reduce its authority after use. Shared tokens across environments also make compromise more damaging and weaken accountability. Mature CI\/CD security uses least privilege, separation of duties, short-lived credentials where possible, detailed audit logging, and protected release workflows. This limits how far an attacker can move through the software supply chain after compromising one component.<\/span><\/p>\n

                            Question 274.<\/b><\/p>\n

                            A production deployment pipeline needs permission to update Deployments in one namespace but does not need to modify Roles or RoleBindings. Which configuration is BEST?<\/b><\/p>\n

                              \n
                            1. <\/b> Grant namespace-admin because it simplifies future pipeline changes<\/span><\/li>\n
                            2. <\/b> Grant only the required deployment permissions and exclude RBAC administration<\/span><\/li>\n
                            3. <\/b> Grant a ClusterRole with write access to all namespaced resources<\/span><\/li>\n
                            4. <\/b> Allow RBAC modification only during maintenance windows<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 2. Grant only the required deployment permissions and exclude RBAC administration<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              A deployment pipeline should have only the permissions necessary for its intended task. If it needs to update Deployments in one namespace, the associated Role can grant the exact verbs and resources required while excluding authorization-management permissions. Giving namespace-admin or broad write access increases the damage possible if the pipeline is compromised. Allowing RBAC changes during maintenance windows still exposes a privilege-escalation path when those permissions are enabled. Pipeline access should be explicit, limited by environment and namespace, and monitored through Kubernetes audit logs. Where possible, short-lived credentials and controlled deployment workflows can further reduce risk. CI\/CD systems are high-value targets because attackers may use legitimate automation to deploy malicious artifacts or establish persistence.<\/span><\/p>\n

                              Question 275.<\/b><\/p>\n

                              A service account that normally reads ConfigMaps suddenly begins creating Pods and reading Secrets. What should the security team conclude FIRST?<\/b><\/p>\n

                                \n
                              1. <\/b> The behavior may indicate credential misuse, privilege escalation, or workload compromise and requires investigation<\/span><\/li>\n
                              2. <\/b> The behavior is normal because service accounts automatically gain permissions over time<\/span><\/li>\n
                              3. <\/b> The application is likely responding to a ResourceQuota change<\/span><\/li>\n
                              4. <\/b> The activity proves that admission policies are functioning correctly<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 1. The behavior may indicate credential misuse, privilege escalation, or workload compromise and requires investigation<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                A significant change in a service account’s behavior is a strong security signal. A workload that historically reads ConfigMaps but suddenly creates Pods and accesses Secrets may have been compromised, had its RBAC permissions changed, or be using stolen credentials. Security teams should review Kubernetes audit logs, recent Role or RoleBinding changes, pod processes, network activity, image provenance, and deployment history. Service accounts do not automatically gain permissions over time; their authorization is determined by RBAC configuration. ResourceQuotas affect resource consumption rather than API privilege. Admission controls may block some insecure operations, but unexpected authorized behavior can still occur. Behavioral monitoring is valuable because attackers frequently abuse valid credentials rather than generating obviously invalid requests.<\/span><\/p>\n

                                Question 276.<\/b><\/p>\n

                                A workload begins spawning shells, executing unfamiliar binaries, and scanning neighboring services. Which security capability is MOST useful for detecting this type of activity?<\/b><\/p>\n

                                  \n
                                1. <\/b> Image vulnerability scanning performed during CI<\/span><\/li>\n
                                2. <\/b> Namespace ResourceQuotas<\/span><\/li>\n
                                3. <\/b> Runtime behavioral monitoring<\/span><\/li>\n
                                4. <\/b> PodDisruptionBudgets<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 3. Runtime behavioral monitoring<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  Runtime monitoring observes what workloads actually do after they start. It can detect unexpected process execution, shell activity, network scanning, filesystem modification, suspicious system calls, and other behavior that static pre-deployment scans cannot predict. Image vulnerability scanning remains important but focuses on known software weaknesses rather than malicious actions occurring after exploitation. ResourceQuotas and PodDisruptionBudgets address consumption and availability. Runtime telemetry should be correlated with Kubernetes audit logs, network data, identity events, and deployment history to provide context. When suspicious behavior is detected, incident-response procedures may require containment, evidence preservation, credential rotation, and remediation. Preventive hardening reduces attack opportunities, while runtime detection provides visibility when preventive controls fail or an application vulnerability is successfully exploited.<\/span><\/p>\n

                                  Question 277.<\/b><\/p>\n

                                  Which network design BEST limits lateral movement from a compromised web front end to internal database services?<\/b><\/p>\n

                                    \n
                                  1. <\/b> Use default-deny NetworkPolicies and explicitly allow only the application communication paths that are required<\/span><\/li>\n
                                  2. <\/b> Allow unrestricted internal traffic but encrypt all connections with TLS<\/span><\/li>\n
                                  3. <\/b> Place each tier in a separate Deployment without additional network restrictions<\/span><\/li>\n
                                  4. <\/b> Use different Service names for the front end, API, and database<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1. Use default-deny NetworkPolicies and explicitly allow only the application communication paths that are required<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    NetworkPolicies can restrict east-west communication so a front-end workload can reach only the backend services it legitimately requires. A default-deny posture creates an explicit communication model rather than trusting all traffic inside the cluster. TLS protects confidentiality and endpoint identity but does not prevent an unauthorized workload from attempting to connect. Separate Deployments and Service names organize application components but do not automatically create security boundaries. Network segmentation should be layered with application-level authentication, separate credentials, workload identities, and runtime monitoring. The goal is to reduce the attacker’s options after compromising one component by ensuring that unrelated or sensitive services remain unreachable even when the attacker has control of an internal workload.<\/span><\/p>\n

                                    Question 278.<\/b><\/p>\n

                                    A sensitive workload should communicate externally only with a specific API and DNS. Which control is MOST appropriate for reducing unauthorized outbound communication?<\/b><\/p>\n

                                      \n
                                    1. <\/b> A dedicated ServiceAccount<\/span><\/li>\n
                                    2. <\/b> An egress NetworkPolicy or equivalent outbound filtering mechanism<\/span><\/li>\n
                                    3. <\/b> A read-only root filesystem<\/span><\/li>\n
                                    4. <\/b> A PodDisruptionBudget<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 2. An egress NetworkPolicy or equivalent outbound filtering mechanism<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      Egress controls directly restrict where a workload can send outbound traffic. If the workload only needs DNS and one approved external API, unrestricted Internet access creates unnecessary risk. A compromised pod could otherwise contact command-and-control infrastructure, download malicious tools, scan external systems, or exfiltrate data. A dedicated service account limits Kubernetes API authorization, while a read-only filesystem restricts local modification and a PodDisruptionBudget supports availability. These controls are useful but do not determine network destinations. Depending on the networking implementation and dynamic nature of external services, organizations may use NetworkPolicies, egress gateways, firewalls, or other filtering mechanisms. Runtime network monitoring should complement egress restrictions so unexpected connection attempts are visible and investigated.<\/span><\/p>\n

                                      Question 279.<\/b><\/p>\n

                                      A Kubernetes node is suspected of compromise after a privileged pod accessed sensitive host resources. Which response is MOST appropriate?<\/b><\/p>\n

                                        \n
                                      1. <\/b> Isolate the node, preserve relevant evidence, investigate the scope of compromise, and rebuild from a trusted state if necessary<\/span><\/li>\n
                                      2. <\/b> Delete the pod and immediately resume normal scheduling on the node<\/span><\/li>\n
                                      3. <\/b> Rotate only the pod’s service account token and assume the host is unaffected<\/span><\/li>\n
                                      4. <\/b> Restart the kubelet and clear local logs to remove suspicious activity<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1. Isolate the node, preserve relevant evidence, investigate the scope of compromise, and rebuild from a trusted state if necessary<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        Privileged workloads can interact with host resources in ways ordinary containers cannot, so suspicious host access may indicate node-level compromise. The node should be contained according to incident-response procedures, often by removing it from normal scheduling or isolating its network access while evidence is preserved. Investigators should review processes, files, credentials, runtime activity, node logs, Kubernetes audit logs, and the privileged workload’s image and behavior. Deleting the pod alone does not reverse potential host modifications. Rotating one token may be insufficient if node credentials or other secrets were exposed. Clearing logs destroys valuable evidence. Depending on findings, rebuilding the node from a known-good image may provide greater assurance than attempting to clean a compromised system manually.<\/span><\/p>\n

                                        Question 280.<\/b><\/p>\n

                                        Which approach BEST represents a mature security strategy for Kubernetes and cloud-native applications?<\/b><\/p>\n

                                          \n
                                        1. <\/b> Rely primarily on perimeter controls and strong administrator authentication<\/span><\/li>\n
                                        2. <\/b> Perform image scanning before deployment and trust approved images afterward<\/span><\/li>\n
                                        3. <\/b> Use runtime monitoring and RBAC but allow broad CI\/CD and network permissions for operational simplicity<\/span><\/li>\n
                                        4. <\/b> Continuously integrate identity controls, least privilege, workload hardening, supply chain security, network segmentation, policy enforcement, vulnerability management, monitoring, logging, and incident response**<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 4. Continuously integrate identity controls, least privilege, workload hardening, supply chain security, network segmentation, policy enforcement, vulnerability management, monitoring, logging, and incident response<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          Kubernetes security requires defense in depth across the complete software and workload lifecycle. Identity security and RBAC protect control-plane actions. Workload hardening reduces process privilege and writable attack surface. Supply chain protections establish trust in source code, dependencies, build systems, registries, signatures, and provenance. Admission policies prevent known unsafe configurations from entering production, while NetworkPolicies limit unnecessary communication and lateral movement. Continuous vulnerability management is required because new weaknesses can appear after deployment. Runtime monitoring, Kubernetes audit logs, and centralized telemetry provide detection and investigative visibility. Finally, tested incident-response procedures support containment, credential rotation, evidence preservation, eradication, and recovery. Mature security is continuous because applications, clusters, dependencies, identities, and attacker techniques all evolve over time.<\/span><\/p>\n

                                           <\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps   Question 261. A Kubernetes workload needs to read ConfigMaps in its own namespace but does not require access to Secrets or write operations. Which RBAC configuration BEST follows least privilege? Create a dedicated service account with a namespaced Role allowing only the required […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21322"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=21322"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21322\/revisions"}],"predecessor-version":[{"id":21323,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21322\/revisions\/21323"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21322"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21322"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21322"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}