NCP-MCI-7.5 Nutanix Certified Professional - Multicloud Infrastructure (NCP-MCI) 7.5 Questions and Answers

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 )

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 documentation for Prism Central deployment states that single Prism Central VM deployments are supported in Small, Large, or X-Large sizes, and that a single-VM deployment can later be scaled out. Since X-Small is not the supported minimum deployment size in this documented model, the minimum supported size is Small. That makes A correct.

This question is really checking whether the administrator understands the starting point for a scale-out-capable Prism Central design. The existence of larger sizes does not change the minimum supported entry point. Nutanix’s documentation is explicit that a single Prism Central VM can begin at Small and later be expanded if more scale or resiliency is needed. Therefore, for a single-node Prism Central deployment with future scale-out potential, the correct answer is Small.

Nutanix documentation for PD-based DR remote-site configuration states that if vStore mapping is not configured, replication occurs to the remote container with the same name as the source container. Nutanix further explains that this fallback relies on the existence of that matching destination container. Therefore, if same-name containers do not exist on the two sites and no explicit vStore mapping is defined, the replication target cannot be resolved correctly and the replication will fail. That makes A the correct answer.

This behavior is intentional. Nutanix does not randomly pick a destination container, nor does it silently force all replications into the default container. When administrators want different container names between source and target, the supported mechanism is vStore mapping. Skipping that mapping only works when identical container names already exist at both sites. Because the question explicitly removes that condition, replications fail to complete, which is why A is the authentic answer.

Foundation Central is about deployment centralization, not backup, lifecycle upgrades, or automatic registration workflows as its main value proposition. Nutanix documentation describes Foundation Central as a tool that can manage several Foundation instances from a single pane of glass, allowing administrators to create clusters of remote nodes. That statement maps directly to option D. ( Nutanix Portal )

The subtle point here is that the question mentions Marketplace only as the method used to deploy Foundation Central, not as the capability being tested. Once deployed, Foundation Central’s job is to simplify remote cluster creation at scale. It does not replace LCM for software upgrades, nor is its primary role to perform backup and recovery of cluster configurations. Automatic cluster registration may happen as part of broader operational workflows, but it is not the core capability Nutanix emphasizes in the product description. In the context of imaging and deploying many branch-office clusters from a central team, the defining capability is centralized cluster creation and management visibility. That is why D is the right answer. ( Nutanix Portal )

Nutanix documentation for enabling Marketplace in Prism Central explicitly states that a unique data services IP address (DSIP) must be configured on the Prism Element cluster that hosts Prism Central. This is a hard prerequisite for Marketplace enablement and application deployment workflows. In exam terms, the presence of DSIP is not optional convenience; it is a setup requirement Nutanix calls out directly before Marketplace can be used. ( Nutanix )

