2.0 Security

Microsoft Defender Antivirus is the built-in Windows malware protection layer that runs through Windows Security, watches the system in real time, and stays effective by receiving current threat definitions.

For Objective 2.2, treat Defender Antivirus as a normal part of Windows security, not as a separate add-on a technician must hunt down and install. A supported Windows device normally includes this protection out of the box. That matters in troubleshooting because the first question is not usually, "Which antivirus should I buy?" The first question is, "Is the built-in protection enabled, updated, healthy, and configured correctly for this device?"

Defender Antivirus helps block viruses, malware, and other threats before they can run, spread, modify files, or abuse the user's account. It works alongside the Windows Security app, Windows Update, reputation-based protection, firewall settings, account controls, browser protections, and organization-managed endpoint policies. On a home computer, the user may see the controls directly. On a business device, some settings may be managed by policy, endpoint management, or a security operations team.

Built-In Protection

The key idea from the infographic is simple: Windows includes a baseline antivirus layer. A technician should expect to find it in the Windows Security app under Virus & threat protection. The exact layout can vary by Windows version, update level, edition, and management state, but the purpose stays the same. It protects the device continuously without requiring a separate third-party antivirus product.

That built-in status is important for support conversations. If a user says they never installed antivirus, that does not automatically mean the system is unprotected. Verify Windows Security first. Check whether Virus & threat protection is present, whether real-time protection is enabled, whether definitions are current, whether a scan is needed, and whether another security product has taken over protection duties.

Name Changes and Where to Look

Microsoft's security branding has changed over time, so users and exam scenarios may use more than one name for the same general protection area. You may hear Windows Defender, Microsoft Defender Antivirus, Microsoft Defender, Windows Security, or Virus & threat protection. Do not let the naming distract you. For Core 2, connect all of those clues back to built-in Windows endpoint protection and its management console.

Windows Security is the app students should remember. It centralizes security categories such as Virus & threat protection, account protection, firewall and network protection, app and browser control, device security, device performance and health, and family options. If the scenario asks where to view or adjust antivirus protection, Windows Security is the practical answer.

Real-Time Protection

Real-time protection is the active watch layer. Instead of waiting for a user to manually start a scan, Defender monitors files, downloads, scripts, attachments, processes, and activity as they happen. When suspicious behavior or known malware appears, the protection engine can block, quarantine, alert, or require action depending on policy and threat severity.

The infographic emphasizes that this setting can be turned on or off, but disabling it should be rare and temporary. Turning off real-time protection increases infection risk because the device loses a major layer of immediate detection. If a technician must disable it for troubleshooting, software installation, or a controlled test, the reason should be specific, the time window should be short, and the setting should be restored as soon as the task is complete.

Definition Updates

Antivirus protection depends on current security intelligence, often called definitions or signatures. These updates teach Defender about newly discovered threats, behavior patterns, indicators, and detection logic. A system with old definitions may still have the Defender feature installed, but it may not recognize newer malware effectively.

Definitions are usually updated automatically through Windows Update or the security intelligence update process. In a support scenario, however, "usually automatic" is not the same as "verified." If malware protection looks stale, check for updates in Windows Security, confirm the device has network access, review Windows Update health, and look for policies or errors that might block updates.

Technician Workflow

• Start in Windows Security: open Virus & threat protection and check the protection status before installing anything else.
• Verify real-time protection: confirm it is on unless there is a documented, temporary reason for disabling it.
• Check definitions: review the last security intelligence update and use Check for updates when protection may be out of date.
• Review alerts and history: look for quarantined items, blocked threats, incomplete remediation, or actions still required.
• Run the right scan: use quick, full, custom, or offline scans based on the symptom, risk, and time available.
• Respect managed settings: if controls are locked by an organization, follow policy and escalate instead of bypassing protections.
• Document the change: record update status, scan results, disabled settings, restored settings, and any user education provided.

Scenario Cues

• User asks where antivirus lives: open Windows Security and go to Virus & threat protection.
• Protection name looks different: recognize Windows Defender, Microsoft Defender Antivirus, and Virus & threat protection as related Windows security clues.
• Malware risk is active: keep real-time protection enabled and run an appropriate scan.
• Installer says antivirus must be disabled: verify the source, avoid unnecessary disabling, and re-enable protection immediately if a temporary exception is approved.
• Definitions are stale: check for security intelligence updates and confirm Windows Update or network connectivity is working.
• Settings are unavailable: check whether another antivirus product or organizational policy is managing protection.

Why It Matters

Defender Antivirus is one of the first Windows security controls a technician should verify because it is present on the device, easy to access, and directly tied to malware prevention. Keeping it enabled reduces the chance that a user mistake, malicious download, infected attachment, or compromised website turns into a full system cleanup.

For the exam, watch for wording that points to built-in protection, Windows Security, real-time scanning, disabled antivirus, stale definitions, or the need to check for updates. The best answer usually keeps protection active, updates the detection data, uses the appropriate scan, and avoids weakening the system unless there is a controlled, temporary, documented need.

Windows Firewall is the built-in network barrier that helps block unwanted traffic, allow trusted connections, and apply different rules depending on the network profile.

Where Microsoft Defender Antivirus watches for malicious files and behavior, Windows Firewall watches network communication. It helps decide which inbound and outbound connections are allowed, blocked, or governed by rules. For a technician, firewall support is about balancing protection with usability: the system should reject unwanted traffic without breaking legitimate applications, printers, remote tools, file sharing, updates, or business services.

The infographic frames Windows Firewall as built in and always on guard. That is the mindset to carry into Objective 2.2. A supported Windows device includes firewall protection, and the safest default is to keep it enabled. If a connection fails, do not immediately turn the firewall off. First identify the network profile, the application, the port, the direction of traffic, and whether a precise rule or approved exception would solve the issue with less risk.

Built-In Network Protection

Windows Firewall comes with Windows, so no extra firewall product is required for baseline host protection. It monitors network traffic and helps stop unauthorized connections. This is especially important on laptops, mobile workstations, shared computers, and devices that move between home networks, business networks, public Wi-Fi, classrooms, hotels, airports, and customer sites.

The firewall usually runs quietly in the background. A user may only notice it when an application is blocked, a notification appears, or a program requests permission to communicate on a network. Those prompts matter. Allowing an unknown program through the firewall can expose the device, while blocking a required business application can interrupt work. The technician's job is to identify the program and choose the narrowest safe access.

Keep It Enabled

The firewall should stay on at all times unless there is a specific, short-term, documented reason to disable it. Disabling Windows Firewall increases the chance that unsolicited traffic, vulnerable services, scanning activity, or malicious connections can reach the device. In many environments, turning it off may also violate policy or trigger security alerts.

If troubleshooting requires a firewall test, make the test controlled. Confirm administrator rights, note the current profile and settings, disable only what is necessary, test quickly, and turn protection back on immediately. If the problem disappears only when the firewall is disabled, that is not the final fix. It is evidence that a rule, profile, application exception, service dependency, or port requirement needs to be reviewed.

Network Profiles

Windows applies firewall behavior based on network profiles. A private network profile is used for trusted networks, such as a home or internal office network, where device discovery or sharing may be appropriate. A public network profile is used for untrusted or unknown networks, such as public Wi-Fi, hotels, airports, coffee shops, guest networks, or any environment where nearby devices should not be trusted.

Public networks should use stricter protection because the device may be surrounded by unknown systems. Private networks allow more flexibility, but private does not mean unsecured. It simply means the user or organization has identified the network as trusted enough for certain discovery, sharing, or application behaviors. Choosing the wrong profile can cause real symptoms: a printer might not be discovered, file sharing might fail, or a device may become more exposed than intended.

Firewall Configuration

