Tüm alıştırma soruları

972 soru

Soru 161Soru

You have a Standard General Purpose v2 (GPv2) storage account. You need to implement an Azure Blob Storage lifecycle management policy to automatically move block blobs to the Cool tier after 3030 days have elapsed since their last modification.

Which of the following JSON fragments contains the correct action and property names to achieve this?

Cevabı ve açıklamayı göster

Cevap: "actions": { "baseBlob": { "tierToCool": { "daysAfterModificationGreaterThan": 30 } } }

Cevap

The correct option is the one defining the action as 'tierToCool' and the property as 'daysAfterModificationGreaterThan' set to 3030.
The correct option specifies 'tierToCool' for moving the blob to the Cool tier and uses the correct schema property 'daysAfterModificationGreaterThan' to measure the age of the blob since its last modification.

Adım Adım Çözüm

1
Identify the target storage tier action
The requirement specifies moving the blobs to the Cool tier, which maps to the 'tierToCool' action in the policy schema.
Choosing the correct destination tier ensures compliance with the storage tiering requirements.
2
Identify the correct parameter to track time since modification
The Azure Blob Storage lifecycle policy uses 'daysAfterModificationGreaterThan' to evaluate the age of a blob based on its last modified timestamp.
Using non-standard properties like 'daysAfterLastModified' results in an invalid JSON schema validation error when uploading the policy.
3
Validate casing and syntax
Ensure camelCase is preserved for 'tierToCool' and 'daysAfterModificationGreaterThan'.
Azure Resource Manager (ARM) and Azure Storage APIs enforce strict case-sensitivity on policy actions.

Anahtar Kavram

Azure Blob Storage Lifecycle Management Policy Schema Rules
Tahmini Süre:45s
Soru 162Soru

You are developing a data processing solution using Azure Durable Functions. You need to sequence the execution flow of the application during a standard function chaining scenario. Arrange the actions in the correct chronological order from start to finish.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct chronological sequence is: first, the client function starts the orchestrator instance; second, the orchestrator executes and yields control at the first await statement; third, the activity function runs to completion and saves its result; and finally, the orchestrator wakes up, replays history, and schedules the next activity function.
In Durable Functions, the workflow is initiated by a client function. When the orchestrator executes, it schedules tasks and yields control (goes to sleep) when awaiting asynchronous activities. The activity runs independently and stores its state. Once complete, the orchestrator wakes up and replays the history to reconstruct its state, allowing it to schedule the next step without maintaining an in-memory active state.

Adım Adım Çözüm

1
Trigger the orchestration client.
A new orchestrator instance is created and placed in the queue.
Durable Functions require an orchestrator client to start orchestrations.
2
Run the orchestrator function until the first await point.
The first activity function is scheduled, and the orchestrator goes to sleep.
Orchestrators are designed to yield control when waiting for asynchronous tasks to save cost and resources.
3
Run the activity function on a worker.
The activity task completes, and the result is written to Azure Storage.
Activity functions execute the actual processing work and store their state upon completion.
4
Awaken the orchestrator function.
The orchestrator replays execution history and proceeds to schedule the next step.
Orchestrator functions rebuild state by replaying history when a scheduled task completes.

Anahtar Kavram

Azure Durable Functions Execution Lifecycle and Replay Mechanism
Soru 163Soru

You are a developer configuring an Azure App Service web app to connect to an on-premises Microsoft SQL Server database on port 14331433. You must use Azure Hybrid Connections to establish the connection without opening public inbound firewall ports on the local network.

Arrange the steps in the correct order to configure and establish the Hybrid Connection.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

To establish the Hybrid Connection, you must first create the connection in the Azure Portal, retrieve the gateway connection string, install the Hybrid Connection Manager (HCM) on-premises, paste the connection string into the HCM, and verify the connection status.
The logical sequence begins with defining the cloud endpoint in the Azure Portal to get the authorization credentials (gateway connection string). Next, the local daemon (HCM) is installed on the on-premises network and configured using that connection string to establish the outbound tunnel. Finally, the setup is validated by verifying the connection status.

Adım Adım Çözüm

1
Create the Hybrid Connection in the Azure Portal's Networking section.
Azure provisions the Hybrid Connection and associated Relay namespace.
This establishes the cloud endpoint for the hybrid connection.
2
Copy the gateway connection string from the Azure Portal.
You obtain the connection string required for local agent authentication.
The connection string is needed to authorize the on-premises manager to connect to the Azure Relay.
3
Install the Hybrid Connection Manager (HCM) on the on-premises server.
The HCM software is ready to run locally.
The on-premises agent must be installed on a machine that can reach the local resource.
4
Configure the HCM with the copied gateway connection string.
The HCM connects to the Azure Relay endpoint.
This establishes the outbound tunnel from the on-premises network to Azure.
5
Verify that the connection status is Connected in the portal and HCM.
The web app can now route traffic to the database on port 14331433.
Confirms the tunnel is active and resolving requests.

Anahtar Kavram

Configuring Hybrid Connections for Azure App Service Web Apps to access on-premises resources.
Tahmini Süre:2m 0s
Soru 164Soru

