Free NCP-MCI-7.5 Practice Test Questions 2026

Explanation:

When provisioning a VM using remote storage in Nutanix, the storage container must be configured as Shared. If the container type is not set to Shared, it will not appear in the dropdown list during VM provisioning.

Shared Container Type → Allows multiple VMs across the cluster to access the container.

Non-shared (private) containers → Restricted to specific usage and therefore do not show up in the provisioning dropdown.

Other options are either irrelevant or incorrect:

A. The storage container does not have a reservation
Reservations are about capacity guarantees, not visibility in the dropdown.

C. The Container Name contains a hyphen(-)
Hyphens are allowed in container names; this does not block visibility.

D. The Container Name Length is 70 characters
Nutanix supports long names, but name length does not prevent the container from appearing.

📖 Reference:

Nutanix NCP-MCI 7.5 Exam Guide — Domain 2.0: Managing Nutanix Storage

Nutanix Documentation: Storage Containers and Shared Type Configuration

Explanation:

Nutanix Disaster Recovery (formerly Leap) supports multi-site protection policies, where a single protection policy created from the source/primary location's Prism Central can define multiple recovery locations. For example, Site A can be the primary location while replicating simultaneously to both Site B and Site C as recovery locations.

This is the most efficient approach because:

It requires configuring and maintaining only one policy rather than multiple redundant ones.

All replication schedules, recovery point objectives (RPOs), and recovery plans for the protected VMs are managed centrally from a single policy definition.

It avoids duplicated administrative effort and reduces the chance of configuration drift between policies, which could happen if managing separate policies per site pair.

Why the other options are wrong:

A. Create a single policy from Site A and clone it to Site B and Site C
Cloning protection policies across separate Prism Central instances isn't how multi-site protection works. Policies aren't cloned between Prism Central instances in this way, and doing so would create disconnected, independently-managed policies rather than one coordinated multi-site policy.

B. Create two protection policies (A→B and A→C)
While functionally this could work, it's not the most efficient method since Nutanix DR explicitly supports defining multiple recovery locations within a single protection policy, making two separate policies unnecessary administrative overhead.

C. Create three different protection policies, one per Prism Central
This is the least efficient option, requiring separate policy management and configuration across all three Prism Central instances, when a single, centrally-managed policy from the source can cover all sites.

Reference:

Nutanix Disaster Recovery (Leap) documentation on protection policies describes support for defining a primary location and multiple recovery locations within one protection policy, enabling simultaneous protection to more than one remote site without creating separate, duplicate policies.

Explanation:

The requirement is to encrypt only the PCI-DSS database servers while leaving general-purpose VMs unencrypted.

The appropriate approach is to use a category-based Storage Policy to apply encryption selectively.

Since the external Key Management Server (KMS) is already registered with Prism Central, the administrator can configure encryption in the storage policy and apply it to the category assigned to the PCI-DSS VMs.

This provides workload-level control without enabling encryption globally for the entire cluster.

Important configuration detail

The question's wording is slightly misleading. A storage policy can selectively encrypt VMs, but the cluster must first have Entity Encryption enabled. Registering the external KMS alone is not sufficient.

Nutanix documentation confirms that storage-policy-based encryption requires Entity Encryption to be enabled on the cluster. Otherwise, the VM is marked non-compliant and its data is not encrypted.

Why the other options are incorrect

A
Cluster-wide encryption would also encrypt general-purpose VM data, violating the requirement.

B
A storage container is not the best way to selectively apply encryption to individual VMs by category.

C
Correct. A category-based storage policy provides VM-level encryption control.

D
Guest OS encryption does not provide the requested Nutanix storage-policy-based encryption using the registered KMS.

Exam takeaway

For selective encryption of PCI-DSS workloads:

Configure the cluster for Entity Encryption using the external KMS.
Create a storage policy with encryption enabled.
Associate the policy with the PCI-DSS VM category.
Remember: Entity Encryption must be enabled before the storage policy can encrypt VM data.

Explanation:

