VMware 3V0-24.25 Advanced VMware Cloud Foundation 9.0 vSphere Kubernetes Service Exam Practice Test

Harbor reduces the risk of running vulnerable or tampered images primarily throughvulnerability scanningandimage signing.Vulnerability scanning (E)detects known CVEs in image layers (OS packages and application dependencies, depending on the scanner configuration). This allows teams to identify—and gate the use of—images that contain high/critical vulnerabilities before those images are deployed to Kubernetes clusters. Enforcing scanning as part of the image promotion process helps prevent outdated images with known CVEs from being pulled into production.Image signing (A)provides integrity and provenance controls by enabling consumers to verify that an image was produced and approved by a trusted publisher and has not been altered. When combined with admission controls/policies (for example, only allowing signed images from specific projects), signing helps block unauthorized or unapproved images from being deployed, which is critical when the incident involves exposed internal APIs and supply-chain risk.

The other choices do not directly prevent recurrence:automatic image update (B)is not a core Harbor registry control,deploy both container and VM images (C)is a content capability rather than a security control, andautomatic image validation (D)is not a standard Harbor registry capability distinct from signing/scanning.

Storage

Resources

When a stateful pod (like Harbor’s database) is stuck Pending/ContainerCreating or repeatedly failing to attach/mount storage, one of the first checks is whether the PVC’sAccess Modesmatch what the workload and backing storage support (for example, ReadWriteOnce vs ReadWriteMany). In Kubernetes, the PVC and PV explicitly showAccess Modes(for example Access Modes: RWO) when you inspect them.

In the vSphere Namespace UI, theStoragetab is where namespace storage is managed and reviewed (including storage policy assignments that back storage classes/PVCs), making it the natural place to validate the storage configuration being consumed by the Harbor database PVC. VMware’s VCF documentation directs administrators to navigate to a namespace and use theStoragetab for storage-related settings.

TheResourcestab is the Kubernetes-object oriented view for the namespace, where you can locate the PVC object associated with the failing pod and inspect its properties/YAML (including the requested storage class and access mode intent). Namespace permissions explicitly include the ability to view Kubernetes resources within the namespace, which aligns with checking PVC details there.

Kubernetes Role-Based Access Control (RBAC) is implemented through theRBAC API group(rbac.authorization.k8s.io) and defines the core authorization primitives used to grant permissions to users, groups, and service accounts. The cluster-scoped objects declared by the RBAC API areClusterRoleandClusterRoleBinding. AClusterRoledefines a set of permissions (verbs such as get/list/watch/create/update/delete) over resources at thecluster scope(including cluster-wide resources and optionally namespaced resources across namespaces). AClusterRoleBindingthenbindsthat ClusterRole to a subject (user/group/serviceaccount), making those permissions effective cluster-wide.

This differs from namespace-scoped RBAC objects (RoleandRoleBinding) which apply only within a single namespace. The other options are incorrect becauseClusterObject/ClusterNodeare not RBAC API objects,ValidatingAdmissionPolicybelongs to the admission control API surface (policy enforcement),ResourceQuotais a namespace resource governance object, andContainer/Deploymentare workload/runtime concepts defined in the core/apps APIs rather than authorization primitives.

A service mesh is an application communication layer that standardizesservice-to-service trafficinside Kubernetes. Instead of each development team building custom logic for retries, timeouts, encryption, and telemetry, the mesh provides these capabilities consistently across workloads. This is typically done by inserting a data plane (often sidecar proxies or node-level proxies) that intercepts inbound and outbound traffic for each microservice, plus a control plane that distributes configuration and identity material.

The key outcomes align directly to optionB: communication becomespossible(reliable connectivity patterns),structured(consistent routing rules, policies, and identity), andobservable(metrics, logs, and distributed tracing for east-west traffic). A service mesh commonly adds controls such asmTLS encryption, fine-grainedtraffic policy(allow/deny, rate limits, circuit breaking), and progressive delivery patterns (canary/blue-green) without changing application code.

By contrast, service discovery (A) is usually a built-in Kubernetes function, load balancing/autoscaling across sites (C) is not the primary definition of a service mesh, and a single centralized global routing table (D) is not how meshes are typically described or implemented.

The documented behavior of kubectl edit is that it opens the object manifest in a local text editor, and the editor it launches is controlled by environment variables. In the VCF 9.0 documentation (Workload Management / Supervisor operations), the procedure explicitly states: “The kubectl edit command opens the namespace manifest in the text editor defined by your KUBE_EDITOR or the EDITOR environment variable.”

