All practice questions

1198 questions

Question 921Question

An online food delivery service is designing a real-time driver tracking system on Azure. The system will ingest GPS coordinates every 5 seconds from 50,000 drivers. The solution must support sub-10ms write latency, distribute write operations evenly to prevent performance degradation, and remain available in the event of a regional datacenter outage. The primary query will retrieve the latest coordinates for a specific active trip using its unique trip identifier (a high-cardinality GUID). Which configuration should you recommend?

Show answer & explanation

Answer: Set the partition key to the trip identifier and enable multi-region writes for the Azure Cosmos DB account.

Answer

Set the partition key to the trip identifier and enable multi-region writes for the Azure Cosmos DB account.
The correct design uses the high-cardinality trip identifier (GUID) as the partition key to distribute write workloads evenly across partitions, combined with multi-region writes to satisfy the sub-10ms write latency and regional disaster resilience requirements.

Step-by-Step Solution

1
Evaluate the partition key cardinality to prevent hot partitions under high write load.
The trip identifier (GUID) is high-cardinality, ensuring uniform distribution of write and read requests across logical partitions.
Using low-cardinality keys like vehicle type concentrates writes on few partition keys, leading to partition key exhaustion and throughput throttling.
2
Select the replication and redundancy strategy to survive regional outages and meet latency requirements.
Configure multi-region writes.
Multi-region writes allow local writes in multiple regions with low latency, providing high availability and regional failover capabilities, whereas LRS lacks regional redundancy.
3
Evaluate secure data access for external storage/archival needs.
Avoid long-lived, direct SAS tokens embedded in the client.
Long-lived SAS tokens without stored access policies cannot be revoked easily and represent a major security risk.

Key Concept

Designing partition keys for even throughput distribution and multi-region replication for disaster recovery in Azure Cosmos DB.
Question 922Question

A gaming company is designing an analytical data platform to analyze multiplayer match telemetry logs. The solution must meet the following requirements:
- Volume: 500 GB of telemetry data is generated daily.
- Ingestion: Logs are uploaded as Parquet files to Azure Data Lake Storage Gen2 (ADLS Gen2) every 6 hours.
- Query Latency: Analysts run ad-hoc exploratory queries that must return results within 2 minutes.
- Cost: The compute solution must not incur charges when no queries are running.
- Resiliency: The storage solution must survive a primary datacenter outage.

Which design should you recommend?

Show answer & explanation

Answer: An Azure Synapse Analytics serverless SQL pool querying data stored in an ADLS Gen2 account configured with Geo-Redundant Storage (GRS)

Answer

An Azure Synapse Analytics serverless SQL pool querying data stored in an ADLS Gen2 account configured with Geo-Redundant Storage (GRS)
The correct solution uses Azure Synapse Analytics serverless SQL pool to query data stored in a Geo-Redundant Storage (GRS) enabled Azure Data Lake Storage Gen2 account. Synapse serverless SQL pool is designed for ad-hoc, exploratory queries on file-based data lakes, scaling compute automatically and charging only for the query data processed (with zero idle cost). GRS replicates data to a secondary region, protecting against primary datacenter failure.

Step-by-Step Solution

1
Evaluate the compute requirement for ad-hoc exploratory queries with zero idle cost.
Identify Azure Synapse Analytics serverless SQL pool as the optimal compute choice because it charges only for data processed and incurs no costs when idle, unlike dedicated SQL pools.
Meets the requirement for ad-hoc querying without persistent compute overhead.
2
Evaluate the resiliency requirement of surviving a primary datacenter outage.
Select Geo-Redundant Storage (GRS) over Locally Redundant Storage (LRS) for the Azure Data Lake Storage Gen2 account.
LRS is vulnerable to a single datacenter outage, whereas GRS replicates data to a paired secondary region.
3
Assess alternate compute solutions like Azure Functions on Consumption plan.
Rule out Azure Functions due to potential execution timeouts (max 10 minutes) when scanning large datasets.
Ensures query execution reliability and avoids serverless timeouts.

Key Concept

Selecting serverless SQL pools for ad-hoc queries on data lakes and configuring Geo-Redundant Storage for resiliency.
Estimated Time:1m 30s
Question 923Question

An Azure Solutions Architect is designing the database tier for a global e-commerce shopping cart service. The system must support millions of concurrent users globally, demanding write and read latencies under 10 ms10\text{ ms} for 99%99\% of requests. The workload is read-heavy with a 70:30 read-to-write ratio. The architect must ensure a 99.999%99.999\% availability SLA for both read and write operations, and the database must survive a regional outage with a recovery point objective (RPO) of less than 5 minutes.

Which two configuration options should you select to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Enable multi-region writes and set the default consistency level to Bounded Staleness.; Select the userId attribute as the partition key for the shopping cart container.

Answer

To meet the requirements, you should enable multi-region writes and set the default consistency level to Bounded Staleness, and select the userId attribute as the partition key for the shopping cart container.
Enabling multi-region writes satisfies the 99.999% write availability SLA requirement. Since strong consistency is not supported with multi-region writes, Bounded Staleness is the best option because it ensures that replication lag is strictly bounded (e.g., to a few seconds or operations), which guarantees the RPO of less than 5 minutes is met. Additionally, selecting the userId attribute provides a high-cardinality partition key that distributes the workload evenly across logical partitions, preventing hot partitions.

Step-by-Step Solution

