Scripting & Remote Access Technologies

Script File Types (Know the Extension)

Objective 4.8 tests you on recognizing script types by file extension and knowing where each runs. The exam will not ask you to write code, but it will show a filename and ask what it is.

Scripting Use Cases CompTIA Lists

Objective 4.8 enumerates the use cases below — expect a scenario that maps to one:

• Basic automation of repetitive tasks
• Restarting machines on a schedule
• Remapping network drives at logon
• Installing applications silently across many PCs
• Automating backups
• Gathering information/data (inventory, logs)
• Initiating updates to OS or applications

Risks of Running Scripts

CompTIA explicitly lists "other considerations" — the dangers of scripting:

Best practice: Review every script, run it in a test/sandbox environment first, and never execute scripts from untrusted sources. PowerShell execution policies (Restricted, AllSigned, RemoteSigned, Unrestricted, Bypass) gate this — RemoteSigned is the sensible production baseline because it requires downloaded scripts to be signed while allowing trusted local scripts.

Remote Access Technologies and Ports

Objective 4.9 covers remote tools and their security considerations. Memorize the ports — they appear on both Core 1 and Core 2.

Other remote/support tools CompTIA names include Microsoft Remote Assistance / Quick Assist, third-party remote tools (TeamViewer, AnyDesk), screen-sharing software, video-conferencing software, file-transfer software, and desktop management software.

Remote Monitoring and Management (RMM)

RMM lets a managed service provider (MSP) or internal IT team manage many endpoints centrally: deploy patches, push/remove software, run scripts fleet-wide, monitor health, and remote into any managed device. Its power is also its risk — a compromised RMM tool can push malicious changes to every endpoint, so access is tightly controlled and audited.

Worked example: A help desk must securely manage a Linux server in another building. The correct A+ choice is SSH on TCP 22 (encrypted command line) rather than Telnet on 23 (plaintext credentials) — and for a graphical Windows host they would use RDP on 3389 with NLA. Matching the protocol to the platform and to its security posture is exactly what objective 4.9 rewards.

How Scripting and Remote Questions Are Framed

For scripting, the exam does not expect you to read or write code. It expects you to recognize a file by its extension, name the platform it runs on, and connect it to a plausible administrative task. A scenario describing the need to map a network drive automatically at every logon points to a logon script; one describing the need to install the same application silently on dozens of machines points to a deployment script run from a management tool. The exam also tests judgment about the dangers of automation.

A script that runs across many endpoints multiplies both productivity and risk, so the safe, exam-correct habit is to review the code, run it first in a sandbox or test environment, and avoid executing scripts from untrusted sources. PowerShell execution policies appear here because they are the mechanism that enforces this discipline; remembering that RemoteSigned blocks unsigned downloaded scripts while permitting trusted local ones is usually enough to answer the policy question.

Remote-access questions are essentially security questions in disguise. The exam wants you to pick the protocol whose encryption and platform fit the scenario, and to reject insecure or mismatched options. Telnet is the classic wrong answer whenever security matters, because it sends credentials and commands in cleartext; the correct replacement for command-line management is SSH on port 22. For a graphical Windows session the answer is RDP on port 3389, ideally with Network Level Authentication enabled so the connection is authenticated before a session is created.

VNC is the cross-platform graphical option, but because its default security is weak the exam-correct practice is to tunnel it through a virtual private network or SSH rather than exposing it directly.

RMM, MSPs, and Their Risk

Remote monitoring and management deserves special attention because it scales a single action to an entire fleet. A managed service provider or internal team uses an RMM platform to deploy patches, push or remove software, run scripts everywhere at once, monitor device health, and remote into any managed endpoint for support. The exam frames this capability as a double-edged sword: the same central control that lets one technician patch a thousand machines also means a compromised RMM agent or stolen administrator credential can push malware to all of them. That is why RMM access is tightly restricted, multifactor-protected, and audited.

When a scenario asks how an MSP supports many remote clients efficiently, the answer is the RMM platform; when it asks about the primary risk of that model, the answer is the blast radius of a single compromised management channel.