Mastering PowerShell Variables and Data Types

Understanding how to effectively work with variables and data types in PowerShell is fundamental to becoming proficient in automation and scripting. Whether you're managing a single server or orchestrating complex enterprise environments, the way you handle data determines the efficiency, reliability, and maintainability of your scripts. Variables serve as the building blocks of every PowerShell script, storing information that can be manipulated, transformed, and utilized throughout your automation workflows.

Variables in PowerShell are containers that hold values—ranging from simple text strings to complex objects with multiple properties and methods. Data types define what kind of information these containers can hold and how that information can be processed. PowerShell's flexible type system allows both strongly-typed and dynamically-typed approaches, giving scripters the freedom to choose the level of control they need for each specific situation.

This comprehensive guide will walk you through everything you need to know about PowerShell variables and data types, from basic declaration syntax to advanced type manipulation techniques. You'll discover how to choose the right data type for your needs, avoid common pitfalls that lead to script failures, and implement best practices that professional scripters use daily. By the end, you'll have the knowledge to write more robust, efficient, and maintainable PowerShell code.

Understanding Variables in PowerShell

Variables in PowerShell begin with a dollar sign ($) followed by a name that you choose. This naming convention makes variables immediately recognizable in your code and distinguishes them from cmdlets, functions, and other PowerShell elements. The flexibility of PowerShell's variable system allows you to create variables on-the-fly without explicit declaration, though understanding when and how to be more explicit will significantly improve your scripting capabilities.

When you create a variable, PowerShell automatically determines its type based on the value you assign. This dynamic typing makes PowerShell incredibly user-friendly for beginners, but it can also lead to unexpected behavior if you're not careful about how types are inferred and converted. The scripting engine performs implicit type conversions when possible, which can be both a convenience and a source of bugs if not properly understood.

Variable Declaration and Assignment

Creating a variable in PowerShell is straightforward. You simply assign a value using the equals sign, and PowerShell handles the rest. The assignment operator works intuitively, allowing you to store everything from simple numbers to complex objects returned by cmdlets. Understanding the nuances of how PowerShell interprets these assignments will help you write more predictable code.

Basic variable assignment follows a simple pattern where the variable name appears on the left side of the equals sign and the value on the right. PowerShell evaluates the right side first, then stores the result in the variable. This evaluation order becomes important when you're assigning the results of commands or expressions that might take time to execute or could potentially fail.

$userName = "JohnDoe"
$userAge = 32
$isActive = $true
$services = Get-Service

Each of these assignments creates a variable with a different underlying type. The first creates a string, the second an integer, the third a boolean, and the fourth an array of service objects. PowerShell's type inference engine examines the assigned value and selects the most appropriate type automatically, though you can override this behavior when necessary.

"The power of PowerShell variables lies not in their simplicity of declaration, but in their ability to adapt to the data they contain while maintaining type safety when you need it."

Variable Naming Conventions

Choosing meaningful variable names is one of the most important aspects of writing maintainable code. Your variable names should clearly communicate the purpose and content of the data they hold. PowerShell variable names can contain letters, numbers, and underscores, but they must start with a letter or underscore. While PowerShell is case-insensitive for variable names, adopting a consistent naming convention improves code readability.

Professional scripters typically use camelCase for variable names, where the first word is lowercase and subsequent words are capitalized. This convention makes multi-word variable names easy to read without requiring underscores or hyphens. Some teams prefer PascalCase or snake_case, and the most important factor is consistency across your codebase rather than the specific convention you choose.

• Use descriptive names that explain what the variable contains, like $customerEmailAddress instead of $cea
• Avoid single-letter variables except in very short loops or mathematical operations where convention dictates their use
• Include units in names when relevant, such as $timeoutSeconds or $maxRetryCount to prevent confusion
• Prefix boolean variables with "is", "has", or "should" to make their true/false nature immediately apparent
• Use plural names for collections and singular names for individual items to indicate cardinality at a glance

Core Data Types in PowerShell

PowerShell supports a rich variety of data types, inherited from the .NET Framework that powers it. Understanding these types and when to use each one is crucial for writing efficient scripts that handle data correctly. While PowerShell's dynamic typing often handles type selection automatically, knowing the available types allows you to make informed decisions about data storage and manipulation.

