The hard set (5 questions)
The hardest SharePoint questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book for this exam holds the full bank.
An engineer builds an unattended PnP PowerShell job to run nightly against SharePoint Online. It registers an Entra ID app and authenticates app-only using a client secret with the SharePoint Sites.FullControl.All application permission (admin-consented). Interactive tests worked, but the unattended app-only calls fail with 'Unsupported app only token' / Access Denied. What is the correct fix?
Correct answer: D. Replace the client secret with a certificate; SharePoint Online blocks app-only access authenticated by a client secret and requires certificate-based credentials
SharePoint Online does not accept client-secret-based app-only tokens; such requests return 'Unsupported app only token' / Access Denied. App-only access to SharePoint Online must use certificate-based credentials (for example, Connect-PnPOnline with a certificate thumbprint). PnP PowerShell's Register-PnPAzureADApp can automate creating the app registration and a self-signed certificate for exactly this flow.
Why the other options are wrong:
- A. -Interactive forces a human, MFA-capable sign-in, which is impossible for an unattended scheduled job; it does not address the app-only token restriction.
- B. A delegated permission requires an interactive signed-in user, which defeats the unattended requirement; the failure is caused by the client-secret token type, not the permission delegation model.
- C. Granting the app a directory admin role is unnecessary and unrelated; SharePoint Online rejects the token because it was obtained with a secret rather than a certificate.
Memory hook: SPO app-only = certificate only. A client secret gets 'Unsupported app only token.'
Microsoft Learn: Security apponly azuread
During an acquisition you run a cross-tenant OneDrive migration with Start-SPOCrossTenantUserContentMove. You pre-created and licensed all target users, established trust, and uploaded the identity map. For a subset of users the migration fails immediately. Investigation shows those users had already signed in to the target tenant, and their OneDrive had been auto-provisioned there. What is the correct explanation and fix?
Correct answer: D. A OneDrive site must NOT already exist for the user on the target tenant - an existing target OneDrive cannot be overwritten, so the move fails. Restrict OneDrive creation on the target and remove the pre-existing sites before migrating.
For cross-tenant OneDrive migration, OneDrive sites should not be created before or during the migration. If a target OneDrive already exists for the user, the migration fails because the existing site cannot be overwritten. Microsoft's guidance is to restrict OneDrive creation on the target tenant to prevent users from provisioning sites.
Why the other options are wrong:
- A. The Cross-Tenant User Data Migration license can be assigned on either the source or the target object; license placement did not cause these failures since all users were licensed.
- B. Cross-tenant moves are one-and-done; incremental and delta passes cannot be performed, so rerunning will not merge into an existing site.
- C. The OneDrive limit is 5 TB or 1 million items, not 400 items; 400 is the maximum full-path character length, which is unrelated to pre-provisioning.
Memory hook: Target OneDrive must be absent - a pre-provisioned site can't be overwritten, so the move fails.
Microsoft Learn: Cross tenant OneDrive migration
An SPFx web part requests the Microsoft Graph permission Group.Read.All through webApiPermissionRequests. The request appears as pending on the API access page in the SharePoint admin center. You must approve it using the least-privileged Microsoft Entra role possible. Which role must you use?
Correct answer: C. Global Administrator
Approving permissions for Microsoft Graph (or any other Microsoft API) on the API access page requires the Global Administrator role. Application Administrator is sufficient only for third-party APIs registered in the tenant, and that is the trap: the least-privilege instinct steers you away from Global Admin, but for a Graph scope no lesser role can approve.
Why the other options are wrong:
- A. Cloud Application Administrator, like Application Administrator, is not sufficient to consent to Microsoft Graph permissions on this page.
- B. SharePoint Administrator can reach related admin surfaces but cannot approve Microsoft Graph permission requests; the API access approval for Microsoft APIs is gated on Global Administrator.
- D. Application Administrator can approve only third-party (non-Microsoft) API requests, not Microsoft Graph scopes.
Memory hook: Microsoft API (Graph) = Global Admin only; third-party API = Application Admin is enough.
Microsoft Learn: API access
A developer who is not a SharePoint or tenant administrator, but is an Owner of the tenant app catalog site, needs to set a tenant property (storage entity) that can be read through the SharePoint REST API. Which approach lets them do this without elevated admin rights?
Correct answer: B. Connect with Connect-PnPOnline and run Set-PnPStorageEntity.
PnP PowerShell's *-PnPStorageEntity cmdlets (after Connect-PnPOnline) can set tenant properties without tenant administrator privileges: any Owner of the app catalog site can do it. By contrast, the SharePoint Online Management Shell's *-SPOStorageEntity cmdlets require first connecting with Connect-SPOService, which requires the SharePoint Administrator role.
Why the other options are wrong:
- A. Set-SPOStorageEntity requires Connect-SPOService, which needs the SharePoint Administrator role, exactly what the developer lacks.
- C. Set-PnPStorageEntity needs only app catalog site ownership, so a supported non-admin path does exist.
- D. Set-SPOTenant configures tenant settings and also requires a SharePoint Administrator connection via the SPO Management Shell.
Memory hook: PnP storage entity = app catalog Owner is enough; SPO storage entity = admin only.
Microsoft Learn: Tenant properties
Your tenant's Site storage limits are set to Automatic (pooled). You run Set-SPOSite -Identity <url> -StorageQuota 5000 to cap one site, but PowerShell returns a generic error. What is the correct explanation and remedy?
Correct answer: B. Per-site quotas can't be set while Site storage limits are Automatic; switch that setting to Manual, set the quota, then switch back if desired. Switching back to Automatic resets all site limits to 25,600 GB (25 TB).
When the tenant uses Automatic (pooled) site storage management, you cannot set an individual site's quota; Set-SPOSite -StorageQuota returns a generic error. The documented workaround is to switch Site storage limits to Manual, set the quota, then switch back to Automatic if desired. Note that switching (back) to Automatic/pooled resets every site's limit to 25,600 GB (25 TB).
Why the other options are wrong:
- A. The unit is not the cause of the error; the blocker is that per-site quotas can't be set while storage management is Automatic.
- C. No lock state is required to change a site's storage quota; the issue is the automatic storage-management mode.
- D. Set-SPOGeoStorageQuota sets quota per geo-location on multi-geo tenants, not per individual site; Set-SPOSite -StorageQuota is not deprecated.
Memory hook: Auto pool blocks per-site quotas: flip to Manual first; auto resets everyone to 25,600 GB.
Microsoft Learn: Manage site collection storage limits
