220-1202 — CompTIA A+ Core 2 Scenario Practice Guide

How to Read 220-1202 Scenario Questions

The CompTIA A+ Core 2 (220-1202) exam expects more than memorizing definitions. Many questions describe a user problem, a technician action, a security requirement, or an operational situation, then ask you to choose the best next step.

A strong scenario answer usually comes from slowing down and identifying:

• The environment: Windows, macOS, Linux, mobile, workgroup, domain, local device, shared system, or managed endpoint.
• The user goal or symptom: What is the technician trying to accomplish or fix?
• The current system state: What changed, what works, what fails, and who is affected?
• The constraint: Time, data preservation, company policy, least privilege, safety, privacy, or minimal disruption.
• The decision point: Are you choosing a tool, command, configuration, security control, troubleshooting step, or communication action?

The best answer is not always the most powerful action. It is the action that fits the facts, respects the constraints, and follows sound support practice.

Start by Finding the Actual Question

Before solving the scenario, identify what the question is asking you to decide.

Common decision words include:

• FIRST: Choose the immediate first action in a process.
• NEXT: Continue from the current point in the workflow.
• BEST: Choose the most complete and defensible option.
• MOST likely: Identify the explanation most supported by the facts.
• MINIMUM / LEAST: Choose the smallest acceptable change.
• MOST secure: Prioritize security, least privilege, and risk reduction.
• WITHOUT affecting users / data: Preserve availability or data while solving the problem.

Do not treat every scenario as “fix the issue immediately.” Some questions ask for diagnosis, containment, documentation, escalation, user communication, or validation.

Use a Core 2 Scenario Reading Sequence

When a scenario feels long, use this sequence.

1. Identify the platform and management context

Core 2 scenarios often depend on where the work is being performed.

Ask:

• Is this Windows, macOS, Linux, Android, iOS, or a browser-based app?
• Is the device standalone, domain-joined, cloud-managed, or personally owned?
• Is the technician working with local settings, user profile settings, permissions, policies, services, logs, or applications?
• Is the affected user a standard user, administrator, remote user, executive, shared workstation user, or mobile user?

This matters because the same symptom may require a different tool depending on the environment.

For example:

• A Windows startup issue may point you toward Startup settings, Safe Mode, System Restore, Event Viewer, Services, Task Manager, or recovery tools.
• A Linux permission issue may require interpreting ownership, groups, and file permissions.
• A mobile device security issue may involve screen locks, remote wipe, app permissions, MFA, or account synchronization.
• A domain or managed endpoint scenario may require following policy instead of making a local exception.

2. Separate the symptom from the cause

A symptom is what the user reports. The cause is what the technician must infer.

Examples:

• “The user cannot print” is a symptom.
• “The print spooler service is stopped” may be a cause.
• “The user receives access denied on a shared folder” is a symptom.
• “NTFS permissions do not grant the user access” may be a cause.
• “The computer is slow and pop-ups appear” is a symptom.
• “Possible malware infection” may be the working diagnosis.

Choose answers based on what the scenario proves, not on what could be true in a different case.

3. Find the scope of impact

Scope helps you decide whether the issue is local, user-specific, application-specific, network-related, security-related, or policy-related.

Look for clues:

• One user only: Profile, permissions, account, mapped drive, application settings, local credentials.
• One device only: Local OS, service, driver, storage, malware, configuration, update issue.
• All users on one device: Machine-wide setting, service, local policy, OS issue, installed application.
• All users in one department: Group policy, permissions, shared resource, recent change, application deployment.
• Many devices after a change: Patch, update, policy, configuration rollout, security control.

The broader the impact, the more likely the answer involves a central change, documented escalation, or rollback rather than a one-device fix.

4. Identify the constraint

Core 2 scenario questions frequently include constraints that decide the answer.

Important constraints include:

