Examkin

Tüm alıştırma soruları

972 soru

Tüm türler972Çoktan seçmeli497Çoklu seçim269Eşleştirme9Sıralama171Boşluk doldurma26
Soru 181Soru →

A document collaboration platform stores real-time edit logs in an Azure Cosmos DB Core (SQL) API container. Each log document contains a `logId` (GUID), `documentId` (String), `userId` (String), `timestamp` (DateTime, formatted as `YYYY-MM-DDTHH:mm:ssZ`), and `editType` (String).

The workload exhibits the following characteristics:
- Write profile: High-frequency write operations occur as more than 1000010{}000 users concurrently edit documents during peak business hours.
- Read profile: The platform frequently retrieves edit history for a specific document on a specific day to show revisions.
- Transactional profile: The application executes transactional batches to group and commit multiple edits for the same document on the same calendar day.

You must design a partitioning strategy that avoids hot partitions, supports the transactional consistency requirements, and optimizes query performance.

Which two actions should you perform? (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 `documentId` and the date portion of the `timestamp` in the application code.; Configure the container partition key path to point to the new custom property that holds the concatenated value.

Cevap

Create a synthetic partition key by concatenating the `documentId` and the date portion of the `timestamp` in the application code, and configure the container partition key path to point to the new custom property that holds this concatenated value.
To satisfy the requirement of executing transactional batches, all documents in a batch must share the same partition key value. By concatenating the document identifier and the daily date portion of the timestamp, you create a synthetic partition key that is unique per document per day. This allows all edits for a single document on a given day to be committed together in a single transaction. To apply this, the application must write this concatenated value to a custom property, and the container must be configured to use this custom property as its partition key path.

Adım Adım Çözüm

1
Analyze transactional requirements.
Identified that transactional batches in Azure Cosmos DB require all operations to share the same partition key value.
Azure Cosmos DB does not support multi-partition transactions, so the partition key must encompass the transactional scope (document edits on the same day).
2
Evaluate write workloads and check for hot partitions.
Determined that using a simple key like timestamp or date alone would cause hot partition issues under high write volumes.
A high concentration of writes on the current date or timestamp will route all requests to a single physical partition, resulting in rate limiting.
3
Formulate a synthetic partition key.
Created a concatenated value combining `documentId` and the date portion of the `timestamp` (e.g., `DOC123_2026-07-16`).
This synthetic key distributes writes across different documents (high cardinality) while keeping edits for the same document on the same day in the same partition.

Anahtar Kavram

Synthetic partition keys allow combining multiple properties to distribute write workloads while keeping related data in the same logical partition to support transactions.
Soru 182Soru →

You are developing a .NET application that stores user profiles in an Azure Cosmos DB SQL API container. The container's partition key path is set to `/userId`. You need to write C# code to create a new user profile document using the Cosmos DB .NET SDK v3. Which code segment should you use?

Cevabı ve açıklamayı göster

Cevap: await container.CreateItemAsync<UserProfile>(profile, new PartitionKey(profile.UserId));

Cevap

await container.CreateItemAsync<UserProfile>(profile, new PartitionKey(profile.UserId));
The correct option correctly uses the .NET SDK v3 Container class method CreateItemAsync and provides the profile object along with a PartitionKey instance initialized with the UserId property, which aligns with the container's partition key path /userId.

Adım Adım Çözüm

1
Identify the Cosmos DB SDK version required.
Cosmos DB .NET SDK v3 is required.
The scenario specifies using the .NET SDK v3, which utilizes the CosmosClient and Container classes instead of the legacy DocumentClient.
2
Determine the correct method for creating an item.
Use the CreateItemAsync method on the Container instance.
CreateItemAsync is the standard asynchronous method to insert a new item into a Cosmos DB container in SDK v3.
3
Select the correct partition key configuration matching the container's partition key path.
Pass a new PartitionKey object initialized with profile.UserId.
The partition key path is /userId. Passing a dynamic, high-cardinality value like profile.UserId ensures correct routing and avoids hot partitions.

Anahtar Kavram

Creating items asynchronously in Azure Cosmos DB using the .NET SDK v3 with a partition key.
Soru 183Soru →

A developer needs to deploy an internal microservice as an Azure Container App named payment-processor. The application must meet the following requirements:

- Pull its container image from a private Azure Container Registry (ACR) named acrapps.azurecr.io.
- Authenticate to the ACR using a user-assigned managed identity named aca-pull-identity (the admin user must remain disabled on the ACR).
- Limit ingress so that the microservice is only accessible by other applications running inside the same Container Apps environment.

When writing the Bicep template to deploy the Container App, which two configuration blocks or properties must you include? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: In the identity block at the root level of the Container App resource, set type to 'UserAssigned' and declare the resource ID of aca-pull-identity within the userAssignedIdentities object.; In the properties.configuration.registries array, add an object that specifies the server as 'acrapps.azurecr.io' and sets the identity property to the resource ID of aca-pull-identity.

Cevap

To configure the Container App to pull from the private ACR using a user-assigned managed identity and secure ingress, you must assign the user-assigned managed identity to the Container App resource's identity block and map the ACR server to that identity's resource ID under properties.configuration.registries.
For an Azure Container App to pull an image from a private Azure Container Registry (ACR) using a user-assigned managed identity, two things must occur: the identity must be assigned to the Container App at the resource level (identity block), and the registry configuration must map the ACR server name to the resource ID of that user-assigned identity. Ingress is restricted internally by setting properties.configuration.ingress.external to false.

Adım Adım Çözüm

1
Assign the user-assigned managed identity to the Container App.
The identity is enabled on the resource level, allowing the Container Apps platform control plane to request tokens on its behalf.
A managed identity must be assigned to the resource before it can be referenced in its configuration.
2
Associate the managed identity with the private registry.
The registries array under properties.configuration maps the server to the identity's resource ID.
This instructs Container Apps to authenticate to the specified registry using the assigned user-assigned identity instead of credentials.
3
Configure the ingress to restrict access.
The ingress block under properties.configuration has external set to false.
This disables public endpoint routing, restricting access to only applications in the same Container Apps environment.

Anahtar Kavram

Configuring private registry access and ingress for Azure Container Apps
Soru 184Soru →

An organization has deployed a web app named app-finance to Azure App Service. The application needs to retrieve a database connection string from an Azure Key Vault named kv-prod. The web app is configured to use a system-assigned managed identity, and Key Vault access policies have been configured to allow this identity to read secrets. You need to add an application setting named DbConnectionString to the web app that references the secret DbPassword in the Key Vault. Which value should you set for the DbConnectionString app setting?

Cevabı ve açıklamayı göster

Cevap: @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbPassword)

