Explanation:
A Windows Server failover cluster requires specific IP addresses for cluster communication and client access. For a two-node cluster like Cluster3, you need IP addresses for each node for node-to-node communication, plus additional IP addresses for the cluster itself and any cluster roles (applications/services).

Correct Option:

B. 3:
The minimum IP addresses required are: one IP address for each of the two cluster nodes (2 IPs) for node-to-node communication and cluster management, plus one IP address for the Cluster Name Object (CNO) that represents the cluster itself. This allows the cluster to function and be accessible on the network. If a clustered role requires its own client access point, additional IP addresses would be needed, but the question asks for node and cluster roles only, not application roles.

Incorrect Option:

A. 2:
Two IP addresses would only cover the two nodes but would leave no IP address for the cluster itself. The cluster must have its own identity and IP address to be managed and accessed as a single entity.

C. 4:
Four IP addresses would be more than necessary for just the nodes and cluster. This might be required if each node had multiple NICs for different networks or if multiple cluster roles were configured, but not for the minimum requirements.

D. 5:
Five IP addresses is excessive for a basic two-node cluster with only node and cluster roles. This would typically include additional IPs for multiple cluster roles or networks.

Reference:

Microsoft Learn: Failover Clustering hardware requirements and storage options

Microsoft Documentation: Cluster IP address requirements

Explanation:
When migrating DHCP servers, you need to export the configuration from the source server and import it on the destination server. The Export-DhcpServer cmdlet exports DHCP scope configurations, options, and leases from the source server. The Import-DhcpServer cmdlet imports this data to the destination server.

Correct Option:

DHCP1 (Source Server):
Export-DhcpServer: This cmdlet exports the DHCP server configuration, including all scopes, options, and lease information, to a specified file. This captures all settings from DHCP1 for migration to the new server.

DHCP2 (Destination Server):
Import-DhcpServer: This cmdlet imports the DHCP configuration from the exported file into the DHCP2 server. It recreates all scopes and settings on the new server.

Add-DhcpServerInDC: After importing the configuration, this cmdlet authorizes the new DHCP server (DHCP2) in Active Directory, allowing it to start leasing IP addresses in the domain.

Incorrect Option:

Add-DhcpServerv4Scope: Used for creating individual scopes manually, not for bulk migration.

Remove-DhcpServerInDC: Used for deauthorizing a DHCP server, not for migration.

Remove-DhcpServerv4Scope: Used for deleting scopes, not for migration.

Reference:

Microsoft Learn: Export-DhcpServer cmdlet

Microsoft Documentation: Migrate DHCP to Windows Server

Explanation:
Since the Active Directory Recycle Bin is enabled, you can restore the deleted group members without a full system state restore. However, you cannot directly view historical group membership. The solution involves mounting an authoritative AD snapshot to view the group's previous state, then restoring the group from Recycle Bin.

Correct Order:
Restore the system state to an alternate location: You must first restore a backup snapshot of AD to an alternate directory to access historical data without affecting the live domain.

Mount Active Directory to port 51389: Using the ntdsutil command, mount the restored snapshot database and expose it on a specified LDAP port (51389) for querying.

From Active Directory Users and Computers, change the domain controller to localhost:51389: Open ADUC and target the mounted snapshot instance to view AD as it existed at the backup time.

View the membership of the group: With ADUC connected to the snapshot, you can now browse the group and see the complete list of users who were members before the accidental removal.

Incorrect Option:
From the Deleted Objects container, run the Restore task: This restores the group but does not help view the historical membership list first.

Restore the group from AD Recycle Bin: This would restore the group but not the membership list, and membership information is not stored in Recycle Bin.

Performing Recycle Bin restore before viewing membership: You need to identify which users were in the group before deciding whether to restore it.

Reference:
Microsoft Learn: Active Directory Recycle Bin step-by-step

Microsoft Documentation: Ntdsutil directory service management

Explanation:
To run pre-scripts and post-scripts with Cluster-Aware Updating (CAU), you need to configure these scripts to execute automatically during the update process. Run profiles in CAU allow you to specify pre-update and post-update PowerShell scripts that run on each cluster node before and after the update installation.