The type system in PowerShell is hierarchical, with all types ultimately deriving from System.Object. This inheritance structure means that every value in PowerShell is an object with properties and methods, even simple numbers and strings. This object-oriented nature gives you powerful capabilities for data manipulation that go far beyond simple value storage.

Working with Strings

Strings are perhaps the most commonly used data type in PowerShell scripting. They represent text data and can be created using either double quotes or single quotes, though these behave differently in important ways. Double-quoted strings support variable expansion and escape sequences, while single-quoted strings treat everything literally. This distinction becomes crucial when you need to include variable values in your strings or when you want to prevent PowerShell from interpreting special characters.

String manipulation in PowerShell is powerful and flexible, thanks to the extensive methods available through the .NET String class. You can concatenate strings using the plus operator, split them into arrays, replace substrings, change case, trim whitespace, and perform countless other operations. Understanding these capabilities allows you to process text data efficiently without resorting to external tools or complex workarounds.

$greeting = "Hello, $userName" # Variable expansion occurs
$literal = 'Hello, $userName' # No expansion, literal text
$multiLine = @"
This is a
multi-line string
"@

Here-strings, created with the @" and "@ syntax, allow you to create multi-line strings without needing to concatenate multiple lines or use escape characters for line breaks. They're particularly useful for embedding SQL queries, JSON data, or formatted text blocks in your scripts. The closing delimiter must be on its own line at the beginning of the line for PowerShell to recognize the here-string properly.

"String handling in PowerShell goes beyond simple text storage—it's about understanding when to use expansion, when to escape, and how to leverage .NET methods for sophisticated text processing."

Numeric Types and Arithmetic

PowerShell provides several numeric types to handle different ranges and precision requirements. The most common are integers for whole numbers and doubles for decimal values. Choosing the right numeric type affects both the accuracy of your calculations and the memory efficiency of your scripts. While PowerShell often handles numeric type conversions automatically, understanding the differences helps you avoid overflow errors and precision loss.

Arithmetic operations in PowerShell follow standard mathematical conventions, with operators for addition, subtraction, multiplication, division, and modulus. The scripting engine handles type promotion automatically when you mix different numeric types in calculations, generally promoting to the type that can represent the result without loss of information. This automatic promotion is convenient but can sometimes lead to unexpected results if you're not aware of the rules.

💡 Addition: $sum = 10 + 5 results in 15

💡 Subtraction: $difference = 10 - 5 results in 5

💡 Multiplication: $product = 10 * 5 results in 50

💡 Division: $quotient = 10 / 5 results in 2

💡 Modulus: $remainder = 10 % 3 results in 1

Integer division in PowerShell automatically returns a double if the result would have a fractional component, which differs from some programming languages that truncate to an integer. If you need integer division with truncation, you must explicitly cast the result to an integer type. This behavior prevents accidental data loss but requires awareness when you specifically need integer results.

Boolean Values and Logical Operations

Boolean variables hold one of two values: $true or $false. These special variables (note they begin with a dollar sign) represent truth values used in conditional logic throughout your scripts. PowerShell's comparison operators return boolean values, and understanding how different types convert to boolean values is essential for writing correct conditional statements.

Many values in PowerShell have implicit boolean conversions that occur when they're used in conditional contexts. Empty strings, zero, and $null all evaluate to false, while non-empty strings, non-zero numbers, and most objects evaluate to true. This truthiness evaluation can simplify your code but also lead to subtle bugs if you're not careful about what values might be present in your variables.

$isAdmin = $true
$hasPermission = $false
$canProceed = $isAdmin -and $hasPermission # Results in $false
$shouldWarn = $isAdmin -or $hasPermission # Results in $true
$isRestricted = -not $isAdmin # Results in $false

Type Casting and Conversion

Type casting is the process of explicitly converting a value from one type to another. While PowerShell performs many conversions automatically, there are situations where you need to force a specific type to ensure your code behaves predictably. Explicit casting prevents ambiguity and makes your intentions clear to anyone reading your code, including your future self.

PowerShell provides two primary methods for type casting: using square brackets before the value or before the variable declaration. Both approaches achieve the same result, but the syntax you choose affects when the conversion happens and whether the variable remains strongly typed for subsequent assignments. Understanding these differences helps you choose the appropriate approach for each situation.

[int]$stronglyTyped = "42" # Variable is always an integer
$converted = [int]"42" # Just this assignment is converted
[string]$text = 123 # Number converted to string "123"
[datetime]$date = "2024-01-15" # String parsed as date

