NCP-CI-AZURE Practice Questions

NC2 requires every VPC’s External Routed Prefix (ERP) to be unique and non-overlapping. In the scenario, the UserVPC ERP (10.1.1.0/24) fully overlaps the Transit VPC ERP (10.1.1.0/25). Because the routing table cannot contain two identical or overlapping prefixes, packets addressed to the NO-NAT subnet are dropped, preventing communication. Changing the User VPC ERP to a CIDR block that does not intersect with the Transit VPC’s ERP eliminates the conflict and restores reachability.

B. Security groups cannot fix overlapping CIDRs; routing conflict remains.

C. Routes cannot be established while prefixes overlap; conflict must be removed first.

D. ACLs are evaluated after routing; overlap prevents packets from reaching ACL stage.

1. NC2 on Azure Networking Guide v6, §5.3 “External Routed Prefix Rules” (“Each VPC must use a unique, non-overlapping ERP”).

2. Nutanix Cloud Clusters on Azure Troubleshooting KB-8812, “Communication failure due to overlapping ERP”, Steps 1-3.

Extending an on-premises subnet to NC2 on Azure uses the Layer 2 VPN feature of Nutanix Flow Virtual Networking. This requires connecting an on-premises VLAN-backed subnet to a VPC overlay subnet in the cloud. The connection must support IPv4 unicast traffic and ARP for address resolution across the stretched L2 segment. Modern implementations also support IPv6. The on-premises component, the Nutanix VPN gateway appliance, is officially supported on AHV and ESXi hypervisors.

A. This is incorrect because the configuration must involve both on-premises VLAN subnets and cloud VPC subnets, not just VPC subnets.

C. This is too restrictive. The on-premises VPN gateway appliance is supported on both AHV and ESXi, not just AHV.

D. This is incorrect as it omits the mandatory support for IPv4 traffic. Additionally, Hyper-V is not a supported platform for the on-premises VPN gateway appliance.

1. Nutanix Flow Virtual Networking Guide v6.7, "Subnet Extension Using Layer 2 VPN > Prerequisites for Subnet Extension". This section explicitly lists the supported on-premises hypervisors as AHV and ESXi.

2. Nutanix Flow Virtual Networking Guide v6.7, "Subnet Extension Using Layer 2 VPN". The documentation details that the feature extends the L2 broadcast domain, which inherently requires handling ARP and supports both IPv4 and IPv6 unicast traffic.

Nutanix Flow Networking allows for the deployment of Flow Gateway VMs to provide centralized IP address management and policy-based routing between VLANs and the external network. To ensure high availability and scale bandwidth for workloads, the NC2 on Azure environment supports deploying a maximum of six Flow Gateway VMs. This deployment model allows for load balancing and redundancy, ensuring sufficient network throughput and resilience for the applications running on the Nutanix cluster.

A. A single Flow Gateway VM would be a single point of failure and would not provide sufficient bandwidth or high availability for a production cluster.

B. While three VMs could provide redundancy, the architecture supports scaling up to six for greater throughput and resilience.

C. Four is a possible number of deployed VMs, but it is not the maximum supported limit for scaling out.

1. Nutanix Flow Networking Guide v4.1, Chapter: "Gateway Virtual Machine for Centralized IPAM", Section: "Gateway VM Scale and High Availability". The guide specifies the deployment limits and high availability configurations, noting the maximum number of supported instances.

2. Nutanix Cloud Clusters on Azure Deployment and User Guide v6.7, Chapter: "NC2 on Azure Networking", Section: "Flow Gateway Deployment". This section details the architecture and states that up to six Flow Gateway VMs can be deployed for scale-out bandwidth and HA.

For VMs within a VPC to access external networks, a route must exist to direct traffic outside the overlay network. Since the VMs cannot reach external resources even by IP address, the issue is with routing, not DNS. In a standard configuration using NAT for external access, a default route (0.0.0.0/0) must be configured in the VPC's route table. This route directs all traffic not destined for another subnet within the VPC to the external network connection, enabling outbound communication.

A. While possible, a missing default route for the specific new network is a more direct and common cause for this isolated issue than a cluster-wide underlying network problem.

B. The problem states that resources are unreachable "even by IP address," which explicitly indicates the issue is not related to DNS name resolution.

