NCA-GENL common mistakes
NCA-GENL · Understand the traps and how to avoid them.
Treating 'hyperconverged' as simply 'storage plus servers in one box' and describing AOS as a storage-only layer, so questions about where the Controller VM sits relative to the hypervisor and the CVMs' role in I/O are answered incorrectly.
Most candidates come from SAN or VMware backgrounds where the storage intelligence lives in a separate array or in the hypervisor kernel. They map AOS onto that mental model and miss that each node runs a Controller VM as a guest on AHV (or ESXi), with all data-path I/O served through the CVMs and the distributed storage fabric.
What to do instead
Draw the per-node stack from memory: hardware, hypervisor, Controller VM, and user VMs, and state that the CVM owns local disks and participates in a cluster-wide distributed storage fabric. Practice explaining what happens to a write from a user VM through the CVM and to replicas on other nodes. Rehearse why the CVM is a VM rather than kernel code, and what that implies for upgrades and for the hypervisor's role.
Confusing Prism Element with Prism Central, and answering management-scope questions with the wrong console (for example, claiming Prism Element performs multi-cluster RBAC or category-based VM policies).
Both are called 'Prism', both are web consoles, and many day-to-day tasks appear in either. Candidates memorize feature lists without anchoring them to scope: single-cluster operations versus multi-cluster, multi-service management.
What to do instead
Build a two-column table: Prism Element = per-cluster management of VMs, storage, alerts, and local tasks; Prism Central = multi-cluster management, categories, policies, and services such as Calm, Flow, and Prism Central-driven reporting. For each practice question, first ask 'is this one cluster or many?' and 'is this a policy across VMs or a local operation?'. Verify each feature against current Nutanix documentation rather than memory.
Describing resiliency only as RAID levels and ignoring replication factor, availability domain, and the distinction between data redundancy and VM/HA restart behaviour, so scenario questions about node or block failure get a partially correct answer.
Candidates carry over RAID terminology and assume a failed node means data loss or manual rebuild. They conflate 'the data still exists somewhere' with 'the VM keeps running', which are separate mechanisms.
What to do instead
Separate the two layers explicitly: the distributed storage fabric keeps replicas across nodes and fault domains (replication factor and checksum settings determine tolerance), while HA mechanisms restart VMs on surviving nodes. Practice a failure walkthrough: one node down, one block down, one disk down, and state what happens to data and to running VMs in each case. Confirm current defaults and limits in Nutanix documentation before answering.
Answering AHV networking questions with ESXi vSwitch concepts, mixing up virtual switches, VLAN-backed networks, and distributed firewall placement, and misplacing where Flow Network Security enforces policy.
AHV's networking model is deliberately simple, and candidates fill gaps with vSphere vocabulary. They also assume security policy is enforced by the hypervisor kernel or by an external appliance rather than by the AHV data path.
What to do instead
Learn AHV networking from the ground up: the default virtual switch, bridge versus VLAN-backed networks, IP address management, and how guest VMs attach to networks. Then place Flow Network Security as policy enforced in the AHV data path at the vNIC level, independent of guest OS. Practice drawing a two-network VM with a security policy between tiers and naming each component.
Treating snapshots and backups as interchangeable, and assuming a snapshot alone satisfies a DR requirement, leading to wrong answers on protection domain and recovery point questions.
Snapshots are fast and familiar, so candidates stop at 'take a snapshot' without asking where the copy lives and what happens if the whole site is lost. They also miss that replication schedules and retention are configured per protection domain.
What to do instead
For every data-protection question, answer three things: where is the copy (same cluster, remote cluster, object store), how often is it taken, and how is it restored. State plainly that a local snapshot is not a site-loss defence and that replication to a remote site or to object storage is what provides it. Rehearse the difference between RPO (schedule and retention) and RTO (restore and restart time).
Assuming Nutanix is only for AHV and that ESXi or Hyper-V clusters are managed differently, or claiming features such as certain Prism Central services work identically on every hypervisor, without checking.
Marketing emphasis on AHV leads candidates to overgeneralize. They then either deny supported functionality on other hypervisors or wrongly extend AHV-only capabilities to them.
What to do instead
Maintain a short matrix of what is hypervisor-agnostic (the distributed storage fabric, Prism, many data-protection features) versus what depends on the hypervisor (specific HA behaviour, some automation and networking features). When a question names a hypervisor, slow down and check whether the feature in question is tied to AHV. Use current Nutanix documentation and release notes as the source of truth per feature.
Answering lifecycle questions by describing upgrades as disruptive node-by-node reboots with manual CVM coordination, instead of the orchestrated rolling process with pre-checks and pre-checks for compatibility.
Candidates extrapolate from traditional firmware and hypervisor upgrade pain. They do not know that lifecycle management plans and runs upgrades with health checks, and they miss the importance of checking compatibility and the impact on running workloads.
What to do instead
Learn the upgrade workflow as a sequence: assess current versions, run pre-checks and compatibility validation, schedule the upgrade, let the orchestrator move workloads and upgrade components in a controlled order, then verify. Be able to say what the impact on running VMs is and what to check before starting. Confirm current tooling names and steps in Nutanix documentation, since these change between releases.
Mixing up Calm (application automation and provisioning), Flow (network security), and other Prism Central services, and attributing a described capability to the wrong service.
Prism Central bundles several services under similar branding, and candidates learn the names as a list rather than as distinct jobs. Under time pressure they pick the most familiar name.
What to do instead
Write a one-line job description for each service you are expected to know and a concrete example task for each. When a question describes an outcome, map the outcome to the job before choosing a name: provisioning and lifecycle of multi-tier apps is different from east-west traffic policy, which is different from cost visibility or self-service. Recheck service scope in current documentation, as services are renamed and expanded.
Answering support questions by skipping evidence gathering, describing escalation as 'open a ticket and wait', or ignoring that log collection, cluster health checks, and case severity affect the outcome.
Candidates treat support as a soft topic and do not study the operational behaviours: what to collect before contacting support, how to check cluster health, and how severity is determined. They also underestimate how much of the exam tests process discipline.
What to do instead
Learn a repeatable triage routine: confirm scope and impact, check cluster and Prism health and alerts, capture relevant logs and timestamps, note recent changes such as upgrades or configuration edits, then engage support with that package. Be able to explain how severity is assigned and why accurate severity and complete evidence shorten resolution. Verify current support procedures and portal workflows in Nutanix documentation.
Treating security as a perimeter concern only, so questions about least privilege, key management, and encryption at rest are answered with 'use a firewall' or 'enable encryption' without naming where keys live and who holds them.
Candidates default to network security because it is visible. Data-at-rest encryption and identity/role management are less familiar, and the distinction between a software key manager and an external key management server is easy to blur.
What to do instead
Study security as three separable layers: identity and role-based access to management interfaces, network policy between workloads, and data protection at rest including where encryption keys are stored and what happens if the key manager is unavailable. For each layer, be able to name the mechanism and the failure mode. Confirm supported key management options and defaults in current Nutanix documentation before answering.