Drag and Drop Matching Questions

VMSS: Provides auto-scaling of identical VMs

VMSS provides automatic scaling of an identical VM fleet, allowing the instance count to scale out/in based on CPU, memory, or custom metrics, and integrates with Azure Load Balancer to distribute traffic; each VM keeps identical configuration, making it the only option matching the 'auto-scaling of identical VMs' description.

Availability Zone: Offers physical separation within a region, with independent power and networking

An Availability Zone is a set of physically separate datacenters within an Azure region, each with independent power, cooling, and networking; placing VMs in different zones protects against a single datacenter failure, and this description directly matches Availability Zones, not Availability Sets.

Dedicated Host: Single-tenant physical servers dedicated to your workloads

A Dedicated Host is a single-tenant physical server reserved for your workloads, giving you full control over maintenance and the ability to use your own Windows/Linux licenses; because other customers' VMs cannot share the same host, it satisfies compliance and isolation requirements, exactly as the description states.

Deploy a new virtual machine: az vm create

The `az vm create` command is the correct Azure CLI command for deploying a new virtual machine. It creates the VM resource in a specified resource group and configures parameters such as `--name`, `--image`, `--size`, and `--admin-username`. Unlike commands that modify an existing VM, `create` provisions brand-new compute, storage, and networking resources as defined by the arguments.

Change the size of a virtual machine: az vm resize

`az vm resize` changes the virtual machine size of an existing VM by updating its hardware profile (e.g., from Standard_D2s_v3 to Standard_D4s_v3). The command may require the VM to be deallocated first if the target size is unsupported on the current host, and it does not create a new VM. This operation is distinct from `create`, which provisions resources, and from `start`/`stop`, which only control power state.

Start a virtual machine: az vm start

`az vm start` is the correct command to start a previously stopped (deallocated) virtual machine, transitioning it to a running state within its availability set. The command allocates a new host for the VM and attaches its managed disks, which is why it can take several minutes. It is not used to reboot a running VM; that is the purpose of `az vm restart`.

LRS: Locally redundant storage replicates data three times within a single datacenter in the primary region.

LRS correctly defines the base redundancy tier: data is written three times within a single datacenter in the primary region. This protects against server and drive failures, but offers no resilience against a full datacenter outage. LRS is the lowest-cost option and is acceptable when you can accept a single-datacenter point-of-failure or when data can be reconstructed from source.

ZRS: Zone-redundant storage replicates data synchronously across three Azure availability zones in the primary region.

ZRS accurately describes synchronous replication across three Azure availability zones within the primary region, ensuring that data survives entire zone outages. Unlike LRS, ZRS provides zone-level fault tolerance while keeping a single-region footprint, which is ideal for high-availability applications that do not need geo-redundancy. The synchronous write path guarantees no data loss when a zone fails.

GRS: Geo-redundant storage replicates data to a secondary region asynchronously and provides six copies across two regions.

GRS is correctly defined by asynchronous replication to a secondary region, resulting in six copies total: three in the primary region and three in the secondary region. The asynchronous nature introduces a possible RPO of up to 15 minutes, so data written just before a regional disaster could be lost. GRS improves durability against region-wide outages but does not offer read access to the secondary copy unless RA-GRS is enabled.

RA-GRS: Read-access geo-redundant storage provides read access to the secondary region data.

RA-GRS extends GRS by allowing read access to the secondary-region replica, which is a key differentiator for disaster-recovery and read-scaling scenarios. With RA-GRS, you can always read from the secondary endpoint even when the primary is healthy, and you can continue reading if the primary becomes unavailable. This is essential for applications requiring business continuity without write access in the secondary region.

Enable secure access from a specific VNet: Use service endpoints

Service endpoints are the correct way to enable secure access from a specific VNet because they extend your VNet's private address space to the storage account, creating a direct, optimized route over the Azure backbone. When you enable a service endpoint for Microsoft.Storage on a subnet and add that subnet to the storage account's network rules, traffic from that subnet to the storage account is no longer sent through a public IP, though it still uses the storage account's public endpoint. This provides identity-based and route-based security without exposing the storage account to the entire internet, and it does not require a private IP from your VNet to be assigned to the storage account.

