Tüm alıştırma soruları

972 soru

Soru 201Soru

You are developing a C# application using the Azure Cosmos DB .NET SDK v3 to manage document collaboration sessions. The container is configured with a partition key path of `/documentId`. The Azure Cosmos DB account is configured with the default consistency level of Session.

An update to a document is processed by Web App Instance A using the following code:
csharp
ItemResponse<Document> writeResponse = await container.ReplaceItemAsync<Document>(
updatedDocument,
updatedDocument.Id,
new PartitionKey(updatedDocument.DocumentId)
);
string token = writeResponse.Headers.Session;

Immediately after the update, Web App Instance B (which runs on a separate virtual machine and utilizes a different `CosmosClient` instance) needs to read the same document to display the latest updates to the same user.

Which C# code segment should you execute on Web App Instance B to guarantee a read-your-writes consistency guarantee for this operation?

Cevabı ve açıklamayı göster

Cevap: ItemRequestOptions options = new ItemRequestOptions
{
SessionToken = token
};
ItemResponse<Document> readResponse = await container.ReadItemAsync<Document>(
documentId,
new PartitionKey(documentId),
options
);

Cevap

Configure ItemRequestOptions with the SessionToken property set to the session token retrieved from the write response, and pass this along with the document ID and partition key to the ReadItemAsync call.
The correct option explicitly passes the session token from the write operation of Web App Instance A to the read operation on Web App Instance B, establishing session consistency across different client instances.

Adım Adım Çözüm

1
Retrieve the session token from the header of the write response on Web App Instance A.
The token is stored in a variable, enabling it to be sent to another client session.
Since session consistency is client-scoped, the session token is required to extend consistency guarantees across distinct CosmosClient instances.
2
Construct ItemRequestOptions on Web App Instance B and assign the session token to the SessionToken property.
An options object containing the correct session token is initialized.
This tells the SDK to execute the read request with the context of the write session token.
3
Call ReadItemAsync passing the document ID, the correct partition key (documentId), and the request options.
The read operation executes successfully, returning the updated document.
Passing the correct partition key is mandatory for item operations in Cosmos DB, and the request options apply the session token context.

Anahtar Kavram

Azure Cosmos DB Session Consistency across distinct client instances
Soru 202Soru

You are deploying an Azure Container App named `task-processor` using a Bicep template. The container app needs to scale dynamically based on the number of messages in an Azure Storage Queue named `taskqueue` located in a storage account named `tasksstorage`.

You have created a user-assigned managed identity named `worker-identity` and granted it the Storage Queue Data Reader role on the storage account.

The identity block in your Bicep template is configured as follows:

bicep
identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${workerIdentity.id}': {}
}
}

You need to configure the custom scale rule in the Bicep template to use the user-assigned managed identity for authenticating against the queue.

Which of the following configuration snippets must you use inside the custom scale rule?

Cevabı ve açıklamayı göster

Cevap: custom: {
type: 'azure-queue'
metadata: {
queueName: 'taskqueue'
accountName: 'tasksstorage'
queueLength: '5'
}
auth: [
{
triggerParameter: 'connection'
identity: workerIdentity.id
}
]
}

Cevap

The configuration that sets identity to the resource ID of the user-assigned managed identity (workerIdentity.id) and maps it to the connection trigger parameter.
The correct configuration correctly maps the connection trigger parameter to the resource ID of the user-assigned managed identity (workerIdentity.id). This allows the Container Apps runtime to authenticate the KEDA scaler with the target Azure Storage Queue using the assigned user-assigned identity.

Adım Adım Çözüm

1
Identify the authentication mechanism required for the Azure Container App scale rule.
Managed identity authentication is required to access the Azure Storage Queue.
The scenario specifies using the user-assigned managed identity instead of storage connection strings or secrets.
2
Determine the parameter mapping for the KEDA azure-queue scaler when using managed identity.
The metadata must include 'accountName' and the auth array must map 'triggerParameter: connection' to the identity.
When using managed identity, KEDA connects using the storage account name and utilizes the identity mapped to the connection parameter.
3
Identify the correct way to reference the user-assigned managed identity in the Bicep template's scale rule.
The identity property in the scale rule auth block must be set to the resource ID of the user-assigned managed identity (workerIdentity.id).
Literal strings like 'system', 'UserAssigned', or the resource's short name 'worker-identity' are invalid because the API expects the fully qualified resource ID.

Anahtar Kavram

Configuring KEDA scale rules in Azure Container Apps using user-assigned managed identities.
Soru 203Soru

You are implementing a simple Durable Functions chaining workflow in C# to process a customer order. The workflow consists of an HTTP-triggered client function, an orchestrator function, and two activity functions: `ValidateOrder` and `ProcessPayment`.

Arrange the steps in the correct order of execution, starting from when a client submits an order.

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

Cevabı ve açıklamayı göster

Cevap

