Free 2V0-17.25 Practice Test Questions 2026

Explanation:

When a VMware Cloud Foundation (VCF) fleet is running in evaluation mode, the administrator must transition it to a fully licensed fleet. The required steps involve registering VCF Operations with the VCF Business console, adding the appropriate license keys to VCF Operations, and then assigning those licenses to the relevant components (vCenter instances, NSX Manager, etc.) from within VCF Operations.

Why these three steps?

B. Register the VCF Operations instance with the VCF Business Services console.
VCF Business Services console manages entitlements and licenses. VCF Operations must be registered with it to pull valid license keys and sync licensing status. Without registration, VCF Operations cannot see the licenses available for the fleet.

E. Add license keys from the VCF Business Service console to VCF Operations.
Once registered, the administrator imports or syncs the actual license keys from the Business console into VCF Operations. This makes the licenses available for assignment within VCF Ops.

F. Assign licenses to vCenter instances from VCF Operations.
After the licenses are present in VCF Operations, the administrator must assign them to the specific components. The question says “choose three,” and while C mentions NSX and vCenter, F is explicitly correct because vCenter licensing is mandatory. NSX licensing assignment is also typically done from VCF Operations, but the exam’s correct triad here is B, E, F — vCenter assignment is explicitly listed and required.

Why the other options are wrong

A. Add the license file from VCF Business Services console to VCF Operations.
You don’t upload a “license file”; you either sync or add license keys (option E). Option A is misleading terminology and not the correct workflow.

C. Assign licenses to vCenter instances and NSX Manager from VCF Operations.
This is partially true in real life, but the exam’s three correct choices are B, E, F. F covers vCenter; NSX assignment is not explicitly required in the chosen triad here. Also, the official documentation emphasizes vCenter assignment as a distinct required step.

D. Generate license keys in the VCF Business Service console for every component.
You do not generate license keys for every component from the Business console — you use existing licenses from VMware or import them. Generation is not part of the post-evaluation licensing workflow.

Reference

Based on VMware Cloud Foundation 9.0 Administrator Guide (Licensing section) and VCF Operations documentation:
After deployment in evaluation mode, the administrator registers VCF Operations with VCF Business Services.

Explanation:

When an administrator edits the NSX Connectivity Profile for a specific NSX VPC, the change applies only to that individual VPC. The connectivity profile is an attribute of the VPC itself — modifying it does not cascade to other VPCs, even those within the same NSX Project or using the same default profile.

Why the other options are incorrect

A. All NSX VPCs associated with the VCF Automation organization
VCF Automation organizations can contain many VPCs across multiple projects. Editing one VPC's profile does not trigger a bulk update across the entire organization.

B. All NSX VPCs that use the default VPC connectivity profile
The default profile is a template used at VPC creation. After creation, each VPC's configuration is independent. Changing a default profile does not retroactively update existing VPCs that were created with it.

D. Only the NSX VPCs within the corresponding NSX Project
While the VPC resides within an NSX Project, modifying its connectivity profile does not affect other VPCs in the same project. Project-level changes would require editing project-wide settings, not a specific VPC's profile.

Reference

Broadcom TechDocs: "NSX Projects and VPC in Network Profiles" — Confirms that VPCs are independent objects and modifications to one do not cascade

VMware Japan Blog: "What are VPC and Transit Gateway in VMware Cloud Foundation 9.0" — Describes the three VPC profiles (Connectivity, Service, Security) and their per-VPC association

Explanation:

The key to this question lies in understanding where DHCP filtering is controlled in NSX and how default profiles behave. When a DHCP server resides on the same segment as the clients, the NSX segment's security profile must be configured to allow DHCP traffic to pass.

Why the Other Options Are Incorrect

B. Clone default segment security profile, disable DHCP server block, and apply
Cloning is unnecessary when you can edit the default profile directly. However, if the requirement were to preserve the original default profile, cloning would be appropriate. The question asks what the administrator must do, not what is possible.

C. Clone default IP discovery profile, disable DHCP server block, and apply
DHCP filtering is not a function of the IP Discovery profile. The IP Discovery profile controls how NSX learns VM IP addresses, not DHCP traffic filtering.

D. Edit default IP discovery profile, disable DHCP server block, and apply
Same fundamental error as option C—DHCP Server Block does not exist in the IP Discovery profile. This option would have no effect on DHCP traffic.

Reference

Broadcom TechDocs: "Understanding Segment Security Segment Profile" – Confirms DHCP Server Block is enabled by default in the default profile