If the administrator’s environment does not have KUBE_EDITOR or EDITOR defined (or they point to an invalid/interactive-less editor in the current session), kubectl edit may not open the expected editor workflow, and the admin may not see the normal confirmation after saving and exiting. Setting KUBE_EDITOR (preferred for kubectl-specific behavior) or EDITOR ensures kubectl launches a known-good editor, allowing the manifest to be modified, saved, and then submitted back to the API server when the editor exits. The same documented requirement also applies to editing other Kubernetes objects (such as a VKS cluster manifest) because the kubectl edit mechanism is identical.

The problem describes demand spikes where capacity exists, but the application cannot meet demand—this typically indicates the cluster needs toscale out(more nodes/pods) automatically when load increases. In VCF 9.0, VKS supportsCluster Autoscaleras an optional package and specifically calls out improvements: “Cluster Autoscaler supports scaling from zero or to zero… You must have the autoscaler standard package installed.” This directly supports optionA(install cluster autoscaling) as the mechanism to dynamically add capacity during peak events and reduce it afterward, optimizing cost and operations while meeting bursts. A load balancer (including Foundation Load Balancer) helps distribute traffic acrossexistingendpoints, but it does not create new compute capacity when pods are pending due to insufficient nodes. Similarly, installing Contour relates to ingress (routing inbound traffic) and is not, by itself, a capacity scaling solution. Oversubscription is a risky workaround that can degrade performance and does not provide targeted, policy-driven elasticity. Therefore, enablingcluster autoscalingis the correct way to address burst demand when underlying resources are available.

Configuration Sequence (in order):

Create the vSphere Namespace

Assign the zones

Select workload networking

Assign the zonal storage policy

Define resource quotas / limits

Grant RBAC / permissions

A zonal vSphere Namespace is created as a standard namespace first, then “zonalized” by associating it with one or morevSphere Zonesso workloads can be scheduled according to zone placement rules. You start bycreating the namespacebecause it is the tenancy and governance container where networking, storage access, quotas, and permissions are applied. Next, youassign the zones, since zone association is what makes the namespace “zonal” and determines where Kubernetes workloads (and their node pools) are allowed to land.

With zones set, you configureworkload networking, because namespaces must have the correct network attachment and IP behavior for the workloads that will be placed across the selected zones. Then youassign the zonal storage policy, ensuring that persistent volumes can be provisioned using storage that is valid/available for the zone placement model you selected. After networking and storage access are defined, you setresource quotas/limits(CPU, memory, storage) so multi-tenant consumption stays within governance boundaries. Finally, yougrant RBAC/permissionsso the right DevOps/users can consume the namespace and provision clusters/workloads under the enforced controls.

In VMware Cloud Foundation 9.0 and vSphere Supervisor architectures, the decision to deploy aSingle-Zoneor aMulti-ZoneSupervisor is made at the time ofinitial enablement. A Single-Zone Supervisor is tied to a specific vSphere Cluster. A Multi-Zone Supervisor requires a minimum of three vSphere Zones (each mapped to a cluster) to be defined before the Supervisor is deployed so that the Control Plane VMs can be distributed for high availability.

Currently, there is no supported " in-place " migration path to convert a deployed Single-Zone Supervisor into a Multi-Zone Supervisor by simply adding zones later. If an organization requires the high availability provided by a three-zone architecture, the administrator must decommission the existing Single-Zone Supervisor and then re-enable the Supervisor Service using the Multi-Zone configuration wizard. This design ensures that the underlying Kubernetes Control Plane components are correctly instantiated with the necessary quorum and anti-affinity rules that can only be established during the initial " Workload Management " setup phase.

In Kubernetes RBAC, cluster-wide permissions are defined withClusterRoleand granted to a user, group, or service account by creating aClusterRoleBinding. The VCF 9.0 documentation for VKS cluster access describes the RBAC workflow used to grant access: first you “define a Role or ClusterRolefor the user or group,” and then you “create a RoleBinding or ClusterRoleBindingfor the user or group and apply it to the cluster.” This wording reflects the RBAC distinction:RoleBindingis scoped to a namespace, whereasClusterRoleBindingis used when the permissions must apply at thecluster scope(cluster-wide resources and/or across namespaces).

VCF 9.0 further illustrates the purpose of ClusterRoleBinding in a token-auth example: it lists the required objects, including “ClusterRole: This defines the access to the Kubernetes cluster” and “ClusterRoleBinding: This binds the created Service Account with the defined ClusterRole.” That binding step is what grants the subject the cluster-level privileges defined in the ClusterRole, makingClusterRoleBindingthe correct object for permissions to cluster-wide resources.

