I85PREP
⌘ K
MS-700 study materials
MS-700 study resources

One approved vendor app, one pinned internal app, one pre-release mistake

MS-700 · Put your knowledge to work in context.

All case studies

One approved vendor app, one pinned internal app, one pre-release mistake

Fabrikam's security team has approved a third-party scheduling app for exactly 40 HR recruiters; everyone else must be blocked from it. At the same time, the internal IT team has built a custom Teams tab app for expense approvals that must be pinned in the left rail for all 3,000 users at first sign-in. The tenant currently has no app permission policies other than the global default and no app setup policies other than the global default. A pilot group of 25 recruiters has already uploaded a pre-release build of the scheduling app as a custom app for testing, and the security team now says that pre-release build must be gone from the tenant entirely. HR also reports that users cannot find the scheduling app in the Teams client at all.

1. Design the minimum set of app policies that lets only the 40 recruiters use the scheduling app. Explain which control actually enforces the restriction and where naive designs fail.

Read the worked answer

Design:

  1. In Teams admin center → Teams apps → Permission policies, keep the Global (Org-wide default) policy blocking the scheduling app. Blocking at the default is what enforces 'nobody else'. Do not rely on the app being merely 'not allowed' - an unlisted app can be allowed by a different policy or by user interaction with a link.
  2. Create a custom app permission policy, e.g. HR-Recruiters-Scheduling, that explicitly allows that one app (or allows all third-party apps, if that is acceptable, but explicit allow is tighter).
  3. Assign the custom policy to a security group containing the 40 recruiters.

Why it works: app permission policies are per-user and additive at the user level; the assigned policy overrides the global default for that user. Group-based assignment is used so the 40-person list is maintained in Entra ID rather than in two places.

Where naive designs fail:

  • Assigning a policy that allows all third-party apps to the recruiters and blocking one app in the global default is fine here, but allowing the app in the global default and blocking it for everyone else is not possible - you would have to enumerate everyone else.
  • Tenant-level toggles (allow third-party apps, allow interaction with custom apps) must be on for any of this to matter; if third-party apps are off org-wide, the allow in the custom policy is inert and HR's 'can't find it' symptom persists.
  • Policies propagate on the order of hours, not instantly; test with one user before declaring done.

2. The expense app must be pinned for all 3,000 users. What exactly do you configure, and what happens if you only upload the app to the catalog?

Read the worked answer

What to configure: an app setup policy (Teams admin center → Teams apps → Setup policies). Add the expense app to the Pinned apps list, order it, optionally add it to Installed apps so it is installed silently for the user, and assign the policy to all users (either edit the Global org-wide default policy, or create a policy and assign it to an 'All Users' group).

If you only upload the app to the org catalog: the app becomes available to users who search the app store or the 'Built for your org' area, but nothing is pinned and nothing is installed. At 3,000 users, 'available but undiscoverable' produces a support queue, not adoption.

Judgement points:

  • Installation and pinning are separate lists. Pinning without installing can leave a pin that resolves only after the user adds the app; adding to Installed apps is what makes first sign-in clean.
  • Setup policy applies at first sign-in for new users; existing users pick up a changed policy at next client refresh, which can take up to a day. Do not tell the business it is instant.
  • If the expense app is a custom app, the tenant must permit custom app upload/interaction, and the app must be uploaded to the org catalog (not sideloaded by a user), otherwise the pin has nothing to point at.
  • Users can unpin apps; setup policy pins are a default, not an enforcement mechanism.

3. The pre-release custom app must be removed from the tenant entirely. What are the constraints and the order of operations?

Read the worked answer

Order of operations:

  1. Block first, delete second. Add the pre-release app to a block in the relevant app permission policies (or the global default) so it stops being usable while you work, then remove it from the catalog.
  2. Delete from the org catalog: Teams admin center → Teams apps → Manage apps → select the app → Delete. This removes it from the tenant catalog so no new user can install it.
  3. Remove existing installs: deleting from the catalog does not reliably uninstall the app from the 25 pilot users' clients. Use the app's user list / 'remove for users' or an app permission policy that blocks it, and confirm removal.
  4. Check for duplicates: custom apps are identified by the manifest id. If the pre-release build was uploaded more than once, or uploaded alongside the vendor's published version, you may have to delete multiple catalog entries that look identical in the UI.

Constraints to state to the security team:

  • Deletion from the catalog is not retroactive to content the app already wrote (tabs, messages, files in SharePoint). Those artefacts remain and need separate cleanup.
  • If the app is a custom app uploaded by users, also close the door that let it happen: review who has custom app upload permission, since it is granted through app setup policy rather than being on for everyone by default.
  • Propagation to clients is not immediate; expect a lag and verify on a test device before confirming closure.