View 2v0-21.23 Exam Questions

Q: 1

An administrator wants to use tag-based placement rules on their virtual machine disks using VMware vCenter. Which option would allow the administrator to achieve this?

Options

Correct Answer:

Explanation

Storage Policy Based Management (SPBM) is the vSphere framework that enables administrators to define storage requirements for virtual machines on a per-VM or per-virtual disk basis. Administrators can create tags and assign them to datastores to categorize them (e.g., by performance tier, data protection level). They then create a VM storage policy that includes rules referencing these tags. When this policy is applied to a virtual machine or its disks, vSphere ensures that the VMDKs are placed only on datastores that have the matching tag, thereby achieving tag-based placement.

Why Incorrect

B. Storage I/O Control: This feature prioritizes storage I/O for virtual machines during periods of contention on a datastore; it does not control initial placement.

C. vSphere Storage APIs for Storage Awareness (VASA): VASA is an API that allows storage arrays to communicate their capabilities to vCenter. SPBM uses this information, but SPBM is the management framework that creates the tag-based rules.

D. vSphere Distributed Resource Scheduler (DRS): DRS balances compute workloads (CPU and memory) across hosts in a cluster. It is not used for storage placement based on tags.

References

1. VMware vSphere 8.0 Documentation

"vSphere Storage

" Chapter 6: Working with VM Storage Policies

Section: Create a VM Storage Policy for Tag-Based Placement.

This section explicitly states: "You can define a VM storage policy that is based on storage-specific tags. When you use this type of policy for a virtual machine

the virtual machine is placed on a datastore that has the specified tag." This directly confirms that SPBM is the mechanism for tag-based placement.

2. VMware vSphere 8.0 Documentation

"vSphere Storage

" Chapter 1: vSphere Storage Fundamentals

Section: VM Storage Policies.

This section describes the role of SPBM: "VM storage policies capture storage requirements for your virtual machines... After you define the policy

you can apply it to the virtual disks... vCenter Server places the virtual machine on a datastore that satisfies the requirements of the assigned policy."

3. VMware vSphere 8.0 Documentation

"vSphere Resource Management

" Chapter 10: Managing Storage Resources

Section: Storage I/O Control.

This reference clarifies the function of SIOC: "When you enable Storage I/O Control on a datastore

ESXi begins to monitor the I/O load of the virtual machines... When latency exceeds the threshold

the datastore is considered congested and Storage I/O Control allocates I/O resources to virtual machines according to their shares." This shows its purpose is I/O management

not placement.

Q: 2

A vSphere environment is experiencing intermittent short bursts of CPU contention, causing brief production outages for some of the virtual machines (VMs). To understand the cause of the issue, the administrator wants to observe near real-time statistics for all VMs. Which two vSphere reporting tools could the administrator use? (Choose two.)

Options

Q: 3

An administrator creates a virtual machine that contains the latest company-approved software, tools and security updates. Company policy requires that only full clones are allowed for server workloads. A combination of which two tasks should the administrator complete to prepare for the deployment of this virtual machine for multiple users? (Choose two.)

Options

Discussion

MiaC Feb 27, 2026 2:24 am

Option D and B. Snapshots (E) look tempting but they're mainly for backup or rollback, not prepping for full clone rollouts. Template plus customization spec is what VMware guides recommend for this scenario, at least from what I've seen in labs and practice.

Ajay I. Feb 17, 2026 9:59 am

Makes sense to use D and B, since templates are standard for full clone rollouts and the customization spec helps ensure unique configs per user. I saw a similar question on a practice exam and these steps were needed.

Priya C. Feb 14, 2026 7:44 am

C or D here, but official guide and hands-on labs both push for using templates (D) and customization specs (B) for deploying multiple servers to unique users. Snapshots are more about rollback, not deployment. Not 100% but that matches what I've seen in exam practice.

Priya Mar 2, 2026 12:23 pm

B , snapshots (E) are needed for rollback but could still help with prepping clones. Not convinced D is always right here.

Jack Z. Feb 25, 2026 4:02 am