Kubernetes Service

When adding a Kubernetes cluster to anexisting vSphere Namespace, the workflow is initiated from within that namespace’s context in the vSphere Client. The administrator first opens the target namespace (as shown in the left navigation where the namespace is selected), then uses theKubernetes Servicearea to create and manage Kubernetes clusters associated with that namespace. In the namespaceSummaryview, theKubernetes Servicetile/card provides the entry point for cluster lifecycle actions, typically via an action link such asManage(and from thereCreate Cluster). This is because the Kubernetes cluster is anamespace-scoped resourcein the Supervisor environment: it inherits namespace-level policies and configuration such as permissions/RBAC, resource limits, storage policies, and networking selections that have already been defined for that namespace. Navigating to other areas likeStorageorNetworkis used to validate or adjust prerequisites (for example, storage policy availability or network settings), but the actual “create cluster” operation is launched fromKubernetes Servicewithin the namespace to ensure the cluster is created under the correct tenant boundary and governance model.

VCF 9.0 explicitly states: “The VKS exposes three layers of controllers to manage the lifecycle of a VKS cluster,” and then enumerates those layers. The first layer is the set of components that integrate the workload cluster with Supervisor-backed resources, including aCloud Provider Plug-inthat integrates with the Supervisor and enables infrastructure integrations such as persistent volume requests being passed to the Supervisor (which is integrated with Cloud Native Storage). The second layer isCluster API, described as providing “declarative, Kubernetes-style APIs for cluster creation, configuration, and management,” driven by resources that represent the cluster, the VMs making up the cluster, and cluster add-ons. The third layer is theVirtual Machine Service, which provides a declarative API for managing VMs and associated vSphere resources and is used to manage the lifecycle of the control plane and worker node VMs hosting a VKS cluster.

Therefore, optionAis the only answer that matches the three lifecycle controller layers defined in the VCF 9.0 documentation.

The errors described—specifically the memcache.go failure, the inability to fetch resource lists for Antrea, and the YAML context error—are classic symptoms of aConfiguration Context mismatch. In VCF 9.0, there are two distinct layers of API interaction: theSupervisor Cluster API(used for management tasks like creating clusters) and theGuest Cluster API(used for deploying workloads within the VKS).

When an administrator upgrades a Supervisor, the API endpoint or the available API groups may change. If the administrator attempts to run kubectl commands against a VKS cluster while their kubeconfig context is still pointing to the Supervisor (or vice versa), the client will encounter " mapping values " errors and " unable to handle request " errors because it is sending requests to an endpoint that does not recognize those specific resource definitions (like Antrea stats in the wrong context). To resolve this, the administrator must ensure they have switched to the correct context using kubectl config use-context < cluster-name > after the Supervisor update to ensure the local client is communicating with the correct API server and version of the Kubernetes binaries.

Configuration Sequence (in order):

Deactivate the service.

Confirm uninstallation.

Delete the service.

Confirm deletion.

Uninstalling a Supervisor Service cleanly follows a “stop/remove/cleanup” pattern to avoid orphaned components and to ensure the Supervisor isn’t still reconciling the service while you remove it. First, youDeactivate the serviceso the Supervisor stops managing and running the Harbor service components. This prevents new service resources from being created while you are attempting to remove them and allows the platform to transition the service into a non-operational state safely.

Next, youConfirm uninstallationto initiate the removal workflow. This step acknowledges that the service’s deployed components (such as pods, controllers, and any associated objects) will be removed from the Supervisor-managed environment. After the uninstall workflow is initiated and the service is no longer active, you proceed toDelete the serviceto remove the Harbor service registration/entry from the Supervisor Services list, ensuring it is no longer available to namespaces or consumers. Finally, youConfirm deletionas the last safeguard, since deletion is typically destructive and removes the service definition from the environment’s available services catalog.

VKS cluster lifecycle is managed using adeclarative API: you usekubectl with a YAML fileto specify the desired state of the cluster (for example: “how many nodes,” Kubernetes version, sizing, and storage). After the cluster is created, youupdate the YAMLto update the cluster. This is why the correct operational approach is to modify the cluster manifest (cluster.yaml) rather than deleting and redeploying.

Additionally, VKS uses multiple controller layers, whereCluster APIand theVirtual Machine Serviceare responsible for provisioning and managing the lifecycle of the control plane and worker node VMs that make up the VKS cluster. In other words, when you change the declared state for control plane sizing/replica count in the cluster YAML, the platform reconciles to that new state by adjusting the underlying control plane VMs through the supported controllers, instead of requiring disruptive “tear down and rebuild” operations.

