Domain 1: Prepare the Environment for an NKP Deployment
- Seeding a private registry copies the container images NKP needs into a registry inside your network, which is what makes an air-gapped installation possible. Without it, cluster components try to pull from the internet and the deployment stalls with image pull failures.
- The seeding command needs the registry URL, credentials and the air-gapped image bundle for the matching NKP version. A version mismatch between the bundle and the NKP CLI is a common cause of missing images later in the install.
- The registry must be reachable from every node that will pull images, and it needs valid TLS or an explicitly trusted certificate. Registry problems usually surface as pod image pull errors rather than as registry errors, so check from a node rather than from your workstation.
- A bootstrap cluster is a temporary local Kubernetes cluster - a KIND cluster on the host - that runs the Cluster API controllers long enough to create the real management cluster. It exists because something has to create the first cluster.
- Once the management cluster is up, its Cluster API resources are moved from the bootstrap cluster into it and the bootstrap cluster is deleted. That pivot is why the bootstrap cluster is disposable and why losing it after the pivot does not matter.
- Bootstrap creation needs a working container runtime on the host and the right NKP CLI version. Export the bootstrap kubeconfig to a file when you need to inspect Cluster API resources while a deployment is failing.
- NKP has three licence tiers - Starter, Pro and Ultimate - and they differ by feature set and scale rather than by support alone. Fleet management across many clusters and multi-cluster capabilities sit at the higher tiers.
- Match the tier to the use case rather than to the budget: a single cluster with basic platform applications is Starter territory, while centralised management of many clusters, multi-tenancy and the fuller platform application set require Pro or Ultimate.
- A bastion host is the jump point into an otherwise isolated environment, and in an air-gapped install it is where the NKP CLI, the image bundles and the registry access live. Its network reach determines what the installation can touch.
- The bastion needs the NKP CLI, a container runtime, connectivity to the target provider API and to the private registry, and SSH access to the nodes in a pre-provisioned deployment. Missing any one of those blocks the install at a predictable point.
- Machine images are built with the Nutanix Image Builder (NIB) for Nutanix targets and the Konvoy Image Builder (KIB) for preparing nodes on other providers. They bake the operating system, container runtime and Kubernetes components into an image so nodes come up ready.
- Building an image in an air-gapped environment needs the offline package bundle, because the build normally downloads packages from the internet. Preparing the bundle in advance is part of the air-gapped workflow rather than an optimisation.
- Customise images through the builder's overrides - additional packages, FIPS mode, a specific Kubernetes version, or organisational hardening - rather than by modifying nodes after they boot, which does not survive scaling or replacement.
- Before building a cluster on any provider, gather the same three families of information: networking (subnets, address ranges, DNS, load balancer or virtual IP), connectivity details (provider endpoint and credentials), and storage (the storage container or class and its capacity).
- Each target provider has its own prerequisites - Nutanix with Prism Central and a storage container, vSphere with a template and resource pool, AWS or AKS with their own identity and networking. Know what changes per provider and what stays the same.
- Check the resource requirements and supported operating systems before deploying rather than after. Undersized control plane nodes and an unsupported OS both produce failures that look like unrelated component errors.
Domain 2: Manage Building an NKP Cluster
- Deploy a cluster with the NKP CLI, which drives Cluster API under the hood. The CLI parameters describe the control plane and worker counts, machine sizes, networking, registry and provider credentials for the target you are deploying to.
- Cluster API is the machinery NKP builds on. A Cluster resource represents the cluster, MachineDeployments manage groups of worker nodes, and provider-specific resources describe the infrastructure. Customisation means adjusting those resources rather than the nodes themselves.
- Generate a manifest rather than deploying directly when the cluster needs customisation beyond the CLI flags: produce the YAML with a dry run, edit the Cluster API resources, then apply it. That is the supported route to a non-default topology.
- Diagnose a failing deployment by working down the Cluster API chain: the Cluster resource, then the control plane and MachineDeployment, then individual Machines, then the provider-specific resources. The first resource that is not Ready tells you which layer is at fault.
- Machines stuck in Provisioning point at infrastructure - credentials, quota, image availability, network reachability. Machines that provision but never become Ready point at bootstrapping - the image, the registry, or the node being unable to reach the control plane endpoint.
- Check the controller logs in the bootstrap or management cluster when the resources themselves give no reason. The Cluster API and provider controllers report the actual API error from the target platform, which the resource status often summarises too briefly.
- Kommander is the management layer that provides the dashboard, workspaces, projects, platform applications and fleet management. NKP without Kommander is a Kubernetes cluster; Kommander is what makes it a managed platform.
- Install Kommander onto the management cluster with the NKP CLI after the cluster is running. It is a separate step, and a management cluster that exists without Kommander is a normal intermediate state rather than a failure.
- Customise Kommander with a configuration file that selects which platform applications are enabled and how they are configured, which is how you install into a smaller environment or disable applications you do not want.
- Apply the NKP licence after installation through the dashboard or the CLI. Features gated by tier do not appear until the licence is applied, so a missing capability is worth checking against the licence before treating it as a bug.
- Kommander deployment problems are usually resources or storage: platform applications need sufficient CPU and memory across the cluster and a working default storage class, and they stay in a pending state when either is missing.
- Diagnose Kommander by looking at the platform application resources and the pods in their namespaces. A single application failing to reconcile can leave the whole installation reported as not ready while everything else is fine.
- Small environments need explicit configuration rather than the defaults, because the default platform application set assumes capacity that a minimal cluster does not have. Installing into a small environment is a documented path, not an improvisation.
Domain 3: Perform Day 2 Operations
- Configure an external identity provider - LDAP, Active Directory or an OIDC provider - so people sign in with existing credentials and group membership drives access. Local accounts are for bootstrapping, not for running an environment.
- Distinguish Kommander roles from cluster roles. Kommander roles govern access to the management plane - workspaces, projects and their resources - while Kubernetes cluster roles govern access to objects inside a cluster. A user can legitimately have one without the other.
- Role bindings apply a role to a user or group at a scope, and roles inherit downwards: a grant at the workspace level applies to the clusters and projects within it. Granting at too high a scope is the usual cause of unintended access.
- Create custom roles when the built-in ones do not fit, following least privilege. Bind them to groups from the identity provider rather than to individuals, so joiners and leavers are handled by group membership.
- Service account tokens authenticate automation rather than people. Scope them tightly and rotate them, and never reuse an administrative token for a pipeline that only needs to read.
- The logging stack collects logs from cluster components and workloads into a central store, built on the logging operator with Loki and Grafana. It is enabled as a platform application rather than installed separately.
- Multi-tenant logging keeps each workspace or project able to see only its own logs, which is what makes a shared platform acceptable to separate teams. Configure it deliberately rather than assuming isolation.
- Persist logs to external storage - Nutanix Unified Storage or S3-compatible object storage - because retaining them on cluster volumes limits retention and makes the data as fragile as the cluster. Scale the logging stack for volume rather than letting it drop data.
- Back up clusters with Velero, which captures Kubernetes resources and, with volume snapshot classes configured, the persistent volume data as well. A backup without a working snapshot class captures the objects and not the data, which is the most damaging misconfiguration here.
- Velero needs an object storage target and credentials before it can back anything up. Schedule backups rather than relying on manual runs, and set retention so old backups expire.
- Test restores rather than assuming them. A restore recreates resources into the cluster and can be scoped by namespace or label, and the time to discover that a backup was incomplete is not during an incident.
- The monitoring stack is Prometheus, Grafana and Alertmanager delivered as platform applications, with dashboards for cluster and workload health. Enable it per cluster or centralise it.
- Centralised metrics aggregate from many clusters into the management cluster so a fleet can be observed in one place, which is the multi-cluster answer rather than visiting each cluster's own Grafana.
- Customise service- and system-level metrics with ServiceMonitors and custom dashboards, and configure alert rules with notification endpoints. Configure backend storage for the monitoring application so metric history survives a pod restart.
- Cluster autoscaling adds and removes worker nodes based on pending pods, so capacity follows demand instead of being provisioned for the peak. It is configured per node pool with minimum and maximum counts, and it is provider-specific in how it creates nodes.
- Autoscaling reacts to pods that cannot be scheduled, so pods with no resource requests never trigger it. Setting requests correctly is a prerequisite for autoscaling to work at all.
- Upgrade in the supported order and check prerequisites first: the management cluster before the clusters it manages, and NKP itself before the Kubernetes version where the documentation requires it. Air-gapped upgrades additionally need the new image bundle seeded in advance.
- Manage node pools as the unit of capacity and configuration: add a pool with different machine sizes for a particular workload, scale a pool manually where autoscaling is not enabled, and replace nodes by updating the pool rather than editing nodes.
- Delete clusters with the NKP CLI so the Cluster API resources and the underlying infrastructure are both removed. Deleting virtual machines directly on the provider leaves orphaned Cluster API resources and infrastructure behind.
Domain 4: Conduct NKP Fleet Management
- A workspace is the fleet-management boundary in Kommander: it groups clusters that share access control, platform applications and configuration. It is how a platform team gives one business unit its own slice of the fleet.
- Assign a workload cluster to a workspace by what it shares with the other clusters in it - the same tenant, the same environment, the same platform applications - because everything configured at the workspace level applies to all of them.
- Configure access control at the workspace level so a group has rights across every cluster in the workspace without being granted anything on the management cluster or on other workspaces.
- Infrastructure providers are configured per workspace with the credentials for the target platform, which is what lets clusters be created into it. A workspace with no infrastructure provider can attach existing clusters but cannot provision new ones.
- Workspace applications are platform applications enabled across the workspace, so a capability such as logging or monitoring is deployed consistently to every cluster in it, with the option to enable an application per cluster where it is not wanted everywhere.
- Insights surfaces recommendations and detected issues across the fleet - configuration problems, known issues, things worth acting on - which is the fleet-scale answer to a question about proactively finding problems.
- Deploying a workload cluster to a workspace creates a new managed cluster into that workspace, using its infrastructure provider. The provider environment determines the parameters and the prerequisites, but the workspace determines what it inherits.
- Troubleshoot a workload cluster deployment the same way as a management cluster - down the Cluster API chain - remembering that credentials, quota and image availability now belong to the workspace's infrastructure provider rather than to your local configuration.
- Attaching a cluster brings an existing Kubernetes cluster under Kommander management without recreating it, which is how EKS, AKS, GKE and other existing clusters join the fleet.
- Attached clusters are managed but not provisioned by NKP, so lifecycle operations such as upgrades and node pool management remain with whoever owns the cluster. Kommander gives visibility, access control and platform applications rather than full control.
- Attaching requires a kubeconfig with sufficient privileges and network reachability between the cluster and the management cluster. Attachment failures are almost always one of those two things.
- Detaching removes a cluster from Kommander management and leaves the cluster running, while deleting a managed cluster destroys it and its infrastructure. Confusing the two is the destructive mistake this objective exists to prevent.
- Decommission deliberately: detach an attached cluster you no longer wish to manage, and delete a managed cluster you genuinely want gone. Clean up the platform applications and access grants that referenced it either way.
- A project is a scope within a workspace, backed by namespaces across the workspace's clusters. It is how a single application team gets consistent namespaces, access and applications across several clusters at once.
- Configure access control at the project level for team-scoped rights, and deploy project applications so an application is present in that team's namespace on every cluster in the project rather than being deployed cluster by cluster.
- Federated resources are defined once at the project level and pushed into the corresponding namespace on every cluster in the project - config maps, secrets, quotas - which is what keeps multi-cluster configuration consistent.
- Continuous deployment at the project level lets a Git repository drive what is deployed into the project across clusters, so the fleet converges on the repository rather than on manual application.
- Choose the scope deliberately, because it is the recurring theme of this section: workspace for a tenant or environment spanning clusters, project for a team or application spanning namespaces, and the individual cluster only when something genuinely applies to one cluster alone.
NCP-CN 6.10: Nutanix Cloud Native exam tips
- Nutanix publishes no percentage weightings for NCP-CN, so budget study time by how much ground each section covers rather than by a published figure. Day 2 Operations and Fleet Management have the most objectives between them.
- The scoring is unusual: 3000 to pass on a 1000-6000 scaled range, not a percentage. Treat every section as testable and do not try to convert that scale into a number of questions you can afford to miss.
- Air-gapped installation runs through the whole first section. Know why you seed a private registry, that the image bundle must match the NKP version, and that machine image builds need an offline package bundle.
- Understand what a bootstrap cluster is for and that it is temporary: it runs the Cluster API controllers, the resources pivot into the management cluster, and it is then deleted.
- Almost every deployment troubleshooting question resolves to walking the Cluster API chain - Cluster, control plane and MachineDeployment, Machines, provider resources - and reading the first thing that is not Ready.
- Keep the two management layers straight. Kommander roles govern workspaces and projects; Kubernetes cluster roles govern objects inside a cluster. Roles inherit downward from workspace to project and cluster.
- The most consequential distinction in fleet management is detach against delete: detaching stops managing an attached cluster and leaves it running, deleting destroys a managed cluster and its infrastructure.
- Know the scope hierarchy cold - workspace for a tenant or environment, project for a team or application across namespaces, cluster for one cluster - because most fleet questions are really asking which scope a setting belongs at.
- For backups, remember that Velero without a configured volume snapshot class captures Kubernetes resources but not persistent volume data. That distinction is exactly the kind of detail this exam tests.
Study guide FAQ
What is the format and passing score of the NCP-CN 6.10 exam?
The exam is 75 multiple-choice and multiple-response questions in 120 minutes, costing US$200 per attempt, available in English and Japanese, and delivered by remote proctoring or at a test centre. The passing score is 3000 on a scaled range of 1000 to 6000, so it is not a straightforward percentage. You get two further attempts after a first failure, with a seven-day wait between them.
Are percentage weightings published for the four sections?
No. The Nutanix blueprint guide lists four sections and their objectives but gives no percentage per section, stating only that the number of questions for each objective relates to how critical that task is in the job role. Any study material that quotes section percentages for this exam is inferring them rather than citing Nutanix, so plan to cover all four.
How much Kubernetes experience do I need?
Nutanix describes the target candidate as having 6-12 months of building and managing Kubernetes clusters, 6-12 months of working with Linux, and around six months with a target infrastructure provider. This is a professional-level exam that assumes you already understand Kubernetes concepts - it tests NKP and Kommander on top of that rather than teaching Kubernetes itself.
What is the difference between detaching and deleting a cluster?
Detaching removes an attached cluster from Kommander management and leaves the cluster itself running and intact - you simply stop managing it. Deleting a managed cluster destroys the cluster and the underlying infrastructure that NKP provisioned for it. Always delete managed clusters through the NKP CLI rather than removing virtual machines on the provider, because doing it directly leaves orphaned Cluster API resources behind.
What is the difference between a workspace and a project?
A workspace groups whole clusters that share access control, platform applications and an infrastructure provider - typically a tenant, a business unit or an environment. A project is a scope inside a workspace backed by namespaces across that workspace's clusters, so a single application team gets consistent namespaces, access control, applications and federated resources across several clusters at once. Deciding which scope a setting belongs at is a recurring theme of the fleet management section.
Official exam sources
This vendor publishes no domain weightings for this exam, so the split below is CertGrid's own division of the published objectives rather than a vendor figure. Each source below records what it confirmed and when it was read, so that is checkable rather than something to take on trust.
- Nutanix - NCP-CN certification detailslink and content verified 8 September 2026"75 multiple choice questions", "Time Limit: 120 minutes", English and Japanese, $200 per attempt - our 75 and our 120 minutes. Four sections whose names are ours word for word: Prepare the Environment for an NKP Deployment; Manage Building an NKP Cluster; Perform Day 2 Operations; Conduct NKP Fleet Management. The experience claim is confirmed and is a description of the candidate rather than eligibility: "A candidate for the NCP-CN has at least 6-12 months of building and managing Kubernetes clusters, 6-12 months of working with Linux, and 6 months of experience with a Kubernetes platform." This REPLACES a recorded-only entry that pointed at a gated blueprint PDF - the certification-details page carries the same detail and renders in a headless browser.
- Nutanix - NCP-CN Exam Blueprint Guide (PDF)Blueprint revised NCP-CN 7.5 beta · link and content verified 8 September 2026Read, and it turns out to describe a DIFFERENT exam from the one on the certification page - which is worth recording rather than glossing. "The NCP-CN 7.5 beta exam consists of 105 multiple-choice and multiple-response questions", the time limit is 180 minutes, there is no cost, and the passing score does not exist yet: "The final score will be determined by examining the results from the beta exam period", 4-6 weeks after it closes. So this PDF does NOT support our 3000 / 6000 label, and is not cited for it. It does confirm that Nutanix attaches no percentage weightings to the objectives - it says only that "a number of questions is determined for each objective, which relates directly to the criticality of the task in the job role".
The vendor does not publish this. Two things, and neither is a correction to the page. First, Nutanix publishes NO percentage weightings for this exam. The certification page lists the four sections and their tasks with no numbers, and the blueprint PDF says only that the question count per objective "relates directly to the criticality of the task in the job role". That is why this page carries no percentages and our practice mocks draw evenly across the four sections, rather than inventing weightings to look complete. Second, the two Nutanix documents describe different exams, as they do for NCM-MCI. The certification page gives 75 multiple-choice questions in 120 minutes, which is ours; the Exam Blueprint Guide linked from it describes the NCP-CN 7.5 beta at 105 questions in 180 minutes, free, with no passing score set until 4-6 weeks after the beta closes. Our 3000 / 6000 label rests on Nutanix's program-wide statement in the NCA, NCP-MCI and NCM-MCI blueprint guides - "the passing score for this exam is 3000 ... The scale is from 1000-6000" - and NOT on this PDF, which explicitly has no score yet. The 7.5 beta is a change to track rather than to adopt.