AZ-204 Question #237: Real Exam Question with Answer & Explanation

Question

Drag and Drop Question You are a developer for a Software as a Service (SaaS) company. You develop solutions that provide the ability to send notifications by using Azure Notification Hubs. You need to create sample code that customers can use as a reference for how to send raw notifications to Windows Push Notification Services (WNS) devices. The sample code must not use external packages. How should you complete the code segment? To answer, drag the appropriate code segments to the correct locations. Each code segment may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content. NOTE: Each correct selection is worth one point. Answer:

Explanation

Explanation: Azure Notification Hubs — Raw WNS Notifications

This question tests knowledge of sending raw push notifications to Windows devices via Azure Notification Hubs using the Azure Instance Metadata Service (IMDS) for authentication. No external packages means using built-in .NET HTTP classes.

Placement 1: http://169.254.169.254/metadata/identity/oauth2/token

Purpose: This is the Azure Instance Metadata Service (IMDS) endpoint used to acquire a Managed Identity (MSI) access token from within an Azure VM or App Service.

Why this URL:

• 169.254.169.254 is the reserved link-local address that Azure exposes IMDS on — it is only reachable from within Azure-hosted resources.
• /metadata/identity/oauth2/token is the correct path for MSI token acquisition.
• The localhost variants are wrong — IMDS is not on localhost.
• 169.254.169.254.50342 is malformed; port 50342 was briefly used in a legacy preview of MSI but is no longer correct.

Common mistake: Confusing this with the older port-50342 format or thinking localhost hosts the token endpoint.

Placement 2: windows

Purpose: This identifies the target platform/channel for the notification hub registration.

Why windows:

• WNS (Windows Push Notification Services) is the push channel for Windows 10/11 Store apps. In Azure Notification Hubs, this platform is registered under the identifier windows.
• windowsphone targets legacy Windows Phone devices (deprecated) and is a separate channel entirely — not WNS.

Common mistake: Assuming windowsphone includes modern Windows devices. WNS is strictly windows.

Placement 3: raw

Purpose: Specifies the WNS notification type via the X-WNS-Type header value, which becomes wns/raw.

Why raw:

• WNS supports four notification types: wns/toast, wns/tile, wns/badge, and wns/raw.
• The question explicitly asks for raw notifications — background data payloads delivered to an app without displaying UI to the user.
• raw is the only type that delivers arbitrary binary/data payloads rather than XML-based UI updates.

Common mistake: Selecting windows here again — windows is the platform, not the notification format.

Placement 4: application/octet-stream

Purpose: Sets the Content-Type HTTP header for the notification payload.

Why application/octet-stream:

• WNS raw notifications carry arbitrary binary data, so application/octet-stream is the required content type per Microsoft's WNS documentation.
• application/xml is used for toast, tile, and badge notifications (which have structured XML payloads).
• application/json is not a valid WNS content type.

Common mistake: Using application/xml — that is correct for visual notifications (toast/tile/badge), not raw.

Summary Table

No community discussion yet for this question.