NCP-NS Practice Questions

Enabling jumbo frames (MTU of 9000) requires an end-to-end configuration across the entire network path. The process must begin with the underlying physical network infrastructure. If the physical switches are not configured to support the larger MTU size, any jumbo frames sent from the Nutanix hosts will be dropped or fragmented, leading to severe performance degradation or complete connectivity loss. Therefore, configuring the physical switches is the foundational and prerequisite step before modifying any settings within the Nutanix AHV hosts, CVMs, or user VMs. This ensures the physical transport layer is prepared to handle the increased packet size.

A. Configure the MTU on the user VMs.

This is a later step. Configuring VMs first without preparing the underlying virtual and physical network will cause their jumbo frame packets to be dropped.

B. Configure the MTU on the Controller VMs (CVMs).

This is also incorrect. The CVMs rely on the same host and physical network stack, which must be configured for jumbo frames first to ensure storage traffic is not disrupted.

C. Configure the MTU on the virtual switch in Prism Element.

This step configures the host's virtual networking, but it must be preceded by configuring the physical switches to which the host's physical NICs connect.

1. Nutanix University - Nutanix Hybrid Cloud Fundamentals Courseware: In the networking module, the principle of end-to-end MTU consistency is emphasized. The courseware explains that network configuration starts from the physical layer (switches) and moves up to the hypervisor and virtual machines to ensure compatibility.

2. Nutanix AHV Networking Best Practices Guide: In the section "Jumbo Frames," the guide states, "To use jumbo frames, you must configure the physical network, all the AHV hosts, and all the UVMs for jumbo frames." This implies a specific order, starting with the physical network as the foundation.

3. Prism Web Console Guide (for AOS 6.5): In the "Network Management" section, under "Managing a Virtual Switch (AHV)", the procedure for setting the MTU on a virtual switch is detailed. This action assumes the upstream physical network devices are already configured to support the desired MTU. The guide focuses on the Nutanix-level configuration, which is dependent on the external physical network configuration.

The most likely reason is that the VPC's high availability is configured in Active/Standby mode. In this configuration, only one gateway node is active at any given time and is responsible for establishing all BGP sessions and forwarding traffic. The second gateway node operates in a passive, standby role. It remains healthy and ready to take over but will not establish its own BGP session until a failover event occurs with the active node. This design ensures a single, predictable routing path while providing redundancy.

A. The external router's AS number is misconfigured.

This would prevent even the first session from establishing correctly. The question states one session is already successful.

B. The second gateway requires a unique BGP policy.

BGP configuration, including policies, is applied at the VPC level and is shared by all gateway nodes within that VPC, not configured individually.

C. The external router's firewall is blocking the second session.

While possible, the inherent behavior of the Nutanix Active/Standby mode is a more direct and architecturally certain cause than an external network issue.

References

1. Nutanix Flow Virtual Networking Guide v4.0 | VPC High Availability:

Reference: In the section on VPC High Availability, the documentation states: "In an active/standby high availability configuration, one gateway VM is active and the other is in standby mode. The active gateway VM forwards traffic for the VPC and establishes BGP sessions with external routers. The standby gateway VM monitors the active gateway VM and takes over its role if the active gateway VM fails." This directly confirms that only the active node will establish a BGP session.

2. Nutanix University | Nutanix Certified Professional - Network Security (NCP-NS) Courseware:

Reference: The official training material for the NCP-NS certification covers VPC architecture and routing. In the module on Flow Virtual Networking, it explains that the default high availability mode for a VPC is Active/Standby, where only the active gateway VM peers with external BGP routers to prevent routing instability, while the standby VM remains passive until needed.

1. Nutanix Flow Virtual Networking Guide 6.5, “Configure eBGP Peering – High Availability with Multiple Gateways,” steps 4-5: “Create a separate neighbor on the external router for each gateway; otherwise only the configured neighbor will establish.”

2. Nutanix AHV Networking Reference v6.1, p. 42, Table “Gateway BGP Peering Requirements” – “One BGP session is formed per gateway; external devices must define one neighbor per gateway IP.”

3. Nutanix AOS Administration Guide 6.5, Chapter “Network Gateways,” note under “Adding a Second Gateway” – “External routers require an additional neighbor statement to peer with the new gateway.”

Enabling Flow Virtual Networking on a Prism Central instance adds network controller and visualization services. To support this additional workload, each Prism Central VM in the deployment must be scaled up. For a Small Prism Central deployment, the standard configuration of 6 vCPUs and 26 GB of memory is increased to 8 vCPUs and 32 GB of memory. This results in an additional resource requirement of 2 vCPUs and 6 GB of memory per Prism Central VM. This ensures the Prism Central instance has sufficient resources to manage both its core functions and the demands of network virtualization and security policy enforcement.

