I85PREP
⌘ K
Nutanix NCP-CN study materials
Nutanix NCP-CN study resources

Nutanix NCP-CN practice questions

One question at a time. Build your Nutanix NCP-CN understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

In Nutanix Kubernetes Platform (NKP), which component runs on each managed cluster and reconciles the cluster's actual state with the desired state declared in its Kubernetes objects?

  1. The kubelet on every node
  2. The control-plane controller manager Correct answer.
  3. The external load balancer
  4. The NKP management plane's cluster registry

Explanation

The controller manager hosts the built-in controllers that continuously compare observed cluster state against the declared spec and drive reconciliation. The kubelet only manages pods on its own node, while the NKP management plane orchestrates lifecycle rather than reconciling workloads inside the cluster.

Question 2Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which NKP cluster type is intended for long-lived production workloads and is typically managed through a declared, GitOps-friendly configuration?

  1. An ephemeral kind cluster
  2. A transient bootstrap cluster
  3. A managed cluster Correct answer.
  4. A local Docker-only cluster

Explanation

Managed clusters are the persistent workload clusters that NKP creates and tracks over their lifecycle, and their configuration is declarative so it can live in Git. Bootstrap and kind clusters are short-lived helpers used during creation.

Question 3Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

During NKP cluster creation, what is the role of the bootstrap cluster?

  1. It serves as the ingress gateway for all tenant traffic
  2. It stores etcd backups for the target cluster
  3. It permanently hosts the workload pods after creation
  4. It temporarily runs the Cluster API controllers that provision the target cluster Correct answer.

Explanation

NKP uses a temporary bootstrap cluster to run Cluster API and related controllers, which then create the infrastructure and Kubernetes components of the target cluster. Once the target cluster is up, management can be pivoted and the bootstrap cluster is discarded.

Question 4Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An administrator wants NKP to create worker nodes directly as virtual machines on AHV without pre-building node images by hand. Which capability should they rely on?

  1. The NKP CLI's offline bundle importer
  2. Manual node registration with preinstalled kubelet
  3. Static inventory files listing bare-metal MAC addresses
  4. Cluster API infrastructure providers for the target platform Correct answer.

Explanation

NKP builds on Cluster API, where infrastructure providers create and delete the machines that back cluster nodes on a given platform such as AHV. Manual registration and static inventories describe older, hand-managed approaches rather than provider-driven provisioning.

Question 5Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement best describes how the NKP management plane relates to the workload clusters it creates?

  1. It runs separately and tracks cluster objects to drive lifecycle operations Correct answer.
  2. It is optional and only needed for monitoring dashboards
  3. It must run inside every workload cluster as a DaemonSet
  4. It replaces the Kubernetes API server in each workload cluster

Explanation

The management plane is a separate control environment that holds the declarative records of managed clusters and performs lifecycle actions such as create, upgrade, and delete. It does not replace the workload cluster's own API server or run as a per-node agent.

Question 6Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

A platform team needs to upgrade the Kubernetes version of an NKP managed cluster. What is the recommended approach?

  1. Delete and recreate the cluster with a new installer ISO
  2. Patch the kubelet binary directly on each worker
  3. SSH into each node and run kubeadm upgrade manually
  4. Change the declared Kubernetes version in the cluster configuration and let NKP reconcile Correct answer.

Explanation

NKP lifecycle operations are declarative: updating the desired Kubernetes version in the cluster definition triggers the controllers to roll nodes through the upgrade. Manual kubeadm or binary patching bypasses reconciliation and is unsupported.

Question 7Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which object in an NKP-managed cluster represents the desired set of machines for a node pool and allows scaling by changing a replica count?

  1. A MachineDeployment Correct answer.
  2. A ServiceAccount
  3. A NetworkPolicy
  4. A PersistentVolumeClaim

Explanation

MachineDeployments are Cluster API objects that manage a group of Machines, and editing their replica count scales the node pool. PersistentVolumeClaims, NetworkPolicies, and ServiceAccounts govern storage, traffic, and identity respectively.

Question 8Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

What does the pivot step accomplish during NKP cluster creation?

  1. It converts worker nodes into control-plane nodes
  2. It rotates the cluster's TLS certificates
  3. It migrates persistent volumes between storage classes
  4. It moves management objects from the bootstrap cluster to the newly created cluster Correct answer.

