Show the 15 questions and explanations
Litware is deploying two Windows Server 2025 virtual machines in Azure as additional domain controllers for its on-premises domain, which it reaches over a site-to-site VPN. Before promotion, the administrator must decide where each virtual machine will hold the AD DS database (NTDS.dit), its log files and SYSVOL. Which storage configuration should the administrator use?
Correct answer: D. A separate persistent data disk with its host caching set to None
The Azure reference architecture for AD DS says to store NTDS.dit, the logs and SYSVOL on a separate persistent data disk, not on the operating system disk, and to set Host Cache Preference on that data disk to None. The ESE database engine behind AD DS manages its own write ordering, and host caching could interfere with database consistency. The same guidance calls for persistent managed OS disks and rules out ephemeral OS disks for domain controllers.
Why the other options are wrong:
- A. An ephemeral OS disk that keeps the files on the host's local storage Learn says not to use ephemeral OS disks for domain controllers; a persistent disk lets a domain controller recover from host maintenance without being promoted again.
- B. A separate persistent data disk with its host caching set to Read-only The separate data disk is right, but Learn calls for None rather than Read-only, because host caching can interfere with how the ESE engine orders its writes.
- C. The OS disk of the virtual machine, with its host caching set to Read/write Learn says not to keep the database, logs or SYSVOL on the same disk as the operating system, and it wants host caching off for the disk that holds them.
Memory hook: Azure DC: NTDS.dit, logs and SYSVOL on their own data disk with host caching None.
Microsoft Learn: Adds extend domain
Inside Contoso's HQ site, an identity provisioning tool writes changes to DC1 and then reads them from other HQ domain controllers. Testers see each change arrive about 15 seconds or more after it was written. The architect wants to view, and possibly shorten, how long DC1 waits before it notifies its same-site partners about changes to the domain partition. Which tool should you use?
Correct answer: C. repadmin /notifyopt against DC1 for the domain directory partition
Learn's article on modifying the intra-site replication interval: after a domain controller writes a change, it waits 15 seconds by default before notifying its first intra-site partner, then pauses 3 seconds between further partners. The delays are the msDS-Replication-Notify-First-DSA-Delay and msDS-Replication-Notify-Subsequent-DSA-Delay attributes on the partition's crossRef object, and repadmin /notifyopt shows them and sets them with /first and /sub.
Why the other options are wrong:
- A. repadmin /kcc on DC1 to rebuild its intrasite connection objects The KCC builds the intrasite connection objects; rebuilding them leaves the notification delays unchanged.
- B. The options attribute of the site link that includes the HQ site The options attribute of a site link turns on change notification across that link between sites; inside a site, changes already trigger notification.
- D. Set-ADReplicationSiteLink with the -ReplicationFrequencyInMinutes parameter ReplicationFrequencyInMinutes is the site link interval, which governs replication between sites, not notification between domain controllers inside HQ.
Memory hook: Inside a site: notify after 15 seconds, then 3 seconds per further partner; repadmin /notifyopt reads and changes it.
Microsoft Learn: Modify default intra site DC replication interval
In contoso.com, a domain in a forest that also contains eu.contoso.com, the global group Auditors contains contoso.com user accounts and the Internal-Audit global group. Auditors is a member of the Compliance-Staff global group and is granted Read on several contoso.com file shares. An administrator tries to change Auditors to universal scope so it can include eu.contoso.com users, and the change is refused. What blocks it?
Correct answer: B. Auditors is a member of Compliance-Staff, which is another global group.
The scope conversion rule in the Active Directory security groups article is that a global group can be converted to universal scope only if it isn't a member of any other global group. Auditors belongs to Compliance-Staff, so the change is refused. Its own members don't block it, because a universal group can contain accounts and global groups from any domain in the same forest.
Why the other options are wrong:
- A. Auditors contains Internal-Audit, which is another global group. Containing a global group isn't a problem, because a universal group can have global groups from any domain in the forest as members. The rule is about what Auditors belongs to, not what it contains.
- C. Auditors is granted permissions in the ACLs of contoso.com file shares. The documented scope conversion conditions all concern group membership, not ACLs, so using the group in permissions doesn't stop the conversion.
- D. Auditors contains user accounts, which must be removed before a scope change. A universal group can contain accounts from any domain in the same forest, so the existing contoso.com users can stay.
Memory hook: Global to universal only works when the group isn't a member of another global group.
Microsoft Learn: Understand security groups
Contoso and Fabrikam have a two-way forest trust. The contoso.com domain local group Proj-Readers contains several Fabrikam users. Last month Fabrikam deleted one of those user accounts. Now, on a contoso.com domain controller, Get-ADGroupMember -Identity Proj-Readers fails with "An unspecified error has occurred." What should the administrator do?
Correct answer: C. Delete the deleted account's foreign security principal from the ForeignSecurityPrincipals container in contoso.com.
A member from another forest is represented in the local domain by a foreign security principal. The Get-ADGroupMember troubleshooting article explains that when the source account is deleted, the foreign security principal isn't updated or removed, and the SID that no longer resolves makes the cmdlet fail on the domain local group. Because the original account no longer exists, you can safely delete that foreign security principal, which also removes it from every group it belongs to.
Why the other options are wrong:
- A. Use Active Directory Users and Computers instead, because Get-ADGroupMember can't list group members from another forest. The snap-in is suggested only as a workaround when a one-way trust is involved. With a two-way trust the failure comes from the orphaned foreign security principal, which the snap-in doesn't remove.
- B. Restore the deleted account from the contoso.com AD Recycle Bin, and then remove it from Proj-Readers. The account lived in fabrikam.com, so the contoso.com Recycle Bin never held it; the object left behind in contoso.com is the foreign security principal.
- D. Wait for the tombstone lifetime to pass so that garbage collection removes the deleted account's entry. The foreign security principal isn't updated or removed when the source account is deleted, so waiting changes nothing; it has to be removed manually.
Memory hook: Deleted in their forest, orphaned in yours: remove the foreign security principal by hand.
Microsoft Learn: Get adgroupmember error remote forest members
Contoso has a two-way forest trust with Fabrikam. After Fabrikam acquired Tailspin Toys, Fabrikam also created a two-way forest trust with the Tailspin Toys forest. Contoso engineers now need to open file shares on servers in the Tailspin Toys forest, but authentication from Contoso accounts to those servers fails. What should you do?
Correct answer: C. Create a forest trust between the Contoso and Tailspin Toys forest root domains
Learn's How trust relationships work for forests in Active Directory states that forest trusts can only be created between two forests and can't be implicitly extended to a third: with trusts between Forest 1 and Forest 2 and between Forest 2 and Forest 3, Forest 1 has no trust with Forest 3, and those two forests need a trust of their own. Create a forest trust between the Contoso and Tailspin Toys root domains, at least one-way with Tailspin Toys trusting Contoso, in Active Directory Domains and Trusts, since netdom trust can't create a forest trust.
Why the other options are wrong:
- A. Run netdom trust with /transitive:yes on the trust between Fabrikam and Tailspin Toys The netdom trust /transitive switch applies only to non-Windows Kerberos realm trusts, and no setting extends a forest trust to a third forest.
- B. Create a shortcut trust between the Contoso and Tailspin Toys forest root domains Shortcut trusts shorten the path between domains inside one forest. Contoso and Tailspin Toys are separate forests with no trust path to shorten.
- D. Enable the Tailspin Toys suffixes on Name Suffix Routing for the Contoso trust with Fabrikam A forest trust collects only its partner forest's namespaces, so the Contoso trust with Fabrikam has no Tailspin Toys suffixes to route; routing doesn't chain through Fabrikam.
Memory hook: Forest trusts don't chain: 1 with 2 plus 2 with 3 gives 1 nothing in 3. Trust 1 and 3 directly.
Microsoft Learn: Concepts forest trust
Adatum links a GPO named Baseline-Security to the adatum.com domain. Administrators of the Research OU enabled Block Inheritance on that OU so that domain-linked GPOs stop reaching their computers. The security team now requires Baseline-Security to apply to every computer in the domain, including Research, while Research keeps blocking the other domain-linked GPOs. What should you do?
Correct answer: A. Set the Baseline-Security link on the domain to Enforced.
The Group Policy processing article calls Enforced a link property and Block Inheritance a container property, and it says the enforced link takes precedence. An enforced link on the domain therefore still reaches computers in the Research OU, while the OU's Block Inheritance keeps stopping every domain-linked GPO that isn't enforced. Nothing about the Research OU has to change, which is what the requirement asks for.
Why the other options are wrong:
- B. Link Baseline-Security to the site that holds the Research computers. Block Inheritance on an OU stops GPOs linked to sites as well as to the domain, so a site link is blocked the same way.
- C. Clear Block Inheritance on the Research OU and keep the existing links. Clearing the block delivers Baseline-Security, but every other domain-linked GPO would reach Research again, which breaks the requirement.
- D. Move the Baseline-Security link to link order 1 on the domain. Link order only ranks GPOs linked to the same container, where link order 1 wins. It doesn't carry a domain-linked GPO past Block Inheritance on a child OU.
Memory hook: Enforced lives on the link, Block Inheritance on the container, and the link wins.
Microsoft Learn: Group policy processing
Someone stole RNO-RODC1 from Woodgrove Bank's Reno branch. Its Allowed list held the Reno-Staff group. Last month the administrator prepopulated passwords for three new hires who haven't signed in yet, and two employees who later moved to Seattle were removed from Reno-Staff after their passwords had been cached. Which accounts must have their passwords reset?
Correct answer: C. Every user and computer account on the Revealed list of RNO-RODC1, the accounts whose passwords it stores.
Learn's Password Replication Policy guidance says that if an RODC is stolen you must reset the passwords of all users and computers whose passwords are cached on it, and that nothing erases a cached password; only a reset makes the stolen copy useless. The Revealed list records exactly those accounts, including prepopulated new hires who never signed in and staff removed from the Allowed group after caching. Get-ADDomainControllerPasswordReplicationPolicyUsage -RevealedAccounts lists them.
Why the other options are wrong:
- A. Every account on the Authenticated to list of RNO-RODC1, the accounts that the RODC has authenticated so far. This list records accounts the RODC authenticated, cached or not, and it misses the prepopulated new hires, who never authenticated there.
- B. Every current member of Reno-Staff, the group that sits on the Allowed list of RNO-RODC1. Membership shows who may be cached, not who is; the two employees removed from Reno-Staff still have cached passwords, because removal erases nothing.
- D. The domain krbtgt account, reset twice so that tickets issued by RNO-RODC1 stop working. The domain krbtgt account is in the Denied RODC Password Replication Group by default and never caches on an RODC, which has its own krbtgt account; resetting it protects no cached user or computer password.
Memory hook: Stolen RODC: reset everything on its Revealed list; allowed isn't cached, and removal erases nothing.
Microsoft Learn: Cc730883(v=ws 10)
Woodgrove Bank created a site named Branch7 and its subnet object, but the branch domain controller won't ship for a month. Branch7 belongs to two site links: Branch7-HQ with cost 100 and Branch7-East with cost 300. HQ and East both host writable domain controllers for the domain, and no DC Locator settings have been changed. Until the branch domain controller arrives, how will Branch7 clients find a domain controller?
Correct answer: D. A domain controller in HQ registers site-specific SRV records for Branch7, because HQ has the lowest-cost connection to it
Learn's Site functions page describes client affinity: a domain controller works out the client's site from its IP address, and the client then queries site-specific SRV records. If no domain controller is located in the client's site, a domain controller with the lowest-cost connection relative to the other connected sites registers site-specific SRV records in that site, so every site has a preferred domain controller. The subnet places clients in Branch7, and HQ, at cost 100 against East's 300, covers Branch7.
Why the other options are wrong:
- A. Domain controllers in both HQ and East register site-specific SRV records for Branch7, because each shares a site link with it Coverage goes to the site with the lowest-cost connection, not to every site that shares a link; East at cost 300 loses to HQ at cost 100.
- B. Branch7 clients get no site name, so they query only the domain-wide SRV records until a domain controller is installed The subnet object maps the clients to Branch7, so a domain controller returns Branch7 as their site, and Branch7's site-specific records exist through coverage.
- C. Branch7 clients are placed in Default-First-Site-Name and use its domain controllers until a domain controller is installed Clients belong to the site whose subnet object contains their address, here Branch7; Default-First-Site-Name plays no part.
Memory hook: A site with no domain controller is covered by domain controllers from the lowest-cost connected site (automatic site coverage).
Microsoft Learn: Site functions
Contoso runs a gMSA named WebFarm whose PrincipalsAllowedToRetrieveManagedPassword lists the WebHosts group. An administrator adds the computer account of a new server, WEB04, to WebHosts and confirms the change has replicated to every domain controller. On WEB04, Test-ADServiceAccount -Identity WebFarm returns False. The three existing servers return True and must keep working. What should the administrator do next?
Correct answer: A. Restart WEB04 so that it gets a Kerberos ticket that reflects its new group membership.
A Kerberos ticket lists the groups a computer belonged to when the ticket was issued, so a host added to an authorized group can't retrieve the gMSA password until it gets a new ticket. The gMSA troubleshooting guidance for domain-joined hosts says that if the host belongs to an authorized group but Test-ADServiceAccount still fails, restart it to obtain a ticket that reflects its current group memberships. Purging the computer's tickets with klist purge -li 0x3e7 has the same effect.
Why the other options are wrong:
- B. Run Install-ADServiceAccount -Identity WebFarm on a domain controller instead of on WEB04. Install-ADServiceAccount installs the account on the computer where it runs, so it belongs on each host that runs the service, not on a domain controller.
- C. Run Set-ADServiceAccount -Identity WebFarm -PrincipalsAllowedToRetrieveManagedPassword WEB04$. PrincipalsAllowedToRetrieveManagedPassword is a complete list of authorized principals, so setting it to WEB04$ alone replaces WebHosts and cuts off the three servers that must keep working.
- D. Run Reset-ADServiceAccountPassword -Identity WebFarm on WEB04 to fetch a new password. Reset-ADServiceAccountPassword is for standalone MSAs only; its reference states that reset isn't supported for group managed service accounts.
Memory hook: New host in the gMSA group but Test-ADServiceAccount says False: give it a fresh Kerberos ticket.
Microsoft Learn: Gmsa troubleshooting
In Fabrikam's single-domain forest, AUS-RODC1 is the Austin branch's RODC, global catalog and DNS server. Its Allowed list holds the Austin-Staff group, which contains every Austin user and workstation account, and those passwords were prepopulated. During a WAN outage, Austin users signed in but couldn't open shares on the branch file server AUS-FS1, whose computer account isn't on the Allowed list. What should the administrator do?
Correct answer: C. Add the AUS-FS1 computer account to the Austin-Staff group, then prepopulate its password on AUS-RODC1.
Learn's Password Replication Policy guidance says the policy must include the appropriate user, computer and service accounts for an RODC to satisfy authentication and service ticket requests locally; when only users are allowed, the RODC relies on a writable domain controller for service tickets, which leads to an outage while the WAN is down. AUS-FS1's password isn't cached, so the RODC can't serve requests for it offline until its account is allowed and its password cached.
Why the other options are wrong:
- A. Prepopulate the Austin-Staff passwords again by running Sync-ADObject with -PasswordOnly and AUS-RODC1 as the destination. The users' passwords are already cached, so prepopulating them again changes nothing; the missing secret belongs to AUS-FS1.
- B. Enable universal group membership caching for the Austin site so that AUS-RODC1 can complete requests while offline. Universal group membership caching lets a site without a global catalog complete sign-ins; AUS-RODC1 is already a global catalog, and users did sign in.
- D. Add the Austin users to the Allowed RODC Password Replication Group so that every RODC can authenticate them. The users are already allowed through Austin-Staff, so this caches nothing for AUS-FS1, and the built-in group widens caching to every RODC in the domain.
Memory hook: An offline branch needs every secret cached: users, workstations and the servers they use.
Microsoft Learn: Cc730883(v=ws 10)
Contoso's single-domain forest has four Windows Server 2025 domain controllers. DC1 and DC2 were upgraded in place from Windows Server 2022; DC3 and DC4 were newly installed and promoted over the network. Both functional levels are Windows Server 2016. Replication is healthy, and the backup software passed a lab test with 32k-page databases. Before enabling the Database 32k pages optional feature, what else must the administrator do?
Correct answer: A. Replace DC1 and DC2 with newly promoted Windows Server 2025 domain controllers, then raise the domain and forest functional levels to Windows Server 2025.
The Database 32k pages article lists two requirements this forest doesn't meet yet: every domain controller must run Windows Server 2025 with a 32k page capable database, and both the domain and forest functional levels must be Windows Server 2025. Domain controllers upgraded in place keep their 8k page database, while one promoted over the network gets a 32k page capable database, so DC1 and DC2 must be replaced by fresh promotions, and both levels raised, before the feature can be enabled. Enabling the feature can't be undone.
Why the other options are wrong:
- B. Back up DC1 and DC2 with Windows Server Backup and restore them from those backups so that their databases are rewritten in the 32k page format. A backup preserves the page size of the database it holds, so restoring DC1 and DC2 from their own backups brings back 8k page databases.
- C. Raise only the forest functional level to Windows Server 2025, because enabling 32k pages is a forest-wide operation that ignores the domain level. Learn requires both the domain and the forest functional level at Windows Server 2025, and a domain level can't sit below the forest level in any case.
- D. Raise the domain and forest functional levels to Windows Server 2025; DC1 and DC2 convert their databases to the 32k page format when the levels change. Raising the levels converts nothing: Learn says in-place upgraded domain controllers continue with their 8k page database, so the requirement that every domain controller be 32k page capable still fails.
Memory hook: 32k pages: every DC promoted fresh on Windows Server 2025, both levels at 2025, and no way back.
Microsoft Learn: 32k pages optional feature
Adatum's single-domain forest has two domain controllers on Windows Server 2012 R2 and two on Windows Server 2019. Both functional levels are Windows Server 2012 R2, and SYSVOL already replicates with DFS Replication. The administrator must add Windows Server 2025 domain controllers, keep the 2019 ones and retire the 2012 R2 ones. What should the administrator do before promoting the first Windows Server 2025 domain controller?
Correct answer: A. Demote the two Windows Server 2012 R2 domain controllers, then raise the domain and forest functional levels to Windows Server 2016.
Learn's functional level matrix supports a Windows Server 2025 domain controller at the Windows Server 2016 and 2025 levels but not at the Windows Server 2012 R2 level, and the 2016 level supports domain controllers from Windows Server 2016 through 2025. The levels can't move to 2016 while 2012 R2 domain controllers remain, so demote those first and then raise both levels. The 2016 level's other requirement, DFS Replication for SYSVOL, is already met.
Why the other options are wrong:
- B. Run adprep /forestprep and adprep /domainprep from the Windows Server 2025 media, then promote the Windows Server 2025 servers. Adprep prepares the schema and the domain and runs automatically during promotion when it's needed; it doesn't change the functional level, which is what rules out a Windows Server 2025 domain controller.
- C. Raise the domain and forest functional levels to Windows Server 2025 first, then promote the new Windows Server 2025 servers into the domain. The Windows Server 2025 functional level accepts only Windows Server 2025 domain controllers, so it can't be raised while the 2012 R2 and 2019 domain controllers exist, and 2016 is already enough.
- D. Promote the Windows Server 2025 servers with -SkipPreChecks, then demote the Windows Server 2012 R2 domain controllers afterward. Skipping the additional prerequisite checks doesn't make the combination supported; the interoperability matrix marks Windows Server 2025 domain controllers as not supported at the 2012 R2 level.
Memory hook: Windows Server 2025 DCs need the 2016 functional level or higher; the 2025 level admits only 2025 DCs.
Microsoft Learn: Active directory functional levels
Fabrikam's single-domain forest has writable hub domain controllers that run Windows Server 2025 and are global catalog and DNS servers. A new Windows Server 2025 member server in a branch office must become an additional writable domain controller, but the branch reaches the hub over a slow, busy WAN link and the directory database is large. How should the administrator promote the server to keep replication over the link as low as possible?
Correct answer: B. On a hub domain controller, use ntdsutil's ifm menu to create media that includes SYSVOL, copy it to the branch, and promote with -InstallationMediaPath.
Install from media seeds the new domain controller's database from local media, so only the objects changed since the media was created replicate over the network; Learn's IFM guidance presents this as the way to avoid replicating the entire directory over a WAN link. Build the media with ntdsutil's ifm menu or Windows Server Backup on a domain controller running the same operating system version, because IFM doesn't work across versions and can't create a domain's first domain controller.
Why the other options are wrong:
- A. Promote the branch server with Install-ADDSDomainController and set -ReplicationSourceDC to the hub domain controller that has the fewest replication partners. A named replication source only decides which partner supplies the data; the whole directory still replicates across the WAN link during promotion.
- C. Promote the branch server with Install-ADDSDomainController -CriticalReplicationOnly so that only the critical part of the directory crosses the WAN link. This switch only postpones the noncritical, lengthy part of replication until after the restart, so the full directory still crosses the link.
- D. Copy NTDS.dit and the SYSVOL folder from a hub domain controller to the branch server, then promote with -DatabasePath and -SysvolPath set to the copies. These parameters only set where the new database and SYSVOL are created; a copy of a live NTDS.dit isn't installation media, which ntdsutil or Windows Server Backup must produce.
Memory hook: Slow link and a big database: IFM media from ntdsutil on a same-version DC, then -InstallationMediaPath.
Microsoft Learn: Cc816722(v=ws 10)
Adatum's forest has three domains: adatum.com, na.adatum.com and eu.adatum.com. Six account administrators, four with accounts in na.adatum.com and two in eu.adatum.com, must manage user objects in the Sales OU of all three domains. You want one group that contains all six administrators and is granted the delegated permissions in every domain. Which group should you create?
Correct answer: A. A universal security group
The guidance on delegating administration of account OUs says that when the data administrators who receive control come from multiple domains, you must use a universal group, because universal groups can contain users from different domains and can be used to delegate control in multiple domains. A universal security group holds accounts from any domain in the forest and can be granted permissions in any domain of the forest, which covers all three Sales OUs.
Why the other options are wrong:
- B. A domain local security group in adatum.com A domain local group can hold accounts from any domain, but it can be granted permissions only within its own domain, so it can't carry the delegation in na.adatum.com or eu.adatum.com.
- C. A global security group in na.adatum.com A global group can contain only accounts from its own domain, so a na.adatum.com global group can't hold the two eu.adatum.com administrators.
- D. A universal distribution group The scope is right but the type isn't: distribution groups aren't security enabled and can't be included in DACLs, so they can't receive delegated permissions.
Memory hook: Administrators from several domains managing several domains: one universal security group.
Microsoft Learn: Delegating administration of account ous and resource ous
Tailspin Toys has a forest with two domains. A branch office with 60 users has one writable domain controller that isn't a global catalog, and a slow, busy WAN link to the hub site, which hosts global catalog servers. The branch runs no applications that need a global catalog. Users there report slow sign-ins, and management won't let the branch domain controller replicate a partial copy of every domain in the forest. What should you configure?
Correct answer: D. Enable universal group membership caching for the branch site.
In a multi-domain forest, sign-ins need universal group membership from a global catalog. The global catalog placement guidance says that for a remote site with a limited WAN link, fewer than 100 users and no applications that require a global catalog, you can enable universal group membership caching in that site. The branch domain controller then caches users' universal group memberships, so sign-ins don't always cross the WAN to a hub global catalog.
Why the other options are wrong:
- A. Enable universal group membership caching for the hub site. Caching belongs on the site whose domain controllers lack a global catalog. The hub already hosts global catalog servers, so caching there does nothing for branch sign-ins.
- B. Add the global catalog role to the branch domain controller. A global catalog stores a partial, read-only replica of every other domain in the forest, which is exactly the replication that management ruled out.
- C. Make the branch domain controller a preferred bridgehead server. Bridgehead servers carry replication between sites; they don't supply universal group membership at sign-in, and Microsoft recommends not defining preferred bridgeheads.
Memory hook: Small branch, slow link, no global catalog: cache universal group membership in the branch site.
Microsoft Learn: Planning global catalog server placement