Nutanix NCP-CN common mistakes
Nutanix NCP-CN · Understand the traps and how to avoid them.
Treating NKP as a single appliance-style cluster and assuming the management cluster also runs tenant workloads by default, instead of planning a dedicated management cluster plus separate workload clusters.
Candidates carry over habits from single-cluster Kubernetes distributions and from Nutanix AHV cluster thinking, so they miss that NKP separates the management plane (lifecycle, identity, policy) from the workload clusters it creates and manages, and they mis-answer questions about where Cluster API objects, Kommander-style policy, and workspace resources actually live.
What to do instead
Draw the NKP object hierarchy explicitly before answering: management cluster, workspaces/projects, target workload clusters, and the per-cluster addons. For each lifecycle question, state which cluster performs the action and which credential (management kubeconfig vs workload kubeconfig) is used. Practice the create-attach-upgrade-delete flow for a workload cluster and note which steps run on the management cluster.
Answering cluster upgrade questions as if all nodes drain and reboot simultaneously, and forgetting that NKP upgrades control plane and worker node pools in a rolling, surge-style sequence tied to the underlying Nutanix node/VM infrastructure.
The lifecycle domain blends Kubernetes version skew rules with Nutanix AHV operations, and candidates who only know vanilla kubeadm upgrades overlook that NKP also manages the OS image, the node pool abstraction, and the interaction with AHV host resources and maintenance mode.
What to do instead
Memorize the ordering: control plane first, then worker node pools, one node at a time with rescheduling, respecting PodDisruptionBudgets. Link it to AHV: a node is a VM, so host maintenance mode requires the VM to be live-migrated or evacuated, and capacity must exist for surge nodes. Rehearse a version-skew table (kubelet vs API server) and the pre-upgrade checks NKP runs.
Assuming Kubernetes LoadBalancer Services get an address automatically, without identifying which load balancer implementation was selected at cluster creation and whether it is MetalLB in L2 or BGP mode, or a Nutanix-native integration.
In on-premises Kubernetes there is no cloud provider to allocate external IPs, so the answer depends entirely on the addon and its address pool configuration. Candidates who only studied cloud-managed Kubernetes expect an automatic IP and pick answers that skip pool or peering configuration.
What to do instead
For every load balancing question, first name the implementation and its address source. In MetalLB L2 mode, one node advertises the VIP via ARP/NDP, so traffic is not truly balanced across nodes; BGP mode requires a peering with the upstream router and advertises /32 routes. Verify the pool does not overlap the node or pod CIDR, and check that the chosen mode is reachable from outside the AHV network.
Planning pod and service CIDRs that overlap the corporate network or the Prism Central/AHV management subnet, then discovering routing and NAT problems after deployment.
Candidates treat CIDR selection as a formality and do not model the traffic path: pods on AHV VMs must reach Prism Central, DNS, NTP, and the Nutanix API endpoints, and overlapping ranges break that path or force NAT that hides pod identity.
What to do instead
Before answering, sketch three ranges: node network, pod CIDR, service CIDR, and confirm none overlap each other or any routed corporate or Nutanix management range. Remember that service CIDRs are virtual and only need to be unique, while pod CIDRs must be routable or NATed to reach external services. Where overlay networking is used, confirm MTU accounts for encapsulation overhead.
Assuming a PersistentVolumeClaim will bind automatically after installing the Nutanix CSI driver, without checking that a StorageClass exists, is defaulted, and references a valid storage container and Prism Element/Prism Central endpoint with correct credentials.
The CSI driver and the StorageClass are separate objects, and the Nutanix CSI driver needs a secret containing Prism credentials plus a storage container or volume group name. Candidates conflate driver installation with storage provisioning and miss questions about Pending PVCs.
What to do instead
Diagnose Pending PVCs in order: is there a StorageClass, is it annotated default, does it name an existing storage container, does the CSI secret exist in the right namespace with valid Prism credentials, and do the CSI controller and node plugins have healthy pods. Know which parameters (storage container, file system type, volume group, QoS) are set at StorageClass level versus per PVC.
Confusing Nutanix Volumes (iSCSI block volumes presented to guests) with Nutanix Files and with the CSI provisioned volumes, and therefore choosing the wrong access mode or the wrong product for a shared-read requirement.
All three are Nutanix storage offerings reachable from Kubernetes, and the CSI driver can provision both block-backed volumes and file-backed shares depending on configuration. Candidates who memorize product names without access semantics pick ReadWriteMany where only ReadWriteOnce is possible, or vice versa.
What to do instead
Anchor on access mode: block volumes via CSI are typically ReadWriteOnce (a single node attaches the volume), while shared filesystem access requires a file-based StorageClass or a Nutanix Files share. For raw block or iSCSI presented volumes, remember the guest initiator and the need to allow the client IQN or subnet. Build a small table of product, protocol, access mode, and typical Kubernetes use case.
Treating NDB as a backup tool only, and missing that it provisions and manages database instances (clone, snapshot, log capture, Time Machine, patching) across engines, with the clone workflow being the most exam-relevant behaviour.
Candidates skim NDB because it looks like a DBA product, then cannot answer questions about how a thin clone is created from a snapshot plus log replay, or what a Time Machine policy actually protects.
What to do instead
Learn the NDB object chain: registered cluster or instance, database server VM, Time Machine, snapshot plus transaction log capture, and clone. Be able to explain that a point-in-time clone replays logs onto a snapshot to reach an arbitrary timestamp, that clones are space-efficient, and that patching and refresh are separate operations from backup retention.
Assuming NC2 is simply a replication target, and failing to distinguish extending a Nutanix cluster into a public cloud from running native cloud services alongside it, including which component provides networking back to on-premises.
NC2 is marketed as hybrid cloud, and candidates collapse it into DR replication or into a VPN-only story. They then miss questions about the NC2 portal, the cluster running on cloud bare metal or nested virtualization, and the role of the transit gateway or VPN for stretched L2 and Prism Central visibility.
What to do instead
Separate the layers: NC2 deploys a real Nutanix cluster on cloud infrastructure, managed through the NC2 portal, with Prism Element and Prism Central running in the cloud; connectivity to on-premises is a networking decision (VPN or dedicated interconnect), and the cloud cluster is a peer, not a passive replica. For each scenario, ask whether the requirement is extension, migration, or DR, because the answer changes.
Answering observability questions by naming only Prometheus and Grafana, without stating what is scraped, where metrics are stored, and how Kubernetes and Nutanix infrastructure signals are correlated.
The exam expects awareness of both the Kubernetes monitoring stack and the Nutanix-side telemetry (Prism, NCC health checks, alerts), and candidates who stop at tool names cannot answer questions about retention, alert routing, or why a pod-level metric does not explain an AHV host-level cause.
What to do instead
For each observability question, identify the signal source (kubelet and cAdvisor, kube-state-metrics, node exporter, application endpoints, Prism/NCC), the storage and retention of that signal, and the alert path. Practice correlating a symptom across layers: pod eviction may be caused by node pressure, which may be caused by AHV host memory contention visible in Prism.
Designing backup and DR for cloud-native workloads as either Velero alone or storage replication alone, without covering both the Kubernetes object state and the persistent data, and without stating the RPO/RTO each mechanism delivers.
Velero backs up API objects and optionally volume snapshots, while Nutanix snapshots and replication protect the underlying storage; candidates pick one and miss the gap, for example restoring objects but not PVC data, or replicating volumes but losing the namespace and secret definitions.
What to do instead
Pair the mechanisms explicitly: Velero (or equivalent) for namespace-scoped objects plus CSI volume snapshots for data, and Nutanix protection domains or async replication for infrastructure-level DR of the volumes and VMs. For each design, state what is protected, the recovery point, the recovery time, and the restore order (storage first, then objects, then verify PVC binding and application consistency).