AZ-204 Practice Questions

The process logically separates infrastructure creation from data migration. First, the existing storage account's configuration is captured by exporting its ARM template. This template is then modified with a new name and the target region.

Next, the deployment process is initiated. This is represented by two granular steps: creating the deployment, which is the action of submitting the template to Azure, and then the template being deployed to provision the new storage account.

Finally, once the new storage account exists, AzCopy is used to perform an efficient, server-side copy of the blob data from the source to the newly created destination account, fulfilling the requirement for a direct data transfer.

Microsoft Docs: Move an Azure Storage account to another region. This document validates the overall procedure.

Reference: The "Prepare and move" section outlines the sequence: Export a template, Modify the template, and Deploy the template. The "Move the data from the source storage account" section recommends using AzCopy.

Microsoft Docs: Tutorial: Create and deploy your first ARM template. This guide explains the relationship between a template and a deployment.

Reference: The tutorial illustrates that a user action creates a deployment resource (Microsoft.Resources/deployments), which then executes the instructions within the template to provision resources.

Microsoft Docs: Copy blobs between Azure storage accounts by using AzCopy v10.

Reference: This document details the azcopy copy command for server-side data transfer between storage accounts, which is the final step in the required process.

The attributes for each property are selected to match the specific search requirements:

• Rating: [IsFilterable, IsSortable, IsFacetable]
• This is required to narrow results (filter and facet) by rating. Making it sortable is also a standard feature for a rating field.
• Cuisines: [IsSearchable, IsFilterable, IsFacetable]
• This enables users to search for cuisines, and also to narrow results by using cuisine as a filter or a facet.
• FamilyFriendly: [IsFilterable, IsFacetable]
• As a boolean value, it's used to narrow results by filtering (e.g., familyFriendly eq true) or faceting (showing counts for 'Yes' and 'No'), not for full-text search.
• location: [IsSearchable, IsFilterable, IsSortable, IsFacetable]
• This meets the requirement to be both searchable and used for narrowing results (filtering and faceting). Making it sortable is a logical addition.
• Description: [IsSearchable]
• This meets the requirement that users must be able to search by description. No other capabilities like filtering or sorting are required for this field.

Microsoft Docs - Create an index in Azure Cognitive Search using the .NET SDK: This document details how to use attributes like IsSearchable, IsFilterable, IsSortable, and IsFacetable to define an index schema from a C# model class. It explains that:

IsSearchable enables full-text search on a field.

IsFilterable allows the field to be used in filter expressions.

IsFacetable allows a field to be used for faceted navigation, which directly supports the "narrow the results" requirement.

(See section: "Define a data model")

Microsoft Docs - Field attributes in the Azure.Search.Documents client library: This reference provides a clear definition for each property attribute used in the Azure Search .NET SDK. It serves as the primary source for understanding the function of each annotation selected in the answer.

The proposed solution does not reliably meet the goal. The standard Azure Blob storage trigger for Azure Functions uses a polling mechanism to detect new blobs. When an Azure Function app runs on the Consumption plan, it can go idle. If a new blob is uploaded while the app is idle, there can be a latency of up to 10 minutes before the function is triggered due to a "cold start." This potential delay exceeds the "less than one minute" requirement. For low-latency scenarios like this, an event-driven approach using an Azure Event Grid trigger is the recommended and more reliable solution, as it provides near-real-time, push-based notifications.

A. Yes: This is incorrect because the Blob storage trigger on the default Consumption plan is not guaranteed to start within one minute due to its polling nature and potential cold-start latency.

1. Microsoft Documentation, "Azure Blob storage trigger for Azure Functions": Under the "Usage" section, it explicitly states: "When you use a Blob storage trigger on a Consumption plan, there can be up to a 10-minute delay in processing new blobs if a function app has gone idle. To avoid this latency, you can switch to an App Service plan with the Always On feature enabled, or you can use an Event Grid trigger."

2. Microsoft Documentation, "Tutorial: Automate resizing uploaded images using Event Grid": This tutorial presents the exact scenario from the question as a primary use case for Event Grid, stating, "This tutorial shows you how to use Event Grid and Azure Functions to resize images that are uploaded to a storage account." This highlights Event Grid as the best practice for this requirement.

