Free Common Mobile OS and Application Security Issues practice questions

Isolating the device by placing it in airplane mode (or removing it from Wi-Fi) is the correct first step because it reduces data loss and stops the spread of any malicious activity while you assess the situation. Containment always comes before cleanup in a suspected security incident. Performing a full factory reset immediately is premature because it erases the evidence needed to document the incident and confirm what happened. Changing the user's passwords from the phone is unsafe because the device may be compromised, and any credentials entered could be captured; passwords should only be changed from a clean, trusted device. Granting the app the permissions it requests directly increases the risk, since an app asking for Accessibility access that doesn't match its purpose should be treated as hostile until proven otherwise. The correct troubleshooting order is to isolate, then remove the app if safe, run an approved security scan, and document everything.

USB debugging (ADB access) lets a computer send advanced commands to an Android phone over USB. In a controlled environment it helps with testing and management, but when a device with USB debugging enabled is connected to an unknown computer with the screen unlocked, a user may accept a prompt that grants broad access through ADB. OEM unlocking is a different developer setting that allows the bootloader to be unlocked for custom firmware, which weakens the startup chain but does not itself allow a computer to issue live ADB commands. Mock location is a test feature that lets apps report a false GPS position; it can relax app behavior checks but does not grant USB command access. Play Protect is a Google security service that scans apps for malware and is actually a protective control, not a risky developer option. The safest habits are to disable USB debugging when not testing, lock the screen before connecting, avoid public charging ports, and use a data-blocking adapter when using unknown USB ports.

The presence of a package manager such as Cydia or Sileo strongly indicates a jailbreak, because these tools are installed specifically to manage tweaks and packages that bypass App Store controls on iOS. Their existence on a device is one of the clearest observable signals during troubleshooting. Running an older iOS version is not proof of a jailbreak; many devices simply have not been updated, and outdated software is a separate concern. Enabling iCloud backups is a completely normal function available on every iPhone and provides no indication of tampering. A screen protector is a physical accessory unrelated to the operating system's integrity. When identifying modified devices, technicians should rely on multiple observable facts rather than assumptions, such as jailbreak package managers, failed integrity checks, banking apps refusing to run, or MDM compliance failures. Once a jailbreak is confirmed on a device holding work data, the response is to protect accounts first, contain corporate access, and follow the organization's wipe and re-enroll policy.

A rooted device that fails an integrity check is the most likely cause, because rooting breaks the trust the operating system relies on. When the OS can no longer prove it is intact, MDM posture checks fail, banking and finance apps refuse to run, and the device is marked noncompliant, often losing access to email, VPN, and conditional-access resources. Users frequently report this breakage suddenly after an update, sometimes without realizing the device was modified. An expired MDM enrollment certificate would show the device as unenrolled rather than noncompliant, and it would not cause a banking app to complain about an insecure environment. An expired corporate password produces sign-in prompts, not a compliance failure, and has no effect on a third-party banking app. Roaming may affect connectivity or data charges, but it does not trigger integrity or compliance checks. When root is confirmed on a device holding work data, the correct response is to protect accounts and sessions, quarantine the device in MDM, preserve approved work data, and wipe and re-enroll according to policy before restoring access in stages.

A spoofed or malicious app is the most likely cause. Spoofed apps copy icons, names, and screens, then use urgency and familiarity to collect logins. Warning signs include a login prompt that appears suddenly, asks you to 're-verify,' looks almost right but has odd fonts or spacing, and pushes for high-risk permissions such as Accessibility, SMS, or device admin early. A real bank app opens from your own tap, uses saved biometrics, and shows consistent screens with minimal permission needs. A legitimate security update would not appear as a look-alike login overlay demanding Accessibility access to 'help you log in faster.' A normal biometric re-enrollment happens within the trusted app flow and does not request Accessibility control. A cached browser page cannot request Accessibility service permissions, which is an OS-level control an app must ask for. If an app needs Accessibility to log you in faster, treat it as an attack until proven otherwise. The correct response is to isolate the device, disable the high-risk permissions, remove any device admin rights, uninstall the app, and change passwords from a clean device.