Broadcom Knowledge Article 433269:"Virtual Machine network connectivity loss on NSX segments" – Directly addresses disabling DHCP Server Block in the segment security profile

Explanation:

When expanding an existing VCF Fleet into a second region (Region B) following the VCF Fleet with Disaster Recovery Design Model, the key component required is VMware Live Recovery. This is because disaster recovery between two VCF instances for management components is implemented using VMware Live Recovery, not other tools like HCX or Data Services Manager .

Why the Other Options Are Incorrect

B. VMware Data Services Manager (DSM)
DSM is for managing database services (PostgreSQL and MySQL) and can forward metrics to VCF Operations . It is not a disaster recovery component for VCF fleet deployment across regions.

C. VCF Operations HCX
HCX provides workload mobility and migration, not disaster recovery. HCX 9.0 supports migration to VPCs, vSphere Supervisor Clusters, and NSX Federated environments . Disaster Recovery capabilities were deprecated in HCX 9.0 . HCX is for workload migration, not management domain protection.

D. VCF Operations
VCF Operations is a management and observability platform that provides fleet management, monitoring, and lifecycle management . While it is a component that gets protected by VMware Live Recovery in a DR scenario, it is not the component that provides disaster recovery. VCF Operations is the workload being protected, not the DR enabler .

Reference

Broadcom TechDocs - Detailed Design for Site Protection and Disaster Recovery: Confirms VMware Live Recovery as the solution for replicating and recovering management components between two VCF instances

VCF Fleet with Multiple Sites Blueprint: Indicates disaster recovery capability requires a "data replication and failover solution"

Explanation:

When a password for a VCF-managed component (such as the vCenter root account) is changed directly in the component rather than through VCF Operations, the stored credential in VCF Operations becomes out of sync. The correct action to restore management capability is to perform a password remediation. This process synchronizes the password stored in VCF Operations with the new password that was manually set on the component .

Why the Other Options Are Incorrect

A. Reset password function
"Reset password" is not a standard VCF Operations password management action. This is a distractor term .

B. Rotate password function
Rotation is performed from SDDC Manager, not VCF Operations, and it triggers VCF to generate and apply a new password automatically. This does not allow you to enter an externally changed password .

D. Update password function
The Update action is used to provide a new password and change it on the server side simultaneously . In this scenario, the server side (vCenter) already has the new password; using Update could cause a mismatch or failure because VCF Operations would attempt to change it again.

References

Broadcom TechDocs: "Managing Passwords for VMware Cloud Foundation Components" - Defines Update, Remediate, and Rotate actions

Broadcom TechDocs: "Remediate Passwords for VMware Cloud Foundation Components" - States that after resetting a password in a component, you must remediate in VCF Operations

Explanation:

1. Create an embedded code to the dashboard (B):
In VCF Operations, the "Share" feature allows administrators to generate an Embedded Code or a URL. This is the standard mechanism for sharing specific dashboards with users without requiring them to navigate the full product UI. To fulfill the requirement of showing the dashboard to a specific group, the administrator must first initiate this sharing workflow.

2. Grant access for 3 months (C):
When configuring the sharing settings for a dashboard, VCF Operations provides a specific security feature called Access Period. You can define whether the link/code is permanent or if it expires. By setting the expiration to 3 months, the system automatically revokes the session and access after that duration, meeting the requirement for automatic revocation without manual intervention.

3. Grant users access to the dashboard (E):
The requirement states that users must be authenticated. In the Share Dashboard configuration, there is a toggle for "Require Authentication." By selecting this, only users who can successfully log in via the identity sources configured in VCF (such as LDAP, Active Directory, or VMware Cloud Foundation’s identity provider) will be able to view the content.

Why the other options are incorrect:

A. Schedule and send a report:
Sending a report is a "push" mechanism that creates a static file (PDF/CSV). It does not provide an interactive dashboard experience, nor does it inherently handle the "revoke access" requirement in the same way as a live link expiration.

D. Use Identity Broker:
While Identity Broker is part of the broader VCF ecosystem, the specific task of sharing a dashboard is handled within the VCF Operations application settings. You don't "use" the broker as a step to share a dashboard; you simply enable the authentication requirement on the share itself.

F. Publish the code on the company intranet:
While this would make the dashboard accessible, the requirement specifically mentions sharing it with a specific group of users. Posting it on a general intranet is a distribution method, not a configuration step within VCF Operations to satisfy the technical constraints of the exam question.

Reference:
VMware Cloud Foundation Documentation / Operations Guide: Refer to the section "Sharing Dashboards" which outlines the use of the Share icon, the creation of public/private links, and the configuration of the Access Period and Authentication toggles.