Cevap

The app setting should be configured with the value @Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbPassword) to resolve the secret from the Key Vault.
The correct format for a Key Vault reference in Azure App Service is `@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>)` or `@Microsoft.KeyVault(VaultName=<vault-name>;SecretName=<secret-name>)`. The option using the `@Microsoft.KeyVault` prefix with the correct `SecretUri` value successfully retrieves the secret.

Adım Adım Çözüm

1
Identify the resource details
The Key Vault is named kv-prod and the secret is named DbPassword, with the corresponding secret URI being https://kv-prod.vault.azure.net/secrets/DbPassword.
This establishes the targets for referencing the Key Vault resource.
2
Select the correct Key Vault reference syntax for App Service
Determine that the syntax requires the prefix @Microsoft.KeyVault with either SecretUri or a semicolon-separated VaultName/SecretName pair.
Correct syntax is required for the App Service runtime to intercept and resolve the reference.
3
Construct the reference string
@Microsoft.KeyVault(SecretUri=https://kv-prod.vault.azure.net/secrets/DbPassword)
Using the SecretUri parameter matches the official syntax precisely.

Anahtar Kavram

Key Vault references in Azure App Service allow an application to access secrets from Key Vault as environment variables without code changes.
Tahmini Süre:1m 30s
Soru 185Soru →

You host a company's internal portal on an Azure App Service Web App that currently runs on a Basic (B1) App Service plan. The portal experiences performance degradation due to sudden CPU utilization spikes during lunchtime. You need to ensure the system automatically increases instances to handle these spikes and scales back down when the load decreases. Which two actions should you perform to implement this scaling configuration?

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

Cevabı ve açıklamayı göster

Cevap: Scale up the App Service plan to the Standard (S1) pricing tier.; Configure an autoscale rule that uses the CPU Percentage metric to adjust the instance count.

Cevap

Scale up the App Service plan to the Standard (S1) pricing tier and configure an autoscale rule that uses the CPU Percentage metric to adjust the instance count.
To support autoscaling, the hosting plan must first be scaled up to at least the Standard (S1) tier. Once on a supported tier, a valid dynamic workload metric, such as CPU Percentage, must be selected to monitor the resource consumption and trigger scaling operations.

Adım Adım Çözüm

1
Evaluate the current App Service plan tier capabilities for scaling.
Identify that the Basic (B1) plan only supports manual scaling and cannot support autoscale rules.
Before configuring rules, the hosting environment must support the autoscale feature.
2
Change the App Service plan pricing tier.
Scale the plan up to the Standard (S1) pricing tier.
Standard (S1) is the entry-level tier that supports autoscale rules.
3
Define the scaling rule metric.
Create a rule based on CPU Percentage to trigger when CPU load spikes.
CPU Percentage is a dynamic load metric that directly corresponds to the performance degradation scenario.

Anahtar Kavram

Azure App Service scaling tiers and autoscale metrics
Soru 186Soru →

You are deploying a new version of a microservice to Azure Container Apps. You want to test the new version by routing 20 percent of the public HTTP traffic to it, while the remaining 80 percent continues to go to the current version. Which two configurations must you apply to the Container App to enable this traffic-splitting behavior?

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

Cevabı ve açıklamayı göster

Cevap: Set the active revisions mode of the Container App to Multiple.; Configure the traffic weight block in the ingress settings to specify the revision names and their respective percentages.

Cevap

To split traffic, the Container App's active revisions mode must be set to Multiple, and traffic weights must be configured in the ingress settings to allocate percentages to specific revisions.
Setting the active revisions mode to Multiple allows multiple versions of the container app to run simultaneously. The ingress configuration's traffic block is where weight percentages are assigned to individual revisions to split incoming traffic. Together, these configurations enable the required traffic-splitting behavior.

Adım Adım Çözüm

1
Change the revisions mode configuration.
The activeRevisionsMode property is set to Multiple, enabling the Container App to run and route traffic to more than one revision at a time.
By default, the revisions mode is Single, which limits traffic to only the newest revision.
2
Configure the ingress traffic weights.
The ingress traffic array is populated with weight distributions (e.g., 20% for the new revision and 80% for the existing revision).
This tells the environment's ingress controller exactly how to route incoming HTTP requests.

Anahtar Kavram

Azure Container Apps Revision Modes and Ingress Traffic Splitting
Tahmini Süre:1m 0s
Soru 187Soru →

You are configuring a new Azure Container App to pull container images from a private Azure Container Registry (ACR). You need to configure a managed identity to authenticate the Container App to the registry. The identity's lifecycle must be managed independently of the Container App resource, and you must follow the principle of least privilege. Which managed identity type and role-based access control (RBAC) role should you use?

Cevabı ve açıklamayı göster

Cevap: A user-assigned managed identity with the AcrPull role

Cevap

A user-assigned managed identity with the AcrPull role
To pull container images from a private Azure Container Registry (ACR), the Azure Container App needs a managed identity that has the AcrPull RBAC role assigned on the ACR. Since the lifecycle of the identity needs to be managed independently of the Container App resource itself (meaning the identity persists even if the Container App is deleted and can be shared among other resources), a user-assigned managed identity must be selected.

Adım Adım Çözüm

1
Determine the correct type of managed identity based on resource lifecycle requirements.
Select a user-assigned managed identity.
The lifecycle of a user-assigned managed identity is independent of any single resource, allowing it to exist before the Container App is deployed and persist after it is deleted.
2
Determine the minimum permission set required for a Container App to pull images from a private registry.
Assign the AcrPull role to the identity at the Azure Container Registry scope.
The AcrPull role is the standard built-in role that permits image pull actions without granting unnecessary push or administration privileges, complying with the principle of least privilege.

Anahtar Kavram

Configuring Azure Container App registry authentication using a user-assigned managed identity and Azure RBAC roles.
Tahmini Süre:45s
Soru 188Soru →

You are designing a globally distributed IoT monitoring solution using Azure Cosmos DB. The account is configured with multi-region writes enabled across East US, West US, and North Europe. The container holding the sensor data was initially partitioned by Region, which resulted in poor write performance and partition rate-limiting. To resolve this, you repartition the container using a high-cardinality key, DeviceId. A stateless analytics service deployed on scaled-out container instances in all three regions reads from the container. Because the instances are stateless and dynamically scaled, they do not share state or Azure Cosmos DB SDK session tokens. The analytics service requires that reads must never see out-of-order writes (writes must be read in the order they were committed). However, the service must also minimize write latency and Request Unit (RU) costs. Which consistency level should you set as the default for the Azure Cosmos DB account to meet these requirements?

Cevabı ve açıklamayı göster

Cevap: Consistent Prefix

Cevap

Consistent Prefix
Consistent Prefix guarantees that reads never see out-of-order writes. Because the analytics service instances are stateless and do not share session tokens, Session consistency falls back to Consistent Prefix-like behavior across different instances. Therefore, Consistent Prefix is the most relaxed consistency level that satisfies the ordering requirements while minimizing latency and Request Unit (RU) costs, and it is fully supported with multi-region writes.

Adım Adım Çözüm

1
Analyze the write configuration of the Cosmos DB account.
The account has multi-region writes enabled.
Strong consistency is not supported with multi-region writes, eliminating Strong consistency from the options.
2
Evaluate the client architecture and session token sharing.
The client instances are stateless and do not share session tokens.
Without session token sharing, Session consistency falls back to Consistent Prefix-like behavior for cross-instance reads and cannot guarantee ordering across the different stateless instances.
3
Evaluate the ordering requirement for reads.
Reads must never see out-of-order writes.
Eventual consistency does not guarantee ordering, so it is eliminated. Consistent Prefix is the most relaxed consistency level that guarantees that reads never see out-of-order writes.
4
Evaluate cost and latency constraints.
Consistent Prefix provides the lowest latency and costs (1 RU per read) compared to Bounded Staleness (which has higher write latency and higher read RU cost under some configurations).
Consistent Prefix satisfies all requirements while minimizing cost and write latency.

Anahtar Kavram

Selecting the optimal Azure Cosmos DB consistency level based on global distribution, write replication constraints, client session token boundaries, and ordering guarantees.
Tahmini Süre:3m 0s
Soru 189Soru →

You are deploying a multi-container group to Azure Container Instances (ACI) using a YAML file. The group contains two containers:
- `app-container`: A web application that pulls its image from a private Azure Container Registry (ACR) named `myregistry.azurecr.io` and retrieves a database connection string from Azure Key Vault at runtime.
- `sidecar-container`: A logging utility that shares a local directory with `app-container` to read its log files.

You must ensure that the container group can authenticate to the private ACR to pull the images, `app-container` can authenticate to Azure Key Vault using a managed identity, and the two containers can share the log directory.

Which three of the following configuration steps or blocks must you include in the YAML configuration or deployment process? (Select THREE)

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

Cevabı ve açıklamayı göster

Cevap: Define a user-assigned managed identity in the root identity block and reference its resource ID under the imageRegistryCredentials block in the YAML file.; Define a volume of type emptyDir in the volumes list at the container group level, and configure volumeMounts in both container definitions pointing to the shared directory.; Assign the Key Vault Secrets User role (or configure a Key Vault access policy with Get permission) for the managed identity to access the Key Vault secrets.

Cevap

To successfully deploy the multi-container group with private ACR image pull, Key Vault authentication, and shared volume access, you must: define a user-assigned managed identity in the root identity block and reference it in the imageRegistryCredentials block; define an emptyDir volume in the volumes list at the container group level and mount it in both containers; and assign Key Vault Secrets User permissions to the managed identity.
The correct configuration requires: defining a user-assigned managed identity in the root identity block and referencing it in the imageRegistryCredentials block because system-assigned identities do not exist during the image pull phase; defining an emptyDir volume at the container group level to share local files between containers; and granting Key Vault Secrets User permissions to the managed identity to allow secret retrieval at runtime.

Adım Adım Çözüm

1
Select the correct identity type for ACR image pulling.
Since system-assigned identities are not created until after the container group is deployed, a user-assigned managed identity must be used. Define the user-assigned identity at the container group level and link it inside the image registry credentials block.
ACI needs a pre-existing identity (user-assigned) to pull container images from a private registry before it can instantiate the container group.
2
Set up shared local storage between the containers.
Define an emptyDir volume at the container group level, and configure volumeMounts in both containers pointing to the shared path.
An emptyDir volume provides a shared, transient directory that is accessible by all containers in the container group and is cleaned up when the group terminates.
3
Grant the managed identity access to Key Vault secrets.
Assign Key Vault Secrets User RBAC role or configure a Key Vault access policy granting Get secret permission to the user-assigned managed identity.
For the application container to retrieve the connection string secret at runtime using the managed identity, the identity must have authorization permissions on the Key Vault.

Anahtar Kavram

Deploying multi-container groups in ACI with private registry access, Key Vault integration, and shared volume storage.
Soru 190Soru →

You are designing an Azure Cosmos DB Core (SQL) API container for an IoT smart grid monitoring system. The system receives telemetry from 1010 electrical substations (`substationId`). Substation 1 is a major hub that handles 90%90\% of the grid's power transmission and has 1,000,0001,000,000 active smart sensors reporting status updates. The other 99 substations have only 1,0001,000 sensors each. During peak periods, the container must ingest up to 100,000100,000 writes per second.

The system has the following requirements:
* Transactional Boundary: For every sensor update, the system must write both a telemetry status document and an associated alarm log document (if a threshold is exceeded) in a single transactional batch. These two documents share the same `sensorId` and `substationId` values.
* Query Profile: The primary read workload consists of real-time control room dashboard queries that retrieve and aggregate telemetry for a specific `substationId` over a rolling 55-minute window.

Which partitioning strategy should you implement to meet these requirements while avoiding hot partitions?

Cevabı ve açıklamayı göster

Cevap: Use a synthetic partition key combining `substationId` and a deterministic hash of the `sensorId` (e.g., `substationId_hashSuffix`).

Cevap

Use a synthetic partition key combining the substation ID and a deterministic hash of the sensor ID.
The correct strategy is to use a synthetic key combining the substation ID with a deterministic hash of the sensor ID. This distributes the massive write load of Substation 1 across a configured number of buckets (e.g., 100 partitions), preventing physical partition write limits from being exceeded. Because the hash is deterministic based on the sensor ID, the telemetry status document and the alarm log document for any given sensor will always resolve to the exact same partition key, preserving the transaction boundary required for transactional batch writes. Additionally, queries filtered by substation ID only need to scan the designated 100 partitions rather than performing a full cross-partition search across the entire database.

Adım Adım Çözüm

1
Analyze the write workload and identify the hot partition risk.
Substation 1 handles 90%90\% of the ingestion load. Partitioning directly by `substationId` will target a single partition for nearly all writes, exceeding the 10,000 RU/s10,000\text{ RU/s} and 20 GB20\text{ GB} physical partition limits.
We must distribute the writes for Substation 1 to prevent throttling and storage limits.
2
Evaluate the transactional boundary constraint.
Cosmos DB transactional batches require all items in the transaction to share the exact same partition key.
Since the status and alarm logs must be written transactionally for a sensor, they must share the same partition key value.
3
Evaluate the read query profile.
Queries target a specific `substationId`. If we partition by `sensorId`, queries by `substationId` must fan out to all physical partitions (millions of sensors), which is highly inefficient.
The partition key must allow routing queries to a small, predictable number of partitions.
4
Synthesize the optimal partition key solution.
A synthetic key combining `substationId` and a deterministic hash of `sensorId` (e.g., `substationId` + `(sensorId % 100)`) splits Substation 1 into 100100 logical partitions to avoid write hotspots. It keeps documents for the same sensor in the same partition for transactional batch operations, and limits read queries to fan out to only 100100 partitions rather than millions.
This strategy balances write distribution, transactional integrity, and query performance.

Anahtar Kavram

Selecting and configuring synthetic partition keys in Azure Cosmos DB to balance write ingestion distribution, transactional scope, and read query efficiency.
Tahmini Süre:3m 0s
Soru 191Soru →

You need to deploy a containerized application to Azure Container Instances (ACI). The container image is stored in a private Azure Container Registry (ACR). You plan to use a user-assigned managed identity to authenticate to the ACR during the container group creation. You will perform the deployment using a YAML configuration file and the Azure CLI. Once the deployment is complete, you must verify the container startup logs to ensure the application initialized correctly.

Which sequence of actions should you perform?

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

Cevabı ve açıklamayı göster

Cevap

To deploy a container group from a private ACR using a user-assigned managed identity, you must first create the identity and assign it the AcrPull role on the registry. Next, retrieve the resource ID of the managed identity. Use this ID to configure the image registry credentials and identity properties inside the YAML definition file. Then, deploy the container group using the az container create command with the --file parameter. Finally, inspect the startup logs using the az container logs command.
The correct order establishes a logical dependency chain. First, the user-assigned identity must be created and granted the AcrPull role on the ACR to authorize image retrieval. Second, its resource ID must be retrieved so it can be embedded in the deployment manifest. Third, the YAML configuration file must be written to specify the identity and credentials. Fourth, the deployment is executed via the Azure CLI using the --file parameter. Finally, after the containers are running, their logs are inspected to verify initialization.

Adım Adım Çözüm

1
Create a user-assigned managed identity and assign it the AcrPull role on the Azure Container Registry (ACR).
A managed identity is provisioned and authorized to pull container images from the registry.
Azure Container Instances requires permission to pull the image from the private registry. Using a user-assigned managed identity is a secure, credential-free method, but it must be created and authorized beforehand.
2
Retrieve the resource ID of the user-assigned managed identity.
You obtain the fully qualified Azure Resource Manager (ARM) ID of the managed identity.
The YAML template configuration requires the exact resource ID of the managed identity to reference it under the identity block and image registry credentials.
3
Author a YAML configuration file that defines the container group, referencing the registry credentials and the managed identity resource ID.
A completed YAML configuration file representing the container group structure and authentication details.
To use a user-assigned managed identity to authenticate to ACR, the relationship must be defined in the YAML file before deployment under the imageRegistryCredentials and identity sections.
4
Deploy the container group by running the az container create command with the --file parameter pointing to the YAML configuration file.
The ACI container group is created and deployed in Azure.
The az container create command applies the YAML configuration to spin up the container group.
5
Verify the deployment and inspect the container startup logs by running the az container logs command.
The stdout/stderr streams of the container are displayed.
Checking the container logs is the final step to confirm the application within the container group started successfully.

Anahtar Kavram

Deploying container groups using YAML and authenticating to ACR using a user-assigned managed identity.
Soru 192Soru →

A developer is deploying a new containerized API to Azure Container Apps. The container image is hosted in a private Azure Container Registry (ACR). Which of the following configurations is required to enable the Container App to pull the image from the private registry?

Cevabı ve açıklamayı göster

Cevap: Configure a managed identity on the Container App and grant it the AcrPull role on the Azure Container Registry.

Cevap

Configure a managed identity on the Container App and grant it the AcrPull role on the Azure Container Registry.
The correct configuration requires assigning a managed identity to the Container App and granting that identity the AcrPull role on the Azure Container Registry. This ensures the Container App has the necessary runtime permissions to authenticate and download the container image securely.

Adım Adım Çözüm

1
Enable a managed identity (system-assigned or user-assigned) on the Azure Container App.
The Container App gets an identity that Azure Active Directory (Azure AD) can authenticate.
The Container App needs a security principal to request access to other Azure resources.
2
Assign the AcrPull role to the Container App's managed identity on the scope of the Azure Container Registry.
The identity is authorized to pull container images from the registry.
Azure Role-Based Access Control (RBAC) enforces that only authorized identities can read private registry images.
3
Configure the Container App registry settings to use the managed identity for authentication.
The Container App pulls the image successfully during deployment.
The Container App environment must know which identity to present when requesting the image from ACR.

Anahtar Kavram

Azure Container App private registry authentication using managed identities
Soru 193Soru →

A cloud architect is designing a performance optimization strategy for a critical REST API hosted on an Azure App Service. The API currently runs on a Basic (B1B1) App Service plan. During seasonal promotions, the API experiences high CPU utilization, and the team wants to implement a dynamic scaling solution. The configuration must automatically add instances when average CPU exceeds 80%80\%, remove instances during low-load periods, and prevent autoscale flapping. Which two actions should be performed to meet these requirements? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: Change the App Service plan pricing tier to Standard (S1S1) or higher.; Ensure the scale-in CPU threshold is less than the scale-out CPU threshold multiplied by the ratio of current instances to post-scale-out instances.

Cevap

Change the App Service plan pricing tier to Standard (S1S1) or higher, and ensure the scale-in CPU threshold is less than the scale-out CPU threshold multiplied by the ratio of current instances to post-scale-out instances.
To enable autoscale rules, the App Service plan must be upgraded to the Standard tier or higher because the Basic tier only supports manual scaling. To prevent autoscale flapping, the scale-in CPU threshold must be set below the expected load drop that occurs when the plan scales out. This drop is calculated by multiplying the scale-out threshold by the ratio of current instances to post-scale-out instances.

Adım Adım Çözüm

1
Identify the minimum pricing tier required for autoscale.
The App Service plan must be upgraded to Standard (S1S1) or higher, as the Basic (B1B1) tier only supports manual scaling.
Autoscale rules cannot be configured on the Basic (B1B1) tier.
2
Analyze the mathematical condition to prevent flapping during scale-in and scale-out events.
The scale-in threshold must be set below the post-scale-out load (Lin<Lout×NcurrentNnewL_{in} < L_{out} \times \frac{N_{current}}{N_{new}}).
If the scale-in threshold is too high, the redistribution of load among the new instances will immediately trigger a scale-in action, leading to a loop of scaling up and down.

Anahtar Kavram

Autoscale rules and tier support in Azure App Service
Soru 194Soru →

An IoT application ingests telemetry data and writes it to an Azure Cosmos DB container configured with a partition key of /DeviceId. Which two of the following statements about performing item operations using the Cosmos DB .NET SDK v3 are correct? (Select TWO).

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

Cevabı ve açıklamayı göster

Cevap: To create a new item, you should call CreateItemAsync<T>(item, new PartitionKey(item.DeviceId)) on the Container instance, passing both the item details and the partition key.; To retrieve a single item efficiently (a point read), you should call ReadItemAsync<T>(id, new PartitionKey(deviceId)) on the Container instance to avoid a cross-partition query.

Cevap

The correct statements are that creating a new item requires calling CreateItemAsync with the item and a PartitionKey, and retrieving a single item efficiently (point read) requires calling ReadItemAsync with the id and PartitionKey.
The .NET SDK v3 Container class provides methods like CreateItemAsync and ReadItemAsync to perform item-level operations. These operations require the item's partition key to be explicitly passed as a parameter (e.g., using new PartitionKey(value)) to ensure they are directed to the correct physical partition, avoiding performance issues or cross-partition queries.

Adım Adım Çözüm

1
Identify the required parameters for creating items in Cosmos DB .NET SDK v3.
CreateItemAsync requires the document object and the partition key (e.g., new PartitionKey(item.DeviceId)).
This ensures the SDK writes the document to the correct logical and physical partition.
2
Identify the required parameters for retrieving a single item (point read).
ReadItemAsync requires the unique ID and the partition key (e.g., new PartitionKey(deviceId)).
Point reads are the most efficient read operation in Cosmos DB because they bypass the query engine and target the specific partition directly.

Anahtar Kavram

Performing item operations using the Cosmos DB .NET SDK v3
Tahmini Süre:1m 30s
Soru 195Soru →

A company is building an image processing system where a user uploads a high-resolution photo, and the system needs to generate three different resized versions (thumbnail, mobile, and desktop) simultaneously. Once all three resizing tasks are finished, a final task must combine them into a single zip archive and notify the user. Which Durable Functions pattern is best suited for this workflow?

Cevabı ve açıklamayı göster

Cevap: Fan-out/fan-in

Cevap

Fan-out/fan-in
The Fan-out/fan-in pattern is the correct choice because the scenario requires executing multiple tasks (generating thumbnail, mobile, and desktop versions) in parallel and then waiting for all of them to complete before performing a final aggregation step (creating a zip archive).

Adım Adım Çözüm

1
Analyze the workflow requirements to identify concurrency.
Three resizing tasks (thumbnail, mobile, and desktop) must run simultaneously (parallel execution).
Identifying parallel tasks helps determine if a fan-out pattern is needed.
2
Analyze the dependency on the parallel tasks.
The final zipping and notification task must wait until all three resizing tasks are completed.
Waiting for multiple parallel tasks to complete before proceeding constitutes a fan-in operation.
3
Match the requirement with the correct Durable Functions pattern.
The combination of parallel execution and aggregation matches the Fan-out/fan-in pattern.
Selecting the correct pattern ensures efficient serverless workflow orchestration.

Anahtar Kavram

Durable Functions Patterns
Soru 196Soru →

You are implementing an Azure Blob Storage lifecycle management policy for a Standard General Purpose v2 (GPv2) storage account to automate data tiering. Which two of the following statements are correct regarding the configuration and execution of these policies? (Select two.)

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

Cevabı ve açıklamayı göster

Cevap: The lifecycle management policy is executed by the Azure Storage service once every 24 hours.; The policy actions, such as tierToCool and delete, are valid operations applied to the baseBlob type.

Cevap

The lifecycle management policy is executed by the Azure Storage service once every 24 hours, and the policy actions, such as tierToCool and delete, are valid operations applied to the baseBlob type.
The lifecycle management policy is executed by the Azure Storage platform once every 24 hours. Furthermore, actions such as tierToCool, tierToArchive, and delete are standard, valid operations that can be defined under the baseBlob node of the policy rule schema.

Adım Adım Çözüm

1
Analyze the execution schedule of Azure Blob Storage lifecycle management policies.
Confirm that lifecycle management runs once daily (every 24 hours) automatically.
This is a platform-managed background process that runs on a daily cycle.
2
Identify valid actions for base blobs (baseBlob) in the policy rules.
Verify that tierToCool, tierToArchive, and delete are supported actions.
The lifecycle rule schema defines these actions for baseBlob to manage the data lifecycle.
3
Evaluate the security and execution requirements of the policy.
Note that native platform policies do not require custom SAS tokens and respect active blob leases.
Security is handled natively by Azure, and active leases block policy executions to prevent accidental data modification or deletion.

Anahtar Kavram

Azure Blob Storage Lifecycle Management execution rules and action schema on Standard GPv2 storage accounts.
Soru 197Soru →

A media streaming application stores user watch history in an Azure Cosmos DB Core (SQL) API container. The database must handle millions of active users who update their viewing progress every 30 seconds. The application must support transactional batch operations to update a user's viewing progress across multiple shows atomically. The most common query retrieves the complete viewing history for a single user to display on their dashboard.

Which partition key should you configure for the container to satisfy these requirements and avoid hot partitions?

Cevabı ve açıklamayı göster

Cevap: userId

Cevap

userId
Selecting the user identifier is the correct choice. It provides high cardinality across millions of users, ensuring that data and throughput requests are evenly distributed across physical partitions. Furthermore, it colocates all viewing history for any single user within the same logical partition. This colocation makes the primary query for a user's dashboard a single-partition query and enables transactional batch operations, which require all involved documents to share the same partition key.

Adım Adım Çözüm

1
Analyze the transactional boundary requirement.
Cosmos DB transactional batch operations are scoped to a single logical partition key. Therefore, the partition key must allow all related items to be updated together under the same key.
This rules out any keys that segment a single user's activities across different partitions, such as a synthetic user-video key.
2
Analyze the throughput and query profile.
Writes occur every 30 seconds per active user, and reads retrieve the complete watch history per user. Partitioning by user identifier groups a user's history into a single logical partition and scales out writes across millions of users.
This prevents hot partitions by using a key with extremely high cardinality.
3
Evaluate distractors for hot partition risks.
Partitioning by video identifier or date concentrates writes on popular media or the current day, creating hot partitions and resulting in rate-limiting.
Choosing a key with low cardinality or highly skewed write traffic violates partitioning best practices.

Anahtar Kavram

Selecting a partition key in Azure Cosmos DB to distribute workload and storage, while supporting transactional boundaries and preventing hot partitions.
Soru 198Soru →

You are deploying an Azure Function App (V4 runtime) that needs to securely access an Azure SQL Database. The database connection string contains sensitive credentials and is stored in Azure Key Vault. You have enabled a system-assigned managed identity for the Function App.

You want to configure the Function App settings to reference the connection string from Key Vault without storing it as cleartext in the app configuration. However, when the Function runs, it fails to connect to the database and logs an authorization error indicating it cannot retrieve the secret from Key Vault.

You inspect the application setting value and find that it is:
`@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/dbconn/f4a5b6)`

Which of the following is the most likely cause of this issue?

Cevabı ve açıklamayı göster

Cevap: The system-assigned managed identity of the Function App has not been granted GET permissions on the Key Vault secrets.

Cevap

The system-assigned managed identity of the Function App has not been granted GET permissions on the Key Vault secrets.
For Key Vault references to resolve correctly at runtime, the managed identity assigned to the Function App must be granted GET permission on secrets in the Key Vault. If this access is missing, the reference resolution fails, leading to authorization errors.

Adım Adım Çözüm

1
Verify that the Key Vault reference syntax in the Function App settings is correct.
The reference syntax `@Microsoft.KeyVault(SecretUri=...)` is correct and follows the required formatting rules.
An incorrect syntax would result in the setting being treated as cleartext rather than a reference, or failing to parse.
2
Check the permissions assigned to the Function App's system-assigned managed identity on the Key Vault.
The system-assigned managed identity exists but lacks 'Get' secret permissions under Key Vault Access Policies or Azure RBAC.
Azure Functions uses the managed identity to authenticate and retrieve the secret at runtime, which requires explicit authorization.
3
Configure the Key Vault access policy or Azure RBAC role assignment.
Assign the 'Key Vault Secrets User' RBAC role or add an Access Policy granting 'Get' permissions to the system-assigned managed identity.
This establishes the necessary permission chain allowing the Function App host to resolve the secret reference successfully.

Anahtar Kavram

Azure Functions Key Vault References and Managed Identities
Tahmini Süre:1m 30s
Soru 199Soru →

A developer is troubleshooting an Azure App Service web app and notices that no application logs are appearing in the Log Stream tool of the Azure Portal, even though the application code contains standard logging statements. The developer has not configured any external storage or monitoring services. What is the most likely cause of this issue?

Cevabı ve açıklamayı göster

Cevap: Application logging to the file system is disabled in the Azure App Service configuration.

Cevap

Application logging to the file system is disabled in the Azure App Service configuration.
Application logging to the file system is disabled by default in Azure App Service. To view real-time logs in the Log Stream tool, developers must explicitly enable application logging to the file system in the settings.

Adım Adım Çözüm

1
Identify the primary mechanism for built-in log streaming in Azure App Service.
The Log Stream tool in the Azure Portal displays stdout/stderr and application logs written directly to the App Service file system.
Understanding where the Log Stream tool reads its source data is necessary to troubleshoot missing logs.
2
Check the default status of filesystem application logging in Azure App Service.
Application logging to the file system is disabled by default for Azure App Service web apps.
Since the developer has not enabled filesystem logging, the application's log statements are not captured by the App Service container host.
3
Determine the required resolution.
Enable 'Application Logging (Filesystem)' under the 'App Service logs' menu in the Azure Portal or via Azure CLI.
Enabling this setting instructs the App Service to capture stdout/stderr or application logs and stream them to the console.

Anahtar Kavram

Enabling application logging to the filesystem is a prerequisite for using the built-in App Service Log Stream.
Soru 200Soru →

A global car rental platform uses an Azure Cosmos DB Core (SQL) API container to store booking reservation documents. Each document contains a unique `bookingId` (GUID), `rentalLocationId` (e.g., `SFO`, `JFK`), `userId`, and a `bookingDate` (formatted as `YYYY-MM-DD`).

The platform has the following operational requirements:
- Throughput & Storage: The system processes millions of bookings per day. The database must scale horizontally without encountering partition size limitations or throughput bottlenecks (hot partitions).
- Transactional Scope: The system must run ACID transactions (via transactional batches or stored procedures) for booking updates that occur on the same day for a specific rental location.
- Read Patterns: A real-time operations dashboard frequently queries active bookings for a specific location on a given day.

Which two partitioning 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: Define a synthetic partition key by concatenating `rentalLocationId` and `bookingDate` (e.g., `SFO_2026-07-16`).; Scope transactional batches to the synthetic partition key value representing the specific rental location and date.

Cevap

Implement a synthetic partition key combining the rental location ID and the booking date, and scope transactional batches to this key.
Defining a synthetic partition key that combines the rental location and booking date satisfies the ACID transactional requirement because Cosmos DB transactional operations are scoped to a single logical partition key value. This approach also limits the logical partition size by daily boundaries, preventing it from exceeding the 20 GB threshold, and supports the dashboard's query pattern without requiring expensive cross-partition scans.

Adım Adım Çözüm

1
Analyze transactional requirements.
Identified that multi-document transactions in Azure Cosmos DB require all target items to have the same partition key value.
This establishes the minimum partition key boundary, which must group documents by location and date.
2
Evaluate scale and logical partition limits.
Determined that partitioning by rental location ID alone will eventually exceed the 20 GB logical partition size limit, while partitioning by booking date alone creates a hot partition for writes on the current day.
Choosing a key with high cardinality and a time component prevents unbounded growth and evenly distributes write throughput.
3
Design a synthetic partition key.
Created a compound key by concatenating the location ID and the date (e.g., SFO_2026-07-16).
This synthetic key guarantees that transactions for a location on a specific day can execute in the same logical partition, daily data remains well below 20 GB, and dashboard queries are highly efficient single-partition reads.

Anahtar Kavram

Selecting and configuring synthetic partition keys in Azure Cosmos DB to satisfy transactional boundaries, size limits, and throughput optimization.
ÖncekiSayfa 10 / 49Sonraki
Tüm alıştırma soruları — Microsoft Azure Developer (AZ-204) | Examkin