Free Microsoft AZ-802 Practice Exam with Questions & Answers | Set: 3

An RODC only caches (replicates) the password of a security principal that is explicitly permitted by its Password Replication Policy — in the exhibit, only members of the built-in Allowed RODC Password Replication Group and the custom Group1 are set to Allow, while Administrators, Account Operators, Backup Operators, Server Operators, and the Denied RODC Password Replication Group are all set to Deny. A user who is not covered by an Allow entry authenticates through pass-through validation to a writable DC and never has credentials cached on the RODC, so User1 ' s credentials are not stored on RODC1, making statement 1 No. Because Server3 sits in Site2 alongside RODC1 and is a member of Group1 (an Allow entry), a user whose credentials are already cached there can still authenticate locally through RODC1 even if WAN connectivity to Site1 ' s writable domain controllers is lost, which is why User2 can sign in successfully during the outage, making statement 2 Yes. Interactive local sign-in to the RODC console itself is governed separately by the RODC ' s Administrator Role Separation (local Administrators group), not by the Password Replication Policy, and nothing in the scenario grants User3 that local logon right, so statement 3 is No.

Reset-ComputerMachinePassword is a PowerShell cmdlet designed specifically to reset a computer ' s domain account password directly against a specified domain controller, and when run locally on the affected computer itself, here Server1, targeting DC1 with -Server, it resets and resynchronizes the computer account ' s password on both sides of the secure channel: it generates a new password, writes it to the Server1$ computer account object on DC1, and simultaneously updates Server1 ' s own local machine-account secret to match, in a single coordinated operation. Because both the AD DS side and the local Server1 side of the shared secret end up holding the same new password value, the secure channel between Server1 and the domain is fully restored, resolving the trust relationship failed error. This is done without removing Server1 from the domain at any point, satisfying the stated constraint, and without changing any domain-wide or server-wide authentication policy setting. This cmdlet, along with Test-ComputerSecureChannel -Repair, is one of Microsoft ' s two documented, non-disruptive remediation methods for a broken computer secure channel, both of which succeed precisely because they update the password consistently on both the local computer and the domain controller rather than on only one side, unlike a solution that touches only the AD DS-stored value.

The documented approach for minimizing cluster downtime while performing an operating system upgrade on a single cluster node is to first pause that node and drain its currently running clustered roles, which causes those roles, including any highly available virtual machines or other clustered workloads, to live-migrate over to the remaining, still-active cluster members before any disruptive action is taken directly against Server1 itself. Only once Server1 has been paused and fully drained of its workloads is it safe to proceed with the actual operating system upgrade to Windows Server 2025 on that node, since the workloads it was hosting are now running elsewhere in the cluster and will not experience downtime while Server1 is being upgraded. Evicting Server1 from the cluster entirely, or taking the whole three-node cluster offline, are both far more disruptive first steps than necessary and would cause unnecessary downtime well beyond what pausing and draining a single node requires, since eviction removes the node from cluster membership altogether and taking the whole cluster offline would stop every clustered role on every node rather than only the one node being upgraded. Updating the functional level of the cluster is a step performed only after every node in the cluster has already been upgraded to the new operating system version, not before the rolling upgrade process even begins, so pausing Server1 and draining its workloads is the correct first action to take.

-source: apphostconfig= " Site1 " ,computername=Server1. -dest: apphostconfig= " Site1 " .

A pull synchronization performed using the Web Deployment Agent Service is executed from the destination server -- Server2 in this scenario -- and retrieves content from a remote source that is explicitly identified using the computername parameter, since a pull, unlike a push, is initiated by whichever machine is meant to receive the content. The msdeploy command is therefore run on Server2, with -source pointing at apphostconfig= " Site1 " ,computername=Server1 so the local Web Deploy Agent Service on Server2 reaches out over the network to the remote Web Deploy Agent Service already running on Server1, and -dest pointing at the local apphostconfig= " Site1 " without any computername value at all, since the destination is simply the machine the command is already executing on and needs no remote address. Specifying computername=Server2 on the destination side instead, or omitting computername entirely from the source side, would either misidentify the local machine as a remote target or fail to tell msdeploy which remote server actually holds Site1 ' s live configuration, breaking the pull operation before it could even start. This exact combination correctly pulls Site1 ' s IIS configuration and content from Server1 down onto Server2, completing the migration as required.

Recent password changes not recognized immediately: PDC emulator. Domains cannot be added or removed: Domain naming master.

The PDC emulator role is responsible for handling urgent, time-sensitive password change replication: when a user ' s password is changed on any writable domain controller, that DC immediately and preferentially replicates the change to the PDC emulator, and any other DC that fails to validate a sign-in attempt with a presented password will, before rejecting it, forward the authentication check to the PDC emulator to see if a more recent password change simply has not replicated to it yet; without a functioning PDC emulator, that fallback check cannot happen, so recently changed passwords fail to be recognized immediately across the domain until normal replication eventually catches up, exactly matching the first issue, and seizing the PDC emulator role onto DC2 restores that immediate cross-DC password-change recognition path. The domain naming master role is the single forest-wide authority responsible for ensuring the uniqueness of domain names anywhere new domains are added to, or existing domains removed from, the forest, and every add-domain or remove-domain operation must contact the domain naming master to be permitted to proceed; without an available domain naming master, those operations are blocked outright, exactly matching the second issue, and seizing that role onto DC2 restores the ability to add or remove domains. The RID master, infrastructure master, and schema master roles have no bearing on either symptom described.

