Free 2V0-41.24 Practice Test Questions 2026

Explanation:

The nsxcli session timeout is a security feature that automatically logs out idle CLI sessions. By default, this timeout is set to 600 seconds (10 minutes) to prevent unauthorized access to an unattended management session . The administrator needs to disable this feature entirely so that CLI sessions no longer time out.

Why other options are incorrect:

A. set cli-timeout 1 – Incorrect.
While this command is syntactically valid, setting the timeout to 1 second is the opposite of disabling it. It would cause the session to disconnect after only one second of idle time, making the CLI nearly unusable. The question specifically asks for the command that disables the timeout, not changes its value.

B. set cli-timeout enabled – Incorrect.
The set cli-timeout command does not accept enabled or disabled as arguments. It only accepts a numerical value (seconds). Using this syntax would result in a command error, as the NSX CLI expects an integer for the timeout value .

C. set cli-timeout disabled – Incorrect.
Similar to option B, disabled is not a valid argument for the set cli-timeout command. VMware commands typically use numerical values (0 to disable) rather than boolean flags for timeout settings . This command would fail to execute.

Reference

VMware NSX CLI Guide– The set cli-timeout command is documented with the note: "Set inactivity timeout in seconds. To disable the timeout, specify 0"

VMware NSX-T Data Center REST API – The NodeProperties schema includes cli_timeout as an integer property with the description "NSX CLI inactivity timeout, set to 0 to configure no timeout"

Explanation:

A key advantage of an L2 VPN in an NSX 4.x environment is the ability to stretch Layer 2 networks across multiple geographic sites while maintaining the same broadcast domain . When a Layer 2 VPN is implemented, the extended network operates as a single subnet with one broadcast domain, meaning virtual machines (VMs) retain their original IP addresses when moved between sites . This provides significant operational benefits for workload mobility and disaster recovery scenarios.

Why other options are incorrect:

A. Achieve better performance – Incorrect.
While L2 VPN can provide functional connectivity, the documentation does not claim better performance as an advantage. In fact, performance considerations such as Path MTU Discovery (PMTUD) are discussed as features to help avoid fragmentation , but performance is not highlighted as a primary benefit. L2 VPN introduces encapsulation overhead that can potentially impact performance rather than improve it.

C. Enables Multi-Cloud solutions – Incorrect.
While L2 VPN can be used in hybrid scenarios (such as connecting on-premises NSX to VMC), enabling multi-cloud solutions is not the primary advantage cited in VMware's official documentation. The documentation focuses on extending L2 networks across sites, data center migration, and disaster recovery use cases . Some exam discussion sources note that L2 VPN "enables hybrid cloud solutions" , but "multi-cloud" is broader than hybrid cloud and is not listed as a core advantage.

D. Enables VM mobility with re-IP – Incorrect.
This option is factually backward. L2 VPN does the opposite of requiring re-IP. The documentation explicitly states that when VMs are moved using L2 VPN, "their IP addresses remain unchanged" . Preserving IP addresses is a key advantage, not requiring re-IP . Re-IP would indicate network reconfiguration is needed, which defeats a primary purpose of L2 VPN extension.

Reference

Broadcom TechDocs – "Understanding Layer 2 VPN": L2 VPN extends Layer 2 networks "across multiple sites on the same broadcast domain"; VMs remain on the same subnet with unchanged IP addresses when moved

Explanation:

The set ntp-server command is the correct CLI command to configure NTP (Network Time Protocol) server settings on both NSX Manager and NSX Edge appliances. This command establishes time synchronization with designated NTP servers, which is critical for ensuring consistent timestamps across logs, certificates, and event correlation.

Why other options are incorrect:

A. set timezone – Incorrect.
This command sets the system time zone (e.g., America/Los_Angeles), not NTP server configuration. Timezone and NTP serve different purposes: time zone defines local time display, while NTP synchronizes the actual system clock with time servers . The set timezone command would not configure an NTP server address.

C. get timezone – Incorrect.
This is a get command (used for viewing, not modifying configuration) and it displays the current time zone setting, not NTP servers. The question specifically asks for a command to "change NTP settings," which requires a set (configuration) command, not a get (viewing) command.