Explanation

After the target cluster's control plane is healthy, NKP pivots the Cluster API management objects from the temporary bootstrap cluster to the new cluster so it manages itself. This lets the bootstrap environment be safely removed.

Question 9Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which NKP concept lets you define reusable, versioned defaults for cluster creation so multiple clusters share the same baseline configuration?

  1. A cluster profile or template Correct answer.
  2. A kubeconfig context
  3. A PodDisruptionBudget
  4. A Helm release hook

Explanation

NKP supports reusable cluster definitions or profiles that capture baseline settings such as Kubernetes version, networking, and node pools, which teams can apply consistently across clusters. Kubeconfig contexts, Helm hooks, and disruption budgets serve unrelated purposes.

Question 10Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which component in an NKP workload cluster is responsible for scheduling pods onto nodes based on resource requests and constraints?

  1. kube-proxy
  2. etcd
  3. CoreDNS
  4. kube-scheduler Correct answer.

Explanation

kube-scheduler watches for unscheduled pods and assigns them to nodes that satisfy resource requests, affinity, and taints. etcd stores state, kube-proxy programs service routing, and CoreDNS resolves names.

Question 11Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

A cluster administrator must remove a worker node from an NKP managed cluster cleanly. What should happen first?

  1. Power off the node and leave the object in place
  2. Cordon and drain the node so its pods are rescheduled Correct answer.
  3. Delete the node's etcd member immediately
  4. Remove the node's kubelet certificate only

Explanation

Cordoning marks the node unschedulable and draining evicts its workloads so they can be rescheduled elsewhere before the node is removed. Deleting etcd members applies to control-plane nodes and is not the first step for workers.

Question 12Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement accurately describes the difference between a control-plane node and a worker node in an NKP cluster?

  1. Control-plane nodes run the API server, scheduler, and etcd; workers run tenant workloads Correct answer.
  2. Control-plane nodes only run ingress controllers
  3. Worker nodes run etcd while control-plane nodes run application pods only
  4. Both node types run identical components with no role distinction

Explanation

Control-plane nodes host the components that make scheduling and state management possible, including the API server, scheduler, controller manager, and etcd. Worker nodes are where tenant application pods are scheduled.

Question 13Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An operator needs NKP to support a highly available control plane for a production cluster. Which configuration satisfies this requirement?

  1. Two control-plane nodes to keep costs low
  2. Three control-plane nodes with an odd-sized etcd cluster Correct answer.
  3. A single control-plane node with a large disk
  4. A control-plane node backed only by a snapshot

Explanation

Highly available control planes use an odd number of control-plane nodes, commonly three, so etcd can maintain quorum if one node fails. Even numbers provide no additional fault tolerance and can complicate quorum.

Question 14Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which NKP capability allows a cluster to be created on a cloud provider's infrastructure using that provider's native APIs for machines and networking?

  1. A manually built inventory spreadsheet
  2. Cloud infrastructure providers integrated with Cluster API Correct answer.
  3. A static kubeconfig file
  4. A local kind configuration

Explanation

NKP integrates cloud-specific Cluster API infrastructure providers so machines, networks, and load balancers are created through the provider's APIs. Static files and spreadsheets do not provision infrastructure automatically.

Question 15Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

What is the primary purpose of the NKP CLI in cluster lifecycle management?

  1. To generate and apply declarative cluster definitions and run lifecycle commands Correct answer.
  2. To compile container images for the cluster
  3. To act as the cluster's DNS resolver
  4. To replace kubectl for all in-cluster workload operations

Explanation

The NKP CLI helps operators create, inspect, upgrade, and delete clusters by generating and applying declarative configuration. It complements kubectl rather than replacing it for workload operations and does not build images or resolve DNS.

Question 16Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

A team wants to add more worker capacity to an existing NKP managed cluster without recreating it. Which action fits the declarative lifecycle model?

  1. Increase the replica count of the relevant MachineDeployment Correct answer.
  2. Change the cluster's DNS domain
  3. Create a second bootstrap cluster
  4. Reinstall the operating system on existing workers

Explanation

Scaling a node pool is expressed by increasing the MachineDeployment replica count, and the controllers create the additional machines. Reinstalling nodes, creating bootstrap clusters, or changing DNS do not add capacity through reconciliation.

