PowerShell Fundamentals Quiz: the object pipeline strikes back

You already built slick Python CLIs, parsed args like a boss, and automated routine tasks without breaking a sweat. Now it's time to flex those muscles in PowerShell, where the pipeline carries objects, not vibes. Well, vibes too.

This is an integrated check-in for Modules 1–6. Think of it as: what would happen if your Python automation brain took a weekend trip to PowerShell Land and came back with stories.

From Python to PowerShell: the mental shift you actually need

Python CLI: argparse + functions + modules + return values
PowerShell CLI: Param block + cmdlets + modules + output objects

Idea	Python world	PowerShell world
Get help	pydoc, --help	Get-Help, -Online, -Examples
Pipelines	text streams	object streams
CLI params	argparse flags	Param(...) with types, attributes
Packaging	entry points	functions, scripts, modules (.psm1)
Errors	exceptions (try/except)	terminating vs non-terminating, try/catch

Key upgrade: PowerShell passes .NET objects between commands. That means far less parsing and far more 'just use the property, king'.

How this works

14 questions across multiple choice, short answer, and tiny hands-on tasks
Answer key with quick explanations at the end
A tiny bit of chaos sprinkled in, because growth is uncomfortable

Multiple choice (select one unless noted)

Which cmdlet name follows PowerShell's standard naming convention?

A) list_processes
B) Get-Process
C) fetchProcess()
D) Process.Get()

In the PowerShell pipeline, what is actually passed between commands by default?

A) Text lines
B) JSON strings
C) Objects
D) CSV records

You want usage examples for Get-Content without opening a browser. Which command?

A) man Get-Content
B) Get-Command Get-Content -Examples
C) Get-Help Get-Content -Examples
D) Get-Help Get-Content | Select-Object Examples

Which one-liner lists stopped services that start with 'Win', showing only Name and Status, sorted by Name?

A) Get-Service 'Win*' | Select-Object Name, Status | Sort-Object Name | Where-Object Status -eq Stopped
B) Get-Service Win* | Where-Object Status -eq 'Stopped' | Select-Object Name, Status | Sort-Object Name
C) Get-Service Win* | Sort-Object Name | Select-Object Name, Status -FilterScript { $_.Status -eq 'Stopped' }
D) Get-Service | Where-Object Name -like 'Win*' -and Status -eq Stopped | Select-Object Name, Status | Sort Name

You run:

$procs = Get-Process | Select-Object Name, Id
$procs | Stop-Process

What magic makes this work?

A) Pipeline type conversion
B) Parameter binding by property name
C) Implicit method invocation
D) Reflection-based coercion

You want to run a local script one time without permanently changing system policy. Which is valid on Windows PowerShell?

A) powershell -ExecutionPolicy Bypass -File .\script.ps1
B) pwsh -executionpolicy Strict -File ./script.ps1
C) Set-ExecutionPolicy Bypass; .\script.ps1; Set-ExecutionPolicy Default
D) Unblock-File .\script.ps1; .\script.ps1 (no policy involved)

Which pair is the PowerShell twin of Python's argparse for named parameters?

A) Param(...) + [CmdletBinding()]
B) Begin{} + End{}
C) Set-Variable + Get-Variable
D) Function + Return

Which command runs on two remote computers and gets the Spooler service?

A) Enter-PSSession -ComputerName A,B { Get-Service Spooler }
B) Invoke-Command -ComputerName A,B -ScriptBlock { Get-Service -Name Spooler }
C) Get-Service -ComputerName A,B Spooler
D) ssh A,B 'Get-Service Spooler'

Which redirects only error output to a file while showing normal output on screen?

A) Get-ChildItem Foo > errors.txt
B) Get-ChildItem Foo 2> errors.txt
C) Get-ChildItem Foo *> errors.txt
D) Get-ChildItem Foo 1> errors.txt

Which pipeline will correctly export process info to CSV with properties intact?

A) Get-Process | Format-Table Name, Id | Export-Csv procs.csv -NoTypeInformation
B) Get-Process | Select-Object Name, Id | Export-Csv procs.csv -NoTypeInformation
C) Get-Process | Out-String | Export-Csv procs.csv -NoTypeInformation
D) Get-Process | Format-List * | Export-Csv procs.csv -NoTypeInformation

Short answer and tiny builds

Write a one-liner that:

Gets all running processes
Sorts by CPU descending
Shows the top 5 with Name, Id, CPU