D. get time-server – Incorrect.
There is no standard get time-server command in NSX CLI. The correct command to view NTP configuration is get ntp-server . Additionally, like option C, this is a get command for viewing, not changing, settings.

Reference

VMware NSX 4.x Administration Guide– "Configuring Appliances": The table of CLI commands explicitly lists set ntp-server as the command for configuring NTP servers on NSX Manager and NSX Edge nodes

VMware Documentation – "Configure a Node Profile": Verification commands include get ntp-server to confirm NTP configuration

Explanation:

To make NSX Edge services available to a VM on a VLAN-backed logical switch, a VLAN Uplink must be configured on the Tier-0 Gateway. The VLAN Uplink serves as the external interface that connects the Tier-0 Gateway to the physical network infrastructure, enabling communication between logical networks within NSX and external networks .

Why other options are incorrect:

B. Downlink interface – Incorrect.
A downlink interface connects Tier-0 Gateway to Tier-1 Gateways for internal routing within the NSX environment. It is not used for connecting to VLAN-backed switches for external Edge services. The documentation explicitly describes that "Tier-0 gateway has downlink connectivity to Tier-1 gateways and external connectivity to the physical network" . The downlink is for internal north-south communication, not for exposing Edge services to VLAN-backed VMs.

C. Loopback Router Port – Incorrect.
A loopback interface is a virtual interface with no physical association, typically used for management or as a stable endpoint for dynamic routing protocols like BGP. It does not provide connectivity from the Tier-0 Gateway to a VLAN-backed logical switch. Loopback ports cannot forward traffic to or from physical network segments.

D. Service interface – Incorrect.
A service interface (also known as LogicalRouterCentralizedServicePort) is indeed used to apply stateful services to traffic , and VMware documentation confirms that "stateful services can be applied on this port" . However, a service interface is not used for the initial connection to a VLAN-backed switch. It is an additional construct that may be implemented after the uplink is configured. The fundamental requirement to establish connectivity between the Tier-0 Gateway and the VLAN-backed logical switch remains the configuration of a VLAN Uplink.

Reference

VMware NSX Documentation – To create an NSX Edge uplink, you must connect a Tier-0 router to a VLAN switch

Broadcom TechDocs – Tier-0 Gateway external interfaces (VLAN Uplinks) are configured by selecting the "External" type and connecting to a VLAN segment

VMware API Documentation – LogicalRouterCentralizedServicePort (service interface) is distinct from uplink ports and does not replace the need for VLAN uplink connectivity

Explanation:

NSX Network Detection and Response (NDR) collects events from multiple sources within the NSX environment to correlate related threat events into intrusion campaigns. According to official VMware documentation, NDR relies on three primary event types, each originating from specific NSX features.

A. Files and anti-malware (file events from the NSX Edge nodes and the Security Analyzer) – Correct.
Malicious file events are collected from Edge appliances when the NSX Malware Prevention feature is activated. These events include file transfers that are identified as containing malware, providing critical data for campaign correlation rules such as "File Transfer (Hash-Based)" and "Successful File Infection Rule".

C. Distributed Firewall flow data from the ESXi hosts – Correct.
Distributed Firewall flow data provides visibility into traffic patterns and potential malicious activity. The Suspicious Traffic feature in Security Intelligence collects network traffic flow data from enabled NSX workloads (hosts or clusters of hosts). This data is stored and analyzed to detect suspicious network behaviors that contribute to campaign correlation.

D. IDS/IPS events from the ESXi hosts and NSX Edge nodes – Correct.
IDS events are collected from Distributed IDS when the NSX IDS/IPS feature is activated. These events include network signature detections for threats such as command and control, drive-by attacks, and malware distribution. Correlation rules like "IDS Command and Control Wave Rule" and "IDS Drive-by Wave Rule" use these events to identify attack waves across multiple hosts.

Why other options are incorrect:

B. East-West anti-malware events from the ESXi hosts – Incorrect.
While anti-malware events are collected, the official documentation specifies that malicious file events are collected from Edge appliances, not directly from ESXi hosts for East-West traffic. The NSX Malware Prevention feature operates on Edge nodes for north-south traffic analysis. East-West malware prevention is a related but distinct feature with different data sources.

