Show the 15 questions and explanations
Users can already find documents by typing an author's name in the search box, but the administrator now wants them to be able to narrow results to a specific field by typing author:Smith. Which managed property setting must be enabled for that field so it can be addressed by name in a query?
Correct answer: C. Queryable
Queryable is the setting that lets a managed property be addressed by name in a query, so author:Smith only works once the property is marked Queryable. Searchable is the trap here: it adds the property's content to the full-text index, which is why a bare keyword like 'Smith' already finds the documents, but it does not enable property:value syntax.
Why the other options are wrong:
- A. Retrievable Retrievable controls whether the value is returned and can be displayed in results, not whether it can be queried by name.
- B. Searchable Searchable includes the property's content in the full-text index for unqualified keyword matching, but it does not by itself allow field-scoped 'author:Smith' queries.
- D. Refinable Refinable lets the property appear as a refiner (filter) in classic search; it does not enable property:value query syntax.
Memory hook: author:Smith needs Queryable. Searchable = keyword match; Retrievable = show it; Refinable = filter panel.
Microsoft Learn: Manage search schema
The facilities team wants to catalog physical assets in SharePoint Online. Each catalog entry is primarily structured metadata (asset tag, location, assigned owner, purchase date), and an entry occasionally needs two or three photos or receipts attached to that same record. There is no single authored 'document' at the center of each entry. Which container best fits these requirements?
Correct answer: B. A custom SharePoint list, using item attachments for the photos and receipts
A document library is file-centric: every item is built around exactly one primary file. A list is record-centric: each item is a row of column metadata and can carry multiple file attachments (up to 250 MB per attached file). For asset records that are mostly metadata with a few supporting files, a custom list with attachments is the correct fit.
Why the other options are wrong:
- A. A document library, storing each asset record as a single file A document library forces each item to be a single primary file, which does not match a metadata-first record that has several supporting files.
- C. A document library with a Document Set created for every asset Document Sets group multiple documents as one deliverable but still live in a file-centric library and add unnecessary overhead for simple asset records.
- D. A site pages library, with one page per asset A site pages library stores web pages, not structured asset records with attachments.
Memory hook: Library = one file per item; List = a row of metadata that can hold many attachments.
Microsoft Learn: SharePoint Online limits
Site owners report that the Information Rights Management link is missing from their document library's Library Settings. You have already activated the Azure Rights Management service for the tenant. Where do you turn on the IRM service so the library-level option appears?
Correct answer: A. In the SharePoint admin center, open the classic settings page, select "Use the IRM service specified in your configuration," then choose Refresh IRM Settings.
IRM is enabled at the tenant level from the SharePoint admin center's classic settings page by choosing "Use the IRM service specified in your configuration" and then Refresh IRM Settings. Only after that refresh does the Information Rights Management link appear in Library Settings and List Settings (it can take up to an hour). Azure Rights Management must be activated first, which the scenario states is already done.
Why the other options are wrong:
- B. In the Microsoft 365 admin center, toggle "Azure Information Protection" under Org settings, then Services. There is no such toggle; Azure Rights Management is activated from its own service and SharePoint IRM is turned on in the SharePoint admin center, not via an 'Azure Information Protection' org setting.
- C. On each affected library, choose Library Settings, then Information Rights Management, and select "Create an IRM policy." The library-level IRM link only appears after the tenant IRM service is refreshed; you cannot enable the service from a library, and there is no 'Create an IRM policy' action there.
- D. In the Microsoft Purview portal, under Information Protection, create and publish a sensitivity label that applies encryption. Sensitivity labels are a separate, newer protection technology; publishing a label does not enable the legacy SharePoint IRM service, and an IRM-enabled library can't even use a sensitivity label.
Memory hook: IRM lives in the SharePoint admin center's CLASSIC settings: flip it on, hit Refresh, wait up to an hour.
Microsoft Learn: Set up IRM in SharePoint admin center
A 'Project Charter' content type was published from the SharePoint admin center content type gallery and is in use across 40 site collections. To retire central management of it, an administrator selects Unpublish in the Manage Publishing panel. What happens to the copies already in use on the 40 subscriber sites?
Correct answer: D. They remain but are converted to local content types on each site, no longer receiving updates from the hub.
Per Microsoft Learn, when you unpublish a content type, any copies of that content type being used in other sites are converted to a local content type. They are not deleted; in no situation is a content type automatically removed from a subscribing site collection. They are, however, severed from the hub and will no longer receive republish (central) updates. Restoring central management requires republishing and re-establishing the subscription, so unpublishing is not a clean rollback.
Why the other options are wrong:
- A. They are automatically merged into each site's default Document content type. There is no automatic merge into the Document content type; each in-use copy simply becomes a standalone local content type.
- B. They become read-only placeholders that block new documents until the content type is republished. Unpublished copies are unsealed into local, editable content types, not read-only placeholders, and they do not block new documents.
- C. They are immediately deleted from all 40 sites, removing the columns from any tagged documents. Unpublishing never automatically deletes the content type or its columns from subscriber sites; the in-use copies persist as local content types.
Memory hook: Unpublish = cut the cord, not delete. In-use copies become local content types and updates stop.
Microsoft Learn: Publish content type
A team wants a single tagging field on a library that lets users apply several free-form tags per document, drawing type-ahead suggestions from managed term sets as well as previously used tags, without binding to one specific term set. The administrator also plans to index this field to support filtered views on a library expected to exceed 5,000 items. Which statement is correct?
Correct answer: D. Add the Enterprise Keywords column; it is always multi-value, draws suggestions from managed term sets and the Keywords set, and cannot be indexed.
The Enterprise Keywords column is, by default, a multi-value column that surfaces type-ahead suggestions from managed term sets and the Keywords term set and lets users enter new values, which is exactly the free-form, multi-tag behavior described. Because it is inherently multi-value, it cannot be added as an indexed column, so it will not support filtered views once the library passes the 5,000-item list view threshold. The scenario's two goals are in tension: whole-store free-form tagging and indexing cannot both be satisfied by this one column.
Why the other options are wrong:
- A. Add a Managed Metadata column; Enterprise Keywords columns are not supported in SharePoint Online. Enterprise Keywords columns are fully supported in SharePoint Online, so this claim is false.
- B. Add a Managed Metadata column bound to a closed term set and enable 'Allow multiple values'; it can still be indexed. A multi-value Managed Metadata column cannot be indexed, and binding to one closed term set contradicts the requirement to suggest from across the store and allow new free-form tags.
- C. Add the Enterprise Keywords column and set it to single-value so it can be indexed for the filtered views. The Enterprise Keywords column has no single-value variant; it is always multi-value and therefore cannot be indexed.
Memory hook: Enterprise Keywords = always multi-value, whole-store suggestions, can't be indexed. Need indexing? Use a single-value Managed Metadata column.
Microsoft Learn: Managed metadata
An administrator is wiring a custom Text site column named 'Contract Owner' to an unused RefinableString slot so it can be used as a refiner. Searching the crawled properties returns two entries for the column: ows_q_TEXT_ContractOwner and ows_Contract_Owner. Which crawled property should be mapped to the RefinableString managed property, and why?
Correct answer: C. ows_Contract_Owner, because when mapping to a refinable managed property you select the ows_ prefixed variant, not the automatically created ows_q_ / ows_r_ / ows_taxId_ one.
A crawled site column typically surfaces two crawled properties: the automatically created ows_q_<TYPE>_ (or ows_r_, ows_taxId_) variant that already feeds the auto-generated managed property, and an ows_ prefixed variant. Microsoft Learn is explicit that when mapping a crawled property to a refinable managed property you should select the crawled property that begins with ows_. After mapping (and setting an alias) you reindex the library so the change is picked up.
Why the other options are wrong:
- A. Either one works identically, since both point to the same site column. They are not interchangeable for this purpose. Mapping the auto-created variant is specifically discouraged; use the ows_ variant.
- B. Neither; you must first create a brand-new Refinable managed property and map both variants to it. In SharePoint Online you cannot create a new Refinable managed property from scratch; you reuse a built-in RefinableString slot and map the ows_ variant to it.
- D. ows_q_TEXT_ContractOwner, because the type-coded variant is the one refiners require. The ows_q_<TYPE>_ entry is the automatically created variant tied to the auto-generated managed property; guidance is to avoid it when mapping to a refinable slot.
Memory hook: Two crawled properties, pick the plain ows_ one for refiner mapping. Skip the ows_q_ / ows_taxId_ auto-created twin.
Microsoft Learn: Add refiners to your search results page
A site owner creates a brand-new document library on a modern team site in SharePoint Online and uploads a document without ever opening Versioning settings. Which statement correctly describes the library's version history behavior out of the box?
Correct answer: D. Major versioning is enabled by default, and the shipped organization default retains up to 500 major versions.
In SharePoint Online, document versioning is active by default on new libraries, and the shipped organization-level default version history limit is Manual with a 500 major-version count and no expiration. A brand-new library therefore keeps up to 500 major versions unless the organization default or the library is changed. Minor/draft versioning is a separate opt-in and is not on by default.
Why the other options are wrong:
- A. Versioning is off by default; the owner must turn on 'Create major versions' before any history is kept. Versioning is not off by default in SharePoint Online; major versioning is turned on automatically for new libraries, a change from older on-premises defaults.
- B. Major and minor (draft) versioning is enabled by default, starting each file at version 0.1. The default is major versions only, not major-and-minor. Minor/draft versioning (0.1) must be enabled explicitly.
- C. Versioning is enabled but capped at 100 major versions until an administrator raises the limit. 100 is the UI minimum you can set for a manual major-version count, not the default; the out-of-box organization default is 500 major versions with no expiration.
Memory hook: New SPO library = major versioning ON, 500 kept, no expiry. Minor/draft is opt-in.
Microsoft Learn: Set default org version limits
A policy library uses major and minor (draft) versioning with content approval. Authors report that colleagues with read-only access can see unapproved 0.x drafts. The admin wants only the item's author and users who can approve items to be able to see drafts, while readers see only the latest approved major version. Which setting should the admin change?
Correct answer: B. Versioning settings, then Draft Item Security, then 'Only users who can approve items (and the author of the item)'
Draft Item Security controls who can see minor (draft) versions. Setting it to 'Only users who can approve items (and the author of the item)' restricts draft visibility to approvers plus the author, while readers still see the last approved major version - meeting the requirement without altering permissions or the versioning scheme.
Why the other options are wrong:
- A. Versioning settings > 'Require documents to be checked out before they can be edited' Requiring check-out controls concurrent editing and version creation, not who can view existing drafts.
- C. Library permissions > break inheritance and remove Read for all members Removing Read for all members over-restricts access and breaks the whole library rather than just draft visibility.
- D. Versioning settings > switch to 'Create major versions only' Switching to major-only removes drafts entirely (losing the draft/publish workflow) instead of controlling draft visibility.
Memory hook: Who sees 0.x drafts? Draft Item Security - dial it to approvers + author.
Microsoft Learn: Versioning content approval and check out planning
In the SharePoint admin center, under Content services, then Content type gallery, an administrator selects a published site content type named 'Contract' and chooses Unpublish. Several sites across the tenant are already using 'Contract' on their libraries. What happens to those existing content types when the change syncs?
Correct answer: D. Existing copies in use are converted to local (site-level) content types and stop receiving updates from the gallery
Unpublishing makes a content type unavailable for download to other sites, and any copies already in use are converted to local content types. They remain in place with their data, but no longer receive published updates from the gallery. Publish/Republish pushes updates; Unpublish severs the update link without deleting content.
Why the other options are wrong:
- A. The 'Contract' content type and all documents created from it are deleted from every site Unpublishing never deletes content types or the documents based on them.
- B. The content type is immediately removed from all libraries, and affected documents lose their metadata The content type is not stripped from libraries and items do not lose metadata; only the update relationship ends.
- C. Nothing changes for existing sites; Unpublish only blocks the content type from new sites created afterward Existing copies ARE affected (they become local content types), so the effect is not limited to future sites.
Memory hook: Unpublish = go local: the copy stays, but it's cut off from the hub's updates.
Microsoft Learn: Publish content type
An admin applies column formatting JSON to a Person column so it displays the assignee's name, using "txtContent": "@currentField". Instead of a name, the column renders blank or shows an object. Which JSON correctly displays the person's name?
Correct answer: D. "txtContent": "@currentField.title"
Person fields are represented as objects, and the display name is held in the object's title property. The formatter must therefore reference @currentField.title. (Lookup fields, by contrast, expose their display text in the lookupValue property.)
Why the other options are wrong:
- A. "txtContent": "@currentField.lookupValue" lookupValue is the display property for lookup fields, not person fields.
- B. "txtContent": "[$AssignedTo]" [$AssignedTo] references the raw field object (and only resolves if that column is in the same view); it still yields the object, not the name.
- C. "txtContent": "=toString(@currentField)" There is no toString conversion for this; the supported approach is @currentField.title.
Memory hook: Person = object: .title for the name; Lookup = .lookupValue.
Microsoft Learn: Column formatting
A subscriber site collection receives several custom document content types published from the content type hub. An admin sets one of those published content types as the default on a library, then enables the Document ID Service site collection feature. Afterward, documents in that library still aren't getting Document IDs and the Document ID column doesn't appear. What is the correct fix?
Correct answer: A. Enable the Document ID Service feature on the content type hub site collection, then republish the content types.
Content types published from the hub are set to read-only on subscriber sites, so the Document ID Service cannot provision its required columns onto them. The documented fix is to enable the Document ID Service on the content type hub site collection itself, then republish the syndicated content types so subscribers receive the updated, Document ID-enabled content types.
Why the other options are wrong:
- B. Set the library's default content type back to the built-in Document content type before enabling the feature. The blocker is the read-only published content type, not the choice of Document vs custom type; reverting does not provision IDs on the custom content type.
- C. Break content type inheritance on the library so the published content type becomes editable locally. Breaking inheritance is not the documented remedy and fragments the published content type; enable the feature at the hub and republish instead.
- D. Re-run the "Document ID enable/disable" timer job manually from the subscriber site collection. The issue isn't a stalled timer job; the published content type is read-only and lacks the Document ID columns until the hub is updated and republished.
Memory hook: Published = read-only; turn on Doc ID at the hub, then republish.
Microsoft Learn: Document IDs unassigned
A site owner wants the ENTIRE row in a list view to be shaded red whenever the 'Status' choice column equals 'Overdue', so overdue records are visually flagged for reviewers. The underlying data must not change. Which approach accomplishes this?
Correct answer: A. Apply view formatting to the view (for example, additionalRowClass) using a conditional expression on the Status field
Column formatting styles a single field (only that one cell), whereas view formatting (via additionalRowClass or rowFormatter) styles the whole row based on field values. To conditionally shade an entire row, use view formatting; like column formatting, it only changes how the row is displayed, not the underlying data.
Why the other options are wrong:
- B. Build a SharePoint Framework (SPFx) Field Customizer extension An SPFx Field Customizer is heavier than needed and also targets a single field, not the whole row; view formatting already covers this scenario.
- C. Apply column formatting JSON to the Status column Column formatting affects only the formatted column's cell, so it cannot shade the whole row.
- D. Add a column validation formula in list settings that blocks 'Overdue' items A validation formula enforces data-entry rules; it does not shade rows and would block saving rather than format display.
Memory hook: Cell = column formatting; whole ROW = view formatting (additionalRowClass).
Microsoft Learn: View formatting
From the Content type gallery in the SharePoint admin center, an admin has published a custom "Contract" content type. They now want that content type to be automatically added to every new list and library created on a set of hub-associated sites, without site owners adding it manually. What must be true for this "push content types to a hub" capability to work?
Correct answer: A. The content type must already be published, and the feature requires a pay-as-you-go (Microsoft Syntex) license.
Pushing content types to hub sites (so they are automatically added to new lists/libraries and to newly associated sites) is a paid capability that requires a pay-as-you-go (Microsoft Syntex) license, and the content type being pushed must already be published from the Content type gallery first.
Why the other options are wrong:
- B. The admin must hold the Global Reader role to open the Content type gallery and select hub sites. The Content type gallery is not available to the Global Reader role at all; you need SharePoint or Global admin permissions.
- C. The Managed Metadata Service must be set as the default keyword storage location for the tenant. Default keyword storage location is unrelated; the gating requirements are prior publishing plus a pay-as-you-go license.
- D. Each target site must first be converted into its own content type hub at /sites/ContentTypeHub. You select ordinary SharePoint hub sites in the gallery; there is a single content type hub at /sites/ContentTypeHub, not one per site.
Memory hook: Push to hub = publish first + pay-as-you-go (Syntex).
Microsoft Learn: Push content type to hub
A records manager wants to add a 'Case File' Document Set content type to a document library so that related case documents can be created and managed as one unit with shared metadata. On a brand-new site, 'Document Set' does not appear as a content type they can add. What must be done first?
Correct answer: C. Activate the Document Sets site collection feature
Document Sets are delivered by a site collection feature that must be activated (Site settings, then Site collection features, then Document Sets, then Activate) before Document Set content types become available. Only after the feature is on can you create or add a Document Set content type to a library.
Why the other options are wrong:
- A. Configure the Managed Metadata Service application The Managed Metadata Service supports term sets and managed metadata columns, not the availability of Document Sets.
- B. Enable versioning on the target document library Versioning governs version history, not whether the Document Set content type is available.
- D. Create a content type hub for the site A content type hub centrally publishes content types but is not required to make Document Sets available on a site.
Memory hook: No Document Set option? Flip the Document Sets site collection feature ON first.
Microsoft Learn: Document set planning
As a site collection administrator you want to see the searches users ran on your site collection that returned no results (a 'No result queries' report), so you can improve findability. In current SharePoint Online, where do you access this report and what time ranges does it cover?
Correct answer: C. Site Settings, then Site Collection Administration, then Microsoft Search, then Configure search settings, then Insights; reports cover the past 31 days and past 12 months
The updated site-collection search usage reports are reached from Site Settings under Site Collection Administration via Microsoft Search, then Configure search settings, then Insights. They include five reports (top queries, abandoned queries, query rule usage, no result queries, and query volume trends), are available for the past 31 days and past 12 months (the prior window was 14 days), and only site collection admins can view them.
Why the other options are wrong:
- A. Site Settings, then Site Collection Administration, then Popularity and Search Reports, then Usage; the Excel report covers the past 14 days and past 3 years Popularity and Search Reports opens Excel usage reports (Popularity Trends is 14 days daily / 3 years monthly); the query-level No result queries insights moved to the Microsoft Search Insights page with 31-day/12-month windows.
- B. Microsoft 365 admin center, then Health, then Microsoft Search insights; data covers the past 7 days The Microsoft 365 admin center is not where a site collection's No result queries report is found, and 7 days is wrong.
- D. SharePoint admin center, then More features, then Search, then Usage reports; data covers the past 30 days only Site-collection query reports are not surfaced under the tenant admin center's Search page, and '30 days only' is incorrect.
Memory hook: Query insights (top / abandoned / no-result) = Site Collection Admin, then Microsoft Search, then Insights; 31 days & 12 months, admins only.
Microsoft Learn: Classic site collection search usage reports