Restrict access to only trusted Microsoft services: Enable trusted services exception

The trusted services exception is the correct mechanism when you need to allow a limited set of Microsoft-managed Azure services to bypass the storage account's default denial of public network access. This exception is controlled by the 'Allow trusted Microsoft services to access this storage account' setting, which permits services like Azure Backup, Azure Site Recovery, Azure Logic Apps, and Azure Data Factory to authenticate using their own managed identities or Azure AD, rather than through shared keys. It is not a blanket grant of access to all Azure services, and it still requires the specific service's request to originate from a Microsoft-owned service context, making it a targeted exception for scenarios like backup vaults or diagnostic logging.

Block all public network access: Disable public network access

Disabling public network access is the definitive way to block all traffic from public endpoints because it tells Azure Storage to reject any connection attempt that does not originate from a private endpoint on your virtual network. When this setting is set to 'Disabled', the storage account no longer accepts requests over its public endpoint (the global or regional DNS name), so internet clients, even those with valid SAS tokens or account keys, cannot reach it. This is a binary, account-wide control and is the strongest option for meeting strict compliance or data isolation requirements, since it eliminates the entire public attack surface rather than merely filtering which source IPs are allowed.

NSG: A distributed firewall that filters traffic based on rules.

An NSG is a distributed firewall implemented by Azure's host networking layer, not a physical or virtual appliance. It filters inbound and outbound traffic based on priority-ordered security rules, each specifying source/destination, protocol, and port ranges. NSGs can be associated with a subnet, a NIC, or both, and are stateful, meaning that allowing inbound traffic automatically permits the corresponding outbound return traffic. This makes it the primary control for permitting or denying inbound connections to a VM.

UDR: Overrides the default system route and can redirect traffic to a network virtual appliance.

A User Defined Route (UDR) is an explicit route entry in a route table that takes precedence over Azure's system routes for matching traffic. When attached to a subnet, UDRs can redirect outbound or inbound traffic that transits the subnet to a network virtual appliance (NVA) by setting the next hop type to 'Virtual Appliance' and specifying its private IP address. This is commonly used to force traffic through firewalls or IDS/IPS for inspection. However, a UDR does not open or block ports; it only changes the path traffic takes, so an NSG is still needed to actually filter that traffic.

ASG: Groups VMs logically to simplify NSG rule management.

An Application Security Group (ASG) is an Azure resource that groups VM network interfaces logically based on workload, such as 'web servers' or 'database servers', rather than by subnet or IP address. In NSG rules, you can reference an ASG as the source or destination, and the rule automatically applies to any VM NIC that is added to or removed from the group. This eliminates the need to update individual NSG rules when IP addresses change and reduces rule management overhead. Note that ASGs are not a firewall or security service; they are purely an organization and targeting construct for NSG rules.

Interactive logins: User delegation SAS

A user delegation SAS is signed with Azure AD credentials rather than a storage account key, meaning it can be issued to an individual user with narrowly scoped permissions and a configurable expiration. This makes it ideal for interactive logins where a human needs temporary, least-privilege access to specific blobs or containers. It requires the calling principal to have the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey permission.

Automated backups: System-assigned managed identity

Automated backups need to write data continuously without human intervention or the burden of maintaining credentials, and a system-assigned managed identity gives an Azure resource a first-class identity in Azure AD with no secrets to store or rotate. When a backup service or workload uses its own managed identity, it can authenticate to Azure Storage via Azure AD and be granted exactly the RBAC roles needed for backup operations. This is secure and fully automated, unlike key-based or SAS-based approaches.

Cross-tenant access: Service principal with certificate

Cross-tenant access requires an identity that exists outside the context of a single resource's tenant, and a service principal with a certificate provides that independent, strongly authenticated identity. The service principal is registered in the home tenant and can be granted RBAC permissions in another tenant, while the certificate proves the principal's identity without exposing secrets. This is a standard pattern for multi-tenant applications and federated automation scenarios.