Question 17Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement correctly describes how NKP handles the kubeconfig for a newly created managed cluster?

  1. NKP retrieves credentials so operators can access the cluster with kubectl Correct answer.
  2. The cluster has no API server until a user logs in
  3. Credentials are stored only inside etcd of the bootstrap cluster
  4. Kubeconfig is only available after the bootstrap cluster is deleted

Explanation

Once a managed cluster is created, NKP provides the credentials needed to connect to its API server, allowing operators to use kubectl or other clients. The API server exists independently of user login and is not tied to the bootstrap cluster's lifetime.

Question 18Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An administrator observes that a node pool's Machines remain in a provisioning state for a long time. Which area should be investigated first?

  1. The PodDisruptionBudget of tenant workloads
  2. The infrastructure provider's ability to create the underlying machines and networks Correct answer.
  3. The CoreDNS ConfigMap contents
  4. The cluster's ingress TLS certificate

Explanation

Machines stuck in provisioning usually indicate the infrastructure provider cannot create the VM or network resources, such as quota, credentials, or image issues. DNS, disruption budgets, and TLS certificates affect workloads after nodes exist.

Question 19Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which NKP lifecycle operation is best described as non-disruptive to running workloads when performed with proper surge settings?

  1. A rolling upgrade of worker nodes Correct answer.
  2. Deleting the cluster's etcd data
  3. Changing the cluster name in place
  4. Removing all control-plane nodes at once

Explanation

Rolling upgrades replace nodes incrementally, and with surge capacity the controllers create new nodes before removing old ones so workloads can be rescheduled. Deleting etcd data or removing all control-plane nodes simultaneously causes outages.

Question 20Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement about etcd in an NKP-managed cluster is accurate?

  1. It stores the cluster's Kubernetes objects and requires a quorum to accept writes Correct answer.
  2. It runs on every worker node by default
  3. It stores only container images for the nodes
  4. It is optional and can be removed in production

Explanation

etcd is the consistent key-value store holding Kubernetes objects, and writes require a majority quorum of members. It is essential in production and runs on control-plane nodes rather than every worker.

Question 21Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

A platform engineer wants to ensure cluster definitions are reviewed and version-controlled before being applied. Which practice best fits NKP's declarative lifecycle?

  1. Store cluster configuration in Git and apply it through a reviewed pipeline Correct answer.
  2. Edit node filesystems by hand after creation
  3. Make changes directly with ad hoc CLI flags on production
  4. Disable reconciliation to prevent drift

Explanation

Because NKP cluster definitions are declarative, keeping them in Git with review and automated application gives an auditable, repeatable lifecycle. Ad hoc changes and disabling reconciliation create drift from the declared state.

Question 22Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which component provides cluster DNS so that services can be reached by name inside an NKP workload cluster?

  1. CoreDNS Correct answer.
  2. The infrastructure provider
  3. The NKP CLI
  4. kube-scheduler

Explanation

CoreDNS runs in the cluster and resolves service and pod names to addresses. The scheduler places pods, the infrastructure provider creates machines, and the CLI manages lifecycle from outside.

Question 23Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

What happens to the bootstrap cluster after an NKP managed cluster is successfully created and management is pivoted?

  1. It is converted into a worker node pool
  2. It becomes the workload cluster's etcd backup target
  3. It can be safely deleted because the new cluster now manages itself Correct answer.
  4. It must remain forever to keep the workload cluster running

Explanation

After the pivot, the new cluster hosts the management objects, so the temporary bootstrap environment is no longer needed and can be removed. Keeping it running adds unnecessary overhead and is not required for the workload cluster.

Question 24Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which combination correctly pairs an NKP node role with the workload it typically runs?

  1. Worker nodes run the API server; control-plane nodes run ingress only
  2. Worker nodes run tenant application pods; control-plane nodes run cluster management components Correct answer.
  3. Control-plane nodes run tenant pods; worker nodes run etcd
  4. Both roles run only system pods and no tenant workloads

Explanation

Worker nodes are the scheduled home for tenant application pods, while control-plane nodes host the components that manage the cluster, including etcd and the API server. Taints usually keep tenant workloads off control-plane nodes.