This question refers to NCC health check KB 4519, which validates that NTP (Network Time Protocol) servers are properly configured across the cluster. Accurate time synchronization is critical for Nutanix clusters because time drift between nodes/CVMs can cause serious issues with cluster services, certificate validation, logging/troubleshooting correlation, and distributed consensus operations.

Nutanix best-practice guidance referenced in this KB recommends configuring a minimum of 5 NTP servers to be considered a "good" and robust configuration. The reasoning follows standard NTP design principles:

A single or small number of NTP sources provides no way to detect a "falseticker", which is a misbehaving time source giving inaccurate time.

With enough servers, such as the recommended 5, the NTP algorithm can reliably use a majority-consensus and voting mechanism to identify and discard any outlier or inaccurate time source. This helps the cluster converge on an accurate and trustworthy time reference even if one or two servers are misbehaving or unreachable.

Fewer servers, such as 1 or 3, leave the cluster more vulnerable to being misled by a single bad time source because there isn't enough redundancy for reliable outlier detection.

Why the other options are wrong:

A. 1
A single NTP server provides no redundancy and no way to validate accuracy. If that server is wrong or unreachable, the entire cluster's time synchronization can fail or become inaccurate.

B. 3
While better than one, three sources still don't provide the same robust consensus and outlier-rejection capability as the recommended five. It is considered insufficient for the "high degree of accuracy" standard referenced in the check.

D. 7
More servers than necessary. While not harmful, this exceeds the documented minimum recommendation and isn't the figure cited by KB 4519 as the baseline "good" configuration.

Reference:

Nutanix KB 4519 ("NCC Health Check: ntp_checks") documents the recommendation to configure a minimum of 5 NTP server sources for the cluster to achieve reliable, high-accuracy time synchronization via consensus-based outlier detection.

Explanation:

Nutanix Move Agent: When migrating virtual machines from Microsoft Hyper-V to Nutanix AHV, a Move Agent must be installed and deployed directly on the source Hyper-V host. This agent communicates with the Nutanix Move appliance, gathers source inventory, interacts with Hyper-V to manage snapshots, and facilitates the data transfer process.

Why Other Options Are Incorrect:

A. Nutanix Move
This is the overall migration appliance/software platform itself, not the specific host-level agent deployed onto Hyper-V.

B. Nutanix VirtIO drivers
These are paravirtualized drivers installed inside the guest operating system of the VM to ensure optimal storage and network performance on AHV, not on the Hyper-V host.

C. Nutanix Guest Tools (NGT)
A software package installed inside guest VMs running on Nutanix to provide advanced management features, VM mobility, and VSS snapshot support, rather than a Hyper-V host migration service.

Explanation:

When deploying a VM with Secure Boot enabled for a UEFI boot configuration on Nutanix AHV, the VirtIO ISO must be attached using the SATA bus type. Nutanix documentation explicitly states that if Secure Boot is enabled for UEFI boot configuration, the IDE interface is not supported for the Nutanix VirtIO ISO, and SATA must be used as the bus type for the CD-ROM device.

This limitation exists because Secure Boot with UEFI requires properly signed and authenticated components to execute during the boot process, and the legacy IDE controller is not compatible with this security framework. The administrator must configure the CD-ROM device hosting the VirtIO ISO with SATA as the bus type to successfully install the necessary drivers during VM deployment.

Why the Other Options Are Not Correct

Option A (SCSI)
SCSI is the recommended bus type for disks after VirtIO drivers are installed, but it cannot be used for the VirtIO ISO itself during initial deployment because the drivers are not yet available to the guest OS.

Option B (IDE)
IDE is explicitly not supported when Secure Boot is enabled.

Option D (SAS)
SAS is not a valid bus type option for CD-ROM devices in Nutanix AHV VM configuration.

Explanation:

Nutanix uses Security Configuration Management Automation (SCMA) to continuously inspect the platform (CVMs and AHV hosts) for security drift — deviations from the established security baseline, including STIG settings. When drift is detected, SCMA automatically reports it and reverts the settings to the baseline.

