{"id":17231,"date":"2026-09-21T07:10:33","date_gmt":"2026-09-21T07:10:33","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=17231"},"modified":"2026-09-21T07:10:33","modified_gmt":"2026-09-21T07:10:33","slug":"linux-foundation-kcna-practice-test-questions-and-exam-dumps-part20-q381-400","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcna-practice-test-questions-and-exam-dumps-part20-q381-400\/","title":{"rendered":"Linux Foundation KCNA Practice Test Questions and Exam Dumps Part20 Q381-400"},"content":{"rendered":"<h2><b>View Full <\/b><a href=\"https:\/\/www.examlabs.com\/kcna-exam-dumps\"><b>Linux Foundation KCNA Exam Dumps<\/b><\/a><b> and Practice Test Dumps.<\/b><\/h2>\n<p>&nbsp;<\/p>\n<h3><b>Question 381<\/b><\/h3>\n<p><b>Which Kubernetes command is commonly used to create or update resources from a YAML manifest?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl apply<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl logs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl describe<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl exec<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl apply command is commonly used to create or update Kubernetes resources from declarative configuration files. It compares the configuration being applied with the existing resource and works with Kubernetes to bring the resource toward the desired state. This approach is useful for managing applications through version-controlled YAML manifests. kubectl logs retrieves container logs, kubectl describe displays detailed resource information, and kubectl exec runs commands inside containers. Using kubectl apply supports the declarative management model that is central to Kubernetes operations.<\/span><\/p>\n<h3><b>Question 382<\/b><\/h3>\n<p><b>Which kubectl command provides detailed information about a Kubernetes resource, including events and configuration details?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl describe<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl apply<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl expose<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl describe command displays detailed information about a Kubernetes resource. For a Pod, for example, the output can include its node assignment, containers, conditions, volumes, and recent events. This makes describe especially useful when troubleshooting scheduling failures, container startup problems, and other operational issues. kubectl get provides a more concise resource view, apply creates or updates resources, and expose creates a Service for a resource. Administrators frequently use kubectl describe when more context is needed than a basic resource listing provides.<\/span><\/p>\n<h3><b>Question 383<\/b><\/h3>\n<p><b>Which kubectl command is commonly used to view output generated by a container in a Pod?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl logs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl events<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl output<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl inspect<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl logs command retrieves logs produced by containers running in Pods. It is commonly used when troubleshooting application errors, startup problems, or unexpected behavior. If a Pod contains multiple containers, the appropriate container can be selected with the relevant kubectl option. Logs are different from Kubernetes Events, which describe cluster-level or resource-related activities such as scheduling and image-pull failures. kubectl logs therefore provides direct access to application or container output and is one of the most frequently used troubleshooting commands.<\/span><\/p>\n<h3><b>Question 384<\/b><\/h3>\n<p><b>Which Kubernetes command can display recent events associated with resources in a Namespace?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl watch<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get events<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl history<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl inspect-events<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl get events command can display Kubernetes Events, which provide information about activities occurring within the cluster. Events can reveal useful details about scheduling failures, image-pull problems, container restarts, mounting issues, and other resource conditions. They complement commands such as kubectl describe and kubectl logs during troubleshooting. Application logs show output produced by containers, while Events describe Kubernetes-level actions and observations. Reviewing Events can therefore help identify why a resource is not behaving as expected.<\/span><\/p>\n<h3><b>Question 385<\/b><\/h3>\n<p><b>Which Kubernetes command can execute a command inside a running container?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl exec<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl enter<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl shell<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl run-command<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl exec command allows an administrator to execute a command inside a running container. It can be useful for troubleshooting application files, checking processes, testing connectivity, or inspecting the container environment. The command must target an appropriate running Pod and, when necessary, specify the container within a multi-container Pod. kubectl logs retrieves output, while kubectl describe displays resource information. Because exec provides direct access inside a workload, appropriate authorization and security practices should be followed.<\/span><\/p>\n<h3><b>Question 386<\/b><\/h3>\n<p><b>Which Kubernetes object is commonly used to expose an application externally through HTTP or HTTPS routing rules?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ingress<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Secret<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReplicaSet<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">An Ingress defines HTTP and HTTPS routing rules that can direct external requests toward Kubernetes Services. It can support host-based or path-based routing depending on the configuration and implementation. An Ingress resource itself requires an Ingress controller to actually process the defined rules and handle traffic. ConfigMaps store configuration, Secrets store sensitive data, and ReplicaSets maintain Pod replicas. Ingress is therefore commonly used when multiple web applications need organized HTTP or HTTPS routing through a shared entry point.<\/span><\/p>\n<h3><b>Question 387<\/b><\/h3>\n<p><b>What is required for an Ingress resource to actually process incoming HTTP or HTTPS traffic?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">An Ingress controller<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A ConfigMap only<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A PersistentVolume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">A ResourceQuota<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">An Ingress controller is required to implement the behavior described by an Ingress resource. The Ingress resource defines routing rules, while the controller watches those resources and configures the underlying proxy or load-balancing mechanism accordingly. Without an appropriate controller, an Ingress object may exist in the cluster without actually handling external traffic. ConfigMaps, PersistentVolumes, and ResourceQuotas serve different purposes. The separation between the Ingress API object and its controller allows different controller implementations to provide HTTP and HTTPS routing functionality.<\/span><\/p>\n<h3><b>Question 388<\/b><\/h3>\n<p><b>Which Service type is generally used when each Pod should be directly discoverable through individual DNS records instead of a single virtual IP?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NodePort<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LoadBalancer<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterIP<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Headless Service<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A headless Service is created by setting its clusterIP to None. Unlike a normal ClusterIP Service, it does not provide a single virtual IP for load balancing. Instead, DNS can return the individual addresses of the selected Pods. This behavior is particularly useful with StatefulSets, where applications may need to discover individual Pod identities. NodePort and LoadBalancer provide other exposure mechanisms, while a standard ClusterIP Service provides a virtual IP. Headless Services are therefore useful for direct Pod discovery and stateful application architectures.<\/span><\/p>\n<h3><b>Question 389<\/b><\/h3>\n<p><b>Which Kubernetes storage access mode indicates that a volume can be mounted as read-write by multiple nodes when supported by the storage system?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteOnce<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadOnlyMany<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteMany<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">SingleWriteOnly<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">ReadWriteMany, abbreviated RWX, indicates that a volume may be mounted with read-write access by multiple nodes, provided that the underlying storage system supports this access mode. This is useful for applications where multiple Pods across different nodes need to access the same persistent data. ReadWriteOnce generally allows read-write mounting by a single node, while ReadOnlyMany allows multiple nodes to mount a volume as read-only. The actual capabilities depend on the storage implementation and its CSI driver.<\/span><\/p>\n<h3><b>Question 390<\/b><\/h3>\n<p><b>Which Kubernetes storage access mode generally allows read-write mounting from a single node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteOnce<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteMany<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadOnlyMany<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">MultiWrite<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">ReadWriteOnce, or RWO, indicates that a persistent volume can generally be mounted as read-write by a single node at a time, depending on the storage implementation. Multiple Pods on that same node may potentially use the volume if the storage system supports that behavior. ReadWriteMany allows read-write access from multiple nodes, while ReadOnlyMany allows read-only mounting from multiple nodes. Access modes describe the supported mounting behavior of storage and should be selected according to the requirements of the application and capabilities of the storage provider.<\/span><\/p>\n<h3><b>Question 391<\/b><\/h3>\n<p><b>Which Kubernetes mechanism can restrict which Pods are allowed to use a particular node based on node characteristics?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Node affinity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service discovery<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Node affinity allows Pods to express placement requirements or preferences based on node labels. For example, a workload can require nodes with a particular operating system, hardware type, or geographic zone. Required affinity creates mandatory placement conditions, while preferred affinity expresses preferences that the scheduler attempts to satisfy. Service discovery handles network endpoint resolution, ConfigMaps store configuration, and ResourceQuotas control aggregate resource consumption. Node affinity is therefore a scheduling mechanism that helps workloads run on nodes with appropriate characteristics.<\/span><\/p>\n<h3><b>Question 392<\/b><\/h3>\n<p><b>Which Kubernetes feature is used to ensure that a Pod is not scheduled onto a node unless it tolerates a specific taint?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Toleration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ServiceAccount<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A toleration allows a Pod to tolerate a matching taint applied to a node. This means the taint does not automatically prevent the Pod from being considered for scheduling on that node. Tolerations are commonly used when nodes are reserved for specialized workloads such as infrastructure services or hardware-specific applications. A toleration does not force scheduling onto a particular node; other scheduling requirements still apply. ResourceQuota controls resource consumption, ConfigMap stores configuration, and ServiceAccount provides workload identity. Tolerations therefore work directly with node taints.<\/span><\/p>\n<h3><b>Question 393<\/b><\/h3>\n<p><b>Which Kubernetes object can provide a logical boundary for applying RBAC permissions and resource quotas to a group of resources?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Namespace<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReplicaSet<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Namespace provides logical organization for many Kubernetes resources and can be used as a scope for mechanisms such as RBAC permissions and ResourceQuotas. For example, an organization can separate development and production resources into different Namespaces and apply different access policies. Namespaces do not create separate physical clusters, and cluster-scoped resources can exist outside Namespace boundaries. PersistentVolumes provide storage, Services provide networking, and ReplicaSets maintain Pod replicas. Namespaces therefore provide an important organizational and administrative boundary within a Kubernetes cluster.<\/span><\/p>\n<h3><b>Question 394<\/b><\/h3>\n<p><b>Which Kubernetes concept describes the ability to run containers as isolated processes sharing the host kernel rather than requiring a separate guest operating system for each container?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Containerization<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Virtual machine migration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Bare-metal partitioning<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Network routing<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Containerization packages applications and their dependencies into isolated processes that generally share the host operating system kernel. This differs from traditional virtual machines, where each virtual machine typically includes its own guest operating system. Containers can provide efficient application isolation while using fewer resources than full virtual machines in many scenarios. Kubernetes uses containerized workloads as its fundamental application execution model. Containerization does not eliminate the need for security controls because containers share underlying kernel resources and must still be configured appropriately.<\/span><\/p>\n<h3><b>Question 395<\/b><\/h3>\n<p><b>Which cloud-native architecture approach commonly breaks an application into independently deployable services?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Monolithic-only architecture<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Microservices<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Single-process scheduling<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Static infrastructure<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Microservices architecture divides an application into smaller, independently deployable services that can communicate through defined interfaces. Each service can potentially be developed, deployed, and scaled independently according to its requirements. Kubernetes is commonly used to orchestrate microservices because it provides mechanisms for workload management, service discovery, configuration, scaling, and networking. Microservices can introduce additional operational complexity, such as distributed communication and observability requirements. Nevertheless, the architecture aligns well with Kubernetes&#8217; ability to manage multiple independently deployed workloads.<\/span><\/p>\n<h3><b>Question 396<\/b><\/h3>\n<p><b>Which observability signal primarily represents numerical measurements such as CPU utilization or request counts?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Metrics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Logs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Traces<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Manifests<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Metrics are numerical measurements collected over time and can represent values such as CPU utilization, memory consumption, request rates, latency, and error counts. They are useful for identifying trends, creating dashboards, and triggering alerts. Logs provide detailed event or application messages, while traces follow requests as they move through distributed components. Kubernetes environments commonly use multiple observability signals together because each provides different information about system behavior. Metrics therefore provide a quantitative view of workload and infrastructure performance.<\/span><\/p>\n<h3><b>Question 397<\/b><\/h3>\n<p><b>Which observability signal records timestamped textual or structured events generated by applications and infrastructure?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Traces<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Metrics<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Logs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Labels<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Logs record events and messages generated by applications, containers, and infrastructure components. They can contain error messages, startup information, request details, or diagnostic information. Logs are often represented as plain text or structured formats such as JSON. Metrics provide numerical measurements, while traces track the path of requests across distributed components. Labels are metadata used by Kubernetes resources and selectors. Reviewing logs is especially valuable when investigating application-level errors or understanding what occurred inside a container at a particular time.<\/span><\/p>\n<h3><b>Question 398<\/b><\/h3>\n<p><b>Which observability technique follows a request as it travels through multiple services in a distributed application?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Resource quotas<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Distributed tracing<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Container scheduling<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Image scanning<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Distributed tracing follows individual requests as they travel through multiple components of an application. A trace can contain spans representing operations performed by different services, allowing engineers to understand request paths and identify where latency or failures occur. This is particularly useful in microservices environments where a single user request may involve several independent services. Metrics provide aggregated numerical information, while logs provide event details. Distributed tracing complements those signals by showing relationships and timing across components in a distributed system.<\/span><\/p>\n<h3><b>Question 399<\/b><\/h3>\n<p><b>Which Kubernetes principle means that a workload should describe the state it wants rather than requiring every individual action to be manually specified?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Declarative configuration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Manual orchestration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Static addressing<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Imperative networking<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Declarative configuration allows users to describe the desired state of a Kubernetes resource rather than manually specifying every action needed to reach that state. Kubernetes controllers then continuously reconcile the actual cluster state toward the declared configuration. YAML manifests are commonly used to express this desired state, and tools such as kubectl apply can submit those definitions to the API. This model supports repeatability and automation because the same configuration can be applied consistently across environments while Kubernetes handles much of the operational reconciliation.<\/span><\/p>\n<h3><b>Question 400<\/b><\/h3>\n<p><b>Which Kubernetes design principle enables the platform to continuously correct differences between the desired state and the observed state?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Static provisioning<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reconciliation loops<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Manual intervention<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Fixed addressing<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Reconciliation loops are a fundamental Kubernetes design principle. Controllers continuously observe resources and compare their current state with the desired state defined through Kubernetes APIs. When differences are detected, controllers take actions intended to move the system toward the desired configuration. For example, if a Deployment requires five replicas and only four are running, the relevant controller can work to create another Pod. This continuous process provides self-healing and automation and is one of the core reasons Kubernetes can maintain declared application states over time.<\/span><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full Linux Foundation KCNA Exam Dumps and Practice Test Dumps. &nbsp; Question 381 Which Kubernetes command is commonly used to create or update resources from a YAML manifest? kubectl apply kubectl logs kubectl describe kubectl exec Correct Answer: 1 Explanation The kubectl apply command is commonly used to create or update Kubernetes resources from [&hellip;]<\/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\/17231"}],"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=17231"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17231\/revisions"}],"predecessor-version":[{"id":17232,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17231\/revisions\/17232"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=17231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=17231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=17231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}