Firewall configuration controls how strict the device should be. One high-security option is to block all incoming connections. This can be useful on unknown or untrusted networks because it ignores allowed exceptions and provides maximum inbound protection. The tradeoff is that helpful connections can stop too, including legitimate sharing, remote access, discovery, or application traffic.

Because firewall rules can affect connectivity, configuration changes should be deliberate. Know whether the traffic is inbound or outbound. Identify the application or service. Confirm the port and protocol when needed. Understand the network profile where the rule applies. Avoid broad exceptions such as allowing every port or every network when a specific app, port, or profile rule would solve the problem.

Where to Manage It

Windows Firewall can be managed from Windows Security or through Control Panel firewall tools. Windows Security is the modern place to review firewall and network protection, see active profiles, manage notifications, and understand which security providers are active. Control Panel and advanced firewall tools may expose more detailed rule management, especially when a technician needs inbound rules, outbound rules, profile-specific settings, or administrative configuration.

Administrator rights are usually required to make meaningful firewall changes. If the setting is managed by an organization, the user may not be able to change it locally. In that case, document the need, gather the application or port requirements, and escalate through the approved support or security process instead of bypassing policy.

Advanced Options

Notifications can alert users or technicians about firewall activity and blocked connections. They can be useful when troubleshooting because they reveal when Windows is preventing an app from communicating. Notification behavior can be adjusted per profile, but reducing notifications should not be confused with reducing risk. A quiet firewall can still be protecting the system, and a noisy firewall may simply need better rules.

Security provider information shows which tools are active on the device, including antivirus, firewall, and web protection. This is useful when multiple security products are installed or when a managed endpoint security suite controls Windows Firewall behavior. If another provider is responsible for firewall protection, avoid making assumptions from the Windows interface alone; verify the active provider and the organization's intended configuration.

Technician Workflow

• Check the active profile: determine whether the connection is using a private, public, or domain-managed network profile.
• Keep the firewall on: avoid disabling it as a permanent fix; use a precise rule or approved exception when possible.
• Identify the traffic: confirm the app, service, port, protocol, source, destination, and direction before changing rules.
• Use profile-specific rules: allow traffic only on the networks where it is actually needed.
• Be careful with inbound traffic: unsolicited inbound connections usually carry more risk than outbound requests from trusted apps.
• Review notifications and providers: use alerts and provider status to understand what is blocking or managing protection.
• Verify and document: test the connection, confirm protection is still enabled, and record exactly what changed.

Scenario Cues

• User is on public Wi-Fi: use the public profile and stricter firewall behavior.
• Home printer or file sharing stops working: check whether the network was marked public instead of private.
• A business app cannot connect: identify the required app, port, protocol, and profile before creating an exception.
• A vendor asks to turn off the firewall: verify the need, avoid broad disabling, and prefer a temporary, documented rule.
• Unknown network detected: keep protection strict and avoid enabling discovery or broad inbound access.
• Firewall options are locked: check for administrator rights, domain policy, endpoint management, or another active security provider.

Exam Mindset

Core 2 firewall questions often test restraint. The tempting answer may be to disable the firewall so something works quickly. The better answer is usually to keep the firewall enabled, choose the correct profile, allow only the required trusted traffic, and understand the security impact before changing anything.

Watch for profile clues. Private network means more trust and flexibility. Public network means extra caution and stricter protection. Blocking all incoming connections provides stronger protection, but it can interrupt legitimate services, so use it when extra security is needed and the connectivity tradeoff is acceptable.

Users and groups define who can sign in, what they can do, and how Windows permissions stay manageable across many people and devices.

Windows security is not only about malware protection and firewall rules. It is also about identity. Every user account represents a person, service, temporary visitor, administrator, or managed identity that may interact with the system. Each account should have the correct level of access for the job, no more and no less.

The infographic focuses on users and groups managed through Active Directory. In a business environment, Active Directory helps organize identities, computers, groups, permissions, policies, and access to shared resources. Instead of configuring every user one at a time on every workstation, administrators can assign users to groups and then grant permissions to the group. That keeps access more consistent, auditable, and easier to remove when someone changes roles or leaves the organization.

User Accounts

A user account defines what a person can do on a Windows system. The account controls sign-in, profile access, file permissions, application rights, network resource access, and sometimes policy settings. If a user cannot perform a task, the technician should first determine whether the problem is authentication, authorization, local permissions, group membership, policy scope, or an application-specific role.

Account type matters because different account types carry different risk. An account with too little access interrupts work. An account with too much access increases the chance that a mistake, malware infection, stolen password, or phishing attack can cause system-wide damage.

Administrators

An administrator account has the highest level of control on a Windows system. Administrators can install software, change system settings, manage users, modify security controls, access protected areas, configure devices, and perform system-wide maintenance. That power is useful for support, but it also creates serious risk.

For Core 2, remember that administrator access should be intentional. Everyday work should not normally be done from an administrator account. If malware runs under an administrator context, it may gain the ability to disable protections, install persistence, change services, tamper with files, or affect other users. When a user needs one elevated task completed, use approved elevation methods rather than permanently placing that user in an administrator group.

Guest Accounts

A guest account is meant for restricted, temporary, or occasional access. It should have limited permissions and should not be used for normal day-to-day work. In many environments, guest-style access is disabled, tightly controlled, or replaced with named temporary accounts so activity can still be tied to a specific person.

The main weakness of shared guest access is accountability. If several people use the same guest account, it becomes harder to prove who performed an action. When temporary access is required, a better design is often a time-limited account, a visitor workflow, or a controlled access group with automatic expiration.

Standard Users

A standard user account is designed for normal daily work. Standard users can sign in, use approved applications, access authorized files, print, browse, communicate, and complete assigned tasks without making broad system-wide changes. This is the account type that best supports least privilege for most people.

Standard user restrictions are not a punishment; they are protection. They reduce accidental damage, limit what malware can do, and create a cleaner separation between ordinary work and administrative maintenance. If a standard user cannot install an app or change a protected setting, the right answer is usually to verify business need and use an approved admin process, not to make that user a permanent administrator.

Groups

Groups make permissions manageable for multiple users. Instead of assigning access separately to every person, an administrator can place users into a group and assign the group access to a folder, printer, application, VPN, shared mailbox, security policy, or administrative role. This simplifies management because access follows membership.

Groups also make audits cleaner. If a department should have access to a shared folder, the technician can review the group's membership instead of searching through many separate permissions. If a user changes jobs, removing them from the old group and adding them to the new group adjusts access more cleanly than editing every resource one by one.

Power Users

The Power Users group historically provided more capabilities than a standard user but less control than an administrator. It existed as a middle tier for users who needed additional local rights without full administrator authority. However, starting with Windows Vista and later versions, many of the older Power Users permissions were removed or reduced.

That history matters because old documentation, older systems, or legacy exam-style wording may still mention Power Users. In modern Windows environments, most organizations use more specific group designs and the principle of least privilege instead of relying on Power Users as a broad middle category. If a user needs a specific capability, assign the specific permission, role, policy, or application right required for that task.

Active Directory Management

Active Directory helps centralize user and group management. It can store user accounts, computer accounts, security groups, distribution groups, organizational units, Group Policy links, and other directory objects. This central structure helps organizations manage access at scale while keeping identities organized.

In a support scenario, Active Directory clues often include domain sign-in, domain users, domain admins, group membership, shared folder permissions, login restrictions, account lockouts, password resets, disabled accounts, expired accounts, and access based on department or role. A technician should check the account state and group membership before assuming the workstation itself is broken.

Least Privilege

The principle of least privilege means users should receive only the access needed to perform their job. Administrators should not grant broad rights because it is faster, easier, or convenient in the moment. More access means more risk, especially if the account is compromised.

Least privilege works best when groups are designed around real job roles. For example, help desk staff may need password reset permissions, but not domain administrator rights. Accounting users may need access to finance shares, but not engineering folders. A temporary contractor may need one application for two weeks, not permanent access to an entire department.