Opening the data usage view and sorting apps by usage is the correct first step because it identifies which app or service is consuming the most data. An app you barely use sitting at the top is a strong clue that something is calling home or is adware-like, while a top talker such as Photos or a cloud backup usually points to a normal sync. This built-in screen lets you confirm the cause before making changes. Performing a factory reset is far too drastic as a first step and erases the evidence needed to identify and prevent the issue. Uninstalling every app from the past year makes cause-and-effect impossible to determine; the correct approach is to remove recent apps one at a time and re-check usage. Replacing the SIM card addresses connectivity or carrier problems, not data consumption from an app. After sorting by usage, a technician should compare foreground versus background data, review permissions, and check for unknown VPN profiles that could reroute and hide traffic before uninstalling the most recent suspicious app.

Closing the browser from the app switcher without tapping anything inside the alert is the safest action. Fake security warnings are designed to rush users into a mistake, and even buttons labeled 'OK' or 'Cancel' can trigger a download or redirect. Exiting the app entirely avoids interacting with the malicious script at all. Tapping OK to dismiss the warning is risky because the buttons within these overlays cannot be trusted and may perform an action other than closing. Calling the number plays directly into the scam; real system alerts never ask you to call a random number, and doing so connects the user to the attacker. Installing the recommended cleaner app is exactly what the scam wants, since these fake 'security' or 'cleaner' apps from unknown links are often the malware itself. After closing the browser, the correct follow-up is to clear browser history and site data, run built-in checks like Google Play Protect, update the OS and apps, and if credentials were entered, change passwords from a known-safe device and enable MFA.

When limited access disappears after the VPN is disabled, the VPN or proxy configuration should be treated as the lead cause, not the Wi-Fi. An always-on VPN can block all traffic when it fails or is misconfigured, routing data into a dead end even though the device shows a connection. This is also a potential security signal worth documenting, since unknown VPN profiles can indicate a compromised or improperly managed device. A router firmware update is unlikely to be the cause because the problem was resolved by a change on the device itself, not the network hardware. A failed SIM card would cause the loss of cellular service entirely, but the issue occurred on both Wi-Fi and cellular and was fixed by disabling the VPN. Critically full storage causes app crashes and sluggish performance, not a routing failure that is corrected by turning off a VPN. Because connectivity returned only after removing the VPN, the technician should document what was found before making further changes and verify whether the VPN profile is authorized.

Deploying apps through MDM-managed installs and approved catalogs is the recommended approach because it maintains a known chain of trust from download to update. MDM can push required apps, block unknown sources, enforce settings, and control versions, while official stores and private enterprise catalogs provide signing, review, and clear publisher identity. Allowing users to install APK files sent through email is a major red flag, because email bypasses store checks, files can be swapped without warning, and accounts can be compromised so even a familiar sender is not proof of safety. Enabling install from unknown sources on all devices removes the store guardrails that screen for malicious behavior and directly increases the attack surface. Letting users download from any third-party store removes signing checks and clean update paths, which is exactly how spoofed and malicious apps spread. Managed environments should follow the principle of least privilege so users cannot enable unknown sources or grant device admin without approval, maintain an approved app allowlist, and provide user training on checking publisher names and avoiding install links from messages.

Reviewing email forwarding rules and filters is most likely to reveal an account takeover, because email acts as the control panel for compromised accounts. Attackers commonly add a rule that forwards mail to an outside address or auto-archives security alerts so the victim never sees new sign-in notices or password reset messages. Finding an unexplained forwarding address or a filter that hides security mail is strong evidence of misuse. Location permissions can leak where the user is, but they do not explain how files were copied out or how an account was accessed remotely. The Bluetooth pairing list is part of tightening local sharing paths, yet it does not expose a remote account takeover. Storage usage shows which apps hold the most data and says nothing about where that data went. Once the device is contained, the technician should also review sign-in alerts, remove unknown devices from the account, audit cloud sharing links, enable MFA, and change passwords from a known-safe device, because accounts outlive devices and ignoring account access lets the leak return.