{"id":21302,"date":"2026-09-24T12:02:06","date_gmt":"2026-09-24T12:02:06","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21302"},"modified":"2026-09-24T12:02:06","modified_gmt":"2026-09-24T12:02:06","slug":"linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part4-q61-80","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcsa-practice-test-questions-and-exam-dumps-part4-q61-80\/","title":{"rendered":"Linux Foundation KCSA Practice Test Questions and Exam Dumps Part4 Q61-80"},"content":{"rendered":"

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

 <\/p>\n

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

An organization wants to prevent developers from deploying container images from unknown public registries into a production Kubernetes cluster. Which security control is MOST appropriate?<\/b><\/p>\n

    \n
  1. <\/b> Admission policies that allow images only from approved registries<\/span><\/li>\n
  2. <\/b> Horizontal Pod Autoscaling<\/span><\/li>\n
  3. <\/b> Node affinity<\/span><\/li>\n
  4. <\/b> Increasing replica counts<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1. Admission policies that allow images only from approved registries<\/b><\/p>\n

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

    Admission policy enforcement can validate workload specifications before Kubernetes accepts them. An organization can define rules requiring production workloads to use container images only from trusted registries or approved repositories. This reduces the risk of unauthorized or malicious artifacts entering the cluster. The policy can be combined with signature verification, vulnerability scanning, image provenance, and immutable references such as digests. Restricting registry sources does not prove that every allowed image is secure, but it narrows the supply chain and makes governance easier. Autoscaling, node affinity, and replica configuration affect workload placement or availability and do not provide meaningful protection against unapproved container image sources.<\/span><\/p>\n

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

    A security team wants to ensure that production workloads use only container images that were approved by its trusted CI\/CD process. Which approach BEST supports this requirement?<\/b><\/p>\n

      \n
    1. <\/b> Allow developers to overwrite image tags manually<\/span><\/li>\n
    2. <\/b> Verify signed images or trusted provenance before admission<\/span><\/li>\n
    3. <\/b> Disable registry authentication<\/span><\/li>\n
    4. <\/b> Use public registries without restrictions<\/span><\/li>\n<\/ol>\n

      Correct Answer: 2. Verify signed images or trusted provenance before admission<\/b><\/p>\n

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

      Artifact signatures and provenance can provide evidence that an image originated from an authorized build process and has not been unexpectedly modified. Admission policies can verify those attributes before permitting a workload to run in production. This creates a stronger connection between approved source code, trusted builds, published artifacts, and deployment. The approach should also include protected CI\/CD credentials, trusted registries, immutable references, vulnerability management, and auditability. Simply using an image tag is insufficient because tags can be changed. Disabling registry authentication or allowing arbitrary public images weakens software supply chain security and increases the possibility of deploying unauthorized or tampered artifacts.<\/span><\/p>\n

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

      Which practice MOST directly helps determine how a particular production image was built and which source revision produced it?<\/b><\/p>\n

        \n
      1. <\/b> Increasing the pod restart policy<\/span><\/li>\n
      2. <\/b> Build provenance metadata<\/span><\/li>\n
      3. <\/b> NetworkPolicy<\/span><\/li>\n
      4. <\/b> Pod affinity<\/span><\/li>\n<\/ol>\n

        Correct Answer: 2. Build provenance metadata<\/b><\/p>\n

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

        Build provenance provides information about the origin and creation process of a software artifact. Depending on the implementation, it can describe the source repository, revision, build system, workflow, and other details associated with the resulting image. This information helps organizations verify that production artifacts came from expected build processes and can improve investigations when a supply chain compromise is suspected. Provenance works best when generated by trusted systems and protected from tampering. It complements artifact signing, SBOMs, vulnerability scanning, source control protection, and admission policies. NetworkPolicy and pod affinity address runtime communication and scheduling rather than traceability of how software artifacts were produced.<\/span><\/p>\n

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

        A company wants to prevent a compromised CI\/CD job from using credentials that provide unnecessary access to unrelated production resources. Which security principle should be applied?<\/b><\/p>\n

          \n
        1. <\/b> High availability<\/span><\/li>\n
        2. <\/b> Horizontal scaling<\/span><\/li>\n
        3. <\/b> Least privilege for pipeline identities and credentials<\/span><\/li>\n
        4. <\/b> Public registry access<\/span><\/li>\n<\/ol>\n

          Correct Answer: 3. Least privilege for pipeline identities and credentials<\/b><\/p>\n

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

          CI\/CD pipelines often require powerful credentials to access source repositories, registries, cloud services, or Kubernetes APIs. Those credentials should be restricted to the exact actions and environments the pipeline requires. A build pipeline that only publishes images should not automatically receive cluster-admin access, and a deployment identity for one namespace should not control unrelated environments. Least privilege reduces the blast radius if the pipeline, a dependency, or its credentials are compromised. Organizations should also separate duties, rotate credentials, prefer short-lived identity mechanisms where practical, monitor pipeline actions, and protect build infrastructure. Scaling and availability controls do not reduce excessive pipeline authorization.<\/span><\/p>\n

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

          Which practice BEST protects source code repositories used to build production Kubernetes applications?<\/b><\/p>\n

            \n
          1. <\/b> Strong authentication, protected branches, controlled changes, and review of sensitive modifications<\/span><\/li>\n
          2. <\/b> Anonymous write access<\/span><\/li>\n
          3. <\/b> Shared administrator credentials<\/span><\/li>\n
          4. <\/b> Disabling repository audit history<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. Strong authentication, protected branches, controlled changes, and review of sensitive modifications<\/b><\/p>\n

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

            Source repositories are a critical part of the software supply chain because malicious changes introduced there can propagate through trusted build and deployment systems. Strong authentication reduces account compromise risk, protected branches help prevent unauthorized direct changes, and code review can detect suspicious or unsafe modifications before they are merged. Repository audit history also helps investigators reconstruct who changed what and when. Additional protections may include signed commits, restricted automation tokens, secret scanning, dependency controls, and separation between development and production deployment authority. Anonymous write access and shared credentials undermine accountability and make it much easier for an attacker to introduce malicious source code.<\/span><\/p>\n

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

            A developer accidentally commits a production API token to a Git repository. What is the MOST appropriate immediate security response?<\/b><\/p>\n

              \n
            1. <\/b> Leave the token unchanged after deleting the file<\/span><\/li>\n
            2. <\/b> Revoke or rotate the exposed credential and investigate its use<\/span><\/li>\n
            3. <\/b> Increase the Kubernetes replica count<\/span><\/li>\n
            4. <\/b> Rename the repository<\/span><\/li>\n<\/ol>\n

              Correct Answer: 2. Revoke or rotate the exposed credential and investigate its use<\/b><\/p>\n

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

              Once a credential has been committed to a repository, it should be considered potentially exposed even if the file is later removed. Repository history, caches, forks, automated systems, or external access may preserve the secret. The safest response is to revoke or rotate the credential, determine where it was used, review logs for suspicious activity, and remove the exposed value from accessible history where appropriate. Preventive controls such as secret scanning and secure secret-management systems can reduce recurrence. Merely deleting the file does not invalidate the credential. Replica counts and repository names have no relationship to the compromise of an exposed authentication token.<\/span><\/p>\n

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

              Why is storing Kubernetes Secrets directly in a public Git repository considered unsafe?<\/b><\/p>\n

                \n
              1. <\/b> Anyone with repository access may obtain the sensitive values<\/span><\/li>\n
              2. <\/b> Git prevents Kubernetes deployments<\/span><\/li>\n
              3. <\/b> Secrets cannot be represented in YAML<\/span><\/li>\n
              4. <\/b> Kubernetes automatically deletes repository files<\/span><\/li>\n<\/ol>\n

                Correct Answer: 1. Anyone with repository access may obtain the sensitive values<\/b><\/p>\n

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

                Sensitive credentials should not be stored in publicly accessible source repositories. Kubernetes Secret manifests may contain values that are only encoded, not securely encrypted for public distribution. Anyone who obtains the repository contents or its history may be able to recover the credentials. Once leaked, those credentials may remain exposed even after the visible file is removed. Organizations should use secure secret-management practices, encryption mechanisms designed for Git-based workflows when appropriate, protected CI\/CD injection, and strict access controls. Credentials should also be rotated if accidental exposure occurs. Source repositories are useful for declarative configuration, but sensitive values require additional protection beyond ordinary version control.<\/span><\/p>\n

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

                Which capability BEST helps determine whether a running workload suddenly begins connecting to an unexpected external command-and-control server?<\/b><\/p>\n

                  \n
                1. <\/b> Horizontal Pod Autoscaling<\/span><\/li>\n
                2. <\/b> StorageClass<\/span><\/li>\n
                3. <\/b> Runtime network monitoring and threat detection<\/span><\/li>\n
                4. <\/b> Deployment rollout history<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 3. Runtime network monitoring and threat detection<\/b><\/p>\n

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

                  Runtime monitoring can observe network behavior from running workloads and identify connections that do not match expected application behavior. A workload that suddenly initiates traffic to an unfamiliar external destination may be compromised, misconfigured, or executing unauthorized software. Runtime detection systems can combine network activity with process, file, and system-call telemetry to improve context. NetworkPolicies can also reduce the risk proactively by limiting permitted egress destinations where practical. However, monitoring is valuable because attackers may exploit allowed communication paths or previously unknown weaknesses. Autoscaling and storage configuration do not detect suspicious outbound connections or runtime command-and-control activity.<\/span><\/p>\n

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

                  A Kubernetes application normally communicates only with an internal database, but security monitoring detects repeated connections to an unknown Internet address. What should the security team do FIRST?<\/b><\/p>\n

                    \n
                  1. <\/b> Investigate the anomalous behavior and determine whether the workload has been compromised<\/span><\/li>\n
                  2. <\/b> Increase the replica count<\/span><\/li>\n
                  3. <\/b> Disable audit logging<\/span><\/li>\n
                  4. <\/b> Grant the pod additional permissions<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1. Investigate the anomalous behavior and determine whether the workload has been compromised<\/b><\/p>\n

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

                    Unexpected network behavior is a meaningful security indicator, particularly when it differs from the application’s established communication pattern. The team should investigate the workload, related processes, recent deployments, image provenance, credentials, and network activity to determine whether the behavior is malicious or legitimate. Depending on incident-response procedures, containment may include isolating the workload, restricting network access, preserving evidence, and rotating potentially exposed credentials. Increasing replicas could multiply a compromised workload, while disabling logs would destroy valuable visibility. Additional permissions would increase risk. A disciplined incident-response process should prioritize validation, containment, evidence preservation, eradication, and recovery.<\/span><\/p>\n

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

                    Which Kubernetes resource is MOST useful for denying all ingress traffic to selected pods unless specific traffic is explicitly allowed?<\/b><\/p>\n

                      \n
                    1. <\/b> ConfigMap<\/span><\/li>\n
                    2. <\/b> A default-deny ingress NetworkPolicy<\/span><\/li>\n
                    3. <\/b> ServiceAccount<\/span><\/li>\n
                    4. <\/b> PersistentVolumeClaim<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2. A default-deny ingress NetworkPolicy<\/b><\/p>\n

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

                      A default-deny ingress NetworkPolicy establishes a restrictive network posture for selected pods by allowing no incoming traffic unless another policy explicitly permits it. This approach supports zero-trust and least-access principles because required communication is defined intentionally rather than assuming all internal traffic is trustworthy. The network plugin must support and enforce Kubernetes NetworkPolicy for the resource to have effect. Organizations may also create default-deny egress policies to restrict outbound traffic. Policies should be tested carefully so legitimate application communication, monitoring, DNS, and operational dependencies remain functional. ConfigMaps, service accounts, and persistent volumes solve unrelated configuration, identity, and storage requirements.<\/span><\/p>\n

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

                      Why can unrestricted pod egress create security risk even when inbound traffic is tightly controlled?<\/b><\/p>\n

                        \n
                      1. <\/b> A compromised workload may exfiltrate data or communicate with malicious external systems<\/span><\/li>\n
                      2. <\/b> Egress automatically disables Kubernetes RBAC<\/span><\/li>\n
                      3. <\/b> Outbound traffic prevents container startup<\/span><\/li>\n
                      4. <\/b> Egress eliminates audit logs<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 1. A compromised workload may exfiltrate data or communicate with malicious external systems<\/b><\/p>\n

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

                        Inbound restrictions reduce who can reach a workload, but a compromised workload may still initiate outbound connections. An attacker could use unrestricted egress to send stolen data, download additional malicious tools, communicate with command-and-control infrastructure, or scan external targets. Restrictive egress policies can limit workloads to destinations they legitimately require, such as specific internal services or approved external endpoints. Monitoring should complement prevention because not every destination can always be statically restricted. DNS requirements and dynamic external services may complicate policy design. Egress control is therefore one layer in a broader defense-in-depth strategy that also includes workload hardening, credentials protection, runtime detection, and application security.<\/span><\/p>\n

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

                        A security architect wants communication between sensitive microservices to provide confidentiality and server identity verification. Which control should be considered?<\/b><\/p>\n

                          \n
                        1. <\/b> Additional replicas<\/span><\/li>\n
                        2. <\/b> Encrypting service-to-service traffic with authenticated TLS where appropriate<\/span><\/li>\n
                        3. <\/b> Node labels<\/span><\/li>\n
                        4. <\/b> Increasing CPU limits<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 2. Encrypting service-to-service traffic with authenticated TLS where appropriate<\/b><\/p>\n

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

                          Authenticated TLS can provide confidentiality while data is in transit and help clients verify the identity of the server they are communicating with. In some architectures, mutual TLS can authenticate both sides of a service-to-service connection. Encryption reduces the risk of sensitive application data being read in transit, while authentication reduces the risk of communicating with an unauthorized endpoint. The exact implementation may involve application-level TLS, a service mesh, platform capabilities, or another trusted mechanism. Encryption does not replace NetworkPolicies or authorization because an encrypted malicious connection is still malicious. Strong security combines identity, authorization, network controls, encryption, certificate lifecycle management, and monitoring.<\/span><\/p>\n

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

                          Which practice MOST directly reduces the risk that an attacker can exploit an unnecessary service listening inside a container image?<\/b><\/p>\n

                            \n
                          1. <\/b> Remove unnecessary services, packages, and tools from the image<\/span><\/li>\n
                          2. <\/b> Increase memory limits<\/span><\/li>\n
                          3. <\/b> Add more namespaces<\/span><\/li>\n
                          4. <\/b> Increase the deployment replica count<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 1. Remove unnecessary services, packages, and tools from the image<\/b><\/p>\n

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

                            Every unnecessary package, daemon, command-line utility, or network service can increase a container’s attack surface. Minimal images reduce the number of components that may contain vulnerabilities and can limit the tools available to an attacker after compromise. Production containers should generally include only what is necessary to run the application. Multi-stage builds can help separate build-time tools from runtime images so compilers, package managers, and debugging utilities do not remain in production artifacts. Minimal images are not automatically secure, so organizations should still scan dependencies, update vulnerable components, use trusted base images, enforce non-root execution, and monitor runtime behavior.<\/span><\/p>\n

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

                            A production container image contains a compiler and package manager that are needed only during application build. Which improvement BEST follows container hardening practices?<\/b><\/p>\n

                              \n
                            1. <\/b> Run the container as privileged<\/span><\/li>\n
                            2. <\/b> Use a multi-stage build so build tools are excluded from the final runtime image<\/span><\/li>\n
                            3. <\/b> Add more Linux capabilities<\/span><\/li>\n
                            4. <\/b> Mount the host root filesystem<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 2. Use a multi-stage build so build tools are excluded from the final runtime image<\/b><\/p>\n

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

                              Multi-stage builds allow one build stage to contain compilers, package managers, source code, and other development tools while the final runtime stage contains only the application and its required runtime dependencies. This reduces image size and attack surface. If an attacker compromises the running application, fewer utilities are available for downloading tools, compiling malicious code, or exploring the environment. The runtime image should still be scanned and patched because minimal does not mean vulnerability-free. Privileged mode, additional capabilities, and host filesystem mounts would all increase the potential impact of a compromise rather than improve the security posture.<\/span><\/p>\n

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

                              Which control BEST helps protect Kubernetes API activity from a stolen long-lived administrator credential?<\/b><\/p>\n

                                \n
                              1. <\/b> Strong identity controls with short-lived authentication where practical and least-privilege authorization<\/span><\/li>\n
                              2. <\/b> Larger worker nodes<\/span><\/li>\n
                              3. <\/b> Additional container images<\/span><\/li>\n
                              4. <\/b> Disabling audit logs<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 1. Strong identity controls with short-lived authentication where practical and least-privilege authorization<\/b><\/p>\n

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

                                Long-lived administrative credentials are valuable targets because an attacker may continue using them until they are revoked. Strong centralized authentication, multi-factor authentication where applicable, short-lived credentials, and least-privilege RBAC can substantially reduce this risk. Individual identities also improve accountability compared with shared administrator credentials. Audit logging and behavioral monitoring provide additional visibility when credentials are misused. Organizations should review privileged access regularly and promptly revoke access when responsibilities change. Larger nodes or additional images do not protect credentials, while disabling audit logs would make unauthorized administrative activity harder to detect and investigate.<\/span><\/p>\n

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

                                Which incident-response action is MOST appropriate when a pod is strongly suspected of being compromised and may contain useful forensic evidence?<\/b><\/p>\n

                                  \n
                                1. <\/b> Immediately erase every related log before investigation<\/span><\/li>\n
                                2. <\/b> Contain the workload while preserving relevant evidence according to the incident-response process<\/span><\/li>\n
                                3. <\/b> Grant the pod cluster-admin access<\/span><\/li>\n
                                4. <\/b> Deploy additional copies of the same compromised image<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 2. Contain the workload while preserving relevant evidence according to the incident-response process<\/b><\/p>\n

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

                                  Incident response should balance containment with preservation of useful evidence. Depending on the organization’s procedures and risk, the compromised workload may be isolated from the network, removed from service, or otherwise contained while investigators preserve logs, runtime information, Kubernetes events, audit records, image identifiers, and other relevant evidence. Immediately deleting logs can destroy information needed to understand the attack. Deploying more copies may spread the compromise, while granting additional permissions would increase potential damage. Cloud-native environments are highly dynamic, so organizations should prepare incident-response procedures in advance and centralize important telemetry rather than assuming compromised containers will remain available for later analysis.<\/span><\/p>\n

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

                                  Why is centralized logging valuable for Kubernetes security monitoring?<\/b><\/p>\n

                                    \n
                                  1. <\/b> It preserves and correlates evidence from multiple components even if an individual workload disappears<\/span><\/li>\n
                                  2. <\/b> It replaces authentication<\/span><\/li>\n
                                  3. <\/b> It automatically patches applications<\/span><\/li>\n
                                  4. <\/b> It makes privileged containers safe<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1. It preserves and correlates evidence from multiple components even if an individual workload disappears<\/b><\/p>\n

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

                                    Containers and pods can be short-lived, restarted, rescheduled, or deleted, so logs stored only inside a workload may disappear before an investigation begins. Centralized logging can preserve application, Kubernetes, node, audit, and security telemetry in a separate location. This allows events from different components to be correlated and can improve detection and incident reconstruction. Central log systems should themselves be protected with access controls, retention policies, integrity protections, and monitoring because they may contain sensitive data and valuable evidence. Logging provides visibility but does not replace authentication, authorization, vulnerability remediation, network restrictions, or secure workload configuration.<\/span><\/p>\n

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

                                    A security team wants alerts when a user unexpectedly creates a ClusterRoleBinding granting cluster-admin privileges. Which data source is MOST relevant?<\/b><\/p>\n

                                      \n
                                    1. <\/b> Application performance metrics only<\/span><\/li>\n
                                    2. <\/b> Kubernetes audit logs<\/span><\/li>\n
                                    3. <\/b> Container image layer size<\/span><\/li>\n
                                    4. <\/b> PersistentVolume capacity<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 2. Kubernetes audit logs<\/b><\/p>\n

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

                                      Kubernetes audit logs can record API requests involving authorization resources such as ClusterRoleBindings. An alerting system can monitor those logs for highly privileged changes, unexpected users, unusual source locations, or actions occurring outside normal administrative workflows. Creation of a cluster-admin binding is a high-impact event because it may grant broad control over the cluster. Monitoring should be combined with preventive RBAC design and change controls so only authorized identities can create such bindings in the first place. Application performance metrics and storage statistics may be useful operationally, but they do not provide the detailed API activity needed to detect privilege-related administrative changes.<\/span><\/p>\n

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

                                      Which approach BEST limits the blast radius if credentials from one Kubernetes application are compromised?<\/b><\/p>\n

                                        \n
                                      1. <\/b> Use dedicated identities, narrowly scoped RBAC, restricted network access, and separate Secrets<\/span><\/li>\n
                                      2. <\/b> Give all applications the same service account<\/span><\/li>\n
                                      3. <\/b> Store all application credentials in one shared Secret<\/span><\/li>\n
                                      4. <\/b> Allow all namespaces unrestricted access to every service<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1. Use dedicated identities, narrowly scoped RBAC, restricted network access, and separate Secrets<\/b><\/p>\n

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

                                        Blast-radius reduction depends on avoiding unnecessary trust relationships between applications. Dedicated service accounts prevent one workload from automatically inheriting another workload’s permissions. Narrow RBAC limits Kubernetes API access, separate Secrets limit credential exposure, and NetworkPolicies restrict lateral communication. Namespace boundaries and admission policies can provide additional layers. Shared service accounts, shared credential stores, and unrestricted networking increase the likelihood that compromise of one workload will affect many others. Security architecture should assume that individual workloads may eventually be compromised and should therefore make lateral movement and privilege expansion as difficult as practical.<\/span><\/p>\n

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

                                        Which approach BEST represents secure Kubernetes operations over time rather than a one-time hardening exercise?<\/b><\/p>\n

                                          \n
                                        1. <\/b> Configure security once and never review it again<\/span><\/li>\n
                                        2. <\/b> Depend entirely on container isolation<\/span><\/li>\n
                                        3. <\/b> Continuously review vulnerabilities, access, policies, supply chain controls, runtime behavior, logs, and incident readiness<\/span><\/li>\n
                                        4. <\/b> Grant broad permissions to reduce administrative effort<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 3. Continuously review vulnerabilities, access, policies, supply chain controls, runtime behavior, logs, and incident readiness<\/b><\/p>\n

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

                                          Kubernetes security changes continuously because applications evolve, users change roles, new vulnerabilities are discovered, dependencies are updated, and attackers develop new techniques. A mature security program therefore includes recurring access reviews, vulnerability management, image rebuilding, policy validation, supply chain verification, runtime detection, audit-log analysis, credential rotation, and testing of incident-response procedures. Configuration drift should also be monitored so insecure changes do not accumulate over time. Security cannot be treated as a one-time installation task. Defense in depth remains effective only when the individual controls are maintained, monitored, and adapted as the environment and threat landscape change.<\/span><\/p>\n

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

                                          View Full Linux Foundation KCSA Exam Dumps and Practice Test Dumps   Question 61. An organization wants to prevent developers from deploying container images from unknown public registries into a production Kubernetes cluster. Which security control is MOST appropriate? Admission policies that allow images only from approved registries Horizontal Pod Autoscaling Node affinity Increasing replica […]<\/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\/21302"}],"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=21302"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21302\/revisions"}],"predecessor-version":[{"id":21303,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21302\/revisions\/21303"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21302"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21302"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21302"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}