Hard to say, B and D again here. If it said the company allowed linked clones, then you might grab E for snapshots instead, but full clones require the template plus a customization spec for unique hosts in production. Seen a similar question with this twist on other practice sets.

Drew V. Feb 17, 2026 6:29 am

I don’t think E is right, since snapshots are more for rollback, not new deployments. Pretty sure it’s B and D-template plus customization spec is what you actually need for this kind of mass server rollout. Anyone see it another way?

Emma K. Mar 2, 2026 9:56 pm

Pretty sure it's B and D. You need the customization spec for unique deployments, and templates are standard for mass VM rollout. Saw similar advice in the official docs and practice labs. Disagree?

Be respectful. No spam.

Correct Answer:

B, D

Explanation

To prepare a master virtual machine for repeated deployment, the standard VMware best practice is to first convert it into a template. A template is a master copy that cannot be powered on or edited, which protects it from accidental changes and makes it a catalog item for provisioning new VMs.

Second, to ensure each deployed virtual machine is unique on the network, a customization specification must be created. This specification automates the process of changing the computer name (hostname), IP address, and security identifiers (SID for Windows), preventing conflicts when multiple clones from the same template are deployed.

Why Incorrect

A. Set appropriate permissions on the virtual machine.

Permissions control user access, which is a security and management task, not a core step in preparing the master image for cloning and customization.

C. Upgrade the virtual hardware.

This is a lifecycle management task performed when new hardware capabilities are needed, not a standard preparation step for deploying a newly created master image.

E. Take a snapshot of the virtual machine.

Snapshots are primarily for creating short-term, point-in-time rollback points. While a VM can be cloned from a snapshot, a template is the purpose-built, non-editable object for mass deployment.

References

1. VMware vSphere Documentation (vSphere 7.0)

vSphere Virtual Machine Administration

"Managing Virtual Machine Templates".

Section: "Creating a Template from a Virtual Machine" states

"You can create a template by converting a virtual machine to a template... A template is a master copy of a virtual machine that you can use to create and provision new virtual machines." This supports option D.

2. VMware vSphere Documentation (vSphere 7.0)

vSphere Virtual Machine Administration

"Customizing Guest Operating Systems".

Section: "Guest Operating System Customization" explains

"When you clone a virtual machine or deploy a virtual machine from a template

you can customize the guest operating system of the virtual machine... Customization is useful if you want to deploy many virtual machines from a single template." This supports option B.

3. VMware vSphere Documentation (vSphere 8.0)

vSphere Virtual Machine Administration

"Cloning an Existing Virtual Machine".

Section: "Clone a Virtual Machine" details the cloning wizard

which includes an option to "Customize the operating system." The documentation notes

"To prevent network conflicts

you must customize the guest operating system of the cloned virtual machine." This reinforces the need for customization (Option B) when deploying copies.

Q: 4

A company has two sites: Site A and Site B. The administrator would like to manage the VMware vCenter inventories in both sites from a single vSphere Client session. Which vCenter feature must be configured?

Options

Correct Answer:

Explanation

Enhanced Linked Mode (ELM) is the vCenter Server feature designed to connect multiple vCenter Server instances. When configured, ELM allows an administrator to log in to any of the linked vCenter Servers and view and manage the inventories (such as hosts, virtual machines, and clusters) of all connected vCenter Servers from a single vSphere Client session. This provides a unified management pane across different sites or vCenter instances, directly addressing the administrator's requirement to manage both Site A and Site B from one interface.

Why Incorrect

A. VMware Certificate Authority: This component manages security certificates for vSphere components but does not provide a unified management interface for multiple vCenter inventories.

B. VMware Site Recovery Manager: This is a disaster recovery and business continuity solution used to orchestrate failover between sites, not for unified day-to-day inventory management.

C. vCenter Single Sign-On: This provides authentication services, allowing a user to log in once. While a prerequisite for ELM, it is the authentication mechanism, not the feature that links the inventories.

References

1. VMware vSphere Product Documentation

vCenter Server and Host Management (vSphere 8.0).