E. Suspicious Traffic Detection events from NSX Intelligence – Incorrect.
This option contains a category error. NSX Network Detection and Response collects network traffic anomaly events from VMware NSX Intelligence when the Suspicious Traffic detectors are activated. However, "Suspicious Traffic Detection events" is not the correct terminology. The documentation consistently refers to "network traffic anomaly events" from NSX Intelligence. The Suspicious Traffic feature is part of Security Intelligence, but the events themselves are anomaly events, not a separate category called "Suspicious Traffic Detection events".

Reference

Broadcom TechDocs – "Overview of NSX Network Detection and Response": The table of event types explicitly lists malicious file events (Edge appliances), IDS events (Distributed IDS), and network traffic anomaly events (NSX Intelligence) as the three data sources

Broadcom TechDocs – "Campaign Correlation Rules": Details how file events, IDS events, and anomaly events are correlated using rules such as "Anomaly Event," "File Transfer," and "IDS Wave" rules

Explanation:

In VMware NSX, centralized logging is achieved by forwarding logs from NSX nodes (Managers, Edges, and ESXi transport nodes) to a central log aggregation server. Among the options provided, two specific tools are used for this purpose:

A. Syslog Server – Correct.
NSX natively supports forwarding logs to standard syslog servers. You can add syslog servers for NSX nodes using the Node Profiles page in NSX Manager, with support for TCP, UDP, and LI (Log Insight) protocols. Additionally, CLI commands like set logging-server allow configuration of syslog forwarding with various protocols and log levels directly on NSX Edge nodes.

C. VMware Aria Operations for Logs – Correct.
This is VMware's purpose-built centralized log management and analytics solution (formerly known as vRealize Log Insight). NSX is designed to integrate directly with Aria Operations for Logs, with a dedicated "LI" protocol option available when configuring syslog servers in NSX. VMware Cloud Director can also be configured to use Aria Operations for Logs as a log provider for monitoring edge gateway and distributed firewall rule logs. VMware knowledge base articles specifically address scenarios where NSX DFW logs are not forwarding to Aria Operations for Logs and provide resolution steps.

Why other options are incorrect:

B. VMware Aria Automation – Incorrect.
VMware Aria Automation (formerly vRealize Automation) is a multi-cloud automation platform for deploying and managing infrastructure and applications. It is not a logging or log aggregation tool. While it may integrate with logging solutions, it does not itself provide centralized logging functionality for NSX.

D. VMware Aria Operations for Networks – Incorrect.
VMware Aria Operations for Networks (formerly vRealize Network Insight) is a network visibility and analytics tool. It provides network flow monitoring, path visualization, and security planning, but it is not a centralized logging solution for NSX. It does not collect or aggregate syslog events from NSX components.

E. VMware Aria Operations – Incorrect.
VMware Aria Operations (formerly vRealize Operations) is a performance and capacity management platform. While it can collect metrics from NSX for monitoring purposes, it is not designed as a centralized logging solution. The GitHub repository example referenced in search results uses Aria Operations for metrics collection, not log aggregation.

Reference

Broadcom TechDocs – "Add Syslog Servers for NSX Nodes": Specifies that NSX nodes can forward logs to syslog servers using TCP, UDP, or LI (Log Insight) protocols

Broadcom TechDocs – "Configure All NSX Nodes to Forward Logs to VMware Aria Operations for Logs": Explicitly describes configuring NSX nodes to send logs to Aria Operations for Logs

Explanation:

Low throughput and congestion between the Tier-0 Gateway and upstream physical routers indicate that the existing Edge node resources or path diversity is insufficient for the traffic load. Two effective architectural and capacity adjustments can address this issue.

A. Configure ECMP on the Tier-0 gateway. – Correct.
Equal-Cost Multi-Path (ECMP) on the Tier-0 gateway allows traffic to be distributed across multiple equal-cost paths to the upstream physical routers. This distribution, based on a 5-tuple hash (source/destination IP, source/destination port, protocol), enables better utilization of all available uplinks and Edge nodes, preventing a single path or node from becoming congested . When multiple Edge nodes are present in the Tier-0 cluster, ECMP ensures that traffic is balanced across them. If one Edge node experiences congestion, ECMP helps redirect flows away from the overloaded path. However, note that ECMP hashing distributes flows, not individual packets, so a single very high-bandwidth flow will still use only one path .