(Assuming the following options based on the provided correct answer 'C')

A. 1 vCPU and 4 GB Memory: This option understates the required vCPU and memory increase for the network controller services.

B. 2 vCPU and 4 GB Memory: This option correctly identifies the vCPU increase but understates the additional memory required for Flow Virtual Networking services.

D. 4 vCPU and 8 GB Memory: This option overstates the resource increase, which corresponds more closely to enabling advanced features on a Large Prism Central deployment, not a Small one.

1. Nutanix Prism Central Guide (pc-2023.4): In the "Prism Central Resource Requirements" section, the table "Prism Central VM Resources" specifies that a Small instance requires 6 vCPUs/26 GB Memory, but with Flow Virtual Networking, it requires 8 vCPUs/32 GB Memory. The difference is +2 vCPU and +6 GB Memory.

2. Nutanix Flow Virtual Networking Guide (vnet-2023.4): In the "Prerequisites" or "Deployment Checklist" section, it states that Prism Central must meet the minimum resource requirements for Flow Virtual Networking, and refers to the Prism Central sizing documentation. It confirms that enabling the feature increases the resource footprint of the Prism Central VM.

The question specifically asks to restrict "intra-tier" communication. In Nutanix Flow Network Security, the concept of "tiers" (e.g., Web, App, DB) is exclusive to Application Security Policies. While an Isolation Policy also blocks communication between VMs in a group, it does not use the "tier" construct. Therefore, the question's terminology points directly to an Application Policy. By default, an Application Policy allows all traffic within the same tier. To meet the requirement, the administrator must create an Application Policy, place the VMs into a single tier, and then explicitly add a rule to block traffic from that tier to itself.

Isolation Policy: This policy type does block intra-group communication by default, but it does not use the concept of "tiers," making it a less precise answer for the specific terminology used.

Quarantine Policy: This is used for the temporary and immediate isolation of a specific VM that is suspected of being compromised, not for defining permanent application segmentation rules.

VDI Policy: This is a specialized policy designed specifically for securing Virtual Desktop Infrastructure (VDI) environments and is not the correct tool for general-purpose VM segmentation.

1. Nutanix Flow Network Security Guide v6.8, Chapter: Security Policy Management, Section: Application Security Policy

"An application security policy secures an application by limiting the inbound and outbound traffic of the application... By default, all traffic is allowed between VMs in the same tier. To block traffic between VMs in the same tier, you must create a rule that denies traffic from the tier to itself." This confirms that an Application Policy is used to manage intra-tier traffic and requires a specific rule to block it.

2. Nutanix Flow Network Security Guide v6.8, Chapter: Security Policy Management, Section: Isolation Security Policy

"An isolation policy separates a group of VMs from the rest of the network... The VMs in the isolated group cannot communicate with each other." This highlights that while the outcome is similar, the terminology and construct (group vs. tier) are different from what the question specifies.

The most efficient and logical method is to create a single Application Security Policy centered on the application tier. This policy secures the Application VMs by defining specific inbound and outbound rules based on categories.

1. Secured Group: The Application VMs are defined as the application to be secured.

2. Inbound Rule: An inbound rule allows traffic from the Frontend VMs category on TCP port 8080.

3. Outbound Rule: An outbound rule allows traffic to the Database VMs category on TCP port 3306.

This single policy enforces the required communication paths while adhering to the principle of least privilege, as all other traffic is implicitly denied.

Using multiple policies: Creates unnecessary complexity and management overhead compared to a single, consolidated application policy for the entire application.

Using an Isolation Policy: This policy type is incorrect as it would block all traffic to and from the specified VMs, preventing the required inter-tier communication.

Incorrectly defining rules: Placing all rules as only inbound or only outbound would fail to model the complete 3-tier traffic flow correctly and violate the requirements.

1. Nutanix Flow Networking Guide (v6.8): In the "Application Security Policy" section, it states, "An application policy secures a group of VMs. You can define rules to control inbound and outbound traffic for the secured group of VMs." This directly supports creating a policy with both inbound and outbound rules for the central application tier. (Reference: Flow Networking Guide, Chapter: "Security Policies", Section: "Application Security Policy").

2. Nutanix University - Nutanix Hybrid Cloud Fundamentals Course: The module on Flow Networking and Microsegmentation explains that the best practice for multi-tier applications is to create a single application policy. This policy defines the application at its core and then specifies the allowed communication paths to and from other tiers using inbound and outbound rules. (Reference: Nutanix Hybrid Cloud Fundamentals, Module: "Flow Networking and Microsegmentation").

