Nutanix Certified Professional Multicloud Infrastructure 6.10 Free Sample Questions

CVM Network Segmentation is the feature designed specifically to isolate CVM back-end storage traffic onto a separate VLAN and physical network interface. This directly addresses the requirement for physical traffic separation for compliance. Flow Microsegmentation provides logical, stateful firewalling between VMs but does not physically separate the CVM back-end traffic. Creating a new bridge or bond is part of the process, but Network Segmentation is the overarching feature that orchestrates this configuration.

NearSync replication is designed for low-RPO scenarios (1 to 15 minutes) over long-distance, high-latency links where synchronous replication is not viable. It meets the business requirement of a sub-15-minute RPO. Metro Availability provides an RPO of zero but requires low latency (<5ms). Standard Asynchronous replication has a minimum RPO of 60 minutes. Cloud Connect is for replicating to a cloud target, not another physical site in this context.

A manual deployment of a Prism Central VM requires three separate disk image files: the boot disk, the home disk, and the data disk. These files contain the operating system, user data, and metadata/service data for the Prism Central instance, respectively. Swap space is managed within the OS and does not require a separate image file.

With Replication Factor 2, data is written in two copies across different nodes. When one node fails, the data that was on that node now only has one remaining copy on another node in the cluster. The cluster will immediately begin recreating the second copy, but until that process completes, that data is at risk. If another node or disk holding the single remaining copy fails during this time, data loss will occur. The cluster remains fully operational (read/write).

In Nutanix Prism, 'Critical' is the highest severity level for alerts. It signifies a serious issue that could lead to a production outage, data unavailability, or data loss. Therefore, to automate ticket creation for the most severe issues, the 'Critical' severity level should be used as the trigger in the X-Play playbook.

This is True. The Witness is designed to handle this specific split-brain scenario. If the secondary site can reach the Witness but the primary site cannot (due to a primary site failure), the Witness will instruct the secondary site to take ownership of the protected container. This ensures business continuity even during a complete primary site outage.

This is the most comprehensive and flexible solution. By categorizing the VMs and applying a QoS policy in Prism Central, the administrator can set a guaranteed number of CPU cycles (using CPU reservation) and a minimum IOPS value for the database VMs. This prevents resource starvation from 'bully' VMs without statically assigning them to hosts, thus maintaining cluster flexibility. Flash Mode is already active on an all-flash cluster, and reserving storage capacity doesn't guarantee performance. VM-Host affinity is too rigid and violates the 'not pinning VMs' requirement.

The Life Cycle Manager (LCM) framework is designed to automate the entire upgrade process in a non-disruptive, rolling fashion. When an administrator initiates a firmware update through LCM, the framework automatically handles putting the node into maintenance mode, live-migrating VMs, shutting down the CVM if necessary, applying the updates, restarting services, and exiting maintenance mode before moving to the next node. Manual intervention as described in the other options is not required and circumvents the built-in safety and automation of LCM.

The correct and recommended approach for creating a logically and potentially physically separate network is to create a new virtual bridge (e.g., br1). This new bridge will then have its own bond (e.g., bond1) composed of the 1GbE physical NICs. VMs that require access to the backup network can then have a vNIC attached to a virtual network created on br1. This ensures complete separation from the primary br0 network. Adding NICs of different speeds to the same bond is not recommended, and adding a second bond to the same bridge does not provide the desired logical separation.

A 'Test Failover' creates a temporary, isolated network bubble for the recovered VMs. The administrator must specify a test network (VLAN) in the recovery plan's network mappings. If this specified VLAN does not exist or is not configured on the hosts at the recovery site, the VMs cannot be attached to a network and will fail to power on. While replication issues can cause failures, a missing test network is a very common and specific cause for this symptom during a test failover.