Hint: Select-Object -First

You're porting a Python CLI to PowerShell. Write a function header that:

Supports named parameters ComputerName (string, mandatory), and Force (switch)
Plays nicely with -WhatIf and -Confirm like a real cmdlet

You only need the signature and the first line.

Explain in one sentence why Format-Table early in the pipeline breaks later processing like Export-Csv.
Cross-platform brain check: What binary launches modern cross-platform PowerShell, and what behavior should you expect for execution policy on Linux?

Answer format: binary name; execution policy note

Fix this script (spot the gremlins)

You're trying to write an advanced function that stops a service by name, with -WhatIf support and friendly validation.

function Stop-NiceService {
    [CmdletBinding(SupportsShouldProcess=$true)]
    Param(
        [Parameter(Mandatory=$true)]
        [ValidateSet('Spooler','BITS','wuauserv')]
        [string]$Name
    )

    if ($PSCmdlet.ShouldProcess('service', 'stop')) {
        Get-Service -Name $name | Stop-Service -Force -Confirm
    }
}

Identify two improvements or fixes to make this more correct and user-friendly.

Pro tip: Think about ShouldProcess targets, pipeline input, and confirmation noise.

Why this matters (aka the automation glow-up)

Remember how you packaged Python scripts as CLIs? In PowerShell, your Param block is your argparse, comment-based help is your man page, and the output is object gold that plays nicely with every other cmdlet. Your routine tasks get shorter, safer, and less parse-y.

The secret handshake: Select for data, Format for display. Use -WhatIf before -Force. And never forget Get-Help exists.

Answer key with quick explains

B. Verb-Noun is the law. Get-Process is correct.
C. PowerShell passes objects. Parsing text is so last semester.
C. Get-Help ... -Examples prints curated inline examples.
B. Filter early, select properties, then sort. The order matters.
B. Pipeline binding by property name wires Id to -Id. Chef's kiss.
A. This runs the script with a temporary bypass. D can help but doesn't guarantee policy.
A. Param with CmdletBinding gives you real cmdlet behavior, including common parameters.
B. Invoke-Command fans out the scriptblock to remote machines.
B. 2> sends only the error stream to a file. Streams are numbered.
B. Select preserves objects; Format turns them into formatting data (aka 'display-only soup').
One good answer:

Get-Process | Sort-Object CPU -Descending | Select-Object Name, Id, CPU -First 5

Sort first, then select the top N with the properties you want.

One good answer:

function Invoke-Thing {
    [CmdletBinding(SupportsShouldProcess=$true)]
    Param(
        [Parameter(Mandatory=$true)] [string]$ComputerName,
        [switch]$Force
    )
    # ...
}

CmdletBinding unlocks -WhatIf and -Confirm. Switch is the idiomatic boolean flag.

Format-Table converts objects into formatting instructions and strings, so downstream cmdlets lose real properties to work with.
Answer: pwsh; on Linux, execution policy is not enforced the same way and generally doesn't block script execution (it is advisory or ignored).

Fixes for Stop-NiceService:

Use a precise ShouldProcess target, e.g. ShouldProcess($Name, 'Stop-Service') so -WhatIf prints meaningful messages.
Avoid redundant -Confirm when you already support ShouldProcess; let the user opt into -Confirm.
Consider pipeline input and property binding:

[Parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true, ValueFromPipeline=$true)]
[string]$Name

Respect errors with -ErrorAction Stop inside try/catch if you want terminating behavior.

Example improved snippet:

function Stop-NiceService {
    [CmdletBinding(SupportsShouldProcess=$true)]
    Param(
        [Parameter(Mandatory=$true, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
        [ValidateSet('Spooler','BITS','wuauserv')]
        [string]$Name
    )
    process {
        if ($PSCmdlet.ShouldProcess($Name, 'Stop-Service')) {
            Get-Service -Name $Name | Stop-Service -Force
        }
    }
}

Final takeaways

PowerShell pipelines are Lego for objects; stop whittling strings when you can just grab properties.
Param + CmdletBinding is your argparse energy. Add comment-based help to be a good citizen.
Select for data, Format for display. Keep formatting at the end.
Use -WhatIf like a safety harness and embrace remoting for scale.

Now go automate something delightfully boring. Your future self (and your logs) will thank you.

Evaluation 1: Integrated Assessment of Modules 1–6

Content