Move blobs not modified for 30 days: Transition to cool tier

The cool tier is optimized for data that has not been accessed for 30 days, offering lower storage costs than hot tier while retaining near-instant retrieval. A lifecycle management rule with a "transition to cool" action after 30 days aligns with Azure's recommended tiering pattern. It is a common practice to move infrequently accessed blobs to cool to reduce storage expenses without sacrificing availability.

Move blobs not modified for 90 days: Transition to archive tier

Archive is the lowest-cost tier designed for long-term retention where retrieval latency of up to 15 minutes is acceptable. Since 90 days without modification indicates cold data, transitioning to archive at that point minimizes cost. The rule should specify "transition to archive" after 90 days from last modification, which is a valid and cost-effective policy.

Delete blobs after 365 days: Delete blob

The appropriate action to remove a blob after one year is the "delete blob" action in a lifecycle management policy. Deleting blobs that have no business need beyond a year saves all associated storage and access costs. It is not a tier transition but a direct deletion, ensuring compliance with data retention policies.

az vm create: Creates a new virtual machine.

The 'az vm create' command is the provisioning entry point: it deploys a new virtual machine by combining a resource group, VM name, image, size, and optional networking/storage parameters. If networking resources are not specified, Azure CLI creates default virtual network, subnet, public IP, and network security group. This command creates the underlying compute, storage, and network resources, unlike lifecycle-management commands that operate on an existing VM.

az vm start: Starts a stopped virtual machine.

The 'az vm start' command transitions a VM in the 'Stopped' (allocated) power state back to 'Running'. It sends a start operation to the Azure fabric, which powers on the VM guest OS from a shutdown state while preserving the existing compute allocation. If the VM was in the 'Deallocated' state, this command also re-allocates compute capacity before boot, but its primary documented purpose is to start a stopped VM.

az vm stop: Stops a running virtual machine.

The 'az vm stop' command shuts down a running VM but does not release the underlying compute resources, leaving the VM in the 'Stopped' (allocated) power state. The hardware lease, public IP address, and compute billing continue, so this is not a cost-saving operation. Use this command for scenarios like applying in-guest maintenance that requires a shutdown while retaining the same host allocation.

az vm deallocate: Deallocates a virtual machine (releases compute resources).

The 'az vm deallocate' command stops the VM and releases the compute resources assigned to it, changing the power state to 'Deallocated'. This frees the VM's physical hardware, which stops compute billing, but preserves the OS disk, data disks, and static IP configuration. The VM can later be started again, at which point Azure allocates new compute resources, potentially on a different host.

Frequent read and write operations: Hot tier

Hot tier is the default and only tier optimized for datasets with frequent read and write operations. It offers the lowest access latency and no minimum storage duration, but has the highest storage cost per gigabyte among the three tiers. Choosing Hot for active workloads minimizes operational cost because access charges are negligible and throughput is maximized.

Infrequent access with 30-day minimum storage duration: Cool tier

Cool tier is designed for data that is accessed infrequently but must be retained for at least 30 days. It offers lower storage cost than Hot but higher access costs and slightly higher latency, making it ideal for short-term backups or older documents that still need occasional retrieval. The 30-day minimum applies to avoid early deletion penalties, so it is a direct fit for this pattern.

Rarely accessed data with 180-day minimum storage duration: Archive tier

Archive tier is the lowest-cost storage tier intended for rarely accessed data that can tolerate retrieval latency of up to 15 hours. It requires a minimum storage duration of 180 days; deleting or moving data before that incurs an early deletion charge. This tier suits long-term compliance archives, backup tapes, or legal records rarely retrieved.

Retrieving data from Archive tier: Rehydrate the blob

Blobs in the Archive tier are in an offline state and cannot be read directly. To access data, you must first rehydrate the blob by changing its tier to Hot or Cool using the Set Blob Tier operation or by copying the blob to a new tier, with rehydration priority from High to Standard. The rehydration process can take from minutes to hours, so plan retrieval accordingly.

General-purpose v2: Provides support for blobs, files, queues, tables, and VM disks. Suitable for most general-purpose workloads.