An agricultural technology system uses an Azure Cosmos DB Core (SQL) API container to store telemetry data from 10,00010,000 active IoT soil sensors. The system has the following workload characteristics:

- Sensor telemetry is ingested continuously with high-throughput writes.
- Queries frequently retrieve the telemetry history for a specific sensor over a single day to display daily graphs.
- The container uses stored procedures to perform atomic batch transactions that update daily average readings, requiring all telemetry items for a specific sensor on a specific day to reside in the same logical partition.
- Using either the sensor identifier (`SensorId`) or the date (`ReadingDate`) alone as the partition key would lead to hot partitions.

Which partition key strategy should you implement to satisfy these requirements while optimizing throughput and avoiding hot partitions?

Cevabı ve açıklamayı göster

Cevap: Create a synthetic partition key by concatenating the sensor identifier and the reading date.

Cevap

Create a synthetic partition key by concatenating the sensor identifier and the reading date.
Creating a synthetic partition key by concatenating the sensor identifier and the reading date ensures that writes are distributed across a wide space (10,00010,000 unique combinations per day), preventing hot partition issues. Concurrently, it groups all telemetry items for a specific sensor on a specific day under one partition key, satisfying the single-partition constraint required for stored procedure execution.

Adım Adım Çözüm

1
Identify the transactional boundaries.
Determine that stored procedures are scoped to a single logical partition key, requiring daily sensor telemetry to share the same partition key value.
Stored procedures in Azure Cosmos DB cannot run across multiple logical partitions.
2
Evaluate partitioning cardinality for ingestion scaling.
Recognize that partitioning by date alone causes a hot write partition on the current day, and partitioning by sensor identifier alone concentrates all history for a sensor in one partition.
High write volumes must be distributed across multiple physical partitions to avoid rate limiting.
3
Select a synthetic key strategy.
Combine the sensor identifier and date (e.g., SensorId_ReadingDate) to create a synthetic key.
This guarantees that all records for a specific sensor on a specific day are colocated, while spreading writes across up to 10,000 active partitions daily.

Anahtar Kavram

Azure Cosmos DB synthetic partition keys and transactional scoping
Tahmini Süre:1m 30s
Soru 165Soru

A development team is configuring an Azure Function App (V4 runtime) to connect to a SQL database. The database connection string must be stored securely in Azure Key Vault. The security architecture mandates that the Function App must retrieve the connection string at runtime using a system-assigned managed identity, without storing any credentials in the application's configuration settings.

Which of the following configuration flows must be implemented to ensure the Function App can successfully retrieve the connection string?

Cevabı ve açıklamayı göster

Cevap: Enable the system-assigned managed identity on the Function App, grant this identity the Key Vault Secrets User role on the Key Vault, and set the application setting value to @Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/).

Cevap

Enable the system-assigned managed identity on the Function App, grant this identity the Key Vault Secrets User role on the Key Vault, and set the application setting value to @Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>/).
To securely fetch secrets from Azure Key Vault without storing credentials, you must enable the system-assigned managed identity on the Function App and authorize it in the Key Vault by granting the Key Vault Secrets User role. Additionally, the Key Vault reference in the Application Settings must conform to the strict '@Microsoft.KeyVault(SecretUri=...)' syntax.

Adım Adım Çözüm

1
Enable the system-assigned managed identity on the Azure Function App.
The Function App gets registered in Microsoft Entra ID with a unique principal ID.
This identity represents the Function App instance and is used to authenticate to other Azure services without credentials.
2
Assign the 'Key Vault Secrets User' role (or configure a Key Vault Access Policy with GET permissions) for the Function App's system-assigned identity on the target Key Vault.
The Function App is authorized to read secrets from the Key Vault.
Managed identities do not have access to Key Vault secrets by default; least-privilege access must be explicitly granted.
3
Add a new Application Setting in the Function App configuration with the connection string key, setting the value to the Key Vault reference format @Microsoft.KeyVault(SecretUri=...).
The Functions runtime automatically resolves the setting to the secret's value at application startup.
This syntax tells the App Service/Functions infrastructure to retrieve the secret value from Key Vault using the app's identity and inject it as an environment variable.

Anahtar Kavram

Configuring Key Vault references with Managed Identities in Azure Functions
Soru 166Soru

You host a web application on an Azure App Service Web App that currently runs on the Free (F1) App Service plan. You need to configure the web app to automatically scale out when the CPU utilization exceeds 80%80\%. In which order should you perform the configuration steps?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

First, upgrade the App Service plan to the Standard (S1) pricing tier. Second, enable Custom autoscale in the Scale out settings of the App Service plan. Third, add a scale-out rule that increases the instance count when the CPU percentage exceeds 80%80\%.
The correct order requires upgrading the App Service plan to a tier that supports autoscale (Standard S1) before configuring the settings and adding the CPU-based scaling rule.

Adım Adım Çözüm