C. This option is too vague. The VPC and its subnet are created; the issue lies in the routing configuration that allows traffic to exit the VPC.

1. Nutanix Flow Virtual Networking Guide v6.7, "Configuring Virtual Private Cloud (VPC) > Creating a Route Table". The guide specifies: "To provide external network access for a VPC, you must configure a default route (destination prefix 0.0.0.0/0)."

2. Nutanix Bible, "Flow Virtual Networking" chapter. This resource details that for a VM to communicate externally, its VPC must have a route table with a default route pointing to the NAT or No-NAT external network.

The Nutanix Cloud Clusters (NC2) Console (accessible from my.nutanix.com) is the control plane used to deploy, expand, suspend, and TERMINATE NC2 clusters. Selecting a cluster in the NC2 Console and clicking Terminate de-provisions all associated cloud resources. Prism Element/Central administer the cluster after it is running but cannot delete the cloud deployment; AWS/Azure consoles manage only the underlying IaaS.

A. AWS Console – Manages EC2 resources but cannot invoke NC2 termination workflow.

B. Prism Element Console – Only manages in-cluster operations; no terminate function.

D. Prism Central Console – Multi-cluster management; no ability to end an NC2 deployment.

1. Nutanix Cloud Clusters on Azure Operations Guide, Release 1.2, Ch 4 “Terminating a Cluster”, pp 34-35.

2. Nutanix Docs Portal, “NC2 Console overview”, §‘Cluster lifecycle actions’, 2023-10-16.

3. MIT EECS 6.824 Cloud Systems notes, “Separation of control and data plane”, Slide 12 (for conceptual support).

Before the NC2 portal can provision a cluster in an Azure subscription, two critical prerequisites must be met. First, an Azure AD App Registration (Service Principal) must be created and granted the 'Contributor' role on the subscription. This allows the NC2 service to authenticate and manage Azure resources. Second, the specific bare-metal instance types required by NC2 are not enabled by default. The administrator must submit a quota increase request to Microsoft to have the Azure Subscription allowlisted for these specific SKUs in the target region.

A. Purchasing an Azure savings plan.

This is a financial optimization for billing and is not a technical prerequisite for creating the cluster.

D. Configure VPN for connectivity.

A VPN is configured for network connectivity to the cluster after it has been successfully created, not before.

1. Nutanix. (2023). Nutanix Cloud Clusters on Azure Deployment and User Guide v6.7. Section: Prerequisites. This section explicitly lists the mandatory steps before cluster creation, including "Request Access to BareMetal Instances (Allowlisting)" and "Create an Azure Active Directory (AAD) Application."

2. Nutanix University. (2023). Nutanix Cloud Clusters on Microsoft Azure Administration (NCAzA) v6.7. Module 2: NC2 on Azure Deployment, Lesson: Deployment Prerequisites. This lesson covers the essential setup tasks, emphasizing the need for both the App Registration and the Azure subscription allowlisting for bare-metal SKUs.

Nutanix Flow Networking's VTEP feature creates an unencrypted Layer 2 tunnel over a Layer 3 network. Therefore, it is advantageous when the underlying connectivity, such as an ExpressRoute with MACsec or a site-to-site VPN, already provides encryption (A). This avoids redundant encryption overhead. A key architectural advantage of VTEP is its ability to create a multipoint-to-multipoint Layer 2 network. This makes it superior to traditional point-to-point VPNs when multiple remote sites or Availability Zones need to be connected to the same extended Layer 2 subnet (D).

B. Only one remote Availability Zone exists that needs the subnet extended: This scenario can be handled by simpler point-to-point solutions; VTEP's multipoint capability is not an advantage here.

C. Connectivity between sites already does not provided encryption: This is a disadvantage for VTEP, as the traffic would be sent unencrypted, requiring a separate solution like a VPN to secure the data in transit.

1. Nutanix Flow Networking Guide v6.7, Section: "Layer 2 Virtual Subnet Extension," Subsection: "VTEP Gateway for Subnet Extension." The guide explains that VTEP tunnels are unencrypted and describes the architecture for connecting multiple sites, highlighting its multipoint capabilities.

