Nutanix NCP-MCI-7.5 Nutanix Certified Professional - Multicloud Infrastructure (NCP-MCI) 7.5 Exam Practice Test

In Prism Central, Runway Analysis is not a simple reading of current utilization; it is a forecast based on historical consumption trends. Nutanix documentation explains that capacity planning and runway use machine learning and historical resource behavior to estimate when CPU, memory, or storage will run out. That means a cluster can still show only 60% memory used today and yet have a short memory runway if the memory-consumption trend has been climbing steadily and rapidly over recent history. In this scenario, the most likely reason for only 12 days of runway is sustained growth in memory use over the historical observation period. ( Nutanix )

The distractors do not fit the documented behavior as well. Nutanix does support scenario modeling, but a low runway in the standard view is primarily a forecast outcome, not a default penalty for missing history or a result of guaranteed HA mode by itself. HA reservations can reduce available effective capacity, but the wording of the question points to forecasting logic rather than static reservation math. Since Nutanix runway is based on actual consumption trends, the answer that best explains a low runway despite moderate present-day utilization is that memory usage has been continuously increasing, which is option B. ( Nutanix )

Nutanix Prism Central documentation for cluster settings profiles includes support for adding both authenticated and unauthenticated NTP servers. In the AOS 7.0 and later generation, the UI and feature set include the fields required for authenticated NTP, such as Key ID and Key Hex. If those fields are not appearing, the most likely explanation is that the managed environment does not meet the required software version for authenticated NTP support in that settings-profile workflow. That is why AOS 7.0 or later is the correct answer. ( Nutanix )

The other answers do not align with the documented dependency. Microservices Infrastructure is unrelated to whether authenticated NTP fields are exposed. There is no requirement that authentication be configured first in Prism Element before it can exist in the settings profile. Changing authentication algorithm type does not explain why the fields are entirely absent to begin with. The version dependency is the decisive factor. Nutanix often exposes advanced configuration fields only when the target cluster capability supports them, so the lack of Key ID and Key Hex strongly indicates that the cluster software level is below the authenticated-NTP requirement. Therefore D is the best answer. ( Nutanix )

In Nutanix Elastic VM Storage and shared-storage workflows, the container used across clusters must be created as a Shared storage container. Nutanix documentation for storage container management and container creation in Prism Central explicitly references Creating a Shared Storage Container and Creating a VM with Shared Storage from another HCI Cluster. If the container is not defined as Shared, it will not be eligible for the remote-storage VM placement workflow, so it will not appear as a valid target in the dropdown. ( Nutanix Portal )

The distractors are there to pull attention toward naming and capacity details, but those are not the gating requirement for remote shared-storage presentation. A reservation setting affects capacity planning, not whether the container is exposed as a remote shared-storage option. Hyphens in names and the specific length shown are not the documented reason the container would be absent from this workflow. Nutanix treats shared cross-cluster storage as a specific container type and workflow. Therefore, if the remote container is missing during provisioning, the most likely explanation is that the container type was not configured as Shared. ( Nutanix Portal )

This workload stores MP4 video files, which are typically large, sequential, and already compressed. For data with those characteristics, additional compression work often provides little benefit and can create unnecessary processing overhead. The best optimization is to disable compression for that workload through a storage policy so cluster resources are not wasted trying to compress data that is unlikely to shrink meaningfully. ( Nutanix Portal )

The other choices are weaker for this scenario. Capacity deduplication is generally most beneficial for repeated blocks or common-image patterns, not unique media streams. Erasure Coding is a capacity-efficiency feature, but on a small 3-node cluster and for a write-heavy recording pattern, it is not the primary performance optimization answer. Moving the data to Files changes the access method, but it does not address the specific inefficiency already identified in the storage settings. Nutanix exams often test whether the administrator can match the data service to the workload profile. Since MP4 content is already compressed, removing unnecessary compression overhead is the most targeted and sensible answer, making D correct. ( Nutanix Portal )