• Data must be preserved
• Company policy must be followed
• User should not receive local administrator rights
• Least privilege is required
• System downtime must be minimized
• Personal or confidential information must be protected
• The issue may involve malware or unauthorized access
• The technician must document or communicate before proceeding

If two answers both solve the technical problem, the correct answer is often the one that also satisfies the constraint.

5. Choose the least disruptive defensible action

A+ support scenarios usually favor a controlled progression:

1. Verify the issue.
2. Identify recent changes.
3. Use available logs, messages, or symptoms.
4. Apply the smallest reasonable fix.
5. Test the result.
6. Document the action and communicate with the user.

That does not mean you always gather more information first. If the scenario describes active malware, a safety hazard, suspected data exposure, or a clear policy violation, the best first step may be containment, safety, or escalation.

Match the Answer Type to the Scenario

If the question asks for a tool

Choose the tool that matches the task, not merely a tool that sounds technical.

Examples of tool matching:

• Event Viewer: Review Windows logs for application, system, or security events.
• Task Manager: View running processes, resource usage, startup impact, or end tasks.
• Services: Start, stop, restart, or configure Windows services.
• Device Manager: View hardware status and driver issues.
• Disk Management: Manage partitions, volumes, drive letters, and disk status.
• Local Users and Groups: Manage local accounts and groups where applicable.
• Group Policy tools: Apply or verify policy in managed Windows environments.
• Windows Security / firewall settings: Review protection status and local firewall rules.
• Credential Manager: Manage stored Windows credentials.
• Command-line utilities: Use platform-appropriate commands when the scenario calls for direct verification or repair.

The right tool is the one closest to the decision point. If the scenario gives a log error, a log viewer may be the next best step. If it identifies a stopped service, service management may be the answer.

If the question asks for a command

Read the platform first. Do not select a Windows command for a Linux scenario or a Linux command for a Windows-only task unless the scenario clearly supports it.

Think in categories:

• File and directory navigation
• Permissions and ownership
• Process and service management
• Network verification
• System repair or integrity checks
• User and account administration
• Disk and storage review

If the command options are unfamiliar, use the scenario’s nouns. A question about permissions is unlikely to be solved by a disk-health command. A question about a running process is unlikely to be solved by changing folder ownership.

If the question asks for a configuration

Identify what must change and at what scope:

• User-level setting
• Device-level setting
• Application setting
• Local security setting
• Network or firewall rule
• Permission assignment
• Mobile device setting
• Browser or email setting
• Managed policy

Then choose the smallest configuration that meets the requirement.

For example, if a user needs read-only access to a folder, granting full control is not the best answer. If a standard user needs an approved application, permanently adding the user to a local Administrators group is usually less defensible than using an approved installation or deployment method.

If the question asks for a troubleshooting step

Use the stage of troubleshooting described in the question.

Ask:

• Has the problem been verified?
• Is there a known recent change?
• Has the cause already been identified?
• Has a fix already been applied?
• Is the question asking for validation?
• Is documentation or escalation required?

If the scenario says the technician has already implemented a fix, the next step is often to verify full system functionality and confirm with the user before documenting closure.

Core 2 Fact Patterns to Practice

Operating system scenarios

For OS questions, first determine whether the scenario is about access, startup, performance, updates, applications, services, storage, or user profiles.

Useful questions to ask:

• Is the issue happening before login, during login, after login, or only when launching an app?
• Is it tied to one profile or the entire system?
• Did it begin after an update, driver change, software installation, or policy change?
• Is the system bootable?
• Are you expected to repair, roll back, restore, reinstall, or collect more evidence?

Typical reasoning:

• If only one user profile is affected, investigate user settings, profile corruption, permissions, or stored credentials.
• If all users are affected on one device, investigate system services, installed applications, drivers, malware, or OS configuration.
• If the issue began after a recent change, consider rollback, uninstall, restore point, or configuration review before drastic repair.
• If the OS is unstable but data matters, preserve data and use repair options before destructive actions.

Security scenarios