The correct sequence begins with the client function receiving the HTTP request and starting the orchestrator. Next, the orchestrator begins execution and calls the ValidateOrder activity. The orchestrator then awaits the activity and goes to sleep while ValidateOrder runs. Finally, the orchestrator wakes up, receives the output, and calls the ProcessPayment activity.
In a Durable Functions workflow, execution begins with the client function starting the orchestrator. The orchestrator runs until it reaches an await statement for an activity, at which point it schedules the activity and goes to sleep. Once the activity completes, the orchestrator is woken up (replayed) to retrieve the result and proceed to the next step in the chain.

Adım Adım Çözüm

1
Trigger the workflow through the client function.
An orchestrator instance is created.
Client functions act as entry points to start orchestrations.
2
Begin orchestrator execution and invoke the first activity.
The ValidateOrder activity is scheduled.
The orchestrator controls the workflow and schedules activities sequentially.
3
Await the scheduled activity.
The orchestrator goes to sleep.
Orchestrators are suspended during active tasks to avoid unnecessary resource consumption.
4
Replay the orchestrator upon activity completion.
The next activity is called.
Azure Durable Functions replay orchestrator functions to resume execution state from history.

Anahtar Kavram

Durable Functions Chaining Execution Lifecycle
Soru 204Soru

You are developing a C# application that uses the Azure.Storage.Blobs SDK (v12) to manage blobs. You need to assign custom metadata to an existing blob to track the department that owns the blob. The metadata key must be 'Department' and the value must be 'Marketing'.

You write the following code:
csharp
BlobClient blobClient = new BlobClient(connectionString, containerName, blobName);
IDictionary<string, string> metadata = new Dictionary<string, string>();
// Code to add the metadata pair
await blobClient.SetMetadataAsync(metadata);

Which code segment should you use to add the metadata key-value pair?

Cevabı ve açıklamayı göster

Cevap: metadata.Add("Department", "Marketing");

Cevap

Add the key-value pair using the key 'Department' directly without the HTTP prefix, as in: metadata.Add("Department", "Marketing");
The correct option correctly uses the dictionary key 'Department' without the HTTP header prefix 'x-ms-meta-'. The Azure Storage SDK automatically prepends the required prefix to the custom metadata keys before sending the request to the Azure Storage API.

Adım Adım Çözüm

1
Identify the SDK method requirements for setting metadata.
The SetMetadataAsync method accepts an IDictionary<string, string> containing user-defined metadata.
To understand what format the SDK expects for dictionary keys.
2
Determine whether the HTTP prefix is required in the SDK dictionary keys.
The Azure Storage SDK (v12) automatically prepends 'x-ms-meta-' to all dictionary keys when constructing the HTTP request.
To avoid duplicating the prefix and causing malformed headers.
3
Select the code segment that defines the key directly.
Using 'Department' directly matches the correct implementation.
This ensures that the final HTTP header sent is 'x-ms-meta-Department' with the value 'Marketing'.

Anahtar Kavram

Azure Blob Metadata SDK Operations
Soru 205Soru

An enterprise application uses an Azure Cosmos DB account distributed across three write regions (East US, West US, and North Europe) with multi-region writes enabled. You need to configure the consistency settings to meet the following requirements:

1. For user profile updates, the application must guarantee that a user always reads their own updates. The web application uses a load balancer, and subsequent requests from the same user may be routed to different web server instances, which must share the session state using the Azure Cosmos DB session token.
2. For a public news feed, the application must minimize read latency and Request Unit (RU) costs while ensuring that readers never see updates out of order.

Which two consistency levels should you select to meet these requirements? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: Session; Consistent Prefix

Cevap

The correct consistency levels are session consistency and consistent prefix consistency.
The correct consistency levels are session consistency and consistent prefix consistency. Session consistency satisfies the profile update requirement because sharing the session token across web servers guarantees that subsequent read operations can see writes from the same session. Consistent prefix satisfies the news feed requirement because it guarantees that reads see writes in chronological order of their commits, and unlike Bounded Staleness, it costs only one Request Unit per read operation.

Adım Adım Çözüm

1
Evaluate consistency level compatibility with the multi-region write configuration.
Strong consistency is ruled out immediately because Azure Cosmos DB does not support Strong consistency on accounts configured with multiple write regions.
Strong consistency requires synchronous replication, which cannot be guaranteed across multiple write regions without introducing severe latency penalties.
2
Identify the consistency level that satisfies the user profile updates requirement.
Session consistency is selected. It provides read-your-own-writes guarantees for a client session, which is preserved across multiple web server instances behind a load balancer by explicitly sharing the session token.
If the session token is not passed, session consistency is scoped only to the individual client instance connection, behaving like eventual consistency across different web servers.
3
Identify the consistency level that satisfies the public news feed requirement.
Consistent Prefix consistency is selected because it guarantees that reads see writes in chronological order of their commits, and it costs only 1 Request Unit (RU) per read.
Eventual consistency does not guarantee order, and Bounded Staleness reads cost 2 RUs, which fails to minimize throughput costs.