C. Deploy Large size Edge node/s. – Correct.
Edge node size directly impacts throughput capacity. The official system requirements specify that a Large Edge node (32 GB memory, 8 vCPUs) is suggested when total throughput requirements are between 2 and 10 Gbps . A Medium Edge node (8 GB memory, 4 vCPUs) is only rated for requirements under 2 Gbps . If an administrator observes congestion, it is possible the Edge node is undersized for the traffic volume. Upgrading to Large (or Extra Large for >10 Gbps requirements) provides more vCPUs for packet processing, more memory for stateful connection tracking, and increased queue capacity for handling high packets-per-second (PPS) rates .

Why other options are incorrect:

B. Configure a Tier-1 gateway and connect it directly to the physical routers. – Incorrect.
Tier-1 gateways are designed to connect to Tier-0 gateways, not directly to physical routers. In the NSX architecture, the Tier-0 gateway provides the external connectivity to the physical network. Connecting a Tier-1 directly to physical routers would bypass the Tier-0 and break the hierarchical routing model, likely causing routing inconsistencies rather than resolving congestion.

D. Configure NAT on the Tier-0 gateway. – Incorrect.
Network Address Translation (NAT) changes packet headers but does not increase throughput or relieve congestion. In fact, stateful NAT processing adds CPU overhead on the Edge node, which could potentially worsen performance in a congested scenario rather than improve it.

E. Add an additional vNIC to the NSX Edge node. – Incorrect.
NSX Edge VMs support only the VMXNET3 vNIC type, but adding more vNICs does not automatically increase throughput to the physical network. The bottleneck is typically CPU processing capacity (for encapsulation, firewall, routing lookups) or the bandwidth of the physical uplink itself, not the number of virtual interfaces. Adding vNICs without addressing underlying resource constraints (vCPU, memory) or path diversity (ECMP) will not resolve congestion.

Reference

Broadcom TechDocs – NSX Edge VM System Requirements: Specifies throughput recommendations for Medium (<2 Gbps) and Large (2-10 Gbps) Edge node sizes

Broadcom Knowledge Base – NSX-T Edge ECMP Behavior: Explains how ECMP distributes traffic across multiple Edge nodes and uplinks

Explanation:

NSX prevents lateral movement (east-west traffic between workloads) primarily through Network Segmentation, specifically a capability known as micro-segmentation . Lateral movement is a common attack strategy in which a threat first compromises one vulnerable workload and then moves stealthily within the network to infect others . Micro-segmentation isolates individual workloads from each other and prevents workload-to-workload interactions except when explicitly authorized . This technique requires no human intervention and is highly effective in containing intrusions, even before they are detected . By creating granular security controls down to the individual workload level, micro-segmentation establishes a "least privileges" or "zero-trust" model that denies default traffic and allows only explicitly authorized communications, making lateral movement fundamentally impossible .

Why other options are incorrect:

B. Virtual Security Zones – Incorrect.
While security zones can be created as part of micro-segmentation strategy, "Virtual Security Zones" is not the core feature name NSX uses to achieve lateral movement prevention. The technology is consistently referred to as "micro-segmentation" in VMware documentation .

C. Edge Firewalling – Incorrect.
Edge Firewall (also known as Gateway Firewall) protects north-south traffic (traffic entering or leaving the data center perimeter), not east-west lateral movement between internal workloads . Edge Firewall operates on Tier-0 or Tier-1 gateways at the network perimeter, while east-west traffic prevention is achieved through Distributed Firewall at the hypervisor kernel level .

D. Dynamic Routing – Incorrect.
Dynamic routing is a networking function (using protocols like BGP, OSPF) for exchanging route information between routers, not a security feature for preventing lateral threat movement . It does not provide workload isolation or traffic filtering capabilities.

Reference

VMware NSX Distributed Firewall – "Micro-segmentation enables security architects to isolate workloads from each other and prevent workload-to-workload interactions except when explicitly authorized. This technique is highly effective in containing intrusions and preventing lateral movement"

VMware NSX Security Architecture – "Distributed Firewall (DFW) is an East-West Firewall used for network segmentation and microsegmentation to achieve zero-trust protection. DFW exists in the kernel of the hypervisor and rules are enforced at the vnic level"