Correct Option:

B. Run profiles:
CAU uses run profiles to control the update process. You can customize the default run profile to include PreUpdateScript and PostUpdateScript parameters, which specify PowerShell scripts to run before and after updating each node. This is the native, built-in method requiring minimal administrative effort.

Incorrect Option:

A. Scheduled tasks:
While you could create scheduled tasks to run scripts, they would not be integrated with the CAU update workflow. You would need complex logic to coordinate with CAU's update cycle, increasing administrative effort.

C. Azure Functions:
This is a cloud-based serverless compute service. Using Azure Functions for on-premises cluster scripting would introduce unnecessary complexity and external dependencies.

D. Windows Server Update Services (WSUS):
WSUS manages the source of updates but does not provide the capability to run pre-scripts or post-scripts during the CAU update process.

Reference:
Microsoft Learn: Cluster-Aware Updating overview

Microsoft Documentation: Configure Cluster-Aware Updating run profiles

Explanation:
When Server2 shuts down unexpectedly, App1 will fail over to Server1 (the other available node). The goal is to ensure that when Server2 starts again, App1 continues to run on Server2 (moves back). Pausing Server1 prevents it from hosting applications but does not automatically trigger failback. Without configuring failback settings in App1 properties, the application will remain on Server1 after it is resumed.

Correct Option:

B. No:
Pausing Server1 and then starting Server1 does not automatically move App1 back to Server2. Even if Server1 is paused, App1 would fail over to Server1 when Server2 shuts down. When Server2 restarts, App1 would still run on Server1 unless failback is explicitly configured in the application properties to allow automatic failback to the preferred owner (Server2).

Incorrect Option:

A. Yes:
This would be incorrect because pausing a node only prevents new resources from coming online on that node. It does not trigger failback of existing resources. The solution fails to meet the goal as App1 would continue running on Server1 after Server2 starts, not on Server2 as required.

Reference:
Microsoft Learn: Configure failover and failback settings for cluster roles

Microsoft Documentation: Cluster failover and failback behavior

Explanation:
To discover physical servers using Azure Migrate, you need to deploy the Azure Migrate appliance on a physical server. The appliance is deployed using a PowerShell script that configures the server as the appliance. After script execution, you configure and register the appliance with your Azure Migrate project to begin discovery.

Correct Order:

Download and extract the Azure Migrate installer script ZIP file:
The first step is to download the installer script package from the Azure portal and extract its contents to the physical server that will host the appliance.

Run AzureMigrateInstaller.ps1:
Execute the PowerShell script to install and configure the Azure Migrate appliance components on the physical server. This script deploys the necessary services and configurations.

Configure the appliance and register the appliance with Azure Migrate:
After installation, access the appliance configuration manager, complete the prerequisites check, and register the appliance with your Azure Migrate project to start server discovery.

Incorrect Option:

Download and extract the Azure Migrate Appliance VHD file:
This method is for deploying the appliance as a VMware VM, not for physical servers. Physical servers require the PowerShell script deployment method.

Import a virtual machine:
This action is not part of the physical server discovery process. The appliance is configured directly on the physical server, not imported as a VM.

Reference:

Microsoft Learn: Prepare for physical server discovery and assessment

Microsoft Documentation: Deploy Azure Migrate appliance on a physical server

Explanation:
To restrict Domain Admins sign-in to domain controllers and limit their Kerberos TGT lifetime, you need to use Authentication Policies and Authentication Policy Silos, features available with domain functional level 2012 R2 or higher. These provide fine-grained control over Kerberos ticket properties and sign-in restrictions for high-privilege accounts.

Correct Order:

Create an authentication policy silo: First, create a container (silo) that will group accounts with similar authentication requirements. This silo will hold the Domain Admins group and define the authentication boundaries.

Create an authentication policy: Create the policy that defines the specific authentication rules, including the one-hour TGT lifetime and the restriction allowing sign-in only to domain controllers.

Assign the authentication policy silo to user and computer accounts: Finally, assign the Domain Admins group and the domain controller computer accounts to the authentication policy silo, linking the policy requirements to the actual accounts.