3. Microsoft Documentation, "Choose between Blob trigger and Event Grid trigger for blob processing (Azure Functions)": This document compares the two triggers, noting that the Blob trigger is "Simple to set up" but has "Higher latency for blob processing compared to the Event Grid trigger (minutes vs. seconds)." It recommends Event Grid for "Functions that need to process blobs in a timely or 'real-time' manner."

Azure Backup is the correct tool for the Backup and Restore issue. It is the native Azure service specifically designed to back up and protect data in Microsoft Azure, including Azure Virtual Machines. It provides application-consistent backups, flexible restore options (including full VM or individual file restore), and long-term retention policies. While Azure Site Recovery provides disaster recovery by replicating VMs, it is not the primary tool for granular backup and restore operations.

Accelerated Networking is the correct tool to address the Performance issue. This feature enables single root I/O virtualization (SR-IOV) for a VM, which significantly improves networking performance. By allowing the network interface to bypass the host's virtual switch, it reduces latency, jitter, and CPU utilization, which is ideal for high-traffic workloads. Azure Network Watcher is for monitoring and diagnostics, not performance enhancement.

Microsoft Azure Documentation, "About Azure VM backup." This document states, "Azure Backup provides independent and isolated backups to guard against unintended destruction of the data on your original VMs." It details the capabilities of the service for backing up and restoring Azure VMs.

Microsoft Azure Documentation, "Accelerated networking overview." Section: "How does Accelerated Networking work?". This page explains, "Accelerated networking enables single root I/O virtualization (SR-IOV) to a VM, greatly improving its networking performance. This high-performance path bypasses the host from the datapath, reducing latency, jitter, and CPU utilization..."

Microsoft Azure Documentation, "What is Azure Site Recovery?". This document clarifies its purpose: "Azure Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages. Site Recovery replicates workloads running on physical and virtual machines (VMs) from a primary site to a secondary location." This distinguishes it from Azure Backup's primary function.

Deployment: In Kubernetes, a Deployment is the standard resource used to declare and manage the desired state for your application's pods. The container image containing the Azure Function code is specified within the Deployment's template. KEDA monitors and scales the pods managed by this Deployment.

ScaledObject: This is a KEDA-specific Custom Resource Definition (CRD) that defines the scaling rules for a Deployment. It links the event source (like an Azure Storage queue) to the Deployment. The spec of the ScaledObject includes trigger-specific metadata, such as the pollingInterval, which dictates how frequently KEDA should check the event source for messages.

TriggerAuthentication: This KEDA CRD is used to securely manage the authentication credentials needed for a scaler to connect to an external event source. Instead of placing the Azure Storage connection string directly in the ScaledObject, you reference a TriggerAuthentication object, which in turn points to a Kubernetes Secret containing the sensitive connection string. This separates configuration from sensitive data.

KEDA Official Documentation - ScaledObject Specification: This document details the structure of the ScaledObject CRD, explicitly mentioning the pollingInterval property within the spec section as the interval to check triggers.

Source: KEDA Documentation, keda.sh, "ScaledObject Specification".

KEDA Official Documentation - Trigger Authentication: This page explains the purpose of the TriggerAuthentication and ClusterTriggerAuthentication CRDs. It provides examples showing how to configure a TriggerAuthentication object to reference a Kubernetes Secret containing credentials like a connection string (connection).

Source: KEDA Documentation, keda.sh, "Trigger Authentication".

KEDA Official Documentation - Deploying Azure Functions to Kubernetes: This guide shows the complete process, including creating a Deployment YAML file to run the function container, a Secret for the connection string, a TriggerAuthentication to reference the secret, and a ScaledObject to define the scaling logic. This confirms that the application code is managed by a Deployment.

Source: KEDA Documentation, keda.sh, "Samples & Tutorials > Azure Functions".

The API for NoSQL is the correct choice because it is the native Azure Cosmos DB API for storing schema-less data in JSON document format. This model is ideal for "customized items," as it does not require a predefined schema, allowing for flexible data structures.

Session is the correct Consistency level because it is the default setting for new Azure Cosmos DB accounts. In the absence of specific application requirements for data consistency, latency, or throughput, the default level is the most appropriate selection. Session consistency provides a pragmatic balance, offering low latency and high throughput while guaranteeing that a client can read its own writes.

