Scripting Basics practice questions

The script file was deleted by Windows Defender.

Why wrong: Windows Defender does not delete scripts without user interaction unless they are detected as malware.

The update changed the default script host to PowerShell.

Why wrong: The default script host for .vbs files remains cscript or wscript; it is not changed by updates.

The network share requires SMB 2.0, which is no longer supported.

Why wrong: SMB 2.0 is still supported; this would affect all drive mappings, not just VBScript.

Store the password in a plain text file and have the script read it.

Why wrong: Plain text passwords are easily compromised; this is not secure.

Embed the password in the script using a variable and run it from a hidden share.

Why wrong: Hidden shares still expose the script to anyone who can access the share; the password is visible in the script.

Use a scheduled task that runs the script as SYSTEM.

Why wrong: Running as SYSTEM does not hide the password; it is still visible in the script file.

A for loop

Why wrong: A for loop is used for iteration, not for checking a condition before action.

A while loop

Why wrong: A while loop repeats code while a condition is true, but it doesn't check existence before a single modification.

A try-catch block

Why wrong: Try-catch is for error handling, not for checking existence before modification.

The remote computer does not have PowerShell installed.

Why wrong: Get-CimInstance uses WMI, which is available on all Windows systems regardless of PowerShell version.

The script uses an incorrect namespace.

Why wrong: The namespace root/cimv2 is default and correct for Win32_OperatingSystem.

The technician is not a member of the Remote Management Users group.

Why wrong: Admin rights are sufficient for WMI; the Remote Management Users group is for WinRM.

Use a for loop to iterate over all services.

Why wrong: A for loop would check all services, but the requirement is to check one specific service and act.

Use a switch statement with multiple conditions.

Why wrong: A switch is for multiple discrete values, not a simple binary check of running/stopped.

Use a try-catch block to handle errors if the command fails.

Why wrong: Try-catch handles errors but doesn't check the service status beforehand.

The script file extension is .ps1 instead of .bat.

Why wrong: PowerShell scripts can be .ps1 and run from Task Scheduler, so this is not the issue.

The network share is mapped as a drive letter, which is not available during system startup.

Why wrong: The script runs daily at a scheduled time, not at startup, so drive mapping should be available.

PowerShell execution policy is set to Restricted for the SYSTEM account.

Why wrong: Execution policy applies to the user context, but the script works manually, so policy is not blocking it.

The script is not running with administrative privileges.

Why wrong: Writing to a log file in the current directory doesn't normally require admin rights.

The Out-File cmdlet is misspelled.

Why wrong: The cmdlet is spelled correctly as Out-File, and the script runs without errors.

The log file path contains a forward slash instead of a backslash.

Why wrong: PowerShell accepts both slashes in paths, so this would not cause an empty file.

The script uses a cmdlet that is not available on the network drive.

Why wrong: Cmdlets are available regardless of drive location; this is not a permission issue.

The network folder has a space in its name.

Why wrong: Spaces can be handled with quotes; they wouldn't cause a permission denied error.

The user is not running PowerShell as an administrator.

Why wrong: Renaming files doesn't require admin rights if the user has full control of the folder.

Setting the execution policy to Restricted.

Why wrong: Execution policy can be bypassed by running scripts in memory; it is not a strong security control.

Disabling PowerShell script block logging.

Why wrong: Disabling logging would reduce visibility, not prevent the attack.

Using a signed script policy.

Why wrong: Signed scripts can still be bypassed if the attacker runs code in memory without a file.

PAUSE

Why wrong: PAUSE halts the script until a key is pressed, not until a process finishes.

TIMEOUT

Why wrong: TIMEOUT waits for a set number of seconds, not until a specific process ends.

CALL

Why wrong: CALL runs another batch file but does not wait for a separate executable to finish.

Using the 'Set-ExecutionPolicy' cmdlet to change the policy to Unrestricted

Why wrong: Incorrect. Set-ExecutionPolicy changes the system policy, but this requires administrative privileges and would leave a trace. Attackers prefer a stealthier bypass.

Using the 'powershell.exe -Command' syntax with an encoded command

Why wrong: Incorrect. While encoded commands can bypass some detection, they do not bypass execution policy unless combined with the Bypass parameter or other techniques.

