YAML and Other Configuration Formats in DevOps

1. YAML is common DevOps configuration—not a magical data model

YAML is widely used by Kubernetes, GitHub Actions, Ansible, Docker Compose, CI systems, and infrastructure tooling. Its surface syntax is designed for human authoring, but after parsing it still becomes mappings (key/value objects), sequences (arrays), and scalar values.

The core engineering rule from this chapter remains: parse structured data with a parser, work with objects, and serialize through a format-aware tool. Do not edit YAML with broad regex replacement unless the task is intentionally plain text.

2. Current PowerShell still needs a YAML dependency

PowerShell's core utility module has built-in converters for JSON, CSV, and CLIXML, but not a core ConvertFrom-Yaml/ConvertTo-Yaml pair. Microsoft documentation for YAML conversion currently demonstrates the community powershell-yaml module. That means YAML parsing introduces a dependency and a supply-chain decision.

Before installing any module in production, verify publisher/repository metadata, pin an approved version, test it, and mirror it to a controlled repository when your organization requires that.

3. Inspect before installing

Get-Command ConvertFrom-Yaml -ErrorAction SilentlyContinue
Get-InstalledPSResource -Name powershell-yaml -ErrorAction SilentlyContinue
# If your environment approves the dependency, installation can be explicit:
# Install-PSResource -Name powershell-yaml -Scope CurrentUser
# Legacy PowerShellGet equivalent:
# Install-Module -Name powershell-yaml -Scope CurrentUser

4. Mappings, sequences, scalars, and indentation

A mapping is a key/value structure, a sequence is a list, and a scalar is a single value such as a string, number, boolean, or null. Indentation expresses nesting, so tabs/spaces and accidental indentation changes can alter meaning.

$yamlText = @'
service:
  name: api
  enabled: true
  replicas: 3
  ports:
    - 443
    - 8443
  labels:
    tier: backend
    owner: platform
'@

5. YAML scalar typing can surprise you

YAML parsers interpret plain scalars according to their schema/version rules. Values that look like booleans, numbers, nulls, or dates may become typed values instead of strings. Quote identifiers when their textual representation must be preserved, and validate the resulting object rather than assuming what type the parser chose.

# After parsing with an approved YAML module:
# $cfg = $yamlText | ConvertFrom-Yaml
# $cfg.service.enabled.GetType().FullName
# $cfg.service.replicas.GetType().FullName

6. Object transformation makes cross-format workflows simple

Once parsed, YAML is just structured state in memory. You can validate it and emit JSON for an API, without line-by-line substitution.

# Requires an approved YAML converter such as powershell-yaml.
if (-not (Get-Command ConvertFrom-Yaml -ErrorAction SilentlyContinue)) {
    throw 'ConvertFrom-Yaml is not available. Install/approve a YAML module before running this lab.'
}
$cfg = $yamlText | ConvertFrom-Yaml
$cfg | ConvertTo-Json -Depth 10

7. Other configuration formats you will encounter

A format is a contract. Prefer the consumer's native format instead of inventing a translation layer without need.

8. PSD1 data files are PowerShell-native configuration data

A .psd1 data file uses a restricted PowerShell hashtable-like syntax and is common for module manifests and PowerShell-owned configuration. Import-PowerShellDataFile reads supported data safely without treating the file as a general script entry point.

$data = @'
@{
    Environment = 'staging'
    Retries = 3
    Features = @('metrics','tracing')
}
'@
$path = Join-Path ([System.IO.Path]::GetTempPath()) 'chapter11.psd1'
$data | Set-Content -LiteralPath $path -Encoding utf8
Import-PowerShellDataFile -LiteralPath $path
Remove-Item -LiteralPath $path -Force

9. Why regex is a poor default for structured configuration

Regex operates on text patterns. Configuration parsers understand nested structure, quoted scalars, escaping, comments, aliases, keys, and arrays. A regex like -replace 'replicas:.*','replicas: 5' can modify commented examples, nested keys, or unrelated text. Parse first, change the intended property, then serialize.

10. Lab: local YAML → object → validation → JSON

This lab uses no paid service. It requires an approved ConvertFrom-Yaml implementation. The guard fails clearly instead of silently installing a dependency.

if (-not (Get-Command ConvertFrom-Yaml -ErrorAction SilentlyContinue)) {
    throw @'
This lab requires a YAML parser. Review and install an approved module such as powershell-yaml,
then restart the lab. The course intentionally does not auto-install dependencies.
'@
}

$yaml = @'
service:
  name: catalog
  environment: staging
  replicas: 2
  features:
    - metrics
    - tracing
'@

$config = $yaml | ConvertFrom-Yaml
$service = $config.service
if ($service.environment -notin 'dev','staging','prod') { throw 'Invalid environment' }
if ([int]$service.replicas -lt 1 -or [int]$service.replicas -gt 20) { throw 'replicas out of range' }

$result = [pscustomobject]@{
    name        = [string]$service.name
    environment = [string]$service.environment
    replicas    = [int]$service.replicas
    features    = @($service.features)
}
$result | ConvertTo-Json -Depth 5

Expected observations

• If no approved YAML converter exists, the lab stops with an actionable dependency message and changes no system state.
• With powershell-yaml or another approved converter available, the YAML mapping becomes an object that can be validated normally.
• The final JSON contains catalog, staging, numeric replicas: 2, and a two-element features array.

11. Verification checklist

• I can state that YAML conversion is an external dependency in core PowerShell 7.6.
• I can identify YAML mappings, sequences, and scalars.
• I can explain why production scripts should not silently install parser modules.
• I can transform parsed YAML to JSON without regex/string replacement.

12. A practical decision framework

• CSV: flat rows for spreadsheets and simple interchange.
• JSON: nested, widely interoperable, API-friendly data.
• XML: enterprise schemas, attributes/namespaces, build/test tooling.
• CLIXML: PowerShell-oriented snapshots where interoperability is secondary.
• YAML: human-authored DevOps configuration when the surrounding ecosystem already uses it.
• PSD1: PowerShell-owned data and module metadata.
• Database: when configuration becomes shared, queried, transactional, concurrent, or too large/relational for files.

13. Common mistakes

• Assuming YAML conversion is built into core PowerShell.
• Auto-installing a dependency in a production script without approval or version control.
• Editing YAML/JSON/XML with broad regex replacements.
• Assuming scalar types without inspecting/validating parsed values.
• Choosing a format based on personal preference instead of the consumer contract.

14. Knowledge check

15. Chapter summary

You now have a format-selection mental model rather than a bag of string tricks. CSV is flat, JSON and XML are interoperable nested formats with different strengths, CLIXML is PowerShell-oriented serialization, and YAML is common DevOps configuration with an explicit parser dependency. Across all formats: parse, validate, manipulate objects, serialize at the boundary, and treat encodings/dependencies/security as part of the contract.

16. Next chapter bridge

Chapter 12 moves from data representation back to operating-system evidence: processes, services, CIM, event logs, scheduled tasks, and platform boundaries. The structured-data skills from this chapter will let you capture that evidence cleanly instead of flattening it into fragile text.

17. Authoritative and dependency references

• Microsoft Learn — example using the powershell-yaml module for YAML conversion
• PowerShell Gallery — powershell-yaml package metadata
• Microsoft Learn — Import-PowerShellDataFile
• Microsoft Learn — ConvertFrom-Json