Free Practice Questions for Microsoft AZ-802 Exam

Rule Type: Isolation. Requirements: Require authentication for inbound and outbound connections. Authentication Method: Computer (Kerberos V5).

Restricting a set of servers so that they only accept inbound connections from, and only initiate outbound connections to, other domain-joined computers describes the classic domain or server isolation scenario in Windows Defender Firewall with Advanced Security, so the rule type must be Isolation rather than Tunnel, which is used to secure gateway-to-gateway traffic, or Authentication exemption, which excludes specific hosts from having to authenticate at all. Because both stated requirements use the word only, with no allowance for a fallback to unauthenticated traffic in either direction, the Requirements setting must be set to Require authentication for inbound and outbound connections rather than the softer default of requiring authentication only for inbound connections while merely requesting it for outbound connections. Since every server in OU1 and every legitimate client that needs to reach them is already joined to the contoso.com domain, Computer (Kerberos V5) is the appropriate authentication method, because it uses the existing Active Directory infrastructure for authentication and avoids the certificate enrollment and public key infrastructure overhead that would only be necessary if non-domain-joined devices needed to be included in the trust boundary.

Azure Relay ' s Hybrid Connections feature is designed specifically to expose an on-premises application, such as App1, to the internet without opening any inbound ports on the on-premises firewall: a small Hybrid Connection Manager agent installed on-premises establishes an outbound-only connection to the Azure Relay service, and internet clients then reach the on-premises app through that relay, so Firewall1 needs no new inbound rules at all -- the connection is entirely outbound-initiated from the on-premises side. Hybrid Connections also natively supports WebSockets-based traffic, matching how internal users already connect to App1. Microsoft Application Request Routing (ARR) is an IIS extension for reverse-proxying and load-balancing HTTP(S) traffic; using it to expose App1 to the internet would still require opening an inbound port on Firewall1 for the reverse proxy to receive traffic, unless combined with something like Azure Relay, so it does not meet the " minimize inbound ports " requirement on its own. Web Application Proxy is an on-premises AD FS/pre-authentication reverse proxy role that also requires an inbound-facing listener and open firewall ports to accept traffic from the internet. Azure Application Gateway is an Azure-hosted load balancer/WAF that operates on resources already reachable from Azure (such as VMs or on-premises endpoints reachable via VPN/ExpressRoute); it does not eliminate the need for inbound connectivity to an on-premises firewall the way Azure Relay ' s outbound-only model does. Therefore, Azure Relay (Hybrid Connections) is the correct inclusion.

Storage tiers require a storage pool to contain physical disks of at least two distinct media types, typically SSD and HDD, because a tiered virtual disk places frequently accessed data on the faster tier (SSD) and less-active data on the slower tier (HDD); Storage Spaces classifies disks by MediaType as HDD, SSD, or SCM, and rotational speed alone (such as 7,200 RPM versus 10,000 RPM) does not create a separate media type — both speeds are still classified simply as HDD. Pool1 contains only 7,200 RPM and 10,000 RPM HDDs and no SSDs at all, so despite having two different physical disk speeds, it has only one media type present and cannot support storage tiers. Pool2 contains 10,000 RPM HDDs together with SSDs, giving it the two distinct media types (HDD and SSD) that tiering requires, so it qualifies. Pool3 contains 7,200 RPM HDDs together with SSDs, which likewise gives it both an HDD and an SSD tier, so it also qualifies. Because tiered virtual disks need both a performance tier and a capacity tier represented by different media types, only Pool2 and Pool3 meet the requirement, and Pool1 does not, making option A correct.

Storage Migration Service is specifically designed to migrate file shares and their data while also supporting a cutover step that transfers the source server ' s name (and optionally IP address) to the destination, which is what allows users to keep referencing \\server1\share1 even after Server1 is decommissioned. File Server Resource Manager only manages quotas, screening, and reporting rather than performing migrations, Windows Server Migration Tools does not provide the identity-takeover/cutover capability needed to preserve the original UNC path, and Azure Migrate is oriented toward moving workloads into Azure rather than between on-premises servers. Storage Migration Service also minimizes administrative effort through its wizard-driven Windows Admin Center interface that walks an administrator through inventory, transfer, and cutover in a single tool. Because the requirement explicitly calls for preserving the original UNC path after decommissioning Server1, only a tool that performs an identity transfer as part of the migration satisfies both stated requirements at once.

The legacy Log Analytics agent, also known as the Microsoft Monitoring Agent or OMS agent, reached end of support on August 31, 2024, and Microsoft has retired it in favor of the Azure Monitor Agent (AMA). The Windows Firewall data connector in Microsoft Sentinel is delivered through the Azure Monitor Agent together with a data collection rule that targets the Windows Firewall event log source, not through the retired Log Analytics agent, so an environment built around this connector has no configuration path that recognizes or uses the legacy agent ' s data. Installing the Log Analytics agent on Server1 therefore does not create the association between Server1 and the data collection rule that the Windows Firewall connector requires, and it does not enable any log forwarding pipeline that Microsoft Sentinel ' s current connector architecture can consume. Because the connector depends entirely on AMA and Server1 additionally needs to be Azure Arc-enabled since it is an on-premises machine, installing the deprecated Log Analytics agent does not enable Sentinel to collect Windows Firewall logs from Server1, so this solution does not meet the goal.

1. Add-KdsRootKey 2. New-ADServiceAccount 3. Install-ADServiceAccount

