AZ-305 sample questions — 25 answered and explained

Restore and search jobs both reach long-term retention: restore for many queries over a time slice, search jobs for one query over a large range.

The deciding details are many different iterative queries over every record in a short window, and the need to minimize cost. Restore brings that time range back into the analytics tier so any number of fast, full-featured queries can run against it, and it is billed only for the restored slice until you dismiss it. A search job is designed to run a single query and save matching records to a new table, so it suits finding specific events over a long range, not repeated exploration. Extending the table's analytics retention to cover 14 months would also make the data queryable, but it keeps paying analytics retention for the whole table every month instead of for three days of data for one week. An export rule only sends data that arrives after it is created.

1. Note whether the need is one query over a long range or many queries over a short slice.
2. One query, large range: search job. Many queries, short slice: restore.
3. Compare cost: restore bills only the slice for as long as you keep it; longer analytics retention bills the whole table indefinitely.

Exam tip: Iterating over a short slice of old data = restore; one targeted query over a long range = search job.

Diagnostic settings have four destination types; Event Hubs is the one for streaming to external tools.

Diagnostic settings can send resource logs to a Log Analytics workspace, a storage account, an event hub or an Azure Monitor partner solution. Microsoft describes Event Hubs as the destination for streaming data to external systems such as non-Microsoft SIEMs. Storage is for archive, a workspace is for Azure Monitor analysis, and action groups only carry alert notifications.

1. Identify the consumer: an external SIEM that reads a stream.
2. Map consumers to destinations: stream = Event Hubs, archive = storage, analysis = workspace.
3. Choose Event Hubs.

Exam tip: External SIEM wants a stream: send diagnostic settings to Event Hubs.

A diagnostic setting can hold one destination of each type; a resource can have up to five settings.

A single diagnostic setting can define no more than one destination of each type. Two Log Analytics workspaces therefore need two settings, and the storage account can be added to either of them because it's a different destination type. Three settings works but isn't minimal; one setting is impossible. Each resource can have up to five settings, so two is within limits.

1. Count destinations by type: two workspaces, one storage account.
2. One setting holds at most one of each type.
3. The type with the most destinations (two workspaces) sets the minimum: two settings.

Exam tip: Two destinations of the same type need two diagnostic settings.

Storage and Event Hubs destinations of a diagnostic setting must be in the monitored resource's region; a Log Analytics workspace can be anywhere.

Diagnostic settings require storage accounts and event hubs to be in the same region as the regional resource they monitor. The North Europe databases can't point at West Europe targets, so they need a storage account and an Event Hubs namespace in North Europe (a Log Analytics workspace, by contrast, can be in any region). The firewall option is a real requirement when virtual networks are enabled, but the stem rules it out. GRS and extra settings don't change where the destination lives.

1. Note which destinations are used: storage and Event Hubs.
2. Recall the rule: those two must share the monitored resource's region.
3. Discard the firewall option because the stem says no firewall.
4. Provision destinations per region.

Exam tip: Diagnostic settings to storage or Event Hubs: one set of destinations per region.

The activity log holds control-plane events for 90 days; a diagnostic setting exports it for longer retention.

