[2026年09月06日] 完全版最新の問題集でPDFで最新KCNA試験問題と解答 [Q93-Q115]

[2026年09月06日] 完全版最新の問題集でPDFで最新KCNA試験問題と解答

無料で使えるKCNA試験問題集で100%合格できる試験簡単に合格させるGoShiken

KCNA認定試験は、Kubernetesとクラウドネイティブ技術を使用して実世界の問題を解決する能力を評価するパフォーマンスベースのテストです。この試験は、候補者がKubernetesクラスタを展開、管理、スケーリングする能力、およびコンテナ化、マイクロサービス、サービスメッシュなどの関連技術に関する知識を示すことを求める一連の実践的なタスクから構成されています。この試験はオンラインで実施され、世界中のどこからでも受験することができます。認定は2年間有効であり、その後は再認定試験に合格するか、より上位の認定を取得することで認定を更新する必要があります。

 

質問 # 93
What happens with a regular Pod running in Kubernetes when a node fails?

• A. A new Pod is scheduled on a different node only if it is configured explicitly.
• B. A new Pod with the same UID is scheduled to another node after a while.
• C. By default, a Pod can only be scheduled to the same node when the node fails.
• D. A new, near-identical Pod but with different UID is scheduled to another node.

正解：D

解説：
B is correct: when a node fails, Kubernetes does not "move" the same Pod instance; instead, a new Pod object (new UID) is created to replace it-assuming the Pod is managed by a controller (Deployment/ReplicaSet, StatefulSet, etc.). A Pod is an API object with a unique identifier (UID) and is tightly associated with the node it's scheduled to via spec.nodeName. If the node becomes unreachable, that original Pod cannot be restarted elsewhere because it was bound to that node.
Kubernetes' high availability comes from controllers maintaining desired state. For example, a Deployment desires N replicas. If a node fails and the replicas on that node are lost, the controller will create replacement Pods, and the scheduler will place them onto healthy nodes. These replacement Pods will be "near-identical" in spec (same template), but they are still new instances with new UIDs and typically new IPs.
Why the other options are wrong:
A is incorrect because the UID does not remain the same-Kubernetes creates a new Pod object rather than reusing the old identity.
C is incorrect; pods are not restricted to the same node after failure. The whole point of orchestration is to reschedule elsewhere.
D is incorrect; rescheduling does not require special explicit configuration for typical controller-managed workloads. The controller behavior is standard. (If it's a bare Pod without a controller, it will not be recreated automatically.) This also ties to the difference between "regular Pod" vs controller-managed workloads: a standalone Pod is not self-healing by itself, while a Deployment/ReplicaSet provides that resilience. In typical production design, you run workloads under controllers specifically so node failure triggers replacement and restores replica count.
Therefore, the correct outcome is B.

質問 # 94
How does dynamic storage provisioning work?

• A. A user requests dynamically provisioned storage by including an existing StorageClass in their PersistentVolumeClaim.
• B. An administrator creates a StorageClass and includes it in their Pod YAML definition file without creating a PersistentVolumeClaim.
• C. A Pod requests dynamically provisioned storage by including a StorageClass and the Pod name in their PersistentVolumeClaim.
• D. An administrator creates a PersistentVolume and includes the name of the PersistentVolume in their Pod YAML definition file.

正解：A

解説：
Dynamic provisioning is the Kubernetes mechanism where storage is created on-demand when a user creates a PersistentVolumeClaim (PVC) that references a StorageClass, so A is correct. In this model, the user does not need to pre-create a PersistentVolume (PV). Instead, the StorageClass points to a provisioner (typically a CSI driver) that knows how to create a volume in the underlying storage system (cloud disk, SAN, NAS, etc.). When the PVC is created with storageClassName: <class>, Kubernetes triggers the provisioner to create a new volume and then binds the resulting PV to that PVC.
This is why option B is incorrect: you do not put a StorageClass "in the Pod YAML" to request provisioning.
Pods reference PVCs, not StorageClasses directly. Option C is incorrect because the PVC does not need the Pod name; binding is done via the PVC itself. Option D describes static provisioning: an admin pre-creates PVs and users claim them by creating PVCs that match the PV (capacity, access modes, selectors). Static provisioning can work, but it is not dynamic provisioning.
Under the hood, the StorageClass can define parameters like volume type, replication, encryption, and binding behavior (e.g., volumeBindingMode: WaitForFirstConsumer to delay provisioning until the Pod is scheduled, ensuring the volume is created in the correct zone). Reclaim policies (Delete/Retain) define what happens to the underlying volume after the PVC is deleted.
In cloud-native operations, dynamic provisioning is preferred because it improves developer self-service, reduces manual admin work, and makes scaling stateful workloads easier and faster. The essence is: PVC + StorageClass # automatic PV creation and binding.
=========

質問 # 95
What is the telemetry component that represents a series of related distributed events that encode the end-to- end request flow through a distributed system?

• A. Spans
• B. Metrics
• C. Traces
• D. Logs

正解：C

解説：
In observability, traces represent an end-to-end view of a request as it flows through multiple services, so D is correct. Tracing is particularly important in cloud-native microservices architectures because a single user action (like "checkout" or "search") may traverse many services via HTTP/gRPC calls, message queues, and databases. Traces link those related events together so you can see where time is spent, where errors occur, and how dependencies behave.
A trace is typically composed of multiple spans (option C). A span is a single timed operation (e.g., "HTTP GET /orders", "DB query", "call payment service"). Spans include timing, attributes (tags), status/error information, and parent/child relationships. While spans are essential building blocks, the "series of related distributed events encoding end-to-end request flow" is the trace as a whole, not an individual span.
Metrics (option A) are numeric time series used for aggregation and alerting (rates, latency percentiles when derived, resource usage). Logs (option B) are discrete event records (text or structured) useful for forensic detail and debugging. Both are valuable, but neither inherently provides a stitched, causal, end-to-end request path across services. Traces do exactly that by propagating trace context (trace IDs/span IDs) across service boundaries (often via headers).
In Kubernetes environments, traces are commonly exported via OpenTelemetry instrumentation/collectors and visualized in tracing backends. Tracing enables faster incident resolution by pinpointing the slow hop, the failing downstream dependency, or unexpected fan-out. Therefore, the correct telemetry component for end- to-end distributed request flow is Traces (D).
=========

質問 # 96
You are running a web application with a high demand for CPU resources. Which Kubernetes scheduling strategy could help you ensure pods are scheduled on nodes with the most available CPU capacity?

• A. Node anti-affinity
• B. Pod affinity
• C. Taints and tolerations
• D. Node affinity
• E. Pod anti-affinity

正解：D

解説：
Node affinity allows you to define preferences for where pods should be scheduled based on node labels. You can use node affinity to prioritize scheduling on nodes with high CPU capacity. While the other options can influence scheduling, they are not directly focused on CPU availability.

質問 # 97
Which of the following is a definition of Hybrid Cloud?

• A. A combination of services running in public and private data centers, only including data centers from the same cloud provider.
• B. A cloud native architecture that uses services running in different public and private clouds, including on-premises data centers.
• C. A combination of services running in public and private data centers, excluding serverless functions.
• D. A cloud native architecture that uses services running in public clouds, excluding data centers in different availability zones.

正解：B

解説：
A hybrid cloud architecture combines public cloud and private/on-premises environments, often spanning multiple infrastructure domains while maintaining some level of portability, connectivity, and unified operations. Option C captures the commonly accepted definition: services run across public and private clouds, including on-premises data centers, so C is correct.
Hybrid cloud is not limited to a single cloud provider (which is why A is too restrictive). Many organizations adopt hybrid cloud to meet regulatory requirements, data residency constraints, latency needs, or to preserve existing investments while still using public cloud elasticity. In Kubernetes terms, hybrid strategies often include running clusters both on-prem and in one or more public clouds, then standardizing deployment through Kubernetes APIs, GitOps, and consistent security/observability practices.
Option B is incorrect because excluding data centers in different availability zones is not a defining property; in fact, hybrid deployments commonly use multiple zones/regions for resilience. Option D is a distraction:
serverless inclusion or exclusion does not define hybrid cloud. Hybrid is about the combination of infrastructure environments, not a specific compute model.
A practical cloud-native view is that hybrid architectures introduce challenges around identity, networking, policy enforcement, and consistent observability across environments. Kubernetes helps because it provides a consistent control plane API and workload model regardless of where it runs. Tools like service meshes, federated identity, and unified monitoring can further reduce fragmentation.
So, the most accurate definition in the given choices is C: hybrid cloud combines public and private clouds, including on-premises infrastructure, to run services in a coordinated architecture.
=========

質問 # 98
You want to configure a CI/CD pipeline to deploy a microservice to Kubernetes. Which of the following steps are essential in the pipeline?

• A. Run automated tests
• B. Push the container image to a registry
• C. Monitor the deployed application
• D. Apply Kubernetes configuration files (e.g., Deployment, Service)
• E. Build the container image

正解：A、B、D、E

解説：
All the listed steps are essential for a robust CIICD pipeline. Building the container image encapsulates your application, pushing it to a registry ensures easy access, applying Kubernetes configurations defines the deployment, and automated tests validate the application's functionality before deployment.

質問 # 99
Manual reclamation policy of a PV resource is known as:

• A. Recycle
• B. Retain
• C. claimRef
• D. Delete

正解：B

解説：
The correct answer is C: Retain. In Kubernetes persistent storage, a PersistentVolume (PV) has a persistentVolumeReclaimPolicy that determines what happens to the underlying storage asset after its PersistentVolumeClaim (PVC) is deleted. The reclaim policy options historically include Delete and Retain (and Recycle, which is deprecated/removed in many modern contexts). "Manual reclamation" refers to the administrator having to manually clean up and/or rebind the storage after the claim is released-this behavior corresponds to Retain.
With Retain, when the PVC is deleted, the PV moves to a "Released" state, but the actual storage resource (cloud disk, NFS path, etc.) is not deleted automatically. Kubernetes will not automatically make that PV available for a new claim until an administrator takes action-typically cleaning the data, removing the old claim reference, and/or creating a new PV/PVC binding flow. This is important for data safety: you don't want to automatically delete sensitive or valuable data just because a claim was removed.
By contrast, Delete means Kubernetes (via the storage provisioner/CSI driver) will delete the underlying storage asset when the claim is deleted-useful for dynamic provisioning and disposable environments. Recycle used to scrub the volume contents and make it available again, but it's not the recommended modern approach and has been phased out in favor of dynamic provisioning and explicit workflows.
So, the policy that implies manual intervention and manual cleanup/reuse is Retain, which is option C.

質問 # 100
In distributed system tracing, is the term used to refer to a request as it passes through a single com-ponent of the distributed system?

• A. Span
• B. Bucket
• C. Log
• D. Trace

正解：A

解説：
https://www.splunk.com/en_us/data-insider/what-is-distributed-tracing.html

質問 # 101
What are the two goals of Cloud-Native?

• A. Frequent deployments and well-defined organizational silos
• B. Rapid innovation and reliability
• C. Slow innovation and stable applications
• D. Rapid innovation and automation

正解：B

解説：
https://www.redhat.com/en/topics/cloud-native-apps

質問 # 102
You have a Kubernetes cluster running on AWS. You want to configure a persistent volume claim (PVC) that uses an AWS EBS volume for storage. Which annotation can be used to specify the EBS volume type?

• A. volume.beta.kubernetes.io/storage-provisioner
• B. volume.beta.kubernetes.io/aws-ebs-volume-encrypted
• C. volume.beta.kubernetes.io/aws-ebs-volume-size
• D. volume.beta.kubernetes.io/aws-ebs-volume-type
• E. volume.beta.kubernetes.io/storage-class

正解：D

解説：
The annotation •volume.beta.kubernetes.io/aws-ebs-volume-type• is used to specify the EBS volume type (e.g., 'gp2 , 701', 'standard') when using an AWS EBS volume for persistent storage. Option 'A' is used to specify the storage class for the PVC. Option 'B' specifies the storage provisioner, which is responsible for creating the volume. Option 'D' is used to specify the size of the EBS volume. Option 'E' is for specifying whether the EBS volume should be encrypted.

質問 # 103
Which kubernetes object do deployments use behind the scenes when they need to scale pods?

• A. Replication controller
• B. ReplicaSets
• C. kubectl
• D. Horizontal pod autoscaler

正解：B

解説：
https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

質問 # 104
Scenario: You have a Kubernetes cluster hosted in a public cloud provider. When trying to create a Service of type LoadBalancer, the external-ip is stuck in the "Pending" state. Which Kubernetes component is failing in this scenario?

• A. Cloud Load Balancer Manager
• B. Cloud Architecture Manager
• C. Load Balancer Manager
• D. Cloud Controller Manager

正解：D

解説：
When you create a Service of type LoadBalancer in a cloud environment, Kubernetes relies on cloud- provider integration to provision an external load balancer and allocate a public IP (or equivalent). The control plane component responsible for this integration is the cloud-controller-manager, so A is correct.
In Kubernetes, a LoadBalancer Service triggers a controller loop that calls the cloud provider APIs to create
/update a load balancer that forwards traffic to the cluster (often via NodePorts on worker nodes, or via provider-specific mechanisms). The Service remains with EXTERNAL-IP: Pending until the cloud provider resource is successfully created and the controller updates the Service status with the assigned external address. If that status never updates, it usually indicates the cloud integration path is broken-commonly due to: missing cloud provider configuration, broken credentials/IAM permissions, the cloud-controller-manager not running/healthy, or a misconfigured cloud provider implementation.
The other options are not real Kubernetes components. Kubernetes does not include a "Load Balancer Manager" or "Cloud Architecture Manager" component name in its standard architecture. In many managed Kubernetes offerings, the cloud-controller-manager (or its equivalent) is provided/managed by the provider, but the responsibility remains the same: reconcile Kubernetes Service resources into cloud load balancer resources.
Therefore, in this scenario, the failing component is the Cloud Controller Manager, which is the Kubernetes control plane component that interfaces with the cloud provider to provision external load balancers and update the Service status.
=========

質問 # 105
You are tasked with deploying a microservices application on Kubernetes. The application relies heavily on communication between its different services, and you need to ensure reliable and secure communication. Which of the following open standards are most relevant for this scenario?

• A. Open Container Initiative (OCI)
• B. Service Level Objectives (SLOs)
• C. Kubernetes API
• D. Open Service Mesh (OSM)
• E. Cloud Native Computing Foundation (CNCF)

正解：D

解説：
Open Service Mesh (OSM) is an open standard focused on providing a secure and reliable way to connect microservices. It helps with service discovery, load balancing, traffic management, and security features, making it ideal for deploying microservices applications on Kubernetes.

質問 # 106
You are using Prometheus to monitor your Kubernetes cluster. You notice that several pods are
experiencing high memory usage. You want to investigate further to determine which containers within these pods are consuming the most memory. How can you effectively use Prometheus to identify these memory-intensive containers?

• A. Use the metric to identify the requested memory limits for each containa
• B. Use the 'kube_pod_container_status_memory_usage_bytes' metric to analyze the actual memory usage of each container.
• C. Filter Prometheus queries by container name and sort by memory usage to pinpoint the memory-intensive containers.
• D. Utilize the • metric to identify containers that are frequently restarting due to memory pressure.
• E. Utilize the metric to identify pods that are not ready due to memory constraints.

正解：B、C

解説：
Both options B and D provide effective solutions for identifying memory-intensive containers. Option B allows you to directly analyze the 'kube_pod_container_status_memory_usage_bytes• metric, which provides the actual memory usage of each container within the pod. Option D suggests filtering Prometheus queries by container name and sorting by memory usage, enabling you to easily pinpoint containers with the highest memory consumption. While option A provides information about requested memory limits, it doesn't directly reflect the actual memory usage. Options C and E are not directly relevant to identifying memory-intensive containers.

質問 # 107
Your application requires a specific storage class for its persistent dat
a. How do you configure this storage class within your deployment YAML?

• A. Specify the storage class name within the field of the deployment.
• B. Create a separate PersistentVolumeClaim (PVC) with the desired storage class and reference the PVC in the deployment's name' field.
• C. Specify the storage class name within the 'spec.template.spec.containers[01.volumeMounts[0].storageClassName' field of the deployment.
• D. Specify the storage class name directly within the 'spec.template.spec.containers[0].volumeMounts[0].name' field of the deployment.
• E. None of the above

正解：B

解説：
The correct approach is to create a separate PersistentVolumeClaim (PVC) that specifies the desired storage class and reference the PVC in the deployments 'spec_template.spec_containers[0]_volumeMounts[0]_name' field. This ensures the PVC is automatically bound to a PV with the correct storage class. Specifying the storage class name directly within the deployment or the volumeMounts section is not the standard practice for defining storage requirements.

質問 # 108
What is autoscaling?

• A. Automatically adding or removing compute resources as needed
• B. Automatically assigning workloads to nodes in a cluster
• C. Automatically measuring resource usage
• D. Automatically repairing broken application instances

正解：A

解説：
https://kubernetes.io/blog/2016/07/autoscaling-in-kubernetes/
Autoscaling means automatically scaling up or down in response to real-time usage data.

質問 # 109
What is the common standard for Service Meshes?

• A. Service Mesh Function (SMF)
• B. Service Mesh Interface (SMI)
• C. Service Mesh Technology (SMT)
• D. Service Mesh Specification (SMS)

正解：B

解説：
A widely referenced interoperability standard in the service mesh ecosystem is the Service Mesh Interface (SMI), so C is correct. SMI was created to provide a common set of APIs for basic service mesh capabilities-helping users avoid being locked into a single mesh implementation for core features. While service meshes differ in architecture and implementation (e.g., Istio, Linkerd, Consul), SMI aims to standardize how common behaviors are expressed.
In cloud native architecture, service meshes address cross-cutting concerns for service-to-service communication: traffic policies, observability, and security (mTLS, identity). Rather than baking these concerns into every application, a mesh typically introduces data-plane proxies and a control plane to manage policy and configuration. SMI sits above those implementations as a common API model.
The other options are not commonly used industry standards. You may see other efforts and emerging APIs, but among the listed choices, SMI is the recognized standard name that appears in cloud native discussions and tooling integrations.
Also note a practical nuance: even with SMI, not every mesh implements every SMI spec fully, and many users still adopt mesh-specific CRDs and APIs for advanced features. But for this question's framing-
"common standard"-Service Mesh Interface is the correct answer.

質問 # 110
Which of the following statements accurately describes the role of ArgoCD in GitOps?

• A. ArgoCD is a tool for managing Kubernetes secrets and sensitive data.
• B. ArgoCD is a container orchestration platform for managing Kubernetes deployments.
• C. ArgoCD is a GitOps engine that synchronizes your Kubernetes cluster with your Git repository, ensuring your desired state is maintained.
• D. ArgoCD is a continuous integration and continuous delivery (CIICD) tool for building and testing applications.
• E. ArgoCD is a cloud-native storage solution for storing Kubernetes configurations.

正解：C

解説：
ArgoCD is a declarative GitOps engine that uses your Git repository as the single source of truth for your Kubernetes cluster's desired state. It monitors changes in the repository and automatically applies them to the cluster, ensuring consistency and reliability.

質問 # 111
Fluentd is the only way to export logs from Kubernetes cluster or applications running in cluster

• A. False
• B. True

正解：A

解説：
https://github.com/cncf/landscape#trail-map

質問 # 112
A Kubernetes _____ is an abstraction that defines a logical set of Pods and a policy by which to access them.

• A. Service
• B. Controller
• C. Selector
• D. Job

正解：A

解説：
A Kubernetes Service is the abstraction that defines a logical set of Pods and the policy for accessing them, so C is correct. Pods are ephemeral: their IPs change as they are recreated, rescheduled, or scaled. A Service solves this by providing a stable endpoint (DNS name and virtual IP) and routing rules that send traffic to the current healthy Pods backing the Service.
A Service typically uses a label selector to identify which Pods belong to it. Kubernetes then maintains endpoint data (Endpoints/EndpointSlice) for those Pods and uses the cluster dataplane (kube-proxy or eBPF- based implementations) to forward traffic from the Service IP/port to one of the backend Pod IPs. This is what the question means by "logical set of Pods" and "policy by which to access them" (for example, round-robin- like distribution depending on dataplane, session affinity options, and how ports map via targetPort).
Option A (Selector) is only the query mechanism used by Services and controllers; it is not itself the access abstraction. Option B (Controller) is too generic; controllers reconcile desired state but do not provide stable network access policies. Option D (Job) manages run-to-completion tasks and is unrelated to network access abstraction.
Services can be exposed in different ways: ClusterIP (internal), NodePort, LoadBalancer, and ExternalName.
Regardless of type, the core Service concept remains: stable access to a dynamic set of Pods. This is foundational to Kubernetes networking and microservice communication, and it is why Service discovery via DNS works effectively across rolling updates and scaling events.
Thus, the correct answer is Service (C).
=========

質問 # 113
Which of the following is a recommended security habit in Kubernetes?

• A. Allow privilege escalation from within a container as the default option.
• B. Disallow privilege escalation from within a container as the default option.
• C. Run the containers as the user with user ID 0 (root) and any group ID.
• D. Run the containers as the user with group ID 0 (root) and any user ID.

正解：B

解説：
The correct answer is B. A widely recommended Kubernetes security best practice is to disallow privilege escalation inside containers by default. In Kubernetes Pod/Container security context, this is represented by allowPrivilegeEscalation: false. This setting prevents a process from gaining more privileges than its parent process-commonly via setuid/setgid binaries or other privilege-escalation mechanisms. Disallowing privilege escalation reduces the blast radius of a compromised container and aligns with least-privilege principles.
Options A and C are explicitly unsafe because they encourage running as root (UID 0 and/or GID 0). Running containers as root increases risk: if an attacker breaks out of the application process or exploits kernel/runtime vulnerabilities, having root inside the container can make privilege escalation and lateral movement easier. Modern Kubernetes security guidance strongly favors running as non-root (runAsNonRoot: true, explicit runAsUser), dropping Linux capabilities, using read-only root filesystems, and applying restrictive seccomp/AppArmor/SELinux profiles where possible.
Option D is the opposite of best practice. Allowing privilege escalation by default increases the attack surface and violates the idea of secure defaults.
Operationally, this habit is often enforced via admission controls and policies (e.g., Pod Security Admission in "restricted" mode, or policy engines like OPA Gatekeeper/Kyverno). It's also important for compliance: many security baselines require containers to run as non-root and to prevent privilege escalation.
So, the recommended security habit among the choices is clearly B: Disallow privilege escalation.

質問 # 114
What are the two steps performed by the kube-scheduler to select a node to schedule a pod?

• A. Filtering and selecting
• B. Filtering and scoring
• C. Grouping and placing
• D. Scoring and creating

正解：B

解説：
The kube-scheduler selects a node in two main phases: filtering and scoring, so C is correct. First, filtering identifies which nodes are feasible for the Pod by applying hard constraints. These include resource availability (CPU/memory requests), node taints/tolerations, node selectors and required affinities, topology constraints, and other scheduling requirements. Nodes that cannot satisfy the Pod's requirements are removed from consideration.
Second, scoring ranks the remaining feasible nodes using priority functions to choose the "best" placement. Scoring can consider factors like spreading Pods across nodes/zones, packing efficiency, affinity preferences, and other policies configured in the scheduler. The node with the highest score is selected (with tie-breaking), and the scheduler binds the Pod by setting spec.nodeName.
Option B ("filtering and selecting") is close but misses the explicit scoring step that is central to scheduler design. The scheduler does "select" a node, but the canonical two-step wording in Kubernetes scheduling is filtering then scoring. Options A and D are not how scheduler internals are described.
Operationally, understanding filtering vs scoring helps troubleshoot scheduling failures. If a Pod can't be scheduled, it failed in filtering-kubectl describe pod often shows "0/... nodes are available" reasons (insufficient CPU, taints, affinity mismatch). If it schedules but lands in unexpected places, it's often about scoring preferences (affinity weights, topology spread preferences, default scheduler profiles).
So the verified correct answer is C: kube-scheduler uses Filtering and Scoring.

質問 # 115
......

無料で試せるKCNA試験問題KCNA実際の無料試験問題：https://www.goshiken.com/Linux-Foundation/KCNA-mondaishu.html

検証済みのKCNA問題集と242格別な問題：https://drive.google.com/open?id=1ygXd3atnqwapqlLocy1raNEbT7GIlFPr