I presumably have a solution for you based on variables being placed in the module visibility scope. It’s based on this blogpost

You create a variable in the module scope and put all the stuff you need for the module to work in it:

$DynDnsSession = [ordered]@{
    ClientUrl           = 'https://api.dynect.net'
    ApiVersion          = $null
    AuthToken           = $null
    StartTime           = $null
    RefreshTime         = $null
}
New-Variable -Name DynDnsSession  -Value $DynDnsSession -Scope Script -Force

As the variable will be defined in the module scope, you’ll have no way of changing it with directly addressing it from your scripts – you have to have wrappers (a getter and a setter) for that variable inside your module.
For example (that is the whole .psm1 module ; based on that same blogpost)

$DynDnsSession = [ordered]@{
    ClientUrl   = 'https://api.dynect.net'
    ApiVersion  = $null
    AuthToken   = $null
    StartTime   = $null
    RefreshTime = $null
}

Function Get-DynDnsSession {
    return $DynDnsSession
}

Function Set-DynDnsSession {
    [CmdletBinding()]
    param(

    )

    DynamicParam {
        # define dictionary for dynamic parameters
        $ParamDictionary = [System.Management.Automation.RuntimeDefinedParameterDictionary]::new() 

        # get all the keys from the module variable; please note the .GetEnumerator()
        # it's to separate properties from each other, otherwise you just get all the values as a single object and not an array
        $DynProps = $DynDnsSession.Keys.GetEnumerator() 
        foreach ($Prop in $DynProps) {
            # type of the attribute. You probably can base this
            # on the type of variables you have in your dictionary
            $AttrType = "String"
            $AttrCollection = [System.Collections.ObjectModel.Collection[System.Attribute]]::new()
            $ParamAttr = [System.Management.Automation.ParameterAttribute]@{
                ParameterSetName = "DynamicFields"
                Mandatory        = $false
                HelpMessage      = $Prop # you can define this with a switch based on a property name if you want to 
            }
            $AttrCollection.Add($ParamAttr)
            $DynParam = [System.Management.Automation.RuntimeDefinedParameter]::new(
                $Prop, $AttrType, $AttrCollection
            )
    
            $ParamDictionary.Add($Prop, $DynParam)
        }
        return $ParamDictionary
    }

    PROCESS {
        foreach ($Param in $PSBoundParameters.GetEnumerator()) {
            if ($DynDnsSession.Contains($Param.Key)) {
                Write-Output $Param
                Write-Verbose "Setting $($Param.Key) to $($Param.Value)" -Verbose
                $DynDnsSession.$($Param.Key) = $Param.Value
            }
        }
    }
}

I have also defined dynamic parameters to validate what you want to set. But if you want to add or remove properties from that module variable you’ll have to use another approach (which would be easier than DynamicParam though). I use that in my multiple RestAPI modules with no problem and never had PSScriptAnalyzer complain.

DynamicParam loosely based on this post.

You can define module level scope variables. For instance:

$Script:WordList = 'cat', 'dog'

And then reference this variable in all of your module functions:

$Script:WordList

While uncommon, it is possible to export variables from PowerShell modules:

Because Import-Module and the implicit module autoloading mechanism by default import a module’s exported elements (functions/cmdlets and potentially also aliases, variables) globally, exported variables effectively become global variables by default.

However, if you ensure that your module is always imported explicitly, via Import-Module -Scope Local, any exported elements, including variables, are only visible to the importing scope and – due to PowerShell’s dynamic scoping – by all its descendent scopes.

The next section contains background information; see the bottom section for a sample implementation of a module that exports variables.

That said, given the conceptual and implementation challenges, it may be better to mediate access to module configuration data via functions or cmdlets instead, as shown in rdnaskelz’s helpful answer, which also simplifies validation of configuration changes; for instance, this is also the approach chosen by the bundled PSReadLine module, whose configuration is managed via the Get-PSReadLineOption and Set-PSReadLineOption cmdlet pair.^[*]

Challenges with respect to exporting variables:

• Conceptual / end-user challenges:

  • Because exporting variables from a module is rare, users may not expect them, and discovery of exported variables is more cumbersome than for functions / cmdlets, and aliases:

    • Exported functions / cmdlets, and aliases can be discovered via Get-Command‘s -Module parameter, e.g. Get-Command -Module Foo -All to list all such elements exported by module Foo (the -All switch is required in order to include aliases in the output).

    • By contrast, the Get-Variable cmdlet has no such parameter, and requires a less obvious, more cumbersome approach:

      # Lists any variables exported by module 'Foo'.
      Get-Variable | Where-Object { $_.Module.Name -eq 'Foo' }
      

  • Referencing exported variables from a not-yet-loaded, but autoloading module does not trigger autoloading (auto-importing) – unlike referencing an exported function / cmdlet or alias.

    • That is, in order to access a given module’s exported variables, that module must previously have been loaded (imported), either explicitly via Import-Module or implicitly by having invoked a function / cmdlet or alias exported by that module.

  • As with exported functions / cmdlets and aliases, there is a risk of name collisions with preexisting variables in the importer’s scope, and given that variable names aren’t subject to PowerShell’s naming conventions, it is worth using a prefix indicating the module of origin in the names of exported variables, say $foo_CONFIG for a variable exported from a module named Foo.

    • Additionally, note that while exported functions / cmdlets whose names clash with those of the importing scope (whether directly defined there or imported from other modules) still support access to all of them via prefixing a call with the module name followed by (e.g., FooGet-Foo), this is not directly supported with variables (and also not with aliases):

      • Any variable declared directly in the importing scope is replaced by an exported variable of the same name from a module being imported, and, if multiple imported modules define such a variable, the one from the module imported last “wins”.

      • However, there is an obscure workaround: by passing a module’s module-information object to &, the call operator, followed by a script block, the latter is executed in the (normally private) scope of the module, allowing access to its variables (as well as functions / cmdlets and aliases); e.g. & (Get-Module Foo) { $foo_CONFIG }