So, editing the cluster.yaml to adjust the control plane replica count is the method that matches the documented VKS declarative operations model and controller-driven reconciliation.

VCF 9.0 defines aVCF CLI contextas aconfiguration setfor a specific endpoint (for example, a Kubernetes cluster, vSphere Supervisor, or VCF Automation) and explains that a context stores the key connection parameters such asendpoint,context type,path to kubeconfig, andcredentials. This aligns directly with optionC, because vcf context create is used to create anamedcontext that encapsulates the access parameters needed to work with a specific Supervisor or VKS cluster and to switch between multiple environments without rewriting configuration each time.

The documentation further shows vcf context create being used to connect either to aSupervisor endpointor to aworkload (VKS) cluster(by providing workload cluster name/namespace or by using a generated kubeconfig), which is exactly the multi-tenant operational pattern in the question. While authentication is part of what happens during context creation (for example, creating a configuration that includes a JWT for Kubernetes API access), the command’s purpose is broader: it creates the reusablecontextobject that defineswhereandhowthe CLI connects.

VCF 9.0 defines VKS as an upstream Kubernetes offering that isbuilt for vSphereand delivered with “well-thought-out defaults” to reduce operational burden. It states VKS provides an“opinionated installation of Kubernetes”with defaults “optimized for vSphere,” which “reduce[s] the amount of time and effort” typically spent deploying and running an enterprise Kubernetes cluster—this directly supportssimplified management and operations (A).

VCF 9.0 also emphasizes VKS is“integrated with the vSphere infrastructure”(storage, networking, authentication) and is built on a Supervisor that maps to vSphere clusters, creating a “unified product experience.” This supportsconsistent Kubernetes deployment on vSphere (B)because clusters are provisioned and operated in a standardized, vSphere-native way.

Finally, VCF 9.0 states VKS clusters “use open source Linux-based” components from VMware by Broadcom and notes key integrations (for example, CNI options) are open source—supportingleveraging open-source technologies (D).

OptionsCandEare not VKS benefits as stated: VKS targets VKS-provisioned upstream Kubernetes clusters (not “any distribution”), and “pods directly on ESXi” is described asvSphere Pods(Workload Management), not a defining benefit of VKS clusters.

VCF 9.0 design guidance for theSupervisor NSX Load Balancer modelstates that theNSX load balancers run on NSX Edges, and sets explicit sizing requirements at theEdge nodelevel. In the “NSX Load Balancer Design Requirements,” VCF 9.0 requires that theNSX Edge cluster must be deployedbecause “NSX Load Balancers run on NSX Edges.” It further requires that“NSX Edge nodes must be deployed with a minimum of Large form factor”because NSX load balancers havefixed resource allocations on NSX Edge nodes, and the Large form factor is needed to accommodate basic system and workload needs.

This directly ties “deployment size” of the load balancer service capacity to theEdge node form factor(Small/Medium/Large, etc.) rather than the number of pods or the number of clusters. The document also notes that if additional load balancers are required, NSX Edges can bescaled up or out, again reinforcing that sizing is anEdge nodesizing decision.

Answer (Correct Order):

Navigate in VCF Operations to Fleet Management → Tasks, select the instance and review Tasks

Check for errors or failed ClusterConfig objects

SSH into the Supervisor Cluster to review logs / attempt manual cleanup if required

Restart the WCP Service

To determinewhya Supervisor upgrade failed, you start where the platform records the most actionable failure context: themanagement-plane task history. The Fleet/Task view surfaces the upgrade workflow steps, timestamps, and the specific operation that failed, which gives you the fastest pointer to the failing phase (precheck, image staging, reconciliation, add-on updates, etc.). Next, you validate the Kubernetes-side reconciliation state by checking forfailed ClusterConfigobjects, because Supervisor enablement/upgrade actions commonly drive configuration via controller reconciliation; a failed ClusterConfig often contains the clearest “reason” and “message” fields that explain what blocked progress (validation errors, dependency issues, unreachable endpoints, incompatible components).

If the management-plane/task view and ClusterConfig status still don’t isolate the root cause, the next escalation is toSSH into the Supervisorto inspect component logs/events and identify low-level failures that may not bubble up cleanly (for example, admission failures, controller crashes, or connectivity/auth issues). Finally,restarting WCPis a remediation step that can clear stuck states, but it’s placed last because it can alter evidence and should not be your first action when you’re still trying to identify the original failure cause.