Nutanix documents Storage QoS as the correct mechanism to throttle VM I/O and prevent noisy-neighbor behavior. Nutanix also documents that storage policies in Prism Central apply to Categories, and that QoS settings such as throttled IOPS can be defined in the storage policy itself. That means the administrator can create one policy, set the IOPS cap, and apply it to the category assigned to Dev VMs. Current and future VMs with that category then inherit the same behavior without one-by-one configuration. That is exactly the scalable model described in option B.

The other options do not meet the requirement as cleanly. Replication factor affects resilience, not IOPS governance. Cloning one VM’s QoS is not a robust policy framework for future operations, especially when category-based automation already exists. Compression changes storage efficiency and sometimes performance characteristics, but it does not function as an enforceable per-VM IOPS cap. Because Nutanix explicitly ties QoS throttling to storage policies and category-based assignment, B is the documented and most maintainable answer.

Nutanix LCM documentation for the pre-check test_ahv_entering_mm_pinned_vms explains that this check identifies VMs that block the host from entering maintenance mode. Nutanix also notes that during host updates, LCM automatically shuts down running non-migratable VMs before updating the host. In practice, VMs using certain pinned or non-migratable features—such as specific agent, passthrough, or unsupported migration cases—must be powered off if they cannot be moved safely. That makes D the best answer. ( portal.nutanix.com , portal.nutanix.com )

The key is that not every special VM can live-migrate in every environment. Credential Guard migration has CPU-generation limitations, and pinned or specialized VMs can still block maintenance. The safest supported action for the listed blocked VMs is to power them off, let the host enter maintenance mode, and then proceed. So D is the right operational answer.

Nutanix documentation for VM revert behavior in Prism Central states that categories are preserved by default when a VM is reverted to a recovery point. Nutanix further notes that if an administrator wants categories to revert to the state captured in the recovery point, that must be done by using a V4 API override rather than the standard default behavior. That directly rules out choices A and B in the ordinary UI-based revert scenario. The expected default behavior is preservation of current categories, not rollback of categories to historical values.

The same recovery-point workflow also preserves present-day management context such as ownership rather than reconstructing all metadata exactly as it existed at the earlier capture point. The reason is practical: reverting the VM is primarily about workload state recovery, not about undoing every later governance assignment unless explicitly requested through advanced controls. From an administrator’s point of view, this is safer because access-control and ownership context is not unexpectedly rolled backward during a restore operation. Therefore the best answer is C: both the VM’s categories and ownership are preserved at their current state.

Nutanix documentation for log collection in Prism Central and related Logbay guidance supports collecting logs for a specific time range, which is exactly what this question requires to minimize noise and capture only the relevant 30-minute incident window. Nutanix also documents that when sending logs to Nutanix Support FTP, the administrator can enter a support case number, allowing the bundle to be attached to the case without manual repackaging. That makes D the strongest answer: use the alert details to identify the impacted entities and timestamps, collect the logs for that time window, and upload them using the support-case workflow. ( Nutanix Portal )

The other options do not produce the right diagnostic artifact. Auto-resolve only affects alert state, not log quality. Tightening thresholds may generate more alerts, but it does not replace collecting platform logs. Exporting a CSV of alerts can help summarize incidents, but it is not the primary evidence Nutanix Support needs for performance troubleshooting. Nutanix’s supported model is very clear: identify the incident timing, collect the appropriate logs for that window, and upload the bundle in a support-compatible way. Therefore D is the authentic answer from a Nutanix troubleshooting workflow perspective. ( Nutanix Portal )

Nutanix documentation explains that Projects in Prism Central provide logical groupings of infrastructure resources and user access, and that you can add users and user groups to a project while also allowing clusters and subnets in that project. That is exactly the mechanism used when a user group needs controlled access to resources drawn from multiple clusters. The project becomes the governance boundary that ties users, roles, and infrastructure scope together. Therefore A. Configure Nutanix Projects is the correct answer. ( Nutanix Portal )

The other choices are unrelated to access scoping across clusters. Advanced Network Controller deals with networking services and policy capabilities, not user resource assignment. Micro Services Platform is not the RBAC/governance feature for multi-cluster access. Availability Zone is relevant for placement and DR topologies, not for delegating cluster resources to user groups. Nutanix’s governance guidance is clear that Projects are the construct used to organize infrastructure resources and assign them to users or groups with the proper RBAC controls. So for a user group that needs access to resources from multiple clusters, the authentic Prism Central action is A. ( Nutanix Portal )

