Which HTTP Header Enables Microsoft Graph Evolvable Enumerations?
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?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
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.
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.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.