Security questions often include a business rule or risk statement. Do not ignore it.

Look for:

• Required authentication method
• Password or account policy
• Least privilege requirement
• Physical security requirement
• Data classification or privacy concern
• Malware indicators
• Social engineering behavior
• Need for encryption
• Need for secure disposal
• Need to report or escalate

Use this decision path:

1. Protect people, data, and systems first.
2. Contain active threats.
3. Use least privilege.
4. Follow policy and escalation paths.
5. Validate and document the outcome.

For example, if a device is suspected of malware infection and is still connected to the network, containment may be more important than immediately deleting files. If a user asks for administrator rights to complete routine work, the more secure answer is usually to provide the needed access through an approved method, not to grant broad privileges.

Software troubleshooting scenarios

Software scenarios often involve installation failures, application crashes, browser issues, email problems, file associations, compatibility, or resource usage.

Read for:

• Error message wording
• Whether the problem affects one app or many apps
• Whether it affects one user or all users
• Recent updates or installations
• Required permissions
• Compatibility mode or OS version clues
• Available storage or resource constraints
• Browser cache, extension, certificate, or pop-up behavior

A practical sequence:

• Reproduce the problem if possible.
• Check whether it is user-specific or system-wide.
• Review recent changes.
• Check logs or error messages.
• Try the least disruptive fix.
• Reinstall, reset, or repair only when simpler actions are not supported by the facts or have already failed.

Operational procedure scenarios

Operational procedure questions are not just “soft skills.” They often determine the correct technical answer.

Watch for:

• Change management
• Documentation
• Asset handling
• Privacy and confidentiality
• Professional communication
• Safety and environmental procedures
• Incident escalation
• Chain of custody language
• Backups before risky work
• User authorization and consent

If a scenario involves user data, company records, suspicious activity, or regulated information, the best answer may be to follow the organization’s procedure rather than taking an independent technical shortcut.

Interpret Scenario Clues Precisely

Use the wording of the scenario as evidence.

Do not add facts that are not present. If the scenario does not say a device is domain-joined, do not assume domain tools are available. If it does not say data is backed up, avoid destructive choices unless the question clearly supports them.

Permission and Access Scenarios

Permissions are common in Core 2-style reasoning because they combine technical accuracy with least privilege.

When reading an access scenario, identify:

• Local access or network access
• User account or group membership
• File system permissions
• Share permissions
• Inherited permissions
• Explicit allow or deny entries
• Whether the user needs read, modify, or full control
• Whether the access should be temporary or permanent

A defensible answer grants only the access required. If a user needs to read reports, assign read access through the appropriate group. If a user needs to modify a shared folder, grant modify permissions to the right group rather than giving broad administrative rights.

For network shares, remember that effective access may depend on both share permissions and file system permissions. For local access, file system permissions are usually the key control.

Malware and Incident Scenarios

When a scenario suggests malware, prioritize containment and protection before convenience.

Look for indicators such as:

• Unexpected pop-ups
• Browser redirects
• Disabled security tools
• Unknown startup items
• Unusual system slowness
• User reports of suspicious links or attachments
• Files encrypted or renamed unexpectedly
• Security alerts
• Unauthorized account activity

A common decision sequence is:

1. Identify and confirm symptoms.
2. Isolate the affected system if there is risk to the network.
3. Follow organizational incident procedures.
4. Use approved anti-malware tools or recovery methods.
5. Remove or remediate the threat.
6. Update systems and security tools.
7. Restore data from known-good backups if needed.
8. Educate the user and document the incident.

If the scenario includes potential evidence, unauthorized access, or company policy language, avoid actions that could destroy evidence or bypass reporting procedures.

Least Privilege and Administrative Rights

Many answers appear to solve the immediate request by granting more access. On Core 2, the best answer often preserves least privilege.

Ask:

• What exact task must the user perform?
• Is administrator access truly required?
• Can the technician perform the task with elevated credentials?
• Can access be granted through a group or approved tool?
• Is the request temporary or ongoing?
• Does policy prohibit local administrator rights?

