[2025年10月]更新のKCSA試験事前練習テスト試験問題と解答Kubernetes and Cloud Native学習ガイド [Q37-Q60]

[2025年10月]更新のKCSA試験事前練習テスト試験問題と解答Kubernetes and Cloud Native学習ガイド

Linux Foundation Kubernetes and Cloud Native Security Associate認証サンプル解答

質問 # 37
Given a standard Kubernetes cluster architecture comprising a single control plane node (hosting bothetcdand the control plane as Pods) and three worker nodes, which of the following data flows crosses atrust boundary
?

• A. From kubelet to Container Runtime
• B. From kubelet to Controller Manager
• C. From API Server to Container Runtime
• D. From kubelet to API Server

正解：D

解説：
* Trust boundariesexist where data flows between different security domains.
* In Kubernetes:
* Communication between thekubelet (node agent)and theAPI Server (control plane)crosses the node-to-control-plane trust boundary.
* (A) Kubelet to container runtime is local, no boundary crossing.
* (C) Kubelet does not communicate directly with the controller manager.
* (D) API server does not talk directly to the container runtime; it delegates to kubelet.
* Therefore, (B) is the correct trust boundary crossing flow.
References:
CNCF Security Whitepaper - Kubernetes Threat Model: identifies node-to-control-plane communications (kubelet # API Server) as crossing trust boundaries.
Kubernetes Documentation - Cluster Architecture

質問 # 38
An attacker compromises a Pod and attempts to use its service account token to escalate privileges within the cluster. Which Kubernetes security feature is designed tolimit what this service account can do?

• A. PodSecurity admission
• B. NetworkPolicy
• C. Role-Based Access Control (RBAC)
• D. RuntimeClass

正解：C

解説：
* When a Pod is created, Kubernetes automatically mounts aservice account tokenthat can authenticate to the API server.
* TheRole-Based Access Control (RBAC)system defines what actions a service account can perform.
* By carefully restricting Roles and RoleBindings, administrators limit the blast radius of a compromised Pod.
* Incorrect options:
* (A)PodSecurity admissionenforces workload-level security settings but does not control API access.
* (B)NetworkPolicycontrols network communication, not API privileges.
* (D)RuntimeClassselects container runtimes, unrelated to privilege escalation through API tokens.
References:
Kubernetes Documentation - Using RBAC Authorization
CNCF Security Whitepaper - Identity & Access Management: limiting lateral movement by constraining service account permissions.

質問 # 39
Which of the following statements on static Pods is true?

• A. The kubelet can run static Pods that span multiple nodes, provided that it has the necessary privileges from the API server.
• B. The kubelet can run a maximum of 5 static Pods on each node.
• C. The kubelet schedules static Pods local to its node without going through the kube-scheduler, making tracking and managing them difficult.
• D. The kubelet only deploys static Pods when the kube-scheduler is unresponsive.

正解：C

解説：
* Static Podsare managed directly by thekubeleton each node.
* They arenot scheduled by the kube-schedulerand always remain bound to the node where they are defined.
* Exact extract (Kubernetes Docs - Static Pods):
* "Static Pods are managed directly by the kubelet daemon on a specific node, without the API server. They do not go through the Kubernetes scheduler."
* Clarifications:
* A: Static Pods do not span multiple nodes.
* B: No hard limit of 5 Pods per node.
* D: They are not a fallback mechanism; kubelet always manages them regardless of scheduler state.
References:
Kubernetes Docs - Static Pods: https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/

質問 # 40
Which of the following statements correctly describes a container breakout?

• A. A container breakout is the process of escaping the container and gaining access to the cloud provider's infrastructure.
• B. A container breakout is the process of escaping the container and gaining access to the Pod's network traffic.
• C. A container breakout is the process of escaping a container when it reaches its resource limits.
• D. A container breakout is the process of escaping the container and gaining access to the host operating system.

正解：D

解説：
* Container breakoutrefers to an attacker escaping container isolation and reaching thehost OS.
* Once the host is compromised, the attacker can accessother containers, Kubernetes nodes, or escalate further.
* Exact extract (Kubernetes Security Docs):
* "If an attacker gains access to a container, they may attempt a container breakout to gain access to the host system."
* Other options clarified:
* A: Network access inside a Pod # breakout.
* B: Resource exhaustion is aDoS, not a breakout.
* C: Cloud infrastructure compromise is possibleafterhost compromise, but not the definition of breakout.
References:
Kubernetes Security Concepts: https://kubernetes.io/docs/concepts/security/ CNCF Security Whitepaper (Threats section):https://github.com/cncf/tag-security

質問 # 41
Which standard approach to security is augmented by the 4C's of Cloud Native security?

• A. Secure-by-Design
• B. Defense-in-Depth
• C. Zero Trust
• D. Least Privilege

正解：B

解説：
* The 4C's model (Cloud, Cluster, Container, Code) is presented in the official Kubernetes documentation as alayeredmodel that explicitly maps todefense-in-depth.
* Exact extracts from Kubernetes docs(security overview):
* "The 4C's of Cloud Native Security are Cloud, Clusters, Containers, and Code."
* "You can think of the 4C's asa layered approach to security; applying security measures at each layer reduces risk."
* "This layered approach is commonly known asdefense in depth."
References:
Kubernetes Docs - Security overview #The 4C's of Cloud Native Security: https://kubernetes.io/docs
/concepts/security/overview/#the-4cs-of-cloud-native-security

質問 # 42
Which of the following statements best describe container image signing and verification in the cloud environment?

• A. Container image signatures are concerned with defining developer ownership of applications within multi-tenant environments.
• B. Container image signatures affect the performance of containerized applications, as they increase the size of images with additional metadata.
• C. Container image signatures are mandatory in cloud environments, as cloud providers would deny the execution of unsigned container images.
• D. Container image signatures and their verification ensure their authenticity and integrity against tampering.

正解：D

解説：
* Image signing (withNotary, cosign, or similar tools) ensures that images are from a trusted source and have not been modified.
* Exact extract (Sigstore cosign docs):"Cosign allows you to sign and verify container images to ensure authenticity and integrity."
* Why others are wrong:
* B:Ownership can be inferred but it's aboutauthenticity & integritynot tenancy.
* C:Not mandatory; enforcement requiresadmission controllers.
* D:Metadata size is negligible and has no runtime performance impact.
References:
Sigstore Project: https://docs.sigstore.dev/cosign/overview
CNCF Security Whitepaper

質問 # 43
Which technology can be used to apply security policy for internal cluster traffic at the application layer of the network?

• A. Network Policy
• B. Ingress Controller
• C. Container Runtime
• D. Service Mesh

正解：D

解説：
* Service Mesh (e.g., Istio, Linkerd, Consul):operates atLayer 7 (application layer), enforcing policies like mTLS, authorization, and routing between services.
* NetworkPolicy:works atLayer 3/4 (IP/port), not Layer 7.
* Ingress Controller:handles external traffic ingress, not internal service-to-service traffic.
* Container Runtime:responsible for running containers, not enforcing application-layer security.
Exact extract (Istio docs):
* "Istio provides security by enforcing authentication, authorization, and encryption of service-to- service communication." References:
Kubernetes Docs - Network Policies: https://kubernetes.io/docs/concepts/services-networking/network- policies/ Istio Security Docs: https://istio.io/latest/docs/concepts/security/

質問 # 44
How can a user enforce thePod Security Standardwithout third-party tools?

• A. Through implementing Kyverno or OPA Policies.
• B. Use the PodSecurity admission controller.
• C. No additional measures have to be taken to enforce the Pod Security Standard.
• D. It is only possible to enforce the Pod Security Standard with additional tools within the cloud native ecosystem.

正解：B

解説：
* ThePodSecurity admission controller(built-in as of Kubernetes v1.23+) enforces the Pod Security Standards (Privileged, Baseline, Restricted).
* Enforcement is namespace-scoped and configured throughnamespace labels.
* Incorrect options:
* (A) Kyverno/OPA are external policy tools (useful but not required).
* (C) Not true, PodSecurity admission provides native enforcement.
* (D) Enforcement requires explicit configuration, not automatic.
References:
Kubernetes Documentation - Pod Security Admission
CNCF Security Whitepaper - Policy enforcement and admission control.

質問 # 45
What is the purpose of an egress NetworkPolicy?

• A. To control the incoming network traffic to a Kubernetes cluster.
• B. To secure the Kubernetes cluster against unauthorized access.
• C. To control the outgoing network traffic from one or more Kubernetes Pods.
• D. To control the outbound network traffic from a Kubernetes cluster.

正解：C

解説：
* NetworkPolicycontrols network trafficat the Pod level.
* Ingress rules:controlincomingconnections to Pods.
* Egress rules:controloutgoingconnectionsfrom Pods.
* Exact extract (Kubernetes Docs - Network Policies):
* "An egress rule controls outgoing connections from Pods that match the policy."
* Clarifying wrong answers:
* A/B: Too broad (cluster-level); policies apply per Pod/Namespace.
* C: Security against unauthorized access is broader than egress policies.
References:
Kubernetes Docs - Network Policies: https://kubernetes.io/docs/concepts/services-networking/network- policies/

質問 # 46
How do Kubernetes namespaces impact the application of policies when using Pod Security Admission?

• A. Different policies can be applied to specific namespaces.
• B. Namespaces are ignored; Pod Security Admission policies apply cluster-wide only.
• C. The default namespace enforces the strictest security policies by default.
• D. Each namespace can have only one active policy.

正解：A

解説：
* Pod Security Admission (PSA)enforces policies by applyinglabels on namespaces, not globally across the cluster.
* Exact extract (Kubernetes Docs - Pod Security Admission):
* "You can apply Pod Security Standards to namespaces by adding labels such as pod- security.kubernetes.io/enforce. Different namespaces can enforce different policies."
* Clarifications:
* A: Incorrect, namespaces are the unit of enforcement.
* C: Misleading - a namespace can have multiple enforcement modes (enforce, audit, warn).
* D: Default namespace doesnotenforce strict policies unless labeled.
References:
Kubernetes Docs - Pod Security Admission: https://kubernetes.io/docs/concepts/security/pod-security- admission/

質問 # 47
An attacker has successfully overwhelmed the Kubernetes API server in a cluster with a single control plane node by flooding it with requests.
How would implementing a high-availability mode with multiple control plane nodes mitigate this attack?

• A. By increasing the resources allocated to the API server, allowing it to handle a higher volume of requests.
• B. By implementing rate limiting and throttling mechanisms on the API server to restrict the number of requests allowed.
• C. By implementing network segmentation to isolate the API server from the rest of the cluster, preventing the attack from spreading.
• D. By distributing the workload across multiple API servers, reducing the load on each server.

正解：D

解説：
* Inhigh-availability clusters, multiple API server instances run behind a load balancer.
* Thisdistributes client requests across multiple API servers, preventing a single API server from being overwhelmed.
* Exact extract (Kubernetes Docs - High Availability Clusters):
* "A highly available control plane runs multiple instances of kube-apiserver, typically fronted by a load balancer, so that if one instance fails or is overloaded, others continue serving requests."
* Other options clarified:
* A: Network segmentation does not directly mitigate API server DoS.
* C: Adding resources helps, but doesn't solve single-point-of-failure.
* D: Rate limiting is a valid mitigation but not provided by HA alone.
References:
Kubernetes Docs - Building High-Availability Clusters: https://kubernetes.io/docs/setup/production- environment/tools/kubeadm/high-availability/

質問 # 48
Is it possible to restrict permissions so that a controller can only change the image of a deployment (without changing anything else about it, e.g., environment variables, commands, replicas, secrets)?

• A. Yes, with a 'managed fields' annotation.
• B. No, because granting access to the spec.containers.image field always grants access to the rest of the spec object.
• C. Yes, by granting permission to the /image subresource.
• D. Not with RBAC, but it is possible with an admission webhook.

正解：D

解説：
* RBAC in Kubernetesis coarse-grained: it controlsverbs(get, update, patch, delete) onresources(e.g., deployments), butnot individual fieldswithin a resource.
* There isno /image subresource for deployments(there is one for pods but only for ephemeral containers).
* Therefore,RBAC cannot restrict changes only to the image field.
* Admission Webhooks(mutating/validating)canenforce fine-grained policies (e.g., deny updates that change anything other than spec.containers[*].image).
* Exact extract (Kubernetes Docs - Admission Webhooks):
* "Admission webhooks can be used to enforce custom policies on objects being admitted." References:
Kubernetes Docs - RBAC: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Kubernetes Docs - Admission Webhooks: https://kubernetes.io/docs/reference/access-authn-authz
/extensible-admission-controllers/

質問 # 49
A container running in a Kubernetes cluster has permission to modify host processes on the underlying node.
What combination of privileges and capabilities is most likely to have led to this privilege escalation?

• A. There is no combination of privileges and capabilities that permits this.
• B. hostPath and AUDIT_WRITE
• C. hostPID and SYS_PTRACE
• D. hostNetwork and NET_RAW

正解：C

解説：
* hostPID:When enabled, the container shares the host's process namespace # container can see and potentially interact with host processes.
* SYS_PTRACE capability:Grants the container the ability to trace, inspect, and modify other processes (e.g., via ptrace).
* Combination of hostPID + SYS_PTRACE allows a container toattach to and modify host processes, which is a direct privilege escalation.
* Other options explained:
* hostPath + AUDIT_WRITE:hostPath exposes filesystem paths but does not inherently allow process modification.
* hostNetwork + NET_RAW:grants raw socket access but only for networking, not host process modification.
* A:Incorrect - such combinationsdo exist(like B).
References:
Kubernetes Docs - Configure a Pod to use hostPID: https://kubernetes.io/docs/tasks/configure-pod-container
/share-process-namespace/
Linux Capabilities man page: https://man7.org/linux/man-pages/man7/capabilities.7.html

質問 # 50
When should soft multitenancy be used over hard multitenancy?

• A. When the priority is enabling resource sharing and efficiency between tenants.
• B. When the priority is enabling complete isolation between tenants.
• C. When the priority is enabling fine-grained control over tenant resources.
• D. When the priority is enabling strict security boundaries between tenants.

正解：A

解説：
* Soft multitenancy(Namespaces, RBAC, Network Policies) # assumes some level of trust between tenants, focuses onresource sharing and efficiency.
* Hard multitenancy(separate clusters or strong virtualization) # strict isolation, used when tenants are untrusted.
* Exact extract (CNCF TAG Security Multi-Tenancy Whitepaper):
* "Soft multi-tenancy refers to multiple workloads running in the same cluster with some trust assumptions. It provides resource sharing and operational efficiency. Hard multi- tenancy requires stronger isolation guarantees, typically separate clusters." References:
CNCF Security TAG - Multi-Tenancy Whitepaper:https://github.com/cncf/tag-security/tree/main/multi- tenancy

質問 # 51
As a Kubernetes and Cloud Native Security Associate, a user can set upaudit loggingin a cluster. What is the risk of logging every event at the fullRequestResponselevel?

• A. Reduced storage requirements and faster performance.
• B. Improved security and easier incident investigation.
• C. Increased storage requirements and potential impact on performance.
• D. No risk, as it provides the most comprehensive audit trail.

正解：C

解説：
* Audit loggingrecords API server requests and responses for security monitoring.
* TheRequestResponse levellogs the full request and response bodies, which can:
* Significantly increasestorage and performance overhead.
* Potentially log sensitive data (including Secrets).
* Therefore, while comprehensive, it introduces risks of performance degradation and excessive log volume.
References:
Kubernetes Documentation - Auditing
CNCF Security Whitepaper - Logging and monitoring: trade-offs between verbosity, storage, and security.

質問 # 52
In Kubernetes, what isPublic Key Infrastructure (PKI)used for?

• A. To manage certificates and ensure secure communication in a Kubernetes cluster.
• B. To manage networking in a Kubernetes cluster.
• C. To monitor and analyze performance metrics of a Kubernetes cluster.
• D. To automate the scaling of containers in a Kubernetes cluster.

正解：A

解説：
* Kubernetes usesPKI certificatesextensively to secure communication between control plane components (API server, etcd, kube-scheduler, kube-controller-manager) and with kubelets.
* Certificates enablemutual TLS authentication and encryptionacross components.
* PKI does not handle scaling, networking, or monitoring.
References:
Kubernetes Documentation - Certificates
CNCF Security Whitepaper - Cluster communication security and the role of PKI.

質問 # 53
What is the difference between gVisor and Firecracker?

• A. gVisor and Firecracker are two names for the same technology, which provides isolation and security for containers.
• B. gVisor is a lightweight virtualization technology for creating and managing secure, multi-tenant container and function-as-a-service (FaaS) workloads. At the same time, Firecracker is a user-space kernel that provides isolation and security for containers.
• C. gVisor is a user-space kernel that provides isolation and security for containers. At the same time, Firecracker is a lightweight virtualization technology for creating and managing secure, multi-tenant container and function-as-a-service (FaaS) workloads.
• D. gVisor and Firecracker are both container runtimes that can be used interchangeably.

正解：C

解説：
* gVisor:
* Google-developed, implemented as auser-space kernelthat intercepts and emulates syscalls made by containers.
* Providesstrong isolationwithout requiring a full VM.
* Official docs: "gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system call interface."
* Source: https://gvisor.dev/docs/
* Firecracker:
* AWS-developed,lightweight virtualization technologybuilt on KVM, used in AWS Lambda and Fargate.
* Optimized for running secure, multi-tenant microVMs (MicroVMs) for containers and FaaS.
* Official docs: "Firecracker is an open-source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services."
* Source: https://firecracker-microvm.github.io/
* Key difference:gVisor # syscall interception in userspace kernel (container isolation). Firecracker # lightweight virtualization with microVMs (multi-tenant security).
* Therefore, optionAis correct.
References:
gVisor Docs: https://gvisor.dev/docs/
Firecracker Docs: https://firecracker-microvm.github.io/

質問 # 54
You are responsible for securing thekubeletcomponent in a Kubernetes cluster.
Which of the following statements about kubelet security is correct?

• A. Kubelet requires root access to interact with the host system.
• B. Kubelet supports TLS authentication and encryption for secure communication with the API server.
• C. Kubelet runs as a privileged container by default.
• D. Kubelet does not have any built-in security features.

正解：B

解説：
* Thekubeletis the primary agent that runs on each node in a Kubernetes cluster and communicates with the control plane.
* Kubeletsupports TLS (Transport Layer Security)for both authentication and encryption when interacting with the API server. This is a core security feature that ensures secure node-to-control-plane communication.
* Incorrect options:
* (A) Kubelet does not run as a privileged container by default; it runs as a system process (typically systemd-managed) on the host.
* (B) Kubelet does include built-in security features such asTLS authentication, authorization modes, and read-only vs secured ports.
* (D) While kubelet interacts with the host system (e.g., cgroups, container runtimes), it does not inherently require root access for communication security; RBAC and TLS handle authentication.
References:
Kubernetes Documentation - Kubelet authentication/authorization
CNCF Security Whitepaper - Cluster Component Security (discusses TLS and mutual authentication between kubelet and API server).

質問 # 55
A container image istrojanizedby an attacker by compromising the build server. Based on the STRIDE threat modeling framework, which threat category best defines this threat?

• A. Denial of Service
• B. Tampering
• C. Spoofing
• D. Repudiation

正解：B

解説：
* In STRIDE,Tamperingis the threat category forunauthorized modification of data or code/artifacts. A trojanized container image is, by definition, an attacker'smodificationof the build output (the image) after compromising the CI/build system-i.e., tampering with the artifact in the software supply chain.
* Why not the others?
* Spoofingis about identity/authentication (e.g., pretending to be someone/something).
* Repudiationis about denying having performed an action without sufficient audit evidence.
* Denial of Servicetargets availability (exhausting resources or making a service unavailable).The scenario explicitly focuses on analtered imageresulting from a compromised build server-this squarely maps toTampering.
Authoritative references (for verification and deeper reading):
* Kubernetes (official docs)- Supply Chain Security (discusses risks such as compromised CI/CD pipelines leading to modified/poisoned images and emphasizes verifying image integrity/signatures).
* Kubernetes Docs#Security#Supply chain securityandSecuring a cluster(sections on image provenance, signing, and verifying artifacts).
* CNCF TAG Security - Cloud Native Security Whitepaper (v2)- Threat modeling in cloud-native and software supply chain risks; describes attackers modifying build outputs (images/artifacts) via CI
/CD compromise as a form oftamperingand prescribes controls (signing, provenance, policy).
* CNCF TAG Security - Software Supply Chain Security Best Practices- Explicitly covers CI/CD compromise leading tomaliciously modified imagesand recommends SLSA, provenance attestation, and signature verification (policy enforcement via admission controls).
* Microsoft STRIDE (canonical reference)- DefinesTamperingasmodifying data or code, which directly fits a trojanized image produced by a compromised build system.

質問 # 56
A container image istrojanizedby an attacker by compromising the build server. Based on the STRIDE threat modeling framework, which threat category best defines this threat?

• A. Denial of Service
• B. Tampering
• C. Spoofing
• D. Repudiation

正解：B

解説：
* In STRIDE,Tamperingis the threat category forunauthorized modification of data or code/artifacts. A trojanized container image is, by definition, an attacker'smodificationof the build output (the image) after compromising the CI/build system-i.e., tampering with the artifact in the software supply chain.
* Why not the others?
* Spoofingis about identity/authentication (e.g., pretending to be someone/something).
* Repudiationis about denying having performed an action without sufficient audit evidence.
* Denial of Servicetargets availability (exhausting resources or making a service unavailable).The scenario explicitly focuses on analtered imageresulting from a compromised build server-this squarely maps toTampering.
Authoritative references (for verification and deeper reading):
* Kubernetes (official docs)- Supply Chain Security (discusses risks such as compromised CI/CD pipelines leading to modified/poisoned images and emphasizes verifying image integrity/signatures).
* Kubernetes Docs#Security#Supply chain securityandSecuring a cluster(sections on image provenance, signing, and verifying artifacts).
* CNCF TAG Security - Cloud Native Security Whitepaper (v2)- Threat modeling in cloud-native and software supply chain risks; describes attackers modifying build outputs (images/artifacts) via CI
/CD compromise as a form oftamperingand prescribes controls (signing, provenance, policy).
* CNCF TAG Security - Software Supply Chain Security Best Practices- Explicitly covers CI/CD compromise leading tomaliciously modified imagesand recommends SLSA, provenance attestation, and signature verification (policy enforcement via admission controls).
* Microsoft STRIDE (canonical reference)- DefinesTamperingasmodifying data or code, which directly fits a trojanized image produced by a compromised build system.

質問 # 57
In a Kubernetes environment, what kind of Admission Controller can modify resource manifests when applied to the Kubernetes API to fix misconfigurations automatically?

• A. ValidatingAdmissionController
• B. MutatingAdmissionController
• C. ResourceQuota
• D. PodSecurityPolicy

正解：B

解説：
* Kubernetes Admission Controllers can eithervalidateormutateincoming requests.
* MutatingAdmissionWebhook (Mutating Admission Controller):
* Canmodify or mutate resource manifestsbefore they are persisted in etcd.
* Used for automatic injection of sidecars (e.g., Istio Envoy proxy), setting default values, or fixing misconfigurations.
* ValidatingAdmissionWebhook (Validating Admission Controller):only allows/denies but doesnot change requests.
* PodSecurityPolicy:deprecated; cannot mutate requests.
* ResourceQuota:enforces resource usage, but does not mutate manifests.
Exact Extract:
* "Mutating admission webhooks are invoked first, and can modify objects to enforce defaults.
Validating admission webhooks are invoked second, and can reject requests to enforce invariants.
"
References:
Kubernetes Docs - Admission Controllers: https://kubernetes.io/docs/reference/access-authn-authz
/admission-controllers/
Kubernetes Docs - Admission Webhooks: https://kubernetes.io/docs/reference/access-authn-authz
/extensible-admission-controllers/

質問 # 58
A cluster administrator wants to enforce the use of a different container runtime depending on the application a workload belongs to.

• A. By manually modifying the container runtime for each workload after it has been created.
• B. By modifying the kube-apiserver configuration file to specify the desired container runtime for each application.
• C. By configuring avalidating admission controllerwebhook that verifies the container runtime based on the application label and rejects requests that do not comply.
• D. By configuring amutating admission controllerwebhook that intercepts new workload creation requests and modifies the container runtime based on the application label.

正解：D

解説：
* Kubernetes supports workload-specific runtimes viaRuntimeClass.
* Amutating admission controllercan enforce this automatically by:
* Intercepting workload creation requests.
* Modifying the Pod spec to set runtimeClassName based on labels or policies.
* Incorrect options:
* (A) Manual modification is not scalable or secure.
* (B) kube-apiserver cannot enforce per-application runtime policies.
* (C) A validating webhook can onlyreject, not modify, the runtime.
References:
Kubernetes Documentation - RuntimeClass
CNCF Security Whitepaper - Admission controllers for enforcing runtime policies.

質問 # 59
In a Kubernetes cluster, what are the security risks associated with using ConfigMaps for storing secrets?

• A. ConfigMaps store sensitive information in etcd encoded in base64 format automatically, which does not ensure confidentiality of data.
• B. Storing secrets in ConfigMaps does not allow for fine-grained access control via RBAC.
• C. Storing secrets in ConfigMaps can expose sensitive information as they are stored in plaintext and can be accessed by unauthorized users.
• D. Using ConfigMaps for storing secrets might make applications incompatible with the Kubernetes cluster.

正解：C

解説：
* ConfigMaps are explicitly not for confidential data.
* Exact extract (ConfigMap concept):"A ConfigMap is an API object used to store non- confidential data in key-value pairs."
* Exact extract (ConfigMap concept):"ConfigMaps are not intended to hold confidential data. Use a Secret for confidential data."
* Why this is risky:data placed into a ConfigMap is stored as regular (plaintext) string values in the API and etcd (unless you deliberately use binaryData for base64 content you supply). That means if someone has read access to the namespace or to etcd/APIServer storage, they can view the values.
* Secrets vs ConfigMaps (to clarify distractor D):
* Exact extract (Secret concept):"By default, secret data is stored as unencrypted base64- encoded strings.You canenable encryption at restto protect Secrets stored in etcd."
* This base64 behavior applies toSecrets, not to ConfigMap data. Thus optionDis incorrect for ConfigMaps.
* About RBAC (to clarify distractor A):Kubernetesdoessupport fine-grained RBAC forboth ConfigMaps and Secrets; the issue isn't lack of RBAC but that ConfigMaps arenotdesigned for confidential material.
* About compatibility (to clarify distractor C):Using ConfigMaps for secrets doesn't make apps
"incompatible"; it's simplyinsecureand against guidance.
References:
Kubernetes Docs -ConfigMaps: https://kubernetes.io/docs/concepts/configuration/configmap/ Kubernetes Docs -Secrets: https://kubernetes.io/docs/concepts/configuration/secret/ Kubernetes Docs -Encrypting Secret Data at Rest: https://kubernetes.io/docs/tasks/administer-cluster
/encrypt-data/
Note: The citations above are from the official Kubernetes documentation and reflect the stated guidance that ConfigMaps are fornon-confidentialdata, while Secrets (with encryption at rest enabled) are forconfidential data, and that the 4C's map todefense in depth.

質問 # 60
......

Linux Foundation試験練習テスト最高得点を獲得しよう：https://jp.fast2test.com/KCSA-premium-file.html

検証済み材料にはここKCSA：https://drive.google.com/open?id=16KiJhM-eKEQVJPTz37e_guGV_FH1X5Yd