Azure Cosmos DB for NoSQL Documentation (Microsoft Learn):

Reference: Choose an API in Azure Cosmos DB, "Azure Cosmos DB for NoSQL" section.

Content: This official documentation specifies that the API for NoSQL is the native API for storing data as JSON documents, which are schema-agnostic. This directly supports the requirement for saving "customized items."

Link: https://learn.microsoft.com/en-us/azure/cosmos-db/choose-api#api-for-nosql

Azure Cosmos DB Consistency Levels Documentation (Microsoft Learn):

Reference: Tunable data consistency levels in Azure Cosmos DB, "Session consistency" and "Default consistency level" sections.

Content: This document states, "Session is the default consistency level for an Azure Cosmos DB account." It further explains that this level is the most widely used and provides a good balance for applications that need read-your-own-writes guarantees.

Link: https://learn.microsoft.com/en-us/azure/cosmos-db/consistency-levels

The proposed solution, enabling Application Request Routing (ARR), does not meet the stated goals. ARR Affinity (also known as "sticky sessions") is a load-balancing feature in Azure App Service that directs all requests from a single client to the same web app instance. This avoids the need for a distributed session state in simple scale-out scenarios but does not provide a shared storage mechanism. It does not allow session state to be shared across different web applications, nor does it provide a distributed cache for HTML output. The requirements explicitly call for a shared storage mechanism for both session state and output caching, which points to a solution like Azure Cache for Redis, not a request routing feature.

A. Yes: This is incorrect because ARR is a request routing and load-balancing mechanism, not a data storage or caching solution. It cannot fulfill the requirements of sharing session state across applications or caching HTTP responses.

1. Microsoft Docs, Azure App Service, "Configure general settings": Under the "Platform settings" section, the "ARR affinity" setting is described. It states, "If you have a stateless application, we recommend disabling this setting. If you have a stateful application, we recommend enabling this setting. For example, if your application uses session variables, it's stateful." This confirms ARR is about routing for stateful vs. stateless apps, not providing the state store itself.

2. Microsoft Docs, Azure Cache for Redis, "ASP.NET Session State Provider for Azure Cache for Redis": This document explicitly states, "Storing session state in a cache is useful in a web farm because... you are not tying the user session to a single machine." This directly addresses the requirement for a shared state mechanism, which ARR does not provide.

3. Microsoft Docs, Azure Cache for Redis, "ASP.NET Output Cache Provider for Azure Cache for Redis": This document details how to use a distributed cache for storing HTTP responses. It explains, "The output cache provider plugs into the output caching extensibility point... For web applications that run in a web farm, using a distributed cache for the output cache can provide a significant performance benefit." This highlights the correct technology for the output caching requirement.

An Azure Container Apps environment serves as a secure boundary for a group of container apps. By design, all container apps deployed within the same environment share common resources. This includes being deployed into the same virtual network and writing logs to the same configured Log Analytics workspace. Therefore, placing all microservices in a single environment directly satisfies the requirements for shared networking and logging in the most efficient way.

A. Enable multiple revision mode: Revision modes control versioning and traffic splitting for a single container app, not the shared infrastructure for multiple apps.

B. Use a separate environment for each container: This would isolate each microservice into its own virtual network and require separate logging configurations, directly violating the requirements.

C. Enable single revision mode: Like multiple revision mode, this is a setting for an individual container app's update strategy and is irrelevant to shared networking or logging.

D. Use a private container registry image and single image for all containers: The image source is unrelated to networking or logging. Using a single image for all microservices contradicts the microservice architectural pattern.

1. Microsoft Learn, Azure Container Apps environments: "An environment creates a secure boundary around a group of container apps. Container Apps in the same environment are deployed in the same virtual network and write logs to the same Log Analytics workspace." This statement directly confirms that a single environment meets the question's requirements.

Source: Microsoft Docs, "Azure Container Apps environments", Introduction section.

2. Microsoft Learn, Networking architecture in Azure Container Apps: "All container apps in an environment share the same virtual network (VNet)." This document clarifies that the VNet is a property of the environment, shared by all apps within it.

Source: Microsoft Docs, "Networking architecture in Azure Container Apps", Virtual network integration section.