Example reasoning:

A user needs a printer installed, but company policy says users must not be local administrators. The most defensible answer is not to add the user to the Administrators group. A better answer is to install the printer using approved administrative credentials or an approved deployment method.

Choosing Between Similar Answers

When two answers seem technically possible, rank them using these questions:

1. Which answer directly addresses the stated symptom or goal?
2. Which answer uses the correct platform or tool?
3. Which answer preserves data and availability?
4. Which answer follows least privilege?
5. Which answer is reversible or minimally disruptive?
6. Which answer fits the troubleshooting stage described?
7. Which answer follows policy, documentation, or escalation requirements?

The best answer is usually the one that satisfies the most scenario facts with the fewest unsupported assumptions.

Short Scenario Walkthroughs

Example 1: One user cannot open a shared folder

A user reports “access denied” when opening a department share. Other users in the department can access it. The user recently changed roles.

Reasoning:

• Scope: one user.
• Resource: shared folder.
• Likely decision area: permissions or group membership.
• Constraint: access should match the new role.
• Best direction: verify the user’s group membership and effective permissions, then adjust access through the appropriate group.

Avoid broad fixes such as changing permissions for everyone or giving the user full control unless the scenario specifically requires it.

Example 2: Application fails after an update

A Windows application crashes when opened after a recent update. Other applications work normally. The user needs the system available today.

Reasoning:

• Scope: one application.
• Change clue: recent update.
• Constraint: availability.
• Best direction: review the application error, repair or roll back the application/update if supported, or use a known working version according to policy.

A full OS reinstall would be too disruptive unless the scenario says other repairs failed or the OS is broadly corrupted.

Example 3: Suspicious email and credential concern

A user clicked a link in an email and entered credentials on a suspicious page. The device still works normally.

Reasoning:

• Primary risk: credential compromise, not necessarily hardware failure.
• Security response: report/escalate according to policy, change or reset credentials, review account activity, and enable or verify MFA if applicable.
• If malware indicators exist, also contain and scan the endpoint.

The best answer should protect the account and follow incident procedure, not just delete the email.

Example 4: Standard user needs software

A standard user needs an approved business application installed. The user asks to be made a local administrator.

Reasoning:

• Goal: install approved software.
• Constraint: least privilege.
• Best direction: install through an approved administrative or software deployment process.
• Avoid granting persistent administrative rights unless policy explicitly supports it.

Performance-Based and Multi-Step Scenarios

For performance-based or interactive scenario tasks, work from requirements to configuration.

Use this checklist:

• Restate the required outcome in plain language.
• List each required setting or action.
• Identify the correct device, user, folder, policy, or app.
• Apply only the changes needed.
• Recheck the scenario for constraints such as security, naming, order, or access level.
• Validate that your final configuration satisfies every requirement.

Do not rush into clicking or selecting options before you know the target state. In configuration tasks, the most common scoring risk is completing part of the requirement while missing a constraint.

Final Review Checklist for 220-1202 Scenarios

Before selecting an answer, pause and ask:

• What is the actual decision point?
• What platform or environment is named?
• Who or what is affected?
• What changed recently?
• Is this a symptom, a cause, or a required outcome?
• Is there a security, privacy, safety, or policy requirement?
• Does the answer preserve data?
• Does the answer use least privilege?
• Is the answer appropriate for the current troubleshooting stage?
• Am I choosing from the facts given rather than assumptions?

If an answer is technically impressive but ignores the scenario’s constraint, it is probably not the most defensible choice.

Practical Next Step

Use scenario practice in short, focused sessions. Drill one Core 2 area at a time, such as operating system tools, permissions, malware response, or software troubleshooting. After each question, explain why the correct answer fits the facts and why the other plausible answers are less defensible. Then take mixed mock exams to practice switching between technical, security, and operational decision-making under exam timing.