1
Upgrade the App Service plan to the Standard (S1) pricing tier.
The plan is moved to a tier that supports custom autoscale rules.
The Free (F1) tier does not support autoscale or manual scale-out; a minimum of Standard (S1) is required for metric-based autoscale.
2
Enable Custom autoscale in the Scale out (App Service plan) settings.
The custom autoscale policy editor becomes active, allowing rule configuration.
Autoscale must be enabled and set to custom before specific metric-based rules can be added.
3
Add a scale-out rule with the CPU percentage metric set to trigger an increase in the instance count when it exceeds 80%80\%.
The auto-scaling rule is applied and active.
Once the custom autoscale engine is active, the rule is defined to increase capacity based on the CPU workload.

Anahtar Kavram

Scaling Azure App Service Web Apps requires a compatible pricing tier (Standard or higher) to support Custom autoscale rules.
Soru 167Soru

A company plans to host a web API in Azure Container Instances (ACI). The Docker image for the API is stored in a private Azure Container Registry (ACR). At startup, the API container must download a database connection string from Azure Key Vault. To maintain high security, the solution must meet these criteria: Avoid storing cleartext registry credentials in the ACI deployment template; Authenticate to the private ACR to download the image; Retrieve the connection string from Key Vault without embedding credentials in the application code. Which identity and authentication configuration should be implemented to support this deployment?

Cevabı ve açıklamayı göster

Cevap: Assign a UserAssigned identity to the container group. Grant this identity the AcrPull role on the ACR and Secret Get permissions on the Key Vault. Specify this identity under both the identity block and the image registry credentials of the deployment definition.

Cevap

Assign a UserAssigned identity to the container group. Grant this identity the AcrPull role on the ACR and Secret Get permissions on the Key Vault. Specify this identity under both the identity block and the image registry credentials of the deployment definition.
Assigning a UserAssigned identity to the container group allows ACI to authenticate to the private Azure Container Registry (ACR) during the container provisioning phase. Since a SystemAssigned identity is only created after the container group is deployed, it cannot be used to pull the image. By using a UserAssigned identity, ACI can fetch the image securely. The same identity can be granted Get secret permissions in Key Vault, allowing the containerized application to fetch the database connection string at startup without storing credentials.

Adım Adım Çözüm

1
Evaluate identity requirements for private container registry image retrieval during ACI provisioning.
Determine that a UserAssigned identity is required because it exists before container group creation, allowing it to authenticate with ACR to pull the image.
SystemAssigned identities are created dynamically during provisioning, which is too late for the image pulling phase.
2
Determine the authorization requirements for Key Vault secret access.
Conclude that the UserAssigned identity (or another identity) must be granted explicit 'Get' secret permission in the Key Vault.
Network-level access configurations (like VNet firewalls) do not grant access to data plane operations such as reading secrets.
3
Map the identity configuration into the ACI YAML/ARM deployment schema.
Assign the identity in the root 'identity' block and reference its resource ID in the 'imageRegistryCredentials' block.
This links the pre-existing UserAssigned identity to the container registry pull credentials.

Anahtar Kavram

Using UserAssigned identities for ACR image pulling and Key Vault access in Azure Container Instances
Soru 168Soru

An organization deploys an Azure Function App (V4 runtime) on a Consumption plan. The function is triggered by an Azure Storage queue and processes incoming orders by writing them to an on-premises database via a Hybrid Connection. During peak hours, rapid scale-out of the Function App causes too many concurrent database connections, exceeding the database's connection limit. You need to restrict the maximum number of concurrent function app instances to 5 to protect the database, without changing the hosting plan or modifying the function code. Which configuration change should you implement?

Cevabı ve açıklamayı göster

Cevap: Add the application setting WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT with a value of 5 in the Azure Portal.

Cevap

Add the application setting WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT with a value of 5 in the Azure Portal.
The setting WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT limits the maximum number of instances that the scale controller can spin up for a function app on a Consumption or Premium plan. By setting this value to 5, the scaling logic is capped, preventing the function app from spawning more than 5 parallel instances and thereby limiting concurrent database connections.

Adım Adım Çözüm

1
Identify the hosting plan and constraint limitations.
The Function App runs on a Consumption plan, and the hosting plan must not be changed.
This rules out migrating to a Dedicated plan or using standard App Service autoscale rules.
2
Analyze how to control scaling at the instance level vs. the application level.
Configuring batchSize in host.json restricts concurrency per instance but doesn't prevent the scaling controller from spawning new instances under high load.
We must restrict the total number of VM instances scaling out globally, not just concurrency per VM.
3
Identify the correct App Setting for limiting scale-out on dynamic plans.
The setting WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT controls the maximum instance count allowed by the scale controller.
Applying this setting to 5 limits the total function instances to 5, preventing database connection exhaustion.

Anahtar Kavram

Azure Functions scale-out limits on dynamic hosting plans.
Tahmini Süre:1m 30s
Soru 169Soru

You are developing a compliance audit workflow for a legal technology firm using Azure Durable Functions in C# (.NET Isolated process). You write the following orchestrator function to verify a batch of documents against a policy:

csharp
[Function("ComplianceAuditOrchestrator")]
public static async Task<string> Run(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
var request = context.GetInput<AuditRequest>();

using (var client = new HttpClient())
{
var response = await client.GetAsync($"https://api.legalcorp.com/rules/{request.PolicyId}");
if (!response.IsSuccessStatusCode)
{
throw new Exception("Failed to retrieve policy rules.");
}
}

var tasks = new List<Task<bool>>();
foreach (var doc in request.Documents)
{
tasks.Add(context.CallActivityAsync<bool>("ScanDocumentActivity", doc));
}

var results = await Task.WhenAll(tasks);
return results.All(r => r) ? "Passed" : "Failed";
}

During testing in a high-volume staging environment, you notice that the orchestrator behaves non-deterministically, occasionally fails with orchestrator validation errors, and performs redundant HTTP calls to the external policy API.

Which modification should you apply to resolve these issues and ensure the orchestrator is deterministic?

Cevabı ve açıklamayı göster

Cevap: Move the HTTP request logic to a separate activity function and call it using the orchestration context.

Cevap

Move the HTTP request logic to a separate activity function and call it using the orchestration context.
Moving the HTTP request logic to a separate activity function and executing it via the orchestration context is correct. Orchestrator functions in Azure Durable Functions must be deterministic. Direct network calls using classes like HttpClient will execute on every replay, leading to side effects and non-deterministic execution failures. By using an activity function, the Durable Functions runtime records the result of the HTTP call in the orchestration history, returning the cached result during replays without re-executing the call.

Adım Adım Çözüm

1
Analyze the orchestrator code for determinism violations.
Identify that the direct instantiation of HttpClient and the network call to retrieve policy rules are non-deterministic operations.
Durable orchestrator functions replay to rebuild their state. Direct I/O operations will re-execute during replays, which violates determinism.
2
Refactor the non-deterministic operation into an activity function.
Create a new activity function dedicated to performing the HTTP call to retrieve the rules.
Activity functions execute once, and their results are recorded in the orchestration history to be replayed deterministically.
3
Invoke the activity function using the orchestration context.
Replace the inline HttpClient code block in the orchestrator with context.CallActivityAsync.
This registers the task in the execution history, ensuring that replays use the cached result instead of executing another HTTP call.

Anahtar Kavram

Orchestrator determinism requirements in Azure Durable Functions
Soru 170Soru

Match each Azure Cosmos DB consistency level on the left with its corresponding behavior or guarantee on the right.

Soldaki öğeye tıklayın, sonra eşleşen sağdaki öğeye tıklayın

Öğeler

Strong
Session
Bounded Staleness
Eventual

Eşleşmeler

Cevabı ve açıklamayı göster

Cevap

Strong consistency matches with synchronous write updates and most recent version reads; Session consistency matches with connection-scoped read-your-writes and is the default setting; Bounded Staleness matches with configuration of staleness thresholds (KK or TT); Eventual consistency matches with no ordering guarantees and lowest latency.
Strong consistency matches with synchronous write replication because it ensures reads always receive the most recent committed state. Session consistency matches with connection-scoped guarantees and is the default level. Bounded Staleness matches with defined thresholds (KK or TT) because it guarantees reads do not lag beyond those limits. Eventual consistency matches with no ordering guarantees and lowest latency because replication is fully asynchronous.

Adım Adım Çözüm

1
Identify the characteristics of Strong consistency.
Strong consistency requires synchronous quorum write agreement, meaning reads always see the absolute latest write.
To match Strong with its definition of absolute consistency at the cost of latency.
2
Identify the characteristics of Session consistency.
Session consistency is the default level and guarantees that within the same session/client connection, the client will read their own writes.
To match Session with its connection-specific guarantees.
3
Identify the characteristics of Bounded Staleness consistency.
Bounded Staleness allows configuration of a staleness window, defined by either maximum versions (KK) or time duration (TT).
To match Bounded Staleness with its defined lag parameter constraints.
4
Identify the characteristics of Eventual consistency.
Eventual consistency has no order guarantees, permitting replicas to catch up out-of-order asynchronously, yielding the lowest latency.
To match Eventual with its weakly consistent, highly performant behaviors.

Anahtar Kavram

Azure Cosmos DB Consistency Levels
Soru 171Soru

To secure database credentials, a company's web application running on an Azure App Service web app must load its connection string from a central Azure Key Vault. The developers plan to configure Key Vault references within the app settings.