Technician Workflow

• Identify the user: confirm the exact account, domain, device, role, and resource involved.
• Check account state: look for disabled, locked, expired, or password-change-required conditions.
• Separate authentication from authorization: signing in successfully does not mean the user has permission to every resource.
• Review group membership: determine whether the user belongs to the correct security groups for the task.
• Prefer groups over one-off permissions: grant access through an approved group when possible so it can be audited and removed cleanly.
• Avoid permanent elevation: use temporary, approved administrative access when a standard user needs one elevated task.
• Document changes: record the request, approval, account, group, resource, permission, and verification result.

Scenario Cues

• User needs daily computer access: use a standard user account for normal work.
• User needs system-wide control: administrator rights may be required, but only for approved administrative tasks.
• Temporary visitor needs limited access: avoid broad rights and use restricted, time-limited access.
• Many users need the same resource: assign permissions to a group rather than editing each account individually.
• Power Users is mentioned: remember it historically offered more than standard user rights, but modern Windows uses more specific least-privilege designs.
• Domain resource access fails: check Active Directory account status, group membership, permissions, and policy scope.

Exam Mindset

Core 2 questions often describe a user who cannot access a file, install an application, change a setting, or perform an administrative task. Read carefully for whether the user needs authentication help, group membership, administrator elevation, a temporary account, or a least-privilege permission change.

The safest answer is usually the one that grants the smallest amount of access for the shortest necessary time through the most manageable method. In domain environments, that usually means using Active Directory groups, documenting approval, and verifying that the user can complete the required task without receiving unrelated permissions.

Windows sign-in options let users prove identity in different ways, including passwords, PINs, biometrics, single sign-on, and passwordless methods such as Windows Hello or security keys.

Objective 2.2 expects a technician to understand that signing in is more than typing a password. A Windows user may authenticate with a traditional username and password, a device-specific PIN, a fingerprint, facial recognition, domain credentials, SSO, or a passwordless flow. Each method balances convenience, security, device support, and management needs differently.

The infographic's main lesson is that one device can support several sign-in methods. The best method depends on the situation. A help desk technician should recognize what each method does, what problem it solves, what can go wrong, and how it fits into a larger security design that may include Active Directory, Microsoft Entra ID, multifactor authentication, conditional access, device management, and organizational policy.

Username and Password

Username and password sign-in is still one of the most common authentication methods. It is widely supported, familiar to users, and used across Windows, websites, cloud services, business applications, VPNs, email systems, and directory environments. Because it is so common, users often understand the basic workflow without much training.

The weakness is user behavior. Passwords can be weak, reused, guessed, phished, typed into fake sites, stored insecurely, shared, or exposed in data breaches. A strong password should be unique, long enough to resist guessing, protected from reuse, and combined with MFA where possible. Password resets should verify identity before changing access, because a password reset is effectively a door into the account.

PIN

A Windows PIN is a short code used to sign in to the device itself. It is designed for quick local access and is often tied to the device's security hardware and Windows Hello configuration. A PIN may feel weaker than a long password because it is shorter, but it is not the same as using the same short password everywhere. A properly configured PIN is device-specific and does not travel to every service the user accesses.

PIN sign-in is useful for everyday access because it is fast, easy, and less likely to be reused on random websites. It can keep the device accessible while still adding a security layer. A technician should know that PIN problems may involve Windows Hello enrollment, TPM or device security state, policy restrictions, account type, failed sign-in attempts, or a user forgetting the code.

Biometrics

Biometric sign-in uses a physical trait, such as a fingerprint or facial recognition, to help verify identity. Many modern laptops, tablets, and mobile devices include fingerprint readers, IR cameras, or facial recognition hardware. Biometrics are popular because they are fast and convenient while reducing reliance on typed passwords.

Biometrics also require careful handling. A fingerprint or face becomes part of the credential experience, so enrollment should happen on a trusted device, under the correct user profile, and according to organizational policy. If biometric sign-in fails, check the sensor, camera, lighting, driver, Windows Hello setup, account enrollment, and alternate sign-in method. A dirty fingerprint reader, poor lighting, blocked camera, changed appearance, or disabled Windows Hello policy can all affect success.

Single Sign-On

Single sign-on, or SSO, allows one sign-in process to unlock access to multiple approved applications or services. In Windows environments, SSO is common with domain credentials, Active Directory, Microsoft Entra ID, Microsoft 365, cloud applications, line-of-business tools, and managed enterprise services. The user signs in once and then receives access to authorized resources without repeatedly entering credentials.

SSO improves productivity and can strengthen security when implemented well because access is centralized, policy can be applied consistently, and account lifecycle changes can remove access across many systems. The risk is that one compromised account may provide broad access, so SSO should be protected with strong passwords, MFA, device compliance, conditional access, monitoring, and fast account disablement when compromise is suspected.

Passwordless Sign-In

Passwordless sign-in reduces or removes the need to type a password during normal access. Examples include Windows Hello facial recognition, fingerprint recognition, security keys, and managed passwordless authentication flows. Passwordless methods help address common password problems such as reuse, phishing, weak passwords, and password fatigue.

Passwordless does not mean "no security." It usually means the user proves identity through a stronger combination of device possession, local unlock, biometric proof, cryptographic keys, or approved factors. Passwordless methods may still exist alongside passwords or recovery methods, so those backup paths must also be protected. A secure passwordless deployment needs good enrollment, recovery, device management, and user education.

Why Passwords Still Matter

Passwords still matter because many breaches begin with poor password practices. Weak passwords, reused passwords, shared passwords, and passwords entered into phishing pages are common ways attackers gain initial access. Even when an organization uses SSO or passwordless sign-in, passwords may still exist for legacy systems, recovery flows, service accounts, local accounts, or emergency access.

Improper implementation can also create risk. If passwordless enrollment is weak, if recovery is easy to abuse, if users can bypass MFA, or if old passwords remain active without monitoring, the organization may think it improved security while leaving the real door open. Better password habits, stronger authentication, and careful implementation all work together.

Technician Workflow

• Identify the sign-in method: determine whether the user is using a password, PIN, biometric, SSO, security key, or passwordless flow.
• Confirm the account type: check whether the account is local, Microsoft, domain, cloud-managed, or tied to a business identity provider.
• Check policy: verify whether sign-in options are allowed, required, disabled, or managed by the organization.
• Verify enrollment: confirm the user is enrolled correctly for Windows Hello, biometrics, PIN, MFA, security key, or SSO.
• Protect recovery paths: reset passwords, PINs, factors, or biometric enrollment only after verifying identity and documenting approval.
• Use the right method: match convenience, security, device support, and access scope to the user's role and environment.
• Document the result: record the symptom, method, account, policy state, reset or enrollment action, and verification test.

Scenario Cues

• User needs broad compatibility: username and password is widely supported, but should be strong and protected with MFA when possible.
• User wants quick local device access: a Windows PIN or Windows Hello method may be appropriate.
• Fingerprint or face sign-in fails: check biometric enrollment, sensor hardware, drivers, lighting, and Windows Hello policy.
• User signs in once and accesses many apps: think SSO, domain credentials, or cloud identity integration.
• Organization wants fewer password problems: consider passwordless methods such as Windows Hello or security keys.
• Account compromise is suspected: reset credentials, revoke sessions where possible, review MFA, check sign-in logs, and document the incident.

Exam Mindset

Core 2 sign-in questions often ask for the best method for a specific user, device, or organization. Do not pick the method that sounds newest by default. Match the clue. Passwords are common and compatible. PINs are convenient for local device access. Biometrics are fast and tied to the user. SSO reduces repeated logins across many services. Passwordless methods reduce common password risks when implemented correctly.

Also watch for the difference between convenience and security. A method can be easy to use and still require careful enrollment, policy, recovery, monitoring, and fallback options. The strongest support answer keeps the user productive while protecting the account from weak passwords, credential theft, and unmanaged access.