General-purpose v2 (GPv2) is the default, multi-protocol Azure Storage account type, designed to support blobs (including page blobs for VM disks), files, queues, and tables within a single account. It provides standard-tier performance with blob access tiers like hot, cool, and archive, making it suitable for most general-purpose workloads. Unlike premium account types, GPv2 does not offer SSD-backed low-latency performance by itself; it relies on standard storage media and is the recommended option when you need a comprehensive storage solution.

BlobStorage: Legacy blob-only account type with performance equivalent to GPv2. Suitable for blob-only workloads.

BlobStorage is a legacy account type that is restricted to blob data only; it cannot host files, queues, or tables, so it is only appropriate for pure blob workloads. It runs on the same standard-tier backend as General-purpose v2, giving it equivalent performance, but it was superseded by GPv2, which provides the same blob capabilities plus additional services and a unified management model. Although still supported, choosing BlobStorage is generally less flexible than GPv2 and is most useful when you know you will never need non-blob services.

BlockBlobStorage: Premium performance for block blob and append blob data, with low latency and high transaction rates.

BlockBlobStorage is a premium-performance account type that uses SSD-backed hardware to deliver consistently low latency and high transaction rates, specifically for block blobs and append blobs. It does not support page blobs, files, queues, or tables, so it is not suitable for VM disks or mixed service workloads. This account type is ideal for high-throughput scenarios like telemetry ingestion, analytics, and IoT data streams where write performance and quick access are critical.

FileStorage: Premium file shares backed by SSDs, providing high performance for enterprise file shares.

FileStorage is a premium account type dedicated exclusively to Azure file shares, with SSD-backed storage that provides high IOPS and throughput for enterprise workloads such as SMB and NFS file shares. Unlike General-purpose v2, FileStorage cannot hold blobs, queues, tables, or VM disks, and it carries a higher cost due to its premium tier. It is the correct choice only when you need high-performance, low-latency file shares for lift-and-shift and enterprise file-serving scenarios.

Restore VM: Creates a new VM

Restore VM is the default restore action in Azure Backup for IaaS VMs. It creates a brand-new virtual machine from the selected recovery point, letting you choose a target resource group, virtual network, and storage settings while leaving the original VM untouched. This is the go-to method when the original VM is corrupted beyond repair and you need a fully functional replacement with the same disks and configuration.

Restore files: Recovers individual files

Restore files is a separate Azure Backup workflow that mounts the selected recovery point as an iSCSI target on a designated machine, not as a full VM. This enables granular recovery of individual files or folders from the backup without incurring the overhead of deploying an entire virtual machine. It is ideal when only a few files are missing or corrupt and the original VM itself remains operational.

Replace existing VM: Overwrites the original VM

Replace existing VM is an Azure Backup restore option that writes the disks from the recovery point directly onto the original VM, overwriting its current state. This operation is destructive because the live VM's data is replaced by the backup snapshot, so it should be used only when you need to revert the same VM resource to an earlier state. The VM's identity, NICs, and other attached resources are preserved, but all changes made after the recovery point are lost.

Cross-region restore: Restores to another region

Cross-region restore is available when the Recovery Services vault has Cross-Region Restore enabled and uses geo-redundant storage for backups. This option restores the VM (or its disks) to the paired Azure region, providing disaster recovery capability if the primary region is unavailable. It is particularly valuable for compliance or business continuity scenarios where a secondary copy of the VM must be created in a different geography.

Azure Monitor Metrics: Collects and analyzes numerical data such as CPU and memory usage from Azure resources.

Azure Monitor Metrics is a time-series data store engineered for high-frequency numerical measurements. It ingests platform metrics from Azure resources and guest OS performance counters like CPU and memory percentages, with near-real-time collection and low latency. Because it holds only numeric values, it is ideal for dashboards and metric alerts, but it cannot store text-based logs or events. This definition directly matches the service's role in Azure Monitor.

Azure Monitor Logs: Collects and analyzes log data such as event logs and error traces from Azure resources.