Section: "vCenter Enhanced Linked Mode"

Content: "vCenter Enhanced Linked Mode allows you to log in to any single instance of vCenter Server and view and manage the inventories of all the vCenter Server systems in the group. You can join up to 15 vCenter Server appliance deployments with vCenter Enhanced Linked Mode in a single vSphere Single Sign-On domain." This directly confirms that ELM provides the single-pane-of-glass management required by the question.

2. VMware vSphere Product Documentation

vSphere Installation and Setup (vSphere 8.0).

Section: "vSphere Authentication"

Content: "vCenter Single Sign-On is an authentication broker and security token exchange infrastructure... When you install vCenter Server

you deploy a vCenter Single Sign-On server." This reference clarifies that SSO's role is authentication

distinguishing it from the management linking function of ELM.

3. VMware vSphere Product Documentation

Site Recovery Manager Administration (Version 8.7).

Section: "Introduction to Site Recovery Manager"

Content: "VMware Site Recovery Manager is a business continuity and disaster recovery solution that helps you to plan

test

and run the recovery of virtual machines between a protected vCenter Server site and a recovery vCenter Server site." This defines SRM's purpose as disaster recovery

not unified management.

Q: 5

An administrator is tasked with installing VMware vCenter. The vCenter Server Appliance must support an environment of: • 400 hosts • 4000 virtual machines Which two resources must be allocated, at a minimum, to meet the requirements? (Choose two.)

Options

Discussion

QuietOps3325 Mar 4, 2026 11:21 am

I'd pick B and D too. 8 vCPUs (D) and 30 GB memory (B) match the Medium deployment specs for vCenter, which is needed for that many hosts. Not completely sure if this changed recently but that's how I remember it.

LunaM Mar 3, 2026 7:18 pm

D and B. A is overkill, C/E would undersize for 400 hosts. Pretty sure that's what VMware guides list for Medium size.

Parker Feb 28, 2026 6:25 pm

Option A I keep seeing conflicting info in VMware docs about vCPU, so I'm thinking 16 vCPUs should cover it?

Noah S. Feb 19, 2026 4:28 pm

D/B? I get why people might think A for CPUs, but that's only needed for the "Large" vCenter deployment size, not this one. The trap is picking more resources than necessary, which VMware actually doesn't require for the given host and VM count. Specs change between versions, but pretty sure D and B are the safe minimums per the current guides. Anyone see a reason to go higher?

Arjun K. Mar 4, 2026 12:55 pm

B and D here. Medium deployment spec in the docs shows 8 vCPUs and 30 GB RAM as the minimum for 400 hosts/4000 VMs. If VMware changes these numbers in a future release, might need to adjust. Anyone disagree?

Maya Feb 15, 2026 6:53 am

A is wrong, D and B. Official sizing guides or practice tests back this up.

Sara X. Feb 15, 2026 4:04 am

B and D imo. Medium deployment is what you want for 400 hosts, so that's 8 vCPUs (D) and 30 GB RAM (B) per VMware's official sizing charts. C or E would undersize the environment and probably cause issues with performance. Haven't seen these requirements shift lately, but correct me if I'm missing something.

Daniel X. Feb 22, 2026 5:49 pm

Its D and B since Medium deployment covers up to 400 hosts, and VMware docs list 8 vCPUs plus 30GB RAM for that size. C/E would be too low. Anyone see these specs change in recent updates?

Ishaan J. Mar 2, 2026 7:15 am

Medium-sized vCenter needs at least 8 vCPUs and 30 GB memory for that many hosts and VMs. So, D and B fit here based on VMware sizing guides. Pretty sure about this but open if someone has newer sizing info.

Be respectful. No spam.

Correct Answer:

B, D

Explanation

The specified environment of 400 hosts and 4000 virtual machines corresponds to the "Medium" deployment size for the vCenter Server Appliance (VCSA). According to the official VMware vSphere documentation, a Medium deployment size has a minimum requirement of 8 vCPUs and 28 GB of memory (for vSphere 7.0) or 30 GB of memory (for vSphere 8.0). The options provided are 8 vCPUs and 30 GB of memory, which directly meet these minimum hardware specifications. Deploying with fewer resources would result in an unsupported configuration and potential performance issues.