The Network Controller is the core component that enables and manages the Virtual Private Cloud (VPC) infrastructure within Nutanix Flow Virtual Networking. Disabling the Network Controller is a destructive operation that removes this entire software-defined network overlay. Before the system allows this action, all dependent resources that the Network Controller manages must be removed. This includes all virtual machines connected to VPC subnets, the subnets themselves, and finally, the VPCs. This ensures a clean removal of the networking stack without leaving orphaned or non-functional network configurations.

A. Migrate all VMs to a different cluster: This is incorrect. VMs must be removed from the VPC subnets, but migrating them to another cluster is not a mandatory prerequisite for disabling the local Network Controller.

B. Disable Flow Microsegmentation: This is incorrect. Flow Microsegmentation (for security policies) and Flow Virtual Networking (for VPCs) are distinct features. Disabling one does not require disabling the other.

C. Place the CVMs in maintenance mode: This is incorrect. Controller VM (CVM) maintenance mode is used for node-specific hardware or software maintenance and is unrelated to disabling a cluster-wide virtual networking feature.

1. Nutanix Flow Virtual Networking Guide v4.0: In the section "Disabling Flow Virtual Networking," the guide explicitly states the prerequisite: "You can disable Flow Virtual Networking only after you delete all the VPCs and subnets." It then lists the required steps in order: 1. Delete all the VMs that are connected to the VPC subnets. 2. Delete all the subnets. 3. Delete all the VPCs. 4. Disable Flow Virtual Networking. (Reference: Nutanix Portal > Documentation > Software Documentation > Flow Virtual Networking)

Enabling the Transit VPC toggle configures the VPC to function as a central hub in a hub-and-spoke network topology. This transit hub is designed to route traffic between multiple connected "spoke" VPCs and can also provide a centralized point of connectivity to external networks. This architecture simplifies network management and scaling by eliminating the need to create a complex full-mesh of connections between all VPCs. All inter-VPC traffic flows through the central transit VPC for routing and policy enforcement.

(These explanations are based on plausible but incorrect functions for the other options.)

A. It enables direct peering with all other VPCs in a full mesh.

This is incorrect. The Transit VPC creates a hub-and-spoke model specifically to avoid the complexity of a full-mesh topology.

C. It isolates the VPC from all external and internal networks.

This is incorrect. The purpose of a Transit VPC is the opposite; it is designed to connect and route traffic between multiple networks.

D. It automatically applies a quarantine security policy to the VPC.

This is incorrect. Security policies are configured independently using Flow Network Security (formerly Flow Microsegmentation) and are not a function of the Transit VPC role.

1. Nutanix Flow Virtual Networking Guide v4.0: In the section "VPC-to-VPC Connectivity with Transit VPC," the documentation states, "Flow Virtual Networking allows you to create a transit VPC that functions as a central hub for networking and security services. You can connect one or more spoke VPCs to a transit VPC. The transit VPC acts as a centralized entity that routes traffic between the connected spoke VPCs and the external network."

2. Nutanix Flow Virtual Networking Guide v4.0: The same section further clarifies the benefit: "A transit VPC simplifies network management by removing the need for a full-mesh connection between all the VPCs." This directly refutes the idea of creating a full mesh.

Nutanix Flow's service insertion feature redirects traffic to an NFVM to act as a transparent, in-line service. This "bump-in-the-wire" model requires two interfaces for traffic processing: one for ingress (receiving traffic from the source) and one for egress (sending processed traffic toward the destination). For the redirection to be transparent at Layer 2, both of these vNICs must be connected to the same network/VLAN. This allows the NFVM to inspect or modify traffic without altering the IP-level path, as the source and destination VMs remain unaware of the redirection.

One vNIC: A single vNIC is insufficient for an in-line service, as it lacks separate ingress and egress paths, which would cause traffic to loop or be dropped.

Two vNICs on different VLANs: This configuration would require the NFVM to act as a router (Layer 3 device), which contradicts the transparent Layer 2 insertion model used by Flow service chaining.

Three or more vNICs for traffic redirection: While an NFVM can have additional vNICs (e.g., for management), the service chain function itself only requires and uses two specific vNICs for the redirected traffic path.

1. Nutanix Flow Network Security Guide v6.8: In the "Service Chaining" section, under "Network Function VM," the guide states, "The network function VM must have at least two vNICs connected to the same network. One vNIC receives traffic from the source (the left vNIC) and the other vNIC sends the traffic to the destination (the right vNIC)." (Section: Service Chaining > Network Function VM)

