Microsoft AZ-204

Answering 'Yes' is incorrect because the proposed architecture fails key requirements. Storage Queues cannot reliably guarantee FIFO ordering, so message processing order may not be preserved. A VM is not directly triggered by Storage Queue events without implementing a polling worker or adding an event-driven compute service, and the solution does not implement controls (such as throttling, TTL, or quotas) to prevent the queue from growing beyond 80 GB.

Event Hubs is optimized for high-throughput event streaming (telemetry ingestion) and uses partitions and consumer groups. While multiple consumer groups can read the same stream, it is not the typical pub-sub broker pattern used for business messaging, and consumption is generally pull-based reading from partitions. It’s best for streaming pipelines (Stream Analytics, Spark) rather than push-based pub-sub notifications.

Queue (such as Azure Storage Queues) implements point-to-point messaging with competing consumers: each message is typically processed by a single consumer. It does not provide a native publish-subscribe fan-out model. While queues reduce tight coupling and can reduce polling when used with triggers, they don’t meet the pub-sub requirement where multiple subscribers receive the same message.

Answering 'Yes' is incorrect because it assumes Event Grid can directly receive and manage device telemetry ingestion. Event Grid can filter and route events, but it is not a device ingestion gateway and does not provide the connectivity, authentication, and ingestion semantics typically required for thousands of globally distributed devices. Additionally, filtering on a device identifier only determines routing; it does not inherently provide durable ingestion and correlation/storage organization. IoT Hub or Event Hubs are the services intended for this type of workload, with downstream persistence to Blob storage.

Azure Event Hubs is optimized for high-throughput event streaming and telemetry ingestion (e.g., IoT, logs). It retains events for a configured time window and is consumed via partitions/consumer groups, not competing workers processing discrete tasks. For “store a completed agreement for later processing,” Event Hubs is usually the wrong abstraction unless you’re building a streaming analytics pipeline.

Azure Service Bus topic supports publish/subscribe with multiple subscriptions and advanced messaging features (sessions, transactions, dead-lettering, duplicate detection). It can work for agreement completion events if multiple independent systems must react. However, for simply storing a completed agreement work item for later processing, it’s typically more complex and costly than needed compared to Storage queues.

Azure Event Grid topic is for routing event notifications to handlers (Functions, WebHooks, Service Bus, etc.) with push delivery and event filtering. It’s not intended as a storage mechanism for completed agreements or as a work queue. Event Grid is appropriate when you need to broadcast “agreement completed” to multiple subscribers, but you’d still store the agreement elsewhere and/or enqueue work.

No is incorrect because Blob storage events are specifically designed to notify downstream services quickly when blobs are created or updated. The requirement is only that the process start in less than one minute, not that the entire image transformation complete in that time. A polling or scheduled approach might fail this requirement, but an event-based trigger from Blob storage does meet it.

Answering 'Yes' is incorrect because it overestimates Service Bus as a device telemetry ingestion service. Correlation filters can help route messages to subscriptions, but they do not inherently solve device-scale ingestion requirements such as secure per-device connectivity, throttling patterns, and IoT protocol support. Additionally, the scenario’s emphasis on many stores worldwide and future growth aligns more closely with IoT Hub or Event Hubs, which are designed for high fan-in event ingestion and easy landing to Blob storage (via routing or Capture). Thus, the proposed Service Bus topic approach does not fully satisfy the intended goal.

Answering 'Yes' would imply that Notification Hubs can receive and store device telemetry, but its primary function is outbound push notification delivery, not inbound data collection. Device registration in Notification Hubs is for targeting notifications (tags/templates), not for authenticating devices for telemetry ingestion or correlating incoming data by device ID. It also does not provide direct integration to write incoming device data to Azure Blob Storage. As a result, it does not satisfy the ingestion and storage requirements described.

Answering "Yes" is incorrect because converting the storage account type does not create an event-driven pipeline or guarantee that processing begins within one minute. While Premium BlockBlobStorage can improve blob read/write performance, it does not provide a mechanism to detect uploads and invoke processing logic. The missing component is an event/trigger service (such as Event Grid) and a compute target (such as Azure Functions) to start the processing. As a result, the goal of starting processing quickly is not satisfied by this change alone.