The frequency of these SCMA checks is controlled by the SCMA schedule, which can be set to Hourly, Daily, Weekly, or Monthly via nCLI commands such as ncli cluster edit-cvm-security-params schedule=... or the equivalent for AHV/PCVM.

Importantly, the documentation explicitly states that you can modify only the SCMA schedule. The system runs the AIDE schedule on a fixed weekly interval.

This matches the question's requirement: adjust how often the platform checks for security drift without modifying controls that run at fixed intervals.

Why the other options are incorrect

A. The AIDE schedule
AIDE (Advanced Intrusion Detection Environment) runs on a fixed weekly schedule and cannot be changed by the administrator.

C. The list of security entities inspected by SCMA
This is not a user-configurable setting; SCMA inspects a predefined set of entities.

D. The SCMA baseline enforcement behavior
SCMA always enforces the baseline and self-heals detected security drift. There is no separate setting to change this behavior independently of the schedule.

References
Nutanix Security Guide – Security Configuration Management Automation (SCMA) Implementation. It explicitly notes that only the SCMA schedule is modifiable, while AIDE runs on a fixed weekly interval.

Explanation:

When troubleshooting sporadic VM I/O stalls across Nutanix clusters, the supported and efficient mechanism for log collection is Logbay.

Logbay is Nutanix's built-in tool for collecting diagnostic logs from CVMs and AHV hosts.

It packages logs into a bundle that can be analyzed locally or escalated to Nutanix Support.

Prerequisite:
Logbay is available only when the node has a Controller VM (CVM) deployed or the AHV compute node has been added to the cluster. Without these, Logbay cannot collect logs.

Other options are incorrect:

B. Panacea
Panacea is an internal Nutanix troubleshooting tool, not the supported mechanism for administrators.

C. Storage policy compliance reports
These are for policy validation, not log collection.

D. ADS (Automatic Diagnostic System)
ADS is not a Nutanix log collection tool; it does not export diagnostic bundles.

📖 Reference:
Nutanix NCP-MCI 7.5 Exam Guide — Domain 6.0: Troubleshooting Nutanix Clusters
Nutanix Documentation: Logbay – Collecting Logs for Support and Analysis

Explanation:

Reserved Capacity (Logical) ensures that a specific storage container has a minimum amount of storage capacity reserved for its use.

In a Nutanix storage pool, multiple containers share the underlying physical storage. Without a reservation, other containers may consume available capacity, leaving insufficient space for the container's workloads.

By configuring Reserved Capacity (Logical), the administrator protects the container's minimum storage allocation from being consumed by other containers.

Why are the other options incorrect?

A. Advertised Capacity (Logical)
Defines the logical capacity presented to the container, not a guaranteed minimum storage allocation.

B. Reserved Capacity (Logical)
Correct. Reserves a minimum amount of storage capacity for the container.

C. Throttled Throughput (IOPS)
Limits storage performance, not storage capacity.

D. Total Space (Physical)
Represents physical storage capacity, not a reservation for an individual container.

Exam Tip

Remember the difference:

Advertised Capacity: The logical capacity presented to a container.

Reserved Capacity: The minimum logical capacity reserved for a container.

Key takeaway:
When a question asks how to protect a container's minimum storage capacity from consumption by other containers, choose Reserved Capacity (Logical).

Explanation

Minimum Node Requirement for RF2 + Erasure Coding:
Nutanix Erasure Coding (EC-X) with Replication Factor 2 (RF2) requires a minimum of 4 nodes. This allows the system to build a valid data and parity stripe layout, such as a 2+1 stripe configuration, across independent nodes to maintain fault tolerance.

Why Other Options Are Incorrect:

A. 3
While a standard RF2 cluster can run with a minimum of 3 nodes, enabling Erasure Coding requires at least 4 nodes to support the parity calculations and distribution.

C. 5
5 nodes is the minimum node requirement for standard clusters using Replication Factor 3 (RF3) without erasure coding, though 6 nodes are required for RF3 combined with Erasure Coding.

