Nutanix NCP-CI-Azure common mistakes
Nutanix NCP-CI-Azure · Understand the traps and how to avoid them.
Treating NC2 on Azure as a lift-and-shift of Prism Central into the customer's Azure subscription and assuming the Prism Central VM runs on customer-managed Azure compute they can RDP into and resize freely.
Candidates study Nutanix on-premises architecture first and map it one-to-one onto Azure. They miss that NC2 is a Nutanix-operated service: the cluster runs on bare-metal Azure instances in a Nutanix-owned subscription, and the customer's interaction is through Prism Central/Prism Element and the NC2 console, not through Azure VM management of the cluster hosts.
What to do instead
Redraw the architecture from scratch: separate the Azure subscription that holds the NC2 cluster (Nutanix-managed bare-metal) from the customer subscription that holds the VNet peering, gateways, and any Azure-native services. Learn which objects the customer controls (VLANs, subnets, IP pools, Prism Central sizing) versus which Nutanix operates, and practise describing the boundary in one sentence before answering any architecture question.
Sizing the cluster by counting vCPUs and RAM of the workloads and dividing by a single node type, without applying Nutanix resiliency (RF2/RF3) and the reserved capacity for the Controller VM.
On-premises sizing habits carry over: people add up VM demand and pick the smallest node count that fits. In NC2 the usable capacity per node is reduced by the CVM reservation and by the redundancy factor, and the supported node configurations are a fixed catalogue, so the arithmetic gives an undersized or unsupported cluster.
What to do instead
Work the calculation in the correct order: raw per-node capacity minus CVM overhead, then apply RF2 (roughly halving usable capacity) or RF3, then add headroom for growth and for maintenance/failure tolerance. Verify the result against the published supported node types and cluster size limits, and check that the chosen node count still meets resiliency after one node is down.
Designing the Azure side as a flat VNet with one large subnet and putting all Nutanix VLANs into it, then discovering overlapping RFC1918 ranges with on-premises.
Candidates focus on the Nutanix VLAN/subnet model and treat Azure networking as a transparent pipe. They forget that NC2 requires a dedicated subnet for the cluster and that each Nutanix VLAN is mapped to an Azure subnet, and that peering and VPN require non-overlapping address space end to end.
What to do instead
Build an IP address plan before anything else: one subnet per Nutanix VLAN, a dedicated cluster subnet, a gateway subnet, and explicit non-overlapping ranges for on-premises, Azure, and any other cloud. Practise mapping 'Nutanix VLAN → Azure subnet → route table → peering/VPN' as a table, and check the plan against Azure VNet and subnet sizing limits.
Assuming traffic between the NC2 cluster and other Azure VNets or on-premises flows automatically because the cluster is 'in Azure', and never configuring peering, gateways, route tables, or NSG rules.
The NC2 cluster lives in a Nutanix-managed subscription, so it is not automatically part of the customer's VNet topology. Candidates who have only built single-subscription Azure labs expect implicit connectivity and skip the explicit peering and routing steps.
What to do instead
Memorise the connectivity checklist: VNet peering (or a gateway connection) between the customer VNet and the NC2 VNet, correct route tables on both sides including gateway transit where used, NSGs permitting the required management and data ports, and DNS resolution across the boundary. For each scenario question, state which of these is missing rather than answering 'it just works'.
Choosing Microsoft Entra ID (Azure AD) as the identity source for Prism Central and expecting on-premises Active Directory group policy or NTLM-based workflows to behave identically.
Candidates conflate Azure role-based access control with Nutanix Prism role-based access control and assume a single directory serves both. The two planes are separate: Azure RBAC governs Azure resources, Prism governs the Nutanix cluster, and directory integration has its own prerequisites and limitations.
What to do instead
Learn the two planes separately and where they meet: Prism local users and roles, directory integration for Prism (LDAP/AD or Entra ID as supported), and Azure RBAC for the surrounding Azure resources. For each question, ask 'who is authorising this action - Prism or Azure?' and answer within that plane, noting that a user may need entitlements in both.
Describing hybrid operations as 'manage everything from Prism Central' without distinguishing which Prism Central instance sees which clusters, and without a plan for registering remote or on-premises clusters.
Single-site study leaves candidates with one Prism Central in mind. In hybrid deployments there may be a Prism Central for the NC2 cluster, an on-premises Prism Central, and a decision about whether to manage clusters from one pane or keep them separate, each with its own version-compatibility requirements.
What to do instead
Draw the management topology explicitly: which Prism Central manages which clusters, whether clusters are registered to a remote Prism Central, and the Prism Central version compatibility with each cluster's AOS version. Practise answering 'where do I click, and which PC am I clicking in?' for common tasks such as firmware updates, alerts, and reporting.
Assuming Nutanix features behave identically in NC2 as on-premises - for example expecting Flow virtual networking, certain networking modes, or hardware-dependent capabilities to be available unchanged.
Feature parity is a common assumption, and candidates memorise on-premises feature lists. NC2 runs on Azure bare metal with a specific supported configuration, so some capabilities are unavailable, have different prerequisites, or are replaced by Azure-native services.
What to do instead
Maintain a short parity table for the features the exam touches (networking, disaster recovery, encryption, backup targets) with a column for 'on-premises' and 'NC2 on Azure'. When a question hinges on a feature, check whether the scenario depends on something the Azure bare-metal platform does not expose, and prefer the Azure-native alternative where the feature is absent.
Designing disaster recovery as 'replicate to Azure and it will fail over' without deciding on the replication technology, the recovery point objective, the network remapping at the recovery site, and how failback works.
Candidates learn that Nutanix replication and protection domains exist and stop there. They do not connect RPO to the replication schedule, and they forget that a recovered VM in Azure needs a subnet, an IP address, and DNS that differ from the protected site.
What to do instead
For every DR scenario, write four lines: source and target (on-premises to NC2, NC2 to on-premises, or NC2 to NC2), replication mechanism and schedule derived from the stated RPO, network remapping plan (VLAN/subnet/IP/DNS at the target), and the failback procedure including how to resynchronise. If a question gives an RPO, compute the required schedule rather than guessing.
Planning a migration by moving VMs with a single tool and ignoring the prerequisites: guest OS support, Nutanix Guest Tools and drivers, IP re-addressing, and the cutover window.
Migration questions reward tool knowledge, so candidates name a product and skip the surrounding work. In practice most migration failures are prerequisite failures - an unsupported OS version, missing virtio drivers, or an address plan that cannot be preserved across the boundary.
What to do instead
Structure migration answers as phases: assess (inventory, OS and driver support, dependencies), prepare (install Nutanix Guest Tools, stage drivers, agree the address plan), replicate (initial sync, delta sync), cut over (downtime window, DNS and IP changes, validation), and decommission. Name the tool only after the phase it serves.
Treating security and cost as separate afterthoughts - for example leaving the NC2 management plane reachable from any source and never tagging or budgeting the Azure-side resources.
Candidates compartmentalise domains and answer governance questions with generic advice. In NC2 the management plane exposure and the Azure networking resources are the main attack surface, and the Azure-side cost drivers (peering data transfer, gateways, public IPs, any Azure-native services) are easy to leave unbudgeted.
What to do instead
Apply a fixed checklist to every scenario: restrict management access to known sources via NSG and a jump host or Bastion, enable encryption and audit logging, apply a tagging scheme to all customer-subscription resources, set budgets and alerts, and review data-transfer costs when choosing between peering and VPN. State the control and the specific resource it applies to, not a general principle.