1
Analyze availability and latency requirements to determine the database replication and consistency configuration.
To achieve a 99.999% SLA for both read and write operations, Cosmos DB must be configured with multi-region writes. Strong consistency cannot be used with multi-region writes, so Bounded Staleness is selected because it bounds the lag (staleness window) to easily satisfy the 5-minute RPO requirement.
Azure Cosmos DB requires multi-region writes to guarantee a 99.999% write availability SLA, and Bounded Staleness enforces a maximum lag limit for secondary regions.
2
Evaluate the partition key selection to prevent hot partitions under high concurrent user load.
A high-cardinality partition key such as userId is selected because it distributes requests evenly across physical partitions, whereas low-cardinality options would cause performance bottlenecks.
Choosing a high-cardinality partition key is a best practice to avoid hot partitions and ensure horizontal scalability in Azure Cosmos DB.

Key Concept

Designing high-availability, multi-region Azure Cosmos DB databases with optimal partitioning and consistency levels.
Estimated Time:2m 0s
Question 924Question

An educational technology company is designing a data integration and analytics platform to process student learning platform telemetry. The platform must meet the following requirements:
- Store and analyze 12 TB of historical student activity logs currently formatted as Parquet files.
- Ingest new telemetry logs as Parquet files at a rate of 15 GB per hour.
- Support ad-hoc exploratory queries using standard T-SQL with a target latency of under 10 seconds.
- Maintain data availability even in the event of a primary Azure region failure.
- Minimize administrative and compute costs associated with the ad-hoc queries.
- Provide secure access to external research partners that can be easily revoked.

Which two actions should you recommend?

Select all that apply

Show answer & explanation

Answer: Configure the Azure Data Lake Storage Gen2 account to use Geo-Redundant Storage (GRS).; Use Azure Synapse Analytics serverless SQL pools to execute T-SQL queries directly on the Parquet files.

Answer

Configure the Azure Data Lake Storage Gen2 account to use Geo-Redundant Storage (GRS) and use Azure Synapse Analytics serverless SQL pools to execute T-SQL queries directly on the Parquet files.
Configuring the Azure Data Lake Storage Gen2 account to use Geo-Redundant Storage (GRS) satisfies the requirement to survive a regional outage, and using serverless SQL pools enables querying the data directly in the lake using T-SQL while minimizing compute costs and administrative overhead.

Step-by-Step Solution

1
Analyze storage redundancy requirements.
Identify that Geo-Redundant Storage (GRS) is required to survive a primary region outage.
Locally Redundant Storage (LRS) is insufficient for regional disaster resilience.
2
Evaluate query models for cost-efficient ad-hoc exploration.
Choose Azure Synapse Analytics serverless SQL pools over dedicated SQL pools.
Serverless SQL pools query files in place, avoiding the cost and overhead of provisioning dedicated clusters.

Key Concept

Selecting appropriate analytical query services and storage redundancy models based on cost, performance, and availability constraints.
Question 925Question

A logistics company is designing an Azure-based telemetry and media capture solution for a global fleet of 50,00050,000 delivery vehicles. Each vehicle uploads a JSON telemetry packet and a small dashcam image every 1010 seconds. The solution must support write-heavy ingestion scalability with sub-10 ms10\text{ ms} database latencies, survive regional datacenter outages, and allow secure, temporary access to the dashcam images stored in Azure Blob Storage. Which configuration should you recommend for the storage architecture?

Show answer & explanation

Answer: Configure Azure Cosmos DB using the NoSQL API with multi-region writes, setting the partition key of the telemetry container to the vehicle ID. Store the dashcam images in a geo-redundant storage (GRS) account, and access them using short-lived Shared Access Signatures (SAS) generated dynamically via a user delegation key.

Answer

Configure Azure Cosmos DB using the NoSQL API with multi-region writes, setting the partition key of the telemetry container to the vehicle ID. Store the dashcam images in a geo-redundant storage (GRS) account, and access them using short-lived Shared Access Signatures (SAS) generated dynamically via a user delegation key.
The correct option correctly pairs a high-cardinality partition key (vehicle ID) to avoid hot partitions with multi-region write replication for high availability and regional resiliency. Additionally, it leverages GRS for image storage and short-lived SAS tokens generated dynamically, satisfying the security, resilience, and operational requirements.

Step-by-Step Solution

1
Select the Cosmos DB partition key.
The vehicle ID provides high cardinality, distributing database requests evenly across physical partitions and preventing hot partitions.
Choosing a high-cardinality property is critical for write-heavy workloads to maximize Request Unit efficiency.
2
Configure redundancy and geo-replication.
Select multi-region writes for Azure Cosmos DB and Geo-redundant storage (GRS) for Azure Blob Storage.
This guarantees high availability, sub-10ms read/write latencies globally, and data survival during a regional outage.
3
Establish secure access for media files.
Generate short-lived user delegation SAS tokens dynamically via Microsoft Entra credentials.
This avoids exposing storage account access keys and limits the potential blast radius of compromised tokens.

Key Concept

Azure Cosmos DB partition key design, multi-region replication, and secure Azure Storage integration.
Estimated Time:2m 0s
Question 926Question

A logistics company is designing an analytical data solution to review daily shipping routes and delivery anomalies. Approximately 50 GB50\text{ GB} of delivery log files in JSON format are uploaded hourly to an Azure Data Lake Storage Gen2 account. Data analysts need to run ad-hoc exploratory SQL queries on the raw JSON data to inspect specific routes. The solution must minimize provisioning and administrative overhead, and ensure compute resources are charged only when queries are executed. Which Azure service should you recommend in the design?

Show answer & explanation

Answer: A serverless SQL pool in Azure Synapse Analytics

Answer

A serverless SQL pool in Azure Synapse Analytics
A serverless SQL pool in Azure Synapse Analytics is the optimal choice because it is a query service over the data lake. It allows analysts to execute T-SQL queries directly against JSON data stored in Azure Data Lake Storage Gen2. There are no resources to provision, and billing is based purely on the amount of data processed by the queries, satisfying the requirement to minimize overhead and cost.