Incorrect Option:

Create a Dynamic Access Control claim type: This is for file server authorization and access control, not for Kerberos authentication restrictions.

Create a Dynamic Access Control central access policy: Also related to file server authorization, not authentication policies for Domain Admins.

Configure the Kerberos Policy settings in Default Domain Policy GPO: While this can modify Kerberos settings, it applies to all users domain-wide, not specifically to Domain Admins. Authentication policies provide targeted control.

Reference:

Microsoft Learn: Authentication Policies and Authentication Policy Silos

Microsoft Documentation: Configure protected accounts

Explanation:
When crash dumps are enabled, the memory dump files are stored locally on the virtual machine. To provide a technician access to these dump files without granting access to the virtual machine itself, the dump files must be copied to a storage location that the technician can access separately. Azure Blob Storage containers are commonly used for storing diagnostic and dump files.

Correct Option:

C. an Azure Blob Storage container:
You can configure VM1 to copy crash dumps to an Azure Blob Storage container. The technician can then be granted access (e.g., using SAS tokens or RBAC) to only that specific container to retrieve the dump files, without ever having access to the virtual machine itself.

Incorrect Option:

A. an Azure file share:
While this could store files, Azure file shares are typically used for file sharing scenarios and may not be the default or most appropriate destination for automated crash dump collection from a VM.

B. an Azure Log Analytics workspace:
Log Analytics workspaces store log data for querying and analysis, not raw crash dump binary files. It is not designed for storing and retrieving memory dump files.

D. a managed disk:
Providing access to a managed disk would essentially give the technician access to the VM's storage, which could potentially expose other data and does not meet the requirement to prevent access to the virtual machine.

Reference:
Microsoft Learn: Enable crash dumps for Azure VMs

Microsoft Documentation: Store VM diagnostics data in Azure Storage

Explanation:
When group changes are not appearing on a remote domain controller, the issue is likely replication-related. You need a tool that can specifically check the replication status of Active Directory between domain controllers. The Active Directory Replication Status Tool provides a comprehensive view of replication health across all domain controllers.

Correct Option:

C. Active Directory Replication Status Tool:
This Microsoft tool (also known as ADREPLSTATUS) scans all domain controllers in the forest and reports replication status, including last replication attempts, failures, and pending changes. It helps identify whether replication is occurring and if the group changes have been replicated to other domain controllers.

Incorrect Option:

A. Microsoft Support and Recovery Assistant:
This tool is primarily for troubleshooting Office 365 and Outlook issues, not Active Directory replication problems.

B. File Replication Service (FRS) Status Viewer:
FRS is the legacy replication engine for SYSVOL, replaced by DFSR in modern domains. This tool does not check Active Directory database replication (which uses DFSR for SYSVOL and the KCC for AD replication).

D. Active Directory Sites and Services:
While you can manually check replication connections and force replication using this console, it does not provide a comprehensive status overview across all domain controllers like the Replication Status Tool does.

Reference:

Microsoft Learn: Active Directory Replication Status Tool

Microsoft Documentation: Troubleshoot Active Directory replication

Explanation:
When Server1 shuts down unexpectedly, App1 will fail over to Server2 (the other available node). The goal is to ensure that when Server1 starts again, App1 continues to run on Server2 (does not move back). Changing the preferred owners list by increasing Server2's priority does not prevent failback. Without disabling failback in the Failover tab, App1 will move back to Server1 when it becomes available.

Correct Option:

B. No:
Increasing the priority of Server2 in the Preferred Owners list only affects which node the application prefers to run on initially or after a manual move. It does not control failback behavior. By default, if failback is enabled (as shown in the exhibit with "Allow failback" selected), App1 will automatically move back to its most preferred owner (Server1) when that node becomes available again, regardless of Server2's priority.

Incorrect Option:

A. Yes:
This would be incorrect because preferred owners determine initial placement and manual moves, not automatic failback behavior. The solution fails to meet the goal as App1 would still fail back to Server1 when it starts.

Reference:
Microsoft Learn: Configure failover and failback settings for cluster roles

Microsoft Documentation: Cluster failover and failback behavior