Anahtar Kavram

Azure Cosmos DB Consistency Levels, multi-region write limitations, and Request Unit (RU) costs.
Soru 206Soru

A developer is writing a .NET application using the Azure Cosmos DB .NET SDK v3. The target container is configured with a partition key path of `/userId`. Which of the following code snippets should the developer use to retrieve a user profile item where both the item ID and the user ID are "user123"?

Cevabı ve açıklamayı göster

Cevap: await container.ReadItemAsync<UserProfile>("user123", new PartitionKey("user123"));

Cevap

await container.ReadItemAsync<UserProfile>("user123", new PartitionKey("user123"));
The correct code snippet uses the ReadItemAsync method passing both the item ID ("user123") and the PartitionKey object initialized with the partition key value ("user123") which matches the /userId path configuration.

Adım Adım Çözüm

1
Identify the target item ID and its partition key path.
The item ID is "user123" and the partition key path is /userId.
Point reads in Cosmos DB require both the ID and the partition key value of the document.
2
Determine the partition key value for the specific document.
Since the partition key path is /userId and the user ID is "user123", the partition key value is "user123".
The partition key value must be the value stored in the document's partition key field.
3
Select the correct SDK v3 method signature for reading an item.
container.ReadItemAsync<T>(string id, PartitionKey partitionKey)
The .NET SDK v3 requires passing both the item ID and the PartitionKey object containing the partition key value.

Anahtar Kavram

Performing point reads in Azure Cosmos DB using the .NET SDK v3 requires specifying both the unique item ID and its corresponding PartitionKey value.
Soru 207Soru

A package delivery dispatch system is implemented using Azure Durable Functions. The workflow assigns a driver, waits up to 30 minutes for the driver to accept the assignment via an external event, and dispatches the delivery if accepted. The driver accepts the assignment 10 minutes after it is assigned.

How does the Durable Task Framework execute and replay the orchestrator function to complete this workflow? Order the execution and replay events chronologically from the initial start of the orchestrator to its completion.

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

Cevabı ve açıklamayı göster

Cevap

The correct chronological order of execution and replay events is: first, the orchestrator starts and schedules the AssignDriver activity; second, it restarts, replays, and schedules both the external event and the timer; third, it restarts upon receiving the external event, cancels the timer, and schedules DispatchDelivery; finally, it restarts, replays all events, and completes execution.
The correct sequence mirrors the stateful replay model of Azure Durable Functions. The orchestrator never blocks; instead, it executes sequentially until it encounters an await, at which point it schedules the activity or event, yields, and shuts down. When the scheduled task completes, the orchestrator is awakened, replays the execution history to rebuild the local state, and continues to the next step.

Adım Adım Çözüm

1
Initiate orchestration and schedule the first activity
The AssignDriver activity is queued, and the orchestrator yields control to save resources.
Durable Functions use an asynchronous queue-based model where the orchestrator does not block thread execution while waiting for activities.
2
Replay the first activity and set up concurrent monitoring
The orchestrator replays, retrieves the AssignDriver result, schedules the DriverResponse event and the timer, and yields control.
To wait for either a timeout or an external event, both tasks must be created and monitored concurrently using Task.WhenAny or equivalent.
3
Process external event completion, cancel the timer, and trigger the dispatch
The orchestrator restarts, cancels the active timer, queues the DispatchDelivery activity, and yields control.
Since the driver responded within the limit, the timer task must be cancelled to avoid unnecessary execution, and the next step is scheduled.
4
Replay final steps and close the orchestration
The orchestrator performs a final replay, matches the DispatchDelivery result, and exits successfully.
The orchestrator must run one final time to evaluate the completed DispatchDelivery activity and return the final state.

Anahtar Kavram

Durable Functions execution lifecycle, determinism, and event/timer orchestration
Soru 208Soru

An application running inside an Azure Container Instances (ACI) container group is configured to use a system-assigned managed identity to access an Azure Key Vault. When the application attempts to retrieve a secret, it receives an HTTP 403 Forbidden error. You confirm that the system-assigned managed identity is enabled on the container group. Which action must you perform to resolve the access error?

Cevabı ve açıklamayı göster

Cevap: Configure an access policy or Azure Role-Based Access Control (RBAC) role assignment on the Key Vault that grants 'Get' permission for secrets to the container group's identity.

Cevap

Configure an access policy or Azure Role-Based Access Control (RBAC) role assignment on the Key Vault that grants 'Get' permission for secrets to the container group's identity.
The HTTP 403 Forbidden error indicates that authentication was successful (the container has an identity), but authorization failed because the Key Vault access policies or RBAC roles do not permit the system-assigned managed identity to access the secrets. Granting 'Get' permission to the identity resolves the issue.