Question 25Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An operator must decommission an entire NKP managed cluster. Which sequence best reflects a safe lifecycle?

  1. Delete the kubeconfig and assume infrastructure is reclaimed
  2. Remove the infrastructure provider credentials before deleting machines
  3. Delete etcd first, then power off nodes, then notify users
  4. Drain workloads, delete the cluster through NKP so infrastructure is cleaned up, then remove the bootstrap remnants Correct answer.

Explanation

A safe decommission drains or migrates workloads, then uses NKP to delete the cluster so the controllers remove the machines and infrastructure they created. Deleting etcd, revoking provider credentials early, or just dropping kubeconfig leaves orphaned resources.

Question 26Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

In NKP, which component runs on the management cluster and is responsible for reconciling Cluster API objects into the actual infrastructure and control-plane resources of managed clusters?

  1. The NKP management cluster's controllers, which watch Cluster API custom resources and drive reconciliation Correct answer.
  2. The kubelet on each worker node, which pulls cluster definitions directly from the management cluster
  3. The container network interface plugin, which translates Cluster API objects into pod networking rules
  4. The NKP CLI binary on the administrator workstation, which continuously polls and applies desired state

Explanation

In the NKP architecture, the management cluster hosts the Cluster API and provider controllers that watch custom resources such as Cluster and MachineDeployment and reconcile them into real infrastructure and control-plane objects. The CLI is an imperative entry point, not a continuous reconciler, and node-level or CNI components do not interpret Cluster API objects.

Question 27Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An administrator wants to inspect the Cluster API resources that describe an NKP managed cluster from the management cluster's perspective. Which action retrieves those objects?

  1. Run kubectl against the management cluster context and list the Cluster and Machine resources in the relevant namespace Correct answer.
  2. Run kubectl against the workload cluster and list Pods in the kube-system namespace
  3. Open a shell on a worker node and read the kubelet configuration file
  4. Query the workload cluster's etcd directly with etcdctl to dump all keys

Explanation

Managed cluster definitions live as Cluster API custom resources on the management cluster, so they are visible through kubectl using the management cluster context and the namespace where the cluster was created. Workload-cluster queries show only the resulting Kubernetes objects, not the declarative Cluster API definitions.

Question 28Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement best describes the role of the management cluster during the lifetime of NKP managed clusters?

  1. It runs application workloads on behalf of all managed clusters to reduce duplication
  2. It hosts the controllers and stored definitions used to create, monitor, and update the managed clusters it owns Correct answer.
  3. It only exists during creation and is destroyed immediately after the first managed cluster becomes ready
  4. It acts purely as a DNS forwarder for the workload clusters it manages

Explanation

The management cluster persists after creation and continues to host the Cluster API controllers plus the custom resources that represent each managed cluster, which is what enables later scaling, upgrades, and health monitoring. It is not a transient bootstrap artifact, nor does it host tenant workloads or serve only DNS.

Question 29Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

During NKP cluster creation, what is the purpose of the temporary bootstrap cluster?

  1. It permanently stores the kubeconfig and credentials for every managed cluster in the environment
  2. It provides the container registry that serves images to the new workload nodes
  3. It runs the production workloads until the new cluster is declared ready
  4. It hosts the initial Cluster API controllers that create the new cluster's control plane before management moves to the new cluster Correct answer.

Explanation

NKP starts with a short-lived bootstrap cluster, often on a local Docker provider, so the Cluster API controllers have a place to run while they provision the real control plane. Once the new cluster's control plane is healthy, management is pivoted to it and the bootstrap cluster is no longer needed.

Question 30Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

A platform engineer wants to declare an NKP managed cluster in a Git repository and have the definition applied reproducibly. Which NKP lifecycle approach fits this requirement?

  1. Manually SSH into each node and run kubeadm join commands in sequence
  2. Use the cloud provider console to click through a virtual machine creation wizard for each node
  3. Author a declarative cluster manifest and apply it with the NKP CLI or kubectl so the management cluster reconciles it Correct answer.
  4. Copy an existing cluster's etcd snapshot onto new machines and restart the API server

Explanation

NKP cluster definitions are declarative Kubernetes resources, so storing them in Git and applying them through the CLI or kubectl gives repeatable, reviewable lifecycle operations driven by the management cluster's controllers. Manual node joins, console clicking, and etcd snapshot copying bypass the declarative model and are not supported lifecycle methods.

