Free Features and Tools of MacOS practice questions

A .dmg file is a disk image that mounts like a temporary drive in Finder. The proper installation flow is to drag the .app icon out of the mounted image and into the Applications folder, then launch it from there and eject the disk image. Dragging the app to Applications ensures the software lives in its permanent home where it can update correctly. Launching the app directly from the mounted disk image is a poor practice because the app may fail to update and can break if the image is not mounted later. Copying the .dmg file into the Applications folder is incorrect because the .dmg is only a wrapper; you need the .app bundle inside it, not the image itself. Moving the .dmg into the Utilities folder accomplishes nothing, as the Utilities folder holds built-in macOS tools and the disk image still would not install the application. After confirming the app runs from Applications, the technician should eject the mounted volume and delete the original .dmg from Downloads.

The ~/Library folder (also written as /Users/username/Library) stores per-user support files, preferences, and caches. Because only one user is affected, the problem is isolated to that user's environment, and settings that keep resetting typically point to the preferences stored in ~/Library/Preferences for that account. /Library holds system-wide support files and settings that affect all users, so a problem there would cause multiple users to experience the same failure rather than just one. /System contains core macOS components that are read-only on modern macOS and are not where application preferences are stored, so it is never the place to troubleshoot user setting issues. /Applications simply holds the app bundle itself and does not store the per-user preference files that control individual settings. When a symptom affects only one user, the technician should focus on that user's home directory and ~/Library first, following least-privilege troubleshooting habits.

A .pkg installer can place files in multiple locations and often adds components such as menu bar items, background services, network extensions, or system extensions that macOS requires the user to approve separately in System Settings. For VPN clients that rely on network filtering, a missing extension approval will make the app appear broken even though the installer succeeded. Placing the app in ~/Applications instead of /Applications does not disable a network extension; the location of the app bundle alone does not stop VPN filtering from functioning. Ejecting is a step associated with .dmg disk images, not .pkg installers, so failing to eject a .pkg is not the issue. Emptying the Trash relates to uninstallation and freeing storage after removing an app, and has nothing to do with a freshly installed VPN not filtering traffic. When an app's core function depends on a system component, missing approval commonly looks like a failed install even when the installation completed correctly.

When macOS displays an X on an app icon in Launchpad, this is the most direct removal method for Mac App Store apps. Clicking the X and confirming Delete removes the main app bundle in one step, which matches how the app was installed through the App Store. Dragging the app from /Library to the Trash is incorrect because apps live in /Applications, not /Library, which stores support files rather than the app bundle itself. Running a third-party one-click cleanup utility is discouraged because these tools can remove shared components or management items and cause new problems; vendor-approved or built-in methods should be used instead. Removing an app receipt from the /System folder is both incorrect and unsafe, as /System is protected on modern macOS and receipts are not stored there. The Launchpad X is available specifically for App Store apps and provides the cleanest single-step removal path.

A security block at first launch is often a helpful signal rather than an inconvenience, and a download obtained through a pop-up ad is a common source of altered or fake installers. The safest first step is to re-download the installer directly from the official vendor page, since a corrupted, incomplete, or look-alike download causes a surprising number of "can't be opened" errors, and the trusted source resolves them. Disabling System Integrity Protection weakens macOS security and is not an appropriate response to a routine Gatekeeper block; it exposes the system to greater risk. Copying the app into /System is both unsafe and ineffective, because /System is a read-only, protected area on modern macOS and is not where applications belong. Granting Full Disk Access does not address a Gatekeeper block caused by an untrusted source and could give an unverified app unwarranted permissions. Gatekeeper checks apps downloaded from outside the App Store using code signing and notarization, so a blocked launch usually points to a bad source or a stale build.

When an app continues to run after the bundle is removed, the leftover behavior usually points to startup items. On modern macOS, the technician should review System Settings > General > Login Items and remove entries related to the uninstalled app, especially helpers that start on login. This is common for sync tools, VPN menu bar apps, and update agents that install background components outside the app bundle. The /System frameworks directory is not where user app helpers live, and it is a protected, read-only area that should not be edited during routine support. The Downloads folder is only a transit area for downloaded files and does not launch persistent background processes, so removing items there would not stop the menu bar helper. The App Store Purchased history section only tracks ownership and re-download availability for App Store apps and has no ability to disable a running background item. Removing related Login Items and background items is the correct step for "it's still running" reports after an app has been deleted.

macOS uses UNIX-style absolute paths that begin with a forward slash, so /Applications is a real folder at the top level of the startup disk even though Finder may label that disk with a friendly name like "Macintosh HD." Recognizing the true absolute path helps technicians navigate reliably. The path written as Macintosh HD/Applications reflects only the Finder display label and is not the correct absolute path format; the file system uses /Applications. The ~/Library folder is a classic example of a location Finder hides by default, and it typically requires the Go menu or a view setting change to reveal, so it is not always visible. The /System folder is protected on modern macOS through a read-only system volume design and System Integrity Protection, meaning even admin accounts generally cannot freely write to it. Understanding the difference between what Finder shows and what the file system contains explains why a user may claim a folder "isn't there" when it actually exists at its correct path.

On a shared Mac, a "my files are missing" report is most often explained by the user signing into the wrong account, since each account has its own home folder under /Users with separate Desktop and Documents locations. Another common cause is iCloud Drive settings, where Desktop and Documents may sync to iCloud, making local files appear to move even though macOS is simply following sync rules. The Desktop folder does not reside on the /System volume; personal files live in the user's home directory under /Users, so a deletion from /System is not the cause. Files are not automatically moved into /Library, which stores shared app support files and settings rather than user documents. A .pkg installer places application and support files but does not relocate a user's personal documents during setup, so that is not a plausible cause. The technician should confirm the correct login and check iCloud sync settings before assuming any data loss has occurred.

Apps installed with a .pkg often place files in multiple locations and add system-wide support files, background services, and extensions, so a simple drag-to-Trash removal leaves working parts behind. The best approach is to use the vendor-provided uninstaller app, uninstall script, or documented removal steps, because these typically stop services first and then remove files in the correct order. This matters especially for VPNs, printers, and management agents whose components load at boot or run under system contexts. Deleting folders inside /System is unsafe and incorrect, because /System is protected on modern macOS and app components are not stored there; removing the wrong item could cause boot or update problems. Installing a random third-party uninstaller is discouraged because these "one-click cleanup" tools can remove shared components or management items and create new issues. Simply emptying the Trash and restarting does nothing to stop the background services and network extension that the installer added. For PKG-based apps, the safest uninstall is usually the one the vendor designed.

When cleaning leftovers, the technician should stay conservative and remove only items that clearly match the app name, vendor name, or a known bundle identifier. If the purpose of a file is unclear, the safest approach is to move it to a temporary folder rather than deleting it outright, then restart and test to confirm nothing breaks before permanently removing it. Deleting an unclear item immediately is risky because removing the wrong file, especially from /Library, can break drivers, background services, or managed settings and create problems that look like a macOS failure. Copying the item into /System is both unnecessary and unsafe, because /System is a protected, read-only area on modern macOS and is not a storage location for support files. Renaming the file and leaving it in place does not verify whether it is safe to remove and may still allow it to be loaded by the system. A cautious "move, restart, test, then delete only clear matches" workflow protects the system while cleaning up.