Explanation:

The VMware NSX portfolio is VMware's comprehensive software-defined networking and security solution for data centers and multi-cloud environments. The portfolio includes several core products that provide specific capabilities. Based on official VMware documentation and industry sources, two of the options listed are clear solutions within the NSX portfolio.

C. VMware NSX Advanced Load Balancer – Correct.
The NSX Advanced Load Balancer (formerly known as the Avi Networks Platform) is a core component of the VMware NSX portfolio. It provides a distributed application delivery controller (ADC) built for multi-cloud environments, offering software load balancing, intelligent web application firewall (WAF), advanced analytics, and monitoring capabilities . Its central control plane and distributed data plane deliver application services as a dynamic, multi-cloud fabric that can run on VMs, containers, or bare metal across any cloud environment . VMware officially lists NSX Advanced Load Balancer as part of its Virtual Cloud Network offerings alongside NSX Data Center .

D. VMware NSX Distributed IDS/IPS – Correct.
VMware NSX Distributed IDS/IPS (Intrusion Detection System/Intrusion Prevention System) is a native security capability within the NSX portfolio. It provides distributed intrusion detection and prevention at the hypervisor kernel level, enabling advanced filtering to be applied at every hop of an application . The distributed architecture helps eliminate blind spots created by traditional perimeter security products and allows security policies to be automatically generated and enforced on an application-specific basis . As documented in NSX feature guides, Distributed IDS/IPS is a key component of NSX Advanced Threat Prevention capabilities .

Why other options are incorrect:

A. VMware Tanzu Kubernetes Grid – Incorrect.
Tanzu Kubernetes Grid (TKG) is part of the VMware Tanzu portfolio, not the NSX portfolio. While NSX can integrate with and provide networking services for Tanzu Kubernetes Grid clusters, TKG itself is a separate product within VMware's modern application portfolio . The Tanzu portfolio focuses on Kubernetes management and container orchestration across multi-cloud environments, whereas NSX focuses on networking and security virtualization .

B. VMware Tanzu Kubernetes Cluster – Incorrect.
This is not a distinct product offering; rather, "Tanzu Kubernetes clusters" refer to the Kubernetes clusters that can be deployed and managed by Tanzu Kubernetes Grid or vSphere with Kubernetes. Like option A, this belongs to the VMware Tanzu portfolio, not NSX. Additionally, the phrasing "Tanzu Kubernetes Cluster" is imprecise as a product name—the actual platform is Tanzu Kubernetes Grid, which is used to create and manage Kubernetes clusters .

E. VMware Aria Automation – Incorrect.
VMware Aria Automation (formerly vRealize Automation) is part of the VMware Aria portfolio, which focuses on cloud management, automation, and infrastructure lifecycle management. While Aria Automation can integrate with and manage NSX components as part of a broader cloud management platform, it is not a solution within the NSX portfolio itself. The Aria portfolio also includes Aria Operations, Aria Operations for Logs, and Aria Operations for Networks . VMware documentation clearly distinguishes between NSX editions and Aria products as separate licensing and product families .

Reference

Broadcom TechDocs – NSX Editions: Lists NSX Distributed Firewall and Gateway Firewall capabilities, including IDS/IPS

VMware Announcement (VMworld 2019): Officially announced NSX Advanced Load Balancer as part of NSX portfolio

Explanation:

NSX supports three types of DHCP services that can be configured on segments to provide dynamic IP address assignment to workloads . These services differ in their scope and where the DHCP server resides.

A. Gateway DHCP – Correct.
Gateway DHCP server acts as a centralized DHCP service that dynamically assigns IP addresses to VMs on all segments connected to a Tier-0 or Tier-1 gateway that use this DHCP type . When a segment uses Gateway DHCP, the DHCP profile attached to the gateway is automatically selected and its server IP addresses are fetched automatically from that profile . Gateway DHCP is supported only for IPv4 subnets; Gateway DHCPv6 server is not supported .

B. Segment DHCP – Correct.
Segment DHCP server is a DHCP service local to a specific segment. It provides dynamic IP assignment only to the VMs attached to that segment . The DHCP server IP address must belong to the subnet configured on the segment and must be different from the gateway IP address . For isolated segments not connected to a gateway, Segment DHCP server is the only supported option . When a segment is connected to a gateway, Segment DHCP is selected by default .