No is incorrect because the proposed design does meet the stated goal in the context of this exam. The requirement is to start processing shortly after upload, and Blob-triggered Azure Functions are specifically intended for that kind of storage-driven automation. Although there can be small trigger latency in real environments, the solution is still considered valid for sub-minute initiation. Therefore rejecting the solution would not align with the expected Azure design pattern.

Event Grid + Azure Functions is good for asynchronous processing and near-real-time reactions to blob events. However, it is not an authoritative transaction log for compliance: delivery is at-least-once, events can be duplicated, and ordering is not guaranteed across all events. Retention is also not inherent; you would need to persist events yourself, and you could still miss events if misconfigured.

Storage Analytics logging (classic) captures request-level logs but is a legacy approach and not optimized for the requirement of an ordered, concise change log specifically for blob and metadata changes. It can be noisy (many operation types), requires parsing, and is not the recommended modern solution for change tracking/auditing compared to Blob Change Feed and Azure Monitor diagnostic settings.

The Azure Monitor HTTP Data Collector API is used to send custom logs into Log Analytics. It does not provide native access to storage transaction history. You would still need a source of truth for blob operations, and scanning request bodies is not a supported or reliable way to reconstruct ordered create/update/delete/copy changes for blobs and metadata.

Azure AD Application Proxy is used to publish on-premises web applications to external users securely via Azure AD (pre-authentication, conditional access). It is a user-to-app remote access solution, not an integration mechanism for Logic Apps connectors to reach on-premises databases or internal systems. It would not typically enable Logic Apps to access on-prem resources like SQL Server or file shares through managed connectors.

A Site-to-Site VPN connects an on-premises network to an Azure VNet, enabling private IP connectivity for many resources. However, standard Logic Apps (Consumption) commonly relies on connector patterns rather than directly routing over your VPN to on-prem endpoints. Unless the scenario explicitly states VNet-integrated Logic Apps/ISE and private routing requirements, S2S VPN is usually not the expected answer for connector-based on-prem access.

Point-to-Site VPN is designed for individual client devices to connect to an Azure VNet (remote user access). It is not intended to provide persistent, scalable connectivity for an on-premises datacenter or to enable server-side services like Logic Apps to reach on-prem resources. For organization-wide hybrid connectivity, S2S VPN or ExpressRoute is used, not P2S.

Azure App Service Environment (ASE) provides an isolated and dedicated environment for hosting Azure App Service resources (Web Apps, API Apps, and some Function App scenarios) inside a VNet. However, it is not the standard mechanism to secure or host Azure Logic Apps. Choosing ASE is a common mistake when candidates equate “secure hosting” with “ASE,” but Logic Apps use ISE for VNet injection.

A VNet service endpoint extends a VNet’s identity to supported Azure PaaS services (such as Azure Storage or Azure SQL) so traffic stays on the Azure backbone and access can be restricted to that VNet. It does not secure the Logic App endpoint itself or place the Logic Apps runtime into a VNet. It’s useful for securing dependencies, not the Logic App hosting plane.

Azure AD B2B integration is used to collaborate with external identities (guest users) and manage access to applications using Azure AD. It addresses authentication/authorization for users, not network isolation or securing the Logic App runtime. While identity controls are important, B2B does not provide the private VNet deployment and traffic control typically implied by “secure the Shipping Logic App.”

Incorrect. Container is not instantiated directly with EndpointUri and PrimaryKey in the Azure Cosmos DB .NET SDK v3+. A Container object is obtained from a CosmosClient (e.g., cosmosClient.GetContainer(databaseId, containerId)). The client handles authentication, connection management, retries, and other request pipeline behaviors, which a Container constructor does not provide in this way.

Incorrect. Database is not created by calling a constructor with EndpointUri and PrimaryKey in the Cosmos DB .NET SDK v3+. You first create a CosmosClient, then get a Database reference (e.g., cosmosClient.GetDatabase(databaseId)) or create it via CreateDatabaseIfNotExistsAsync. Credentials and endpoint configuration belong to CosmosClient, not Database.