• Implementation challenges:

  • A full-fledged PowerShell script module that is directory-based and encompasses (at least) a script-module file, *.psm1, and a module-manifest file, *.psd1 specifies what elements to export in two layers:

    • What the *.psm1 file exports (possibly by default) are the export candidates, …

    • … which can then be constrained by the FunctionsToExport / CmdletsToExport, AliasesToExport, and VariablesToExport manifest entries.

    • For better performance, it is recommended to explicitly enumerate the elements to export in these entries rather than to use wildcards, such as @('*') to mean all.

  • Because *.psm1 files export all functions and aliases by default and given that exporting variables is rare, it is usually sufficient to focus on the *.psd1 file and to enumerate the elements to be exported only there.

  • By contrast, in order to export variables, you need to explicitly export them from the *.psm1 file, which requires a call to Export-ModuleMember using its -Variable parameter. A potential pitfall is that you must then also specify -Function and -Alias arguments in order to ensure that these types are exported too.

    • A simple solution is to use * (meaning: all) as the argument for all three parameters, and enumerate the specific elements in the *.psd1 file, as usual; be sure to place the call at the end of the file, to ensure that all exportable elements have already

       # At the *end* of your *.psm1 file: 
       # Export all variables, functions, and aliases.
       # You may be specific here, but you'll have to repeat the 
       # specific names in your *.psd1 file.
       Export-ModuleMember -Variable *  -Function * -Alias *
      

Sample module that exports a variable:

• The following creates a full-fledged sample module named ModuleWithVars that exports variable $mwv_Foo programmatically, in the current user’s temp directory, along with a sample function, Get-MwvFoo.

• To inspect the module after running the code, examine the files in the directory whose path is returned by:

  Join-Path ('/tmp', $env:TEMP)[$env:OS -eq 'Windows_NT'] ModuleWithVars
  

• To clean up afterwards, run the following:

  Remove-Module -ErrorAction Ignore ModuleWithVars
  Remove-Item -Recurse (Join-Path ('/tmp', $env:TEMP)[$env:OS -eq 'Windows_NT'] ModuleWithVars)
  

# Create the module directory and determine the manifest and script-module file paths.
$moduleDir = New-Item -Type Directory -Force (Join-Path ('/tmp', $env:TEMP)[$env:OS -eq 'Windows_NT'] ModuleWithVars)
$moduleManifest = Join-Path $moduleDir ModuleWithVars.psd1
$scriptModule = Join-Path $moduleDir ModuleWithVars.psm1

# Create a minimal module manifest; normally, manifests are created with
# New-ModuleManifest
@'
@{
RootModule = 'ModuleWithVars.psm1'
ModuleVersion = '0.0.1'
Description = 'Sample module that demonstrates variable export'
# Specify the elements to export here; enumerate them explicitly.
FunctionsToExport = @( 'Get-MwvFoo' )
AliasesToExport = @()
VariablesToExport = @( 'mwv_Foo' )
}
'@ > $moduleManifest

# Create a simple script module with one sample function and variable
# $mwv_Foo to export.
@'
# Define a sample function.
function Get-MwvFoo {
  'Hi from module ModuleWithVars'' Get-MwvFoo function.'
}

# Define the variable to export.
$mwv_Foo = 'Hi from module ModuleWithVars'' $mwv_Foo variable.'

# At the *end* of your *.psm1 file: 
# Export-ModuleMember -Variable MUST be used in order to export variables, 
# in which case -Function and -Alias must also be used.
# '*' targets all, to be constrained by the *.psd1 file.
Export-ModuleMember -Variable *  -Function * -Alias *
'@ > $scriptModule

# Now that the module has been created, import it
# (of necessity by its full module-directory path, given that it isn't
# in a location discoverable by module autoloading).
Import-Module -Force -Verbose $moduleDir

# Invoke the exported function and print the value of the exported variable.
Get-MwvFoo
$mwv_Foo

You should see output such as the following; the verbose output indicates what elements were imported by the caller, thanks to passing -Verbose to Import-Module:

^{[*] However, note that if the Get- cmdlet returns an internally used configuration dictionary (hashtable) as-is, it is still possible for the caller to manipulate it directly, potentially bypassing any validation by the Set- cmdlet. This applies to both dnaskelz’s answer and the Get-PSReadLineOption / Set-PSReadLineOption cmdlet pair.}