For AHV, when enabling LACP, Nutanix documentation specifies the Active-Active bond type, also described as balance-tcp. Nutanix explicitly ties LACP and link aggregation behavior to the Active-Active configuration and notes that this configuration sets LACP fallback to Active-Backup on AHV hosts. That makes C the correct bond type for an LACP-enabled design. ( Nutanix Portal )

It is also important to understand why Active-Active with MAC Pinning is wrong here. Nutanix documentation states that the MAC-pinning / balance-slb style must not be used with link aggregation protocols such as LACP. So even though both options sound like they distribute traffic, only one is compatible with LACP. Active-Backup provides redundancy, but not the LACP behavior being requested. “No Uplink Bond” obviously does not meet the requirement. Even without the missing exhibit from the uploaded file, the Nutanix networking documentation makes the intended answer clear: Active-Active is the bond type used when enabling LACP on AHV. ( Nutanix Portal )

Nutanix documentation for creating a storage container with Replication Factor 1 shows the workflow in the Prism Element web console. The official steps begin with logging on to Prism Element, navigating to storage, and creating the RF1-enabled container there. This makes A the correct answer.

This question is really about administrative scope. RF1 is a specialized storage-container setting that is managed at the cluster level, and Nutanix documents it in Prism Element rather than Marketplace or Self-Service. Prism Central can manage many cluster-wide resources, but the specific documented RF1 container-creation workflow is rooted in Prism Element. For exam prep, when a question asks which interface is required to create an RF1 container, the safe and documentation-aligned answer is Prism Element. Therefore A is the authentic Nutanix answer.

The wording “security drift” points to SCMA rather than AIDE. In Nutanix security hardening guidance, SCMA scheduling is the control that determines how often SCMA runs, with schedule options such as hourly, daily, weekly, and monthly. That makes the SCMA schedule the setting that changes the cadence of security drift checking without changing the underlying controls themselves. ( Nutanix Portal )

AIDE is a file-integrity mechanism and has its own role, but the question is specifically asking about how often the platform checks for drift in a broader security-configuration sense. Changing the list of entities inspected or baseline enforcement behavior would alter scope or enforcement semantics, not merely frequency. The most direct administrative answer is to change the schedule for SCMA. From an exam perspective, Nutanix often separates what runs, how it is enforced, and when it runs into different settings. Here the requirement is only about “how often,” so option B is the precise match. ( Nutanix Portal )

Nutanix documentation for enabling load balancing of vDisks in a volume group states that vDisk load balancing is enabled by default for volume groups attached to VMs by using a Data Services IP address. That is the exact behavior this question asks about: how to make load balancing happen by default rather than managing it manually each time. Therefore D is the correct answer. ( portal.nutanix.com , portal.nutanix.com )

The other answers may relate to supported limits or guest best practices, but they do not describe the default-enablement mechanism. Nutanix intentionally ties this behavior to the DSIP-based attachment model, which simplifies pathing and discovery while automatically enabling the balancing behavior. So for a study guide aligned to Nutanix docs, D is the authentic answer.

Nutanix documentation for Updating Capacity Configurations explains that the Reserve Capacity For Failure option determines whether runway analysis should account for the impact of a node failure, and when Auto Detect is selected, Prism Central automatically uses the cluster’s failure assumptions rather than the full unconstrained cluster total. In practical runway terms, that means the calculation reflects the loss of the node whose failure would have the greatest effect on usable capacity. Among the provided options, the best match for that documented logic is D: the runway analysis excludes the resources of the largest node so estimates account for a node failure. ( Nutanix Portal )

This behavior is important because runway is intended to answer “how long until I run out of safe usable capacity,” not just “how long until all raw resources are consumed.” Nutanix therefore lets administrators model capacity while preserving headroom for failure scenarios. The fixed 10% answer is too generic and not how Nutanix documents the option. Storage-only reservation also misses the fact that runway tracks CPU, memory, and storage dimensions. So, based on Nutanix’s Auto Detect wording and the resilience-oriented design of runway planning, D is the most authentic answer. ( Nutanix Portal )