Why Incorrect

A. 16 vCPUs: This allocation is for a "Large" deployment (up to 1000 hosts), which exceeds the minimum required for the specified environment.

C. 4 vCPUs: This allocation is for a "Small" deployment (up to 100 hosts), which is insufficient to support the required 400 hosts.

E. 20 GB Memory: This memory allocation is below the minimum requirement of 28 GB/30 GB for a "Medium" deployment and would be insufficient.

References

1. VMware vSphere 8.0 Documentation

"vCenter Server Installation and Setup". In the section "System Requirements for the vCenter Server Appliance

" the table "Hardware Requirements for the vCenter Server Appliance" specifies that a Medium environment (up to 400 hosts

4000 VMs) requires 8 vCPUs and 30 GB of Memory.

2. VMware vSphere 7.0 Documentation

"vCenter Server Installation and Setup". In the section "Hardware Requirements for the vCenter Server Appliance

" the table "Hardware Requirements for the vCenter Server Appliance for vSphere 7.0" specifies that a Medium environment (up to 400 hosts

4000 VMs) requires 8 vCPUs and 28 GB of Memory. Option B (30 GB) is the closest choice that meets this minimum requirement.

Q: 6

An administrator enables Secure Boot on an ESXi host. On booting the ESXi host, the following error message appears: Fatal error: 39 (Secure Boot Failed)

Options

Discussion

Ava Feb 20, 2026 6:20 am

Why does error 39 always map to the kernel and not VIB/driver issues? Just want to be sure I'm not missing a nuance in Secure Boot chain for ESXi.

CuriousMentor9853 Feb 16, 2026 7:44 am

I don’t think it’s D. A is correct for error 39, kernel tamper triggers this specific Secure Boot fail.

Reese F. Feb 21, 2026 10:59 am

Probably A, since error 39 maps to the kernel tamper specifically, D is a trap if you miss the code.

Taylor A. Feb 13, 2026 4:20 pm

Might be D, since tampered VIBs or drivers can mess with Secure Boot checks.

Skyler Mar 1, 2026 12:35 pm

D tbh, Secure Boot errors can pop up if a VIB or driver was messed with.

QuickCandidate760 Feb 26, 2026 6:09 pm

Yeah I think A is right. Secure Boot error 39 usually means kernel tamper, not just a package or driver.

MiaP Feb 24, 2026 9:19 am

Pretty sure it's A since the "Fatal error: 39" is usually thrown when Secure Boot can't verify the kernel signature, not just a random driver or VIB. D can cause issues, but that specific error points to the kernel itself being tampered. If someone has different experience, let me know.

Quinn N. Feb 13, 2026 1:27 pm

Its D, because a VIB or driver tamper could also trigger Secure Boot errors like this.

FocusedNeteng251 Feb 26, 2026 2:50 am

Looks like that's pointing to a kernel issue. A

Be respectful. No spam.

Correct Answer:

Explanation

The error message "Fatal error: 39 (Secure Boot Failed)" is generated by the ESXi bootloader (mboot.efi). The ESXi boot process with UEFI Secure Boot enabled follows a strict chain of trust. First, the UEFI firmware verifies the signature of the ESXi bootloader. Once the bootloader is verified and executed, its primary responsibility is to verify the digital signature of the VMkernel. The "Fatal error: 39" specifically indicates that this second step has failed; the bootloader was unable to validate the kernel's signature. This failure halts the boot process to prevent a potentially compromised or corrupted kernel from loading.

Why Incorrect

B. The Trusted Platform Module chip has failed.

The Trusted Platform Module (TPM) is primarily used for remote attestation and storing cryptographic keys, not for validating component signatures during the Secure Boot process itself.

C. The administrator attempted to boot with a bootloader that is unsigned or has been tampered with.