C. DHCP Relay – Correct.
DHCP Relay forwards DHCP client requests to external DHCP servers located outside the NSX environment, such as in the physical network or another subnet . The DHCP Relay service is local to the segment and not available to other segments . When using DHCP Relay, you cannot configure DHCP settings, DHCP options, or static bindings on the segment . DHCP Relay is supported on VLAN segments through the service interface of a Tier-0 or Tier-1 gateway .

Why other options are incorrect:

D. Port DHCP per VNF – Incorrect.
This is not a supported DHCP service type in NSX. The official VMware documentation lists only three DHCP configuration types: Segment DHCP server, Gateway DHCP server, and DHCP Relay . There is no "Port DHCP per VNF" service option available.

E. VRF DHCP Server – Incorrect.
While VRF (Virtual Routing and Forwarding) gateways are supported in NSX for multi-tenancy , "VRF DHCP Server" is not a distinct DHCP service type. DHCP services on VRF gateways would fall under the same three categories (Segment DHCP, Gateway DHCP, or DHCP Relay) that apply to standard gateways.

Reference

Broadcom TechDocs – NSX DHCP:Lists the three supported DHCP configuration types as Segment DHCP server, Gateway DHCP server, and DHCP Relay

Broadcom TechDocs – NSX DHCP Configuration Settings: Provides detailed reference for configuring DHCP types, including when each type is supported or not supported

Explanation:

The get log-file syslog command is the correct NSX CLI command to display syslog messages directly on the NSX Manager appliance.

Why other options are incorrect:

A. show log manager follow – Incorrect.
According to exam discussion sources, show log manager follow is not a valid CLI command in NSX. There is no show log command or manager option in the NSX CLI. This appears to be a distractor option that resembles commands found in other network operating systems but does not exist in NSX.

B. get log-file auth.log – Incorrect.
While get log-file auth.log is a valid CLI command syntax, it displays the authorization log, not the syslog. The auth.log file contains authorization and authentication-related messages, not general system syslog messages. Although the command format is correct, the specific log file specified is wrong for viewing syslog.

D. /var/log/syslog/syslog.log – Incorrect.
This option is a file path, not a CLI command. While syslog messages on NSX appliances are located in /var/log/syslog, the question asks for a "CLI command" to show syslog, not a file path reference. Additionally, the exact path is /var/log/syslog, not /var/log/syslog/syslog.log. The latter is an incorrect or non-existent path on NSX Manager.

Reference

Broadcom TechDocs – "Log Messages and Error Codes": On NSX appliances, run get log-file syslog to view system logs

Broadcom Knowledge Base Article 425724 – "How to check the Log-file via NSX-CLI": Confirms the command syntax and notes the use of follow for live logs

Explanation:

When the NSX Manager UI is inaccessible, an administrator can generate a support bundle directly from the NSX Manager command line interface (CLI). The correct command for this operation is get support-bundle file, which collects system logs and configuration data into a single compressed file .

Why other options are incorrect:

A. esxcli system syslog config logger set --id=nsxmanager – Incorrect.
This command is used on ESXi hosts (not NSX Manager) to configure syslog logging parameters. It does not generate a support bundle. Additionally, --id=nsxmanager is not a valid logger ID in ESXi.

C. vm-support – Incorrect.
The vm-support command is used on ESXi hosts (not NSX Manager) to collect diagnostic bundles for VMware technical support . It is not a valid command on the NSX Manager appliance. The NSX Manager equivalent is get support-bundle.

D. set support-bundle file vcpnv.tgz – Incorrect.
The set command in NSX CLI is used to modify configurations (e.g., set napp kubeconfig for NSX Application Platform ). set support-bundle is not a valid NSX CLI command. The correct verb for generating a support bundle is get, not set.

Reference

Broadcom Knowledge Base Article 383034 – "How to collect a support bundle for NSX nodes via CLI": When the NSX UI is inaccessible, support bundles can be generated via CLI using get support-bundle file

Broadcom TechDocs – "Collect the NSX Application Platform Support Bundles Using the CLI": Confirms the get support-bundle file command syntax