220-1102 Question 797
Single answerOther considerations when using scriptsA technician downloads a PowerShell script from the company's internal repository to collect log files from several Windows 11 PCs. When the technician runs the script, PowerShell reports that the script cannot be loaded because running scripts is disabled on the system. The technician needs to run this script once, keep the organization's security settings intact, and minimize risk from untrusted code. Which action is the BEST choice?
- A
Set the execution policy to Unrestricted for the local machine, run the script, and leave the setting in place for future troubleshooting
- B
Open the script in Notepad, copy the contents, and paste them directly into the PowerShell console to bypass the restriction
- C
Verify the script is from the trusted internal source and run it in the current PowerShell session with a temporary process-level execution policy
- D
Rename the .ps1 file to .bat so Windows will treat it as a standard batch file and allow it to run
Show answer and explanation
Correct answer: C
Explanation
This question tests an important A+ Core 2 scripting consideration: balancing functionality with security controls. In real environments, technicians should avoid weakening execution policy more than necessary. PowerShell supports execution policies at multiple scopes, including Process, CurrentUser, and LocalMachine. Using a temporary Process-scope policy is a safer choice when a script must be run once. Best practice also includes validating the script's source before execution, especially when using downloaded or transferred scripts. Microsoft documents PowerShell execution policies and scope behavior, emphasizing that broader policy changes should be made cautiously and only when justified. For support technicians, the key principle is to use the least permissive change necessary, maintain system security baselines, and verify script trust before execution.
- A. Incorrect.
This is incorrect because setting the execution policy to Unrestricted at the LocalMachine scope weakens security for all users and future sessions on that computer. It does not align with the requirement to run the script once while keeping the organization's security settings intact. A common mistake is assuming the fastest permanent fix is also the best administrative choice, but broad policy changes increase risk unnecessarily.
- B. Incorrect.
This is incorrect because pasting script contents into the console may bypass some script-file restrictions, but it defeats the intent of the control and increases the chance of running unreviewed or altered code. It also reduces auditing and change control. A technician might choose this because it seems quick, but it is not a best practice when security and trust validation matter.
- C. Correct.
This is correct because the technician should first confirm the script is trusted, such as verifying it came from the internal repository and has not been altered. Then the script can be run using a temporary execution policy at the Process scope, which affects only the current PowerShell session and preserves the system's broader security configuration. This approach minimizes exposure while allowing the required task to be completed.
- D. Incorrect.
This is incorrect because changing a PowerShell script's file extension does not convert it into a batch file or make it executable as one. Batch and PowerShell scripts use different interpreters and syntax. This distractor reflects a misconception that Windows file extensions alone determine compatibility.