NTFS permissions control access to files and folders on the file system, while share permissions control access only when users connect over the network.

Windows file access often depends on more than one permission layer. A user might be able to sign in, see the network, and open a shared folder path, but still be blocked from a file because NTFS permissions deny access. Another user might have NTFS permission to a folder but still fail over the network because the share permission is too restrictive. For Objective 2.2, the technician must know which layer applies and how the layers combine.

The infographic's big warning is that NTFS permissions and share permissions have different purposes, different reach, and both matter. NTFS permissions stay with the file or folder on an NTFS volume. Share permissions apply to network access through a shared folder. When both layers apply, Windows uses the more restrictive effective permission. That one rule explains many access problems.

NTFS Permissions

NTFS permissions control who can access files and folders no matter how they connect. They apply to local users sitting at the computer and to remote users accessing the resource over the network. Because NTFS permissions are part of the file system, they follow the data on the NTFS volume and remain important even if the folder is not shared.

Common NTFS permissions include read, write, modify, full control, list folder contents, read and execute, and special permissions. These determine whether a user can open files, create files, edit content, delete objects, run programs, view folder contents, change permissions, or take ownership. NTFS permissions are the deeper and more durable file-security layer.

Share Permissions

Share permissions control access only when people connect to a shared folder over the network. They do not affect a user who is physically signed in to the computer and browsing the folder locally. Share permissions are applied at the shared folder boundary and are typically simpler than NTFS permissions.

Common share permission levels include read, change, and full control. Share permissions can be useful as a second layer of control for network resources, but they should not be treated as a replacement for NTFS permissions. A strong design uses NTFS permissions to protect the data and share permissions to control the network doorway into that shared resource.

When Both Apply

When a user accesses a shared folder over the network, both share permissions and NTFS permissions apply. Windows evaluates the user's effective access through both layers, and the more restrictive result wins. If the share allows change but NTFS only allows read, the user effectively gets read. If NTFS allows modify but the share only allows read, the user effectively gets read.

Deny entries are especially powerful. If one layer says deny and another layer says allow, access is denied. This is why deny permissions should be used carefully. A broad deny can block users unexpectedly, including users who appear to have access through another group.

Explicit Permissions

Explicit permissions are set directly on a file, folder, or share. They are useful when a resource needs a specific access rule that does not simply follow the parent folder. For example, a department folder may inherit standard permissions from a parent, while a sensitive subfolder has explicit access for a smaller group.

Explicit permissions are powerful because they define exactly who gets what access at that object. They can also become messy if used too often. A technician should document why explicit permissions exist, who approved them, and whether they should remain after the business need ends.

Inherited Permissions

Inherited permissions are automatically passed down from a parent folder to child files and folders. This is the normal way to keep permission design manageable. Set the correct access on the parent folder, and the child objects beneath it receive the same baseline permissions unless inheritance is blocked or changed.

Inheritance saves time and keeps permissions consistent, but it can surprise users. If a folder is moved to a different folder on the same NTFS volume, it may keep its original permissions. If it is copied or moved in a way that causes it to inherit from a new parent, access may change. A technician should check the actual permissions on the object instead of assuming the path alone proves access.

Explicit vs. Inherited Rules

Explicit permissions generally override inherited permissions because they are set directly on the object. If a file has an explicit allow or deny entry, that direct rule can change the result even when the parent folder has a different inherited rule. However, inherited deny permissions can still create unexpected access problems, especially when users belong to multiple groups.

The practical lesson is to review effective access, not just one visible permission entry. A user may be a member of several groups, receive permissions from multiple paths, and be affected by both allow and deny entries. The final result is the effective permission Windows calculates from those layers.

Least Privilege Permission Design

Good permission design follows least privilege. Users should receive only the access needed for their role. Most users do not need full control. Many users only need read access. Some need change or modify access. A small number of administrators may need full control for management purposes.

In a domain environment, assign permissions to groups instead of individual users whenever possible. For example, use a security group for Accounting Read, Accounting Modify, or HR Confidential Access. Then place users into the correct group. This keeps access easier to audit, transfer, remove, and document.

Technician Workflow

• Identify how the user connects: local access uses NTFS permissions; network access may use both share and NTFS permissions.
• Check the share first for network paths: confirm the shared folder exists and the share permission allows the required access.
• Check NTFS permissions on the folder or file: verify the user or group has the correct file-system permission.
• Look for deny entries: remember that deny can override allow and can arrive through group membership.
• Review inheritance: determine whether permissions are inherited from a parent or explicitly set on the object.
• Use effective access: calculate or inspect the final permission result instead of trusting one group or one setting.
• Document changes: record the resource, user or group, permission level, approval, reason, and verification result.

Scenario Cues

• User can open a folder locally but not through a network share: check share permissions and the shared folder configuration.
• User can reach the share but cannot edit a file: check NTFS permissions and effective access.
• One permission says allow and another says deny: access is denied because deny is more restrictive.
• Access changed after moving a folder: review inheritance and whether permissions followed the object or changed with the new parent.
• Many users need the same folder access: assign permissions to a security group instead of individual accounts.
• A user needs temporary access: use a group or explicit permission with approval, documentation, and a removal plan.

Exam Mindset

Core 2 questions about file access often hide the answer in how the user connects. If the clue says the user is sitting at the computer, think NTFS permissions. If the clue says the user is connecting over the network to a shared folder, think share permissions plus NTFS permissions. If both apply, choose the more restrictive effective permission.

Do not assume "full control somewhere" means full control everywhere. A restrictive share permission can limit broad NTFS access over the network. A restrictive NTFS permission can block broad share access. Deny can override allow. Explicit settings can override inherited settings. The best answer is the one that identifies the correct layer and grants only the access required.

Run as administrator gives an application elevated privileges for a specific task, allowing system-level changes without making every app run with administrative rights by default.

Windows separates normal user activity from elevated administrative activity. Even when a user belongs to the local Administrators group, programs do not automatically run with full administrator rights. This behavior reduces accidental damage and helps limit what malicious software can do if it launches during ordinary work.

The Run as administrator option is the controlled way to give one trusted application extra authority for one task. It may be needed to install software, remove software, change protected settings, modify system files, manage services, write to protected folders, or run troubleshooting tools that need access beyond a standard user context. More power means more risk, so elevation should be intentional.

What It Does

Running an app as administrator lets that app perform actions that normally require administrative approval. Examples include modifying protected Windows files, writing to system directories, installing drivers, changing system-wide settings, editing certain registry areas, managing services, configuring security tools, or applying changes that affect every user on the computer.

This does not change the app into a different program. It changes the security context the app runs under. The same installer, command prompt, management console, or troubleshooting utility may behave differently when elevated because Windows grants it additional privileges for that session.

Why It Is Not Automatic

Being an administrator does not mean every program launches with administrator rights. Windows uses User Account Control, or UAC, to help separate standard operation from elevated operation. This helps prevent accidental changes, reduces the impact of malicious programs, and gives the user a moment to confirm that a program really should receive extra privileges.

If every application ran as administrator automatically, a browser, email attachment, script, game, or unknown installer could make broad system changes without a meaningful barrier. UAC and explicit elevation create a checkpoint. The user or technician must choose to elevate the application, and in many cases approve a UAC prompt before the program receives higher privileges.

When to Use It

Run as administrator is appropriate when the task truly needs a higher level of access. Common examples include troubleshooting system problems, installing or removing software, changing protected Windows settings, managing services, running administrative command-line tools, editing files in protected areas of Windows, or launching vendor tools that must touch drivers or system components.

The important phrase is "when needed." Do not use elevation for everyday browsing, email, document editing, chat apps, or unknown downloads. Elevation should come from a trusted source and a specific purpose. If the technician cannot explain why the app needs admin rights, that is a warning sign.