If the bootloader were invalid, the UEFI firmware would have blocked it from executing. The error would originate from the system's UEFI firmware, not the ESXi environment.

D. A package (VIB or driver) has been tampered with.

Packages (VIBs) are verified by the VMkernel after the kernel has been successfully loaded. A VIB signature failure would occur later in the boot sequence and result in a different error.

References

1. VMware vSphere Documentation

"Managing ESXi Booting with UEFI Secure Boot": "When UEFI Secure Boot is enabled on an ESXi host

the bootloader is first to be verified by the UEFI firmware. After the bootloader is verified

the bootloader verifies the ESXi kernel. Finally

the kernel verifies each VIB." This official documentation confirms the boot sequence

placing the kernel verification step immediately after the bootloader is loaded

which is when the specified error occurs.

2. VMware vSphere 8 Security Guide (PDF)

Page 49

"ESXi Secure Boot": "The ESXi bootloader contains a VMware public key. The bootloader uses this key to verify the signature of the kernel... The kernel in turn verifies the signature of every VIB that is loaded." This source explicitly states that the bootloader is responsible for verifying the kernel

reinforcing that a failure at this stage is due to a kernel issue.

3. VMware Knowledge Base Article 2147606

"ESXi host fails to boot with error: Fatal error: 39 (Secure Boot Failed)": This KB article documents the specific error message. While it describes a scenario where an outdated bootloader is the root cause of the problem (as it cannot correctly process the new kernel)

the direct trigger for the "Fatal error: 39" message is the bootloader's failure to verify the kernel signature. This supports that the error is tied to the kernel verification step.

Q: 7

An administrator has mapped three vSphere zones to three vSphere clusters. Which two statements are true for this vSphere with Tanzu zonal Supervisor enablement? (Choose two.)

Options

Discussion

Jack J. Feb 16, 2026 4:41 am

B/E from what I've seen in the official docs and practice tests.

MethodicalLearner8055 Mar 2, 2026 3:59 am

Maybe D and A. I saw something similar on a practice exam where it indicated Supervisors could be mapped per zone, and Namespaces would stay inside that zone. Not totally sure, anybody else see it this way?

Chloe A. Feb 25, 2026 9:04 pm

Option B and E here. Supervisor gets stretched across all zones, not created per zone. Trap is A, but that's how the legacy setup worked before zonal topology came out. Anyone disagree?

ChloeP Feb 20, 2026 3:51 pm

Nice, clear question on Tanzu zones. B and E are correct.

Vikram N. Feb 22, 2026 7:51 am

I don’t think A or D is right here, it’s B and E. Trap is thinking each zone gets its own Supervisor, but zonal mode stretches one across all zones and Namespaces aren’t confined per zone.

SharpTester2219 Feb 24, 2026 4:49 am

B E
That’s how vSphere with Tanzu zonal Supervisor works now.

SofiaX Feb 21, 2026 2:21 am

I get the confusion, but in zonal Supervisor mode it's a single Supervisor stretched over all zones (so B), and Namespaces aren't locked to one-they spread across (E). This tripped me up at first because old clusters worked differently. Let me know if you see any docs saying otherwise.

LoganR Feb 24, 2026 11:25 am

It’s B and E for zonal Supervisor, since one Supervisor spans all zones and Namespaces aren’t tied to a single zone. Pretty sure, vSphere 8 changed this from the older per-cluster setup. If anyone sees it different, let me know.

Be respectful. No spam.

Q: 8

An administrator is completing the configuration of a new vSphere cluster and has enabled vSphere High Availability (HA) and vSphere Distributed Resource Scheduler (DRS). After adding the ESXi hosts to the cluster, which networking information will the administrator be prompted to provide when using the Cluster Quickstart workflow?

Options

Correct Answer:

Explanation

The Cluster Quickstart workflow in vSphere is designed to streamline the creation and configuration of a cluster. After the initial step of enabling services like vSphere High Availability (HA) and Distributed Resource Scheduler (DRS) and the second step of adding ESXi hosts, the workflow proceeds to the 'Configure cluster' step. In this final step, it configures the necessary networking for the enabled features. Both DRS (for workload balancing) and HA (for migrating VMs) depend on vMotion. Therefore, the workflow prompts the administrator to configure vMotion networking, typically by creating a vSphere Distributed Switch and migrating the hosts' vMotion VMkernel adapters.

