What Is PowerShell and Why DevOps Engineers Use It?

1. The problem PowerShell is designed to solve

DevOps work is full of tasks that are easy to perform once and dangerous to perform inconsistently a hundred times. You may need to inspect processes on a build runner, collect machine information during an incident, call a deployment API, check configuration before a release, or repeat the same administrative action across many systems. A human can click through a graphical interface or type a few commands for one machine, but that approach does not scale well. The steps are hard to review, hard to reproduce, and easy to perform differently under pressure.

PowerShell addresses that problem by giving you a command-line environment that is also a scripting and automation environment. The commands you test interactively can become part of a script, a CI/CD job, an incident-response runbook, or a reusable module. The goal is not to replace every other DevOps tool. The goal is to make repeatable work explicit, inspectable, and programmable.

2. Separate the terminal, shell, language, platform, command, and operating system

Several terms are often used as though they mean the same thing. They do not. Keeping them separate now prevents confusion later when the same PowerShell process is launched from Windows Terminal, a Linux terminal emulator, Visual Studio Code, an SSH session, or a CI runner.

An operating system is the software platform that manages hardware and provides services to applications. Windows, Linux distributions, and macOS are operating systems. A terminal is the user interface through which you interact with a command-line program. Modern terminals are usually graphical applications that display text, accept keyboard input, and host one or more shells.

A shell is a program that accepts commands and coordinates their execution. PowerShell is a shell, but it is more than a shell. It also includes a scripting language: syntax for variables, conditions, loops, functions, error handling, classes, and other programming constructs. The broader PowerShell ecosystem acts as an automation platform because scripts can work with operating-system services, files, processes, APIs, cloud modules, configuration systems, and native command-line tools.

A cmdlet (pronounced “command-let”) is a PowerShell command designed to participate in PowerShell's command model. Cmdlets generally use a Verb-Noun name such as Get-Process or Get-ChildItem. A native executable is a program outside PowerShell, such as git, docker, or an operating-system utility. PowerShell can launch native executables, but the boundary matters because native programs usually exchange text and exit codes rather than PowerShell objects.

• Operating system: the platform on which applications run.
• Terminal: the interface that displays a command-line session.
• Shell: the command interpreter and execution environment.
• Scripting language: the language used to express reusable logic.
• Automation platform: the larger environment used to coordinate systems and tools.
• Cmdlet: a PowerShell-native command that follows PowerShell conventions.
• Native executable: a separate operating-system program that PowerShell can launch.

3. Inspect the shell you are actually running

PowerShell exposes information about its own environment through variables and commands. A variable is a named place where PowerShell makes a value available. Variables begin with $. You do not need to understand the full variable system yet; for this lesson, treat the following built-in variables as labels that PowerShell already knows.

$PSVersionTable
$Host | Select-Object Name, Version
Get-Process -Id $PID | Select-Object Id, ProcessName, Path
$PSHOME
Get-Location

$PSVersionTable contains version and edition information. $Host describes the PowerShell host interface. $PID is the process identifier of the current PowerShell process. $PSHOME is the directory in which the current PowerShell engine is installed. Get-Location reports the current working location.

The output on your computer will differ from the example below. That is expected: process identifiers, installation paths, host names, and operating-system details are environment-specific.

Name                           Value
----                           -----
PSVersion                      7.6.4
PSEdition                      Core
...

Name             Version
----             -------
ConsoleHost      7.6.4

 Id ProcessName Path
 -- ----------- ----
8240 pwsh        C:\Program Files\PowerShell\7\pwsh.exe

C:\Program Files\PowerShell\7

Path
----
C:\Users\you

The important observation is not the exact formatting. It is that PowerShell can describe itself and the process in which it is running. In later chapters you will learn that the displayed columns are only a view of richer underlying objects.

4. The defining idea: commands can pass objects, not merely printed lines

Many command-line traditions compose programs by sending text from one process to another. That is powerful, portable, and still essential. PowerShell adds another model for PowerShell-native commands: the pipeline can carry objects. An object is a structured value with named pieces of data, called properties, and sometimes operations, called methods.

You do not need object-oriented programming knowledge to use this idea. Imagine that one command sends labeled records down a conveyor belt. Instead of receiving a printed line such as pwsh 8240 1.42 and guessing which character positions represent the process name, ID, and CPU time, the next command can receive a process object whose properties have names such as ProcessName, Id, and CPU.

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

The vertical bar | is the pipeline operator. Here, Get-Process obtains process objects. Sort-Object orders those objects by their CPU property. Select-Object keeps the first five and projects the three named properties for display. You are composing operations around data with known structure rather than parsing a fixed-width screen layout.

A representative result might look like this:

ProcessName       Id       CPU
-----------       --       ---
code            9132   812.42
chrome          4380   526.77
pwsh            8240    12.31
...

This does not mean every PowerShell pipeline is object-only. PowerShell can launch native programs, consume text, emit text, and cross boundaries where object structure is lost. The course will make those boundaries explicit rather than pretending they do not exist.