Step-by-Step Solution

1
Analyze the ingestion and storage requirements.
JSON delivery logs totaling 50 GB50\text{ GB} daily are stored in Azure Data Lake Storage (ADLS) Gen2.
Understanding the source storage helps filter out services that cannot query raw data files directly.
2
Evaluate compute models based on cost and overhead.
Ad-hoc query patterns require a pay-per-query model with zero provisioning to minimize overhead.
Dedicated clusters or databases would incur idle costs and require schema setup.
3
Identify the optimal SQL query engine for ADLS Gen2 files.
Synapse serverless SQL pool supports direct T-SQL queries over JSON in ADLS Gen2 on-demand.
This matches the requirement to only pay for executed queries and minimize setup work.

Key Concept

Selecting serverless T-SQL execution over raw data lakes for ad-hoc exploratory queries
Estimated Time:1m 30s
Question 927Question

An online streaming media platform needs to analyze user engagement metrics collected from smart TV applications. The platform logs are continuously ingested into Azure Data Lake Storage (ADLS) Gen2 in Parquet format. Analysts need to run ad-hoc exploratory queries to investigate user behavior patterns over the past 24 hours. The platform must minimize operational overhead and avoid paying for idle compute resources, as these ad-hoc queries are unpredictable and infrequent. Which analytical query solution should you recommend to meet these requirements?

Show answer & explanation

Answer: Azure Synapse Analytics serverless SQL pools querying the Parquet files directly in Azure Data Lake Storage Gen2

Answer

Azure Synapse Analytics serverless SQL pools querying the Parquet files directly in Azure Data Lake Storage Gen2
Using Azure Synapse Analytics serverless SQL pools to query Parquet files directly in Azure Data Lake Storage Gen2 is the most cost-effective and low-overhead solution. It uses a pay-per-query model, which avoids costs for idle resources during periods with no ad-hoc query activity.

Step-by-Step Solution

1
Analyze the operational and resource requirements of the scenario.
Identified that queries are ad-hoc, unpredictable, infrequent, and require minimizing costs for idle compute.
To determine the appropriate pricing model and compute tier.
2
Evaluate compute models in Azure Synapse Analytics.
Serverless SQL pools charge per query based on data processed, while Dedicated SQL pools charge continuously for provisioned resources.
To choose between serverless and dedicated SQL pools based on cost efficiency.
3
Assess storage tier and redundancy requirements.
Archive tier data cannot be queried directly, and Locally Redundant Storage (LRS) does not survive regional outages.
To eliminate configurations that fail to meet retrieval latency and resiliency requirements.

Key Concept

Data Integration and Analytical Storage
Question 928Question

A company is designing a global booking application for hotel reservations. The application must support:
- Sub-10ms read and write response times for users worldwide.
- High-throughput write ingestion of reservation records.
- Resilience against regional outages without requiring manual failover.
- Queries that primarily retrieve individual booking details using a unique booking ID, and secondary queries that list all bookings by hotel.

You need to design the Azure Cosmos DB NoSQL solution. Which two configurations should you recommend to meet the requirements?

Select all that apply

Show answer & explanation

Answer: Enable multi-region writes and configure the container's partition key using the booking ID.; Configure the Azure Cosmos DB account to replicate across multiple regions and enable service-managed failover.

Answer

Enable multi-region writes, configure the container's partition key using the booking ID, replicate the account across multiple regions, and enable service-managed failover.
The correct architecture uses a high-cardinality partition key (booking ID) to distribute operations evenly across physical partitions, avoiding throttling. To meet the latency and availability goals, the Azure Cosmos DB account must replicate to multiple regions with multi-region writes enabled, and service-managed failover must be enabled to automate disaster recovery.

Step-by-Step Solution

1
Select a partition key with high cardinality.
Using the unique booking ID ensures writes and reads are distributed evenly across logical partitions, avoiding hot partitions.
Choosing a low-cardinality key like hotel country code would create hot partitions, which violates Cosmos DB best practices.
2
Configure global distribution and failover options.
Enabling multi-region writes and replicating to multiple regions provides low latency and geo-redundancy, while service-managed failover automates disaster recovery.
This configuration provides sub-10ms writes globally and guarantees automatic failover in the event of a regional outage.

Key Concept

Azure Cosmos DB partition key design and high-availability configuration
Question 929Question

An organization is modernizing its application portfolio and migrating its data tier to Azure Cosmos DB. You need to recommend the appropriate Azure Cosmos DB API for each application workload based on their technical requirements. Match the application workloads on the left to the correct Azure Cosmos DB APIs on the right.

Click a left item, then click its matching right item

Items

A telemetry system currently running on a wide-column store that must continue using CQL-based client drivers and tools.
A new customer order management system requiring flexible JSON document storage and queries using structured SQL syntax.
A fraud detection system that analyzes networks of transactions, accounts, and devices to identify suspicious relationship patterns.
A legacy catalog system built with the Mongoose ODM framework that must be migrated with minimal application code modifications.

Matches

Show answer & explanation

Answer

Match the wide-column telemetry system using CQL to API for Cassandra; match the new customer order management system using SQL syntax to API for NoSQL; match the fraud detection system analyzing relationship patterns to API for Gremlin; and match the legacy content management system using Mongoose to API for MongoDB.
Matching the wide-column telemetry workload to API for Cassandra allows the reuse of CQL drivers. Matching the new JSON SQL-based workload to API for NoSQL aligns with native Cosmos DB capabilities. Matching the network-relationship fraud detection workload to API for Gremlin facilitates graph traversals. Matching the Mongoose ODM catalog workload to API for MongoDB ensures compatibility with MongoDB drivers.