Right-Click Method

One common way to elevate a program is the right-click method. Locate the application, shortcut, installer, script, or management tool. Right-click it, select Run as administrator, and approve the UAC prompt if it appears. Depending on the account and policy, Windows may ask for confirmation or administrator credentials.

This method is useful when the technician can see the exact file being launched. It also gives a moment to verify that the file name, publisher, location, and purpose make sense before granting extra rights. Be cautious with installers from Downloads, removable media, email attachments, or unknown websites.

Search Method

The Start menu search method is another common path. Search for the application, such as Command Prompt, PowerShell, Device Manager, Services, Registry Editor, or a vendor utility. Then choose Run as administrator from the result options and approve the UAC prompt if it appears.

This method is especially useful for built-in Windows tools. For example, an elevated Command Prompt may be required for commands that modify system files, networking settings, service state, boot configuration, or protected directories. A normal command prompt may open successfully but fail when the command needs elevated rights.

UAC Prompts

A UAC prompt is Windows asking whether the elevated action should proceed. If the signed-in user is an administrator, the prompt may ask for approval. If the signed-in user is standard, it may ask for administrator credentials. In managed environments, policy can control how these prompts behave.

A technician should not treat UAC prompts as annoying pop-ups to click through blindly. The prompt is a security checkpoint. Verify the app name, publisher, file origin, and reason for elevation. If the prompt appears unexpectedly while browsing, opening a document, or running an unknown program, stop and investigate before approving it.

Risk and Responsibility

Administrative elevation increases the blast radius of mistakes and malware. An elevated app may be able to install services, change firewall rules, disable protections, alter system files, modify other users' data, or make changes that persist after reboot. That is why the infographic stresses using the option responsibly.

Use trusted sources, known tools, approved installers, documented procedures, and the least amount of elevation required. If a user requests permanent administrator rights because one task failed, look for a safer workflow: an approved install, temporary elevation, remote support session, software deployment tool, or a narrower permission change.

Technician Workflow

• Confirm the task: identify exactly what change requires elevated privileges.
• Verify the source: check the app name, publisher, location, download source, and business reason before elevation.
• Use elevation only when needed: do not run everyday apps or unknown programs as administrator.
• Approve UAC deliberately: review the prompt and provide credentials only when the request is expected and trusted.
• Complete the task: install, troubleshoot, modify settings, manage services, or access protected files as required.
• Return to normal context: close the elevated app when finished so later work does not continue with extra rights.
• Document the action: record what was elevated, why it was needed, who approved it, and what changed.

Scenario Cues

• Installer fails due to permissions: verify the installer is trusted, then run it as administrator if elevation is required.
• Command says access denied: check whether the command prompt or PowerShell session needs elevation.
• User needs to change protected settings: use an approved admin workflow instead of granting permanent administrator rights.
• UAC prompt appears unexpectedly: do not approve blindly; verify the program and reason first.
• Tool must manage services or drivers: administrative elevation may be necessary.
• Unknown app requests admin rights: treat it as suspicious until the source and purpose are confirmed.

Exam Mindset

Core 2 questions may describe a standard user, an administrator account, a UAC prompt, or an app that cannot change system settings. Remember that administrative membership and elevated execution are not the same thing. An administrator may still need to explicitly choose Run as administrator before the app receives elevated privileges.

The best answer usually grants elevation only for the specific trusted task. Avoid answers that permanently weaken the device, disable UAC, or give broad administrator rights when a controlled elevation would solve the problem. The right tool at the right time keeps the system more secure.

User Account Control is a built-in Windows safety check that helps prevent unwanted system changes by requiring approval before programs receive elevated privileges.

User Account Control, usually shortened to UAC, is one of the most visible Windows security controls because it interrupts the moment when an app wants more power. It does not replace antivirus, firewall rules, least privilege, or good account management. Instead, it adds a checkpoint between normal daily work and actions that can change the system.

The infographic frames UAC as a simple question: are you sure? That question matters because many risky changes happen when software tries to install, modify settings, alter protected files, change drivers, change services, or write to parts of Windows that ordinary apps should not touch. UAC gives the user or technician a chance to approve, deny, or investigate before the change proceeds.

What UAC Does

UAC helps prevent unauthorized changes to a Windows system. It controls which programs can run with elevated privileges and asks for permission when elevation is needed. That extra approval step makes it harder for unwanted software to silently gain the same power as an administrator.

When an app requests elevated access, Windows may display a UAC prompt. The prompt may ask an administrator to approve the action, or it may ask a standard user to enter administrator credentials. The exact behavior depends on account type, policy, application behavior, and system configuration.

Standard Users

Standard users are designed for everyday work. They can use the internet, access approved shared resources, work with files, run allowed applications, and change their own password. They usually cannot make major system changes, install many types of software, change protected settings, or modify areas of Windows that affect all users.

This limitation is useful. Standard accounts keep people productive while reducing the risk of accidental or unwanted changes. If a user clicks a malicious installer while using a standard account, that malware has a harder time making system-wide changes unless the user also provides administrative approval or credentials.

Administrators

Administrator accounts have greater control and greater responsibility. They can install software and hardware, make system configuration changes, manage security settings, configure Remote Desktop, change protected areas, and perform maintenance tasks that standard users cannot.

That power should be used carefully. Administrator access should not be the default answer to every support problem. A user who performs normal daily work as an administrator increases risk because mistakes and malware can have broader impact. The safer pattern is to use standard access for everyday work and elevate only when an approved task requires it.

Secure Desktop

UAC can display prompts on a separate secure desktop. This trusted prompt environment helps prevent malicious programs from automatically clicking Yes, spoofing the prompt, or gaining access through automated interaction. The screen may dim, and the user must respond directly to the UAC prompt before continuing.

The secure desktop is important because it protects the approval moment. Without that protection, a malicious program might try to interact with the prompt or trick the user through a fake window. The secure desktop reduces automated, unauthorized access and makes the elevation request more obvious.

UAC and Run as Administrator

UAC and Run as administrator are closely related. Run as administrator is a way to request elevated privileges for a trusted application. UAC is the control that asks whether that elevation should be allowed. Together, they support the idea that administrative power should be used only when needed.

If a technician right-clicks an app and chooses Run as administrator, UAC may appear. If a program launches and needs protected access, UAC may appear. If the prompt is unexpected, the safest response is to pause and verify the program, source, publisher, file location, and reason for elevation before approving.

Why UAC Matters

UAC helps limit software access and protect the computer from unwanted changes. It does not make the user invincible, and it does not prove that a program is safe. A user can still approve a harmful action. But UAC slows the moment down and makes privilege escalation visible, which can prevent silent or accidental system modification.

For organizations, UAC supports least privilege. Standard users can do normal work, while administrators use elevated rights for approved maintenance. This separation lowers risk, simplifies support, and makes it easier to explain why a user can do some things without being allowed to change the whole system.

Technician Workflow

• Read the prompt: check the app name, publisher, file location, and requested action before approving.
• Confirm the need: verify that the task truly requires elevated privileges.
• Match the account to the job: use standard accounts for daily work and administrator accounts for approved system changes.
• Do not bypass UAC casually: disabling or weakening UAC removes an important protection layer.
• Watch for unexpected prompts: a prompt that appears during normal browsing, document viewing, or idle time may signal risk.
• Use trusted sources: approve elevation only for known tools, approved installers, and legitimate support tasks.
• Document elevated work: record what was approved, why it was needed, what changed, and whether the issue was resolved.

Scenario Cues

• User can work with files but cannot install software: they are likely using standard user permissions, which is expected for daily work.
• A program requests permission to make changes: identify the UAC prompt and verify the app before approving.
• An admin action needs approval: UAC may require confirmation or administrator credentials.
• Malware tries to elevate automatically: secure desktop and UAC prompts help reduce automated unauthorized approval.
• User wants permanent admin rights: prefer standard access with controlled elevation for specific approved tasks.
• Remote Desktop or system configuration must be changed: administrator privileges may be required, but use them carefully.

