{"id":21308,"date":"2026-09-24T12:03:01","date_gmt":"2026-09-24T12:03:01","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21308"},"modified":"2026-09-24T12:03:01","modified_gmt":"2026-09-24T12:03:01","slug":"linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part7-q121-140","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part7-q121-140\/","title":{"rendered":"Linux Foundation KCSA Practice Test Questions and Exam Dumps Part7 Q121-140"},"content":{"rendered":"

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

 <\/p>\n

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

An organization wants to reduce the risk that compromised credentials can be used to access multiple Kubernetes clusters. Which identity design BEST supports this goal?<\/b><\/p>\n

    \n
  1. <\/b> Use centralized identity with separate, least-privilege authorization for each cluster<\/span><\/li>\n
  2. <\/b> Share one cluster-admin credential across all environments<\/span><\/li>\n
  3. <\/b> Store kubeconfig files in a public repository<\/span><\/li>\n
  4. <\/b> Disable authentication on development clusters<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1. Use centralized identity with separate, least-privilege authorization for each cluster<\/b><\/p>\n

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

    Centralized identity can simplify authentication while still allowing each Kubernetes cluster to enforce its own least-privilege authorization. This helps organizations avoid long-lived shared administrator credentials and improves accountability because actions can be tied to individual identities. Access should be scoped according to job responsibilities and environment sensitivity. Production permissions should usually be more restrictive than development permissions, and access should be reviewed regularly. Strong authentication, short-lived credentials where practical, RBAC, audit logging, and prompt revocation all strengthen the model. Sharing one administrative credential across many clusters creates a large blast radius because compromise of that single credential may expose every environment it can access.<\/span><\/p>\n

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

    A user needs temporary administrative access to troubleshoot a production Kubernetes issue. Which security approach is MOST appropriate?<\/b><\/p>\n

      \n
    1. <\/b> Give the user permanent cluster-admin access<\/span><\/li>\n
    2. <\/b> Grant time-limited, auditable privileged access only for the required task<\/span><\/li>\n
    3. <\/b> Share another administrator\u2019s kubeconfig<\/span><\/li>\n
    4. <\/b> Disable audit logs during troubleshooting<\/span><\/li>\n<\/ol>\n

      Correct Answer: 2. Grant time-limited, auditable privileged access only for the required task<\/b><\/p>\n

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

      Temporary privileged access reduces the risk associated with standing administrative permissions. A mature access model grants elevated rights only when required, for a limited duration, and with appropriate approval and auditability. This supports least privilege while still allowing administrators to respond to operational incidents. The access should be revoked automatically or promptly after the task ends. Audit logs should remain enabled so sensitive actions can be reviewed later. Permanent cluster-admin access expands the blast radius of account compromise, while shared kubeconfig files weaken accountability and make revocation difficult. Privileged access should be treated as an exception that is monitored closely rather than a normal default state.<\/span><\/p>\n

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

      Which practice BEST improves accountability for sensitive Kubernetes administrative actions?<\/b><\/p>\n

        \n
      1. <\/b> Use individual user identities instead of shared administrator accounts<\/span><\/li>\n
      2. <\/b> Disable authentication<\/span><\/li>\n
      3. <\/b> Use one service account for all administrators<\/span><\/li>\n
      4. <\/b> Delete audit logs daily<\/span><\/li>\n<\/ol>\n

        Correct Answer: 1. Use individual user identities instead of shared administrator accounts<\/b><\/p>\n

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

        Individual identities allow actions to be attributed to specific people, which is essential for accountability, auditing, and incident investigation. Shared administrator credentials make it difficult to determine who performed a sensitive action and complicate access removal when staff responsibilities change. Individual identities should be combined with strong authentication, role-based permissions, temporary elevation where appropriate, and centralized audit logging. Sensitive administrative changes such as modifying RBAC, deleting namespaces, or creating privileged workloads should be monitored carefully. Accountability is not only useful after an incident; it also discourages unsafe behavior and supports compliance requirements. Deleting logs or sharing service account credentials would weaken rather than strengthen operational security.<\/span><\/p>\n

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

        A security engineer wants to restrict administrators from accessing Kubernetes Secrets unless their role specifically requires it. Which control should be used?<\/b><\/p>\n

          \n
        1. <\/b> NetworkPolicy<\/span><\/li>\n
        2. <\/b> Pod affinity<\/span><\/li>\n
        3. <\/b> RBAC permissions that omit Secret access for users who do not need it<\/span><\/li>\n
        4. <\/b> Horizontal Pod Autoscaling<\/span><\/li>\n<\/ol>\n

          Correct Answer: 3. RBAC permissions that omit Secret access for users who do not need it<\/b><\/p>\n

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

          Kubernetes RBAC can restrict access by resource type and action. Administrators who do not need to read Secrets should not receive verbs such as <\/span>get<\/span>, <\/span>list<\/span>, or <\/span>watch<\/span> on Secret resources. Secret access is highly sensitive because it may expose database credentials, API keys, tokens, certificates, or other authentication material. Permissions should also be reviewed for indirect access paths, such as the ability to create pods that mount Secrets. Least privilege means considering what a user can achieve through combinations of permissions rather than looking only at one resource. NetworkPolicy controls network traffic, while pod affinity and autoscaling relate to scheduling and workload capacity rather than API authorization.<\/span><\/p>\n

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

          Which security principle is MOST important when assigning RBAC permissions to a CI\/CD deployment service account?<\/b><\/p>\n

            \n
          1. <\/b> Least privilege<\/span><\/li>\n
          2. <\/b> Maximum replication<\/span><\/li>\n
          3. <\/b> High availability<\/span><\/li>\n
          4. <\/b> Service discovery<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. Least privilege<\/b><\/p>\n

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

            A CI\/CD deployment identity should receive only the permissions needed to deploy the intended resources into the intended environments. It should not automatically receive cluster-admin privileges or access to unrelated namespaces. Pipeline identities are attractive targets because compromise can allow an attacker to deploy malicious software through a trusted automation path. Organizations should therefore restrict RBAC permissions, protect pipeline credentials, separate build and deployment authority where practical, use short-lived credentials, and monitor deployment activity. Least privilege limits the damage an attacker can cause if the pipeline or its credentials are compromised. Scaling and availability concepts do not address authorization risk.<\/span><\/p>\n

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

            A company wants to prevent users from deploying containers with unrestricted host access. Which policy should be enforced?<\/b><\/p>\n

              \n
            1. <\/b> Allow privileged mode for all workloads<\/span><\/li>\n
            2. <\/b> Deny privileged containers and unnecessary host namespace access through admission policies<\/span><\/li>\n
            3. <\/b> Disable image scanning<\/span><\/li>\n
            4. <\/b> Grant all users cluster-admin<\/span><\/li>\n<\/ol>\n

              Correct Answer: 2. Deny privileged containers and unnecessary host namespace access through admission policies<\/b><\/p>\n

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

              Privileged containers and host namespace access can significantly weaken isolation between workloads and Kubernetes nodes. Admission policies can reject configurations that request privileged mode, hostPID, hostIPC, hostNetwork, or dangerous hostPath mounts unless an approved exception exists. Preventing insecure configurations before they run is stronger than relying only on runtime detection. System components with legitimate host access requirements should be narrowly scoped and reviewed carefully. Additional protections may include dedicated nodes, restricted capabilities, seccomp, mandatory access control, and enhanced monitoring. Disabling scanning or granting broad administrative access would increase the attack surface rather than reduce it.<\/span><\/p>\n

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

              Which workload security setting MOST directly prevents a container from running as the root user when the image is compatible with non-root execution?<\/b><\/p>\n

                \n
              1. <\/b> runAsNonRoot: true<\/span><\/li>\n
              2. <\/b> hostPID: true<\/span><\/li>\n
              3. <\/b> hostNetwork: true<\/span><\/li>\n
              4. <\/b> privileged: true<\/span><\/li>\n<\/ol>\n

                Correct Answer: 1. <\/b>runAsNonRoot: true<\/b><\/p>\n

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

                The <\/span>runAsNonRoot<\/span> setting tells Kubernetes that the container should not run as UID 0. This reduces the privileges available to an attacker who gains control of the application process. The container image must be designed to support non-root execution, including suitable file ownership and permissions. Non-root execution should be combined with other controls such as dropping unnecessary Linux capabilities, disabling privilege escalation, applying seccomp profiles, and using a read-only root filesystem where practical. Running as non-root does not eliminate all container security risks, but it meaningfully reduces the potential impact of compromise. The other options listed increase access to host-level resources and therefore weaken isolation.<\/span><\/p>\n

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

                A container must write temporary files but does not need to modify the rest of its filesystem. Which design is MOST secure?<\/b><\/p>\n

                  \n
                1. <\/b> Make the entire root filesystem writable<\/span><\/li>\n
                2. <\/b> Mount the host root filesystem<\/span><\/li>\n
                3. <\/b> Use a read-only root filesystem with a dedicated writable temporary volume<\/span><\/li>\n
                4. <\/b> Run the container in privileged mode<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 3. Use a read-only root filesystem with a dedicated writable temporary volume<\/b><\/p>\n

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

                  A read-only root filesystem limits what an attacker or compromised process can modify inside the container. If the application requires writable storage for temporary data, that requirement can be satisfied with a narrowly scoped writable volume mounted only where needed. This design reduces the writable attack surface while preserving application functionality. The temporary storage should also be managed according to data sensitivity and lifecycle requirements. Running the entire container filesystem as writable provides more opportunities for tampering and persistence. Host filesystem mounts and privileged mode further weaken isolation. This approach illustrates least privilege applied to filesystem access: provide exactly the writable locations the application needs and nothing more.<\/span><\/p>\n

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

                  Why should production containers generally avoid including SSH servers?<\/b><\/p>\n

                    \n
                  1. <\/b> They add an unnecessary network service and attack surface in most container workflows<\/span><\/li>\n
                  2. <\/b> SSH prevents pods from starting<\/span><\/li>\n
                  3. <\/b> SSH disables Kubernetes RBAC<\/span><\/li>\n
                  4. <\/b> SSH automatically grants cluster-admin access<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1. They add an unnecessary network service and attack surface in most container workflows<\/b><\/p>\n

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

                    Containers are generally managed through orchestration and controlled debugging mechanisms rather than by running an SSH daemon inside each workload. Including SSH adds another network service, authentication mechanism, package set, and potential vulnerability surface that usually provides little operational value. Secure container images should include only the services and tools required by the application. Debugging and troubleshooting should use controlled platform mechanisms with appropriate auditing and permissions. Removing SSH does not eliminate all risk, but it follows the broader hardening principle of minimizing unnecessary software and exposed interfaces. Any service that listens for connections creates an additional attack path that must be maintained, patched, monitored, and secured.<\/span><\/p>\n

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

                    A security team wants to stop compromised application pods from downloading arbitrary tools from the Internet. Which control can MOST directly help?<\/b><\/p>\n

                      \n
                    1. <\/b> Additional ReplicaSets<\/span><\/li>\n
                    2. <\/b> Restrictive egress NetworkPolicies or equivalent network controls<\/span><\/li>\n
                    3. <\/b> More ConfigMaps<\/span><\/li>\n
                    4. <\/b> Larger nodes<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2. Restrictive egress NetworkPolicies or equivalent network controls<\/b><\/p>\n

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

                      Egress controls can restrict workloads to the external and internal destinations they actually require. If an application only needs to reach a specific database and approved API, allowing unrestricted Internet access creates unnecessary risk. A compromised pod could otherwise download malicious tools, communicate with command-and-control infrastructure, or exfiltrate data. NetworkPolicy support depends on the networking implementation, and additional controls may be needed for advanced egress filtering. DNS access and dynamic endpoints should also be considered carefully. Network restrictions work best alongside minimal images, runtime monitoring, workload identity, and application-level controls. Replica counts, ConfigMaps, and node size do not prevent malicious outbound network communication.<\/span><\/p>\n

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

                      Which approach BEST protects sensitive traffic between microservices from passive network interception?<\/b><\/p>\n

                        \n
                      1. <\/b> Encrypt service-to-service communication using TLS where appropriate<\/span><\/li>\n
                      2. <\/b> Increase replica counts<\/span><\/li>\n
                      3. <\/b> Add more namespaces<\/span><\/li>\n
                      4. <\/b> Disable authentication<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 1. Encrypt service-to-service communication using TLS where appropriate<\/b><\/p>\n

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

                        TLS protects the confidentiality and integrity of data in transit between communicating services. It can also provide server authentication, and mutual TLS can authenticate both endpoints where the architecture requires it. Encryption is particularly important when traffic carries credentials, personal information, financial data, or other sensitive content. TLS should be implemented with sound certificate issuance, rotation, trust, and revocation practices. Encryption does not replace authorization or network segmentation because an authenticated and encrypted connection can still be inappropriate. Strong service-to-service security combines identity, access control, encryption, NetworkPolicies, application authorization, and monitoring. Scaling or namespace separation alone does not protect packet contents from interception.<\/span><\/p>\n

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

                        Which security risk can occur if a container image is pulled from an untrusted public registry without verification?<\/b><\/p>\n

                          \n
                        1. <\/b> The image may contain malicious or tampered software<\/span><\/li>\n
                        2. <\/b> Kubernetes cannot create Services<\/span><\/li>\n
                        3. <\/b> Pods automatically lose networking<\/span><\/li>\n
                        4. <\/b> Persistent volumes are deleted<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 1. The image may contain malicious or tampered software<\/b><\/p>\n

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

                          Untrusted registries can host images containing malicious code, backdoors, vulnerable dependencies, or misleading tags. An attacker may intentionally publish an image with a name similar to a legitimate project or compromise an existing repository. Organizations should use trusted registries, restrict image sources, verify signatures or provenance, scan images for vulnerabilities, and prefer immutable references. CI\/CD pipelines should control how production images are built and promoted. Image trust is a supply chain issue: even a securely configured Kubernetes cluster can be compromised if it executes malicious software supplied through an untrusted artifact source. Registry security therefore belongs alongside workload and cluster security in a defense-in-depth model.<\/span><\/p>\n

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

                          Which artifact can help a security team map a newly disclosed vulnerability to specific container images?<\/b><\/p>\n

                            \n
                          1. <\/b> Software Bill of Materials<\/span><\/li>\n
                          2. <\/b> Service selector<\/span><\/li>\n
                          3. <\/b> NetworkPolicy<\/span><\/li>\n
                          4. <\/b> Namespace label<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 1. Software Bill of Materials<\/b><\/p>\n

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

                            An SBOM records the software components and dependencies associated with an artifact. When a vulnerability is announced in a particular library, security teams can query SBOM data to identify which applications or images contain that component. This can dramatically improve incident and vulnerability response compared with manually inspecting every image. SBOMs are most useful when they are complete, trustworthy, and associated with exact image versions or digests. They do not indicate automatically whether a vulnerability is exploitable in a specific application, so risk assessment and testing remain necessary. SBOM information complements vulnerability scanners, artifact provenance, dependency management, and secure build pipelines.<\/span><\/p>\n

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

                            Which practice BEST protects a container registry from unauthorized modification of production images?<\/b><\/p>\n

                              \n
                            1. <\/b> Allow anonymous push access<\/span><\/li>\n
                            2. <\/b> Require authenticated access and restrict push permissions to authorized identities<\/span><\/li>\n
                            3. <\/b> Share registry administrator credentials with all developers<\/span><\/li>\n
                            4. <\/b> Disable audit logging<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 2. Require authenticated access and restrict push permissions to authorized identities<\/b><\/p>\n

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

                              Production registries should tightly control who can publish, overwrite, delete, or administer artifacts. Authentication establishes identity, while authorization limits the operations each user or automation identity may perform. Developers may require pull access but not necessarily direct push authority to production repositories. CI\/CD pipelines can publish approved artifacts through dedicated credentials with limited scope. Registries should also support immutable tags or protected repositories where appropriate, scanning, image signing, audit logging, and secure retention policies. Anonymous push access would permit arbitrary artifact replacement, while shared administrator credentials make accountability and revocation difficult. Registry security is critical because trusted deployment systems may automatically execute artifacts stored there.<\/span><\/p>\n

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

                              A build system produces a signed image, but the signing key is stored on a publicly accessible server. What is the primary security concern?<\/b><\/p>\n

                                \n
                              1. <\/b> An attacker could sign malicious images that appear trusted<\/span><\/li>\n
                              2. <\/b> The image will run more slowly<\/span><\/li>\n
                              3. <\/b> The registry will lose DNS access<\/span><\/li>\n
                              4. <\/b> Kubernetes will disable RBAC<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 1. An attacker could sign malicious images that appear trusted<\/b><\/p>\n

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

                                Digital signatures are meaningful only if the signing identity and private keys remain trustworthy. If an attacker steals a signing key, they may be able to produce malicious artifacts that pass signature verification and therefore appear legitimate to admission policies or operators. Signing keys should be protected with strong access controls, secure key-management systems, hardware-backed protection where appropriate, audit logging, rotation procedures, and limited use. Organizations should also have a plan to revoke or distrust compromised keys. Supply chain security depends on protecting the systems and credentials that establish artifact trust. Merely signing images is insufficient if the signing process itself can be compromised easily.<\/span><\/p>\n

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

                                Which runtime security event should be considered suspicious for a container that normally only serves HTTP traffic?<\/b><\/p>\n

                                  \n
                                1. <\/b> A configured health probe request<\/span><\/li>\n
                                2. <\/b> An unexpected shell spawning a network scanner process<\/span><\/li>\n
                                3. <\/b> A normal application log message<\/span><\/li>\n
                                4. <\/b> A scheduled deployment rollout<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 2. An unexpected shell spawning a network scanner process<\/b><\/p>\n

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

                                  A production web container that normally serves HTTP traffic should not typically launch an interactive shell or network scanning utility. Such behavior can indicate exploitation, unauthorized debugging, lateral movement attempts, or malware execution. Runtime security tools can detect unexpected processes, command execution, file modifications, privilege changes, and network activity. Security teams should investigate the process ancestry, image digest, network destinations, Kubernetes audit activity, and recent deployment history. The event should be interpreted in context because legitimate maintenance can occasionally look unusual, but unexplained shell and scanning behavior is a strong anomaly. Health probes and planned rollouts, by contrast, are expected operational events when configured correctly.<\/span><\/p>\n

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

                                  A Kubernetes node begins making unexpected outbound connections after a privileged pod was deployed. Which incident-response step is MOST appropriate?<\/b><\/p>\n

                                    \n
                                  1. <\/b> Investigate and contain the affected node and workload while preserving evidence<\/span><\/li>\n
                                  2. <\/b> Grant the pod additional permissions<\/span><\/li>\n
                                  3. <\/b> Delete all logs immediately<\/span><\/li>\n
                                  4. <\/b> Increase the pod replica count<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1. Investigate and contain the affected node and workload while preserving evidence<\/b><\/p>\n

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

                                    Unexpected node-level network activity after deployment of a privileged pod may indicate that the workload has affected the host. Incident responders should contain the suspected workload and node according to established procedures, preserve relevant logs and forensic evidence, and investigate the pod image, processes, network connections, credentials, and Kubernetes audit trail. Depending on the environment, containment may involve isolating or cordoning the node, restricting traffic, and removing it from production service. Deleting logs destroys evidence, while scaling the workload could expand the compromise. Privileged containers are particularly sensitive because they can access host-level capabilities that ordinary containers cannot, making careful investigation and remediation essential.<\/span><\/p>\n

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

                                    Why should Kubernetes audit logs be forwarded to a separate protected logging platform?<\/b><\/p>\n

                                      \n
                                    1. <\/b> To reduce the likelihood that an attacker controlling cluster resources can erase important evidence<\/span><\/li>\n
                                    2. <\/b> To disable RBAC<\/span><\/li>\n
                                    3. <\/b> To increase pod scheduling speed<\/span><\/li>\n
                                    4. <\/b> To automatically patch vulnerabilities<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 1. To reduce the likelihood that an attacker controlling cluster resources can erase important evidence<\/b><\/p>\n

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

                                      Audit logs are valuable during security investigations because they can record API activity such as resource creation, deletion, Secret access, and RBAC changes. If those logs remain only on systems controlled by an attacker, they may be modified or deleted. Forwarding them to a separately secured logging platform improves evidence preservation and allows centralized correlation with identity, network, application, and runtime security events. The logging platform should have its own access controls, retention policies, monitoring, and integrity safeguards. Centralized logs do not automatically prevent attacks or patch systems, but they provide essential visibility for detection, compliance, troubleshooting, and incident reconstruction.<\/span><\/p>\n

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

                                      Which strategy BEST limits the damage if an application Secret is stolen from one namespace?<\/b><\/p>\n

                                        \n
                                      1. <\/b> Use separate credentials for unrelated applications and limit what each credential can access<\/span><\/li>\n
                                      2. <\/b> Reuse the same database password in every namespace<\/span><\/li>\n
                                      3. <\/b> Store all credentials in one shared Secret<\/span><\/li>\n
                                      4. <\/b> Grant the stolen credential administrator access<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1. Use separate credentials for unrelated applications and limit what each credential can access<\/b><\/p>\n

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

                                        Credential separation reduces the blast radius of compromise. If every application uses the same database password or API token, theft from one namespace can expose many unrelated systems. Separate credentials allow access to be revoked or rotated for one workload without disrupting others and support more precise authorization. Credentials should also be scoped to the minimum resources they require, stored securely, rotated regularly, and monitored for suspicious use. Kubernetes RBAC should restrict which users and service accounts can retrieve the Secret. NetworkPolicies can provide additional containment by limiting where a compromised workload can connect. Security architecture should assume that individual credentials may eventually be exposed and design access boundaries accordingly.<\/span><\/p>\n

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

                                        Which approach BEST represents defense in depth for securing Kubernetes workloads and the software supply chain?<\/b><\/p>\n

                                          \n
                                        1. <\/b> Depend only on container image scanning<\/span><\/li>\n
                                        2. <\/b> Use only perimeter firewalls<\/span><\/li>\n
                                        3. <\/b> Combine protected source control, secure builds, trusted artifacts, admission policies, least privilege, network segmentation, runtime monitoring, logging, and incident response<\/span><\/li>\n
                                        4. <\/b> Grant broad administrator access to simplify operations<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 3. Combine protected source control, secure builds, trusted artifacts, admission policies, least privilege, network segmentation, runtime monitoring, logging, and incident response<\/b><\/p>\n

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

                                          Defense in depth assumes that any single security layer may eventually fail. Source repositories need strong authentication and controlled changes. Build systems and CI\/CD credentials must be protected. Container images should come from trusted registries, be scanned, signed, and traceable through provenance and SBOMs. Admission policies can block insecure workloads before execution. At runtime, hardened containers, least-privilege identities, NetworkPolicies, encryption, and monitoring reduce the impact of compromise. Audit and centralized logs provide investigation data, while tested incident-response procedures support containment and recovery. This layered model is significantly stronger than relying only on perimeter controls or image scanning because Kubernetes threats can originate from identities, workloads, dependencies, build systems, or runtime behavior.<\/span><\/p>\n

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

                                          View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps   Question 121. An organization wants to reduce the risk that compromised credentials can be used to access multiple Kubernetes clusters. Which identity design BEST supports this goal? Use centralized identity with separate, least-privilege authorization for each cluster Share one cluster-admin credential across all […]<\/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\/21308"}],"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=21308"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21308\/revisions"}],"predecessor-version":[{"id":21309,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21308\/revisions\/21309"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21308"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21308"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21308"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}