Step-by-Step Solution

1
Analyze the telemetry workload requiring CQL driver compatibility.
Identify that CQL is the Cassandra Query Language, pointing to the API for Cassandra.
This minimizes rewrites for Cassandra-based applications.
2
Analyze the customer order management workload requiring JSON storage and SQL-like queries.
Identify that Azure Cosmos DB's native SQL API is the API for NoSQL.
API for NoSQL provides optimal performance and features for document-based workloads querying with SQL syntax.
3
Analyze the fraud detection workload analyzing transaction networks and relationships.
Identify that graph relationships are best managed via a graph database model using Gremlin.
API for Gremlin supports graph traversals and relationship modeling.
4
Analyze the legacy content management system workload utilizing Mongoose ODM.
Identify that Mongoose is a popular MongoDB ODM framework, mapping to the API for MongoDB.
API for MongoDB supports MongoDB wire protocols, allowing Mongoose to function with minimal config adjustments.

Key Concept

Azure Cosmos DB API selection based on workload requirements and legacy system compatibility.
Question 930Question

An insurance company is designing an analytical data platform to query historical claims data. The platform must ingest transaction data at a rate of 200 GB200\text{ GB} per day, resulting in a volume of 6 TB6\text{ TB} of Parquet files monthly. Data analysts will run ad-hoc, exploratory SQL queries against these files with unpredictable frequency and require a query latency of under one minute. The solution must minimize operational and compute costs when no queries are running. Additionally, the data storage must survive a complete regional datacenter outage. Which two configurations should you recommend in the design? (Select two.)

Select all that apply

Show answer & explanation

Answer: An Azure Synapse Analytics serverless SQL pool to execute the ad-hoc queries.; An Azure Data Lake Storage Gen2 account configured with Geo-Redundant Storage (GRS) to store the Parquet files.

Answer

The correct configurations are using an Azure Synapse Analytics serverless SQL pool and an Azure Data Lake Storage Gen2 account configured with Geo-Redundant Storage (GRS).
To support ad-hoc SQL queries on Parquet files in a data lake without ongoing operational compute costs when inactive, a serverless SQL pool in Azure Synapse Analytics is the most cost-effective and low-overhead solution. To survive a complete regional datacenter outage, the Azure Data Lake Storage Gen2 account must be configured with Geo-Redundant Storage (GRS), which replicates the data asynchronously to a secondary region.

Step-by-Step Solution

1
Analyze the query and operational overhead requirements.
Identify that queries are ad-hoc and unpredictable, and compute costs must be minimized when inactive.
This determines whether to use a serverless query model (no continuous compute charges) or a dedicated persistent cluster.
2
Evaluate the storage redundancy needs for disaster recovery.
Determine that the storage account must withstand a complete regional datacenter outage.
This requires selecting a geo-redundant storage replication tier (GRS) rather than local replication (LRS).
3
Combine the selected services into a unified architecture.
Combine an Azure Synapse Analytics serverless SQL pool with a Geo-Redundant (GRS) Azure Data Lake Storage Gen2 account.
This fulfills all target architecture requirements with minimal cost and maximum durability.

Key Concept

Designing low-cost ad-hoc analytical query layers coupled with geo-resilient storage replication.
Estimated Time:2m 0s
Question 931Question

A company is designing a data storage and retention strategy for two datasets stored in an Azure Storage account. The account must be designed to survive a primary datacenter outage and maintain regional disaster resilience. The datasets have the following requirements:

* Active Queries: These blobs are accessed frequently for the first 1010 days, followed by occasional access for the next 3535 days during which sub-second retrieval latency is required. The blobs must be deleted after a total of 4545 days.
* Audit Logs: These blobs are accessed occasionally for the first 3030 days during which sub-second retrieval latency is required. They must be retained for a total of 365365 days for compliance, after which they can be deleted. A retrieval latency of up to 1515 hours is acceptable after the initial 3030 days.

You need to select the storage account redundancy and lifecycle policy configuration that minimizes costs while meeting all requirements without incurring early deletion charges.

Which solution should you recommend?

Show answer & explanation

Answer: Configure the storage account with Geo-redundant storage (GRS). For Active Queries, transition to the Cool tier after 1010 days, and delete after 4545 days. For Audit Logs, transition to the Archive tier after 3030 days, and delete after 365365 days.

Answer

Configure the storage account with Geo-redundant storage (GRS). For Active Queries, transition to the Cool tier after 1010 days, and delete after 4545 days. For Audit Logs, transition to the Archive tier after 3030 days, and delete after 365365 days.
The correct solution configures the storage account with Geo-redundant storage (GRS) to satisfy the regional resilience requirement, as Locally redundant storage (LRS) only replicates data within a single datacenter. For the Active Queries dataset, transitioning to the Cool tier after 1010 days and deleting after 4545 days keeps the data in the Cool tier for 3535 days, which exceeds the Cool tier's minimum retention period of 3030 days and thus avoids early deletion charges while maintaining the sub-second retrieval latency requirement. For the Audit Logs dataset, transitioning to the Archive tier after 3030 days and deleting after 365365 days keeps the data in the Archive tier for 335335 days, which exceeds the Archive tier's minimum retention period of 180180 days, minimizing costs while meeting the latency and retention requirements.

Step-by-Step Solution