3. Microsoft Learn, Log monitoring in Azure Container Apps: "Azure Container Apps is integrated with Azure Monitor Log Analytics to monitor and analyze your container app's logs. When you create a Container App environment, a Log Analytics workspace is created for you, or you can use an existing one." This shows the one-to-one link between an environment and a Log Analytics workspace.

Source: Microsoft Docs, "Log monitoring in Azure Container Apps", Introduction section.

Configuring a custom domain for an Azure Storage static website without downtime involves a specific sequence of steps to ensure domain ownership is verified before live traffic is routed.

1. Identify the host name of the storage endpoint: The first step is to get the full URL of the static website (e.g., storage1.z13.web.core.windows.net). This URL is the target for the DNS CNAME record.
2. Create a CNAME record asverify.www.contoso.com: To verify domain ownership without impacting the existing www.contoso.com record (and thus avoid downtime), Azure uses an asverify prefix. You create a CNAME record for asverify.www.contoso.com that points to asverify.<storage_endpoint_hostname>. This proves to Azure that you control the contoso.com DNS zone.
3. Set the custom domain name in the storage account: After the verification record is in place, you configure the custom domain www.contoso.com in the Azure Storage account settings. Azure checks for the asverify record to confirm ownership before accepting the configuration.
4. Create the final CNAME record www.contoso.com: Once Azure has verified and registered the custom domain, you create the final CNAME record. This record points www.contoso.com to the storage endpoint hostname identified in the first step. This action routes live user traffic to your static website.

This sequence ensures the storage account is ready to accept traffic from the custom domain before the DNS is updated, preventing any service interruption.

Microsoft Learn: Map a custom domain to an Azure Blob Storage endpoint. The section titled "Register your custom domain name with indirect CNAME validation" details the use of the asverify subdomain in a CNAME record to prove domain ownership to Azure before mapping the final domain. This method is used to prevent downtime.

Microsoft Learn: Tutorial: Map an existing custom DNS name to Azure App Service. In the section "Map a CNAME record", this document describes the standard Azure pattern of using a verification CNAME record (asverify) to validate domain ownership before the actual mapping, which prevents service disruption and dangling DNS entries. Although this document is for App Service, the domain verification principle is the same across Azure services.

Assigning a managed identity to the App Service (App1) creates an identity for it in Azure Active Directory (Azure AD). This identity can then be granted access to the Key Vault (Vault1) via an access policy. The Azure platform automatically manages the credentials (the service principal) for this identity, including rotation. The application code can then use this identity to request an access token from Azure AD to authenticate to Key Vault without needing any secrets or keys stored in the application's code or configuration, fulfilling all requirements of the scenario.

A. Enable App Service authentication for Appt. Assign a custom RBAC role to Vault1.

App Service Authentication (Easy Auth) is for authenticating end-users accessing the web app, not for the app's own identity to access other Azure resources.

B. Add a TLS/SSL binding to App1.

TLS/SSL bindings are used to secure inbound HTTP traffic to the web app from clients. They are not used for authenticating the app to other backend services.

D. Upload a self-signed client certificate to Vault1. Update App1 to use the client certificate.

This method requires manual creation, management, and rotation of the certificate, which contradicts the requirement to "automatically rotate credentials." Managed identities handle this automatically.

1. Microsoft Docs, "What are managed identities for Azure resources?": "Managed identities for Azure resources is a feature of Azure Active Directory. It provides Azure services with an automatically managed identity in Azure AD. You can use the identity to authenticate to any service that supports Azure AD authentication, including Key Vault, without any credentials in your code."

Section: Introduction, "What are managed identities for Azure resources?" paragraph 1.

2. Microsoft Docs, "Tutorial: Use a managed identity to connect Key Vault to an Azure web app": This tutorial explicitly details the process. "This tutorial shows you how to use a managed identity to access Azure Key Vault from an Azure App Service web app... You don't have to store any secrets in your code or configuration."

Section: "Overview" and "Create a managed identity".

3. Microsoft Docs, "Key Vault authentication options": This document compares authentication methods. "For applications deployed on Azure, we recommend using a managed identity... The credentials used by a managed identity are fully managed by the platform and are automatically rotated."

Section: "Managed identity".