Azure Monitor Logs, backed by a Log Analytics workspace, ingests and stores text-based data such as Windows Event logs, Syslog, custom application logs, and Azure resource logs. Data is queryable using KQL (Kusto Query Language) for deep correlation, trend analysis, and troubleshooting across long retention windows. It is not designed for high-frequency numerical alerting alone, but rather for rich investigative and historical log analysis. This makes it the correct service for event logs and error traces.

Application Insights: Monitors the performance, availability, and usage of applications.

Application Insights is a dedicated application performance management (APM) service within Azure Monitor. It tracks live application telemetry such as requests, dependencies, exceptions, page views, and traces, often instrumented via SDKs or agents. It also provides availability tests and distributed tracing to pinpoint performance bottlenecks. Because it focuses on the application layer rather than the underlying VM infrastructure, it does not natively collect host CPU or memory usage.

Alerts: Proactively sends notifications when specified conditions are met based on metrics or logs.

Azure Monitor Alerts is the notification and automation engine that continuously evaluates metric thresholds or log queries against defined rules. When a condition is met, it invokes action groups to send emails, SMS, push notifications, webhooks, or trigger ITSM and automation runbooks. Unlike the raw data collection services, alerts provide proactive, real-time response and can use dynamic thresholds to adapt to baseline patterns. Thus it is correct that alerts send notifications based on metrics or logs.

Retention Range: Defines how long backup snapshots and recovery points are kept.

Retention Range is the policy element that establishes the lifecycle of every backup copy, defining the duration—from days to years—that daily, weekly, monthly, or yearly recovery points remain available before they expire and are purged from the Recovery Services vault. This duration directly determines how far back in time you can restore a VM, making it the core control for backup durability. It is a time-based measure, not a count.

Backup Schedule: Specifies the time and day when backups are created.

Backup Schedule specifies the exact frequency—typically once or twice per day—and the precise time (along with the time zone) at which Azure triggers a backup job for the protected VM, creating a consistent recovery point at that moment. This setting controls the point-in-time granularity of recoverability, such as a nightly 2:00 AM snapshot. It does not determine how long those points are kept; that responsibility belongs to the retention range.

Snapshot Retention: Controls the number of instant restore snapshots retained.

Snapshot Retention is a distinct setting in Azure VM backup that limits how many instant restore snapshots—taken immediately at backup time and stored locally in the VM's resource group—are kept. The default is two snapshots, and you can configure between one and five; these snapshots permit rapid file or VM restore from the local snapshot without waiting for data to be copied from the vault. This is separate from vault-based retention, which governs recovery points in the backup storage.

Policy Type: Determines whether the policy is Standard or Enhanced.

Policy Type refers to the two available backup policy models for Azure VMs: Standard and Enhanced. The Standard policy only supports the default daily backup and vault-based recovery points up to 30 days, while the Enhanced policy enables multiple backups per day, hourly frequency, and session-level consistency across a VM's disks for faster and more granular recovery. Choosing the correct policy type is a prerequisite because some retention and snapshot options are only available with Enhanced.

where: Filters results to rows matching a specified condition

'where' filters rows based on a boolean expression, keeping only those rows for which the predicate evaluates to true. It operates row-by-row and supports standard comparison operators (=, !=, >, <), string operators (has, startswith), and logical combinations (and, or, not). This operator reduces the number of rows in the result set but does not alter columns or perform any aggregation, making it essential for scoping investigations to a specific time range or error code.

project: Selects a subset of columns

'project' explicitly defines the shape of the output by selecting a subset of existing columns, optionally renaming them or creating new computed columns inline. It reduces the result set's column count and can also reorder columns, but it does not change the number of rows. In investigations, project is used to narrow down the fields of interest after filtering with where, so analysts can focus on relevant attributes without carrying unnecessary data.

summarize: Aggregates data by groups with aggregation functions

'summarize' groups rows by one or more key columns and computes aggregate values (count, sum, avg, min, max, dcount, etc.) for each group. It collapses the input into a new table with one row per distinct combination of group keys, and you can apply multiple aggregation functions in a single summarize clause. Unlike where, it does not preserve individual rows; it transforms the data into statistical summaries, which is useful for quantifying failed operations by error type or resource.