1
Determine the storage account redundancy configuration required for regional disaster resilience.
The storage account must be configured with Geo-redundant storage (GRS).
The requirements specify that the storage account must survive a primary datacenter outage and maintain regional disaster resilience. Locally redundant storage (LRS) only replicates data within a single datacenter and cannot survive a datacenter outage.
2
Determine the lifecycle policy for the Active Queries dataset based on retention and retrieval latency requirements.
Transition Active Queries to the Cool tier after 1010 days, and delete them after 4545 days.
Active Queries require sub-second retrieval latency between days 1111 and 4545. Moving them to the Archive tier would violate this requirement due to rehydration delays. Transitioning them to the Cool tier after 1010 days and deleting them after 4545 days means they spend 3535 days in the Cool tier. Since this is greater than the Cool tier's 3030-day minimum retention period, no early deletion charges are incurred.
3
Determine the lifecycle policy for the Audit Logs dataset based on retention and retrieval latency requirements.
Transition Audit Logs to the Archive tier after 3030 days, and delete them after 365365 days.
Audit Logs require sub-second retrieval latency for the first 3030 days. After 3030 days, a 1515-hour retrieval delay is acceptable, allowing them to be moved to the Archive tier to minimize costs. Since they will spend 335335 days in the Archive tier (36530365 - 30) before deletion, this exceeds the Archive tier's 180180-day minimum retention period, avoiding early deletion charges.

Key Concept

Lifecycle management tier transitions and early deletion penalties
Question 932Question

An organization is designing a globally distributed IoT stream processing application that will ingest telemetry data from 100,000100,000 smart grid sensors deployed across two geographic regions. The workload is write-heavy, generating over 50,00050,000 writes per second. You need to design an Azure Cosmos DB for NoSQL solution that ensures write scalability, prevents hot partitions, and maintains high availability even during a regional outage. Which configuration should you recommend?

Show answer & explanation

Answer: Configure the Cosmos DB container with a partition key of deviceId and enable multi-region writes for the Cosmos DB account across the deployed regions.

Answer

Configure the Cosmos DB container with a partition key of deviceId and enable multi-region writes for the Cosmos DB account across the deployed regions.
The configuration utilizing deviceId as the partition key and enabling multi-region writes is correct because deviceId has high cardinality, which distributes the 50,00050,000 writes per second evenly across the physical partitions. Multi-region writes provide the necessary high availability and write performance in both regions to survive regional outages.

Step-by-Step Solution

1
Analyze partition key requirements for write scalability.
Identify deviceId as a high-cardinality attribute (100,000100,000 unique values) compared to region (2 values) or deviceType (low variety).
A high-cardinality partition key ensures even distribution of write requests across physical partitions, avoiding hot partitions.
2
Evaluate high availability and disaster recovery requirements.
Select multi-region writes rather than locally redundant storage options.
Locally Redundant Storage (LRS) is vulnerable to regional datacenter outages, whereas multi-region write replication guarantees high availability and regional failover capabilities.
3
Verify security best practices for credentials.
Avoid hardcoded long-lived Shared Access Signature (SAS) tokens.
Hardcoded secrets with long lifetimes violate the principle of least privilege and complicate rotating credentials or revoking access if compromised.

Key Concept

Azure Cosmos DB partitioning, multi-region replication, and secure credential design.
Estimated Time:1m 30s
Question 933Question

An organization is designing a fleet management system using Azure Cosmos DB for NoSQL to store telemetry data from 2,000,0002,000,000 active delivery vehicles. Each vehicle uploads a status message containing `VehicleId`, `CurrentStatus` (which can be 'Active', 'Idle', or 'Maintenance'), and `Timestamp` every 6060 seconds. The database must sustain high-throughput write operations and handle queries that retrieve the telemetry history for a specific vehicle. Additionally, the database must remain available for reads even during a regional outage. Which design configuration should you recommend?

Show answer & explanation

Answer: Configure the container with VehicleId as the partition key and add a secondary region to the Azure Cosmos DB account.

Answer

Configure the container with VehicleId as the partition key and add a secondary region to the Azure Cosmos DB account.
The correct design uses VehicleId as the partition key because it has high cardinality (2,000,0002,000,000 unique values) and aligns with the query pattern, which distributes throughput evenly. Adding a secondary region ensures that the database remains available for reads if the primary region experiences an outage.

Step-by-Step Solution

1
Analyze partition key requirements for high-throughput writes and specific query patterns.
VehicleId is selected as the partition key because it has high cardinality (2 million unique values) and aligns with the query pattern of retrieving history for a specific vehicle.
Choosing a high-cardinality key like VehicleId ensures write and read operations are distributed evenly across physical partitions, avoiding hot partitions.
2
Evaluate high availability and disaster recovery requirements.
Adding a secondary region to the Azure Cosmos DB account ensures high availability and read availability in the event of a primary region outage.
Locally redundant storage (LRS) only replicates data within a single region and cannot protect against a regional outage.
3
Evaluate the security configuration for client writes.
Avoid distributing long-lived credentials (like a 5-year SAS token) directly on the vehicle devices.
Long-lived credentials without stored access policies are difficult to revoke and expose the database to unauthorized access if a device is compromised.

Key Concept

Azure Cosmos DB Partition Key Selection and High Availability
Question 934Question

A logistics company is designing an Azure storage solution for a fleet tracking application. The application will store telemetry data as block blobs in a General Purpose v2 (GPv2) storage account. The solution must meet the following requirements:

* The storage must survive the failure of an entire availability zone in the primary region without data loss or downtime.
* The data must be replicated to a paired secondary region to protect against a regional disaster.

Which two redundancy options meet these requirements?

Select all that apply

Show answer & explanation

Answer: Geo-zone-redundant storage (GZRS); Read-access geo-zone-redundant storage (RA-GZRS)

Answer