Nutanix documentation for Windows VM creation on AHV clearly states that when deploying the Nutanix VirtIO ISO for a VM using Secure Boot and UEFI, the SATA bus type must be used. Nutanix also documents that IDE is not supported when Secure Boot is enabled for UEFI mode, which reinforces the correct bus choice. This makes C. SATA the correct answer directly from the official procedure. ( Nutanix )

This is a compatibility question, not a performance question. It can be tempting to choose SCSI because it is common in virtual machine storage design, but Nutanix’s secure-boot provisioning guidance is explicit about the VirtIO ISO attachment method. The exam often checks whether the administrator remembers that the driver ISO itself has a required bus type in secure-boot scenarios. Since the supported method in the Nutanix documentation is to mount the VirtIO ISO on SATA, C is the correct answer. ( Nutanix )

Nutanix AHV documentation for Windows Defender Credential Guard support states that the VM must be configured with UEFI and Secure Boot enabled, and Nutanix security guidance for vTPM explains that vTPM is used to protect Windows credentials and is part of the trusted platform features required by modern Windows security functions. Together, these requirements map directly to option D: enable UEFI firmware, enable Secure Boot, and add a vTPM device.

The other options each contain a flaw. IDE is not the correct secure-boot bus choice in these workflows, legacy BIOS does not satisfy the modern secure boot requirement, and “Generation 2 firmware” is Hyper-V-oriented wording rather than the standard AHV requirement stated in Nutanix docs. The policy in the question explicitly mentions rootkit resistance and credential isolation, both of which are tied to Secure Boot and TPM-backed trust. Therefore Nutanix’s documented VM configuration that satisfies those requirements is exactly what is described in D.

The decisive metric in the iostat output is %iowait = 83.20. In Linux performance interpretation, such a high iowait value means the CPU is spending most of its time waiting for disk I/O operations to complete rather than actively executing user or system work. On a Nutanix CVM, that strongly suggests the storage path is the bottleneck at that moment, whether due to backend disk saturation, contention, or broader storage subsystem latency. Since user CPU and steal are both low, the issue is not primarily compute pressure or hypervisor scheduling contention. Therefore, A is the most accurate description. ( Nutanix )

This is a classic Nutanix troubleshooting interpretation question. If the output had shown high %steal, then hypervisor contention would be a stronger candidate. If %system and %user were both very high, compute load from services would be more likely. But with the overwhelming majority of time in iowait, the signal points toward delayed storage completion. In operational terms, the next steps would usually involve checking CVM disk metrics, Stargate performance, storage latency, and possibly the health of the underlying drives. The evidence in the output supports a storage wait condition, which is exactly what option A says. ( Nutanix )

Nutanix documentation for Performing Failover in PD-based DR includes the exact error message quoted in the question: “Protection domain is already active on source site ... Please trigger migrate from source site to activate the protection domain.” Nutanix shows this message when the protection domain is still active on the source cluster and the proper action is a planned migrate from the source, not an activate at the target. In other words, the source cluster is still reachable and authoritative, so trying to activate the protection domain on the other side is the wrong operation. That makes D the correct answer. ( Nutanix Portal )

This is a classic Nutanix DR distinction between planned migration and unplanned failover/activation. If the primary cluster is still available, Nutanix expects the administrator to use migrate from the source site. Activation at the destination is reserved for failover conditions when the source cannot safely coordinate the move. The error itself tells you the reason if you read it carefully: the protection domain is still active on the source site. Therefore the root cause is that the administrator is trying to activate the PD while the primary cluster is still reachable and still owns the active copy, which is exactly option D. ( Nutanix Portal )

Nutanix documentation for Active Directory authentication in Prism Element states that the default LDAP port is 389, while port 636 is used for LDAPS, which provides encrypted LDAP traffic. Because the question explicitly says the administrator wants all traffic encrypted, the correct port is 636. That is the standard LDAPS answer and the one Nutanix documents directly.