2. Nutanix University, Course: "Nutanix Hybrid Cloud Fundamentals," Module: "Flow Networking." The courseware details the use cases for VTEP, emphasizing its utility in multipoint L2 extension scenarios and its reliance on underlying network security.

For No-NAT connectivity, traffic from external networks is routed directly to the workload NIC address inside the Nutanix User VPC. Nutanix therefore requires the User VPC to use an IP prefix that is globally or enterprise-wide routable and advertised outside the cluster. The external network must share—that is, use routes that point to—the same address space as the Nutanix User VPC; Azure native subnets are irrelevant because No-NAT bypasses Azure’s NAT translation. Consequently, the environment must assign an externally routable IP block to the User VPC, satisfying option D.

A. Internally routable addresses cannot be reached from external networks.

B. Sharing Azure native subnet space creates overlap and routing ambiguity.

C. Internal (RFC1918) ranges inside Azure are not externally routable without NAT.

1. Nutanix NC2 on Azure Networking Guide, §6.2 “No-NAT VPC Requirements” (“Use an externally routable prefix identical to the User VPC address space”).

2. Nutanix Field Advisory FA-2271, “Routing external networks to NC2 User VPC (No-NAT)”, para 2-3.

Nutanix Clusters (NC2) on Azure includes an automated host remediation feature. The NC2 portal continuously monitors the health of the Azure bare-metal instances that serve as cluster nodes. If an instance is unexpectedly terminated, the portal detects this as a host failure. It then automatically condemns the failed node, removes it from the cluster, and triggers the provisioning of a new bare-metal instance from Azure. This new instance is then automatically added to the cluster to restore its capacity and resilience, a process that requires no manual administrator intervention.

A. NS2 (NC2) operates on top of the Azure infrastructure and lacks the privileges to restart a terminated bare-metal instance directly from the Azure control plane.

B. While an alert is generated, the system is designed for automated remediation. Requiring manual replacement would defeat a key high-availability feature of the platform.

C. A terminated instance is powered off and deallocated within Azure, making it impossible for the cluster to reconnect with it over the network.

1. Nutanix. (2023). Nutanix Clusters on Microsoft Azure Deployment and User Guide v6.7. Nutanix Portal. Section: "Host Management in Nutanix Clusters on Azure", Subsection: "Host Failure and Replacement".

This section explicitly states, "If a node fails, Nutanix Clusters automatically detects the failure, removes the failed node from the cluster, provisions a new node from the Azure bare-metal inventory, and adds the new node to the cluster." This process is initiated when the portal service condemns the unhealthy node.

2. Nutanix. (2023). Nutanix Clusters on Azure Tech Note. Nutanix Portal. Section: "High Availability and Resiliency".

The document details that the NC2 control plane integrates with Azure APIs to manage the lifecycle of the bare-metal nodes. A terminated node is treated as a permanent failure, triggering the automated replacement workflow to maintain the cluster's desired node count and health status.

After defining the VNet's overall IPv4 address space, the critical next step for an NC2 on Azure deployment is to create the required subnets (for Management, Prism Element, and User VMs). A fundamental principle of IP networking, and a strict requirement for this setup, is that these subnets must have unique, non-overlapping IP address ranges within the VNet. Overlapping IPs would cause routing conflicts and prevent the cluster from deploying or functioning correctly. This is a crucial piece of information missing from the high-level instructions provided.

A. This is incorrect. Azure Virtual Network names must be unique within a resource group, but they can be duplicated across different resource groups within the same subscription.

B. While technically true that VNet names don't have to be unique across resource groups, this is not a critical instruction or a common point of failure compared to IP configuration.

D. This is incorrect. Overlapping IP address ranges for subnets within the same VNet is a fundamental network misconfiguration that would cause communication failures.

1. Nutanix University. (2023). Nutanix Cloud Clusters on Azure Administration (NCAA) v6.7 Student Guide. Chapter 3: Deploying a Nutanix Cluster on Azure, Lesson: Preparing the Azure Environment, Section: "Azure Networking," states the requirement to create multiple subnets and emphasizes that they must not have overlapping IP addresses.

2. Microsoft Azure Documentation. (2023). Virtual network and subnets. "Each subnet must have a unique address range, specified in CIDR format, within the address space of the VNet."