Why Incorrect

B. Management networking: This must be configured on each ESXi host before it can be added to vCenter Server and the cluster. It is a prerequisite, not a post-addition configuration step in this workflow.

C. vSAN networking: The workflow only prompts for vSAN networking configuration if the vSAN service was explicitly enabled in the first step of the Quickstart process. The question does not state that vSAN was enabled.

D. Virtual machine networking: While the workflow creates a vSphere Distributed Switch that can be used for VM networking, its primary prompted task for HA and DRS is to configure the essential infrastructure networking, which is vMotion.

References

1. VMware vSphere 8.0 Documentation

vCenter Server and Host Management

"Create a Cluster with the vSphere Client".

Section/Reference: In the description of the Cluster Quickstart workflow

Step 3

"Configure cluster

" states: "The workflow validates the hosts for NTP and HA configuration. It also configures vMotion and vSAN networking on the hosts by creating a vSphere Distributed Switch and moving the hosts' VMkernel adapters to the distributed switch." This directly confirms that vMotion networking is configured.

2. VMware vSphere 7.0 Documentation

vCenter Server and Host Management

"Using the Cluster Quickstart Workflow".

Section/Reference: The section "Configure the Newly Created Cluster" details the final step of the workflow. It explicitly mentions configuring networking for vMotion: "The workflow configures networking on the hosts for vMotion... by creating a vSphere Distributed Switch."

Q: 9

Refer to the exhibit.

After removing an ESXi host from a cluster for maintenance, a number of virtual machines have encountered the warning seen in the exhibit. After re-adding the ESXi, the issue is resolved. Which step should the administrator take to move the triggered alarm to its normal state?

Options

Discussion

Nina U. Feb 24, 2026 9:43 am

I've always just acknowledged these alarms and they go away, so C.

Mia Y. Feb 14, 2026 6:25 am

I don’t think C is right, it’s got to be B. Acknowledge only stops the pop-up, doesn’t change the alarm itself in vSphere.

Aisha T. Feb 19, 2026 7:05 am

Why do some folks think acknowledging the alarm (C) actually resets it? Doesn't that just silence notifications instead of fixing the root alert state in vSphere? Curious if anyone's seen different in 8.x clusters.

Owen X. Feb 28, 2026 7:24 pm

Yeah, Reset to Green is the move here (B). Acknowledge only quiets the notification but doesn't actually put the alarm back to normal state in vCenter. Pretty sure that's the expected VMware workflow, but let me know if I'm wrong.

Nina O. Feb 21, 2026 11:21 am

A is wrong, B. You actually need to "Reset to Green" so the alarm state clears out after the issue is fixed. Just acknowledging it doesn't do that, it just hides the notification. Seen this on my test cluster, pretty sure that's how VMware works.

Parker I. Feb 21, 2026 4:33 pm

Probably B here. When the HA issue is fixed, vCenter doesn't always clear the alarm on its own. "Reset to Green" actually resets the status, where Acknowledge just silences it. I'm pretty sure that's the official workflow for these alarms.

Noah Feb 26, 2026 2:22 am

C or B for me. I've always just hit Acknowledge (C) on these and the alarm seemed to clear up, especially in smaller labs, but maybe that's not how it works at scale. Is Acknowledge just for silencing the alert instead of actually resetting its state? Maybe I'm mixing up vCenter behavior here-let me know if I'm off.

Avery P. Mar 3, 2026 4:36 pm

A isn’t right, it’s B. Pretty sure you have to use “Reset to Green” for vSphere HA alarms after fixing the resource issue, otherwise the alert stays active even though things are fine now. Someone confirm?

Be respectful. No spam.

Correct Answer:

Explanation