The missing exhibit is not actually necessary to answer the question because the encryption requirement itself is enough. Ports 443 and 9440 are associated with web interfaces or management access, not LDAP directory authentication transport. Port 389 is unencrypted LDAP unless other mechanisms are layered on top. Nutanix’s own directory-authentication docs make the intended answer clear: use LDAPS on port 636. Therefore C is the authentic Nutanix answer.

The uploaded answer key lists B, and that is the safest supported choice among the options because it preserves the cluster’s all-NVMe storage profile rather than introducing mixed media tiers or an all-SSD design that changes the storage architecture. In Nutanix cluster expansion planning, keeping node media type aligned with the existing cluster profile is the normal supported design principle, especially when the existing cluster is already Full-NVMe. Nutanix storage documentation also emphasizes a single storage-pool-per-cluster model and consistent cluster design so that performance and capacity are optimized predictably across the nodes.

The alternative answers introduce obvious design mismatches. Mixed NVMe+HDD or SSD+NVMe nodes would materially change latency and tier behavior, while adding an all-SSD node into a Full-NVMe cluster would also break architectural consistency. Although the exact public expansion-matrix wording was not surfaced in the search results, the answer set itself strongly points to the only media-aligned option: one All NVMe node with 96 TiB RAW capacity. So for an exam-prep answer aligned with Nutanix design logic and the provided key, B is the correct choice.

Nutanix DR documentation for volume groups distinguishes replication types by RPO range. Nutanix documents Asynchronous Replication as the model for 1 hour or more RPO, while NearSync covers 1 minute to 15 minutes, and synchronous/Metro designs target near-zero or zero-RPO behavior with tighter latency expectations. Since the requirement here is 1 hour and the clusters are in different geographic regions, Asynchronous is the correct fit. That makes D the right answer.

The geography in the question is also a clue. Synchronous and Metro Availability are usually associated with low-latency links and more demanding network requirements, which are not implied by “different geographic regions.” NearSync is too aggressive for a 1-hour target and is documented for much shorter RPO windows. Nutanix’s own replication taxonomy places 1 hour or more squarely in the Asynchronous category, so D is the authentic answer.

Nutanix documentation specifically identifies deduplication as providing the greatest benefit for common data sets, and it explicitly calls out full-clone VDI workloads as one of the strongest matches. In a full-clone desktop environment, many virtual desktops contain highly similar operating-system files, application binaries, and repeated data blocks. Capacity deduplication is designed to eliminate those repeated blocks and therefore reduce the total physical storage consumed by the environment. This is exactly why Nutanix recommends deduplication for such use cases.

The other answers are less targeted. Thin provisioning is useful generally but is not the signature optimization for repeated-content VDI storage. Erasure coding is powerful for write-cold data and capacity efficiency, but it is not the primary answer Nutanix recommends for full-clone VDI patterns. “Post-process map reduce” is not the standard storage-efficiency answer expected in this context. For exam purposes, whenever Nutanix asks about full-clone VDI, the important association is with capacity deduplication, because that feature directly exploits the high block similarity across cloned desktops. Therefore B is the correct and most authentic answer.

Nutanix documentation for updating a VM through Prism Central states explicitly: “BIOS mode: You cannot modify the BIOS mode after the VM is created.” That wording directly answers the question and makes A the correct option. By contrast, vCPU count and memory allocation are common VM settings that administrators can adjust as part of lifecycle management, and boot priority can also be changed in supported conditions. The only one Nutanix calls out as restricted after creation is the BIOS mode. ( Nutanix Portal )

This reflects how foundational firmware mode is to VM identity and boot architecture. Once the VM is created using Legacy BIOS or UEFI, many guest-OS assumptions, boot-device structures, and security options depend on that original firmware model. Nutanix therefore locks this parameter after creation instead of treating it as an ordinary runtime edit. For exam preparation, this is a classic item to memorize: CPU and memory can generally be changed, but BIOS mode cannot be modified after VM creation. So the authentic Nutanix answer here is A. BIOS mode. ( Nutanix Portal )

Nutanix volume groups support attaching storage to one or more VMs. Nutanix documentation for creating volume groups states that if you want to attach a volume group to multiple VMs, you select the Shared option. That is the key requirement when building an application-level high-availability configuration where two database VMs need shared access to the same block storage construct. ( Nutanix Portal )