When you declare a variable with a type constraint (the first example above), PowerShell enforces that type for all future assignments to that variable. Attempting to assign an incompatible value will either trigger an automatic conversion if possible or throw an error if the conversion cannot be performed. This type safety can prevent bugs but also requires more careful code design.

"Type casting is not about forcing square pegs into round holes—it's about being explicit about your data's nature and ensuring PowerShell interprets it exactly as you intend."

Implicit Type Conversion

PowerShell's type conversion engine works behind the scenes to make sense of operations that involve different types. When you add a string to a number, multiply an array by an integer, or compare values of different types, PowerShell follows specific rules to determine how to handle the conversion. These rules generally prioritize preserving data and preventing errors, but they can produce surprising results if you're not familiar with them.

The context in which a value is used often determines how PowerShell converts it. A string containing digits might be converted to a number in an arithmetic context, while a number might become a string when concatenated with text. Understanding these context-sensitive conversions helps you predict how your code will behave and write more robust scripts that handle edge cases gracefully.

Working with Collections

Collections are fundamental to PowerShell scripting because most real-world tasks involve working with multiple items rather than single values. Arrays, hash tables, and other collection types allow you to group related data and process it efficiently. Understanding the different collection types and their characteristics helps you choose the right structure for each situation and write more performant code.

PowerShell provides several collection types, each with distinct characteristics and use cases. Arrays are ordered lists that allow duplicate values and are accessed by numeric index. Hash tables store key-value pairs for fast lookup by key. ArrayLists and other .NET collections offer additional capabilities like dynamic sizing and specialized operations. Choosing the appropriate collection type can significantly impact both code clarity and performance.

Arrays

Arrays in PowerShell are zero-indexed collections that can hold any type of object. You can create arrays explicitly using the @() operator or implicitly by assigning multiple values separated by commas. PowerShell arrays are actually .NET arrays, which means they have a fixed size once created. This immutability affects how you add or remove elements, as these operations actually create new arrays behind the scenes.

$emptyArray = @() # Empty array
$numbers = @(1, 2, 3, 4, 5) # Array of integers
$mixed = @("text", 42, $true, (Get-Date)) # Mixed types
$range = 1..10 # Range operator creates array
$firstItem = $numbers[0] # Access by index
$lastItem = $numbers[-1] # Negative index from end

Accessing array elements uses square bracket notation with the index position. PowerShell supports negative indices to access elements from the end of the array, where -1 refers to the last element, -2 to the second-to-last, and so on. You can also use ranges within the brackets to extract multiple elements at once, creating a new array from a subset of the original.

Adding elements to an array requires creating a new array with the additional elements, since arrays are immutable. The += operator appears to add elements in place, but it actually creates a new array, copies all existing elements, adds the new element, and reassigns the variable. This operation becomes increasingly expensive as arrays grow larger, making ArrayLists or other dynamic collections better choices for frequently modified collections.

"Arrays are the workhorse of PowerShell collections, but understanding their immutability is crucial for writing efficient scripts that don't inadvertently create performance bottlenecks through repeated array expansion."

Hash Tables

Hash tables provide key-value storage where each unique key maps to a specific value. This structure enables fast lookups by key, making hash tables ideal for configuration data, lookup tables, and any scenario where you need to associate related pieces of information. PowerShell's hash table syntax is concise and readable, using @{} notation with key-value pairs separated by semicolons.

$person = @{
Name = "Jane Smith"
Age = 28
Department = "IT"
IsActive = $true
}
$personName = $person["Name"] # Access by key
$personName = $person.Name # Dot notation also works
$person["Email"] = "jane@example.com" # Add new key-value pair

Hash tables in PowerShell are case-insensitive by default for string keys, meaning "Name" and "name" refer to the same key. You can create case-sensitive hash tables if needed, but the default behavior simplifies most scripting scenarios. The ability to access values using either bracket notation or dot notation provides flexibility in how you write your code, though bracket notation is required when key names contain spaces or special characters.

Special Variables and Automatic Variables

PowerShell includes numerous built-in variables that provide information about the environment, script state, and execution context. These automatic variables are created and maintained by PowerShell itself and provide access to important runtime information. Understanding these variables helps you write more dynamic scripts that adapt to their execution environment and handle errors appropriately.