Resource deletions and role assignment changes are control-plane operations recorded in the Azure activity log, which Azure keeps for 90 days. A subscription-level diagnostic setting sends it to the AzureActivity table in a Log Analytics workspace, where retention can be set up to 12 years (and activity log ingestion isn't charged). Resource logs and Entra audit logs record different things, and an alert doesn't store history.

1. Classify the events: control-plane operations on Azure resources.
2. Those live in the activity log, kept 90 days by default.
3. Export it with a subscription diagnostic setting to a workspace.

Exam tip: Control-plane history beyond 90 days: export the activity log with a diagnostic setting.

Capturing every subscription activity log event needs a subscription-level diagnostic setting; Azure Policy deploys one everywhere automatically.

Microsoft notes that a diagnostic setting on a management group doesn't capture every subscription-level event: events without the hierarchy property don't propagate, so a subscription-level setting is still required. Doing that per subscription by hand or by script misses new subscriptions. A DeployIfNotExists policy assigned at the management group (such as the built-in policy that configures Azure Activity logs to stream to a specified workspace) deploys the setting to every current and future subscription; a remediation task covers existing ones.

1. Note the two requirements: every subscription event, and future subscriptions automatically.
2. Recall that management group settings miss events without the hierarchy property.
3. Use Azure Policy DeployIfNotExists at the management group to deploy subscription-level settings, with remediation for existing ones.

Exam tip: All subscription activity events, now and later: DeployIfNotExists policy for subscription diagnostic settings.

Azure Policy DeployIfNotExists plus remediation tasks enable diagnostic settings at scale.

Microsoft's built-in policies and initiatives for resource logging use the DeployIfNotExists effect: when a resource in scope lacks the diagnostic setting, the policy deploys it using a managed identity. That covers new resources automatically. Existing resources are only evaluated as non-compliant, so a remediation task deploys the setting to them. AuditIfNotExists only reports, Deny can't see a setting that doesn't exist yet, and management group diagnostic settings carry activity log events rather than resource logs.

1. Separate new resources from existing ones.
2. New: DeployIfNotExists deploys the setting on create or update.
3. Existing: a remediation task deploys it.
4. Reject effects that only report or block.

Exam tip: Diagnostic settings at scale = DeployIfNotExists for new resources + remediation for existing ones.

Business Critical is the vCore tier for low-latency OLTP with In-Memory OLTP and hot standbys.

Business Critical runs on local SSD storage with a cluster of replicas, giving the lowest I/O latency, fast failover and support for memory-optimized tables. General Purpose uses remote storage and has no In-Memory OLTP, whatever the hardware or redundancy setting. Hyperscale is the default for most new workloads and offers hot standby replicas, but memory-optimized tables aren't supported there, so it fails the cart-session requirement.

1. Find the deciding requirements: memory-optimized tables and lowest storage latency.
2. Remove tiers without In-Memory OLTP tables: General Purpose and Hyperscale.
3. Business Critical remains and also provides hot standby replicas.

Exam tip: Memory-optimized tables in Azure SQL Database = Business Critical (or Premium DTU).

Hyperscale separates compute from storage to support very large databases with fast backup, restore and scaling.

Hyperscale storage grows automatically up to 128 TB, backups are file snapshots taken by the storage layer with no impact on compute, restores complete in minutes, and compute can be scaled without data movement. General Purpose and Business Critical are limited to 4 TB per database and use size-dependent backup and restore, and the DTU tiers are smaller still. Only Hyperscale meets the growth and operations requirements together.

1. Compare the 40 TB projection with each tier's maximum size.
2. Check backup and restore behaviour: only Hyperscale is snapshot-based and size-independent.
3. Choose Hyperscale, which also scales compute without copying data.

Exam tip: Beyond 4 TB or need size-independent backups in Azure SQL Database? Hyperscale.

Leaving Hyperscale is possible only by reverse migration to General Purpose within 45 days.

Two Hyperscale behaviours combine here. A database converted to Hyperscale can be reverse migrated within 45 days, but only to General Purpose; to reach Business Critical you reverse migrate first and then change the service tier. And Hyperscale backups can't be restored as a non-Hyperscale database; pre-migration backups can be, but they don't contain the changes made after conversion. Geo-replicas share the primary's tier, so they don't offer a way out either.

1. Recall the exit path from Hyperscale: reverse migration, 45-day window.
2. Recall its target: General Purpose only, then any further tier change.
3. Reject backup-based and replica-based paths that lose data or can't change tier.

Exam tip: Out of Hyperscale = reverse migrate to General Purpose within 45 days, then change tier.

Serverless compute with auto-pause bills only storage while a database is paused.

The serverless compute tier autoscales between a minimum and maximum vCore setting and bills per second. With auto-pause enabled (it is on by default with a configurable delay), a database idle for the delay is paused and only storage is billed; the next connection resumes it after a short delay. Provisioned compute, in a single database or an elastic pool, is billed continuously, so none of the other options meets the pay-only-for-storage requirement.

1. Note the usage pattern: intermittent, unpredictable, long idle periods.
2. Note the cost goal: only storage while idle, and a resume delay is acceptable.
3. Choose serverless with auto-pause enabled.

Exam tip: Intermittent single database that can wait to resume = serverless with auto-pause.

Elastic pools are the price-performance choice for many databases with intermittent, non-overlapping usage.

Microsoft positions serverless for single databases that can afford warm-up delays, and provisioned elastic pools for multiple databases with intermittent, unpredictable usage. The no-warm-up constraint rules out auto-pause; serverless without auto-pause and per-database provisioning both pay for compute per database. A pool lets the 40 databases share one set of vCores because their peaks rarely coincide, which minimizes total cost with immediate responsiveness.

1. Note the two constraints: no warm-up delay and lowest total compute cost.
2. Auto-pause fails the first; per-database compute (serverless or provisioned) fails the second.
3. Share compute across the 40 databases with an elastic pool.

Exam tip: Many intermittent databases and no resume delay allowed = provisioned elastic pool.

Read scale-out uses the readable replica that Business Critical and Premium already include.

Business Critical (and DTU Premium) databases keep several replicas for high availability, and read scale-out exposes one of them for read-only work at no extra cost. Applications opt in with ApplicationIntent=ReadOnly in the connection string. Data on the replica can lag the primary slightly, which the reports tolerate. Geo-secondaries and Hyperscale named replicas offload reads but are billed for their own compute, and scaling up the primary adds compute charges while leaving the reports on the primary.

1. Note the tier: Business Critical already has a readable replica.
2. Note the constraint: no increase in compute cost.
3. Route the reports with ApplicationIntent=ReadOnly.

Exam tip: Business Critical or Premium + read-only reports = ApplicationIntent=ReadOnly, no extra cost.

Vault storage redundancy is fixed once backups are configured.

Set a Recovery Services vault's storage replication type before you protect anything: after backup is configured, the option to modify it is disabled. To move to GRS later, Microsoft's workaround is to configure protection in a new GRS vault (with Cross Region Restore if restores in the paired region are needed), and stop protection in the old vault while retaining its data so the existing recovery points stay restorable until they expire. Cross Region Restore requires GRS, and recovery points can't be moved between vaults.

1. Recognise that the vault already protects items, so its redundancy is locked.
2. Rule out enabling Cross Region Restore on an LRS vault.
3. Plan a new GRS vault with Cross Region Restore for future backups.
4. Keep the old vault's data by stopping protection with retain data.

Exam tip: Pick vault redundancy before the first backup; changing it later means a new vault.

Multi-user authorization (MUA) for Azure Backup vaults.

Multi-user authorization uses a separate Azure resource, Resource Guard, to protect critical vault operations such as reducing policy or protection retention, stopping protection with delete data, disabling immutability, disabling MUA itself and changing the MARS security PIN. A different user or team must own the Resource Guard, and it can sit in a different subscription or tenant, so a compromised vault admin can't perform those operations alone. Unlocked immutability and resource locks can be undone by an administrator, and longer soft delete doesn't add an approver.

1. Identify the threat: a single privileged account acting alone.
2. Look for a control that requires permissions the vault admin doesn't have.
3. Map that to MUA with a Resource Guard owned by another team.
4. Place the Resource Guard in a separate subscription or tenant for stronger isolation.

Exam tip: Critical backup operations needing a second team's approval = MUA with Resource Guard.

Immutable vaults and soft delete protect backups against ransomware and insiders.

An immutable vault blocks operations that could lose recovery points: stopping protection with delete data and reducing retention, whether by editing or replacing a policy. While it's only enabled it can be disabled; locking it makes the setting irreversible. Soft delete is a separate layer: deleted backup data is kept for the soft-delete retention period, 14 days by default and configurable up to 180 days, so 30 days is supported. MUA adds approvals, not an absolute block, and resource locks can be removed.

1. Translate 'nobody, and not removable' into irreversible immutability: enabled and locked.
2. Translate 'deleted data recoverable for 30 days' into soft-delete retention.
3. Reject controls that an authorised person can still undo or approve.
4. Confirm both settings apply to the Recovery Services vault.

Exam tip: Irreversible protection = locked immutable vault; recover deletions = soft-delete retention.

Azure Backup has two vault types, and each supports a set of workloads.

Azure Backup uses Recovery Services vaults for Azure VMs, SQL Server and SAP HANA in VMs, Azure Files and on-premises (MARS/MABS) backups, and Backup vaults for newer workloads such as Azure Blobs, Azure Disk Backup, Azure Database for PostgreSQL and AKS. Blobs and managed disks therefore fit in one Backup vault.

1. List the workloads: blobs and managed disks.
2. Recall which vault type supports each.
3. Choose the vault type that covers both.

Exam tip: Blobs, managed disks, PostgreSQL and AKS back up to a Backup vault.

Flexible orchestration is the recommended scale set mode for mixed instances.

Flexible orchestration is Microsoft's recommended scale set mode. It manages standard Azure VMs, so features such as Azure Backup work, and it allows mixing Spot and regular-priority instances and different VM sizes in one set. Uniform orchestration manages identical instances from one profile, all Spot or all regular, and its instances aren't supported by Azure Backup. The mode is chosen at creation and can't be changed later.

1. List the requirements: mixed priority, mixed sizes, Azure Backup.
2. Check each against Uniform: it fails all three.
3. Choose Flexible orchestration.

Exam tip: Mixed sizes or mixed Spot and regular in one scale set: Flexible orchestration.

Physical single-tenant hosting is Azure Dedicated Host; scheduled maintenance is a maintenance configuration.

Azure Dedicated Host provides physical servers dedicated to one Azure subscription; you place VMs on hosts in a host group. Because the hosts are yours, you can attach a maintenance configuration to control when platform updates are applied, within a window you set. Confidential VMs protect data in use but share hardware; proximity placement groups and availability sets control placement for latency or resilience, not tenancy.

1. Translate the regulator's rule: hardware used by one customer only.
2. Map it to Azure Dedicated Host.
3. Add control of when platform updates are applied: a maintenance configuration.
4. Reject placement features that don't change tenancy.

Exam tip: No shared hardware: Dedicated Host; control its updates with a maintenance configuration.

Data in use without code changes: confidential VMs, not enclaves.

Azure confidential VMs use hardware-based trusted execution (AMD SEV-SNP or Intel TDX) to encrypt the entire VM's memory with keys the host can't read, and they support attestation of the VM's boot state. Because the whole VM is the protected boundary, an unmodified application can be lifted and shifted. SGX enclaves also protect data in use, but only for code built for an enclave. Dedicated hosts address tenancy, and disk encryption addresses data at rest.

1. Classify the data state: in use, in memory.
2. List services that protect data in use: confidential VMs and enclaves.
3. Apply the no-code-change constraint: rules out enclaves.
4. Choose confidential VMs.

Exam tip: Protect memory from the host with no code changes: confidential VM; with code changes: enclave.

Direct Kubernetes API access is the line between AKS and Container Apps.

Helm charts and operators that install custom resource definitions talk directly to the Kubernetes API server. AKS is the managed Azure service that gives you that API. Azure Container Apps is built on Kubernetes but deliberately hides the API and cluster, so Kubernetes-native tooling can't target it. Container Instances and App Service have no Kubernetes control plane at all.

1. Identify the dependency: Helm and CRD-based operators.
2. Ask which service exposes the Kubernetes API: only AKS.
3. Choose AKS.

Exam tip: Need kubectl, Helm, operators or CRDs? AKS. Don't need the Kubernetes API? Consider Container Apps.

Microservices without cluster operations fit Azure Container Apps.

Azure Container Apps is a serverless container platform built on Kubernetes, Dapr, KEDA and Envoy. It provides service discovery, revisions with traffic splitting, Dapr building blocks and scale to zero, while Microsoft runs the underlying cluster. AKS offers the same capabilities only if the team runs a cluster; Container Instances and App Service lack the microservice features.

1. List the features: Dapr, discovery, revisions, scale to zero.
2. Apply the constraint: no cluster to operate.
3. Choose Azure Container Apps.

Exam tip: Kubernetes-style microservices without running Kubernetes: Container Apps.

Specialised hardware goes in its own user node pool, reserved with taints and scaled to zero.

AKS separates system node pools (which host critical system pods and must keep at least one node) from user node pools. A GPU user pool with the cluster autoscaler can scale from zero, so GPU VMs are billed only while training pods need them. Applying a taint to the GPU pool and a toleration to the training pods reserves those nodes. A node selector only attracts pods to nodes; it doesn't keep other pods, such as the web pods, off them.

1. Separate the hardware: a dedicated GPU user node pool.
2. Remove idle cost: cluster autoscaler with minimum count 0.
3. Reserve the nodes: taint the pool, tolerate only training pods.
4. Reject changes to the system pool or a second cluster.

Exam tip: GPU or Spot capacity in AKS: its own user pool, tainted, autoscaled from zero.

Interruptible AKS work goes on a Spot user node pool that autoscales.

AKS supports Spot node pools as user node pools only; the system pool must use regular capacity. Because the pods checkpoint and restart safely, eviction is acceptable. Enabling the cluster autoscaler on the Spot pool lets it add nodes when pods are pending and remove them when the run ends. Spot pools carry a taint, so the processing pods need the matching toleration to schedule there.

1. Confirm the pods tolerate eviction: checkpoints and restart.
2. Place them on a Spot user pool, never the system pool.
3. Add the cluster autoscaler so capacity exists only during the run.

Exam tip: Spot in AKS: user pools only, with the cluster autoscaler for bursty work.

Container Apps scale rules come from KEDA; scale to zero needs an event-based rule and min replicas 0.

Azure Container Apps scales with KEDA-based rules. A custom rule for Azure Service Bus watches message count and adds replicas as the backlog grows. Setting the minimum replica count to 0 allows the app to scale to zero when there is nothing to process. CPU and memory rules can't scale to zero and don't measure the backlog, and a minimum of 1 keeps a billed replica running all night.

1. Identify the scaling signal: queue length.
2. Choose the matching KEDA rule: Service Bus.
3. Set minimum replicas to 0 to remove idle cost.

Exam tip: Queue-driven Container App: event scale rule plus min replicas 0.