The other options either describe different capabilities or are not the documented mechanism for this requirement. External client access is used when exposing the volume group to external iSCSI initiators, which is not what the question asks. Storing vDisks on different containers does not create shared access semantics. “Multi-writer mode via storage policy” is not the standard Nutanix answer here; Nutanix’s documented configuration language for this use case is the Shared setting on the volume group itself. So if the requirement is two VMs, same application data path, and application-level HA, the correct Nutanix configuration is to create the VG in shared mode. ( Nutanix Portal )

Here the uploaded answer key says D, but official Nutanix documentation supports B. Nutanix documents that for enhanced security of ROBO environments (typically 1- or 2-node clusters), administrators should select Native KMS (remote) for software-based encryption. Nutanix also states in KMS considerations that software encryption using Native KMS is supported for ROBO deployments using the Native KMS (remote) KMS type. Because the question explicitly describes a 2-node ROBO cluster and requires the keys to be stored outside the cluster, the Nutanix-authentic answer is B. Native KMS (remote).

An external KMS is valid in many enterprise encryption designs, but this question is more specific: it asks for the KMS type Nutanix supports and recommends for software encryption on a ROBO cluster. On that narrow requirement, the official docs point to Native KMS (remote) rather than External KMS. So for an authentic study guide aligned to Nutanix documentation, B is the correct answer.

This question is about CPU feature compatibility, not storage or networking uniformity. Nutanix documentation and KB guidance explain that VM migration can fail when clusters contain nodes with different CPU generations or different exposed CPU features. A VM that is already running with features negotiated on a newer-generation CPU may not live-migrate successfully to an older or feature-different node until it is power-cycled or configured with advanced processor compatibility. That makes C the correct answer. ( portal.nutanix.com , portal.nutanix.com , portal.nutanix.com )

The important subtlety is that “same core count, memory, storage, subnet, and software version” does not guarantee CPU-feature equivalency. Firmware or ADS activity is not the primary issue described. Affinity rules can restrict placement, but the classic symptom after mixing repurposed nodes is CPU compatibility. Nutanix also documents that advanced processor compatibility settings persist across migrations and power cycles, reinforcing that CPU exposure is the real gating factor here.

When the requirement is to deploy multiple remote clusters efficiently from a central point, Nutanix’s intended tool is Foundation Central. Nutanix documentation describes Foundation Central as a way to manage several Foundation instances from a single pane of glass, allowing administrators to create clusters of remote nodes. That design matches the scenario perfectly: five newly purchased clusters, remote deployment, and a need for efficiency and centralized control. ( Nutanix Portal )

The other tools are more limited in scope. Foundation for Windows/Mac and a standalone Foundation VM are useful for imaging and cluster creation, but they do not provide the same centralized, multi-cluster orchestration model that Foundation Central provides. Phoenix ISO is a recovery or re-imaging tool and is not the normal answer for greenfield mass deployment. In short, this question is less about “which tool can build a cluster” and more about “which tool is purpose-built for remote, scaled deployment across many clusters.” Nutanix positions Foundation Central exactly for that use case, so B is the best answer. ( Nutanix Portal )

Nutanix separates storage resiliency reservation from compute high availability. For storage, the relevant setting is Rebuild Capacity Reservation, which reserves storage space so the cluster can self-heal and rebuild after node, block, or rack failure. For memory and compute, the relevant concept is High Availability, which reserves or accounts for host resources needed to restart workloads after a host failure. Putting those together gives the combination that best governs the remaining usable storage and memory capacity while preserving fault tolerance. That makes C the most correct answer.

The distractors either use non-standard phrasing or split the concepts incorrectly. “Memory Reservation” by itself is not the standard Nutanix answer when the exam is asking about cluster-wide restart capacity and usable memory after failure accounting. Nutanix administrators think in terms of HA for compute-memory protection and rebuild capacity reservation for storage protection. If the goal is to manage the usable remaining capacity for both storage and memory correctly, the right pair is Rebuild Capacity Reservation and High Availability. Therefore C is the authentic answer.

