AZ-802 Exam Results

1. az extension add. 2. az vm repair create. 3. az vm repair run. 4. az vm repair restore.

The Azure VM repair commands are delivered as the vm-repair Azure CLI extension rather than as a built-in part of the core CLI, so az extension add, which installs that extension, is always the required first step before any az vm repair subcommand can be invoked in Cloud Shell. Once the extension is installed, az vm repair create copies VM1 ' s operating system disk and attaches that copy to a new, temporary repair virtual machine so it can be examined and worked on without further risking the original VM. The optional az vm repair run step then executes a diagnostic or fix-up script against the disk that is now attached to the temporary repair VM, allowing an administrator to inspect or repair the file system, boot configuration, or other disk-level issue that is preventing VM1 from starting. Finally, az vm repair restore swaps the repaired disk back onto the original VM1 in place of its damaged disk and cleans up the temporary repair VM and its associated resources, completing the recovery process and allowing VM1 to start normally again with its repaired disk.

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.

A read-only domain controller caches only the passwords (and, depending on the Password Replication Policy, credentials) of a limited set of accounts, but by default it still holds a full read-only copy of every other attribute ' s value for objects in its domain partition, including custom or sensitive attributes such as Employee-Number, unless that attribute has been specifically excluded. The mechanism for excluding a specific attribute from ever being replicated to any RODC is the RODC Filtered Attribute Set (FAS), which is configured by setting a bit in the searchFlags property of that attribute ' s attributeSchema object — and the schema, including every attributeSchema object, lives in the forest-wide schema partition, not in the domain, configuration, or global catalog partition. Marking Employee-Number as confidential/filtered in the schema partition causes it to be excluded from replication to any RODC in the forest going forward, meaning RODC1 would never hold that attribute ' s value at all, so even a full compromise of RODC1 ' s computer account (and therefore its cached directory data) could not expose it. Modifying the domain partition would not affect what an RODC caches, since the RODC FAS is a schema-level, forest-wide setting, not a domain-level one; the configuration partition manages forest-wide configuration data unrelated to attribute filtering; and there is no separate, independently modifiable global catalog partition — global catalog status is a server property, not a directory partition. The schema partition is therefore the one to modify.

1. Create a disk encryption set and generate RSA keys. 2. Grant Vault1 the managed identity permission for the disk encryption set. 3. Create VM1 and associate the disks of the virtual machine with the disk encryption set.

To enable encryption at host on a new Windows Server virtual machine using a customer-managed key rather than a platform-managed one, the first step is to create a disk encryption set that references, or generates, an RSA key stored in Vault1; creating the disk encryption set automatically provisions its own system-assigned managed identity as part of that creation, so no identity needs to be separately enabled on VM1 itself for this purpose. The administrator then grants that disk encryption set ' s own managed identity the necessary key permissions on Vault1, specifically get, wrap key, and unwrap key, which is what actually authorizes the encryption set to use the customer-managed key stored there for encrypting and decrypting data. Only after the encryption set has been created and properly authorized against Vault1 does the administrator create VM1 itself, enable encryption at host on it, and associate its OS and data disks with the already-configured disk encryption set, which is the step that actually applies customer-managed-key encryption to the virtual machine ' s disks and its host cache and temporary storage. Assigning the Virtual Machine Contributor role to a managed identity plays no part in this particular key-management workflow at all.