5. Where PowerShell fits in real DevOps work

PowerShell is useful when the same workflow touches several kinds of systems or data. A DevOps engineer might inspect a host, transform results into structured records, call an HTTP API, invoke a cloud or container CLI, and return a status to a CI runner—all from one script.

Host administration includes inspecting processes, services, files, event data, networking state, or configuration. CI/CD automation includes validating build inputs, packaging artifacts, running tests, creating release metadata, and failing a job deliberately when a contract is violated. Cloud tooling can use PowerShell modules when a provider offers them, or invoke provider CLIs when that is the better interface.

API automation matters because modern delivery systems expose HTTP endpoints for source control, build systems, monitoring, ticketing, secrets platforms, and infrastructure services. Configuration work often involves reading JSON, YAML, CSV, XML, environment variables, and command output and converting that data into a predictable form. During incident response, PowerShell can help collect evidence consistently and produce repeatable diagnostics rather than relying on a sequence remembered under stress.

Modern PowerShell 7 is cross-platform, so the same language and many of the same commands can run on Windows, Linux, and macOS. Cross-platform does not mean every command is identical everywhere. Some modules expose Windows-only technologies; native executables differ by operating system; filesystem and privilege models differ. Portable automation begins by identifying those boundaries.

6. PowerShell and Bash solve overlapping problems with different strengths

Bash and PowerShell are both shells and scripting environments used heavily in DevOps. A useful comparison is not “which one is universally better?” but “what data model and surrounding toolchain fit this task?”

Bash traditionally excels at composing native Unix programs whose standard interfaces are text streams, files, and exit statuses. It works naturally in Linux environments where tools such as grep, awk, sed, curl, and many infrastructure CLIs are already present. PowerShell's native command model emphasizes objects and named parameters, which can reduce fragile parsing when PowerShell cmdlets or modules expose structured data directly.

The distinction is a tendency, not a wall. Bash can work with structured formats through tools such as jq; PowerShell can manipulate text and invoke native tools. Production systems frequently use both. A Linux CI image might run Bash for a small toolchain wrapper and PowerShell for a cross-platform deployment module. The engineering question is whether the chosen tool makes data flow, errors, dependencies, and maintenance clearer.

7. Hands-on lab: build a read-only PowerShell identity report

This first lab changes no machine configuration. It gathers facts about the current PowerShell process and returns one structured object. A PS> marker in course prose means “this is a PowerShell prompt”; do not type the marker itself.

[pscustomobject]@{
    PowerShellVersion = $PSVersionTable.PSVersion.ToString()
    Edition           = $PSVersionTable.PSEdition
    HostName          = $Host.Name
    ProcessId         = $PID
    ProcessPath       = (Get-Process -Id $PID).Path
    PSHome            = $PSHOME
    OS                = [System.Runtime.InteropServices.RuntimeInformation]::OSDescription
    Architecture      = [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
    WorkingDirectory  = (Get-Location).Path
    IsWindows         = $IsWindows
    IsLinux           = $IsLinux
    IsMacOS           = $IsMacOS
}

[pscustomobject]@{ ... } creates a record-like object with the property names you choose. The syntax is introduced here only so you can see the final report as one coherent unit; Chapter 05 teaches custom objects in detail. The RuntimeInformation type comes from .NET, the runtime platform used by modern PowerShell. You do not need .NET programming knowledge to call this read-only system information API.

Verify the report rather than accepting it blindly. The edition should normally be Core for PowerShell 7.x. Exactly one of IsWindows, IsLinux, and IsMacOS should be true in PowerShell 7 on those supported platforms. The process path should identify the executable you actually launched, and PSHome should point to the engine's installation directory.

8. Common mistakes and how to reason about them

Mistake: “Windows Terminal is PowerShell.” Windows Terminal can host PowerShell, but it can also host other shells. Inspect the running process and version rather than inferring the shell from the window.

Mistake: “PowerShell output is just the text I see.” Formatting is often a view over objects. If you build automation by scraping the displayed columns of a cmdlet, you may throw away structure that PowerShell already provides.

Mistake: “Cross-platform means every command exists everywhere.” The PowerShell engine is cross-platform. Modules, operating-system APIs, native executables, permissions, and paths may still be platform-specific.

Mistake: copying the prompt marker. Documentation sometimes writes PS> Get-Process to show context. Type Get-Process, not the prompt text.

Mistake: choosing a shell by loyalty rather than workflow. DevOps systems are heterogeneous. A reliable engineer is comfortable crossing tool boundaries and documenting why a particular shell is used.

9. Knowledge check

10. Summary

PowerShell is a cross-platform shell, scripting language, and automation environment designed for repeatable work. A terminal is not the shell, the shell is not the operating system, a cmdlet is not the same thing as a native executable, and the formatted text on screen is not necessarily the data model underneath. PowerShell's object-oriented pipeline is the central idea that will make later commands easier to reason about.

11. Further reading

• Microsoft Learn — What is PowerShell?
• Microsoft Learn — PowerShell documentation
• PowerShell project on GitHub