D. 6
6 nodes are recommended for optimal EC-X efficiency, such as a 4+1 stripe, and are the minimum required for Erasure Coding combined with RF3, but not for RF2.

Explanation:

In Nutanix's VM performance classification, as seen in Prism's VM efficiency and performance analysis, a Constrained VM is one that is being starved of resources. It is not getting enough CPU, memory, or storage I/O performance to run efficiently, and this shows up as measurable symptoms of resource contention.

CPU Ready Time > 5% — indicates the VM's vCPUs are waiting in the scheduler queue for physical CPU time because the host is oversubscribed or experiencing contention, meaning the VM isn't getting scheduled promptly.

Memory Swap Rate > 0 Kbps — indicates the VM is being forced into memory swapping at the hypervisor level, which is a sign that physical memory is insufficient or contended for what the VM needs.

High Stargate CPU usage (>85%) — indicates the storage I/O path, handled by the Stargate storage controller service, is heavily loaded. This can cause the VM's I/O requests to queue and slow down, reflecting storage-side constraint.

Together, these three metrics point to a VM that is resource-starved across CPU, memory, and storage I/O. This is the classic signature of a "Constrained" VM, meaning its performance is being limited by insufficient available resources due to contention, oversubscription, or an undersized cluster relative to demand.

Why the other options are wrong:

A. Inactive VM
An inactive VM would show low resource usage across the board, including idle CPU, no memory pressure, and minimal I/O. This is the opposite of the high contention symptoms described here.

B. Over-provisioned VM
An over-provisioned VM is one that has been allocated more resources than it actually uses, such as being assigned 16 vCPUs while using only 2. This is a sizing and resource-waste issue, not a symptom of the VM struggling to get the resources it needs.

D. Bully VM
A Bully VM is one that consumes excessive resources and negatively impacts other VMs on the host, causing contention for other workloads. This is the opposite role: a bully causes constraint in others, whereas the VM described here is experiencing the constraint itself.

Reference:

Nutanix Prism's VM performance and efficiency categorization distinguishes between Constrained VMs, which are starved of resources and show symptoms such as high CPU ready time, swapping, and I/O contention, and Bully VMs, which over-consume resources and cause contention for others. The combination of CPU ready time, swap rate, and Stargate CPU usage represents the documented signature of a constrained VM.

Explanation:

The cluster has reached its resilient capacity limit, which is the threshold that triggers the write-blocking behavior when Reserve Rebuild Capacity is enabled.

According to Nutanix documentation, when the Reserve Rebuild Capacity option is enabled, the cluster reserves a portion of storage to guarantee it can self-heal from a node failure. The Resilient Capacity is the total usable capacity minus the reserved rebuild capacity. When the Resilient Capacity limit is reached, the cluster stops accepting write requests.

If the used capacity is close to the resilient capacity and increases due to large write operations, internal background jobs, or migration tasks, the used capacity can overshoot the resilient capacity. If rebuild capacity is already reserved on the cluster, the cluster stops accepting write requests.

The VM outages described in the question are a documented consequence of this scenario. Enabling Rebuild Capacity Reservation on a cluster with current usage close to the Resilient Capacity threshold might result in a VM outage. This matches the symptoms described: the cluster stopped accepting writes, and VMs experienced outages.

Why the Other Options Are Not Correct

Option A (EC-X capacity limit)
Incorrect because Erasure Coding has its own separate capacity considerations and does not directly cause the write-blocking behavior described when Reserve Rebuild Capacity is enabled.

Option B (A node failed causing 2N/2D containers to degrade)
Incorrect because a cluster with 2N/2D fault tolerance requires a minimum of 5 nodes, and a single node failure would not cause the specific write-blocking behavior tied to the Resilient Capacity threshold. The scenario describes a capacity threshold being reached, not a failure event.

Option D (A node failed causing 1N/1D containers to degrade)
Incorrect because while a node failure is a possible trigger for rebuild operations, the question specifically describes the cluster reaching a capacity limit that stops writes. The documented behavior is tied to the Resilient Capacity threshold being exceeded, not the act of a node failing itself.