1.0 Operating Systems

Boot methods are the different ways a computer can start from installation media, recovery tools, local storage, network services, or another operating system.

For Objective 1.2, installation does not begin when the setup wizard appears. It begins when the technician chooses how the system will boot. The boot method determines where the computer looks for startup files, which firmware settings must be enabled, what media or network services are required, and whether the installation can happen locally, remotely, over the internet, or from an existing drive.

Think of booting as the handoff between firmware and the operating system installer.

• USB storage: A bootable USB flash drive is one of the most common installation methods. It is portable, fast, reusable, and useful when the device has no optical drive. The firmware must be configured to allow USB boot, and the USB must be built correctly for the target system.
• PXE network boot: PXE, often pronounced "pixie," lets a computer boot across the network and receive installation or imaging instructions from deployment services. The computer, firmware, network adapter, DHCP environment, and deployment server must all support the process.
• Solid-state or hard drives: Internal SSDs and hard drives may store operating system installation files, recovery partitions, or deployment images. A technician may install to a separate drive, boot from a prepared internal drive, or use a local recovery environment.
• Internet-based boot or recovery: Some systems can install or recover an OS through online services. Examples include Linux distribution installers, macOS Recovery, cloud recovery options, and Windows update or recovery workflows.
• External or hot-swappable drives: External USB storage, removable drives, and certain hot-swappable storage setups can be used for installation media, recovery images, or ISO-based workflows when supported by firmware and hardware.
• Multiboot: A multiboot system lets a user choose between two or more operating systems at startup, such as Windows and Linux. This requires careful partitioning, bootloader configuration, and data-protection planning.

The most common mistake is assuming the installer is the problem when the system never actually booted into the installer. If the firmware boot order points to the internal drive first, the system may skip the USB drive entirely. If Secure Boot blocks unsigned or unsupported media, the installer may fail before loading. If PXE is disabled, the network deployment option may never appear. If the system is configured for UEFI but the media was built for legacy BIOS, the boot device may not show up as expected.

Common boot-method scenario clues:

• No optical drive or quick local install: Use bootable USB media.
• Many computers need the same image: Consider PXE or another network deployment method.
• System recovery without local media: Consider internet-based recovery, vendor recovery, or cloud recovery options.
• Installer files stored locally: Look for internal recovery partitions, local installation files, or a prepared internal drive.
• External media is attached but ignored: Check boot order, one-time boot menu, USB boot support, Secure Boot, and UEFI/legacy compatibility.
• User chooses Windows or Linux at startup: Think multiboot and bootloader configuration.

Technician mindset:

• Use the one-time boot menu when you need to test a boot device without permanently changing the boot order.
• Confirm the USB installer was created for the correct OS, architecture, partition style, and boot mode.
• For PXE, verify network link, DHCP scope, boot server availability, VLAN access, and whether network boot is enabled in firmware.
• Before using internet recovery, verify network connectivity, power, account requirements, vendor support, and whether the device is still eligible for recovery services.
• Before installing to or booting from an internal drive, confirm the target drive is detected, healthy, partitioned correctly, and backed up if user data exists.
• Before configuring multiboot, plan partitions, bootloader order, encryption, backups, time synchronization, and how the user will recover if one OS breaks the bootloader.

Installation methods describe how the operating system is placed onto the device, configured for the user, and prepared for reliable use.

After choosing how the computer will boot, the technician must choose the actual installation approach. A single user with a corrupted system may need a repair installation or recovery partition. A new workstation may need a clean install. A company preparing hundreds of laptops may need an image deployment or zero-touch deployment. The best method depends on the amount of data to preserve, the number of devices, available infrastructure, user downtime, driver needs, security requirements, and how consistent the final configuration must be.

The exam is looking for the method that fits the situation, not the method that sounds most powerful.

