Monitor and maintain Azure resources

• Enable a managed identity on the Azure resource (App Service, VM, Function App, Container Instance, etc.).
• Assign the managed identity the Key Vault Secrets User role on the vault (for read-only secret access) or Key Vault Secrets Officer for read/write.
• The application's code uses the DefaultAzureCredential or ManagedIdentityCredential SDK classes to authenticate automatically — no credentials are stored in code or configuration.

• A vault in Central US can back up VMs in Central US, regardless of which resource group they are in.
• That same vault cannot back up a VM in West US even if both are in the same resource group.
• For Azure Files, the storage account containing the share must be in the same region as the vault.
• Diagnostic settings for the vault (e.g. Azure Backup Reports logs) must also point to a storage account or Log Analytics workspace in the same region as the vault.

1. From the Azure portal, navigate to the Recovery Services vault → Backup Items → the VM → click File Recovery.
2. Select a restore point that contains the files you need to recover.
3. Download and run the script that mounts the backup snapshot as a drive on the local computer.
4. Copy the required files using File Explorer (Windows) or standard copy commands (Linux).

The Microsoft Azure Recovery Services (MARS) Agent backs up files and folders from a VM at the file-system level, rather than taking a full disk snapshot. When a MARS backup taken on VM1 needs to be restored to VM2, the first step is to install the MARS Agent on VM2. The agent handles the authentication to the Recovery Services vault and the restore operation. Without the agent installed on the target machine, there is no mechanism to initiate the restore there. Installing Windows Server Backup (a Windows feature) on VM2 is not the answer — Windows Server Backup handles Windows-native backup, not Azure MARS agent restores.

When determining how long a specific backup will be retained, check the tiers in order from longest to shortest: yearly → monthly → weekly → daily. The first tier that applies to that backup point determines the retention. For example, a backup taken on March 1 (a Sunday) that qualifies as a weekly backup (10 weeks retention) and also as a monthly backup (36 months retention): the monthly retention wins — it will be kept for 36 months, not 10 weeks. Never default to daily retention without first checking whether higher tiers apply to that backup point.

• The first thing to create before configuring App Service backup is an Azure Storage account (and optionally a specific blob container within it).
• Backup configuration is done in the web app's portal blade under Backup, where you specify the storage account, the schedule, and the retention count.
• To exclude specific folders from the backup, create a file named _backup.filter in the web app's wwwroot directory and list the folder paths to exclude. A backup policy, a lock, or a WebJob cannot exclude folders from App Service backup.

Before MAU can be enabled on a Recovery Services vault, a Resource Guard must first be created. The Resource Guard is a standalone Azure resource that acts as the second authority in the two-person model. It is ideally owned by a different administrator or team than the vault owner, enforcing genuine separation of duties. Any critical vault operation (stopping protection, deleting backup data, changing MUA settings) will require explicit approval from the Resource Guard owner if MAU is active.

• ReadOnly — prevents any modifications to the locked resource. Read operations are still permitted. This is the most restrictive lock — it blocks writes, deletes, and configuration changes.
• Delete (CanNotDelete) — prevents deletion only. Read and write (modify) operations are still permitted. This is appropriate when you want to allow configuration changes but prevent accidental deletion.

Locks can be applied at subscription, resource group, and individual resource scope. Management Groups and the Tenant Root Group cannot have locks applied to them — locks stop at the subscription level. A lock on a subscription is inherited by all resource groups and resources within it. When asked "at which scope can a lock be applied?", the valid answers are subscription, resource group, and resource.

• The Append effect fires when a resource is created or updated (PUT/PATCH operation). It adds the specified tag and value to the resource being deployed.
• The tag is added only to that specific resource — not to the resource group it belongs to, not to the subscription, and not to other existing resources that were not touched.
• Existing resources created before the policy was assigned will not automatically receive the new tag. They are marked as non-compliant until remediated or updated.