The az vm repair create command creates a brand-new, temporary repair virtual machine and automatically attaches a copy of the problem VM ' s operating system disk to that repair VM as a data disk, which is precisely the documented technique for mounting an unbootable virtual machine ' s OS disk offline onto another machine so that boot configuration data, drivers, or registry settings can be inspected and corrected without needing the original VM to actually boot. The az vm boot-diagnostics enable command only turns on console output and screenshot capture for boot diagnostics; it does nothing to mount a disk elsewhere and would not help troubleshoot a disk that already fails to boot at all. The az vm capture command generalizes a virtual machine into a reusable image, which is a destructive operation on the source VM and is unrelated to offline disk troubleshooting. The az vm disk attach command requires the disk to already be detached from its original VM and does not, by itself, create a repair VM or copy the disk for the administrator, making the repair-create command the complete, purpose-built solution here.

Server administrators can be prevented from configuring Windows Defender Firewall rules by defining firewall policy centrally in a Group Policy Object and linking it to the servers ' organizational unit(s); domain-based GPO firewall policy overrides any local, administrator-configured Windows Defender Firewall rules on the domain-joined servers, since Group Policy-delivered firewall settings take precedence over local policy. Adaptive network hardening in Microsoft Defender for Cloud only generates recommendations to tighten network security group (NSG) rules protecting Azure resources -- it has no visibility into or control over host-based Windows Defender Firewall configuration on on-premises servers. A network security group (NSG) in Sub1 filters traffic at the Azure virtual network boundary and has no bearing on the on-premises Chicago office servers described in the scenario. An Azure Firewall policy governs the centrally managed Azure Firewall network virtual appliance, not the host-based Windows Defender Firewall running locally on each on-premises server. Because the servers in question are on-premises and domain-joined, only a Group Policy Object can centrally enforce and lock down their local Windows Defender Firewall configuration, preventing server administrators from modifying the rules directly on each machine. Therefore, configuring a GPO is the correct way to reduce this security risk.

A Windows Server failover cluster requires a distinct IP address for each individual cluster node ' s network adapter, plus one additional IP address for the cluster ' s own network name resource -- the cluster access point that clients and management tools use to address the cluster as a single logical entity rather than any one specific node. Cluster3 will contain two physical nodes, Node1 and Node2, so at minimum one IP address is required for Node1 ' s network adapter and one for Node2 ' s network adapter. Beyond those two node-level addresses, the cluster core resource itself (the cluster name object and its associated IP address resource) requires one more address so that the cluster can be addressed and managed as a whole and so that any highly available roles hosted on the cluster (such as the file share role planned for Cluster3) can obtain the network identity they need to fail over between nodes. Adding these together -- one for Node1, one for Node2, and one for the cluster ' s own network name -- yields a minimum of three IP addresses required for Cluster3 ' s node and cluster roles. Fewer than three would leave either a node or the cluster itself without a usable network identity, and while additional IP addresses may be consumed by highly available roles later added to the cluster, three is the baseline minimum for the node and cluster roles themselves.

Storage Migration Service is purpose-built to inventory the data, security descriptors, and both share-level and NTFS-level permissions on a source file server such as Fileserver1, transfer that data to a destination server such as Fileserver2, and then perform a cutover that reassigns the source server ' s network identity -- its computer name and IP address -- to the destination server. That cutover step is precisely what allows the existing \\Fileserver1\Data UNC path, already relied upon by the Chicago office application, to continue working unchanged after the migration, since client requests to that path transparently resolve to Fileserver2 once it has taken on Fileserver1 ' s identity. The Microsoft File Server Migration Toolkit and Windows Server Migration Tools are older, largely superseded utilities that can move some file server settings but do not provide this automated inventory-transfer-and-cutover workflow, and neither preserves the source server ' s identity on the destination the way Storage Migration Service does, meaning the UNC path would need to be manually updated or redirected. File Server Resource Manager (FSRM) is a quota, file-screening, and storage-reporting feature entirely unrelated to migrating data between servers. Therefore, Storage Migration Service is the correct tool to perform this migration while preserving the existing UNC path.

DHCP1: Export-DhcpServer, Remove-DhcpServerInDC. DHCP2: Add-DhcpServerInDC, Import-DhcpServer.

Migrating a DHCP server ' s configuration together with its existing leases and reservations by PowerShell follows an export/unauthorize-then-authorize/import pattern across the two servers. On the source server, DHCP1, Export-DhcpServer captures the existing scopes, options, leases, and reservations into a migration file, which is what allows the existing leases and reservations to actually carry over to the replacement server. Remove-DhcpServerInDC is then run on DHCP1 to unauthorize it in Active Directory, which is what prevents DHCP1 from continuing to service client requests once DHCP2 is brought online, satisfying that specific migration requirement. On the target server, DHCP2, Add-DhcpServerInDC authorizes the new server in AD DS so it is permitted to lease addresses on the network, and Import-DhcpServer then applies the configuration file exported from DHCP1, causing DHCP2 to hand out the same address ranges as DHCP1 along with the existing leases and reservations that were captured during export. Add-DhcpServerv4Scope and Remove-DhcpServerv4Scope only create or delete an individual scope ' s address range and do not export, import, or preserve any existing lease or reservation data, so neither is part of this migration sequence. Therefore, DHCP1 requires Export-DhcpServer and Remove-DhcpServerInDC, while DHCP2 requires Add-DhcpServerInDC and Import-DhcpServer.