Adım Adım Çözüm

1
Identify the authentication mechanism
The ACI container group is authenticated with a system-assigned managed identity.
We must understand how ACI identifies itself before checking authorization.
2
Verify Key Vault authorization settings
The identity exists, but does not have permissions to access the secrets inside the Key Vault.
Authentication is successful but authorization is failing with HTTP 403 Forbidden.
3
Grant the required permissions
Add a Key Vault access policy or Azure RBAC role assignment allowing 'Get' operations for secrets to the container group's managed identity.
This grants the system-assigned identity the required authorization to retrieve the secret.

Anahtar Kavram

Assigning Key Vault permissions to an ACI system-assigned managed identity
Tahmini Süre:1m 30s
Soru 209Soru

A telemetry processing service is hosted on an Azure App Service Web App running on a Standard (S1) App Service plan. The autoscale setting is configured to scale out by 1 instance when the average CPU Percentage is greater than 80% for 10 minutes. The instance limits are set to a minimum of 1, a default of 2, and a maximum of 4 instances. You want to configure the scale-in rule to decrease the instance count by 1 instance when CPU load drops, while preventing autoscale flapping.

Which scale-in threshold for the CPU Percentage metric should you configure to meet this requirement?

Cevabı ve açıklamayı göster

Cevap: Less than 35%

Cevap

Less than 35%
To prevent autoscale flapping, the scale-in threshold must be configured so that the CPU average immediately after a scale-out event does not drop below the scale-in threshold. If we have 2 instances running at 80% CPU (total CPU capacity of 160%) and scale out to 3 instances, the new average CPU drops to 160%/353.3%160\% / 3 \approx 53.3\%. If we have 3 instances running at 80% CPU (total CPU capacity of 240%) and scale out to 4 instances, the new average CPU drops to 240%/4=60%240\% / 4 = 60\%. Therefore, to prevent a scale-in rule from triggering immediately after scaling out, the scale-in threshold must be lower than 53.3%. Choosing a threshold of 35% satisfies this condition.

Adım Adım Çözüm

1
Calculate the total CPU workload at the scale-out threshold of 80% for different instance counts.
For 2 instances, total capacity is 160%160\%. For 3 instances, total capacity is 240%240\%.
This determines the amount of load that will be redistributed when a new instance is added.
2
Calculate the expected average CPU workload per instance immediately after scaling out.
Scaling from 2 to 3 instances drops the average CPU to 160%/353.3%160\% / 3 \approx 53.3\%. Scaling from 3 to 4 instances drops the average CPU to 240%/4=60%240\% / 4 = 60\%.
To prevent flapping, the scale-in threshold must be set below these post-scale-out values.
3
Compare the calculated values with the available threshold options to identify a safe scale-in limit.
The threshold must be strictly less than 53.3%. The option 'Less than 35%' is the only configuration that prevents flapping across all possible transitions.
Selecting a threshold like 55%, 65%, or 75% would cause the post-scale-out CPU load to trigger an immediate scale-in, creating a flapping loop.

Anahtar Kavram

Autoscale rule thresholds must be configured to prevent flapping, which occurs when a scale-out event immediately satisfies the criteria for a scale-in event.
Soru 210Soru

You are configuring a custom domain (api.contoso.com) for a public-facing Azure Container App named inventory-api. You need to ensure the custom domain is validated and secured with an SSL/TLS certificate.

Which sequence of steps must you perform to configure the custom domain and certificate?

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

Cevabı ve açıklamayı göster

Cevap

To configure a custom domain and certificate for an Azure Container App, you must first retrieve the FQDN and verification code from Azure, then configure the CNAME and TXT records at the DNS provider, followed by adding the custom domain to the app to complete validation, and finally creating and binding the SSL/TLS certificate.
The correct order resolves dependencies chronologically. First, the FQDN and validation token are retrieved from the Container App. Second, these values are used to configure CNAME and TXT records at the DNS provider. Third, the domain is added and validated in the Azure Container App. Finally, a certificate is bound to the validated domain.

Adım Adım Çözüm

1
Retrieve the FQDN and verification code from the Container App settings.
The verification token and default domain name are obtained.
These values are required to configure the DNS records at your registrar.
2
Configure CNAME and TXT records at the DNS provider.
DNS records are updated to point to the Container App.
Azure requires public DNS records to prove ownership of the domain before it can be registered.
3
Add the custom domain to the Container App.
The custom domain is validated and registered in the Container App environment.
Validation queries the DNS provider and will fail if the TXT and CNAME records are not present.
4
Create and bind the SSL/TLS certificate.
HTTPS is secured for the custom domain.
You cannot issue or bind a certificate to a domain that is not registered with the Container App.

Anahtar Kavram

Configuring custom domains and TLS certificates for ingress in Azure Container Apps.
Tahmini Süre:2m 0s
Soru 211Soru