Geo-zone-redundant storage (GZRS) and Read-access geo-zone-redundant storage (RA-GZRS)
The correct options are Geo-zone-redundant storage (GZRS) and Read-access geo-zone-redundant storage (RA-GZRS). GZRS replicates data across three availability zones in the primary region and also replicates it asynchronously to a secondary region, providing protection against both zone-level and region-level failures. RA-GZRS offers the same replication capabilities with the added benefit of read access to the secondary region, which also satisfies the core resiliency constraints.

Step-by-Step Solution

1
Analyze the primary region high availability requirement.
Survival of an availability zone failure requires synchronous replication across multiple availability zones in the primary region (ZRS or GZRS/RA-GZRS). Locally redundant options (LRS and GRS) are eliminated because they replicate within a single datacenter in the primary region.
GRS uses LRS in the primary region, meaning a zone outage containing that datacenter would cause data unavailability.
2
Analyze the disaster recovery requirement.
Protection against a regional disaster requires replication to a secondary region (GRS, RA-GRS, GZRS, or RA-GZRS). Local or zonal-only redundancy options (LRS and ZRS) are eliminated because they do not replicate outside the primary region.
ZRS only replicates within the primary region, meaning a regional outage would result in data loss or unavailability.
3
Combine the requirements to identify the matching redundancy options.
Only Geo-zone-redundant storage (GZRS) and Read-access geo-zone-redundant storage (RA-GZRS) provide both zone-level redundancy in the primary region and geo-replication to a secondary region.
Both GZRS and RA-GZRS satisfy the combined constraints of surviving a zone failure and providing regional disaster recovery.

Key Concept

Azure Storage redundancy options combine local, zonal, and regional replication strategies. Surviving a zone outage requires ZRS-based primary replication, while surviving a regional outage requires geo-replication.
Question 935Question

A financial services company is designing an analytical data platform to audit daily credit card transactions. The platform must store 15 TB15\text{ TB} of historical records and ingest new batch transaction data at a rate of 250 GB250\text{ GB} of CSV files nightly. Data analysts need to run ad-hoc exploratory SQL queries on the raw files with sub-minute query latency. The storage solution must remain available even during a complete regional datacenter outage. You need to minimize operational overhead and avoid paying for idle compute resources. Which two components should you include in the analytical storage and query design?

Select all that apply

Show answer & explanation

Answer: Azure Synapse Analytics serverless SQL pools; Azure Data Lake Storage Gen2 with Geo-Redundant Storage (GRS)

Answer

Azure Synapse Analytics serverless SQL pools and Azure Data Lake Storage Gen2 with Geo-Redundant Storage (GRS)
The correct architecture uses Azure Synapse Analytics serverless SQL pools for pay-per-query ad-hoc SQL analysis on raw CSV files directly in the data lake, eliminating idle compute costs and operational overhead. Azure Data Lake Storage Gen2 with Geo-Redundant Storage (GRS) ensures the storage layer survives a regional datacenter outage by replicating the files to a paired region.

Step-by-Step Solution

1
Evaluate the analytical query model requirements.
Serverless SQL pools are selected instead of dedicated SQL pools because queries are ad-hoc, run directly on raw CSV files, and compute costs must only be incurred during query execution with minimal operational overhead.
Dedicated pools incur high idle costs and administrative overhead, which violates the requirement to avoid paying for idle compute.
2
Determine the optimal storage account tier and redundancy level.
Azure Data Lake Storage Gen2 with GRS is selected.
A hierarchical namespace is required for organizing data lake files efficiently, and GRS replicates data to a secondary region to satisfy the regional resilience requirement, whereas LRS only protects against local hardware failures.

Key Concept

Selecting the optimal serverless query engine and geo-redundant storage configuration for ad-hoc analytical workloads.
Question 936Question

A pharmaceutical research company is designing a storage solution for clinical trial data using Azure Blob Storage. The data is stored in a General Purpose v2 (GPv2) storage account. The solution must satisfy the following requirements:

* The primary storage must survive the failure of an entire availability zone within the primary region without any downtime or data loss.
* In the event of a complete primary region failure, read operations must continue from a secondary region with a minimal recovery time objective (RTO), without waiting for a failover to be initiated.

Which storage redundancy option should you recommend?

Show answer & explanation

Answer: Read-access geo-zone-redundant storage (RA-GZRS)

Answer

Read-access geo-zone-redundant storage (RA-GZRS)
Read-access geo-zone-redundant storage (RA-GZRS) is correct because it combines the zonal replication of ZRS in the primary region with geo-replication to a secondary region. Crucially, it provides a read-only endpoint in the secondary region, allowing applications to read data immediately during a primary region failure without waiting for a failover.

Step-by-Step Solution

1
Identify the primary region resiliency requirement.
To survive an availability zone failure without downtime or data loss, the data must be replicated across multiple availability zones in the primary region. This narrows the choices to Zone-redundant storage (ZRS), Geo-zone-redundant storage (GZRS), or Read-access geo-zone-redundant storage (RA-GZRS).
Zonal resilience requires zone-redundant options in the primary region.
2
Identify the regional disaster recovery requirement.
The solution must survive a complete primary region failure, which eliminates ZRS because it only replicates data within the primary region.
Regional disaster recovery requires a geo-redundant storage option.
3
Evaluate read availability requirements during a regional outage.
The company requires read operations to continue from the secondary region without waiting for a failover to be initiated. GZRS requires a manual or customer-managed failover to make the secondary region active, whereas RA-GZRS provides a read-only endpoint in the secondary region that is immediately available for reads.
Immediate read access during regional failover without intervention requires read-access enabled geo-redundant storage.

Key Concept

