{"id":21333,"date":"2026-09-24T12:06:53","date_gmt":"2026-09-24T12:06:53","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21333"},"modified":"2026-09-24T12:06:53","modified_gmt":"2026-09-24T12:06:53","slug":"linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part19-q361-380","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part19-q361-380\/","title":{"rendered":"Linux Foundation KCSA Practice Test Questions and Exam Dumps Part19 Q361-380"},"content":{"rendered":"

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

 <\/p>\n

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

A Kubernetes application requires access to one Secret in its namespace and no other API resources. Which design BEST follows least privilege?<\/b><\/p>\n

    \n
  1. <\/b> Use a dedicated service account with a Role permitting only the required read action on that Secret<\/span><\/li>\n
  2. <\/b> Give the application read access to all Secrets in the namespace<\/span><\/li>\n
  3. <\/b> Use the default service account with namespace-wide read permissions<\/span><\/li>\n
  4. <\/b> Bind the application to a ClusterRole that includes read access to ConfigMaps, Secrets, and Pods<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1. Use a dedicated service account with a Role permitting only the required read action on that Secret<\/b><\/p>\n

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

    A dedicated service account with narrowly scoped RBAC permissions limits the workload to exactly what it needs. If the application requires only one Secret, the Role can specify the necessary read verb and the particular resource rather than exposing every Secret in the namespace. Using the default service account can unintentionally share identity and permissions across unrelated workloads. A broad ClusterRole also expands the potential blast radius if the pod or its token is compromised. Least privilege should be applied to identity, verbs, resource types, namespaces, and even individual resource names where appropriate. Audit logging and periodic permission reviews help confirm that the application’s access remains aligned with its actual function.<\/span><\/p>\n

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

    A platform team discovers that a CI deployment account can modify ClusterRoleBindings, even though it only needs to update Deployments in one namespace. What is the BEST remediation?<\/b><\/p>\n

      \n
    1. <\/b> Keep the permission but monitor all ClusterRoleBinding changes<\/span><\/li>\n
    2. <\/b> Replace the CI account with the namespace default service account<\/span><\/li>\n
    3. <\/b> Remove ClusterRoleBinding permissions and grant only the deployment actions required in the target namespace<\/span><\/li>\n
    4. <\/b> Restrict the CI account’s network access while leaving RBAC unchanged<\/span><\/li>\n<\/ol>\n

      Correct Answer: 3. Remove ClusterRoleBinding permissions and grant only the deployment actions required in the target namespace<\/b><\/p>\n

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

      The ability to modify ClusterRoleBindings can provide a direct privilege-escalation path because the pipeline could bind itself or another identity to a highly privileged ClusterRole. If the CI process only updates Deployments in one namespace, its permissions should be limited to those deployment operations. Monitoring privileged changes is useful but does not remove the underlying excessive authorization. Network restrictions also do not address Kubernetes API permissions, and using the default service account may worsen identity separation. CI\/CD systems should use dedicated, narrowly scoped identities, ideally with short-lived credentials and detailed audit logging. This reduces the impact if the pipeline, its configuration, or its credentials are compromised.<\/span><\/p>\n

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

      Which Kubernetes permission is MOST sensitive because it may allow an identity to act as another user or service account?<\/b><\/p>\n

        \n
      1. <\/b> Permission to list Pods<\/span><\/li>\n
      2. <\/b> Permission to impersonate users, groups, or service accounts<\/span><\/li>\n
      3. <\/b> Permission to read Services<\/span><\/li>\n
      4. <\/b> Permission to watch Deployments<\/span><\/li>\n<\/ol>\n

        Correct Answer: 2. Permission to impersonate users, groups, or service accounts<\/b><\/p>\n

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

        Impersonation can allow one principal to submit Kubernetes API requests under another identity’s security context. If the impersonated identity has greater permissions, this can become a privilege-escalation mechanism. For that reason, impersonation rights should be limited to trusted administrators or components with a clearly documented requirement. Read-only access to Pods, Services, or Deployments can expose operational information but normally does not provide the same direct ability to assume another identity. Kubernetes audit logging is especially important for impersonation because it can preserve both the initiating identity and the impersonated context. RBAC reviews should therefore examine indirect escalation paths such as impersonation, binding creation, and workload creation permissions.<\/span><\/p>\n

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

        A company wants to prevent application teams from deploying privileged containers, using hostPID, or mounting arbitrary hostPath volumes. Which control BEST enforces this before the workload starts?<\/b><\/p>\n

          \n
        1. <\/b> Runtime behavioral monitoring<\/span><\/li>\n
        2. <\/b> An ingress NetworkPolicy<\/span><\/li>\n
        3. <\/b> ResourceQuota enforcement<\/span><\/li>\n
        4. <\/b> Admission policy enforcement<\/span><\/li>\n<\/ol>\n

          Correct Answer: 4. Admission policy enforcement<\/b><\/p>\n

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

          Admission policies evaluate workload specifications before Kubernetes accepts and schedules them. This makes admission the best preventive control for known-risk settings such as privileged mode, host namespace access, dangerous hostPath mounts, excessive Linux capabilities, or missing security context settings. Runtime monitoring remains valuable because it can detect malicious behavior after execution, but it is less effective for configurations that can be blocked before the workload runs. NetworkPolicies control network paths, and ResourceQuotas control consumption rather than privilege. Organizations should align admission policy with Pod Security Standards or equivalent internal requirements and define a controlled exception process for trusted system components that genuinely require elevated access.<\/span><\/p>\n

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

          A containerized application writes only temporary files under <\/b>\/tmp<\/b>. Which configuration BEST limits the ability of a compromised process to alter the rest of the container filesystem?<\/b><\/p>\n

            \n
          1. <\/b> Use a read-only root filesystem and mount a writable temporary volume only at <\/span>\/tmp<\/span><\/li>\n
          2. <\/b> Keep the entire root filesystem writable but run the container as non-root<\/span><\/li>\n
          3. <\/b> Mount the node’s <\/span>\/tmp<\/span> directory directly into the container<\/span><\/li>\n
          4. <\/b> Enable privileged mode and make only the application directory read-only<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. Use a read-only root filesystem and mount a writable temporary volume only at <\/b>\/tmp<\/b><\/p>\n

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

            A read-only root filesystem prevents a compromised application from modifying most binaries, libraries, and packaged configuration within the container image. If the only writable requirement is <\/span>\/tmp<\/span>, a dedicated temporary volume there gives the application the functionality it needs without making the entire filesystem mutable. Running as non-root is also beneficial but does not stop the process from altering files it owns or can access. Mounting the host’s <\/span>\/tmp<\/span> introduces unnecessary node exposure, while privileged mode substantially weakens isolation. This design applies least privilege to filesystem access and works best alongside non-root execution, capability reduction, seccomp, and disabled privilege escalation.<\/span><\/p>\n

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

            A workload requires one Linux capability to perform a legitimate operation. Which configuration BEST minimizes privilege?<\/b><\/p>\n

              \n
            1. <\/b> Keep the runtime’s default capabilities because they are already limited<\/span><\/li>\n
            2. <\/b> Run the container as root but disable interactive shells<\/span><\/li>\n
            3. <\/b> Drop unnecessary capabilities and add back only the specific capability required<\/span><\/li>\n
            4. <\/b> Enable privileged mode but apply a restrictive NetworkPolicy<\/span><\/li>\n<\/ol>\n

              Correct Answer: 3. Drop unnecessary capabilities and add back only the specific capability required<\/b><\/p>\n

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

              Linux capabilities split traditional root privileges into smaller units. If an application requires only one capability, the most secure approach is to remove the others and restore only the one with a documented functional requirement. Keeping a broad default set exposes unnecessary kernel-level powers. Running as root increases process privilege, while privileged mode weakens many isolation controls and cannot be compensated for simply by limiting network access. Capability minimization should be combined with non-root execution, <\/span>allowPrivilegeEscalation: false<\/span>, seccomp, and mandatory access control. The workload should be tested with the reduced capability set to ensure security improvements do not interfere with legitimate application behavior.<\/span><\/p>\n

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

              Which pod security control MOST directly prevents a process from gaining more privileges than its parent process?<\/b><\/p>\n

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

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

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

                allowPrivilegeEscalation: false<\/span> is specifically intended to stop a process from gaining additional privileges through mechanisms such as setuid executables or file capabilities. A read-only root filesystem protects against file modification, while disabling service account token automounting reduces Kubernetes credential exposure. Avoiding host networking preserves network namespace separation. These controls complement each other but address different security concerns. Strong workload hardening normally combines non-root execution, capability minimization, disabled privilege escalation, seccomp, mandatory access control, and limited writable paths. Using multiple layers makes it more difficult for a single application vulnerability to become a broader container or node compromise.<\/span><\/p>\n

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

                Which Linux mechanism is designed specifically to restrict which system calls a containerized process can make?<\/b><\/p>\n

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

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

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

                  seccomp filters Linux system calls and can reduce the kernel attack surface available to a containerized process. Many applications require only a subset of the available syscall interface, so unnecessary operations can be blocked. AppArmor is another valuable host-level security mechanism, but it primarily enforces mandatory access rules around files and process behavior rather than acting specifically as a syscall filter. Kubernetes RBAC governs API authorization, while NetworkPolicy governs traffic. seccomp profiles should be tested carefully because denying a syscall that an application genuinely requires may cause failure. It is strongest when used alongside non-root execution, reduced capabilities, AppArmor or SELinux, and runtime monitoring.<\/span><\/p>\n

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

                  Which control BEST restricts a container process from accessing sensitive files or devices even when normal Unix permissions might allow the operation?<\/b><\/p>\n

                    \n
                  1. <\/b> AppArmor or SELinux<\/span><\/li>\n
                  2. <\/b> Kubernetes ServiceAccount RBAC<\/span><\/li>\n
                  3. <\/b> ResourceQuota<\/span><\/li>\n
                  4. <\/b> Horizontal Pod Autoscaler<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1. AppArmor or SELinux<\/b><\/p>\n

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

                    AppArmor and SELinux provide mandatory access control at the operating-system layer. They can restrict which files, devices, paths, and resources a process may access even if ordinary discretionary permissions permit the action. This creates an additional containment layer for workloads that become compromised. ServiceAccount RBAC applies to Kubernetes API operations rather than local process access to filesystem resources. ResourceQuotas and autoscaling address resource usage and availability. Mandatory access control works best when combined with seccomp, capability reduction, non-root execution, and read-only filesystem settings. Policies should be carefully tested because overly restrictive rules can break legitimate workloads, while overly permissive policies may provide little meaningful protection.<\/span><\/p>\n

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

                    A production image includes compilers, package managers, shells, and debugging tools that are required only during the build. Which approach BEST reduces runtime attack surface?<\/b><\/p>\n

                      \n
                    1. <\/b> Keep the full image but restrict registry access<\/span><\/li>\n
                    2. <\/b> Use a multi-stage build and copy only the necessary runtime artifacts into the final image<\/span><\/li>\n
                    3. <\/b> Keep the tools but block outbound Internet access<\/span><\/li>\n
                    4. <\/b> Move the tools to a directory outside the application PATH<\/span><\/li>\n<\/ol>\n

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

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

                      Multi-stage builds allow build-time dependencies to remain in earlier stages while the final production image includes only the application and required runtime components. This reduces the number of potentially vulnerable packages and limits the utilities available to an attacker after compromise. Registry restrictions protect artifact distribution but do not reduce what is inside the image. Egress controls can contain network behavior but still leave unnecessary software present. Moving utilities outside PATH also does not prevent an attacker from invoking them directly. Minimal images should still be scanned, signed, patched, and tied to SBOM and provenance information. Removing unnecessary components is stronger than merely hiding or restricting them.<\/span><\/p>\n

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

                      Which artifact is MOST useful for quickly identifying whether a deployed container image contains a newly vulnerable library version?<\/b><\/p>\n

                        \n
                      1. <\/b> An SBOM tied to the image’s exact digest<\/span><\/li>\n
                      2. <\/b> Kubernetes audit logs<\/span><\/li>\n
                      3. <\/b> A NetworkPolicy manifest<\/span><\/li>\n
                      4. <\/b> A PodDisruptionBudget<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 1. An SBOM tied to the image’s exact digest<\/b><\/p>\n

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

                        A Software Bill of Materials provides a structured inventory of the packages, libraries, and versions contained in an artifact. Associating the SBOM with an immutable image digest ensures the inventory corresponds to the exact image being assessed. When a vulnerability is disclosed, security teams can search SBOM data to identify potentially affected artifacts quickly. The SBOM does not automatically determine exploitability, so exposure analysis, vulnerability scanning, and remediation are still required. Audit logs describe API activity, NetworkPolicies describe traffic rules, and PodDisruptionBudgets support availability. None of those provide software composition information. Accurate SBOMs are therefore an important part of software supply chain visibility and vulnerability response.<\/span><\/p>\n

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

                        A Kubernetes Deployment references a mutable image tag called <\/b>approved<\/b>. Which practice BEST ensures the exact reviewed image continues to be used?<\/b><\/p>\n

                          \n
                        1. <\/b> Increase registry audit-log retention<\/span><\/li>\n
                        2. <\/b> Reference the approved image by immutable digest<\/span><\/li>\n
                        3. <\/b> Configure <\/span>imagePullPolicy: Always<\/span><\/li>\n
                        4. <\/b> Limit Deployment restarts to cluster administrators<\/span><\/li>\n<\/ol>\n

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

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

                          A digest identifies the exact contents of a container image, whereas a mutable tag can later be reassigned to different content. If the Deployment references only <\/span>approved<\/span>, a restart could pull a new artifact without any change to the workload manifest. Pinning the digest removes this ambiguity and improves reproducibility, rollback reliability, and forensic investigation. Audit logs help reveal tag changes but do not prevent them. <\/span>imagePullPolicy: Always<\/span> can actually make mutable tag replacement more dangerous because each pull retrieves the tag’s current content. Restricting restarts also does not solve artifact identity. Digest pinning should be combined with registry access controls, signatures, provenance, scanning, and admission verification.<\/span><\/p>\n

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

                          A company wants the cluster to reject images that were not produced by its trusted build pipeline. Which control BEST satisfies this requirement?<\/b><\/p>\n

                            \n
                          1. <\/b> Admission-time verification of trusted signatures or build provenance<\/span><\/li>\n
                          2. <\/b> A namespace ResourceQuota<\/span><\/li>\n
                          3. <\/b> Runtime CPU monitoring<\/span><\/li>\n
                          4. <\/b> A default-deny ingress NetworkPolicy<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 1. Admission-time verification of trusted signatures or build provenance<\/b><\/p>\n

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

                            Signatures and build provenance can provide evidence that an image was generated or approved through an authorized software supply chain. Verifying those signals during admission allows Kubernetes to block untrusted artifacts before they execute. ResourceQuotas regulate resource consumption, CPU monitoring observes runtime behavior, and ingress policy controls communication. None of these establishes artifact origin. Trust mechanisms must themselves be secured because compromised signing keys or build infrastructure can make malicious artifacts appear legitimate. Strong supply chain assurance combines admission verification with protected source repositories, secure CI\/CD systems, immutable image references, trusted registries, vulnerability scanning, SBOMs, and narrowly scoped release credentials.<\/span><\/p>\n

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

                            A deployment pipeline needs to update Deployments and Services in one namespace but should not manage RBAC. Which permission model is MOST secure?<\/b><\/p>\n

                              \n
                            1. <\/b> Grant namespace-admin for operational flexibility<\/span><\/li>\n
                            2. <\/b> Grant only the exact Deployment and Service permissions required in that namespace<\/span><\/li>\n
                            3. <\/b> Permit RoleBinding creation but deny ClusterRoleBinding creation<\/span><\/li>\n
                            4. <\/b> Grant cluster-wide write access but use a short-lived credential<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 2. Grant only the exact Deployment and Service permissions required in that namespace<\/b><\/p>\n

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

                              A CI\/CD identity should receive only the verbs, resources, and scope necessary for its deployment function. If it updates Deployments and Services in one namespace, it should not have unrelated access to Secrets, Roles, RoleBindings, or other namespaces. Namespace-admin is broader than needed, while even RoleBinding creation can become a privilege-escalation path if powerful roles can be referenced. A short-lived token reduces exposure duration but does not make excessive cluster-wide permissions safe. Strong pipeline security also includes separate identities, protected configuration, artifact verification, and audit logging. Least privilege limits how much damage an attacker can cause if the pipeline or its credentials are compromised.<\/span><\/p>\n

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

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

                                \n
                              1. <\/b> Whether the namespace ResourceQuota changed<\/span><\/li>\n
                              2. <\/b> Possible service account compromise, RBAC modification, or malicious workload behavior<\/span><\/li>\n
                              3. <\/b> Whether a liveness probe failed<\/span><\/li>\n
                              4. <\/b> Whether DNS records were recently updated<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 2. Possible service account compromise, RBAC modification, or malicious workload behavior<\/b><\/p>\n

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

                                A significant change in an identity’s behavior is an important security signal. A service account that historically reads ConfigMaps but suddenly accesses Secrets or creates Pods may have been compromised or granted additional permissions. Security teams should review Kubernetes audit logs, recent Role and RoleBinding changes, workload processes, network activity, image identity, and deployment history. ResourceQuotas, liveness probes, and DNS changes do not automatically grant API privileges. Ideally, least-privilege RBAC would prevent the account from performing those actions at all. Behavioral monitoring is valuable because attackers often abuse valid credentials and permitted API requests rather than triggering obvious authentication failures.<\/span><\/p>\n

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

                                A fixed-function production container unexpectedly launches a shell, downloads an executable, and starts it. Which response is MOST appropriate?<\/b><\/p>\n

                                  \n
                                1. <\/b> Increase the container’s CPU and memory limits for observation<\/span><\/li>\n
                                2. <\/b> Add the download destination to the application’s egress allowlist<\/span><\/li>\n
                                3. <\/b> Restart the pod repeatedly until the activity stops<\/span><\/li>\n
                                4. <\/b> Treat the event as a possible compromise, contain the workload, and preserve evidence<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 4. Treat the event as a possible compromise, contain the workload, and preserve evidence<\/b><\/p>\n

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

                                  Unexpected shell execution followed by downloading and running unfamiliar code is a strong indicator of exploitation or unauthorized activity. The incident-response process should prioritize containment while preserving evidence. Responders may isolate the workload, restrict network communication, preserve audit and application logs, record process state, identify image digests, and determine whether credentials were exposed. Restarting repeatedly can destroy evidence and does not correct the underlying vulnerability. Increasing resources or allowlisting the external host would make suspicious activity easier to continue. After containment, the organization should determine root cause, rotate affected credentials, rebuild from trusted artifacts, and validate remediation before restoring normal service.<\/span><\/p>\n

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

                                  Which network design BEST limits lateral movement if a front-end pod is compromised?<\/b><\/p>\n

                                    \n
                                  1. <\/b> Use default-deny NetworkPolicies and explicitly allow only the communication paths required by the application<\/span><\/li>\n
                                  2. <\/b> Permit all internal traffic but use TLS for every connection<\/span><\/li>\n
                                  3. <\/b> Put application tiers in separate Deployments without policy enforcement<\/span><\/li>\n
                                  4. <\/b> Use unique Service names for each tier<\/span><\/li>\n<\/ol>\n

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

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

                                    A default-deny network posture restricts communication unless the application architecture explicitly requires it. A front-end workload may need access to an API backend but should not automatically reach databases, monitoring systems, or unrelated namespaces. TLS protects confidentiality and identity for allowed connections, but it does not prevent unauthorized workloads from attempting to connect when network reachability remains broad. Separate Deployments and Service names provide organization rather than isolation. Network segmentation should be combined with service authentication, separate credentials, workload identity, and runtime monitoring. This defense-in-depth design assumes any one workload can become compromised and therefore limits what it can reach afterward.<\/span><\/p>\n

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

                                    A sensitive application should contact only DNS and two approved external services. Which control BEST limits unnecessary outbound network access?<\/b><\/p>\n

                                      \n
                                    1. <\/b> A namespace-scoped Role<\/span><\/li>\n
                                    2. <\/b> An egress NetworkPolicy or equivalent outbound filtering control<\/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 control<\/b><\/p>\n

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

                                      Egress filtering directly restricts the destinations a workload can contact. If the application requires only DNS and two approved external services, unrestricted Internet connectivity creates unnecessary risk of command-and-control communication, malicious downloads, data exfiltration, or external scanning after compromise. Kubernetes NetworkPolicy can provide this control when supported by the networking implementation, while dynamic external services may require gateways or firewall-based controls. RBAC controls Kubernetes API authorization, a read-only filesystem limits local modification, and a PodDisruptionBudget supports availability. These controls do not constrain outbound destinations. Runtime network monitoring should complement egress restrictions so unusual or blocked connection attempts are visible and investigated.<\/span><\/p>\n

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

                                      Which logging design BEST supports forensic investigation when compromised pods may be deleted or replaced before responders can inspect them?<\/b><\/p>\n

                                        \n
                                      1. <\/b> Forward Kubernetes audit, application, node, and runtime security telemetry to protected centralized storage<\/span><\/li>\n
                                      2. <\/b> Store all logs inside the pod’s writable filesystem<\/span><\/li>\n
                                      3. <\/b> Retain only Kubernetes Events<\/span><\/li>\n
                                      4. <\/b> Disable long-term log retention to reduce exposure of sensitive information<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1. Forward Kubernetes audit, application, node, and runtime security telemetry to protected centralized storage<\/b><\/p>\n

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

                                        Pods are ephemeral and may disappear because of restarts, scaling, rescheduling, containment actions, or attacker behavior. Logs stored only in the workload can therefore vanish before an investigation begins. Centralized logging preserves evidence outside the pod lifecycle and enables correlation across multiple layers. Kubernetes audit logs reveal API actions, runtime telemetry captures suspicious processes and network behavior, application logs provide service context, and node logs can reveal host-level events. Kubernetes Events are useful but typically insufficient for detailed forensics. Centralized storage should have strong access controls, encryption, integrity protections, retention policies, and monitoring. Incident readiness depends on collecting important telemetry before a compromise occurs.<\/span><\/p>\n

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

                                        Which approach BEST represents a mature Kubernetes security program across software development, deployment, and runtime?<\/b><\/p>\n

                                          \n
                                        1. <\/b> Focus on image scanning and trust approved artifacts afterward<\/span><\/li>\n
                                        2. <\/b> Secure the cluster perimeter and allow broad internal workload communication<\/span><\/li>\n
                                        3. <\/b> Use RBAC and monitoring while giving CI\/CD systems broad permissions for convenience<\/span><\/li>\n
                                        4. <\/b> Continuously combine identity security, least privilege, workload hardening, software supply chain controls, network segmentation, policy enforcement, vulnerability management, monitoring, logging, and incident response<\/span><\/li>\n<\/ol>\n

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

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

                                          A mature Kubernetes security program uses defense in depth throughout the entire cloud-native lifecycle. Identity controls and RBAC protect API access. Workload hardening reduces process privilege, writable attack surface, and unnecessary kernel access. Supply chain controls protect source code, dependencies, build infrastructure, registries, signatures, provenance, and artifact promotion. Admission policies prevent known-insecure configurations from reaching runtime, while NetworkPolicies reduce lateral movement and unnecessary egress. Continuous vulnerability management addresses weaknesses discovered after deployment. Runtime monitoring and centralized logging provide detection and investigation capabilities when preventive measures fail. Finally, tested incident-response procedures help teams contain compromised workloads, rotate credentials, preserve evidence, eradicate root causes, and recover safely.<\/span><\/p>\n

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

                                          View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps   Question 361. A Kubernetes application requires access to one Secret in its namespace and no other API resources. Which design BEST follows least privilege? Use a dedicated service account with a Role permitting only the required read action on that Secret Give the […]<\/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\/21333"}],"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=21333"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21333\/revisions"}],"predecessor-version":[{"id":21334,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21333\/revisions\/21334"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21333"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21333"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21333"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}