A multi-tenant corporate wellness application tracks daily employee physical activity logs in an Azure Cosmos DB API for NoSQL container. The application's workload profile is as follows:
- The platform supports 5,0005,000 corporate clients (tenants), each with up to 20,00020,000 employees.
- Users write multiple activity log entries throughout the day.
- A background process performs transactional batch operations using `TransactionalBatch` to update an employee's daily activity summary item and append new activity log items. These operations must succeed or fail together.
- You must ensure the container scales to handle write ingestion without reaching the 20 GB logical partition limit or creating hot partitions.

Which two actions should you perform to implement a partitioning strategy that meets these requirements? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: Create a synthetic partition key by concatenating the employee ID and the current date (e.g., employeeId_YYYYMMDD) to use as the container's partition key.; Ensure all items updated or created within a single TransactionalBatch use the same concatenated employee ID and date value as their partition key.

Cevap

Create a synthetic partition key combining the employee ID and the current date (e.g., employeeId_YYYYMMDD) to use as the container's partition key, and ensure all items updated or created within a single TransactionalBatch share this partition key value.
To execute operations in a TransactionalBatch, all participating items must share the same logical partition key. A synthetic partition key combining the employee ID and the current date (e.g., employeeId_YYYYMMDD) satisfies this requirement by grouping a single employee's logs for that day in one partition. This avoids hot partitions since writes are distributed across different employees and days, and keeps logical partition sizes well under the 20 GB limit.

Adım Adım Çözüm

