Nutanix NCA-7.5 - Nutanix Certified Associate (NCA) 7.5 Exam

CPU Ready measures the time during which a virtual CPU is prepared to execute but is waiting for the hypervisor to schedule it on a physical processor. A VM can therefore report low apparent CPU consumption while still responding slowly: its workload is not continuously executing because the assigned vCPUs are waiting for physical CPU time.

Elevated CPU Ready commonly indicates physical CPU contention, excessive vCPU allocation, an unfavorable vCPU-to-core ratio, or competition from other VMs on the host. The administrator should correlate CPU Ready with host CPU utilization, VM sizing, the number of runnable vCPUs, and workload behavior. Assigning additional vCPUs without confirming the cause can worsen scheduling delays because the hypervisor may need to coordinate more virtual processors.

Disk capacity measures available storage space and does not identify processor scheduling latency. Memory usage can reveal pressure, swapping, or insufficient guest memory, but it does not directly represent time spent waiting for CPU scheduling. Snapshot size relates to retained point-in-time storage data and is unrelated to hypervisor CPU dispatch. Nutanix identifies CPU Ready Time as the percentage of CPU wait time, making it the appropriate metric. Reference: Nutanix Intelligent Operations – VM Details and CPU Ready Time . NHCF alignment: workload performance interpretation.

===============

The VM must be powered on so that the Nutanix Guest Agent and the guest operating system can participate in the NGT installation or upgrade workflow. The NGT software runs inside the guest, so a powered-off VM cannot execute the installer, communicate status, or complete the upgrade operation.

An available IDE or SATA CD-ROM slot is also required because Prism mounts the Nutanix Guest Tools ISO to the VM during configuration, installation, or upgrade. If the VM’s virtual CD-ROM is already occupied by another ISO, the NGT media cannot be attached through the expected workflow. Nutanix documentation therefore requires at least one empty supported CD-ROM device. After installation or reconfiguration, supported versions can automatically eject the mounted NGT media.

A DNS entry is not a universal prerequisite for upgrading NGT. Although functional name resolution may support broader management operations, the upgrade requirement is based on VM power state and the ability to mount the NGT ISO. Powering off the VM directly conflicts with the installation requirement. References: Prism Central 7.5 – Setting Up NGT and Nutanix Guest Tools Requirements . NHCF alignment: VM guest-tools administration.

===============

A VM template provides a controlled master configuration from which administrators can deploy multiple standardized virtual machines. The template preserves the source VM’s supported configuration, including its virtual hardware, operating-system disk, and other deployment properties. Prism Central also supports template versioning, allowing administrators to maintain and update the master image without manually rebuilding every new VM.

Snapshots preserve point-in-time VM data and are primarily intended for recovery, cloning, or data-protection workflows; they are not the principal mechanism for repeatedly provisioning standardized VMs. Categories attach metadata to entities for organization, policy assignment, governance, and automation, but they do not contain a deployable VM configuration. Volume groups provide block-storage resources that can be attached to one or more VMs and therefore do not satisfy the requirement for identical complete VM deployments.

Nutanix documentation describes a VM template as a golden image or master copy used to create VMs in Prism Central. Consequently, deploying from a template minimizes configuration variance and administrative effort. Reference: Prism Central 7.5 – VM Template Management . NHCF alignment: VM lifecycle operations and standardized VM provisioning.

===============

Nutanix Guest Tools is disabled by default on a cloned VM, even when NGT was installed and enabled on the source VM. Cloning reproduces the VM configuration and virtual disks, but the clone becomes an independent machine with its own identity. Automatically retaining the source VM’s active NGT configuration could produce duplicate guest-agent identities or invalid communication relationships with the Nutanix cluster.

The administrator must explicitly enable NGT on the cloned VM and complete the appropriate guest-side procedure. If the clone is powered off, NGT can be enabled through Prism and the VM can then be powered on. If it is already running, the administrator enables NGT and may need to restart the Nutanix Guest Agent or remount and execute the installer, depending on the guest operating system and existing NGT state.

“Deleted” is inaccurate because the cloned virtual disks may still contain the NGT software inherited from the source. The management state is disabled, not necessarily absent. “Updated” is also incorrect because cloning does not automatically upgrade the installed NGT package. Administrators should verify the resulting NGT status and version before relying on application-consistent snapshots or guest operations.

NHCF/NCA reference: VM cloning and NGT administration. Official references: Managing an AHV VM and Enabling NGT on Cloned VMs .

===============

A Nutanix storage pool is the physical aggregation of disks contributed by the nodes in a cluster. The disks may come from one or more storage tiers, such as NVMe, SSD or HDD, depending on the supported hardware configuration. Each physical storage device belongs to a storage pool, and Nutanix generally recommends a single storage pool per cluster so AOS can optimize capacity and performance across the available devices.

A storage container is a logical subdivision of storage capacity presented from the storage pool. Administrators apply settings such as compression, deduplication and other storage policies at the container level. Therefore, a container consumes capacity from a pool but is not itself the grouping of physical disks.

A volume group is a collection of virtual disks exposed to one or more VMs or external clients as block storage. “Disk group” is not the Nutanix AOS abstraction defined by the question.

The hierarchy is consequently physical disks, then the storage pool, followed by logical storage containers and workload-facing virtual disks or volume groups.

NHCF/NCA reference: Storage Concepts—AOS storage architecture, storage pools, containers and storage tiers; NCA Section 2, “Discuss storage operations.” Official references: Prism 7.5—Storage Components , AOS 7.5—Nutanix Software Configuration .

The 1N & 1D cluster fault-tolerance level is supported on a three-node cluster. It is designed to maintain access to data when one complete node and one additional disk fail concurrently, provided that the failures and remaining resources satisfy the documented resiliency conditions. To achieve this protection level, the platform configures replication factor 3 for the relevant data and maintains three metadata copies.

This configuration is distinct from standard 1N/1D fault tolerance, which protects against either one node failure or one disk failure and normally uses data replication factor 2. The ampersand in 1N & 1D is technically significant because it indicates simultaneous node-and-disk protection.

A two-node cluster uses a separate witness-based architecture and cannot provide this three-node 1N & 1D configuration. Nutanix documentation identifies three as both the required and supported node count for this specific fault-tolerance mode. Larger conventional clusters use their applicable fault-tolerance configurations rather than treating 1N & 1D as an arbitrary scalable setting.

Administrators must also verify that the cluster has sufficient resilient capacity before enabling the higher protection level. References: Prism 7.5 – One Node and One Disk Cluster Fault Tolerance and Cluster Fault Tolerance .

===============