Question 31Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement correctly describes how an NKP management cluster tracks the health and status of a managed cluster's machines?

  1. Each machine writes a status file to a shared NFS export that administrators read manually
  2. Machine objects report phase and conditions that the management cluster surfaces for each node pool Correct answer.
  3. Health is inferred only from ping responses sent by the NKP CLI during interactive sessions
  4. Machine health is tracked exclusively inside the workload cluster's scheduler logs

Explanation

Cluster API Machine objects carry status fields such as phase and conditions, and the management cluster aggregates them so operators can see provisioning progress and node-pool health. This status is part of the API surface, not a file share, a CLI ping, or scheduler log parsing.

Question 32Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An operator needs to change the instance type used by future worker nodes in an existing NKP managed cluster while keeping current nodes running. Which approach aligns with NKP lifecycle practices?

  1. Edit the existing Machine objects in place to change their instance type field
  2. Change the kubelet flags on running nodes so they report a different instance type
  3. Create a new node pool with the desired instance type and scale down the old pool after workloads migrate Correct answer.
  4. Delete the management cluster and recreate every managed cluster from scratch

Explanation

Node pools are the unit of machine configuration in NKP, so a new pool with the target instance type is added and the old pool is drained and scaled down as workloads reschedule. Machine objects are immutable in the fields that define provisioning, and kubelet flags cannot change underlying infrastructure.

Question 33Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which NKP concept describes the set of machines that back a single Kubernetes node pool and enables rolling replacement of those machines?

  1. A PersistentVolumeClaim, which reserves storage for stateful workloads
  2. A NetworkPolicy, which restricts traffic between node pools
  3. A MachineDeployment, which manages a ReplicaSet-like set of Machines and performs rolling updates Correct answer.
  4. A DaemonSet, which ensures one pod runs on every node in the cluster

Explanation

In the Cluster API model used by NKP, a MachineDeployment owns a set of Machines for a node pool and rolls them out with surge and replacement semantics. DaemonSets, PersistentVolumeClaims, and NetworkPolicies are workload-level Kubernetes objects unrelated to machine lifecycle.

Question 34Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

What does the NKP CLI's cluster creation flow require before it can provision infrastructure for a new managed cluster?

  1. A prebuilt container image of the workload application pushed to every node
  2. A manually created etcd cluster running outside of Kubernetes
  3. An existing workload cluster to act as a template for the new one
  4. A configured infrastructure provider and its credentials available to the management cluster Correct answer.

Explanation

NKP needs an infrastructure provider, such as a cloud or on-premises provider, with valid credentials so its controllers can create the machines and networks for the new cluster. The application image and any template cluster are not prerequisites, and etcd is provisioned as part of the control plane.

Question 35Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An administrator wants to retrieve the kubeconfig for a newly created NKP managed cluster in order to run kubectl against it. Which approach is consistent with NKP lifecycle tooling?

  1. Extract the kubeconfig from a worker node's /etc/kubernetes directory over SSH
  2. Read the kubeconfig from the bootstrap cluster's etcd before the bootstrap cluster is deleted
  3. Regenerate the kubeconfig by reinstalling the CNI plugin on the workload cluster
  4. Use the NKP CLI to fetch the cluster's kubeconfig and merge it into the local kubeconfig file Correct answer.

Explanation

The NKP CLI can retrieve the kubeconfig for a managed cluster and merge it into the administrator's local configuration, which is the supported way to obtain credentials. The bootstrap cluster is ephemeral and not a credential source, and node files or CNI reinstallation are not lifecycle mechanisms for kubeconfig retrieval.

Question 36Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement about the relationship between an NKP management cluster and the workload clusters it manages is accurate?

  1. Each workload cluster requires its own dedicated management cluster that can never manage another cluster
  2. A single management cluster can own multiple managed clusters, each isolated in its own namespace with its own Cluster API objects Correct answer.
  3. Workload clusters must be deleted before the management cluster can create another one
  4. A management cluster can only manage clusters that run on the same physical host as itself

Explanation

NKP management clusters are designed to manage many workload clusters, with each cluster's Cluster API objects typically scoped to a namespace for isolation. There is no one-to-one requirement, no same-host restriction, and no need to delete existing clusters before creating new ones.

