Exactprep AZ-802 Questions

User1: 9. Admin1: 8.

Fine-grained password policies delivered through Password Settings Objects (PSOs) take precedence over the domain-wide Default Domain Policy for any user they apply to. When more than one PSO would apply to the same user only through different group memberships (as opposed to one being linked directly to the user), the PSO with the lowest numeric precedence value wins. User1 is a member of both Group2 (targeted directly by PSO1, precedence 10, minimum password length 9) and Group4 (targeted directly by PSO2, precedence 20, minimum password length 11); since PSO1 ' s precedence value of 10 is lower than PSO2 ' s 20, PSO1 governs, giving User1 an effective minimum password length of 9. Admin1 is a member only of Domain Admins, which is not targeted by either PSO, so no fine-grained password policy applies. Admin1 is also in OU1, which has GPO1 linked to it with a minimum password length of 10, but Account Policy settings such as password policy configured in an OU-linked GPO never affect the effective password policy of domain user accounts -- only a GPO linked at the domain root can supply a fallback domain-wide default, and PSOs otherwise take precedence over that default. With no applicable PSO, Admin1 ' s effective policy falls back to the Default Domain Policy, whose minimum password length in this environment is 8.

Promoting a new domain controller that runs a newer operating system version than any existing domain controller in the forest -- here, DC4 running Windows Server 2022 into a forest whose functional level is still Windows Server 2012 R2 -- requires the Active Directory schema to first be extended to support that OS version ' s schema additions (the adprep /forestprep and /domainprep operations, which modern promotion tools such as Install-ADDSDomainController run automatically when needed). Extending the schema requires connectivity to the domain controller holding the Schema Master FSMO role, since schema changes can only be made by contacting that specific role holder; if the Schema Master is offline, the schema extension step fails and the promotion cannot proceed. According to the domain controllers table, DC1 holds both the RID master and the schema master roles. DC2 holds the PDC emulator and infrastructure master roles, and DC3 holds the domain naming master role -- neither of those role sets is relevant to a schema extension. Therefore, DC1, as the Schema Master, must be online for DC4 ' s promotion (and its associated schema extension) to succeed.

Storage Migration Service is designed to migrate a file share such as Share1 to a new server (Server2) while carrying over both the share-level and NTFS folder/file permissions, and it can also perform a cutover of the source server ' s name and IP address if a fully transparent migration is later required. This directly satisfies the requirement to migrate Share1 to Server2 including all the share and folder permissions. File Server Resource Manager (FSRM) only provides quota, file-screening, and storage-reporting capabilities and has no mechanism to migrate data, shares, or permissions between servers. Server Manager is a general-purpose administration console with no dedicated share-migration workflow -- it can be used to create shares manually but cannot transfer existing permissions programmatically. Storage Replica performs block-level volume replication intended for disaster recovery and stretch-cluster scenarios rather than a one-time, permission-preserving share migration to a specific destination server. Therefore, Storage Migration Service is the correct tool to migrate Share1 to Server2 while preserving its share and folder permissions.

1. Stop VM1. 2. Resize the operating system disk. 3. Start VM1. 4. Resize volume C.

Resizing an existing Azure managed disk ' s provisioned capacity, unlike attaching or detaching an additional data disk, requires the virtual machine using that disk to be stopped (deallocated) first; Azure does not permit a disk resize operation against a disk that is currently attached to a running VM. The first step is therefore to stop VM1. With the VM deallocated, the operating system disk can be resized (increased from 128 GB up to 250 GB) through the Azure portal, CLI, or PowerShell. Once the resize completes, VM1 must be started again so that Windows can see and use the newly enlarged disk. Growing the underlying managed disk only makes additional unallocated space available at the disk level; it does not automatically grow the NTFS volume sitting on that disk, so the final step is to resize volume C from within the guest operating system (using Disk Management ' s Extend Volume wizard or diskpart ' s extend command) to actually claim that unallocated space into the C: volume. Resizing VM1 (changing its compute size/SKU) and redeploying VM1 (moving it to different underlying hardware) are unrelated operations that do not participate in a disk-capacity-increase workflow at all. The correct order is: stop VM1, resize the operating system disk, start VM1, then resize volume C.