Which HTTP Header Enables Microsoft Graph Evolvable Enumerations?

AZ-204 By islever Editorial Last updated

Implement user authentication and authorization

Short answer

D Use the Prefer request header so Microsoft Graph GET responses return unknown members of evolvable enumerations.

Question

You are developing a Microsoft Entra ID integrated app that interacts with Microsoft Graph. You must allow GET operations to receive unknown members that might be defined in the future in Microsoft Graph API. You plan to include support for evolvable enumerations in the app. You need to specify the HTTP request header that will provide the evolvable enumerations support in the app. Which header should you specify?
  1. Accept
  2. Content-Type
  3. If-Match
  4. Prefer Correct Answer

Key Takeaways

It tests whether you know that Microsoft Graph future/unknown enum members are requested via the Prefer header — the trap is confusing opt-in preferences with content negotiation (Accept) or body metadata (Content-Type).

Microsoft Graph evolvable enumerations let an API add new enum members later without breaking clients, and clients opt in to receive those unknown members with a specific HTTP request header. This page establishes that the required header is Prefer, not Accept, Content-Type, or If-Match.

Common mistake: Most candidates pick Accept, because Accept feels like the header that says 'here is what my client can handle' — but Accept negotiates response media types (for example application/json), while evolvable enumeration opt-in is expressed as a preference with Prefer.

Expert Analysis

Why the Answer Is Correct

Evolvable enumerations in Microsoft Graph were designed so that a service can add new members to an enumeration in the future without breaking existing clients — but the client must explicitly ask to see those members it does not yet know about. That opt-in is expressed as an HTTP preference, so the header is Prefer, typically with a value such as include-unknown-enum-members on the GET request. The question states you must allow GET operations to receive unknown members that might be defined in the future in Microsoft Graph, which is exactly the scenario the Prefer header was created for. Because Prefer is a request header conveying client preference rather than a hard requirement or a content-negotiation contract, the service is free to honor it, which fits the additive, non-breaking design of evolvable enumerations.

Why the Other Options Are Wrong

Accept is used for proactive content negotiation: the client tells the server which response media types (for example application/json or application/xml) it can process, and it says nothing about unknown enumeration members. Content-Type describes the media type of a request body that the client is sending, and it is irrelevant on a GET request with no payload. If-Match is a conditional-request header that carries an ETag for optimistic concurrency control, so it governs lost-update protection, not enumeration visibility. None of these three headers changes whether Microsoft Graph returns members of an evolvable enumeration that your application was not compiled against.

Community Comment Notes

Every learner vote recorded for this item selected D, and the comments are consistent with the official guidance. As passme847 explained, "you can opt in to receive those members by using an HTTP Prefer request header". KeithSh pointed directly at the Microsoft Graph best-practices page and its section on handling future members in evolvable enumerations, and Vichu_1607 summarized the same point, noting the header ensures the response includes unknown members. Mattt and c75314a also confirmed the Prefer header. The consensus here aligns with the documented behavior, so there is no conflict between the community votes and the correct answer.

Official Reference

https://learn.microsoft.com/en-us/graph/best-practices-concept#handling-future-members-in-evolvable-enumerations

This link opens the official vendor documentation in a new tab.

Exam Strategy

When a stem mentions Microsoft Graph 'unknown members', 'future members', or 'evolvable enumerations', map it immediately to the Prefer header and stop reading the other headers. AZ-204 frequently tests header roles: Accept for media-type negotiation, Content-Type for payload format, If-Match for concurrency/ETags, and Prefer for optional service behaviors.

Frequently Asked Questions

Why does the Accept header not enable unknown members in a Microsoft Graph GET?

Accept only negotiates the response media type, such as application/json. It signals nothing about evolvable enumeration members, so the service will still omit enum values your app was not built for.

When should I use If-Match instead of Prefer in a Microsoft Graph request?

If-Match carries an ETag for optimistic concurrency, protecting against lost updates on writes. Prefer expresses an optional behavior such as include-unknown-enum-members on reads.

More AZ-204 FAQ →

Community Votes

D
100%

100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

  1. passme847 👍 3 Answered D
    " If you design your application to handle unknown members as well, you can opt in to receive those members by using an HTTP Prefer request header" https://learn.microsoft.com/en-us/graph/best-practices-concept
  2. KeithSh 👍 2 Answered D
    Correct D: https://learn.microsoft.com/en-us/graph/best-practices-concept#handling-future-members-in-evolvable-enumerations
  3. Vichu_1607 👍 1 Answered D
    Prefer Header: Ensures that the response includes unknown members, supporting evolvable enumerations.
  4. Mattt 👍 1 Answered D
    D is correct
  5. c75314a 👍 1 Answered D
    d

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

How Do You Mitigate Azure Cache for Redis Maintenance Performance Issues?

S-grade

Azure Service Bus FIFO Processing Order

S-grade

How Do You Increase Read Cache in Azure Cache for Redis?

S-grade

Which Cosmos DB consistency level avoids out-of-order writes in multi-region reads?

S-grade

← Back to AZ-204 Study Guide