• Deny — prevents the resource operation from completing if it violates the policy. The resource is not created or updated. For a policy that says "Not allowed resource types: Microsoft.Compute/virtualMachines", an attempt to create a VM in the scope is denied at deployment time.
• Append — adds fields to the resource being created/updated (most commonly used to add tags). Does not block the operation; it only adds the specified property.
• DeployIfNotExists — after a resource is created or updated, if a related resource or configuration is missing, Azure Policy triggers a remediation deployment to add it. Requires a managed identity on the policy assignment.
• Audit — marks non-compliant resources in the compliance report but does not block anything or make any changes.
• Modify — adds, removes, or modifies tags and properties on resources at creation/update time.

An exclusion removes a specific sub-scope from the policy's effect. When a policy is assigned to Subscription1 with an exclusion for ContosoRG1, the policy applies everywhere in Subscription1 except ContosoRG1. Resources in ContosoRG1 are not evaluated by that policy at all. Exclusions must be at or below the assignment scope — you cannot exclude something that is outside the scope the policy is assigned to.

A policy definition can be assigned at any of these levels in order from broadest to narrowest:

• Tenant Root Group
• Management Groups
• Subscriptions
• Resource Groups

Policies cannot be assigned at the individual resource level (e.g., a specific VM or storage account). The assignment scope determines the broadest boundary of effect, and child scopes inherit the policy.

Exclusions can be specified at any scope that is at or below the assignment scope. If a policy is assigned to Subscription1, valid exclusions include: Subscription1 itself (though that would exempt everything), any resource group within Subscription1, or any individual resource within those resource groups — all the way down to individual VMs and storage accounts.

• actions — lists the management-plane operations the role permits. For example, "Microsoft.Network/virtualNetworks/*" permits all operations on VNets; "Microsoft.Network/virtualNetworks/read" permits only reading VNet configuration.
• notActions — explicitly excludes specific operations from the actions list. For example, including "Microsoft.Authorization/*" in notActions prevents the role from managing access permissions, even if it is in a wildcard action.
• dataActions — governs data-plane access (e.g., reading blob data, signing in to VMs). Virtual machine sign-in requires the "Microsoft.Compute/virtualMachines/login/action" data action — it is a dataAction, not an action.
• assignableScopes — defines where the role can be assigned. To restrict a role to resource groups within a specific subscription: "/subscriptions/{subId}/resourceGroups/". To allow it everywhere: "/".

• A user with Reader on management group MG1 inherits Reader on all subscriptions, RGs, and resources within MG1.
• If that same user is also assigned Contributor on Sub1 (within MG1), the user has Contributor rights on Sub1 and Reader on everything else in MG1.
• You cannot use RBAC to remove or override an inherited role — assigning a more restrictive role at a lower scope only adds that role; it does not remove the higher-scoped one.

The Co-Administrator role is a legacy role from the classic Azure management model. It can only be assigned at the subscription scope — not at management groups, resource groups, or individual resources. When asked "to what can you add a user as co-administrator?" the answer is the subscription, not a management group, resource group, or VM.

• Users who need to create initiative definitions (groups of policy definitions) require Resource Policy Contributor at the scope where the initiatives will live — typically the subscription.
• Users who need to assign initiatives to a specific resource group require Resource Policy Contributor scoped to that resource group.
• Resource Policy Contributor does not grant the ability to modify the actual Azure resources that policies govern — it only governs the policy objects themselves.

When configuring a DCR to filter Windows Event Log data before it is collected from VMs, the filter expressions are written in XPath 1.0 syntax. This is a collection-time filter that reduces the volume of data ingested. Once data has been ingested into a Log Analytics workspace, it is queried using KQL (Kusto Query Language). These two query languages serve different purposes at different stages of the data pipeline.

1. Create an Azure Monitor Private Link Scope resource.
2. Add the Log Analytics workspace (and any Application Insights components) to the AMPLS.
3. Create a private endpoint in the VNet and link it to the AMPLS.