Exam Mindset

Core 2 questions may describe a prompt asking whether an app should be allowed to make changes. That is a UAC clue. The point is not just clicking Yes or No; the point is understanding that Windows is asking for approval before elevated privileges are granted.

Choose answers that preserve least privilege and keep UAC as a protection layer. Standard users are for everyday tasks. Administrators are for system-level changes. UAC helps bridge the gap by asking for permission when elevated access is needed. Disabling UAC, ignoring prompts, or giving everyone administrator rights should look risky unless a very specific approved scenario says otherwise.

BitLocker is Windows full-disk encryption that protects data on a drive so files, settings, and the operating system remain unreadable without the correct unlock method or recovery key.

BitLocker protects data at rest. That means it is designed for the moment when a device is powered off, lost, stolen, removed from the user's control, or physically attacked. A password on a Windows account can stop casual sign-in, but it does not always protect the drive if someone removes the storage device and connects it to another computer. BitLocker closes that gap by encrypting the volume itself.

The infographic's core message is that encrypted data stays encrypted wherever the drive goes. A stolen laptop, removed SSD, or misplaced USB drive should not expose files just because someone has the physical hardware. Without the correct password, PIN, TPM-backed unlock, recovery key, or approved recovery process, the data remains out of reach.

What BitLocker Does

BitLocker encrypts the whole volume, including the operating system, user files, settings, applications, and other data stored on that protected drive. When the device starts normally and the proper unlock conditions are met, Windows can read the encrypted data transparently. To the authorized user, the device works normally. To someone without the unlock material, the drive contents should look like unreadable encrypted data.

This is especially important for laptops and portable workstations because those devices leave controlled spaces. A desktop in a locked office can still be stolen, but mobile devices face extra risk from travel, classrooms, cars, client sites, airports, hotels, and public areas. BitLocker helps keep the information safe even when the hardware is not.

Lost or Stolen Devices

If a BitLocker-protected device is lost or stolen, the data remains protected as long as the attacker cannot unlock the drive. A thief may still have the physical computer, but they should not be able to read the files by removing the drive or booting another operating system. That is the main reason full-disk encryption is a standard requirement in many organizations.

A technician should still follow incident procedures when a device is missing. Report the loss, document the device identity, preserve asset records, disable or revoke accounts when appropriate, review remote management options, and verify whether the recovery key is stored securely. BitLocker reduces data exposure, but it does not replace inventory, incident response, backups, or account protection.

Protection That Follows the Data

BitLocker protects the volume, not just the computer case. If the physical drive is removed and connected to another system, the encrypted information remains encrypted. This matters because attackers often bypass the installed operating system by moving the drive to a different machine or booting from external media.

Encryption also protects against accidental exposure during repair, recycling, warranty service, or device reassignment. Before sending a device out of the organization, confirm encryption state, backup status, recovery key storage, and data-handling policy. If the device is being retired, encryption may be one layer in a broader disposal plan, but it does not replace secure wiping or documented destruction when policy requires it.

BitLocker To Go

BitLocker To Go extends similar protection to removable drives such as USB flash drives and external storage. This is useful when users carry files between workstations, classrooms, client sites, home offices, or support locations. If the removable drive is lost, the data should remain locked unless the finder has the unlock password or recovery key.

Removable drives are easy to misplace, so BitLocker To Go is a practical control for portable data. A technician should encourage users to store sensitive data only on approved encrypted media, avoid unapproved personal USB drives, and follow policy for recovery keys. Encryption is only helpful if the user can still recover authorized data and the organization can manage access responsibly.

Recovery Keys

A BitLocker recovery key is critical. It is used when Windows needs proof that the person unlocking the drive is authorized, especially after hardware changes, firmware changes, TPM issues, boot configuration changes, policy changes, or forgotten unlock credentials. Losing the recovery key can mean losing access to the data.

In managed environments, recovery keys may be stored in Active Directory, Microsoft Entra ID, endpoint management platforms, or another approved escrow location. On personal systems, users may store recovery keys with a Microsoft account or another safe location. A technician should never casually expose, email, screenshot, or mishandle recovery keys because they can unlock protected data.

Edition and Availability

The infographic notes that BitLocker is built into Windows and is available in many editions, but not Windows Home in the traditional full BitLocker management sense. Some Windows Home devices may support device encryption, but Core 2 scenarios that specifically say BitLocker usually point to Pro, Enterprise, Education, or business-managed Windows environments.

That distinction matters in support. If a user cannot find BitLocker settings, verify the Windows edition, hardware support, TPM state, firmware mode, organizational policy, and whether device encryption is being used instead. Do not assume every Windows device exposes the same encryption management options.

Technician Workflow

• Verify the need: identify whether the goal is protecting a laptop, desktop, removable drive, or sensitive portable data.
• Check edition and hardware: confirm Windows edition, TPM availability, firmware settings, and organizational policy.
• Protect the recovery key: store recovery keys only in approved locations before relying on encryption.
• Confirm encryption status: verify whether the volume is fully encrypted, encrypting, suspended, locked, or unprotected.
• Use BitLocker To Go for removable media: encrypt USB drives that carry sensitive files outside trusted storage.
• Plan before hardware changes: recovery prompts can appear after firmware, boot, TPM, motherboard, or storage changes.
• Document the result: record device, volume, encryption state, recovery-key escrow location, and any user instructions.

Scenario Cues

• Laptop may be lost or stolen: use BitLocker to protect data at rest on the internal drive.
• Drive could be removed and connected elsewhere: BitLocker keeps the volume encrypted outside the original computer.
• USB drive carries sensitive files: use BitLocker To Go for removable media.
• User is prompted for a recovery key: check authorized recovery-key storage and recent hardware or firmware changes.
• BitLocker option is missing: verify Windows edition, device encryption, TPM support, and management policy.
• Device is being serviced or reassigned: verify encryption, backup, recovery, and data-handling requirements before release.

Exam Mindset

Core 2 BitLocker questions usually point to protecting data if hardware leaves the owner's control. Look for words like lost laptop, stolen device, removed drive, full-disk encryption, recovery key, removable USB drive, or data at rest. The best answer is often BitLocker for internal volumes or BitLocker To Go for removable drives.

Remember that encryption does not eliminate every security task. Users still need strong sign-in protection, account security, backups, recovery-key management, incident reporting, and proper disposal procedures. BitLocker protects the data on the drive, but the technician still has to manage the whole lifecycle around that protection.

Encrypting File System, or EFS, is Windows file-level encryption that protects selected files and folders on NTFS volumes by tying the encryption key to the user's Windows credentials.

EFS protects individual files and folders instead of encrypting the entire drive. That makes it different from BitLocker. BitLocker is full-disk or volume encryption for data at rest across a whole drive. EFS is more granular: it encrypts specific files or folders at the file-system level so unauthorized users cannot read them even if they can browse the disk.

The infographic's key idea is that EFS keeps files private on a Windows PC. The data remains protected where it lives, but the protection depends heavily on the NTFS file system and the user's credentials. That credential dependency is powerful, but it also introduces a support risk: if credentials are reset incorrectly, EFS-protected files may become inaccessible.

What EFS Does

EFS automatically encrypts selected files and folders at the file-system level. Once enabled on a file or folder, Windows handles encryption and decryption in the background for the authorized user. The user opens the file normally, but another account without the correct key cannot read the file contents.

This is useful when only certain data needs extra privacy. For example, a technician might see EFS used for sensitive documents, local records, confidential project files, or user-specific data on a shared Windows device. It helps protect private files from other local users who should not be able to read them.

File-Level Encryption