Selecting the optimal Azure storage redundancy tier based on zonal availability, regional disaster recovery, and read-access requirements.
Question 937Question

A utility provider is designing an analytical solution to monitor power grid telemetry. The solution must process daily load profile data stored as Apache Parquet files in Azure Data Lake Storage Gen2. Data analysts need to run ad-hoc, exploratory queries across these files to identify consumption anomalies. The solution must minimize administrative overhead, avoid persistent compute costs, and ensure that the analytical and underlying storage components survive a primary datacenter outage within the region. Which configuration should you recommend?

Show answer & explanation

Answer: Azure Synapse serverless SQL pool querying files in a Zone-Redundant Storage (ZRS) Azure Data Lake Storage Gen2 account using Microsoft Entra ID authentication

Answer

The configuration using an Azure Synapse serverless SQL pool to query files in a Zone-Redundant Storage (ZRS) Azure Data Lake Storage Gen2 account using Microsoft Entra ID authentication.
The correct configuration uses an Azure Synapse serverless SQL pool to query the Parquet files in a Zone-Redundant Storage (ZRS) Azure Data Lake Storage Gen2 account. Serverless SQL pools require zero setup and charge only for the data processed, which eliminates persistent compute costs and minimizes administrative overhead. Zone-Redundant Storage replicates data across three separate physical datacenters within the region, ensuring survival of a primary datacenter outage.

Step-by-Step Solution

1
Identify the analytical query model needed.
Since the query requirement is ad-hoc, exploratory, and must minimize persistent compute costs and overhead, a serverless SQL pool is preferred over a dedicated SQL pool.
Serverless SQL pools scale automatically and charge only per query, whereas dedicated SQL pools incur continuous hosting costs.
2
Determine the storage redundancy model.
To survive a primary datacenter outage within the region, Zone-Redundant Storage (ZRS) must be used instead of Locally Redundant Storage (LRS).
ZRS replicates data across three separate Availability Zones within the region, while LRS replicates only within a single datacenter.
3
Evaluate authentication and security.
Using Microsoft Entra ID authentication is secure, whereas using a long-lived SAS token without a stored access policy introduces security risks and management issues.
Entra ID integrates identity governance, while long-lived SAS tokens on the URI are difficult to rotate or revoke.

Key Concept

Selecting the appropriate analytical query engine and storage redundancy model based on cost, management overhead, and resilience requirements.
Estimated Time:1m 30s
Question 938Question

An agricultural technology company hosts an IoT crop telemetry application on Azure virtual machines in the West US 2 region. The application architecture consists of:

- `vm-app01`: An application tier virtual machine with a total write churn of 4 MB/s4\text{ MB/s} on a single disk.
- `vm-db01`: A SQL Server database tier virtual machine with a database data disk experiencing a write churn of 12 MB/s12\text{ MB/s} and a transaction log disk experiencing a continuous write churn of 32 MB/s32\text{ MB/s}.

You need to design a disaster recovery (DR) solution to the East US region that meets the following requirements:
- A Recovery Time Objective (RTO) of 1 hour1\text{ hour} for the entire application.
- A Recovery Point Objective (RPO) of less than 10 seconds10\text{ seconds} for the database tier.
- Minimize replication costs and administrative complexity.

Which disaster recovery strategy should you recommend?

Show answer & explanation

Answer: Replicate `vm-app01` using Azure Site Recovery. Configure SQL Server Always On Availability Groups to replicate the database to a SQL Server instance running on a virtual machine in the East US region.

Answer

Replicating the application virtual machine using Azure Site Recovery and configuring SQL Server Always On Availability Groups to replicate the database to a virtual machine in the target region.
The correct strategy is to replicate the application VM using Azure Site Recovery and configure SQL Server Always On Availability Groups for the database VM. The application VM's write churn of 4 MB/s4\text{ MB/s} is well within Azure Site Recovery's limits. However, the database VM has a transaction log disk with 32 MB/s32\text{ MB/s} of write churn, which exceeds the standard Azure Site Recovery limit of 10 MB/s10\text{ MB/s} per disk. Moreover, Azure Site Recovery replicates asynchronously with crash-consistent recovery points typically in minutes, which cannot satisfy the strict database Recovery Point Objective (RPO) of less than 10 seconds10\text{ seconds}. SQL Server Always On Availability Groups in asynchronous-commit mode provides near-real-time replication that can easily achieve the sub-10-second RPO while bypassing the disk-level write churn limitations of Azure Site Recovery.

Step-by-Step Solution

1
Analyze the RPO and write churn metrics for the database tier to determine suitability for Azure Site Recovery.
The database VM has a transaction log disk with a write churn of 32 MB/s32\text{ MB/s}, which exceeds the standard Azure Site Recovery limit of 10 MB/s10\text{ MB/s} per disk. In addition, the required RPO is less than 10 seconds10\text{ seconds}, which is lower than the typical RPO of Azure Site Recovery (minutes).
Identifying these constraints prevents replication failures and ensures that the disaster recovery design meets the system's performance and data loss requirements.
2
Determine the appropriate replication method for the database VM.
Native SQL Server replication, such as SQL Server Always On Availability Groups in asynchronous-commit mode, is selected for the database VM.
SQL Server Always On Availability Groups bypasses Azure Site Recovery storage-level churn limits and provides near-real-time asynchronous replication capable of meeting the sub-10-second RPO.
3
Determine the replication method for the application VM (vm-app01).
Azure Site Recovery is selected to replicate the application VM to the target region.
The application VM's write churn of 4 MB/s4\text{ MB/s} is well within standard Azure Site Recovery limits, and Azure Site Recovery easily meets the 1 hour1\text{ hour} Recovery Time Objective (RTO) for the application tier.