Question 37Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which component inside an NKP workload cluster is responsible for persisting the cluster's API objects and serving as the source of truth for the control plane?

  1. The node-problem-detector daemonset that reports node conditions
  2. The CoreDNS pods that resolve service names for workloads
  3. The kube-proxy instances that program service routing rules on each node
  4. The etcd members that form the control plane's key-value store Correct answer.

Explanation

etcd stores the workload cluster's API objects and is the authoritative datastore behind the API server. Kube-proxy, CoreDNS, and node-problem-detector are supporting components that consume API data rather than persist it.

Question 38Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

A team must guarantee that an NKP workload cluster's control plane survives the loss of a single control-plane node. Which configuration satisfies this requirement?

  1. Three control-plane nodes so that etcd maintains quorum with one member unavailable Correct answer.
  2. Two control-plane nodes so that either member can serve alone
  3. Three worker nodes with the control-plane role added only during maintenance
  4. One control-plane node with frequent etcd snapshots for recovery

Explanation

etcd requires a majority quorum, so a three-member control plane tolerates one failed member while two remain to form quorum. Two members cannot tolerate one loss because quorum would drop below two, and a single control-plane node has no redundancy at all.

Question 39Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

Which statement accurately characterizes the NKP CLI's relationship to the management cluster's API?

  1. The CLI bypasses the API and writes directly to the management cluster's etcd
  2. The CLI replaces the management cluster's controllers by performing provisioning itself
  3. The CLI authenticates to the management cluster and creates or modifies API objects that controllers then act upon Correct answer.
  4. The CLI operates only offline and produces manifests that must be applied by a separate tool

Explanation

The NKP CLI is a client of the management cluster's Kubernetes API: it authenticates, submits declarative objects, and lets controllers perform the actual work. Writing directly to etcd is never the supported path, and the CLI is not a substitute for controllers.

Question 40Nutanix Kubernetes Platform (NKP) architecture and cluster lifecycle

An operator plans to upgrade the Kubernetes version of an NKP managed cluster and wants to understand what happens to worker machines during the rollout. Which behavior should be expected?

  1. Worker machines are replaced in a rolling fashion according to the node pool's rollout strategy, with surge where configured Correct answer.
  2. All worker machines are deleted at once and recreated after the control plane finishes upgrading
  3. Worker machines keep their original kubelet version permanently and are never replaced
  4. Worker machines are upgraded only when an administrator manually edits each Machine object

Explanation

Node pools roll out version changes by replacing machines according to the MachineDeployment strategy, and surge settings control how many extra machines exist during the rollout. Simultaneous deletion of all workers, permanent version skew, and manual per-machine edits are not how NKP performs upgrades.

Question 41Kubernetes networking and load balancing with Nutanix

In a Nutanix Kubernetes environment, which component is responsible for programming load-balancer VIPs and node routes when a Service of type LoadBalancer is created?

  1. The etcd leader
  2. The kubelet on each worker node
  3. The cloud-controller-manager using the Nutanix CCM integration Correct answer.
  4. The CoreDNS pod in kube-system

Explanation

The cloud-controller-manager watches Services of type LoadBalancer and programs the underlying infrastructure. On Nutanix this is handled by the Nutanix cloud provider/CCM integration, which allocates and advertises the VIP. kubelet, CoreDNS, and etcd do not provision external load-balancer addresses.

Question 42Kubernetes networking and load balancing with Nutanix

Which Kubernetes Service type exposes an application on a cluster-internal IP reachable only from inside the cluster?

  1. ClusterIP Correct answer.
  2. NodePort
  3. ExternalName
  4. LoadBalancer

Explanation

ClusterIP is the default Service type and allocates a virtual IP reachable only from within the cluster network. NodePort and LoadBalancer additionally expose the Service outside the cluster, and ExternalName maps to a DNS CNAME without a cluster IP.

Question 43Kubernetes networking and load balancing with Nutanix

What is the primary role of a CNI plugin in a Kubernetes cluster?

  1. Scheduling pods onto nodes based on resource requests
  2. Encrypting etcd traffic between control-plane nodes
  3. Managing persistent volume claims for stateful workloads
  4. Providing pod networking, including IP address management and pod-to-pod connectivity Correct answer.

