1. Create the KDS root key in AD DS. 2. Create a group managed service account (gMSA) in Active Directory. 3. Configure the IIS application pool (on WEB1 and WEB2) to run as the gMSA via a specified user account.

The requirement is that every instance of Webapp1 (running on both WEB1 and WEB2) uses the same identity, and that identity ' s password rotates automatically every 30 days, without any administrator manually resetting it. A standalone managed service account (sMSA) is tied to a single computer and cannot be shared across WEB1 and WEB2, so it does not meet the requirement. A group managed service account (gMSA) is designed exactly for this scenario: one AD-managed identity that multiple servers can use simultaneously, with the Key Distribution Service automatically rotating its password (by default every 30 days) without needing manual intervention or downtime. Before any gMSA can be created in the forest, a one-time prerequisite must exist: the KDS root key, which the Key Distribution Service uses to generate and later recompute the gMSA ' s password material. So the correct order is to first create the KDS root key, then create the gMSA object in Active Directory, and finally configure the IIS application pool on each web server to run as that gMSA using the " specified user account " identity option (entered as domain\gMSA$ with no password required, since the password is centrally managed). Creating a system- or user-assigned managed identity in Microsoft Entra ID does not apply here, since Webapp1 runs on IIS on domain-joined VMs, not as an Azure PaaS resource.