Key Concept

Azure Site Recovery disk-level write churn limits and selection of native database replication for low-RPO workloads.
Estimated Time:2m 0s
Question 939Question

A retail company hosts a customer order processing system on Azure virtual machines in the East US region. The disaster recovery (DR) solution must replicate workloads to the West US region. The application architecture consists of:

- `vm-orderapp`: An application server with an OS disk and a data disk (both Premium SSD v1). The data disk experiences a write churn rate of 12 MB/s12\text{ MB/s}.
- `vm-orderdb`: A SQL Server database server with an OS disk and a data disk (both Premium SSD v1). The database transaction log data disk experiences a continuous write churn rate of 62 MB/s62\text{ MB/s}.

The company requires a Recovery Point Objective (RPO) of 2 hours2\text{ hours} for the application tier and 10 seconds10\text{ seconds} for the database tier, with a Recovery Time Objective (RTO) of 1 hour1\text{ hour} for the entire solution.

Which two actions should you include in the disaster recovery design? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Replicate vm-orderapp to the West US region using Azure Site Recovery.; Configure SQL Server Always On Availability Groups to replicate the database from vm-orderdb to a SQL Server instance in the West US region.

Answer

To meet the design requirements, you must replicate the application server (vm-orderapp) using Azure Site Recovery and configure SQL Server Always On Availability Groups to replicate the database from the database server (vm-orderdb) to the target region.
Replicating the application server using Azure Site Recovery is correct because its disk write churn is within the 54 MB/s54\text{ MB/s} threshold for Premium SSD v1, and the 2 hour2\text{ hour} RPO is fully supported. Implementing SQL Server Always On Availability Groups is correct because the database server's disk write churn of 62 MB/s62\text{ MB/s} exceeds the maximum per-disk limit of ASR, and ASR cannot guarantee the required 10 second10\text{ second} RPO.

Step-by-Step Solution

1
Analyze the write churn rates against Azure Site Recovery limits.
The application server's write churn (12 MB/s12\text{ MB/s}) is below the 54 MB/s54\text{ MB/s} limit per Premium SSD v1 disk. The database server's write churn (62 MB/s62\text{ MB/s}) exceeds the 54 MB/s54\text{ MB/s} per-disk limit.
Azure Site Recovery enforces a hard limit of 54 MB/s54\text{ MB/s} write churn per Premium SSD v1 disk for replication.
2
Evaluate replication capability for the recovery objectives.
The 2 hour2\text{ hour} RPO for the application tier is fully supported by Azure Site Recovery. The 10 second10\text{ second} RPO for the database tier cannot be guaranteed by ASR, which replicates asynchronously with typical recovery points in minutes.
Database tier replication requires a native replication technique such as SQL Server Always On Availability Groups to achieve sub-minute RPO and handle high churn.
3
Select the appropriate hybrid replication strategy.
Map the application server to Azure Site Recovery and the database server to SQL Server Always On Availability Groups.
This configuration ensures all technical limits are respected and both RPO and RTO requirements are met.

Key Concept

Replication limits and capability constraints in Azure Site Recovery vs. native application/database replication.
Estimated Time:2m 0s
Question 940Question

A healthcare analytics company is designing the Azure compute and storage infrastructure for a new real-time patient health tracking application. The architecture must satisfy the following requirements:
- The analytics engine runs steady-state, 24/7, and processes highly sensitive health records. It must protect data in use via hardware-based memory encryption.
- The compute layer must automatically scale out to handle peak loads.
- The compute infrastructure must achieve a 99.99% availability Service Level Agreement (SLA).
- The database engine stores transaction logs that require high IOPS and sub-millisecond write latency.

Which virtual machine configuration and storage architecture should you recommend?

Show answer & explanation

Answer: A Virtual Machine Scale Set utilizing DCasv5-series Virtual Machines deployed across three Availability Zones, with Premium SSD v2 disks for database transaction logs.

Answer

A Virtual Machine Scale Set utilizing DCasv5-series Virtual Machines deployed across three Availability Zones, with Premium SSD v2 disks for database transaction logs.
The correct option combines a Virtual Machine Scale Set (VMSS) with confidential computing (DCasv5-series) for hardware-based memory encryption. Distributing these VMs across three Availability Zones ensures a 99.99% SLA. Utilizing Premium SSD v2 satisfies the sub-millisecond write latency and high IOPS required for database transaction logs.

Step-by-Step Solution

1
Analyze security requirements for memory encryption.
Identify that confidential computing (DC-series, such as DCasv5) is required to provide hardware-based virtualization and memory encryption for sensitive data in use.
Standard virtual machines do not encrypt data in memory during processing.
2
Analyze availability requirements for SLA.
Select a multi-zone deployment strategy across at least two (ideally three) Availability Zones to qualify for the 99.99% Virtual Machine SLA.
Single Availability Zone deployments only guarantee up to a 99.9% SLA.
3
Determine compute orchestration and scaling requirements.
Select Virtual Machine Scale Sets (VMSS) to support automatic scaling rules.
Individual virtual machines require manual scaling configuration and do not group instances uniformly out-of-the-box.
4
Select storage tier for database transaction logs.
Choose Premium SSD v2 to achieve sub-millisecond write latency and support high IOPS.
Standard HDD disks are slow, high-latency, and unsuitable for database write-intensive workloads.

Key Concept

Designing high-availability confidential compute virtualization solutions with high-performance storage in Azure.
Estimated Time:2m 0s
PreviousPage 47 / 60Next
All practice questions — Microsoft Azure Solutions Architect (AZ-305) | Examkin