NSEA common mistakes
NSEA · Understand the traps and how to avoid them.
Treating the distributed storage fabric as a conventional RAID array - for example, stating that a given virtual disk's data lives on a fixed set of two or three nodes, or that a node failure forces a rebuild of the whole disk group before I/O resumes.
Candidates carry over mental models from SAN/NAS or RAID controllers, where redundancy is per-array. Nutanix instead stripes data as extents across many nodes with per-extent replicas (or erasure-coded stripes), so the failure unit is the extent, not the disk or the array. This shows up whenever a question asks what happens to a specific VM's data during a node outage.
What to do instead
Rehearse the data path explicitly: guest write, Controller VM, extent store, replication factor (RF2/RF3) or EC scheme, then metadata update in Cassandra and placement decided by Stargate/Curator. Practise explaining what a single node loss does to each of RF2, RF3 and EC configurations, and note that with EC the stripe spans nodes so a single failure is tolerated without full rebuild.
Answering sizing questions by summing raw capacity and dividing by VM disk size, then declaring the cluster has enough space.
Sizing questions look like arithmetic, so candidates skip the overheads: RF or EC multiplier, reserved capacity for metadata and the cluster's ability to sustain a node failure, snapshot and protection-domain growth, and the recommended headroom. The arithmetic answer is always more optimistic than the correct one.
What to do instead
Use a fixed sizing sequence: usable capacity = raw × (1 − reserve) ÷ RF (or the EC ratio); then subtract snapshot/protection-domain allowance; then check that the result still meets the resilience target with one node down; then confirm the answer leaves the vendor-recommended free-space buffer. Show the arithmetic in your reasoning so a wrong assumption is visible rather than hidden.
Confusing the Controller VM with the hypervisor, or assuming the CVM can be live-migrated or that it consumes no licensed resources.
The CVM runs as a VM on each node and owns the storage and cluster services, while the hypervisor hosts guest VMs. Candidates who blur the two mis-answer questions about what happens during maintenance mode, why the CVM must not be migrated by standard HA, and how CVM memory/CPU reservations affect usable host capacity.
What to do instead
Build a one-page node diagram: hardware, hypervisor, CVM (with its reserved vCPU/RAM), guest VMs, and the paths between them (local disk passthrough or PCI passthrough to the CVM). Then annotate what happens on maintenance mode, on CVM reboot, and on full node failure. Treat 'CVM is protected from normal HA evacuation' as a fact to memorise.
Describing a cluster as having a single controller or a single metadata database, or claiming that losing the node holding 'the master' stops the cluster.
The control plane is distributed: metadata is replicated across CVMs, and leadership roles are elected and re-elected. Candidates who have only seen traditional clustered storage expect a head node and over-predict catastrophic outcomes from one node loss.
What to do instead
Learn which services are distributed versus per-node (metadata ring, leader election, placement services) and what quorum means for the cluster. For any 'node X fails' question, ask first whether quorum is preserved and whether the affected role is elected, then answer about degraded performance rather than outage.
Mixing up protection domains, consistency groups, snapshots and replication in answers - for example, saying a protection domain is a synchronous replication construct, or that snapshots are stored on the same node as the source VM.
These are adjacent concepts with overlapping vocabulary. Under time pressure candidates collapse them into 'backup', losing the marks attached to RPO/RTO, schedule granularity, and where snapshot data physically resides.
What to do instead
Make a comparison table with columns: scope (VM set), mechanism (snapshot vs continuous replication), locality (local vs remote site), RPO, and typical use case. Force yourself to state the RPO for each construct before choosing an answer; synchronous versus asynchronous is usually the discriminator in the question stem.
Assuming a network design that works for management traffic also works for storage replication, and omitting the requirement that storage and management traffic be separated or that replication traffic be accounted for in link sizing.
Candidates focus on the guest VLAN and forget that the CVMs talk to each other constantly for writes and rebuilds, and that replication to a remote site consumes WAN bandwidth proportional to change rate. Questions about a slow cluster or a failed replication often hinge on this.
What to do instead
For every network question, draw three planes: management/CVM, guest VM, and replication/backup. State the MTU and VLAN assumptions for each, and check whether the proposed design keeps CVM-to-CVM latency low. When replication is involved, compute change rate × retention window against link capacity before accepting the design.
Answering installation questions as if any node can join any cluster at any time, ignoring the prerequisites checked at foundation - identical or compatible hardware generation, matching hypervisor and AOS versions, correct network configuration and time synchronisation.
The install workflow is usually memorised as a click sequence (image the nodes, run the foundation/installer, create the cluster), so the compatibility gates that cause real-world failures are skipped. Exam stems that describe a node that 'will not join' are testing exactly those gates.
What to do instead
Memorise the pre-join checklist as a diagnostic order: hardware model and firmware compatibility, AOS and hypervisor version match, CVM IP reachability and correct VLAN, DNS/NTP, and cluster health. When a question describes a failed expansion, walk that list in order instead of guessing at the installer.
Treating Prism as a single tool and therefore mis-assigning tasks - claiming that capacity trending, alert tuning and one-click upgrades all happen in the same place, or that Prism Central is required to run a cluster.
Prism Element is the per-cluster interface and Prism Central is the multi-cluster management plane; they overlap but are not interchangeable, and some capabilities (categories, multi-cluster policies, some reporting) exist only in Central. Candidates who have only used one of them generalise.
What to do instead
List the tasks you would perform in Element versus Central and note which Central features require registration of the Element cluster. Remember that a cluster operates and can be managed locally without Central, and that Central adds cross-cluster policy and analytics.
Confusing availability with resiliency in design answers - proposing a design that survives a disk failure but not a node failure, or claiming that a stretched cluster removes the need for local redundancy.
'Highly available' and 'resilient' sound synonymous, and candidates satisfy the word in the stem without checking the failure domain the customer actually cares about. Stretched-cluster questions are especially prone to this because the site failure domain and the node failure domain coexist.
What to do instead
For each design, write the failure domains explicitly (disk, node, block/rack, site) and state the tolerated failures and the resulting RPO/RTO at each level. Then verify the proposed RF/EC and replication configuration against each row. If a row is unmet, the design is wrong regardless of how good the other rows look.
Skipping discovery in pre-sales scenarios and jumping straight to a bill of materials based on the number of VMs alone.
Technical candidates enjoy the product answer more than the requirements interview, so they size on VM count and ignore IOPS profile, growth rate, existing hypervisor and network constraints, compliance/residency needs, and the customer's actual RTO. The resulting design answers the wrong question.
What to do instead
Before any sizing, extract and write down: workload mix and IOPS/latency targets, current and projected capacity with growth rate, resilience target per workload tier, network and site constraints, and migration window. Only then select RF/EC, node model and count, and validate against the headroom rule. In exam stems, underline the constraint words (RTO, growth, compliance) and let them drive the answer.