LRS: Data is replicated three times within a single data center.

LRS (Locally Redundant Storage) copies your data synchronously three times within a single physical data center in the primary region. It is the lowest-cost redundancy option, offering significant durability against disk and server failures, but it cannot survive a data center disaster. LRS is appropriate for non-critical workloads or for scenarios where data can be easily reconstructed, since all writes are committed locally without cross-site latency.

ZRS: Data is replicated synchronously across three Azure availability zones.

ZRS (Zone-Redundant Storage) replicates your data synchronously across three Azure availability zones inside the primary region, so all copies remain online even if an entire zone becomes unavailable. Because the copies are in different physical locations, the storage account survives a full data center failure, but it does not protect against a region-wide outage. This redundancy tier is ideal for high availability within a region, but you would still need geo-replication for disaster recovery.

GRS: Data is replicated to a paired secondary region asynchronously.

GRS (Geo-Redundant Storage) copies your data asynchronously to a paired secondary region thousands of miles away, giving you protection from full regional outages. Because replication is asynchronous, the secondary copy can lag behind the primary by a defined recovery point objective (RPO), typically 15 minutes, so some recent writes could be lost during an unplanned failover. The secondary endpoint is not available for reads unless you enable RA-GRS or perform a customer-managed failover.

GZRS: Data is replicated across availability zones and also to a secondary region.

GZRS (Geo-Zone-Redundant Storage) provides maximum durability by combining synchronous zone-redundant replication (three copies across availability zones) with asynchronous geo-replication to a paired secondary region. It ensures your data survives both a zonal failure and a full regional disaster, unlike ZRS or GRS alone. However, in its standard form GZRS does not offer read access to the secondary copy; that capability is reserved for RA-GZRS.

SAS: Provides time-limited delegated access with specified permissions.

A Shared Access Signature (SAS) is a cryptographically signed URI that grants time-limited, delegated access to specific Azure Storage resources without exposing the storage account key. You can specify allowed permissions (e.g., read, write, delete, list) and a validity window, making it suitable for sharing temporary access. The token is signed with either the account key or a user-delegation key derived from Azure AD, and it is validated by the service for each request.

Azure AD authentication: Uses Azure AD identities to authenticate users and applications.

Azure AD authentication signs the request with an OAuth 2.0 access token obtained by the user or application after authenticating to Azure AD. This method supports Azure AD identities, service principals, and managed identities, and integrates with RBAC to authorize actions. It is the recommended alternative to Shared Key authorization because it enables conditional access, MFA, and auditing.

Public access: Allows anonymous read access to containers and blobs.

Public access is a container/account-level setting that allows any unauthenticated client to issue read requests to blobs or container metadata. It can be configured as 'Blob' (anonymous read only for blobs) or 'Container' (anonymous read plus list of blobs). Because no identity or token is presented, this access is anonymous and is typically used for immutable, universally accessible content such as web assets.

RBAC: Assigns granular permissions to Azure AD users, groups, or apps.

RBAC grants permissions via role assignments to users, groups, or apps in Azure AD, with built-in roles such as Storage Blob Data Owner/Reader/Contributor. Roles can be scoped to a management group, subscription, resource group, storage account, or an individual container/queue. RBAC is the primary authorization mechanism for Azure AD-authenticated requests, meaning the request must first be authenticated via Azure AD.

NSG applied to subnet: Traffic filtering is applied to all network interfaces in that subnet.

An NSG associated with a subnet applies its rules to all VMs and resources within that subnet.

ASG applied to VMs: Allows grouping of VMs for application of NSG rules based on workload roles.

ASGs enable logical grouping of VMs with similar functions, simplifying NSG rule creation.

Azure VPN Gateway: Connect on-premises network to Azure storage account over the internet using an encrypted tunnel

Azure VPN Gateway creates a site-to-site (S2S) IPsec/IKE tunnel that sends encrypted traffic from your on-premises network to an Azure virtual network over the public internet. Because encryption protects the payload, you can securely reach a storage account's service endpoint or private endpoint even though the connection path crosses internet routers. This is fundamentally different from a dedicated private connection: the underlying transport is the internet, not a private carrier-grade link.