Some automatic variables are read-only, containing information about the PowerShell environment that you can query but not modify. Others can be modified to change PowerShell's behavior, such as preference variables that control how PowerShell responds to different types of messages and errors. Familiarizing yourself with the most commonly used automatic variables improves your ability to write robust, environment-aware scripts.

• $PSVersionTable contains information about the PowerShell version and host environment, useful for version-specific code paths
• $_ or $PSItem represents the current object in the pipeline, essential for pipeline processing and filtering operations
• $args contains all arguments passed to a function or script that weren't captured by named parameters
• $Error is an array containing error objects from recent errors, invaluable for debugging and error handling
• $null represents the absence of a value, used for comparisons and initializing variables that might not have values yet
• $Home contains the path to the current user's home directory, useful for creating user-specific file paths
• $PWD holds the current working directory path, essential for relative path operations
• $true and $false are the boolean constant values used throughout conditional logic

Preference Variables

Preference variables control how PowerShell responds to various situations during script execution. These variables allow you to customize PowerShell's behavior regarding error handling, progress display, verbosity, and warnings. Modifying preference variables at the script or function level provides fine-grained control over execution behavior without requiring changes to every command in your code.

$ErrorActionPreference = "Stop" # Stop on any error
$VerbosePreference = "Continue" # Show verbose messages
$WarningPreference = "SilentlyContinue" # Suppress warnings
$DebugPreference = "Continue" # Show debug messages

The ErrorActionPreference variable is particularly important as it determines what happens when a command encounters an error. The default value "Continue" allows scripts to proceed after non-terminating errors, while "Stop" converts all errors to terminating errors that halt execution. Understanding this variable and the -ErrorAction parameter that can override it on individual commands is crucial for implementing proper error handling.

"Preference variables are the control panel for PowerShell's runtime behavior—mastering them means you can make PowerShell as verbose or silent, as forgiving or strict as your specific situation demands."

Variable Scopes

Scope determines where a variable can be accessed within your PowerShell code. Understanding scope is essential for writing functions and scripts that don't interfere with each other or with the global PowerShell environment. PowerShell uses a hierarchical scope system where child scopes can read variables from parent scopes but modifications in child scopes don't affect parent scopes unless explicitly specified.

PowerShell has several scope levels: global scope (available everywhere), script scope (available throughout a script), local scope (the current scope), and private scope (restricted to the current scope only). When you reference a variable, PowerShell searches for it starting in the local scope and moving up through parent scopes until it finds the variable or reaches the global scope. This search order allows for scope-specific variable shadowing while maintaining access to outer scope variables.

Scope Modifiers

You can explicitly specify a variable's scope using scope modifiers, which are prefixes that tell PowerShell exactly which scope level you want to access. These modifiers become necessary when you need to modify a variable in a parent scope from within a function or script block, or when you want to ensure you're accessing a specific scope's version of a variable that might exist at multiple levels.

$global:ConfigPath = "C:\Config" # Global scope
$script:Counter = 0 # Script scope
$local:TempValue = "temporary" # Local scope (default)
$private:SecretKey = "hidden" # Private scope

Global variables persist for the entire PowerShell session and are accessible from anywhere. Script variables exist for the duration of a script's execution and are accessible throughout that script. Local variables are the default and exist only in the current scope. Private variables are like local variables but cannot be accessed by child scopes, providing true encapsulation when needed.

Environment Variables

Environment variables are system-level variables that exist outside PowerShell and are shared across all processes. They store configuration information like system paths, user preferences, and application settings. PowerShell provides access to environment variables through the $env: drive, allowing you to read and modify these system-wide settings from your scripts.

$currentPath = $env:PATH # Read environment variable
$env:CUSTOM_CONFIG = "MyValue" # Set environment variable
$env:PATH += ";C:\NewPath" # Append to PATH
$allEnvVars = Get-ChildItem Env: # List all environment variables

Changes to environment variables made within a PowerShell session only affect that session and any child processes it creates. The changes don't persist after the session ends unless you modify the system or user environment variables through the appropriate Windows settings or registry keys. This session-level modification allows you to temporarily change environment settings for testing without affecting the broader system.

Type Validation and Constraints

Type constraints allow you to enforce that a variable only accepts values of a specific type, adding a layer of safety to your scripts. When you declare a variable with a type constraint, PowerShell validates every assignment to that variable, either converting the value to the required type or throwing an error if conversion isn't possible. This validation catches type-related bugs early and makes your code's expectations explicit.