EFS is file-level encryption, not whole-drive encryption. That means a user can encrypt one file, one folder, or a set of folders without encrypting the entire operating system volume. If a folder is encrypted, files created inside it can inherit encryption behavior depending on how Windows applies the setting.

Because EFS is selective, it is not a complete replacement for BitLocker. If the whole device is lost or stolen, BitLocker is usually the stronger broad protection because it encrypts the full volume. EFS is better understood as a targeted privacy control for files and folders inside Windows.

NTFS Requirement

EFS requires the NTFS file system. It works at the file-system level, so the volume must support NTFS features. If a file is stored on a file system that does not support EFS, such as many removable drives formatted with FAT32 or exFAT, EFS protection will not apply in the same way.

This requirement is a common troubleshooting clue. If the EFS option is unavailable, greyed out, or not behaving as expected, check the file system first. Confirm the drive is NTFS, verify the Windows edition, and determine whether policy or permissions are preventing encryption.

Windows Compatibility

The infographic notes that EFS is supported on most Windows editions but not Windows Home. In practical terms, EFS is associated with professional and business Windows environments where users, files, and permissions are managed more deliberately. If a user on Windows Home asks why EFS is not available, edition support may be the answer.

Compatibility also matters when files move. If an EFS-encrypted file is copied to a location that does not support EFS, copied through a tool that strips attributes, sent through email, uploaded to cloud storage, or moved to another system, encryption behavior may change. A technician should not assume EFS protection follows every copy in every situation.

Credentials Protect the Key

EFS uses the user's Windows credentials as part of protecting the encryption key. The authorized user's account can decrypt the file because Windows can access the user's EFS certificate and private key. Another user account, even on the same computer, should not be able to open the encrypted data unless access is specifically configured.

This creates an important support rule: keep credentials and EFS keys safe. If an administrator resets a user's password in a way that breaks access to the user's encryption keys, the user may lose access to EFS-encrypted files. Changing a password normally through the user's signed-in session is different from an administrator forcibly resetting it without preserving key access.

Recovery and Data Loss Risk

EFS can protect privacy so well that careless recovery can become data loss. If the user's private key is lost, the password is reset incorrectly, the profile is damaged, or the EFS certificate is not backed up, encrypted files may be unreadable. In domain environments, a Data Recovery Agent may be configured to help recover EFS-protected data, but that depends on policy and planning.

Before resetting passwords, deleting profiles, reinstalling Windows, replacing drives, or migrating user data, check whether EFS is in use. Back up EFS certificates and keys through approved methods when appropriate. If EFS files exist and recovery is uncertain, stop and escalate before taking destructive steps.

EFS vs. BitLocker

EFS and BitLocker both use encryption, but they solve different problems. BitLocker protects a whole volume if hardware is lost, stolen, or removed. EFS protects selected files and folders from unauthorized users inside Windows. BitLocker is broad device or drive protection. EFS is targeted file and folder privacy.

They can be used together. A laptop may use BitLocker to protect the whole drive if it is stolen, while certain sensitive files also use EFS to limit access between user accounts. When both are present, the technician should understand which layer is responsible for the symptom or protection goal.

Technician Workflow

• Identify the protection goal: use EFS for selected files and folders, not full-drive encryption.
• Verify NTFS: confirm the file or folder is stored on an NTFS volume before expecting EFS support.
• Check Windows edition: EFS is not available on Windows Home in the way business editions support it.
• Protect credentials: avoid password reset actions that can break access to encrypted files.
• Back up keys when appropriate: preserve EFS certificates and recovery options before migrations or repairs.
• Check effective access: remember that file permissions and encryption are different controls.
• Document carefully: record encrypted locations, user account, recovery method, certificate handling, and support actions.

Scenario Cues

• Only certain files need encryption: EFS is a file-level or folder-level encryption option.
• Entire device or drive must be protected: BitLocker is usually the better clue than EFS.
• EFS option is unavailable: check NTFS, Windows edition, policy, and file location.
• Administrator reset a password and files no longer open: suspect EFS key access problems.
• User profile migration is planned: preserve EFS certificates and private keys before moving data.
• Several users share one PC: EFS can help keep one user's sensitive files unreadable to other local users.

Exam Mindset

Core 2 EFS questions usually point to individual files or folders, NTFS, Windows edition support, and user credential dependency. If the scenario says a user encrypted files and then cannot open them after an administrator reset the password, EFS is the clue.

Do not mix up EFS and BitLocker. BitLocker protects the volume. EFS protects selected files and folders. BitLocker is usually the answer for a lost or stolen laptop. EFS is usually the answer for keeping specific files private on an NTFS Windows system.

Active Directory is a centralized Windows directory service that stores information about users, computers, groups, printers, file shares, and other network resources so organizations can authenticate users and manage access consistently.

Active Directory, often shortened to AD, is more than a login system. It is the backbone of many Windows business networks because it gives administrators one organized place to manage identities, devices, resources, permissions, and policy. Instead of configuring every computer and user separately, AD lets an organization centralize control.

The infographic frames Active Directory around four ideas: centralize, authenticate, manage, and connect. That is the exam mindset. AD stores information about the environment, verifies users with AD credentials, organizes resources into domains, and helps IT teams manage access to the things users need.

Central Directory

Active Directory stores information about objects on the network. Common objects include user accounts, computer accounts, groups, printers, shared folders, organizational units, service accounts, and policy targets. This central database helps technicians answer practical questions: Who is this user? Which computer is this? Which group grants access? Which resource is shared? Which policy applies?

Centralization matters because unmanaged identity becomes chaos quickly. In a small network, local accounts may seem manageable. In a school, business, medical office, government site, or enterprise, users change roles, devices are replaced, groups need access, passwords expire, and permissions must be reviewed. AD provides structure for that ongoing work.

Authentication and Sign-In

Users authenticate with Active Directory credentials when they sign in to a domain environment. The username and password, smart card, or other approved authentication method is checked against the directory and related policies. If authentication succeeds, the user can sign in and receive access based on account state, group membership, device state, and resource permissions.

Authentication is not the same as authorization. AD may verify that the user is who they claim to be, but permissions still determine what the user can access. A user can successfully sign in and still be blocked from a shared folder, printer, app, or administrative tool because they are not in the correct group or the resource permissions do not allow it.

Domain Basics

A domain is a named collection of users, computers, and resources that share a central directory. Each domain has a unique name, such as an internal name used by a school or business. The domain creates a security and management boundary where accounts, computers, groups, and policies can be organized together.

Domain controllers store and provide access to the central database for the domain. They handle authentication requests, directory lookups, policy-related activity, and replication with other domain controllers. If domain controllers are unavailable, users may have trouble signing in, changing passwords, accessing resources, or receiving updated policies.

Permission Management

Active Directory helps centralize permission management by using groups and policies. Instead of granting folder access to each user one at a time, administrators can create groups based on department, role, application, or access need. Users are placed into groups, and those groups receive permissions to resources.

This approach supports least privilege and cleaner audits. If a user transfers from one department to another, group membership can be updated. If a contractor leaves, the account can be disabled or removed from access groups. If a shared folder has the wrong access, the technician can inspect group membership and permissions rather than searching through scattered local settings.

Everyday Uses

IT teams rely on Active Directory for password resets, account creation, account removal, group membership changes, permission troubleshooting, device management, and domain-related support. If a support ticket involves users, devices, or access in a Windows business network, Active Directory is often part of the answer.

Common support actions include unlocking accounts, resetting passwords, disabling old accounts, creating new user accounts, adding users to approved groups, removing stale access, checking computer objects, confirming domain membership, and reviewing whether policies have applied correctly. These tasks are routine, but they affect security, so they should be documented and approved where policy requires it.

Joining a Device to the Domain

