Sample questions
Mobile Distribution CiDifficulty 3
A rollout configuration is set as follows:
release:
version: 4.2.0
rollout_percentage: 10
halt_on_crash_rate_increase: true
If the app has 200,000 active users, approximately how many would be receiving version 4.2.0 while the rollout sits at this stage?
- aAbout 2,000 users.
- bAbout 20,000 users.✓
- cAbout 180,000 users.
- dAll 200,000 users, since rollout percentage only affects update visibility timing, not the total.
Explanation:10% of 200,000 is 20,000. Rollout percentage directly controls what fraction of the population receives the new version at that stage, not just visibility timing.
Mobile Distribution CiDifficulty 3
A backend team removes a field from an API response, believing all clients now use the new version. A week later, users on an old app version start reporting a blank screen. What was most likely missed?
- aSome users had not yet updated, and the old app version still depended on the removed field.✓
- bThe store rejected the update, so no users ever received the new client.
- cThe removed field was unrelated to the crash and the true cause is a signing certificate mismatch.
- dThe blank screen is caused by the staged rollout being paused.
Explanation:The scenario's root cause is a backward-compatibility gap: some users hadn't updated yet, and their old client still relied on the removed field. Nothing in the scenario points to store rejection, signing, or a paused rollout.
Mobile Distribution CiDifficulty 3
Two versions are compared: version A has a 0.3% crash rate on 100 sessions, and version B has a 0.5% crash rate on 50,000 sessions. A team is deciding which crash rate is more reliable evidence for a rollback decision. Which reasoning is correct?
- aVersion A's rate is lower, so it must always be the safer version regardless of sample size.
- bNeither rate is meaningful unless both versions have identical marketing spend.
- cCrash rate cannot be compared across versions if the sessions were collected on different days.
- dVersion B's larger sample makes it the more statistically reliable rate.✓
Explanation:With only 100 sessions, version A's rate is statistically noisy and could shift drastically with a handful more crashes; version B's rate, from 50,000 sessions, is a far more stable estimate even though its percentage is higher. Marketing spend and calendar day are irrelevant to this comparison.
Mobile Distribution CiDifficulty 3
A submission is rejected with the review note: 'Metadata screenshots do not reflect current app functionality.' The team's release checklist includes:
[x] Run automated tests
[x] Verify code signing
[ ] Update store listing assets after UI changes
[x] Check crash-free rate over 24h
Which checklist gap best explains this specific rejection reason?
- aThe automated tests item, since failing tests produce this exact rejection message.
- bThe code signing item, since expired signatures produce this exact rejection message.
- cThe unchecked item about updating store listing assets after UI changes.✓
- dThe crash-free rate item, since crash monitoring is checked here but is unrelated to listing content.
Explanation:The rejection is specifically about screenshots not matching current functionality — that maps directly to the unchecked 'update store listing assets' item. Test failures and signing issues produce different rejection reasons entirely, and the crash-free item, while unrelated to listing content, was actually completed (checked) in this checklist.
Mobile Distribution CiDifficulty 3
A team's release pipeline is automated end-to-end, but one release fails right before publishing because the signing key used doesn't match the one used for all previous releases. What is the most likely consequence if this mismatched build were force-published anyway?
- aDevices may refuse the update since the signing source no longer matches.✓
- bThe app would automatically be re-signed by the store using the original key.
- cOnly the app's icon would fail to display correctly.
- dThe staged rollout percentage would be reset to 100% automatically.
Explanation:Update installation on existing devices typically requires the same signing identity as prior releases; a mismatched key breaks that trust chain and devices may reject the update. Stores don't automatically re-sign builds with the original key, and the mismatch isn't limited to a cosmetic icon issue or rollout percentage reset.
Mobile NavigationDifficulty 3
A deep link points to a screen that is normally three levels deep in the app's hierarchy (Home → Category → Item). What should the app do with the back stack when it opens directly to Item from a deep link?
- aSynthesize the parent screens onto the stack, matching the natural hierarchy✓
- bShow only the Item screen and disable the back control entirely for that session
- cIgnore the target screen depth and always open the app's default home screen instead
- dOpen Item with an empty stack, so the very first back press exits the app
Explanation:To keep back navigation coherent, the app should build the stack as if the user had navigated there normally (Home, then Category, then Item), so pressing back steps up through the hierarchy instead of exiting unexpectedly. (b) removes a core navigation affordance; (c) defeats the point of the deep link; (d) produces a jarring exit on the first back press.