[ValidateNotNullOrEmpty()][string]$userName = "John"
[ValidateRange(1,100)][int]$percentage = 75
[ValidateSet("Low","Medium","High")][string]$priority = "High"
[ValidatePattern("^\d{3}-\d{2}-\d{4}$")][string]$ssn

Validation attributes go beyond simple type checking to enforce specific constraints on values. ValidateNotNullOrEmpty ensures a string variable always contains data. ValidateRange restricts numeric values to a specific range. ValidateSet limits string values to a predefined list of options. ValidatePattern uses regular expressions to ensure strings match a specific format. These attributes turn variables into self-validating entities that reject invalid data automatically.

"Type constraints and validation attributes transform variables from simple storage containers into intelligent gatekeepers that actively protect your script's data integrity."

Best Practices for Variables and Data Types

Following established best practices when working with variables and data types leads to more maintainable, reliable, and efficient code. These practices have evolved from the collective experience of the PowerShell community and represent proven approaches to common challenges. Adopting these patterns helps you avoid common pitfalls and write code that other scripters can easily understand and maintain.

Consistency in how you declare, name, and use variables makes your code more predictable and easier to debug. While PowerShell's flexibility allows many different approaches, choosing conventions and sticking to them reduces cognitive load when reading code. The small investment in following best practices pays dividends in reduced debugging time and easier collaboration with other scripters.

• Initialize variables before use to avoid unexpected $null values and make default values explicit in your code
• Use type constraints for function parameters to catch type mismatches early and provide clear documentation of expected input
• Choose descriptive names over brevity because code is read far more often than it's written, and clarity trumps keystrokes
• Limit variable scope to the smallest necessary level to prevent unintended side effects and make dependencies explicit
• Use strongly-typed variables for critical data where type safety is more important than flexibility
• Avoid modifying automatic variables unless you fully understand the implications, as this can lead to unpredictable behavior
• Clean up large variables when done with them using $variable = $null to free memory in long-running scripts
• Document complex type conversions with comments explaining why the conversion is necessary and what it accomplishes

Performance Considerations

The way you work with variables and data types can significantly impact script performance, especially in loops or when processing large datasets. Understanding the performance characteristics of different operations helps you make informed decisions about data structure choices and manipulation approaches. While premature optimization is a mistake, being aware of performance implications allows you to write efficient code from the start.

Array expansion using += is a common performance pitfall because it creates a new array for each addition. When building large arrays, using an ArrayList or collecting results in a pipeline is much more efficient. Similarly, string concatenation in loops can be slow because strings are immutable; using a StringBuilder or joining an array of strings is faster for building large text outputs. These patterns become important when processing thousands or millions of items.

"Performance optimization in PowerShell isn't about micro-optimizing every line—it's about understanding which operations are expensive at scale and choosing the right data structures and patterns for your specific scenario."

Common Pitfalls and How to Avoid Them

Even experienced PowerShell scripters encounter common mistakes related to variables and data types. Being aware of these pitfalls helps you recognize and avoid them in your own code. Many of these issues stem from PowerShell's flexibility and dynamic typing, which make the language accessible but can also hide problems until runtime.

Type coercion surprises represent one category of common issues. PowerShell's automatic type conversion is usually helpful but can produce unexpected results when types are mixed in ways you didn't anticipate. Another frequent problem involves null reference errors when code assumes a variable contains a value but it's actually $null. Understanding these patterns helps you write defensive code that handles edge cases gracefully.

Pitfall: Comparing different types without understanding conversion rules

"10" -eq 10 # Returns $true (string converted to number)
10 -eq "10" # Returns $true (same comparison, different order)
"10" -gt "9" # Returns $false (string comparison, not numeric)

Solution: Explicitly cast values to the same type before comparison or use type-specific comparison operators

Pitfall: Treating $null, empty strings, and zero as interchangeable

$value = ""
if ($value) { "Has value" } else { "No value" } # Prints "No value"

Solution: Use specific tests like -eq $null, -eq "", or -eq 0 depending on what you're actually checking

Pitfall: Modifying arrays in loops with +=

$results = @()
foreach ($i in 1..10000) { $results += $i } # Very slow

Solution: Use ArrayList, collect in pipeline, or pre-allocate array size