In Prism Central behavioral learning and VM efficiency views, Nutanix defines an over-provisioned VM as one that is oversized and wasting resources that are not actually needed. If a VM is consistently using less than half of what has been allocated, it is a classic over-provisioning signal: the VM has more CPU and/or memory assigned than its real workload profile requires. ( Nutanix Portal )

The wrong options each represent a different operational pattern. An inactive VM is largely idle. A constrained VM lacks sufficient resources and typically shows signs of pressure, contention, or poor performance. A bully VM consumes disproportionate resources and can negatively affect neighbors. None of those fit the scenario of consistently low utilization relative to allocated sizing. Nutanix includes these VM efficiency categories so administrators can right-size workloads and reclaim capacity before buying more infrastructure. In a resource planning exercise, identifying over-provisioned VMs is especially important because right-sizing them can delay expansion and improve overall efficiency. That is why D is the correct classification. ( Nutanix Portal )

Nutanix documentation states that the default erasure coding window for write-cold data is seven days. That means newly written or recently modified data is not immediately converted into erasure-coded stripes. If there was a large increase in data usage over a weekend, the administrator might not yet see the expected space savings because the new data has not aged long enough to fall within the EC processing window. That is why D is the correct answer.

This is a timing question more than a configuration question. The issue is not that EC has failed or deactivated automatically; it is that the data may still be considered too “hot” for the erasure-coding policy to process under the default window. DSIP and Prism Central health are irrelevant to whether EC space savings appear on a storage container. Nutanix separates the eligibility window from the fact that EC is enabled. Therefore, after a sudden growth event, lower-than-expected savings are best explained by the default erasure coding window settings, which is option D.

Nutanix documentation on capacity reservation explains that a storage container can reserve a portion of storage so that a minimum amount of capacity remains available for that specific container. When reservations are configured, one container may retain protected usable space while other containers in the same storage pool can run out of usable capacity first, even though the pool still shows free space overall. That exactly matches the scenario in the question, which is why C is the correct answer. ( Nutanix )

This is a subtle storage-administration concept. The question is not saying the pool itself is full; it says all but one container are out of space while the single pool still has free space. That pattern is much more consistent with reservation policy than with hardware failure. Failed nodes or drives would usually surface additional health symptoms and would not neatly explain one container still having preserved capacity while the others are exhausted. Nutanix intentionally allows reservation for predictable capacity control, and that is the feature responsible here. Hence A, B, and D are distractors, while C is correct. ( Nutanix )

For a standard AHV cluster deployment, each node typically requires one IP for the hypervisor host, one for the Controller VM (CVM), and one for IPMI or management access. Nutanix cluster-creation and expansion documentation repeatedly references entering host, CVM, and IPMI addresses for each node. If the administrator also wants a cluster virtual IP, that adds one additional IP for the cluster VIP. This results in three IPs per node plus one VIP, which is option C. ( Nutanix )

The answer choices with four IPs per node overstate the standard requirement, while the two-VIP choices add an extra VIP not requested in the question. Nutanix documentation for cluster details also distinguishes the per-node addresses from the optional virtual IP used for cluster access. So the clean way to think about this is: per node = host + CVM + IPMI, plus one shared VIP for the cluster. That aligns exactly with C. ( Nutanix )

Nutanix networking documentation is explicit that LACP on AHV requires the Active-Active bond type, also described as balance-tcp. Nutanix further explains that this mode increases host and VM bandwidth utilization beyond a single uplink by balancing VM NIC TCP and UDP sessions across multiple physical adapters. That directly addresses both parts of the requirement in the question: maximizing per-host throughput and per-VM throughput while also providing LACP support. For that reason, B is the correct answer.

The other options do not satisfy the stated requirement. Active-Backup gives redundancy but does not aggregate active bandwidth. Active-Active with MAC pinning (balance-slb) can use multiple adapters without switch configuration, but Nutanix documents that it must not be used with LACP. “No Uplink Bond” obviously cannot maximize throughput or provide aggregation. This question is testing a core AHV networking distinction: if the user explicitly wants LACP, then the answer is always the Active-Active / balance-tcp model. That is why B is the authentic Nutanix answer.