Nutanix NCP-DB common mistakes
Nutanix NCP-DB · Understand the traps and how to avoid them.
Treating the NDB Server VM as the database host during architecture questions, so answers place the database engine, the time machine, and the snapshot repository all on the NDB VM.
The NDB Server is a control plane (management, scheduling, metadata in its internal PostgreSQL). Database engines, the NDB Agent, and the time machine storage live on registered target clusters/VMs. Candidates who have only seen the UI assume everything they click happens locally.
What to do instead
Draw the three planes before answering: control plane (NDB Server + metadata DB), data plane (registered Nutanix clusters, database VMs running the NDB Agent), storage plane (time machine snapshot and log locations, SMB/NFS shares). For each option, ask which plane performs the action. The NDB VM never holds customer database data.
Describing the time machine as a backup schedule only, and missing that it is the logical container binding a source database to its snapshots, log-capture chain, clone lineage, and retention policy.
The UI presents 'Data Access Management' style schedules, so the time machine looks like a cron job. Questions about clone refresh, PITR, and snapshot retention then get answered with schedule semantics instead of lineage semantics.
What to do instead
Memorise the time machine as an object with a one-to-many relationship to snapshots and logs, and a parent-child link to every clone. Practise stating: deleting the time machine affects clones and PITR; changing retention affects which snapshots and logs remain; the SLA defines RPO/RTO, not the schedule alone.
Planning an installation without pre-validating DNS (forward and reverse), NTP, the Prism Element/Prism Central registration, and the target cluster's network, then blaming the installer when registration or provisioning fails.
NDB registration depends on name resolution in both directions and on clock skew tolerances; candidates focus on the OVA/ISO deploy steps they can see and treat prerequisites as paperwork.
What to do instead
Build a pre-flight checklist you can recite: static IP and gateway for the NDB VM, A and PTR records for the NDB VM and every database VM, NTP reachable and synchronised, correct Prism credentials with sufficient role, cluster registered and healthy, required ports open between NDB and the cluster. Answer prerequisite questions by naming the specific validation that fails, not 'recheck the network'.
Assuming a clone is a full physical copy of the source database and sizing storage and time accordingly, then choosing wrong answers about provisioning speed, space consumption, and clone independence.
Cloning in NDB is snapshot-and-attach based on the Nutanix storage layer, so clones are near-instant and space-efficient, with copy-on-write divergence. Candidates with traditional tooling mental models expect a data copy.
What to do instead
Learn the distinction between a snapshot-based clone (fast, thin, shares source snapshots) and a full copy or a clone refreshed from a later snapshot. When a question mentions provisioning time or capacity, ask whether the clone shares the snapshot chain. Also know that clones can be refreshed in place, which changes their data without changing their identity.
Confusing patch and upgrade operations: applying an OS patch when the question asks for a database engine version upgrade, or expecting a major version upgrade to behave like a minor patch in terms of downtime and rollback.
NDB exposes patching for the database engine, the OS, and the NDB Agent, plus upgrade workflows. The labels look similar in the UI, and candidates memorise 'patch = safe, upgrade = risky' instead of the actual scope of each operation.
What to do instead
Map each operation to its target and its preconditions: database engine patching, OS patching, NDB Agent upgrade, and NDB Server upgrade are separate. Know which operations require a snapshot or time machine first, which can be done on a clone for validation, and which need a maintenance window. Answer by naming the target component and the rollback path.
Describing PITR as 'restore the latest snapshot' and ignoring the continuous log-capture chain, the recovery target granularity, and the requirement that the time machine be healthy and log capture enabled.
Snapshot-based recovery is intuitive; log-based recovery requires understanding that NDB captures database logs to a repository and replays them to a chosen point. Candidates skip the log chain and pick the newest snapshot answer.
What to do instead
State the PITR chain explicitly: base snapshot, captured logs, chosen recovery timestamp, replay to that point, then a new database or clone. Know the prerequisites (log capture configured, repository reachable, retention covering the target time) and what happens when the target falls outside retention. Distinguish restore-in-place from restore-to-new.
Treating clone refresh as 'delete and re-clone', and therefore predicting a new clone name, new connection strings, or lost local modifications when the question describes a refresh.
Refresh is an in-place operation that replaces the clone's data with data from the source (or a newer snapshot) while preserving the clone's identity and registration. Candidates default to the recreate pattern they know from other tools.
What to do instead
Contrast the two paths in one sentence each: refresh keeps the clone entity, IP, and registration but discards its data and replaces it from the source; re-clone creates a new entity. Then answer questions about application impact, credential preservation, and what happens to data written to the clone since the last refresh.
Answering RBAC questions by naming a role from memory without mapping it to the scope where it applies (NDB-wide versus per-database or per-clone), and without separating NDB roles from Prism roles.
Access in NDB is layered: Prism Central/Element permissions govern infrastructure, NDB roles govern database operations, and directory services can supply identities and groups. Candidates collapse the layers and pick a role that exists but is scoped wrongly.
What to do instead
Build a two-axis table: role (what actions) versus scope (where). Learn which roles are administrative versus operational versus read-only, and how group membership inherits. For any scenario, first ask 'is this an infrastructure permission or a database permission?', then pick the role and the scope. Remember that a user who can see a cluster in Prism is not automatically able to provision on it in NDB.
Diagnosing a failed operation by looking only at the database VM logs, ignoring the NDB Server task/operation record that holds the step-by-step failure and the agent-side log.
NDB orchestrates multi-step workflows; the failure is usually recorded against the operation with the specific step that broke (agent unreachable, snapshot failed, credential error). Candidates jump to the guest OS and miss the orchestration record.
What to do instead
Adopt a fixed triage order: NDB operation/task detail and its failing step, then NDB Agent status on the target VM, then connectivity and credentials, then the database engine log. Learn which alerts indicate agent heartbeat loss, snapshot failure, log-capture lag, and capacity pressure, and what each implies for the time machine's SLA.
Assuming a snapshot exists in NDB because a Nutanix volume-group or VM snapshot exists on the cluster, or vice versa, and answering retention and recovery questions with the wrong snapshot type.
There are two snapshot layers: Nutanix storage snapshots that NDB creates and tracks, and NDB's own snapshot records tied to a time machine. Candidates conflate them and mis-state what happens when one is deleted or when retention prunes.
What to do instead
Keep the layers separate: NDB schedules and records snapshots for a time machine, and those map to storage-layer snapshots used for clones and restores. Know that deleting an NDB snapshot record versus deleting the underlying storage snapshot has different consequences, and that manual cluster-level snapshots are not managed by NDB retention. Answer by naming which layer the question is about.