1
Analyze transactional requirements for the database operations.
Identified that a TransactionalBatch is required, meaning all items involved in a single daily transaction (the employee's summary and log items) must share the same partition key.
Cosmos DB transactions are scoped to a single logical partition key.
2
Determine the constraints for partition key size and throughput distribution.
Ruled out partition keys with low cardinality (like tenantId) or unbound growth (like employeeId alone over years) to prevent hitting the 20 GB logical partition limit or causing hot partitions.
A single tenant with 20,000 active employees will exceed the 20 GB limit, and highly active employees would eventually exceed it if their historical logs are stored in the same partition.
3
Select a synthetic partition key strategy combining employee identity and a time boundary.
Formulated a synthetic key (employeeId_YYYYMMDD) that groups all of an employee's activities for a single day together, satisfying the transactional boundary while distributing data across many logical partitions over time.
This strategy keeps the logical partitions small and balanced, well under the 20 GB limit, while still supporting the daily transactional batch writes.

Anahtar Kavram

Selecting and configuring synthetic partition keys in Azure Cosmos DB to satisfy transactional boundaries while avoiding size limits and hot partitions.
Tahmini Süre:1m 30s
Soru 212Soru

You have a private Azure Container Registry named registry1 and an Azure Container App named app1. You need to configure app1 to pull images from registry1 using a system-assigned managed identity. The configuration must follow the principle of least privilege. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

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

Cevabı ve açıklamayı göster

Cevap

To configure the container app, first enable the system-assigned managed identity on the container app, then assign the AcrPull role to the container app's system-assigned managed identity on the Azure Container Registry, and finally configure the container app's registry credentials to use the system-assigned managed identity.
To allow a container app to pull images from a private Azure Container Registry using a system-assigned identity, you must first enable the system-assigned identity on the container app resource so that Microsoft Entra ID registers it. Next, you assign the AcrPull role to this identity at the registry's scope to authorize access. Finally, you update the container app's registry configuration to use the system-assigned identity for authentication.

Adım Adım Çözüm

1
Enable the system-assigned managed identity on the container app.
An identity principal is created in Microsoft Entra ID for the container app.
You must create the system identity before you can grant it permissions on other resources.
2
Assign the AcrPull role to the container app's system-assigned managed identity on the Azure Container Registry.
The identity principal is granted read-only pull permissions to the registry.
This grants the minimum access permissions necessary to retrieve container images from the registry.
3
Configure the container app's registry settings to use the system-assigned managed identity.
The container app uses its system-assigned identity to authenticate against the registry URL.
The container app must be explicitly configured to authenticate via the system-assigned identity when referencing the registry.

Anahtar Kavram

Configuring private container registry access for Azure Container Apps using a system-assigned managed identity.
Soru 213Soru

You are developing a web application hosted on an Azure App Service. You need to enable application logging to the file system and view the log messages in real-time using the Azure CLI. Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

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

Cevabı ve açıklamayı göster

Cevap

First, run the az webapp log config command with the --application-logging true parameter. Second, run the az webapp log tail command. Third, navigate to the web application URL to generate HTTP traffic.
To view application logs in real-time, you must first enable file system application logging by running the configure command with the application-logging flag set to true. Once configured, you run the tail command to start the live log stream, and then perform actions in the application to generate log entries.

Adım Adım Çözüm

1
Enable filesystem application logging using Azure CLI
Application logging to the file system is enabled for the Web App
By default, application logging to the file system is disabled. It must be enabled before you can stream logs.
2
Start the log stream session
Real-time log streaming begins in the command line interface
Initiating the tail command starts listening for diagnostic events from the Web App.
3
Browse the web application
Diagnostic trace and log outputs appear live in the terminal
Generating web requests triggers the application execution which produces the log entries to stream.

Anahtar Kavram

Enabling and streaming Web App application logs using Azure CLI
Soru 214Soru

You are developing a secure Azure Function App (V4 runtime). The Function App must retrieve a database connection string from an Azure Key Vault. To comply with security policies, the Function App must use a user-assigned managed identity to resolve Key Vault references.

Arrange the steps in the correct order to configure the Function App to use the user-assigned managed identity for resolving Key Vault references.

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

Cevabı ve açıklamayı göster

Cevap

To configure the Function App to use a user-assigned managed identity for Key Vault references, first create and assign the user-assigned managed identity to the Function App. Next, update the Function App configuration to set this identity as the key vault reference identity. Then, grant this identity the Key Vault Secrets User role on the Key Vault. Finally, add the application setting referencing the Key Vault secret.
To successfully configure a user-assigned managed identity for Key Vault references in Azure Functions, the identity must first be created and assigned to the Function App. Then, the Function App must be configured to use this user-assigned identity for resolving Key Vault references (via the keyVaultReferenceIdentity setting). Next, the identity must be granted read access to the Key Vault (using the Key Vault Secrets User role or access policies). Finally, the reference setting is added to the Function App's configuration.

Adım Adım Çözüm

1
Associate the user-assigned identity with the Function App.
The identity is linked to the Function App resource.
The identity must be associated with the Function App first so it has permission to act on behalf of the application.
2
Configure the Key Vault reference identity setting.
The keyVaultReferenceIdentity configuration of the Function App is set to the identity's resource ID.
By default, Key Vault references use system-assigned identities; you must explicitly override this to use a user-assigned identity.
3
Grant Secret Get access.
The user-assigned identity is authorized to retrieve secrets from the Key Vault.
The identity requires RBAC permissions or an access policy to fetch the secret values.
4
Add the application setting using Key Vault reference syntax.
The connection string setting is configured as a reference to the secret.
The setting is created last to ensure it resolves immediately when the Function App loads the configuration.

Anahtar Kavram

Configuring Azure Functions to use user-assigned managed identities for Key Vault references.
Tahmini Süre:2m 0s
Soru 215Soru

A development team is deploying a web application to Azure App Service named webapp-orders-prod. The application requires a connection string to a database. The connection string is stored in an Azure Key Vault named kv-orders-prod as a secret named DbConnectionString.

A system-assigned managed identity has been enabled for webapp-orders-prod.

The developer configures an application setting named ConnectionStrings:DefaultConnection on the web app with the value:
@Microsoft.KeyVault(SecretUri=https://kv-orders-prod.vault.azure.net/secrets/DbConnectionString)

However, when the application starts, it fails to connect to the database. Upon checking the Azure portal, the Key Vault reference for ConnectionStrings:DefaultConnection shows a status of 'Access Denied'.

Which configuration step must be performed to resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Grant the system-assigned managed identity of the web app the 'Get' secret permission in the Key Vault's access policies or Azure role-based access control (RBAC).

Cevap

Grant the system-assigned managed identity of the web app the 'Get' secret permission in the Key Vault's access policies or Azure role-based access control (RBAC).
The correct answer is to grant the system-assigned managed identity 'Get' permission. For an App Service web app to resolve Key Vault references, it needs read permissions to the Key Vault. Enabling the system-assigned managed identity creates an identity for the web app in Microsoft Entra ID, but you must explicitly authorize it in the Key Vault access policies or via Azure RBAC.

Adım Adım Çözüm

1
Identify the security principal used by the web app.
The web app is configured with a system-assigned managed identity.
App Service uses this identity to authenticate to Key Vault.
2
Configure authorization on the target Azure Key Vault.
Add an access policy or an Azure RBAC role (such as Key Vault Secrets User) for the system-assigned managed identity.
By default, enabling a managed identity does not grant access to data inside Key Vault. The identity must be explicitly authorized to get secrets.

Anahtar Kavram

Configuring Key Vault references in Azure App Service web apps requires both enabling a managed identity on the web app and granting that identity permission to read secrets from the Key Vault.
Soru 216Soru

You need to write a C# application using the Azure.Storage.Blobs SDK (v12) to temporarily lock a blob for exclusive write access. Arrange the following steps in the correct order to acquire a 30-second lease, perform operations, and then clean up the lease resource.

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

Cevabı ve açıklamayı göster

Cevap

First instantiate a BlobClient, then initialize a BlobLeaseClient using GetBlobLeaseClient, next call AcquireAsync to secure the lease, and finally call ReleaseAsync to unlock the blob.
The correct sequence begins with creating the base BlobClient targeting the blob. Next, you must instantiate a BlobLeaseClient by calling the GetBlobLeaseClient extension method on the BlobClient. Once initialized, AcquireAsync is invoked on the lease client to lock the blob. Finally, after performing modifications, ReleaseAsync is called to free the lock.

Adım Adım Çözüm

1
Instantiate the BlobClient.
A BlobClient instance representing the specific blob is obtained.
All blob-level operations require a client targeting the resource.
2
Initialize the BlobLeaseClient.
A BlobLeaseClient bound to the BlobClient is obtained.
Lease operations are handled by the BlobLeaseClient class in Azure.Storage.Blobs (v12).
3
Acquire the lease.
The blob is locked for 30 seconds, returning a lease ID.
The lease must be active before modifying the blob or before releasing it.
4
Release the lease.
The lease is removed and the blob is unlocked.
This unlocks the blob so that other writers are not blocked once the task is completed.

Anahtar Kavram

Acquiring and releasing leases using the Azure.Storage.Blobs SDK (v12) BlobLeaseClient.
Soru 217Soru

You are developing a C# (.NET Isolated process) Durable Function orchestrator named InventoryAuditOrchestrator to coordinate a nightly inventory synchronization workflow. The orchestrator must retrieve a list of store locations, generate a unique audit tracking identifier (GUID) for each location, call an activity function to perform the audit, and record the completion timestamp.

You write the following orchestrator function code:

csharp
[Function("InventoryAuditOrchestrator")]
public static async Task RunOrchestrator(
[OrchestrationTrigger] TaskOrchestrationContext context)
{
var stores = await context.CallActivityAsync<List<string>>("GetStoreLocations", null);
foreach (var store in stores)
{
Guid auditId = Guid.NewGuid();
DateTime auditTime = DateTime.UtcNow;

var auditData = new AuditPayload(store, auditId, auditTime);
await context.CallActivityAsync("RunStoreAudit", auditData);
}
}

During testing, you notice that the workflow fails during execution replay, resulting in mismatched audit identifiers and timestamps across replays.

Which modification must you apply to the orchestrator code to resolve the replay errors and guarantee deterministic execution?

Cevabı ve açıklamayı göster

Cevap: Replace the Guid.NewGuid() call with context.NewGuid() and replace the DateTime.UtcNow call with context.CurrentUtcDateTime.

Cevap

Replace the Guid.NewGuid() call with context.NewGuid() and replace the DateTime.UtcNow call with context.CurrentUtcDateTime.
The correct answer is to replace Guid.NewGuid() with context.NewGuid() and replace DateTime.UtcNow with context.CurrentUtcDateTime. In Azure Durable Functions, the orchestrator function must be deterministic because its state is rebuilt by replaying execution logs. Standard system calls for generating GUIDs or fetching the current time return different values upon each invocation, which causes the orchestration engine to detect a mismatch between the current execution and the recorded history. By using the methods provided on TaskOrchestrationContext, the framework records the generated values in the history database on the first run and replays them consistently on subsequent runs.

Adım Adım Çözüm

1
Analyze the orchestrator's code for non-deterministic behavior.
Identify Guid.NewGuid() and DateTime.UtcNow as non-deterministic API calls.
Durable orchestrator functions must be deterministic because they replay the execution history to rebuild state. Standard system calls like Guid.NewGuid() and DateTime.UtcNow yield different values on every execution, violating this constraint.
2
Evaluate the TaskOrchestrationContext API capabilities for deterministic alternatives.
Identify context.NewGuid() and context.CurrentUtcDateTime.
The Durable Functions SDK provides built-in API replacements for GUID generation and time retrieval that coordinate with the execution history to return the same values during replays.
3
Substitute the non-deterministic system calls with their deterministic SDK equivalents.
The code generates identical tracking identifiers and timestamps during orchestrator replays, preventing execution mismatch errors.
This maintains the integrity of the replay state machine while satisfying the workflow logic.

Anahtar Kavram

Orchestrator determinism requirements and C# isolated worker SDK APIs
Tahmini Süre:2m 0s
Soru 218Soru

You have a web application deployed to an Azure App Service. You want to enable application logging to the local file system to troubleshoot a runtime issue. Which of the following actions should you perform to enable this logging?

Cevabı ve açıklamayı göster

Cevap: Run the az webapp log config command with the --application-logging true parameter.

Cevap

Run the az webapp log config command with the --application-logging true parameter.
Running the az webapp log config command with the --application-logging true parameter is the standard, native method to enable application logs on the local file system using the Azure CLI. This modifies the App Service configuration directly without incurring additional billing or requiring external services.

Adım Adım Çözüm

1
Identify the target diagnostic requirement.
Built-in application logging to the local file system needs to be enabled.
This determines which logging mechanisms and configurations are relevant.
2
Determine the correct command-line parameter.
Use the --application-logging true parameter with the az webapp log config command.
This is the native configuration mechanism for enabling App Service application logs.
3
Differentiate from external monitoring and access permissions.
Exclude Application Insights, Key Vault access policies, and hosting plan scaling.
These services are not dependencies for built-in local file system logging.

Anahtar Kavram

Enabling application logging to the file system in Azure App Service
Tahmini Süre:45s
Soru 219Soru

You are designing an Azure Cosmos DB Core (SQL) API container for a smart home energy monitoring system that tracks electricity usage for 500,000 devices. Each device uploads energy telemetry logs every 10 seconds. The container must support transactional batches to update a device's telemetry log and its current state cache document atomically. Additionally, some high-frequency industrial devices will accumulate more than 20 GB of telemetry data over time. The most frequent read queries will retrieve all telemetry logs for a specific device during a given calendar month.

Which partition key strategy should you implement?

Cevabı ve açıklamayı göster

Cevap: Create a synthetic partition key by concatenating the device ID and the current year and month (e.g., DeviceId_YearMonth).

Cevap

Create a synthetic partition key by concatenating the device ID and the current year and month (e.g., DeviceId_YearMonth).
The correct strategy is to create a synthetic partition key by combining the device ID and the year-month. This satisfies the 20 GB size constraint by splitting the telemetry of any single device into monthly buckets. Because transactional batch operations must target the same partition key, storing the telemetry and state cache document under the same device ID and month allows transactional updates to succeed. Lastly, queries looking for telemetry from a specific device in a specific month will target a single partition, maximizing query efficiency.

Adım Adım Çözüm

1
Analyze storage and partition constraints
Since some industrial devices will generate telemetry exceeding 20 GB, a single device ID cannot be used as the partition key directly.
Azure Cosmos DB logical partitions have a maximum storage limit of 20 GB.
2
Evaluate transactional boundaries
Items modified within a transactional batch must share the same partition key.
Transactional batches cannot span multiple logical partitions.
3
Select a partition key that satisfies all constraints
A synthetic key combining DeviceId and YearMonth satisfies the 20 GB limit, keeps transactional updates in the same partition (occurring at the same time), and ensures the primary query is single-partition.
It groups data logically by device and month, distributing writes across partitions while keeping related monthly records together.

Anahtar Kavram

Selecting and configuring synthetic partition keys in Azure Cosmos DB to handle high-write ingestion, satisfy transactional batch requirements, and avoid exceeding logical partition size limits.
Soru 220Soru

A smart home energy platform collects high-frequency telemetry data from millions of IoT smart meters. Each meter writes power consumption readings every 10 seconds. Each telemetry document contains `deviceId`, `timestamp`, `deviceType` (e.g., Thermostat, SmartPlug), and `powerUsage`.

The solution must meet the following requirements:
- Support a high volume of write ingestions without encountering hot partitions.
- Ensure that all telemetry readings and device state updates for a specific meter on a given day can be executed atomically as a single transaction.
- Prevent individual logical partitions from exceeding the 20 GB size limit as data accumulates over years of operation.
- Optimize queries that retrieve daily consumption metrics for a specific meter.

Which two partition key strategies or configurations should you implement to satisfy these requirements? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: Create a synthetic partition key by concatenating the device ID and the current date (for example, deviceId_YYYY-MM-DD) for telemetry ingestion.; Group the telemetry writes and state updates for a meter on a specific day into a single transactional batch using the synthetic partition key.

Cevap

The correct answer is to use a synthetic partition key combining the device ID and the current date (deviceId_YYYY-MM-DD) and execute database writes in a single transactional batch using that partition key.
A synthetic partition key combining the device ID and the date (e.g., `deviceId_YYYY-MM-DD`) satisfies the 20 GB limit by dividing the data per device into daily segments. Since all items written for a specific meter on a single day share this partition key, they can be modified atomically using a transactional batch.

Adım Adım Çözüm

1
Analyze partition limits.
Using a static device ID as a partition key can cause unbounded growth that eventually exceeds the 20 GB logical partition limit.
Cosmos DB limits logical partitions to 20 GB, so keys with infinite growth per value must be scoped down.
2
Determine transaction scopes.
Transactional batches in Azure Cosmos DB can only target a single logical partition key.
To perform transactions for a device per day, the key must contain both the device ID and the date.
3
Avoid hot partitions.
Low-cardinality attributes like deviceType will concentrate writes onto a few physical partitions, causing rate-limiting.
A synthetic key solves this by distributing writes across many distinct values.

Anahtar Kavram

Designing synthetic partition keys to balance write throughput, logical partition size limits, and transactional boundaries.
ÖncekiSayfa 11 / 49Sonraki
Tüm alıştırma soruları — Microsoft Azure Developer (AZ-204) | Examkin