Advanced Type Manipulation

Beyond basic type casting, PowerShell offers sophisticated type manipulation capabilities that leverage the full power of the .NET Framework. These advanced techniques allow you to work with custom types, create type accelerators, and perform complex type operations that go beyond what's needed for everyday scripting but become invaluable in advanced scenarios.

Custom objects allow you to create structured data with named properties without defining a formal class. The PSCustomObject type accelerator provides an efficient way to create objects with specific properties, making your data more organized and self-documenting than using arrays or hash tables. These objects integrate seamlessly with PowerShell's pipeline and formatting system, displaying cleanly in tables and lists.

$customObject = [PSCustomObject]@{
ComputerName = "SERVER01"
Status = "Online"
LastCheck = Get-Date
ResponseTime = 45
}

Type accelerators are shortcuts for commonly used .NET types that make your code more readable. Instead of writing [System.Management.Automation.PSCustomObject], you can use [PSCustomObject]. PowerShell includes many built-in accelerators, and you can even add your own for types you use frequently. Understanding available accelerators and when to use full type names versus accelerators helps you write code that balances readability with explicitness.

Working with $null

The $null value represents the absence of a value and requires special handling in PowerShell. Unlike empty strings or zero, $null indicates that a variable has no value at all. Understanding how $null behaves in different contexts is crucial for writing robust scripts that handle missing or unavailable data correctly.

Testing for $null requires careful consideration of comparison order. When $null appears on the left side of a comparison, PowerShell treats it specially, but when it's on the right side, the behavior depends on the other operand's type. This asymmetry can lead to unexpected results if you're not aware of it. The -eq operator behaves differently with $null than other comparison operators, making explicit null checks important in critical code.

$value = $null
$null -eq $value # Correct way to test for null
$value -eq $null # Works but can give unexpected results with arrays
[string]::IsNullOrEmpty($value) # For string-specific null/empty testing

Null coalescing and null-conditional operators, available in PowerShell 7 and later, provide more elegant ways to handle $null values. The ?? operator returns the right operand if the left is $null, while the ?. operator safely accesses members of potentially null objects. These operators reduce the need for verbose if-statements when dealing with potentially null values.

What is the difference between single and double quotes in PowerShell?

Single quotes create literal strings where variables and escape sequences are not expanded. Everything between single quotes is treated exactly as written. Double quotes allow variable expansion and interpret escape sequences like `n for newlines. Use single quotes when you want literal text and double quotes when you need to include variable values or special characters in your strings.

How do I check what type a variable contains?

Use the GetType() method on any variable to see its type information. For example, $myVariable.GetType() returns an object containing the type name and other metadata. You can also use the -is operator to test if a variable is a specific type: $myVariable -is [string] returns $true if the variable contains a string. These techniques help you debug type-related issues and understand how PowerShell has interpreted your data.

Can I create constants in PowerShell?

Yes, use the New-Variable cmdlet with the -Option Constant parameter to create true constants that cannot be changed or deleted during the session. For example: New-Variable -Name MaxRetries -Value 3 -Option Constant. Once created, attempting to modify or remove a constant variable results in an error. This provides stronger guarantees than simply using a variable you promise not to change.

Why does my array appear to have only one element when I expect multiple?

PowerShell automatically "unrolls" arrays with a single element in many contexts, treating them as scalar values. To force an array to remain an array regardless of element count, use the @() operator when creating it or wrap the result in @(). This ensures consistent behavior whether your data source returns one item or many, preventing type-related bugs in code that expects array operations.

How do I convert a string to a number safely?

Use explicit casting with [int] or [double] for simple conversions, but wrap it in a try-catch block to handle conversion failures gracefully. Alternatively, use .NET parsing methods like [int]::TryParse() which return a boolean indicating success without throwing exceptions. For user input or untrusted data, validation before conversion prevents errors: if ($stringValue -match '^\d+$') { $number = [int]$stringValue } ensures the string contains only digits before attempting conversion.

What happens when I assign a cmdlet result to a variable?

The variable stores whatever the cmdlet outputs to the pipeline. If the cmdlet returns multiple objects, you get an array. If it returns one object, you get that object directly. If it returns nothing, the variable contains $null. This behavior means you should always consider whether a cmdlet might return varying numbers of results and handle both single-object and array cases in your code, or force array behavior with @() when consistency is important.