Before any group managed service account can be created in a forest, the Key Distribution Service root key must exist, since it supplies the key material the KDS uses to compute and periodically roll the gMSA ' s password; this is created once with Add-KdsRootKey. Next, New-ADServiceAccount creates the actual gMSA object, and its -PrincipalsAllowedToRetrieveManagedPassword parameter can be pointed directly at the existing NLBHosts group, which authorizes all five NLB nodes to retrieve the managed password in a single step, without needing to grant permission to each computer individually. Finally, Install-ADServiceAccount must be run locally on each of the five NLB nodes to actually install and cache the gMSA account on that computer, which is what allows the NLB service running there to authenticate as the gMSA. Set-KdsConfiguration adjusts advanced KDS server-side settings and is not a required step in standard gMSA provisioning. Add-ADGroupMember would only be needed if authorization were being granted by adding individual computer accounts to a security group after the fact, which is unnecessary here since the group already exists and is referenced directly. Add-ADComputerServiceAccount associates a computer with a standalone (non-group) managed service account and does not apply to gMSA scenarios like this one.

A broken trust relationship exists because the computer account password Server1 has stored locally no longer matches the password value AD DS holds for the Server1$ computer account, and repairing the secure channel requires both sides of that shared secret to be resynchronized to the same value. Set-ADAccountPassword -Identity " Server1$ " -Reset changes only the AD DS side of that shared secret: it sets a new password value on the computer account object as stored in the directory, but it has no mechanism to also update the local secret Server1 itself has cached, since Set-ADAccountPassword is an Active Directory module cmdlet that operates purely against the directory over LDAP/Kerberos and never touches a computer ' s local machine-account secret store. After running this cmdlet, the two sides of the secure channel are now mismatched in the opposite direction from before (AD DS has the new password, Server1 still has the old one), which does not restore the trust relationship at all and can, in practice, leave the account in exactly the same broken state or worse. Restoring the secure channel properly requires a cmdlet or tool that updates both sides together, such as Test-ComputerSecureChannel -Repair or Reset-ComputerMachinePassword run from Server1 itself, neither of which this solution uses, so this solution does not meet the goal.

 For User1, \\server2\share maps to drive H.: No

 For User2, \\server1\share maps to drive H.: Yes

 For User3, \\server3\share maps to drive H.: No

The Administering Windows Server Hybrid Core Infrastructure materials explain that Group Policy is processed in the order Local → Site → Domain → OU, with the last applied policy normally taking precedence. Two modifiers change this behavior: Enforced (No override) on a GPO link and Block inheritance on a container/OU. The guide states that an Enforced link “prevents child containers from overriding settings in that GPO,” while Block inheritance “prevents higher-level GPOs from applying except those marked Enforced.”

Applying these rules:

User1 (Contoso\Users) is not in OU1, so GPO2 (drive H to \\server2\share ) does not apply. Only domain-level GPOs apply to the Users container; thus, the statement for \\server2\share is No.

User2 (OU1) receives GPO1 (Domain, Enforced) and GPO2 (OU1). Because GPO1 is Enforced, its mapping (H → \\server1\share ) cannot be overridden by GPO2, so the statement is Yes.

User3 (OU1\OU2) is in OU2, which has Block inheritance. This blocks higher GPOs except those Enforced, so GPO1 still applies and GPO2 is blocked. Although GPO3 (OU2) also applies, the Enforced domain GPO (GPO1) takes precedence over conflicting lower-level settings, so H: remains \\server1\share , making the statement about \\server3\share No.

Azure Files ' Microsoft Entra ID Kerberos authentication for a storage account share currently requires that the security group placed on the share ' s access control list be a Microsoft Entra security group with assigned membership; groups with dynamic membership rules are not supported for this purpose, and a Microsoft 365 group is a different kind of object that is likewise not a supported security principal for this access-control scenario. Creating the group in the Microsoft Entra tenant as a standard security group with assigned membership therefore satisfies the share2 requirement directly. Because Group writeback is already enabled in Microsoft Entra Connect, a cloud-created Microsoft Entra security group (with assigned, not dynamic, membership — writeback also does not support dynamic groups) is written back down into the on-premises AD DS domain as a corresponding group object, which is what allows it to be used in an NTFS or share permission entry on share1 and to contain (or be evaluated against) users whose accounts live in the on-premises AD DS domain. Creating the group directly in the on-premises AD DS domain (option A) would satisfy share1 but would not automatically exist as a Microsoft Entra security group usable for storage2 ' s Entra-ID-based access control unless synced up, which is not how writeback operates (writeback is one-directional, cloud to on-premises). Creating the group in the Entra tenant with assigned membership is therefore the single action that satisfies both requirements.

Adding or removing an application directory partition in AD DS -- including custom partitions such as the one App1 used to store its configuration data -- is an operation that must be performed against, and requires the availability of, the domain controller holding the Domain Naming Master FSMO role for the forest. This is the single operations master responsible for maintaining the list of domains and application partitions in the forest and for coordinating additions or removals of directory partitions; if that role holder is offline or unreachable, attempts to add or remove an application partition will fail, even though normal object read/write operations against other partitions (users, groups, and so on) may continue to function against any available domain controller. According to the exhibit ' s role assignments, DC3 holds the Domain Naming Master role. The Schema master (DC1) governs schema extensions, the Infrastructure master (DC2) governs cross-domain object reference updates, and the PDC emulator/RID master (DC4) govern time synchronization, password/authentication emulation, and relative ID pool allocation respectively -- none of these roles are involved in application partition add/remove operations. Because the removal of the custom application partition specifically failed, the unavailable domain controller must be the Domain Naming Master role holder, DC3.