Explanation:

The "Self-Managed" Requirement (B):

In VMware Cloud Foundation, the SDDC Manager expects a specific architectural layout to take over the management of an existing environment. For a successful "Import" or "Conversion" process (often referred to as a "Brownfield" import), the vCenter Server that manages the environment must reside on the compute resources (the cluster) that it is currently managing. This allows VCF to establish a proper management domain structure where the management components and the workload resources are correctly aligned within the VCF inventory.

Why the other options are incorrect:

A. All clusters must use vSphere Lifecycle Manager (vLCM) baselines:
Actually, VCF 9.0 (and versions 5.x before it) has moved away from legacy baselines (VUM) in favor of vLCM Images. Convergence often requires moving toward a single image-based lifecycle management model rather than maintaining legacy baselines.

C. All Virtual Distributed Switch (VDS) are version 7.0 or later:
While VCF 9.0 requires modern VDS versions, the specific "convergence" prerequisite for the management stack is focused on the placement and management relationship of the vCenter Server itself. Additionally, for VCF 9.0, VDS 8.0 is typically the standard for the underlying SDDC components.

D. The vSphere environment must have VMware NSX deployed:
This is incorrect because VCF often brings the NSX deployment as part of the SDDC automation. In a convergence scenario, you are often moving from a standard vSphere environment into a VCF-managed environment where VCF will deploy or configure the NSX components as part of the bring-up or expansion process.

Reference:

VMware Cloud Foundation Planning and Preparation Guide: Refer to the "Requirements for Importing an Existing vSphere Environment" section. It specifies that the vCenter Server and its associated PSC (if applicable in older versions) must be running on the cluster that is being converted into the first VCF Management Domain.

Explanation:

1. Configure gateway, subnet, and IPAM (C):
To satisfy the requirement that workloads "automatically get an IP address from the internal IPAM solution," the network objects within VCF Automation must be aware of the IP space. Even if an external IPAM provider is integrated, the specific network segments must be configured with their CIDR and gateway information so the automation engine can coordinate the IP allocation during the provisioning workflow.

2. Create a new network profile and add the net:appdev tag (D):
A Network Profile defines how networks are associated with a Cloud Zone (and thus, different clusters). By creating a specific profile for the "appdev" project and tagging it with net:appdev, you create a logical link. When a Cloud Template (Blueprint) is requested with a matching constraint tag, VCF Automation knows to only look at the segments defined within this specific profile, ensuring the required isolation from other development activities.

3. Add vlan: capability tags (F):
The requirement states the user must be able to "specify the VLAN number" to determine the network. In VCF Automation, this is achieved through Tag-based placement. By tagging individual network segments with a unique key-value pair like vlan:10, vlan:20, etc., the administrator allows the self-service user to input a value that the engine matches against the segment tags to select the correct destination network.

Why the other options are incorrect:

A. Create a custom group:
Custom groups in VCF Operations or NSX are used for monitoring or security policies, but they do not govern the deployment placement logic within VCF Automation templates.

B. Add the net:appdev tag to ALL segments:
This would violate the isolation requirement. If all segments (including general production or dev) have the same tag, the "appdev" workloads could potentially land on non-project segments.

E. Add all appdev networks to the existing development project's network profile:
This contradicts the goal of "logical isolation." Mixing the new project's networks into an existing profile makes it difficult to restrict access and manage specific placement constraints for the new critical project.

Reference:

VMware vRealize Automation / Aria Automation Documentation:Refer to "Learn about Network Profiles" and "Using Capability Tags to inform placement" sections. These guides detail how tags on networks and profiles interact with constraints in Cloud Templates to drive intent-based provisioning.

Explanation:

VMware vSphere Kubernetes Service (VKS) uses the open-source Cluster API (CAPI) project to automate lifecycle management of Kubernetes clusters . This is explicitly stated in the official VCF 9.0 documentation: "VKS provides self-service lifecycle management of VKS clusters. VKS is an implementation of the open-source Cluster API project that defines a set of custom resources and controllers to manage the lifecycle of Kubernetes clusters" .

Why Other Options Are Incorrect

A. Kubeadm
Kubeadm is a bootstrap tool for minimal Kubernetes cluster setup, not an automated lifecycle management framework. It handles initial cluster creation but lacks the declarative, ongoing management capabilities of Cluster API .

B. Contour
Contour is an ingress controller for Kubernetes that manages external access to services. It has no role in cluster provisioning or lifecycle management .

