SharePoint Content, Metadata, and Search (15 questions)
Go deeper on this topic in SharePoint Online Content, Metadata, and Search Field Guide.
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 controls whether the value is returned and can be displayed in results, not whether it can be queried by name.
- B. 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 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: https://learn.microsoft.com/sharepoint/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 forces each item to be a single primary file, which does not match a metadata-first record that has several supporting files.
- C. 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 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: https://learn.microsoft.com/office365/servicedescriptions/sharepoint-online-service-description/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. 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. 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. 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: https://learn.microsoft.com/purview/set-up-irm-in-sp-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. There is no automatic merge into the Document content type; each in-use copy simply becomes a standalone local content type.
- B. Unpublished copies are unsealed into local, editable content types, not read-only placeholders, and they do not block new documents.
- C. 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: https://learn.microsoft.com/sharepoint/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. Enterprise Keywords columns are fully supported in SharePoint Online, so this claim is false.
- B. 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. 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: https://learn.microsoft.com/sharepoint/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. They are not interchangeable for this purpose. Mapping the auto-created variant is specifically discouraged; use the ows_ variant.
- B. 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. 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: https://learn.microsoft.com/sharepoint/search/how-to-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 not off by default in SharePoint Online; major versioning is turned on automatically for new libraries, a change from older on-premises defaults.
- B. The default is major versions only, not major-and-minor. Minor/draft versioning (0.1) must be enabled explicitly.
- C. 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: https://learn.microsoft.com/sharepoint/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. Requiring check-out controls concurrent editing and version creation, not who can view existing drafts.
- C. Removing Read for all members over-restricts access and breaks the whole library rather than just draft visibility.
- D. 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: https://learn.microsoft.com/sharepoint/governance/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. Unpublishing never deletes content types or the documents based on them.
- B. The content type is not stripped from libraries and items do not lose metadata; only the update relationship ends.
- C. 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: https://learn.microsoft.com/sharepoint/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. lookupValue is the display property for lookup fields, not person fields.
- B. [$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. 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: https://learn.microsoft.com/sharepoint/dev/declarative-customization/column-formatting#display-field-values-basic
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. 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. Breaking inheritance is not the documented remedy and fragments the published content type; enable the feature at the hub and republish instead.
- D. 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: https://learn.microsoft.com/troubleshoot/sharepoint/lists-and-libraries/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. 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. Column formatting affects only the formatted column's cell, so it cannot shade the whole row.
- D. 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: https://learn.microsoft.com/sharepoint/dev/declarative-customization/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 Content type gallery is not available to the Global Reader role at all; you need SharePoint or Global admin permissions.
- C. Default keyword storage location is unrelated; the gating requirements are prior publishing plus a pay-as-you-go license.
- D. 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: https://learn.microsoft.com/microsoft-365/documentprocessing/push-content-type-to-hub?view=o365-worldwide
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. The Managed Metadata Service supports term sets and managed metadata columns, not the availability of Document Sets.
- B. Versioning governs version history, not whether the Document Set content type is available.
- D. 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: https://learn.microsoft.com/sharepoint/governance/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. 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. The Microsoft 365 admin center is not where a site collection's No result queries report is found, and 7 days is wrong.
- D. 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: https://learn.microsoft.com/troubleshoot/sharepoint/search/classic-site-collection-search-usage-reports