A Windows PC can be joined to an Active Directory domain so it becomes a managed domain member. Once joined, the device can use domain authentication, receive policy, appear as a computer object, and participate in centralized management. Domain membership helps organizations protect devices, standardize settings, and control access.

Joining a device may be done through Windows system settings, deployment tools, provisioning workflows, or scripts. The infographic mentions that PowerShell can automate domain join tasks. Automation is useful for consistency, but the technician still needs the correct domain name, network connectivity, permissions, DNS configuration, and device naming process.

Troubleshooting AD Issues

Active Directory troubleshooting starts by identifying which layer is failing. Is the computer joined to the domain? Can the user authenticate? Is the account locked, disabled, expired, or missing group membership? Can the device reach a domain controller? Is DNS configured correctly? Did policy apply? Does the resource permission allow access?

Many "Windows problems" are really directory or access problems. A user may blame the computer, but the issue could be a disabled account. A shared folder may look broken, but the user may be missing group membership. A password reset may work in one place but not another because the user is offline, cached credentials are involved, or replication has not caught up.

Technician Workflow

• Identify the domain context: confirm the domain name, user account, computer name, and resource involved.
• Check account state: look for locked, disabled, expired, or password-change-required conditions.
• Verify domain membership: confirm the device is joined to the domain when domain management is expected.
• Review group membership: determine whether the user belongs to the groups that grant required access.
• Check domain controller reachability: verify network, DNS, time sync, and authentication path.
• Use least privilege: grant access through approved groups and avoid broad administrator rights.
• Document directory changes: record account, group, computer, approval, reason, and verification result.

Scenario Cues

• User needs a password reset or account unlock: think Active Directory account management.
• User signs in with domain credentials: authentication is tied to AD or a related directory service.
• User cannot access a shared folder: check AD group membership plus share and NTFS permissions.
• Computer must be managed by the organization: join it to the domain if AD domain management is used.
• Domain login fails for many users: check domain controllers, DNS, network reachability, and time synchronization.
• Access should follow a job role: use groups instead of individual one-off permissions.

Exam Mindset

Core 2 Active Directory questions often describe domain credentials, password resets, group membership, domain-joined computers, shared resources, or centralized permission management. When the clue involves users, devices, or access across a Windows network, AD is likely involved.

Remember the distinction between signing in and being allowed to access a resource. AD can authenticate the user, but authorization depends on permissions, groups, policies, and resource settings. The strongest answer usually checks account state, domain membership, group membership, and permissions before making broad changes.

Objective 2.2 is about using Windows security features together: protect the device, control network traffic, assign the right access, elevate only when needed, encrypt sensitive data, and manage identities through a directory.

The major pattern across this objective is controlled access. Microsoft Defender Antivirus helps stop malicious software. Windows Firewall controls network communication. User accounts, groups, permissions, UAC, and Run as administrator control what people and applications can do. BitLocker and EFS protect data. Active Directory ties users, computers, groups, and resources into a manageable Windows environment.

For support scenarios, do not memorize these as isolated vocabulary terms. Read the clue, identify what needs protection, and choose the Windows feature that fits the layer involved. A malware clue points to Defender Antivirus. A blocked or risky connection points to Windows Firewall. A user cannot open a file because of access rights? Think NTFS permissions, share permissions, groups, and Active Directory membership. A lost laptop with sensitive data points to BitLocker. A selected file that must stay private on NTFS points to EFS.

Built-In Protection Takeaways

Microsoft Defender Antivirus and Windows Firewall are built into Windows and should normally stay enabled. Defender Antivirus helps detect and block malware in real time, while Firewall helps block unwanted network traffic and allow trusted connections. Both tools are strongest when configured carefully and kept current.

If a user asks to disable protection, treat that as a risk decision, not a normal first troubleshooting step. A temporary change may be appropriate for a verified task, but the safer path is usually to check health, updates, scan results, firewall profiles, allowed apps, rules, notifications, and specific exceptions before turning protections off.

Account and Privilege Takeaways

User accounts define identity and daily access. Standard users are intended for everyday work, guest-style access is limited and temporary, and administrator accounts can make system-wide changes. Groups make access easier to manage because permissions can be assigned to a role or department instead of one user at a time.

Run as administrator and User Account Control are closely related. Being an administrator does not mean every application automatically runs with elevated rights. Windows requires deliberate elevation for tasks such as installing software, changing system settings, modifying protected files, or troubleshooting system-level problems. UAC prompts help stop accidental or malicious changes by asking for approval before elevated privileges are granted.

Sign-In and Authentication Takeaways

Windows supports several sign-in methods, including username and password, PIN, biometrics, single sign-on, Windows Hello, security keys, and passwordless methods. The best method depends on the device, organization policy, recovery needs, risk level, and user workflow. Convenience matters, but it should not erase accountability or recovery planning.

Authentication proves who the user is. Authorization determines what that user can access after sign-in. Many troubleshooting scenarios require this distinction. A user may sign in correctly but still be blocked by NTFS permissions, share permissions, group membership, firewall rules, device policy, or directory configuration.

Permission Takeaways

NTFS permissions and share permissions solve different parts of the same access problem. NTFS permissions apply to files and folders on an NTFS volume whether the user connects locally or over the network. Share permissions apply only when users access a shared folder over the network. When both layers apply, the more restrictive effective permission wins.

Explicit permissions are set directly on a file, folder, or share. Inherited permissions flow from a parent folder to child objects. This helps administrators manage many files consistently, but it can also surprise users when access changes because a parent folder changed. For exam and support work, remember that Deny overrides Allow, and the least permissive combined result is what the user experiences.

Data Protection Takeaways

BitLocker protects an entire volume. It is the stronger clue when a device or drive may be lost, stolen, removed, or plugged into another computer. BitLocker keeps the operating system volume, files, settings, and data protected at rest, and the recovery key must be protected because it may be needed to regain access.

EFS protects selected files and folders on NTFS volumes. It is tied to the user's credentials and encryption keys, so careless password resets or missing recovery planning can make encrypted files inaccessible. Use BitLocker for full-drive protection and EFS for file-level privacy when the scenario specifically calls for selected files or folders.

Directory and Management Takeaways

Active Directory provides centralized identity and resource management in many Windows environments. It stores users, computers, groups, printers, file shares, and other objects. Domains organize those resources, and domain controllers store and provide access to the directory database.

AD troubleshooting commonly includes password resets, account unlocks, computer domain membership, group membership, permissions, domain controller reachability, DNS, time synchronization, and policy application. If the scenario involves users, computers, groups, shared resources, or centralized access in a Windows network, Active Directory is often part of the answer.

Scenario Decision Cues

• Malware, scans, definitions, or real-time protection: check Microsoft Defender Antivirus and Windows Security.
• Blocked traffic, public networks, private networks, or allowed apps: check Windows Firewall and the active network profile.
• Daily user work without system changes: use a standard user account and least privilege.
• System-level task or protected Windows location: use Run as administrator only for the trusted task that needs elevation.
• Prompt before a major change: recognize User Account Control and secure desktop approval.
• Shared folder access problem: evaluate both share permissions and NTFS permissions.
• Lost or stolen laptop: use BitLocker and protect the recovery key.
• One user's private files on NTFS: use EFS and protect the user's credentials and keys.
• Domain credentials, group membership, password reset, or domain join: think Active Directory.

Exam Mindset

Choose the control that matches the layer in the question. Do not choose administrator rights when a group membership or permission correction would solve the issue. Do not disable antivirus or firewall protection when a scan, update, rule, exception, or profile change is the safer answer. Do not confuse full-disk encryption with file-level encryption. Do not treat sign-in success as proof that the user has resource access.

Objective 2.2 rewards careful thinking: identify the asset, determine the access path, confirm the protection layer, make the smallest responsible change, test the result, and document what changed. That rhythm works whether the task is malware protection, network security, local account control, domain access, encryption, or permissions.