C. Grafana
Grafana is a data visualization and observability tool for metrics dashboards. It does not provision or manage Kubernetes clusters .

References

Broadcom TechDocs: "VKS Architecture" – Confirms Cluster API provides declarative APIs for cluster creation, configuration, and management

Broadcom TechDocs: "What Is a VKS Cluster?" – States VKS is an implementation of the open-source Cluster API project

Explanation:

1. Enforce multi-control-node at the Organization level (F):
The requirement states that by default, all Kubernetes clusters must tolerate a single control plane node failure. In VCF/Supervisor architecture, high availability for the control plane requires three nodes. By applying the "Enforce multi-control-node" policy at the Organization level, you establish a global default. All projects (Development and Production) will inherit this setting unless a more specific policy is applied at the project level.

2. Disallow VM resources in Production (A):
The task specifies that only Kubernetes cluster resources will be deployed within the production project. To prevent users from deploying standard Virtual Machines (VMs) and ensure the project is dedicated to Tanzu/Kubernetes workloads, the administrator applies the "Disallow VM resource" template specifically to the Production project. This overrides any general permissions and restricts the resource types allowed.

3. Enforce single-control-node in Development (D):
In the Development project, resources must be minimized. While the global (Org) policy requires three control plane nodes, applying a project-specific policy to "Enforce single-control-node" overrides the default. This allows development clusters to run with only one control plane node, significantly reducing the resource footprint (CPU/RAM/Storage) for non-critical testing.

Why the other options are incorrect:

B. Enforce multi-control-node for Development:
This contradicts the requirement to "minimize resources." Multiple nodes increase resource consumption.

C. Disallow VM resource for the Organization:
If applied at the Org level, users wouldn't be able to deploy VMs anywhere in the private cloud. The requirement only specified this restriction for the Production project.

E. Enforce single-control-node for Production:
This violates the "default" requirement that clusters must tolerate a failure. Production workloads typically require high availability.

Reference:

VMware Cloud Foundation / vSphere with Tanzu Documentation: Look for "Managing IaaS Resource Policies." It explains how policies assigned at the Organization level provide defaults, while Project-level policies allow for specific overrides to control Kubernetes cluster sizing (control plane count) and restricted resource types (VM vs. Pod).

Explanation:

When deploying VMware Cloud Foundation (VCF) in a dark site (an air-gapped environment with no internet connectivity), the administrator must first download all required installation binaries on a machine that has internet access, then physically transfer them to the isolated environment .

Why Other Options Are Incorrect

A. Use Broadcom DownloadsManual portal downloads provide individual ISOs, but VCF requires complete bundle sets with metadata that only the VCF Download Tool packages correctly for offline depots .

B. Use SDDC ManagerSDDC Manager requires internet connectivity to pull bundles directly from the online depot and cannot function in a dark site environment .

D. Use the VCF InstallerThe installer consumes binaries from a depot but cannot download them. In dark sites, it must be pointed to a pre-populated offline depot created by the VCF Download Tool .

References
Broadcom TechDocs: "Download Install Binaries to an Offline Depot"
Broadcom TechDocs: "Download VCF Core Component Binaries to an Offline Depot"
VMware Blog: "Using the Offline Bundle Transfer Utility for Disconnected VMware Cloud Foundation Sites"

Explanation:

Cluster API (CAPI) is the open-source project used by vSphere Kubernetes Service (VKS) to provision Kubernetes workload clusters. CAPI provides declarative APIs and controllers that handle the full lifecycle—creation, scaling, upgrades, and deletion—of Kubernetes clusters. In VCF 9.0, the vSphere Supervisor acts as the CAPI management cluster, using the Cluster API Provider for vSphere (CAPV) to provision VKS clusters as native cloud resources. This enables consistent, automated, and policy-driven cluster deployments.

Why Other Options Are Incorrect

A. Carvel
Carvel is a suite of tools for building, packaging, and deploying applications on Kubernetes. It does not provision Kubernetes clusters themselves.

C. cert-manager
cert-manager automates TLS certificate issuance and renewal inside Kubernetes clusters. It has no role in provisioning cluster infrastructure.

D. Harbor
Harbor is a private container image registry for storing and scanning images. It is unrelated to cluster lifecycle management.

References

Broadcom TechDocs: "Workflow for Provisioning VKS Clusters Using VCF CLI" – Confirms Cluster API as the provisioning engine

Broadcom TechDocs: "About VKS Cluster Provisioning" – States VKS is an implementation of the open-source Cluster API project