The hard set (4 questions)
The hardest MS-700 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.
Before its tenant was automatically migrated to app-centric management, Contoso used a custom app permission policy assigned to contractors that blocked a specific third-party app, while the Global (Org-wide default) permission policy allowed the same app. After the automatic migration completes, contractors report they can now access the app. What explains this behavior?
Correct answer: A. This is documented migration behavior: when an app is allowed in the global policy but blocked in a custom policy, auto-migration makes the app available to all users of the tenant - the one case where app access changes - and the admin must manually restrict availability afterward
Microsoft Learn documents this exact conflict case for ACM auto-migration: 'There's no change of app permissions during the migration, except where an app is allowed in the global policy but blocked in the custom app permission policy. Here, the app is available to all users of the tenant' (except for EDU customers, where it becomes available to none). This is the only instance where access changes during migration, and Microsoft explicitly says admins can modify the resulting availability as desired post-migration. The fix is to edit the app's 'Available to' assignment on the Manage apps page.
Why the other options are wrong:
- B. ACM fully supports restricting an app to a subset of users via the 'Specific users or groups' availability option. The migration behavior in this conflict case is a defined rule, not a capability gap.
- C. Nothing failed - the access change in this specific global-allow/custom-block conflict is the documented, intended migration outcome. Migration also cannot be re-run or reverted once complete.
- D. Auto-migration does create one security group per custom app permission policy to preserve assignments, but the contractors' new access comes from the documented conflict-resolution rule, not from a deleted group.
Memory hook: ACM migration golden rule: nothing changes - EXCEPT global-allow + custom-block, which migrates to available-to-everyone. Audit that one conflict before April's migration wave hits.
Microsoft Learn: App centric management
A Teams administrator creates a custom app setup policy that pins a single line-of-business app to the app bar and assigns the policy to field technicians. On Teams desktop, the app appears pinned as expected. On the technicians' iOS and Android clients, the app bar remains unchanged even several days later. What is the cause?
Correct answer: A. A setup policy must pin at least two apps for the Teams mobile client to apply it; with fewer, the mobile client ignores the policy and keeps its existing configuration.
Microsoft Learn's app setup policy considerations state that at least two apps must be pinned for the Teams mobile clients (iOS and Android): 'If a policy has fewer than two agents or apps, the mobile client doesn't reflect the policy settings. Instead, the mobile client continues to use the existing configuration.' The desktop client has no such minimum, which explains why the pin works there while mobile appears unaffected. The fix is to pin a second app (for example, a core Microsoft app) in the same policy so mobile honors it.
Why the other options are wrong:
- B. App policies apply to Teams on web, mobile, and desktop clients. No Intune app configuration policy is needed for policy-based pinning on mobile.
- C. Admin pins always take precedence whether user pinning is on or off - the toggle only controls whether users can add and reorder their own pins below the admin list. It is not a prerequisite for admin pins on mobile.
- D. If the app were blocked by the user's permission policy, it would be unusable on desktop as well. The scenario confirms the pin works on desktop, so the app is allowed; the failure is mobile-specific.
Memory hook: Mobile needs a pair: fewer than two pinned apps and the iOS/Android clients ignore the setup policy entirely.
Microsoft Learn: Teams app setup policies
In Org-wide app settings the 'Let users interact with custom apps' setting is turned OFF. For one team, 'Allow members to upload custom apps' is ON, and the app setup policy assigned to that team's members has 'Upload custom apps' set to ON. What can those users do with custom apps?
Correct answer: B. No one can upload custom apps for personal or team use; users can only submit custom apps for admin approval.
The org-wide custom app setting is the master switch. When it is OFF, the Upload custom apps option is unavailable across the organization regardless of team-level or app-setup-policy settings. Users can still submit a custom app for admin approval, but they cannot upload it for their own personal or team use.
Why the other options are wrong:
- A. Team owners can upload only when the org-wide custom app setting is ON; with it off, upload is unavailable.
- C. Members uploading to a team requires the org-wide setting ON plus the other toggles; the master switch is off here.
- D. Personal-scope upload also depends on the org-wide setting being ON; it is off, so this is not possible.
Memory hook: Org-wide custom-app switch OFF = upload dead everywhere; only 'submit for approval' survives.
Microsoft Learn: Teams custom app policies and settings
Fabrikam hosts a Teams shared channel and invites several Contoso users through B2B direct connect. Cross-tenant access settings are correctly configured in both tenants, and Fabrikam's channel owners have no policy restrictions. The invited Contoso users, however, cannot participate in the external shared channel. Contoso's Teams administrator must resolve this with a teams policy change. Which setting must be turned On, and where?
Correct answer: B. 'Join external shared channels' in the teams policy assigned to the affected users in Contoso's tenant
The 'Join external shared channels' setting (PowerShell parameter -AllowUserToParticipateInExternalSharedChannel on CsTeamsChannelsPolicy) controls whether users can 'participate in shared channels created by other organizations where a cross-organization trust has been configured.' It is a per-user policy evaluated in the participating user's home tenant - here, Contoso. Because the Contoso users are the ones joining an externally hosted channel, Contoso's Teams administrator must ensure the policy assigned to them has this setting On.
Why the other options are wrong:
- A. 'Create shared channels' controls whether team owners can create shared channels at all. The scenario involves participating in an external channel, not creating one.
- C. 'Invite external users to shared channels' governs the outbound hosting direction - whether owners and members of shared channels in YOUR tenant can invite external participants. It does not control your users' ability to join channels hosted elsewhere.
- D. 'Join external shared channels' applies to the users doing the joining, in their home tenant. Assigning it in Fabrikam (the hosting tenant) has no effect on Contoso users' ability to participate.
Memory hook: Two directions, two toggles: INVITE external users = host side. JOIN external channels = participant's home tenant. Fix the policy where the blocked user lives.
Microsoft Learn: Teams policies