Which two configuration steps are required to ensure the web app can successfully resolve the references at runtime? (Choose two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Enable a system-assigned managed identity on the web app and grant it Get secrets permission in the Key Vault access policies.; Set the App Setting value to @Microsoft.KeyVault(SecretUri=https://vault-prod.vault.azure.net/secrets/db-conn/).

Cevap

To resolve Key Vault references, you must enable a system-assigned managed identity on the web app and grant it Get secrets permission in the Key Vault, and set the App Setting value to use the correct syntax starting with the @Microsoft.KeyVault prefix.
For an App Service web app to resolve Key Vault secrets at runtime, two conditions must be met: the app must have an identity authorized to access the Key Vault, and the app setting must use the valid syntax. Enabling a system-assigned managed identity on the web app and granting it Get secrets permission in Key Vault satisfies the security requirement. Setting the App Setting value to the exact @Microsoft.KeyVault(SecretUri=...) format satisfies the syntactic requirement.

Adım Adım Çözüm

1
Enable Managed Identity on App Service
The web app gets an identity registered in Microsoft Entra ID.
App Service requires an identity to authenticate to Key Vault without storing credentials in code.
2
Grant Access Policy in Key Vault
The web app's identity is authorized to retrieve secrets.
Without Get permission, the reference resolution will fail with a forbidden status.
3
Configure App Setting with correct syntax
The runtime detects the @Microsoft.KeyVault prefix and fetches the secret value.
Valid formatting is required for the App Service integration to intercept the setting request.

Anahtar Kavram

Key Vault references in App Service allow an application to use Key Vault secrets in app settings without code changes, requiring a managed identity, proper access permissions, and correct URI syntax.
Soru 172Soru

A healthcare organization is designing an Azure Cosmos DB Core (SQL) API container to store real-time telemetry from 100,000100,000 active medical wearables. The system ingests approximately 20,00020,000 write operations per second, with each document containing the fields `deviceId`, `patientId`, `timestamp` (ISO 8601 string format), `hospitalId`, and `vitalMetrics`.

The container must satisfy the following requirements:
- Ingestion & Storage: Prevent hot partitions. While overall writes are balanced, intensive care patients generate 10×10\times more telemetry packets than standard patients.
- Queries: Optimize read queries from clinicians retrieving a patient's telemetry for a single day (e.g., `SELECT * FROM c WHERE c.patientId = 'P-8802' AND c.timestamp STARTSWITH '2026-07-16'`).
- Transactional Scope: Stored procedures must execute transactional batches to atomically update a patient's daily summary document alongside new telemetry entries.

Which two design decisions should you implement to satisfy these requirements? (Select two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Configure the container with a synthetic partition key created by concatenating the patientId and the date portion of the timestamp (for example, patientId_YYYY-MM-DD).; Store both the daily summary documents and the telemetry documents in the same container, using the synthetic partition key value to scope transactional batches.

Cevap

Configure the container with a synthetic partition key created by concatenating the patientId and the date portion of the timestamp (for example, patientId_YYYY-MM-DD), and store both the daily summary documents and the telemetry documents in the same container, using the synthetic partition key value to scope transactional batches.
The correct strategy combines a synthetic partition key with document co-location. Concatenating the patient identifier and the date ensures that all telemetry and summaries for a patient-day reside in the same logical partition. This satisfies the single logical partition requirement for transactional batches while maintaining high key cardinality and avoiding storage-bound hot partitions.

Adım Adım Çözüm

1
Analyze the transactional boundary requirement.
Cosmos DB transactions (stored procedures and transactional batches) are strictly limited to a single logical partition.
This means all documents that need to be updated atomically (the telemetry records and the daily summary document) must share the same partition key value.
2
Evaluate candidate partition keys for cardinality and hot partition risk.
Using the hospital identifier leads to low cardinality and hot partitions. Using the patient identifier alone risks growing too large over time and causing hotspots for high-frequency (intensive care) patients.
Selecting a partition key with low cardinality or unbounded growth violates the physical partition constraints (20 GB20\text{ GB} storage limit and 10,000 RU/s10,000\text{ RU/s} throughput limit).
3
Formulate a synthetic partition key strategy.
Combine the patientId and the date portion of the timestamp (e.g., `patientId_YYYY-MM-DD`).
This limits the data volume per logical partition to a single patient's daily activity, ensures high cardinality across the system, co-locates the daily transactions, and prevents write hotspots from persisting across multiple days.

Anahtar Kavram

Selecting a partition key in Azure Cosmos DB requires balancing transaction boundaries, query patterns, and write scalability. A synthetic partition key combining an entity identifier and a time-based window (like a date string) is a standard pattern to co-locate transactional scope without creating unbounded logical partitions or long-term hot partitions.
Soru 173Soru

You are designing an Azure Cosmos DB Core (SQL) API solution for a smart city traffic management platform. The platform collects real-time vehicle telemetry from 10,00010,000 traffic sensors deployed across 55 major cities.

Workload Profiles:
- Write Ingestion: Highly write-heavy. Each sensor transmits telemetry (including `sensorId`, `cityName`, `timestamp` in `YYYY-MM-DD hh:mm:ss` format, and `vehicleCount`) every 1010 seconds. Write volume peaks heavily during rush hours.
- Read Queries: Real-time traffic control dashboards query the most recent 55 minutes of telemetry data for a specific city to adjust traffic light timings (high-frequency, low-latency reads).
- Transactional Boundary: A stored procedure must run atomically to update both the daily aggregate vehicle count and the latest telemetry record for a specific sensor.

You need to select the partitioning strategy that avoids the hot partition problem for writes, satisfies the transactional requirements, and minimizes Request Unit (RU) consumption for read queries.

Which two strategies should you implement? (Select two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Define a synthetic partition key for the primary container by concatenating the sensorId and the date portion of the timestamp (e.g., sensorId_YYYY-MM-DD).; Use the Azure Cosmos DB Change Feed to replicate telemetry data to a secondary container partitioned by cityName to serve the dashboard queries.

Cevap

The correct strategies are defining a synthetic partition key by concatenating the sensorId and the date portion of the timestamp, and using the Azure Cosmos DB Change Feed to replicate telemetry data to a secondary container partitioned by cityName.
Defining a synthetic partition key by concatenating the sensorId and the date portion of the timestamp ensures that write volume is evenly distributed across a high number of logical partitions, avoiding the hot partition problem. This partition key also scopes daily sensor transactions within a single logical partition, allowing successful execution of atomic stored procedures. Using the Azure Cosmos DB Change Feed to replicate telemetry data to a secondary container partitioned by cityName allows dashboard queries to be processed as efficient single-partition reads, avoiding expensive cross-partition scans.

Adım Adım Çözüm

1
Analyze write ingestion patterns and hot partition risks.
Using cityName or YYYY-MM-DD on the primary container results in hot partitions because writes are concentrated in a few cities during rush hour or on a single daily partition.
Choosing a high-cardinality key is essential to distribute write throughput across multiple physical partitions.
2
Evaluate transactional boundaries.
Since transactions (stored procedures) require atomic updates on both the daily aggregate and the latest telemetry for a specific sensor, the partition key must encompass the sensor ID and the specific day.
Cosmos DB transactions are strictly scoped to a single logical partition.
3
Analyze read query efficiency and optimize container layout.
Dashboard queries filter by cityName, which would result in expensive cross-partition queries on a container partitioned by sensorId. Replicating the data to a secondary container partitioned by cityName via the Change Feed solves this.
Replication enables fast single-partition reads for dashboard queries without compromising the write performance of the primary ingestion container.

Anahtar Kavram

Selecting a partition key involves balancing write distribution (preventing hot partitions), transactional scopes (single-partition boundaries), and read optimization (minimizing cross-partition queries).
Soru 174Soru

You are designing an Azure Cosmos DB Core (SQL) API container for a logistics monitoring system that tracks delivery fleet telemetry. The system receives data from 50,00050,000 active vehicles. Each vehicle is assigned to one of 2020 shipping carriers.

The telemetry documents contain the following fields:
- `vehicleId` (unique string identifier)
- `carrierId` (unique carrier code)
- `routeId` (unique route identifier)
- `timestamp` (date and time of the reading)
- `location` (latitude/longitude coordinates)

The system has the following requirements:
- Writes: Telemetry is ingested continuously at a rate of 5,0005,000 writes per second. Three large shipping carriers account for 85%85\% of all vehicle updates.
- Reads: Active tracking dashboards query vehicle locations for a specific route. These queries always filter by `routeId` and `timestamp`.
- Transactions: When a vehicle crosses a state line, the platform must execute a transactional batch operation to atomically update the vehicle status and insert a route checkpoint log.

Which partition key strategy should you select to meet these requirements while preventing hot partitions and optimizing query performance?

Cevabı ve açıklamayı göster

Cevap: Create a synthetic partition key that combines `routeId` and the date portion of the `timestamp` (for example, `routeId_date`).

Cevap

Create a synthetic partition key that combines routeId and the date portion of timestamp.
The correct answer is correct because creating a synthetic partition key combining the route identifier and the date allows the container to distribute data across multiple partitions over time, avoiding the hot partition issue of using a low-cardinality key like carrier identifier or an unboundedly growing partition like route identifier alone. Furthermore, since transactions are scoped to a route on a specific day, grouping them under the same synthetic partition key satisfies the Cosmos DB constraint that all items in a TransactionalBatch must share the same partition key value.

Adım Adım Çözüm

1
Identify the transactional boundaries of the application.
Recognize that TransactionalBatch requires all participating documents to share the same partition key value.
Cosmos DB transactions are restricted to a single logical partition.
2
Analyze the write throughput skew and cardinality to avoid hot partitions.
Determine that using carrierId (low cardinality, high skew) or routeId alone (unbounded growth over time) will create hot partitions.
A partition key must distribute RU consumption and storage evenly across logical and physical partitions.
3
Combine the transactional scope with the query and partitioning requirements using a synthetic key.
Derive a synthetic key routeId_date (e.g., route_1092_2026-07-16).
This satisfies the transaction scope for a single route on a given day, avoids unbounded partition growth, and supports single-partition read queries.

Anahtar Kavram

Synthetic Partition Keys and Transactional Boundaries in Azure Cosmos DB

Alternatif Yöntem

An alternative approach is to use a hierarchical partition key (available in newer Cosmos DB versions) with `routeId` as the first level and `date` as the second level, which achieves a similar logical structure without manually concatenating strings in client code.
Tahmini Süre:2m 30s
Soru 175Soru

A development team is deploying a containerized microservice to Azure Container Instances (ACI). The containerized microservice must securely connect to a database hosted in an Azure Virtual Network (VNet) without exposing the database to the public internet. The microservice uses a custom Linux-based container image. Which configuration is required to successfully deploy the container group into the Azure Virtual Network?

Cevabı ve açıklamayı göster

Cevap: The target subnet must be delegated to Microsoft.ContainerInstance/containerGroups and must not contain other resource types.

Cevap

The target subnet must be delegated to Microsoft.ContainerInstance/containerGroups and must not contain other resource types.
The correct answer is that the target subnet must be delegated to Microsoft.ContainerInstance/containerGroups and must not contain other resource types. Azure Container Instances requires a dedicated subnet delegated exclusively to ACI for virtual network integration. This subnet cannot be shared with other resource types, such as virtual machines or App Service plans.

Adım Adım Çözüm

1
Identify the requirement for network isolation and virtual network integration for Azure Container Instances.
Confirming that ACI container groups can be deployed directly into an Azure Virtual Network to communicate securely with other resources.
This establishes private network routing and secures the database connection.
2
Determine the subnet constraints and delegation requirements for ACI.
The target subnet must be delegated exclusively to the Microsoft.ContainerInstance/containerGroups resource provider.
Subnet delegation is mandatory for ACI network integration and prevents other resource types from sharing the subnet.

Anahtar Kavram

Azure Container Instances Virtual Network Integration and Subnet Delegation
Tahmini Süre:1m 30s
Soru 176Soru

An organization hosts a web application on an Azure App Service plan that is currently configured for the Basic (B1) pricing tier. You are tasked with configuring the web app to automatically scale out (autoscale) whenever the average CPU usage exceeds 75%75\%.

What must you do first?

Cevabı ve açıklamayı göster

Cevap: Scale up the App Service plan to the Standard (S1) pricing tier or higher.

Cevap

Scale up the App Service plan to the Standard (S1) pricing tier or higher.
The correct answer is to scale up the App Service plan to the Standard (S1) pricing tier or higher. In Azure App Service, autoscaling (scaling out automatically based on rules and metrics like CPU usage) requires at least the Standard pricing tier. The Basic tier only supports manual scaling.

Adım Adım Çözüm

1
Determine if the current pricing tier supports autoscaling.
The Basic (B1) tier only supports manual scaling up to 3 instances; it does not support autoscaling.
Before configuring autoscale rules, the App Service plan must be in a tier that supports autoscale.
2
Identify the minimum pricing tier required for autoscale.
The Standard (S1) pricing tier is the minimum tier that supports autoscale capabilities.
Scaling up to the Standard tier enables Azure Monitor autoscaling features.
3
Select the correct action to enable the requirement.
Scale up the App Service plan to the Standard (S1) pricing tier or higher.
This enables the option to configure metric-based autoscaling rules.

Anahtar Kavram

Azure App Service pricing tiers and scale-out capabilities
Soru 177Soru

You are developing an Azure Function App (V4 runtime) that processes messages from an Azure Storage Queue. The processing logic for some messages can take up to 15 minutes to complete. The security policy requires that the Queue connection string must be stored securely in Azure Key Vault and must not be exposed in the application source code or settings files.

Which two configurations or actions should you implement to meet these requirements? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Change the hosting plan of the Function App to a Premium or Dedicated (App Service) plan.; Add an application setting in the Function App that references the Key Vault secret using the `@Microsoft.KeyVault(SecretUri=...)` syntax.

Cevap

To meet the requirements, you must change the hosting plan of the Function App to a Premium or Dedicated (App Service) plan, and add an application setting in the Function App that references the Key Vault secret using the `@Microsoft.KeyVault(SecretUri=...)` syntax.
Changing the hosting plan to a Premium or Dedicated plan is necessary because the Consumption plan has a maximum execution limit of 10 minutes, meaning a 15-minute execution would be terminated early. Furthermore, using a Key Vault reference in the Application Settings with the `@Microsoft.KeyVault(SecretUri=...)` syntax is the standard and secure way to inject secrets into the function configuration without exposing them in clear text.

Adım Adım Çözüm

1
Identify the hosting plan requirements based on execution duration.
The execution can take up to 15 minutes. The Consumption plan has a maximum limit of 10 minutes, so a Premium or Dedicated (App Service) plan is required.
Hosting plan limits dictate the maximum execution duration for Azure Functions.
2
Determine the secure method for referencing Key Vault secrets in application configurations.
Add an application setting in the Function App using the `@Microsoft.KeyVault` prefix and pointing to the Secret URI.
Key Vault references in Application Settings permit secure access to secrets at runtime without exposing credentials in code.

Anahtar Kavram

Hosting plans, timeout configurations, and Key Vault integration for Azure Functions.
Soru 178Soru

You are developing a serverless workflow using Azure Durable Functions. You need to ensure that the orchestrator function remains deterministic during execution. Which two actions must you perform to meet this requirement?

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Use the context's current UTC date-time property instead of using standard system date-time calls.; Create durable timers using the orchestration context rather than using thread sleep or task delay methods.

Cevap

To ensure the orchestrator function remains deterministic, you must use the context's current UTC date-time property instead of standard system date-time calls, and create durable timers using the orchestration context rather than thread sleep or task delay methods.
Orchestrator functions in Azure Durable Functions must be deterministic to ensure that replay execution behaves identically. Using the built-in context properties for current UTC date-time and creating durable timers instead of blocking threads ensures that the orchestration state remains consistent across execution replays.

Adım Adım Çözüm

1
Identify the core constraints of Durable Functions orchestrator functions.
Orchestrator functions must be deterministic because they are replayed to rebuild state.
Replay execution requires that the same input always produces the exact same output, with no side effects.
2
Evaluate the options for system date-time, timers, and external variables.
Standard system calls like DateTime.UtcNow and Thread.Sleep or Task.Delay are non-deterministic or block execution, whereas context-provided properties (e.g., CurrentUtcDateTime) and durable timers are safe for replay.
The orchestrator context manages these operations to ensure consistent behavior across replays.

Anahtar Kavram

Orchestrator Function Determinism Constraints
Tahmini Süre:45s
Soru 179Soru

A company hosts a financial processing API on an Azure App Service Web App that currently runs on the Standard (S1) pricing tier with a default instance count of 2. During peak hours, the API experiences high CPU utilization. You are configuring Azure Monitor autoscale rules to handle this load. You create a scale-out rule that increases the instance count by 1 when the average CPU Percentage is greater than 80% for 10 minutes. To prevent autoscale flapping (rapidly alternating between scaling out and scaling in), which of the following scale-in configurations should you implement?

Cevabı ve açıklamayı göster

Cevap: Decrease the instance count by 1 when the average CPU Percentage is less than 40% for 10 minutes.

Cevap

Decrease the instance count by 1 when the average CPU Percentage is less than 40% for 10 minutes.
The correct option correctly prevents flapping by establishing a scale-in threshold (40%) that is lower than the expected CPU per instance immediately after a scale-out event (approximately 54%). This ensures that the system will only scale back in when the overall workload significantly drops.

Adım Adım Çözüm

1
Calculate the total CPU workload at the scale-out threshold.
Total workload = 2 instances×81% CPU=162%2 \text{ instances} \times 81\% \text{ CPU} = 162\% of a single instance's capacity.
To find the post-scale-out CPU utilization, we must first determine the total processing load that will be distributed among the new number of instances.
2
Calculate the expected CPU utilization per instance after scaling out.
Post-scale-out CPU = 162%/3 instances=54%162\% / 3 \text{ instances} = 54\% average CPU per instance.
When scaling out from 2 to 3 instances, the total load of 162% is divided among 3 instances.
3
Identify the threshold to avoid immediate scale-in.
The scale-in threshold must be strictly less than 54%54\%. A value of 40%40\% is appropriate.
If the scale-in threshold is higher than or equal to 54%54\% (such as 60%60\% or 75%75\%), the scale-in rule will trigger immediately after scaling out, causing flapping.

Anahtar Kavram

Autoscale flapping prevention in Azure App Service Plans
Tahmini Süre:2m 0s
Soru 180Soru

You are developing an Azure Function App (V4 runtime) that contains a Service Bus triggered function. The function is configured with a connection property named `TelemetryServiceBus`.

Your company's security policy prohibits the use of secrets or connection strings in application settings. You must configure the Function App to connect to the Azure Service Bus namespace using a user-assigned managed identity that has the client ID `11111111-2222-3333-4444-555555555555`.

Which three application settings must you add to the Function App's configuration to establish this identity-based connection?

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: TelemetryServiceBus__fullyQualifiedNamespace; TelemetryServiceBus__credential; TelemetryServiceBus__clientId

Cevap

TelemetryServiceBus__fullyQualifiedNamespace, TelemetryServiceBus__credential, and TelemetryServiceBus__clientId
To configure a Service Bus trigger with an identity-based connection using a user-assigned managed identity, the Azure Functions runtime requires the setting prefix 'TelemetryServiceBus' followed by double underscores and specific suffixes. The 'fullyQualifiedNamespace' suffix defines the target Service Bus resource. The 'credential' suffix set to 'managedidentity' along with 'clientId' containing the GUID of the user-assigned managed identity are required for the host to successfully authenticate using that specific identity.

Adım Adım Çözüm

1
Identify the prefix for the identity-based connection settings.
The prefix must match the connection property name specified in the function binding, which is 'TelemetryServiceBus'.
Azure Functions V4 uses the connection property name as the prefix followed by double underscores to bind identity-based configuration properties.
2
Configure the namespace property for the connection.
Create the application setting 'TelemetryServiceBus__fullyQualifiedNamespace' pointing to the Service Bus fully qualified domain name.
The namespace location is required so the runtime knows where to locate the Service Bus namespace.
3
Configure the credential type and user-assigned managed identity client ID.
Create 'TelemetryServiceBus__credential' with the value 'managedidentity' and 'TelemetryServiceBus__clientId' with the client ID of the user-assigned identity.
By default, the host assumes a system-assigned managed identity. To use a user-assigned managed identity, 'credential' must be explicitly set to 'managedidentity' and 'clientId' must specify the target identity's client ID.

Anahtar Kavram

Azure Functions Identity-Based Connections
ÖncekiSayfa 9 / 49Sonraki
Tüm alıştırma soruları — Microsoft Azure Developer (AZ-204) | Examkin