The "vSphere HA virtual machine failover failed" alarm is triggered when vSphere High Availability determines there are insufficient resources in the cluster to fail over a virtual machine. Removing a host for maintenance reduced the cluster's available resources, triggering this condition. After the host was re-added, the resource constraint was resolved. However, the alarm state does not automatically clear. The administrator must manually intervene to clear the alarm. The "Reset to Green" action is the correct procedure to manually override the alarm's status and return it to normal (green), signifying that the underlying issue has been resolved.

Why Incorrect

A. Ignore: This is not a formal action in the vSphere Client to clear an alarm; it would leave the system in a persistent warning state.

C. Acknowledge: Acknowledging an alarm only confirms that an administrator has seen it. It does not clear the alarm or change its color status from warning to green.

D. Disable: Disabling the alarm is a permanent configuration change that would prevent this specific alarm from ever triggering again, which is not the appropriate response to a resolved, temporary issue.

References

1. VMware vSphere Product Documentation

"vSphere Monitoring and Performance" (for vSphere 8.0): In the section "Acknowledge or Reset a Triggered Alarm

" the documentation states

"You can reset the alarm to clear it and return it to its normal state... Resetting an alarm also clears any acknowledgment for the alarm." This directly supports using "Reset to Green" to clear a resolved alarm.

2. VMware Knowledge Base Article 2004802

"'vSphere HA virtual machine failover failed' alarm in vCenter Server": This article explains the cause of the specific alarm in the question

noting it is triggered by insufficient failover capacity. It confirms that after resolving the underlying resource issue (like re-adding a host)

the alarm must be manually cleared. The procedure described is functionally identical to "Reset to Green".

3. VMware vSphere Product Documentation

"vSphere Availability" (for vSphere 8.0): The section on "vSphere HA Admission Control" explains the conditions that lead to failover resource constraints. This provides the context for why removing a host would trigger the alarm

and implicitly

why re-adding it resolves the condition that needs to be manually cleared.

Q: 10

An administrator is tasked with configuring vSphere Trust Authority. The administrator has completed the following steps: • Set up the workstation • Enabled the Trust Authority Administrator • Enabled the Trust Authority State • Collected information about the ESXi hosts and vCenter to be trusted Which step does the administrator need to complete next?

Options

Correct Answer:

Explanation

The vSphere Trust Authority configuration follows a specific, ordered workflow. The administrator has completed the initial setup steps, including enabling the Trust Authority services and collecting the necessary information from the hosts that will be trusted. According to the official VMware documentation, the immediate next step in this process is to import the collected ESXi host information into the Trust Authority cluster. This action establishes the trust relationship by registering the trusted hosts' identities and attestation information with the Trust Authority service, which is a prerequisite for configuring the key provider.

Why Incorrect

B. The data flow is reversed. Information is collected from the trusted hosts and imported to the Trust Authority cluster, not the other way around.

C. Configuring the Key Provider on the trusted cluster is a subsequent step that occurs only after the trust has been established by importing the host information.

D. The destination is incorrect. The host information is imported into the Trust Authority Cluster, not the Trusted Cluster from which the information was gathered.

References

1. VMware vSphere 8.0 Security Documentation. "Configuring and Managing vSphere Trust Authority

" section: "vSphere Trust Authority Configuration Workflow." The documentation lists the steps in sequence

showing that after "Collect Information About the ESXi Hosts and vCenter Server to Be Trusted

" the next step is "Import the Trusted Host Information to the Trust Authority Cluster."

2. VMware vSphere 7.0 Security Documentation. Chapter 10

"vSphere Trust Authority

" section: "vSphere Trust Authority Configuration Workflow." This document for the version where the feature was introduced confirms the same procedural order

validating the required next step.

Question 1 of 20 · Page 1 / 2

Premium Access Includes

✓ Quiz Simulator
✓ Exam Mode
✓ Progress Tracking
✓ Question Saving
✓ Flash Cards
✓ Drag & Drops
✓ 3 Months Access
✓ PDF Downloads

Get Premium Access

Premium Access Includes

FLASH OFFER

avail 10% DISCOUNT on YOUR PURCHASE