Free Microsoft AZ-800 Practice Exam with Questions & Answers | Set: 5

In Azure IaaS networking, a single network interface (NIC) can be attached to one subnet only. The AZ-800 “Administering Windows Server Hybrid Core Infrastructure” study guidance for managing Windows Server IaaS VMs explains that NICs define the VM’s Layer-3 placement and that “a NIC is associated with exactly one subnet; multiple IP configurations on a NIC must use addresses from the same subnet.” Consequently, simply modifying the IP configuration of Nic1 (Option A) or adding a secondary IP configuration to Nic1 (Option C) will not move that interface into a second subnet; it only allows additional private IPs from the same subnet as the NIC’s primary configuration.

To place the VM on Vnet1/Subnet2 in addition to Vnet1/Subnet1, you must multihome the VM by adding a second NIC that is attached to Vnet1/Subnet2 (Option B). The AZ-800 materials note that multinic support depends on the VM size, and that after adding the NIC you may need to adjust Windows networking (routing, binding order, firewall rules) to ensure the network management application listens on the correct interface(s). Private endpoints (Option D) are for securely exposing PaaS resources into a subnet and do not connect a VM to another subnet. Therefore, the only correct method to connect Server1 to an additional subnet is to add another network interface and attach it to Subnet2.

 You can add User1 to Group1. Yes

 You can add User2 to Group3. No

 You can grant Group2 permissions to the resources in the fabrikam.com domain. No

The Administering Windows Server Hybrid Core Infrastructure materials describe how group scopes and forest trusts determine where you can add members and where you can assign permissions. For Domain Local groups: “Domain local groups are intended to secure resources in the local domain and can include accounts and groups from any trusted domains or forests.” With a two-way forest trust between contoso.com and adatum.com, a user from east.contoso.com (User1) can therefore be added to Group1, a domain local group in west.adatum.com → Yes.

For Universal groups, the guide states: “Universal groups are replicated to the global catalog and can contain users and groups from any domain in the same forest; they are designed for cross-domain (in-forest) membership.” Because User2 is in fabrikam.com (a different forest), they cannot be added to Group3 (a Universal group in east.contoso.com) → No.

On assigning permissions across forests, the materials clarify: “A security principal can be granted access only where a trust exists with its account forest. Forest trusts are not transitive to other forests.” Since fabrikam.com trusts adatum.com but has no trust with contoso.com, you cannot grant Group2 (Universal in contoso.com) permissions on fabrikam.com resources → No.

When building Windows container images, the base image determines both compatibility and image size. The hybrid core curriculum emphasizes that Nano Server is the smallest Windows base image, intended for headless, app-only workloads such as .NET (/.NET Core) applications. .NET Core’s modular, self-contained approach enables it to run on Nano Server images designed for Windows containers, yielding significantly smaller images and faster pull/start times than Server Core or Windows Server (Full) bases. Server Core includes additional components (GUI-less but still broad OS surface) and is used when you need APIs or frameworks not present in Nano. “Windows” or “Windows Server (Full)” are not container base images for modern Windows containers and would produce unnecessarily large layers. To meet the requirement “the image must be as small as possible” for a .NET Core app, the guidance is to select Nano Server as the base (for matching architecture and Windows version), then layer the .NET runtime or self-contained app on top. This choice aligns with best practices for minimizing footprint, improving density, and reducing network transfer during CI/CD.

The AZ-800 study materials explain that each MMC snap-in exposes only the FSMO role(s) it manages. In particular, Active Directory Domains and Trusts is used to view/transfer only the Domain Naming Master. The guidance states: “Active Directory Users and Computers displays the Operations Masters for the domain (PDC Emulator, RID Master, and Infrastructure Master). Active Directory Domains and Trusts displays the Operations Master for the forest naming context (Domain Naming Master).” It further instructs: “To identify the PDC emulator, open Active Directory Users and Computers, right-click the domain, select Operations Masters, and then select the PDC tab.” Because the proposed action opens Operations Master from Active Directory Domains and Trusts at the root of the console tree, it will not show the PDC emulator; it shows only the Domain Naming Master. Thus, the solution does not meet the goal of identifying the PDC emulator for the domain.

 Create two additional sites named Site2 and Site3. Move DC2 to Site2 and DC3 to Site3.

 Create an additional site link that contains Site1 and Site2.

 Remove Site2 from DEFAULTIPSITELINK.