Signing the script with a self-signed certificate

Why wrong: Incorrect. Signing the script would require the execution policy to be set to AllSigned, but the system policy might not allow self-signed certificates. This is not a reliable bypass method.

Set the execution policy to Restricted

Why wrong: Incorrect. Restricted prevents all scripts from running, which may break legitimate administrative scripts. The requirement is to block only unsigned scripts.

Set the execution policy to RemoteSigned

Why wrong: Incorrect. RemoteSigned only requires signatures for scripts downloaded from the internet. Locally created unsigned scripts would still run, which doesn't meet the requirement.

Disable PowerShell using Group Policy

Why wrong: Incorrect. Disabling PowerShell entirely would break many administrative tasks and is not a targeted solution for script signing.

The script uses the 'del' command without a path

Why wrong: Incorrect. Without a path, 'del' would prompt for confirmation or delete files in the current directory, but it wouldn't explain why no files are deleted at all.

The script runs as a standard user without admin rights

Why wrong: Incorrect. Lack of permissions would cause access denied errors, not silent failure to delete files.

The script uses 'echo' instead of 'del'

Why wrong: Incorrect. 'echo' would display a message, not delete files, but the technician said the script runs without errors; if it used 'echo', it would still output something.

The script has a syntax error

Why wrong: Incorrect. The script works when run manually, so syntax is not the issue.

The script uses absolute paths that change after reboot

Why wrong: Incorrect. Absolute paths remain the same after reboot. This would not cause a failure only on reboot.

The script is blocked by antivirus software

Why wrong: Incorrect. Antivirus would likely block the script consistently, not only after reboot.

Enter-PSSession

Why wrong: Incorrect. Enter-PSSession starts an interactive session with a single remote computer, not suitable for scripting across multiple machines.

Get-WmiObject

Why wrong: Incorrect. Get-WmiObject can query remote computers but is deprecated in favor of CIM cmdlets. It also doesn't handle complex script blocks as easily as Invoke-Command.

Out-File

Why wrong: Incorrect. Out-File writes output to a file on the local machine, but it doesn't execute commands on remote computers.

Use the 'Write-Host' cmdlet to display the message

Why wrong: Incorrect. Write-Host outputs to the console, which would require the console window to be visible. The requirement is to hide the window.

Use the '-NoProfile' parameter when starting PowerShell

Why wrong: Incorrect. -NoProfile prevents loading of user profiles but does not hide the console window. The window would still appear.

Use a scheduled task with 'Run whether user is logged on or not'

Why wrong: Incorrect. This would run the script in the background without user interaction, so no message would be displayed to the user.

File permissions

Why wrong: Incorrect. File permissions would cause an 'access denied' error, not 'file not found'. The user can still see the file.

Script syntax error

Why wrong: Incorrect. A syntax error would produce a different error message, not 'file not found'. The script ran yesterday, so the syntax is likely fine.

Network connectivity

Why wrong: Incorrect. Network issues would cause a 'network path not found' error or similar, not a 'file not found' error for a script that is accessible.

Error handling with try-except

Why wrong: Incorrect. Error handling is important for robustness but not essential for the basic iteration and deletion logic.

A while loop with a counter

Why wrong: Incorrect. A while loop could work but is less natural for iterating over a collection of folders. A for loop is the standard approach.

A function to calculate date difference

Why wrong: Incorrect. Calculating date differences is necessary, but the question asks for the concept essential for iterating through folders, which is a loop.

A for loop

Why wrong: Incorrect. A for loop is used to repeat actions, not to make a decision based on a condition.

A variable

Why wrong: Incorrect. Variables store data, but they don't control the flow of the script. The script still needs a conditional statement to check the variable's value.

A while loop

Why wrong: Incorrect. A while loop repeats as long as a condition is true, but it doesn't provide a simple one-time check before an action.

Use a for loop to run the script 100 times

Why wrong: Incorrect. A for loop would run the script multiple times on the same computer, not once per computer.

Use a parameter to pass the computer name

Why wrong: Incorrect. A parameter helps target specific computers but does not prevent the script from running again on the same computer.

Schedule the script to run daily

Why wrong: Incorrect. Scheduling daily would run the script repeatedly, not once. It would change the password every day, which is not desired.