2. Prism Central Infrastructure Guide v6.8: The procedure for creating a service chain details the configuration of the NFVM. It requires the administrator to specify a "Left vNIC" and a "Right vNIC" for the VM, reinforcing the two-interface requirement for the data path. (Section: Security Management > Flow Network Security > Creating a Service Chain)

The security policy is applied to a category (AppType: Web-DB) that contains both web and database servers. The option "Allow traffic between VMs within the category" is enabled, which creates a permissive rule allowing all VMs within that category to communicate freely with each other. This setting overrides any more specific inbound or outbound rules and is the direct cause of the web servers being able to communicate. To enforce the principle of least privilege and prevent web-to-web communication, this general allowance must be disabled. The administrator can then create a specific inbound rule to allow the required DB-to-DB traffic.

A. Change the policy to Monitor mode.

Monitor mode only logs traffic and does not block it; this would not prevent the web servers from communicating.

C. Create a separate policy for the web servers.

This is inefficient and does not fix the fundamental flaw in the existing policy, which is overly permissive.

D. Change the policy to Apply to a different category.

This action would simply move the misconfigured policy to a different set of VMs without correcting the incorrect rule logic.

1. Nutanix Flow Network Security Guide v4.0: In the "Creating an Application Security Policy" section, the guide describes the policy configuration options. It states, "To allow traffic between all the VMs in the secured group, check the Allow traffic between VMs within this category checkbox." This confirms that checking this box permits all intra-category traffic, which is the issue described in the scenario. (Reference: Nutanix Flow Network Security Guide, Chapter: "Security Policy Management", Section: "Creating an Application Security Policy").

2. Nutanix University - Nutanix Enterprise Cloud Administration (ECA) 6.5 Courseware: The module on Flow Network Security explains that application policies are designed for zero-trust environments. The "Allow traffic between VMs" option is a convenience that should be used with caution, as it bypasses the zero-trust model for all VMs within the specified category. The correct approach for the scenario is to disable this and create explicit allow rules. (Reference: ECA 6.5 Courseware, Module: "Securing the Cluster with Flow Network Security").

In a Nutanix Flow Networking hub-and-spoke topology, each subnet within a user (spoke) VPC is associated with a route table. For traffic from a subnet to reach an external network via the transit (hub) VPC, its route table must contain a route (typically a default route 0.0.0.0/0) that directs traffic to the transit VPC connection. Since other subnets are working correctly, the overall VPC peering and external connectivity are functional. The issue is isolated to one subnet, making a misconfiguration in that specific subnet's route table the most probable cause.

A. The VPC peering connection to the Transit VPC is down.

This would disrupt connectivity for all subnets within the user VPC, not just a single one.

C. The external network route is not advertised from the Transit VPC.

This would prevent all subnets in the user VPC from learning the path to the external network.

D. A Flow Network Security policy is blocking all outbound traffic from the VPC.

This policy would affect the entire VPC. While a policy could target a single subnet, a missing route is a more fundamental and direct cause for a reachability failure.

References:

1. Nutanix Flow Networking Guide v4.0, Chapter: VPC Configuration, Section: VPC Route Tables

"Each subnet in a VPC must be associated with a route table. A subnet can be associated with only one route table at a time, but a route table can be associated with multiple subnets." This establishes the per-subnet granularity of routing policy.

"To enable spoke VPCs to communicate with the external network through the hub (transit) VPC, you must add a default route (0.0.0.0/0) in the spoke VPC route tables with the next hop as the hub VPC." This directly states the requirement that is missing in the scenario described by the correct answer.

2. Nutanix University, Nutanix Hybrid Cloud Fundamentals Course, Module: Flow Virtual Networking

The courseware explains that for spoke VPCs to access networks outside the Nutanix environment (like the internet or a corporate WAN), a default route must be configured in the spoke VPC's route table, pointing to the transit VPC as the next hop. The absence of this route for a specific subnet's route table isolates the failure to that subnet.

1. Nutanix® Flow Virtual Networking Guide v.2023.1, “Create or Edit Subnet – Advertise Prefix Externally”, p. 72–73.

2. Same guide, “Transit VPC Routing and Prefix Export”, p. 116–118 – notes that only advertised prefixes are installed in the Transit VPC route-table.

3. Nutanix AOS 6.5 Prism Central Admin Guide, Section “Prefix Advertisement and Route Propagation”, p. 302–304 – explains effect of disabling advertisement on reachability beyond local VPC.