Azure ExpressRoute: Connect on-premises network to Azure storage account with a dedicated private connection that does not traverse the internet

Azure ExpressRoute establishes a private, dedicated logical connection between your on-premises infrastructure and Azure through a carrier-partner or direct peering, with traffic that never traverses the public internet. This delivers SLAs on availability, lower latency, and higher bandwidth than VPN-based connections. For storage, ExpressRoute can use Microsoft peering or private peering with a private endpoint to reach the storage account without routing over the internet.

Azure Private Link: Access Azure SQL Database privately from a virtual network, ensuring traffic never leaves the Microsoft network

Azure Private Link exposes a PaaS service, such as Azure SQL Database, as a private endpoint with its own IP address inside your virtual network. Traffic from your VNet to the service is routed entirely over the Microsoft backbone, never the public internet, and you can restrict the service's public access. This is a network-level isolation mechanism, distinct from DNS or hybrid WAN solutions.

DNS CNAME record: Map a custom domain name to an Azure App Service endpoint

A DNS CNAME record maps one hostname to another hostname, so you can point your custom domain (e.g., www.contoso.com) to the Azure App Service's default *.azurewebsites.net endpoint. App Service rejects the custom domain until you create and validate the CNAME (or TXT/A record for apex domains), and the mapping affects only DNS resolution, not the network path. This is a configuration task, not a networking service.

Metric alerts: Monitor numeric values

Metric alerts are the correct choice when you need to monitor numeric, time-series data such as CPU percentage, memory utilization, or disk I/O. They evaluate these values against static thresholds (e.g., CPU > 90%) or dynamic thresholds that adapt to the resource's baseline. Alerts fire when the metric crosses the threshold for a specified evaluation period, enabling near-real-time incident response.

Activity log alerts: Track resource changes

Activity log alerts are designed to detect operational events recorded in the Azure activity log, such as resource creation, configuration changes, or deletions. They fire when a specific resource, resource group, or subscription-level operation occurs and can include conditions on operation name, status, or initiator. This supports governance, auditing, and change-control monitoring rather than performance tracking.

Log alerts: Query log data for patterns

Log alerts execute Azure Log Analytics queries on data collected from workspaces, VM insights, or other sources to identify patterns like repeated errors, failed login sequences, or unusual application traces. You define a query and a condition (e.g., result count > 0) with a scheduled frequency and time window. This allows alerting on multi-table logic and historical correlations that metric alerts cannot express.

Changing replication to GRS: Replicates all existing recovery points

When you change a Recovery Services vault's storage redundancy from LRS to GRS, Azure automatically replicates all existing recovery points to the paired region. This is a one-time background operation that propagates historical backups without requiring reconfiguration, and subsequent backups are also replicated. The process ensures that all previously stored restore points become available in the secondary region for disaster recovery.

Soft delete: Retains deleted data for 14 days

Soft delete is a security feature that protects backup data from accidental or malicious deletion. When a backup item is deleted, the data is retained in a soft-deleted state for 14 days, during which it can be restored and the deletion can be undone. After 14 days, the data is permanently purged, unless the soft delete state is re-enabled or the security feature is disabled with escalated privileges.

Changing storage replication after backup: Requires reconfiguration

If you alter the storage replication type for a Recovery Services vault after a backup has already been taken, the vault must be reconfigured to apply the change. This reconfiguration includes stopping and restarting backup jobs or re-registering the backup items, because the existing recovery points are not automatically moved to the new setting. The change takes effect for future backups, but existing recovery points may not be migrated, so you must plan accordingly to avoid losing access to older restore points.

Custom managed identity: Grants specific resource access

A custom managed identity assigned to a Recovery Services vault grants it access to specific Azure resources with a narrowly scoped set of permissions. For example, the vault can use the identity to authenticate to Azure Key Vault for encryption keys or to a storage account for archive or restore operations, without storing user credentials. This follows the principle of least privilege and reduces the risk of credential compromise.