• Clean install: Erases the existing operating system and installs a fresh copy. This is useful when the device needs a clean slate, malware or corruption is severe, or the system is being repurposed. User data, settings, licenses, and apps must be backed up or migrated first.
• Image deployment: Applies a preconfigured OS image to one or many computers. Images create repeatable systems with standard settings, apps, drivers, security baselines, and policies. They save time across many devices but must be maintained and updated.
• Remote network installation: Installs the OS from a network location, deployment share, local server, cloud service, or remote management platform. This is useful for large-scale rollouts, distributed teams, and environments where local media is not practical.
• Recovery partition: Uses a hidden or dedicated partition containing recovery tools, factory restore files, or OS repair resources. This is helpful when the OS will not boot or when the device must be restored without separate installation media.
• Repair installation: Reinstalls or refreshes system components to fix OS problems while attempting to preserve personal files, settings, and sometimes installed apps. It is less disruptive than a full reinstall when user data must remain in place.
• Zero-touch deployment: Installs, configures, enrolls, secures, and prepares the device with little to no user interaction. The goal is for the user to power on the system and reach a ready-to-work environment.

Installation planning also includes hardware and driver readiness. Storage, network, chipset, graphics, audio, biometric, wireless, Bluetooth, printer, docking station, and management drivers can affect whether the OS installs properly and whether the finished system is usable. If the installer cannot see the storage controller or network adapter, the installation may fail or stop before the technician can continue. If post-install drivers are missing, the system may boot but still be incomplete.

Common installation-method scenario clues:

• Start over completely: Clean install, after backup and migration planning.
• Deploy the same build repeatedly: Image deployment or zero-touch deployment.
• Install from a server, deployment share, or remote service: Remote network installation.
• Restore a system that will not boot: Recovery partition, recovery media, repair install, or vendor recovery workflow.
• Keep user files while repairing OS components: Repair installation or reset/refresh option that preserves data.
• Ship devices to users already configured: Zero-touch deployment with enrollment, policies, apps, and account readiness.
• Installer cannot find the disk or network: Load required storage, network, or chipset drivers.

Technician mindset:

• Before a clean install, verify backups, license information, user files, browser data, application installers, product keys, encryption recovery keys, and required drivers.
• Before image deployment, confirm the image is current, compatible with the hardware model, patched, licensed, and built with the right applications and security baseline.
• Before remote network installation, verify network connectivity, deployment server access, credentials, bandwidth, VLAN/firewall rules, and whether the device can boot or enroll correctly.
• Before using a recovery partition, confirm whether the restore will preserve user data or return the system to factory state.
• Before repair installation, document the symptom, back up important data, and confirm the method preserves what the user expects it to preserve.
• Before zero-touch deployment, verify enrollment rules, identity requirements, management profiles, app assignments, compliance policies, and first-time user experience.

Partitioning and formatting prepare storage so an operating system can be installed, booted, organized, and protected.

A physical disk is just raw storage until the system knows how to divide it and how to store files on it. Partitioning divides a drive into manageable sections. Formatting applies a file system to a partition so the operating system can create folders, save files, track free space, enforce permissions, and recover from some errors. For the A+ exam, partitioning and formatting are not just setup chores. They affect boot compatibility, drive size support, dual-boot design, data safety, recovery options, and whether the operating system can install successfully.

Partition first, format second: partitioning defines the sections; formatting makes a section usable as a volume.

• Partition: A defined section of a physical drive. One disk can have one partition or multiple partitions depending on the installation plan.
• Volume: A formatted storage area the operating system can use. In Microsoft terminology, a formatted partition is commonly treated as a volume.
• File system: The structure applied during formatting, such as NTFS, exFAT, FAT32, APFS, ext4, or XFS.
• Boot partition/system partition: Boot-related partitions hold files needed to start the OS. The exact terminology can vary by operating system and tool.
• Recovery partition: A dedicated partition that stores recovery tools or factory restore files.

Partitioning choices should be made before installing the operating system when possible. Existing partitions may contain user data, recovery tools, boot files, vendor utilities, or another operating system. Deleting or reformatting the wrong partition can erase data or make the system unbootable. A technician should identify each disk and partition carefully before making changes.

GPT versus MBR:

• GPT: GUID Partition Table is the modern partitioning standard. It uses a unique identifier for each partition, works with UEFI-based systems, supports many partitions, and handles very large drives. Windows can currently use very large GPT partitions, and GPT avoids the old extended/logical partition workaround.
• MBR: Master Boot Record is the older partitioning method used with legacy BIOS systems. It is limited compared with GPT, including a practical 2 TB partition limit and a four-primary-partition structure.
• Primary partition: In MBR, primary partitions can be bootable, and one primary partition can be marked active.
• Extended partition: In MBR, an extended partition is used to go beyond the four-primary-partition limit by holding logical drives.
• Logical drive: A logical drive exists inside an extended partition and is not used the same way as a primary boot partition.

Boot mode and partition style must match. A modern UEFI installation typically uses GPT. A legacy BIOS installation commonly uses MBR. Some systems offer BIOS compatibility or legacy support mode, but using compatibility mode may disable or interfere with UEFI features such as Secure Boot. On real devices, the technician may need to check firmware settings before deciding whether to convert, repartition, or reinstall.

Quick format versus full format:

• Quick format: Creates a new file system and makes the drive appear empty to the OS, but it does not scan the entire drive for bad sectors. It is fast and is often the default choice during normal Windows installations.
• Full format: Writes across the drive, scans for bad sectors, and takes longer. It is better when preparing a questionable drive, clearing a drive more thoroughly, or investigating storage problems.
• Data warning: Formatting can remove access to existing files. A quick format does not securely erase all underlying data, but normal users may not be able to recover it without special tools.

Technician mindset:

• Before changing partitions, identify the correct physical disk, confirm the target partition, and back up important data.
• Check whether the device boots in UEFI or legacy BIOS mode before choosing GPT or MBR.
• Do not delete recovery, EFI, system, or vendor partitions unless the installation plan specifically requires it and data has been protected.
• Use Disk Management or installation tools carefully; the wrong disk selection can wipe the wrong drive.
• For dual-boot systems, plan space, bootloader behavior, encryption, backups, and how each OS will access shared data.
• When a drive reports errors or behaves unpredictably, consider a full format or storage diagnostics before trusting it with user data.

A system upgrade changes the operating system while trying to keep users productive, preserve what matters, and move the device to a supported, secure state.

For Objective 1.2, a technician must know when to upgrade an existing operating system and when to install fresh. An upgrade is not just a newer version number. It is a planned change that can affect user files, applications, drivers, device performance, security controls, account sign-in, encryption, backups, and business workflows. A good upgrade plan reduces downtime, protects data, and gives the user a stable system afterward.

The main decision: preserve the existing environment or start over with a clean slate.

• In-place upgrade: Updates the existing operating system while keeping applications, documents, settings, user profiles, and local configuration in place when supported. Setup usually runs from within the current OS, and the goal is minimal disruption.
• Clean install: Removes the existing operating system and installs a fresh copy. This is better when the system is badly corrupted, infected, unstable, being repurposed, or needs a completely standardized build.
• Upgrade path: The supported route from the current OS version and edition to the target version and edition. Unsupported paths may require a clean install or staged migration.
• Rollback path: The plan for restoring the device, user data, or previous OS state if the upgrade fails or breaks required apps.

In-place upgrades are popular because they save time and preserve the user experience. Users can often keep their files, installed applications, preferences, local accounts, desktop layout, browser data, printers, and application settings. This approach is valuable when disruption must be low, the current system is healthy, and applications are compatible with the target operating system. However, an in-place upgrade can also carry forward old problems, unused software, misconfigurations, driver conflicts, or malware remnants if the existing system is not clean.

Clean installs take more planning because they remove what is already there, but they can produce a cleaner, more reliable result. A clean install is often the better choice for major OS changes, severe troubleshooting, device repurposing, new ownership, unknown system history, or standardized deployment. The tradeoff is that user data, settings, apps, licenses, and preferences must be backed up, migrated, reinstalled, or reconfigured afterward.

Why upgrade?