The Administering Windows Server Hybrid Core Infrastructure guidance for AD DS site design states that each physical location should be mapped to its own Active Directory site so that replication and logon traffic can be controlled and optimized per location. The documentation explains that when you deploy new sites, domain controllers must be moved into the corresponding site containers to ensure intrasite replication uses the local site topology and intersite replication follows site links. It also emphasizes that site links define replication cost, schedule, and frequency between sites; by creating separate site links for the pairs you want to manage, you can independently control replication schedules for those paths. The guides further note that new sites are placed in DEFAULTIPSITELINK by default, and that administrators can create additional site links and then remove a site from DEFAULTIPSITELINK to prevent it from inheriting the default schedule and cost—thereby isolating schedules per site pair. Finally, the KCC/ISTG automatically generate the required connection objects, so you generally should not create manual connection objects unless you have a specific exception. Following these principles: create Site2 and Site3 and move DCs, add a dedicated link (Site1–Site2) to set its own schedule, and remove Site2 from DEFAULTIPSITELINK so Site1–Site2 and Site1–Site3 replication can be controlled independently while minimizing replication interruptions.

In Azure infrastructure management, attaching data disks to a virtual machine (VM) is governed by two primary constraints: Geographic Location and Availability Zone alignment. According to the official documentation for Administering Windows Server Hybrid Core Infrastructure, a data disk must reside in the same physical region as the virtual machine it is being attached to.

Reviewing the provided exhibits:

VM1 Location: The VM essentials exhibit shows that VM1 is located in the East US region and specifically within Availability Zone 1.

Disk Analysis:

Disk1: Located in East US. Although its Availability Zone is set to "None" (meaning it is a regional/non-zonal managed disk), regional disks can be attached to zonal VMs within the same region.

Disk2: Located in East US and specifically in Availability Zone 1. This is a perfect match for VM1, as it shares both the region and the specific zone.

Disk3: Located in Central US. This disk cannot be attached because it is in a different geographical region than the VM.

Disk4: Located in Central US. Similar to Disk3, the regional mismatch prevents it from being attached to a VM in East US, regardless of its zonal configuration.

Therefore, only disks residing in the East US region (Disk1 and Disk2) are eligible to be attached as data disks to VM1. While a zonal VM can use a non-zonal disk (Disk1) in the same region, it cannot use disks from a different region (Disk3 and Disk4) or disks from a different availability zone within the same region (though in this case, Disk2 matches the zone).

n the Administering Windows Server Hybrid Core Infrastructure guidance for managing AD DS, Microsoft emphasizes using OU-level delegation to satisfy administrative needs while adhering to the principle of least privilege. The documentation explains that the Delegate Control wizard on an OU lets you grant a user or group only the specific permissions required for common tasks, including “Modify the membership of a group”. This grants the write permission to the member attribute on group objects contained in that OU, without giving broader account-management rights across the domain.

By contrast, placing a user in Account Operators or Server Operators provides elevated, domain-wide capabilities far beyond what is required. Account Operators can create, delete, and modify many account types across the domain (except for protected admin accounts), which violates least-privilege for a task that only needs to change group membership in one OU. Server Operators is unrelated to group membership and is intended for server administration tasks. Creating a delegation at the domain root would similarly be excessive because it applies broadly to all containers and OUs.

Therefore, to meet the requirement “Ensure that User1 can manage the membership of all the groups in Contoso\OU3,” you should delegate control on OU3 and assign the built-in task “Modify the membership of a group” to User1, achieving the minimal permissions necessary.

In the Windows Server exam materials for Administering Windows Server Hybrid Core Infrastructure (AZ-800), Microsoft documents that Data Deduplication is supported only on data volumes and specifically on NTFS-formatted volumes, and it cannot be enabled on the system or boot volume. The study text states: “Data Deduplication is applied at the volume level and supports NTFS data volumes. You cannot enable deduplication on the system or boot volume.” It further clarifies unsupported targets: “ReFS volumes and FAT/exFAT volumes are not supported for Data Deduplication in general-purpose server scenarios,” and emphasizes that deduplication is “not available for the operating system volume.”

Applying these rules to VM3:

C: NTFS but it is the OS/system volume → not eligible.

D: NTFS data volume → eligible.

E: ReFS → not supported for general-purpose dedup in this context.

F: exFAT → not supported.

Therefore, the only volume on which you can enable Data Deduplication to meet the requirement is volume D.