NCS-Core common mistakes
NCS-Core · Understand the traps and how to avoid them.
Treating the CVM as the only place cluster services run and assuming the hypervisor host has no role in storage or cluster membership, so questions about where genesis, Stargate, or Cassandra-style metadata services live get answered as 'all inside the CVM on any node'.
Most lab exposure is through Prism Element and the CVM, so candidates never see the host-side agents and forget that the AHV host runs the hypervisor plus a controller VM per node, and that some services are host-local while distributed metadata is replicated across CVMs.
What to do instead
Draw the per-node stack once from memory: hypervisor, controller VM, local disks presented to the CVM, and the distributed services (genesis, Stargate, Cassandra-style metadata ring, Prism) that replicate across CVMs. Then state for each service whether it is node-local or cluster-wide, and verify against Nutanix documentation before exam day.
Confusing the roles of Prism Element and Prism Central when answering management-plane questions, for example claiming Prism Central is required to create the cluster or that Prism Element cannot do RF and storage configuration.
Both interfaces look similar and Prism Central is presented as the 'main' UI, so candidates assume it is mandatory and holds all configuration. In practice a cluster is deployed and can be fully operated through Prism Element, while Prism Central adds multi-cluster management, categories, and services such as Flow or Calm.
What to do instead
Memorise a two-column table: what only Prism Element does (per-cluster storage, RF, node-level networking, cluster health), what only Prism Central does (multi-cluster inventory, categories, RBAC across clusters, services), and what either can do. Answer management questions by first asking 'single cluster or many'.
Planning a cluster with an even number of nodes or with a node count that cannot satisfy the desired replication factor, then defending the design because 'it has enough raw capacity'.
Candidates size on capacity alone and forget that resiliency and availability are driven by node count and fault domains. An RF2 cluster needs at least three nodes to tolerate a node failure, and RF3 needs at least five, so capacity math that ignores this produces a design that cannot meet its stated durability.
What to do instead
For every cluster design question, state the node count, the intended RF, and the number of tolerated failures, then check the arithmetic explicitly. Rehearse the rule that usable capacity is roughly raw capacity divided by RF, minus reserved space, and show the calculation rather than asserting a number.
Describing the imaging and foundation process as installing an operating system per node manually, or skipping the requirement that the cluster be created from a single node that then expands as others join.
Candidates with traditional virtualization backgrounds map the workflow onto per-host OS installs and miss that nodes are imaged with the hypervisor plus CVM image, and that cluster creation starts on one node with the rest discovered and added afterward.
What to do instead
Walk the deployment sequence in order: prepare and image nodes, network them, create the cluster on the first node, discover and add remaining nodes, then configure storage, networking, and Prism Central registration. Practise explaining what happens at each step and what would block the next one.
Mixing up which network carries which traffic, for example putting CVM management, storage replication, and VM guest traffic on the same flat network and then being unable to explain how a node failure is detected or how traffic is separated.
Small labs often run everything on one subnet, so candidates never internalise the distinction between the management network, the internal cluster or backplane traffic, and guest VM networks, nor how they can be separated or bonded.
What to do instead
Label the traffic types first: management, storage or internal cluster communication, and guest VM traffic. For each, state whether it can be separated, what happens if it shares a link, and how link aggregation or VLANs change the design. Answer networking questions by naming the traffic type before choosing a configuration.
Answering data protection questions with a single 'replication' answer, without distinguishing protection domain snapshots, remote replication, and backup to external targets, or stating recovery objectives without matching them to the mechanism.
The terms overlap in casual use, so candidates collapse them. They then give an RPO that the chosen mechanism cannot meet, or claim a snapshot is a backup when it lives on the same cluster.
What to do instead
Build a three-row comparison of local snapshots, remote replication, and external backup, each with where the copy lives, typical RPO and RTO, and what failure it survives. When a scenario gives an RPO or RTO, choose the mechanism that meets it and justify the choice against that table.
Treating lifecycle management as 'run the upgrade button' and ignoring prerequisites such as the LCM framework version, the compatibility of firmware and software bundles, and the need for health checks before starting.
Candidates memorise that LCM exists but not the workflow around it, so they miss questions about inventory, bundle selection, pre-checks, and the fact that some updates require the cluster to be healthy and may need coordination with the hypervisor vendor.
What to do instead
Learn the LCM sequence: run inventory, review available bundles and compatibility, apply pre-checks, schedule, execute, and verify. Be able to name what blocks an upgrade, for example an unhealthy cluster or an unsupported bundle combination, and where you would confirm compatibility.
Escalating to support as the first troubleshooting step, or conversely refusing to escalate and continuing to troubleshoot a hardware fault or data-loss risk without opening a case.
Candidates either lack a structured triage method and jump straight to support, or they over-index on self-reliance and miss the point at which a case should be opened with logs collected. Both behaviours lose marks on scenario questions about escalation criteria.
What to do instead
Use a fixed triage order: identify the symptom and scope, check cluster and Prism health, review relevant logs and alerts, attempt a known safe remediation, then escalate if the issue is hardware, involves data integrity, or exceeds your authority. State the trigger for escalation and what you would attach to the case.
Assuming adding a node is capacity-only work, and forgetting that expansion must respect the same resiliency rules, may trigger data rebalancing, and needs the new node to match or be compatible with the existing hardware and software.
Expansion is often taught as 'rack it and add it', so candidates miss compatibility checks, the rebalancing period where performance may be affected, and the fact that a poorly matched node can constrain the cluster.
What to do instead
List the expansion checklist: verify compatibility and firmware, image the node, add it to the cluster, confirm it joins the metadata ring, watch rebalancing complete, and re-verify resiliency status. Be ready to explain what changes in usable capacity and failure tolerance after the add.
Describing role-based access control as a single admin account and being unable to say how authentication sources, roles, and categories combine to scope permissions across clusters in Prism Central.
Most hands-on time is spent as the local admin, so candidates never exercise directory integration, role assignment, or category-based scoping, and they answer access-control questions with generic 'use least privilege' statements.
What to do instead
Learn the access-control model as three parts: the identity source (local or directory), the role and its permitted actions, and the scope (cluster or category). Work through one example of granting a team access to a subset of VMs via a category and a role, and state what that role cannot do.
Answering automation questions with 'use the UI or a script' and being unable to name the API style, authentication method, or how to discover endpoints when asked how to automate a repeated task.
Candidates avoid the API surface because it feels optional, so they cannot describe how Prism exposes REST endpoints, how to authenticate, or how to find the right call, and they fall back on vague answers.
What to do instead
Practise the API workflow end to end: authenticate and obtain a session or token, browse the API explorer to find the endpoint, issue a request and read the task status returned, then poll until completion. Be able to describe one concrete automation, such as creating a VM or taking a snapshot, in terms of the calls involved.