• Security: Move away from unsupported or vulnerable systems and gain current patches, protections, and compliance support.
• Compatibility: Support newer applications, drivers, hardware, browsers, management tools, and cloud services.
• Consistency: Bring multiple devices to a standard OS version, edition, configuration, and policy baseline.
• Productivity: Keep users working by preserving files, settings, and applications when an in-place upgrade is appropriate.
• Lifecycle: Replace systems approaching end of support before they become a security or operational risk.

Common upgrade scenario clues:

• User must keep apps and settings: Consider an in-place upgrade if the current OS is healthy and the upgrade path is supported.
• System is unstable or heavily compromised: Consider a clean install after data protection and recovery planning.
• Major version change or repurposed device: Clean install may provide the best long-term result.
• Business needs consistent settings: Use imaging, provisioning, or managed deployment after selecting the correct upgrade or install path.
• Upgrade might fail: Confirm backups, rollback options, power, storage space, app compatibility, driver readiness, and encryption recovery keys.

Technician mindset:

• Before upgrading, verify hardware requirements, TPM/Secure Boot requirements when applicable, CPU/RAM/storage capacity, available disk space, and firmware readiness.
• Back up user data and confirm the backup can be restored before changing the OS.
• Check application compatibility, licensing, browser requirements, line-of-business apps, VPN tools, printer software, and security agents.
• Confirm driver availability for storage, chipset, graphics, wireless, Ethernet, audio, docking stations, biometric devices, and specialty peripherals.
• Protect encryption recovery keys and confirm the user or organization can unlock the device if the upgrade changes boot or security state.
• After the upgrade, test sign-in, network access, important applications, printers, mapped drives, security tools, updates, backups, and user files.
• Document the upgrade method, version changes, issues found, fixes applied, and verification results.

Installation preparation protects user data, confirms the system can run the target OS, and prevents avoidable setup failures.

A smooth operating system installation is usually won before the first reboot. Technicians should not rush directly into setup just because installation media is available. The safer process is to understand the drive, protect the data, verify requirements, check compatibility, gather needed information, and prepare drivers or recovery paths. A few minutes of preparation can prevent hours of troubleshooting or permanent data loss.

Preparation answers the question: are we ready to let setup change this system?

• Understand the drive: Identify whether the drive already contains data, whether it has been formatted before, which partitions or volumes are present, and which disk is the actual installation target.
• Protect what matters: Back up user files, application data, browser data, local profiles, encryption keys, product keys, configuration files, and anything else the user expects to keep.
• Let setup do the heavy lifting: Modern OS installers can often create, delete, partition, and format the target drive, but the technician must know what will be erased and what will remain.
• Use a clean target when appropriate: Starting with a clean drive or clean partition can reduce inherited problems, but it should never happen before data is protected.

Before installation, confirm both minimum and recommended system requirements. Minimum requirements tell you whether the OS can install. Recommended requirements tell you whether the user experience will be acceptable. A system that barely meets minimum RAM, storage, CPU, TPM, Secure Boot, graphics, or firmware requirements may install successfully but perform poorly afterward. For Windows 11 scenarios, tools such as PC Health Check may appear as compatibility clues.

Pre-installation checks:

• System requirements: CPU, RAM, storage capacity, graphics, firmware mode, TPM/Secure Boot where required, and OS edition support.
• Hardware compatibility: Confirm the target OS supports the motherboard, chipset, storage controller, network adapter, Wi-Fi, Bluetooth, graphics, audio, camera, biometric device, docking station, printer, and specialty peripherals.
• Application compatibility: Verify required business apps, security tools, VPN clients, browser requirements, plug-ins, drivers, and licensing support the target OS.
• Installation details: Have the drive/partition plan, product key or digital license status, account requirements, network credentials, encryption recovery keys, and deployment instructions ready.
• Driver readiness: Download or stage storage, network, chipset, and device drivers when the installer might not include them.
• Power and network: Use AC power for laptops and confirm reliable internet/network access for activation, updates, account sign-in, or remote installation.

Drive preparation is especially important because installation tools can be destructive. The installer may show multiple disks, removable drives, recovery partitions, EFI partitions, or unallocated space. Choosing the wrong disk can wipe the wrong device. Deleting the wrong partition can remove recovery tools or boot files. Formatting the wrong volume can make user data unavailable. When in doubt, stop and confirm the drive identity before continuing.