The other answers are not Marketplace prerequisites in the same direct sense. SMTP is useful for email notifications, LDAP for external authentication, and LACP for network design, but none of those is the documented enabling requirement for Marketplace. Nutanix separates platform application management prerequisites from general infrastructure best practices, and DSIP falls into the former category. So when the exam asks what must already be in place on the Prism Element cluster before enabling Marketplace, the correct answer is A: Data services IP must be configured. ( 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.

Nutanix does support exposing storage containers for hypervisor access patterns, but Nutanix also clearly recommends not using an AOS storage container as a general-purpose NFS or SMB share. For a temporary exception such as a migration host, the safer and more controlled approach is to whitelist only the exact host that needs access. Using a single host IP with a 255.255.255.255 netmask is the most restrictive option listed and follows the principle of least privilege. That reduces risk during the migration window and avoids broad, unnecessary exposure of the container to an entire subnet. ( Nutanix Portal )

This question is really about administration discipline, not just raw connectivity. Opening the whole subnet might be convenient, but it creates more attack surface and more chance of accidental mounting from unauthorized systems. Nutanix documentation steers administrators toward purpose-built file services, such as Nutanix Files, when they need true shared file access. Since this is only for a temporary migration, the best practice is a tightly scoped NFS allowlist entry for one external host. That makes B the strongest operational and security choice. ( Nutanix Portal )

Nutanix documentation is very clear on this point: Secure Boot is not supported if the VM uses IDE disks. Nutanix also states that for AHV, if Secure Boot is enabled for UEFI mode, the IDE interface is not supported and SATA should be used for the VirtIO ISO in that configuration. So an IDE-attached disk is a direct blocker to enabling Secure Boot. ( Nutanix Portal )

This is one of those areas where the exam expects you to know compatibility rules, not just feature names. UEFI is actually part of the supported Secure Boot path, so option D is not the blocker. The CVM’s RAM and node cache storage are unrelated to whether the VM’s firmware and bus configuration can support Secure Boot. The administrative fix is usually to convert the VM to a supported configuration using UEFI and non-IDE bus types where required. Therefore, among the listed options, the condition that prevents completion of the task is the presence of IDE disks, making C correct. ( Nutanix Portal )

When Prism Central is scaled out for resiliency, the design goal is not only to have multiple Prism Central VMs, but also to ensure they are not placed together in a way that creates a common point of failure. Nutanix documentation around anti-affinity policies explains that VM-VM anti-affinity is used to keep selected VMs from running on the same host. In a scaled-out Prism Central deployment, this placement separation is the logical next step to strengthen resiliency, because it prevents the Prism Central instances from collapsing onto the same physical host and failing together during a node outage. ( Nutanix )

The other options are either unrelated or not the primary required follow-up. Witness Service is associated with Metro Availability and DR designs, not with the baseline requirement of distributing Prism Central VMs after scale-out. Protection Domain protection may be useful in some cases, but it does not solve co-location risk. HA reservations on the hosting Prism Element cluster address restart capacity, not placement diversity. The most direct resiliency improvement after scaling out Prism Central is to enforce separation between the Prism Central VMs. That is why D is the best answer. ( Nutanix )

The uploaded source file shows the answer key as B, but the supporting exhibit or calculation context is missing from the provided document, so a full mathematical derivation cannot be verified from the question bank itself. Because of that missing context, the safest exam-faithful response is to preserve the source answer of 1125 IOPS while being transparent that the exact intermediate values used to reach that number are not visible in the provided material.

From a Nutanix policy perspective, IOPS throttling is implemented through storage policies to control or cap workload consumption and prevent noisy-neighbor impact. The conceptual goal is to set a value high enough to accommodate the intended steady-state workload while still enforcing policy boundaries. In practice, administrators usually choose a value above the observed average to allow normal variance, bursts, and scheduler overhead rather than matching the average exactly. That design logic is consistent with an answer larger than 800 IOPS. Given the choices and the source key, 1125 is the preserved answer for this batch, but this is one of the questions where the missing exhibit should ideally be restored before using it as a final study reference. ( Nutanix )

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 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 explicitly states that in Prism Central, when you are using more than 80% of Prism Central capacity, a red PC Under-provisioned warning icon appears. That means this alert is not describing the managed cluster’s resilient capacity, nor is it about a storage over-provisioning ratio on the Prism Central VM. It is specifically tied to the Prism Central instance itself approaching its own capacity limit. ( Nutanix Portal )

This is a good example of monitoring terminology that can be misleading on the exam. Because the administrator is looking at future resource needs for clusters, it is easy to assume the warning is about the cluster being under-provisioned. However, Nutanix labels this condition as PC Under-provisioned, and the documentation ties it to Prism Central consumption, not the cluster’s resilience threshold or a failed scale-out event. Operationally, the response is to review Prism Central sizing and determine whether scale-out or resizing is required to support the monitored environment. Based on the Nutanix documentation wording, B is the correct answer. ( Nutanix Portal )

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.

Nutanix documentation for updating an existing virtual switch describes both Quick and Standard (Recommended) methods. Nutanix explicitly recommends the Standard method for production-style changes because it applies updates in a controlled rolling manner, typically by migrating workloads and updating nodes sequentially to minimize impact. The Quick method is available only in certain update scenarios and is not the recommended path for critical workloads when avoiding disruption is the priority. That makes A correct. ( portal.nutanix.com , portal.nutanix.com , portal.nutanix.com )

Deleting and recreating the switch would be far more disruptive. Putting all nodes into maintenance mode at once defeats the entire purpose of non-disruptive rolling change. Nutanix’s own recommendation in this area is the strongest clue: for production, use the Standard method.

Nutanix documentation for service accounts states that authentication is done using a shared secret key generated and managed through IAM. The same service-account framework is designed so the account can perform actions according to assigned privileges rather than inheriting unrestricted administrator rights. In practical terms, that means a service account is meant for automation, API use, and non-interactive authentication, while still being controlled through the RBAC model. That matches D exactly.

The incorrect options reflect common misunderstandings. A service account does not simply log in with the cluster admin password, and it does not automatically inherit full administrator privileges. It is not an external-KMS construct, and certificate-based auth is not how Nutanix documents this service-account mechanism. The exam clue is the phrase “without an interactive user password” combined with “granular permissions.” Nutanix’s answer to that requirement is a service account authenticated by an IAM-managed shared secret with assignable permissions. Therefore D is the authentic Nutanix answer.

If the organization has changed naming conventions and needs VM disks placed into containers that comply with the new standard, the direct operational method is to move the VM’s virtual disks to the correct container. In Nutanix, that action is done through live vDisk migration. This preserves workload availability while relocating storage placement to the new destination container that matches policy. The question is really about correcting existing placement, not just defining intent for future objects. ( Nutanix Portal )

The other options do not solve the immediate placement problem. A storage policy can influence behavior, but it does not retroactively relocate already placed vDisks unless that policy is tied to an action that changes their storage location. Image placement policy affects images, not existing VM disk residency. Renaming storage containers is not the right operational answer here because naming policy changes usually result in a need to place workloads into the correct containers, and administrators do not rely on renaming alone to change where current VM data lives. Nutanix’s management model supports live movement of VM storage, so A is the practical and technically correct answer. ( 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.

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 )

Nutanix Volumes documentation explains that external iSCSI clients use the iSCSI Data Services IP address for target discovery and connection. Nutanix specifically documents creating or updating the ISCSI Data Services IP Address on the cluster as part of enabling access to Volumes. If that step is missing, an external initiator can fail to discover or connect to the volume group correctly. Therefore B is the correct answer.

The other options are unrelated to the direct connectivity requirement. Microservices Infrastructure and Prism Central registration are not the necessary cluster-side prerequisites for an external iSCSI connection. LDAP directory configuration is also not the primary dependency being tested here. The key Nutanix platform requirement is that the cluster exposes the Volumes service via the configured Data Services IP. Without that, the initiator connection workflow breaks. So B is the authentic answer.

Nutanix documentation on rebuild capacity reservation and resilient capacity emphasizes that some storage space must remain effectively protected so the cluster can recover from failures and maintain resiliency. If a cluster consumes all capacity beyond that protected threshold, it can reach a point where it no longer safely accepts writes because continuing to do so would violate resiliency guarantees. The symptoms in the question—stopped accepting writes and VM outages—align with a cluster hitting its resilient capacity limit, not merely an EC optimization limit. ( Nutanix )

This distinction matters. Erasure coding limits affect efficiency opportunities, but they do not by themselves explain the cluster refusing writes. A degraded container after a node failure may contribute to pressure, but the wording centers on cluster-wide behavior after rebuild-capacity reservation is enabled. Nutanix’s resiliency logic is designed to protect the cluster from entering an unsafe state, and one enforcement mechanism is to stop admitting additional writes when resilient capacity has been exhausted. Therefore, the most likely cause is C: the cluster has reached its resilient capacity limit. ( Nutanix )

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 networking guidance makes this distinction very clearly: balance-slb (Active-Active with MAC pinning) is the bond type used when the administrator wants multi-uplink utilization without additional physical-switch configuration. Nutanix also documents that LACP requires Active-Active / balance-tcp, and balance-slb must not be combined with link aggregation protocols such as LACP. If the switch team turns on LACP while the Nutanix side remains in balance-slb, the uplink behavior is mismatched and degraded throughput is the expected result. Therefore D is the correct answer.

This is a classic exam trap because both balance-slb and balance-tcp are Active-Active styles, but they are not interchangeable. One is switch-independent and the other is switch-dependent with LACP. The problem here is not MTU, uplink count, or support for vs0. It is the fact that the switch configuration and AHV bond mode no longer agree. In Nutanix, if LACP is enabled on the switches, the virtual switch must be configured for the LACP-compatible Active-Active mode, not MAC pinning. That is why D is the authentic answer.

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.

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 documentation describes guest customization profiles as reusable configuration settings that can be applied during VM deployment from a template and also during certain clone operations. For Linux-based cloud-init workflows, Nutanix explicitly shows that when deploying a VM from a template with Cloud-Init guest customization, administrators can apply or override the customization settings at deployment time. That makes option A the cleanest and most documentation-aligned answer. ( portal.nutanix.com , portal.nutanix.com )

Why not the others? Nutanix does support guided setup and clone scenarios, but the wording “create a VM template for reusability” points most strongly to the template deployment workflow rather than one-off cloning. Cloud-init is also the Nutanix-native customization method for Linux initialization at first boot, which makes it especially suitable for standardized reusable templates. So if the goal is simple repeatable management with a template-driven lifecycle, the correct point to apply the guest customization profile is when deploying a VM with Cloud-Init guest customization, which is A. ( portal.nutanix.com )

The requirement is not to keep the mission-critical VMs together or apart from each other; it is to prevent them from running on a specific set of older hosts. In Nutanix Prism Central policy terms, that is a VM-Host Anti-Affinity Policy. Anti-affinity at the VM-host level allows administrators to mark selected hosts as unsuitable targets for selected VMs, which is exactly what the scenario requires. Therefore C is the correct answer.

The distractors all target the wrong relationship. VM-VM affinity and anti-affinity control how VMs are placed relative to other VMs, not whether they can run on particular hosts. VM-Host Affinity would express a positive preference or requirement to run on a chosen host group, but the question is framed negatively: the VMs must never run on the older hosts. Nutanix’s policy model supports this exact exclusion use case through VM-Host Anti-Affinity. In a long refresh delay scenario, this is the safest operational control to keep sensitive workloads off weaker or undesirable hardware without removing those hosts from the cluster immediately. Therefore C is the authentic answer.

For Prism Central–based DR between on-prem Availability Zones, Nutanix documentation states that the clusters participating in the protection workflow must be registered with Prism Central. In the standard same-management-plane deployment model, the primary and recovery clusters need to be available to the Prism Central instance orchestrating the policy and recovery objects. That is why B is the expected exam answer for successfully configuring asynchronous replication with a protection policy in this scenario. ( Nutanix )

The other options reflect common misconceptions. Identical storage-container naming is not a mandatory prerequisite because Nutanix supports vStore mapping to map source and destination containers when names differ. The strict less than 5 ms RTT requirement is associated with synchronous-style designs such as Metro Availability, not ordinary asynchronous replication. Matching Prism Central versions is good practice but is not the core requirement expressed in the documented prerequisites. Since the protection policy workflow depends on managed registration within the Prism Central DR architecture, B is the best answer. ( Nutanix )

Nutanix’s recommended migration tool for moving VMs into AHV is Nutanix Move. Official Nutanix guidance and migration material specifically recommend Move as the preferred mechanism for migrating VMs to AHV, especially when the goal is to reduce disruption compared with coarse methods like backup-and-restore. Move is purpose-built for this scenario and supports migration workflows from platforms such as VMware into Nutanix AHV with minimized downtime during cutover. ( Nutanix )

The distractors highlight common confusion between the overall product and helper components. Move Agent may be involved in certain source-platform workflows, but the question asks what should be used to minimize downtime at the solution level. The correct answer is the migration platform itself: Nutanix Move. Backup and restore is usually more disruptive and manual. CCLM is unrelated here. Nutanix positioning is very clear that the standard, supported, low-downtime migration path from a third-party virtual environment to AHV is Move, so D is correct. ( Nutanix )