Answering "Yes" is incorrect because authenticating a VM to Azure Resource Manager using an X.509 certificate is not the expected VM workload identity pattern. While certificates can be used as credentials for a service principal (app registration), that would require creating and managing an Azure AD application, installing and protecting the private key on the VM, and handling rotation/expiry. In contrast, managed identities allow the VM to obtain tokens via IMDS without storing secrets and then use RBAC assignments scoped to the required resource groups. Therefore, the certificate-based solution is not considered to meet the goal in this context.

Answering Yes is incorrect because assigning the Reader role does not provide an authentication mechanism or a token acquisition method. A VM needs an Azure AD-backed identity (managed identity or service principal) to request an OAuth 2.0 access token, and only then does RBAC determine whether ARM operations are allowed. Reader merely grants read permissions once authenticated; it does not enable token retrieval. As a result, the solution does not satisfy the requirement to obtain an ARM access token.

No is incorrect because the proposed solution is exactly how a VM-based managed identity is intended to request tokens for Azure services. The local managed identity endpoint is designed for workloads running on the Azure resource itself, and PowerShell can call it directly. The only caveat is that the VM must have a managed identity enabled and the identity must have the necessary RBAC permissions, but the token acquisition method itself is correct.

AddRuleAsync adds or updates a subscription rule/filter. A TrueFilter would match all messages, but the prompt already indicates messages are being sent to the subscription (visible in the portal), meaning routing and filtering are not the problem. Adding a rule also doesn’t start message consumption; it only affects which messages are forwarded into the subscription.

This line constructs the SubscriptionClient, which the scenario states you already did (“create and initialize a subscription client object by supplying the correct details”). Instantiation alone does not start receiving messages. You still need to register a handler or implement a receive loop to actually consume messages from the subscription.

CloseAsync shuts down the client and releases network resources. Calling it would stop any receiving and is the opposite of what you need. CloseAsync is used during graceful shutdown after processing is complete, not to initiate message consumption.

Incorrect. Azure AD B2C is designed for customer-facing (external) identity scenarios with social identities and custom user flows. The question describes an internal employee website using Azure AD (workforce tenant). For employees, you typically use Azure AD (Microsoft Entra ID) directly with Conditional Access to require MFA, not B2C.

Incorrect. Azure AD Application Proxy is used to securely publish on-premises applications to be accessed externally through Azure AD. It is not required for an Azure-hosted internal website, and it does not by itself implement MFA. If you used it, MFA would still typically be enforced via Conditional Access, not by Application Proxy alone.

Incorrect. “Baseline policies” are legacy and have largely been replaced by Security Defaults and Conditional Access. Even when available, baseline/security defaults are tenant-wide and not as granular as a dedicated Conditional Access policy for a specific application. The question asks to implement MFA for the website, which is best done with an app-targeted Conditional Access policy.

Telemetry.Context.Cloud.RoleInstance identifies the specific compute instance that emitted the telemetry, such as an App Service instance or VM. This can help diagnose node-specific issues in scaled-out environments, but it does not define or enable dependency tracking for a database call. It is host metadata, not a dependency telemetry property required for representing the dependency itself. Therefore it is not part of the solution here.

Telemetry.Context.Operation.Id is a correlation context property used to associate telemetry items with the broader request or distributed trace. Although correlation is important, this question asks which dependency telemetry properties to use to ensure dependency tracking works for a third-party database. The dependency item itself is primarily defined by fields like Id and Name, while Operation.Id is broader context that is often flowed automatically by the SDK. As a result, it is not the best answer among the given choices.

Telemetry.Context.Session.Id is intended to associate telemetry with a user or client session, most commonly in interactive application scenarios. A server-side Web API dependency call to a database does not rely on session context to be tracked as a dependency. This property does not identify the dependency operation or make it appear correctly in dependency telemetry. Therefore it is unrelated to the requirement.