Common readiness scenario clues:

• Unsure whether the drive contains data: Back it up first, then inspect partitions and volumes.
• Upgrade is planned: Run compatibility checks and verify apps, drivers, and hardware support before setup.
• Clean install is planned: Confirm user data, preferences, licenses, and recovery keys are saved before erasing anything.
• Installer cannot see the drive: Check storage mode, controller drivers, firmware settings, or drive health.
• Installer cannot reach the network: Check network drivers, Wi-Fi/Ethernet support, deployment server access, or internet requirements.
• User needs the system immediately after install: Plan app installation, driver updates, account setup, security tools, printers, and file restoration before starting.

Technician mindset:

• Ask what the user needs to keep before deciding what to erase.
• Confirm the backup exists, is recent, and can be restored before formatting or repartitioning.
• Record the current OS version, edition, architecture, activation status, device name, accounts, and important applications before changing the system.
• Verify the target drive by size, model, connection type, and partition layout, not by guesswork.
• Stage critical drivers and network access before starting if the installer may need them.
• Keep recovery media or a rollback plan available until the new installation is verified.

Windows 11 readiness is about more than storage and memory. The device must meet modern security, firmware, and hardware expectations before the upgrade or installation is supported.

Objective 1.2 expects technicians to verify whether a system can install or upgrade to the target operating system. Windows 11 is a major example because it introduced stricter requirements than earlier Windows versions. A computer may run Windows 10 well but still fail Windows 11 readiness checks because of processor support, TPM version, firmware mode, Secure Boot capability, or other hardware requirements.

Do not begin the upgrade until the hardware and security foundation is verified.

• Core hardware requirements: Verify the CPU, RAM, storage, graphics, display, firmware, TPM, and Secure Boot requirements for the target Windows 11 edition and deployment scenario.
• TPM 2.0: Trusted Platform Module 2.0 is required for Windows 11 compatibility. TPM supports security features such as BitLocker, Windows Hello, credential protection, measured boot, and hardware-backed trust.
• UEFI firmware: Windows 11 expects a modern UEFI-based boot environment. Devices using legacy BIOS mode may require firmware changes or disk conversion before installation.
• Secure Boot: Secure Boot helps prevent unauthorized bootloaders and some pre-OS malware from loading. The system must support Secure Boot, and it may need to be enabled in firmware.
• Supported processor and platform: Some older PCs may have enough RAM and storage but still fail because the processor or chipset is not supported.

Technicians should use supported tools and vendor information before making a recommendation. Microsoft compatibility tools, PC Health Check, Windows Setup checks, System Information, firmware setup screens, and the TPM management console can all provide clues. The image references tpm.msc, which opens the TPM management console in Windows and helps confirm whether TPM is present, ready, and compatible.

Important readiness checks:

• Run compatibility checks: Use PC Health Check or Windows Setup readiness checks when planning a Windows 11 upgrade.
• Check TPM: Use tpm.msc, Device Manager, Security processor settings, or firmware settings to confirm TPM presence and version.
• Check firmware mode: Use System Information to verify BIOS Mode is UEFI when required.
• Check Secure Boot: Use System Information, firmware settings, or security settings to confirm Secure Boot state.
• Confirm disk style: UEFI boot normally pairs with GPT. A legacy MBR installation may need conversion planning before moving to a UEFI Windows 11 installation.
• Review manufacturer support: Some devices require firmware updates, TPM enablement, BIOS settings changes, or may not support Windows 11 at all.

Security features work together. TPM provides hardware-backed key storage and trust. UEFI provides the modern firmware environment. Secure Boot helps protect the boot process. BitLocker, Windows Hello, credential protections, and modern Windows security features build on that foundation. If one required piece is missing or disabled, the installation or upgrade may be blocked or unsupported.

Common Windows 11 scenario clues:

• Upgrade blocked by hardware check: Verify CPU support, TPM 2.0, Secure Boot, UEFI, RAM, and storage.
• TPM not detected: Check tpm.msc, firmware settings, security processor settings, or whether a firmware update is needed.
• Secure Boot unavailable: Confirm UEFI mode. Older legacy BIOS systems may not support Secure Boot.
• System boots in legacy mode: Review MBR/GPT state, UEFI settings, and whether conversion or clean installation is safer.
• Older PC works fine today: Working performance does not guarantee Windows 11 support. Check the manufacturer and official requirements.

Technician mindset:

• Verify compatibility before promising a Windows 11 upgrade to a user or business.
• Record the current OS version, device model, BIOS/UEFI version, TPM status, Secure Boot state, processor model, RAM, and storage before changes.
• Back up data and protect BitLocker recovery keys before changing firmware, TPM, Secure Boot, or partition settings.
• Be cautious when switching from legacy BIOS to UEFI or converting MBR to GPT. A mistake can make the system unbootable.
• After upgrade or installation, verify activation, updates, drivers, security status, device encryption, Windows Hello, applications, and user data.
• If the PC is not supported, recommend a supported OS path, hardware replacement, or lifecycle plan instead of forcing an unsupported upgrade.

The Windows lifecycle is Microsofts structured plan for keeping Windows secure, current, supported, and predictable over time.

Operating system installation and upgrade decisions are not only about what works today. A technician also needs to know whether the operating system will continue receiving updates, fixes, security patches, and support. Windows follows a lifecycle model that defines when versions are released, how long they are supported, when updates arrive, and when organizations must plan the next upgrade.

A supported Windows version is safer, easier to manage, and less risky than one that has reached end of support.

• Reliable monthly updates: Windows receives regular monthly updates that deliver security patches, bug fixes, stability improvements, and quality updates. These updates help close vulnerabilities and resolve known issues.
• New capabilities over time: Larger feature updates or major releases introduce new capabilities, interface changes, security improvements, hardware support, and management enhancements.
• Support after release: Microsoft supports each Windows release for a limited period. Support timelines vary by Windows version, edition, channel, and lifecycle policy.
• Modern Lifecycle Policy: Microsofts modern lifecycle approach applies to products that are continuously serviced and supported, as long as the customer stays current and follows servicing requirements.

The lifecycle matters during installation planning because installing an operating system near the end of support is a poor long-term decision. A technically successful installation can still be the wrong answer if security updates will end soon. Organizations need enough support runway to keep systems patched, compliant, and manageable. Home users also benefit from staying current because supported systems receive fixes and compatibility improvements.

Lifecycle terms technicians should recognize:

• Quality update: A regular update that focuses on security, reliability, and bug fixes rather than major new features.
• Feature update: A larger update or release that may introduce new capabilities, security improvements, and platform changes.
• Servicing: The ongoing process of keeping Windows updated and supported through patches and releases.
• End of support: The point when a version no longer receives normal updates or support. Systems beyond this point become security and compliance risks.
• Edition and channel: Support timelines can differ between Home, Pro, Enterprise, Education, LTSC, and other servicing channels.

Most standard Windows releases receive a defined support period after release. The exact number of months can vary, but the important exam idea is that support is limited. The image highlights typical support windows such as 18 to 36 months for many modern releases, depending on edition and version. Technicians should verify the current Microsoft lifecycle documentation before making a production recommendation.

Common lifecycle scenario clues:

• The system is no longer receiving updates: Treat it as an end-of-support security risk and plan an upgrade or replacement.
• A business wants a stable standard build: Choose a supported Windows version with enough lifecycle runway for the deployment plan.
• A feature update is available: Test application, driver, and hardware compatibility before broad rollout.
• Monthly updates keep failing: Troubleshoot update health, disk space, services, network access, and policy restrictions.
• Older hardware is still in use: Confirm whether it supports the next supported Windows version before promising an upgrade.

Technician mindset:

• Before installing or upgrading Windows, check whether the target version and edition are currently supported.
• Do not recommend a version that is close to end of support unless there is a documented short-term reason and a migration plan.
• For organizations, test feature updates with business apps, VPN clients, security tools, printers, drivers, and management policies before broad deployment.
• Track update compliance so systems do not silently fall behind on security patches.
• Document lifecycle concerns in upgrade recommendations so users understand that unsupported systems are security risks.
• Use Microsoft lifecycle information and organizational policy to plan when devices should upgrade, be replaced, or be retired.