Explanation

The Container Network Interface plugin supplies the pod network: it assigns pod IPs and programs the dataplane so pods can communicate across nodes. Scheduling, storage, and control-plane encryption are handled by other components.

Question 44Kubernetes networking and load balancing with Nutanix

A Service selects pods using its selector, but the endpoints list is empty. Which cause should be investigated first?

  1. The pod labels do not match the Service selector Correct answer.
  2. The CNI plugin has not been installed on the nodes
  3. The kube-proxy mode is set to ipvs
  4. The Service has no external IP assigned

Explanation

Endpoints are populated only for pods whose labels match the Service selector and that are Ready. A label mismatch, or pods failing readiness, is the most common reason for an empty endpoint list. Missing CNI or proxy mode affects connectivity but not endpoint population.

Question 45Kubernetes networking and load balancing with Nutanix

Which DNS name format resolves a Service named payments in namespace finance from a pod in another namespace?

  1. payments.svc.finance.cluster.local
  2. payments.cluster.local.finance.svc
  3. payments.finance.svc.cluster.local Correct answer.
  4. finance.payments.svc.cluster.local

Explanation

Kubernetes DNS uses the form <service>.<namespace>.svc.<cluster-domain>, so payments in finance resolves as payments.finance.svc.cluster.local. The namespace appears after the service name and before svc.

Question 46Kubernetes networking and load balancing with Nutanix

What does a Kubernetes Ingress resource require to actually route external HTTP traffic to Services?

  1. A StorageClass bound to the Ingress object
  2. A StatefulSet backing the Ingress
  3. A NetworkPolicy allowing port 443
  4. An Ingress controller running in the cluster Correct answer.

Explanation

An Ingress object is only a set of routing rules; an Ingress controller must be deployed to watch those rules and configure a proxy or load balancer. Without a controller the rules have no effect.

Question 47Kubernetes networking and load balancing with Nutanix

Which component on each node programs iptables or IPVS rules so that traffic to a ClusterIP is forwarded to a backing pod?

  1. kube-scheduler
  2. kubelet
  3. kube-proxy Correct answer.
  4. cloud-controller-manager

Explanation

kube-proxy watches Service and EndpointSlice objects and programs the node dataplane, using iptables or IPVS depending on configuration, to direct ClusterIP traffic to pods. The scheduler, kubelet, and CCM serve different roles.

Question 48Kubernetes networking and load balancing with Nutanix

What is the purpose of an EndpointSlice in a Kubernetes cluster?

  1. To define DNS zones served by CoreDNS
  2. To scale the number of replicas for a Deployment
  3. To store the TLS certificates used by Ingress resources
  4. To track the network addresses of pods backing a Service in a scalable way Correct answer.

Explanation

EndpointSlices group the addresses of pods backing a Service, replacing the older single Endpoints object for scalability. They are consumed by kube-proxy and other dataplane components to route Service traffic.

Question 49Kubernetes networking and load balancing with Nutanix

A team wants pods in namespace dev to accept traffic only from pods in namespace prod on TCP 8080. Which resource enforces this?

  1. A PodDisruptionBudget on the dev pods
  2. A NetworkPolicy in the dev namespace selecting the pods and allowing ingress from prod on port 8080 Correct answer.
  3. A ResourceQuota in the dev namespace
  4. An Ingress rule with a host-based route

Explanation

NetworkPolicy is the Kubernetes object that filters pod traffic; an ingress rule with a namespaceSelector for prod and a port of 8080 permits exactly that traffic. ResourceQuota, Ingress, and PodDisruptionBudget do not filter pod-to-pod packets.

Question 50Kubernetes networking and load balancing with Nutanix

What happens to a NetworkPolicy that selects a pod when its policyTypes field includes Ingress but the ingress rules list is empty?

  1. All ingress traffic to the selected pod is allowed
  2. The policy is ignored because no rules are defined
  3. Only traffic from the same namespace is allowed
  4. All ingress traffic to the selected pod is denied Correct answer.

Explanation

Once a pod is selected by a NetworkPolicy that lists Ingress in policyTypes, ingress is default-deny for that pod; an empty rules list therefore blocks all inbound traffic. Traffic is only allowed by explicit rules.