Once configured, the VMs' Azure Monitor Agents resolve Azure Monitor endpoints to private IPs via private DNS and all monitoring traffic stays within the VNet. The AMPLS is the umbrella resource that coordinates the private connectivity across multiple Azure Monitor components.

The ITSM Connector must be deployed first before it can be used as an action in an action group. Once deployed and connected to the ITSM platform, an action group can be configured with an ITSM action that specifies which type of work item to create and in which ITSM workspace. Automation runbooks, Function Apps, Logic Apps, and webhooks serve different integration purposes — only ITSMC provides native, bidirectional integration with supported ITSM tools.

Each alert rule monitors exactly one signal (one metric, one activity log operation, or one log query). You cannot combine multiple signals into a single alert rule. The minimum number of alert rules therefore equals the number of distinct signals being monitored.

An action group defines a set of notification actions (email addresses, SMS numbers, webhooks, etc.). The same action group can be reused across multiple alert rules. To minimise the number of action groups, identify which alert rules notify exactly the same set of people — those can share a single action group. Each unique recipient combination requires its own action group.

When an alert processing rule with type "Suppress notifications" is active during a time window:

• The alert rule still fires when the condition is met — the alert appears in the Azure portal.
• The action group notifications (emails, SMS, webhooks) are suppressed — they are not sent.
• After the suppression window ends, notifications resume normally for any new alert fires.

Suppression never prevents the alert from being logged or visible — it only silences the notifications during the window.

If Alert1 is scoped to RG1 and Alert2 is scoped to VM1 (which is inside RG1), and a user performs an administrative operation on VM1:

• Alert2 fires — the operation was directly on VM1, which is in Alert2's scope.
• Alert1 also fires — VM1 is inside RG1, and operations on VM1 are within the scope of RG1-scoped alerts.

• Creating, modifying, or deleting any Azure resource
• Attaching or detaching a managed disk to/from a VM
• Assigning or modifying resource tags (on a resource or a resource group)
• Modifying NSG rules
• Resizing a virtual machine
• Starting or stopping a VM (in some contexts)

• Cost — identifies underutilised VMs (based on low CPU and memory usage over 30 days), idle resources, and recommends right-sizing or shutdown to reduce spending. This is the category relevant for "find underutilised VMs to reduce service tier."
• Reliability — high availability recommendations including availability sets, geo-redundancy, and backup configuration.
• Security — security posture improvements, integrating with Microsoft Defender for Cloud recommendations.
• Operational Excellence — service health, support plans, and operational best practices.
• Performance — throughput and latency improvements for specific resource types.

• A budget can have multiple threshold alerts, each set to a percentage of the budget (e.g., 50%, 80%, 100%, 120%).
• Each threshold can be set to trigger on Actual spend (current charges) or Forecasted spend (projected charges).
• Each threshold triggers an action group. If two thresholds are breached in a billing period, two separate action group notifications are sent.

Azure adds or updates resources defined in the template. Resources already in the resource group that are not in the template are left untouched. Incremental mode is the safe default — redeploying a template in Incremental mode will never accidentally delete resources that were created by other means or at other times. It is additive and non-destructive.

Azure adds or updates resources defined in the template, and deletes any resources in the resource group that are not in the template. Complete mode makes the resource group contain exactly and only what the template defines. It is used when a clean-slate deployment is required — for example, removing legacy resources or ensuring environment parity between environments. The requirement phrase "remove all existing resources before deploying" signals Complete mode.

To view the template used for a specific deployment: navigate to the resource group that received the deployment, open the Deployments blade, find the deployment by name or timestamp, and click it to view its template and input parameters. The template is stored at the resource group level — it is not accessible from individual resource blades (VM1, storage2), from the subscription blade, or from storage account blob containers (unless templates were explicitly exported there).