Objective 1.2 is about choosing the safest, most appropriate installation or upgrade path for the scenario, then verifying the system works afterward.

Installation and upgrade questions are decision questions. The exam may mention boot media, PXE, clean installs, image deployment, recovery partitions, GPT, MBR, Windows 11 requirements, user data, or end-of-support risk. Your job is to connect the clue to the correct method and avoid unnecessary risk. A good technician protects data first, confirms compatibility, chooses the right path, performs the work carefully, verifies the result, and documents what changed.

Know the purpose of each major decision area:

• Boot methods: USB, PXE, internal drives, external drives, internet recovery, and multiboot determine how the system reaches the installer or operating system.
• Installation methods: Clean install, image deployment, remote network installation, recovery partition, repair installation, and zero-touch deployment solve different problems.
• Partitioning and formatting: GPT, MBR, partitions, volumes, quick format, and full format affect boot support, disk size, recovery, data safety, and installation success.
• Upgrade strategy: In-place upgrades preserve apps, files, and settings when supported; clean installs start over and are better for severe problems, repurposing, or standardization.
• Preparation: Readiness checks include backups, drive contents, system requirements, hardware support, app compatibility, drivers, product keys, accounts, and recovery keys.
• Windows 11 readiness: Verify TPM 2.0, UEFI, Secure Boot, supported hardware, PC Health Check results, tpm.msc, and manufacturer support.
• Windows lifecycle: Supported versions receive updates and support. End-of-support systems become security, compliance, and reliability risks.

Scenario clues matter more than habit.

• If the system must boot from removable local media, think bootable USB and firmware boot order.
• If many computers need the same standard build, think image deployment, PXE, remote deployment, or zero-touch deployment.
• If the user needs to keep files, apps, and settings, think in-place upgrade or repair install when supported.
• If the device is being repurposed or the OS is severely damaged, think clean install after backup and license planning.
• If the question mentions UEFI, very large disks, or modern Windows installation, think GPT.
• If the question mentions older BIOS systems or a four-primary-partition limit, think MBR.
• If the question mentions Windows 11 compatibility, think TPM 2.0, UEFI, Secure Boot, CPU support, PC Health Check, and tpm.msc.
• If the question mentions updates ending, unsupported versions, or staying current, think Windows lifecycle and upgrade planning.

High-value reminders:

• Backups come first: Partitioning, formatting, clean installs, upgrades, and firmware changes can all affect data availability.
• Firmware matters: Boot order, USB boot, PXE, UEFI, legacy BIOS, Secure Boot, TPM, and storage detection can block setup before the installer starts.
• Compatibility is layered: Check hardware, firmware, drivers, apps, licensing, accounts, encryption, and management tools.
• Clean install is not always best: It gives a clean slate but requires migration, app reinstall, license recovery, and user reconfiguration.
• In-place upgrade is not always safe: It preserves the environment but can carry forward old problems if the current OS is unhealthy.
• Unsupported is a risk: An OS that no longer receives updates should be treated as a security and lifecycle problem.

Technician mindset:

• Never erase, repartition, or format until you know what is on the drive and whether it is backed up.
• Use the least disruptive method that meets the technical requirement and protects the user.
• Verify the target OS is supported on the hardware before promising an upgrade.
• Keep recovery media, rollback options, and encryption recovery keys available until the work is verified.
• After installation or upgrade, test sign-in, network, updates, drivers, apps, printers, security tools, and user data.
• Document the method, settings changed, problems found, and verification results so the next technician can trust the handoff.

Complete 20 multiple-choice questions in the Core 1 final exam style: 15 scenario-based questions and 5 rote memory questions. Each question has one best answer and three plausible distractors. Read each question like a technician: identify the user need, protect the data, verify requirements, choose the correct boot, installation, partition, or upgrade method, then confirm supportability and document the result.