What's new​

https://github.com/Mynster9361/msgraphProxy/blob/main/changelog.md

Install-Module -Name msgraphProxy -Scope CurrentUser -Force

See the module docs and command reference for details, or view it on the PowerShell Gallery.

Intro​

If you have ever written a script that fetches all users, all groups, or all devices from Microsoft Graph on a schedule, you already know the pain: even with $select trimming down the properties and $filter narrowing the result set along with ´batching´, you are still re-downloading data that has not changed since the last run. Delta endpoints are the answer to that problem. They let you do one full sync to get a baseline, and from that point forward only receive the objects that were added, updated, or deleted since your last call.

NOTE: the below result is of a tenant with 25k users

LinkedIn: Morten Mynster

Discord: Morten (Mynster)

What do Delta endpoints do?​

A delta endpoint works in two phases:

1. Initial sync – You call the endpoint without a delta token. Graph pages through the full result set exactly like a normal request, but at the very end of the last page it returns a @odata.deltaLink instead of a @odata.nextLink.
2. Incremental sync – You store that delta link (or the token embedded in it) and use it on your next run. Graph now returns only the objects that changed since the token was issued, along with a fresh delta link for the next cycle.

Deleted objects are included too — they come back as stub objects with a @removed annotation so you know to remove them from your local copy.

The net effect is dramatic: a tenant with 50k users might return thousands of objects on the first call, but only a handful on subsequent runs when activity has been low.

The token under the hood​

The delta link URL looks like this:

https://graph.microsoft.com/v1.0/users/delta?$deltatoken=<opaque-string>

The opaque token encodes a server-side cursor. You do not need to understand its contents — just store it and hand it back on the next request.

Two important expiry behaviours to be aware of:

• Token expiry — For directory objects (users, groups, devices, service principals, etc.) delta tokens are valid for 7 days. For Outlook entities (messages, mail folders, events, contacts, etc.) the limit is not fixed — it depends on the size of the internal delta token cache. When a token expires, Graph returns a 40X error with code syncStateNotFound. That is your signal to restart with a full sync.
• Synchronisation reset — Separately, Graph can return 410 Gone with a Location header pointing to an empty $deltatoken. This happens due to internal maintenance or tenant migration and also requires a fresh full sync.

So when would a use case for this occur?​

Think about any recurring automation that keeps a local copy of directory data in sync:

• Nightly user sync to a database or SIEM — Instead of re-importing 80k rows every night, only process the 30 accounts that were created, changed, or deleted since yesterday.
• Group membership cache — Keep a local hashtable of group members up to date without hammering the groups endpoint every few minutes.
• Device compliance dashboard — Track which devices moved in or out of compliance since the last poll.
• Licence reconciliation — Detect newly onboarded or offboarded users without a full tenant export each time.
• Teams channel message sync — Archive only new messages rather than fetching entire conversation histories.

Any scenario where you need what changed rather than everything that exists is a candidate for a delta endpoint.

Benchmarking: full fetch vs delta​

Using Invoke-RestMethod (raw approach)​

To understand what is happening under the hood, here is the full implementation using plain Invoke-RestMethod.

First run — full sync, delta link captured

$clientId = ''
$clientSecret = ''
$tenantId = ''

$tokenBody = @{
    Grant_Type    = "client_credentials"
    Scope         = "https://graph.microsoft.com/.default"
    Client_Id     = $clientId
    Client_Secret = $clientSecret
}
$tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method POST -Body $tokenBody

$headers = @{
    Authorization  = "Bearer $($tokenResponse.access_token)"
    'Content-Type' = 'application/json'
}

Measure-Command {
    $users = [System.Collections.Generic.List[object]]::new()
    $t = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/users/delta" -Headers $headers -Method GET

    do {
        $t.value | ForEach-Object { $users.Add($_) }
        if ($t.'@odata.nextLink') {
            $t = Invoke-RestMethod -Uri $t.'@odata.nextLink' -Headers $headers -Method GET
        }
    } while ($t.'@odata.nextLink')

    # At this point $t.'@odata.deltaLink' holds the cursor for the next run
    $deltaLink = $t.'@odata.deltaLink'
    $deltaLink | Set-Content -Path "delta_link.txt" -Encoding utf8

    $users | ConvertTo-Json -Depth 10 | Out-File -FilePath "delta_users_full.json" -Encoding utf8
}
<#
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 44
Milliseconds      : 18
Ticks             : 440184726
TotalDays         : 0,0005094730625
TotalHours        : 0,0122273535
TotalMinutes      : 0,73364121
TotalSeconds      : 44,0184726
TotalMilliseconds : 44018,4726
#>

Notice the loop condition: while a @odata.nextLink exists we keep paging. When there are no more pages Graph replaces it with @odata.deltaLink — that URL is your cursor and must be saved before the script exits.

Subsequent runs — only changes

$deltaLink = Get-Content -Path "delta_link.txt" -Raw

Measure-Command {
    $changes = [System.Collections.Generic.List[object]]::new()
    $t = Invoke-RestMethod -Uri $deltaLink -Headers $headers -Method GET

    do {
        $t.value | ForEach-Object { $changes.Add($_) }
        if ($t.'@odata.nextLink') {
            $t = Invoke-RestMethod -Uri $t.'@odata.nextLink' -Headers $headers -Method GET
        }
    } while ($t.'@odata.nextLink')

    # Save the new delta link for the next run
    $t.'@odata.deltaLink' | Set-Content -Path "delta_link.txt" -Encoding utf8

    $changes | ConvertTo-Json -Depth 10 | Out-File -FilePath "delta_users_changes.json" -Encoding utf8
}
<#
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 135
Ticks             : 1359807
TotalDays         : 1,57385069444444E-06
TotalHours        : 3,77724166666667E-05
TotalMinutes      : 0,002266345
TotalSeconds      : 0,1359807
TotalMilliseconds : 135,9807
#>

This works, but as you can see there is quite a bit of boilerplate: manual pagination, manually detecting which link type came back on the last page, and manually persisting the cursor. Also note that i had 0 changes between these two but instead of having to gather all the data again and basicly wasting 44 seconds we were just told no changes since last request so in this instance it is the very least amount of time to execute.

Using EntraAuth (simplified approach)​

The EntraAuth module wraps all of the above into a single parameter.

First run — full sync, baseline stored

NOTE: The time result will be the same just a lot less code

Connect-EntraService -Service "Graph" -ClientID $clientId -TenantID $tenantId -ClientSecret $clientSecret

$delta = @{}

Measure-Command {
    $users = Invoke-EntraRequest -Path 'users/delta' -DeltaSession $delta
    $users | ConvertTo-Json -Depth 10 | Out-File -FilePath "delta_users_full.json" -Encoding utf8
}

This will page through every user in the tenant and write the full set to disk. The $delta hashtable is populated in-place by the module with the delta token, ready for the next run.

Subsequent runs — only changes

Measure-Command {
    $changes = Invoke-EntraRequest -Path 'users/delta' -DeltaSession $delta
    $changes | ConvertTo-Json -Depth 10 | Out-File -FilePath "delta_users_with_delta_session.json" -Encoding utf8
}

On the second call the -DeltaSession parameter makes Invoke-EntraRequest automatically append the stored delta token to the request URL. In a quiet tenant the response is near-instant because almost nothing has changed.

Why the -DeltaSession parameter is so convenient​

Compare the two approaches side by side. With raw Invoke-RestMethod you must:

1. Detect whether the last page returned @odata.deltaLink or @odata.nextLink.
2. Extract the delta link from the final response yourself.
3. Persist the link to disk between runs and restore it on the next invocation.
4. Remember to update the saved link after every run.

With -DeltaSession you pass a plain [hashtable] reference and the module handles all of that bookkeeping for you. The hashtable is updated in-place so the same variable is ready to use on the next iteration.

Persisting the EntraAuth delta session between script runs​

Because $delta is just a hashtable, serialising and restoring it is trivial:

# Save token to disk after each run
$delta | ConvertTo-Json | Set-Content -Path "delta_token.json" -Encoding utf8

# Restore on next run
$delta = Get-Content -Path "delta_token.json" -Raw | ConvertFrom-Json -AsHashtable

Now your script can be run in a scheduled task and pick up exactly where it left off every time.

Handling deleted objects​

Delta responses include deletions as lightweight stub objects. When processing changes, check for the @removed key:

foreach ($user in $changes) {
    if ($user.'@removed') {
        switch ($user.'@removed'.reason) {
            'changed' {
                # Soft-deleted — still restorable via the deletedItems API
                Write-Host "Soft-deleted (restorable): $($user.id)"
            }
            'deleted' {
                # Permanently deleted — cannot be restored
                Write-Host "Permanently deleted: $($user.id)"
            }
        }
    } else {
        # Object was added or updated
        Write-Host "Changed: $($user.displayName)"
    }
}

The reason value matters if your downstream system needs to distinguish between a recoverable deletion (changed) and a hard delete (deleted).

Available Delta endpoints currently​

# Directory / identity
/administrativeunits/delta
/applications/delta
/contacts/delta           # organisational contacts
/devices/delta
/directoryroles/delta
/directoryobjects/delta
/oauth2permissiongrants/delta
/serviceprincipals/delta
/users/delta

# Groups
/groups/delta
/groups/{id}/calendar/calendarview/delta
/groups/{id}/calendar/events/delta
/groups/{id}/calendarview/delta
/groups/{id}/drive/root/delta
/groups/{id}/events/delta
/groups/{id}/planner/plans/delta

# OneDrive / SharePoint
/drives/{id}/root/delta
/sites/delta
/sites/{id}/drive/root/delta
/sites/{id}/lists/{id}/items/delta

# Planner
/planner/plans/{id}/buckets/delta
/planner/rosters/{id}/plans/delta
/planner/tasks/delta

# Teams
/teams/{id}/channels/{id}/messages/delta

# Per-user: calendar / mail / contacts
/users/{id}/calendar/events/delta
/users/{id}/calendargroups/{id}/calendars/{id}/events/delta
/users/{id}/calendars/delta
/users/{id}/calendars/{id}/calendarview/delta
/users/{id}/calendars/{id}/events/delta
/users/{id}/calendarview/delta
/users/{id}/contactfolders/delta
/users/{id}/contactfolders/{id}/contacts/delta
/users/{id}/events/delta
/users/{id}/mailfolders/delta
/users/{id}/mailfolders/{id}/messages/delta
/users/{id}/mailboxfolders/delta      # mailboxFolder resource
/users/{id}/mailboxitems/delta        # mailboxItem resource

# Per-user: drive / Planner / To Do
/users/{id}/drive/root/delta
/users/{id}/planner/all/delta
/users/{id}/planner/tasks/delta
/users/{id}/tasks/lists/delta
/users/{id}/tasks/lists/{id}/tasks/delta
/users/{id}/todo/lists/delta
/users/{id}/todo/lists/{id}/tasks/delta

# Education
/education/classes/delta
/education/schools/delta
/education/users/delta
/education/classes/{id}/assignments/delta

# Calls / recordings (beta only)
/communications/callRecords/{id}/sessions/delta
/teams/{id}/channels/{id}/messages/{id}/replies/delta

Reference: Microsoft Graph delta query overview

Intro​

So you are ready to begin seeing how many permissions you can remove from your applications, Great!

This step-by-step guide that i believe some people need in order to get started with my module but to be honest i have no clue is this is the issue for the low adoption rate that i am seeing. So if you are brave and have an opinion or feedback that you think is would help more people adopt my module please reach out to me i am on discord or linkedin and my messages are open.

LinkedIn: Morten Mynster

Discord: Morten (Mynster)

Get up and running​

First up a prerequisite for you to be able to set this up is to have either Entra ID P1 or P2 license. The easiest way to see this is by going to the Entra Overview page.

Here you should be able to see which license you have for Entra

Now that is out of the way lets get started.

Setup a Log Analytics workspace​

First you need a subscription and if you have been using Azure i will gurantee you already have one that you have access to and can utilize.

Easy peacy right!

Setup Entra diagnostics for Microsoft Graph Activity Logs​

Now the log analytics workspace is created we need to enable the diagnostics logs so go to Entra and then Diagnostic settings

Click Add diagnostic setting

Now give the diagnostic setting a name like "MicrosoftGraphActivityLogs" Enable MicrosoftGraphActivityLogs and send to log analytics workspace and select you subscription and log analytics workspace

Done deal now you have logs for Microsoft graph activity. Note it will take a bit to populate with data

You can go to log analytics and try and request some data from the log analytics workspace like the below example

Example query:

MicrosoftGraphActivityLogs | where RequestUri endswith "/users"

Setup an automation to gather the report on a regular basis​

Create your app registration

Create some credentials to use for authentication

Now give the role "Log Analytics Reader" to the service principal on the log analytics workspace

And give the app Application.Read.All permissions

NOTE: if you want to audit Delegated permissions you also need to add "Directory.Read.All" as that is the least privileged role that can send requests to the endpoint "/oauth2permissiongrants"

Once that is done you can use the following code to create a report:

$tenantId = "Your tenant id"
$clientId = "App id"
$clientSecret = "App secret" | ConvertTo-SecureString -AsPlainText -Force
$daysToQuery = 5 # How long back should this report be this is 5 days
$logAnalyticsWorkspaceId = "Workspace id from the log analytics can be found on the overview of log analytics"

Import-Module LeastPrivilegedMSGraph

Initialize-LPMSLogAnalyticsApi

Connect-EntraService -Service "LogAnalytics", "GraphBeta" -ClientID $clientId -TenantID $tenantId -ClientSecret $clientSecret

$msGraphReport = Get-LPMSAppRoleAssignment
$msGraphReport | Get-LPMSAppActivityData -WorkspaceId $logAnalyticsWorkspaceId -Days $daysToQuery # Defaults to 100k entries per app use -MaxActivityEntries to increase max is 500k entries per app
$msGraphReport | Get-LPMSAppThrottlingData -WorkspaceId $logAnalyticsWorkspaceId -Days $daysToQuery
$msGraphReport | Get-LPMSPermissionAnalysis
Export-LPMSPermissionAnalysisReport -AppData $msGraphReport -OutputPath ".\report.html"

That's it now you have a report that you can utilize to better limit your applications to only the needed permissions.

How to read the report​

The first view you will be met with might be a bit overwhelming but lets get to it!

All apps​

First up the general information you will see the Total apps, the apps in your tenant that already has the most optimal permissions, Apps that has excessive permissions and apps with unmatched activities.

So first up Total apps makes sense right? but you might be thinking wait i have way more than 1612 apps why is it only showing that? Well the report only works for apps with Microsoft Graph permissions assigned either application permissions or delegated permissions.

Optimal permissions​

This section will show a list of apps that already is setup correctly compared to which endpoints it has sent requests to.

Excessive Permissions​

This will show a list of apps that for one reason or another has permissions that it does not use or is higher privileged than what the app is sending requests to to give an example lets say we have an app that sends GET requests to the /groups endpoint and that the app has Group.ReadWrite.All permissions then this app would be included in the Excessive permissions as the least privileged permissions for the GET /groups endpoint is GroupMember.Read.All so the suggested action would be to remove the Group.ReadWrite.All permission and give the GroupMember.Read.All permission.

Apps with Unmatched Activities​

These are apps where i have not been able to map one or more of the requests sent by the app up with a permission hopefully in the future i will be able to match 100% of all activites but for now each app that has unmatched activity will contain a list of the endpoints i have not been able to match up.

Throtling​

The second set of blocks is concerning throttling which is more of a subset addition for the actual report it is just something that can be helpful if you ever run into an issue with one or more apps being throttled a lot this will help you identify those and then you can dig futher into it by utilizing the log analytics workspace i will not get more into it for now.

The easy part - No activity​

Moving into some of the more fun stuff if you just want a list of apps where you can remove permissions from straight away to get some value from this module set the filter "Activity Status" to "No Activity" This will give you a complete list of all apps that has some Microsoft Graph Permissions but are not using them most of them will properly be the default delegated permission "User.Read" you should be able to remove 90% of these with out having to spend to much time investigating. The others that might be included here will properly also be some SSO applications these can be a bit more tricky as you will properly not see too much activity on these for these i would suggest having Sign-in logs enabled in diagnostic settings so you can see if there are any sign ins to the app. If there is no sign in and there is no Microsoft graph activity i will almost gurantee that the app is no longer in use.

The harder part - Excessive permission​

Looking at the 2 below pictures we have the app ZDX Endpoint Analytics First we have some Throttling statistics along with some general information on errors, amount of requests along with when it was first and last seen (Based on how many days you looked back)

For this app we successfully matched up all activities from the app within the timeframe. We can see what the app has as Current Permissions. Next we get a list of the "Optimal Permissions" this is what the app should have in order to query the endpoints that it is sending requests to below that/those permissions you will also have a drop down available showing which endpoints this permission covers in this instance the least privileged permission for all the endpoints that it is requesting is covered by one permission "DeviceManagementManagedDevices.Read.All" which means the rest of the permissions can be removed as shown in the Excess permissions.

Finally at the bottom we will have a list of the API Activities that the app has sent requests to and what method was used.

Finally if this application had any endpoints that my module was not able to lookup a permission for it would be listed below the API Activites like shown below:

So how much does it cost​

This is for a larger tenant for January and the total cost for the logs we have enabled 1.659,70 $ USD

The more realistic cost for just the MSGraph activity logs that we have would be 304.722 * 2.78$ = 847,12716 $ USD

Which in total gives us 399.684.221 entries in my instance so quite a lot of data to pass through!

Background​

While developing a PowerShell module to enable sending Actionable Messages from PowerShell to Outlook, I discovered a significant information exposure issue in the Microsoft Actionable Messages admin portal. This post details the journey from initial discovery through disclosure to resolution.

The Discovery​

To send Actionable Messages, developers must register on the Actionable Email Developer Dashboard. Organizations can choose between two approval scopes:

• Organization: Requires approval from the organization's Exchange administrator
• Global: Requires approval from Microsoft

The Vulnerability​

The issue was found in the admin portal where administrators could search for Microsoft-approved providers:

Actionable Email Developer Dashboard Admin site

Any user with Global Administrator or Exchange Administrator permissions could view detailed information about all approved providers Note that anyone could register their own tenant give themself the permission and see this., including:

• Friendly Name
• Provider ID (originator)
• Organization information (including Tenant ID)
• Email address of submitter (partially masked)
• Sender email address
• Target URLs (including full query parameters)
• Scope of submission
• Audit history

The Problem​

While most of this information is reasonable for administrators to see, the critical issue was the Target URLs field. This field exposed complete URLs including query parameters that often contained secrets such as API keys, SAS tokens, and signature values:

Example: Logic App Credentials Exposed​

Friendly Name: TimesheetsApproval
Provider Id: cd8aac59-1e1e-48f9-a9fc-5db88acf31d7
Target URL: https://prod-132.westeurope.logic.azure.com:443/workflows/
  cc2d84593b344d10bcf06fdfc24f28d8/triggers/manual/paths/invoke?
  api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&
  sig=A_SUPER_SECRET_KEY_WAS_WRITTEN_HERE

The above is one example there were multiple available be it internally developed apps with secrets in the url or other Microsoft services other than logic apps

The exposed signature keys (sig parameter) allowed anyone to:

• Send POST requests to these Logic Apps
• Potentially run up costs for the affected organizations
• Inject malicious payloads depending on Logic App implementation
• Trigger unintended workflows

Before 23.rd december:

After 23.rd december:

Attack Vectors​

The exposed secrets in target URLs enabled several attack vectors be it that some is more unlikely than others:

1. Cost Amplification​

Attackers could repeatedly trigger Logic Apps to generate unexpected Azure costs for the affected organizations.

2. Workflow Manipulation​

Depending on Logic App implementation, attackers could inject data that would be processed, potentially causing:

• Unauthorized actions
• Data manipulation
• Service disruptions

3. Unauthorized Access​

Any service using secrets in the target URL could be accessed by anyone with administrator permissions in any Microsoft 365 tenant, bypassing intended access controls.

Disclosure Timeline​

August 6, 2025 - Initial Report to MSRC​

Submitted detailed report to Microsoft Security Response Center (MSRC) including:

• Description of the vulnerability
• Screenshot evidence
• Potential impact assessment
• List of affected providers

MSRC Case: 100332

August 7, 2025 - Case Opened​

MSRC acknowledged the report and opened an investigation.

August 26, 2025 - MSRC Assessment​

MSRC concluded: "We consider this a moderate severity as there is a fairly limited attack scope and appears to be more of a privacy issue than a security issue."

The team forwarded the report to the product group for consideration of a future fix.

August 27, 2025 - Disclosure Discussion​

I inquired whether affected customers would be notified. I never received an answer to this question MSRC confirmed I was free to disclose publicly and requested a draft for review.

September 12, 2025 - Draft Submission​

Submitted draft blog post and LinkedIn post with proposed disclosure date of September 23, 2025.

September 23, 2025 - Postponement​

After not receiving feedback, I postponed publication to allow MSRC additional review time.

October 28, 2025 - Support Case Opened​

Opened Microsoft support case TrackingID#2510281420002121 to follow up on remediation efforts.

October 30, 2025 - Product Team Engagement​

Support engineer @Microsoft escalated the issue to onboardoam@microsoft.com (OAM Partner Onboarding Support team).

November-December 2025 - Implementation​

The OAM team developed and tested a fix through Microsoft's internal rings.

December 10, 2025 - Fix Announced​

Microsoft confirmed the fix was ready: "We now only display the host URI of the target URL to the admins."

December 23, 2025 - Rollout Complete​

The fix was deployed to all customers. The admin portal now shows only the host portion of URLs:

Before: https://prod-132.westeurope.logic.azure.com:443/workflows/...?sig=SECRET
After:  https://prod-132.westeurope.logic.azure.com

Impact Assessment​

Organizations Affected​

• All organizations that registered global-scoped Actionable Message providers
• Specifically those using Logic apps, Powerapps, Webhooks or other services with API keys in URLs
• Organizations included Microsoft's internal teams and third-party partners

Data Exposed​

The primary concern was credentials embedded in target URLs:

• Logic App signature keys (SAS tokens)
• API keys and secrets in query parameters
• Complete endpoint URLs revealing internal architecture

While other information like organization names and sender emails were also visible, these were considered less sensitive as they served the legitimate purpose of helping administrators identify approved providers.

Exposure Window​

The vulnerability was present from an unknown date until December 23, 2025. The admin portal was accessible to any user with Global or Exchange Administrator permissions in any Microsoft 365 tenant.

Key Takeaways​

For Developers​

1. Never include secrets in URLs: Use authentication headers or POST body parameters
2. Rotate exposed credentials: If you submitted a provider with secrets in the URL, get in contact with the OAM team and rotate them as soon as possible I heard in my case that it can take up to 14 days to get them rotated with them.
3. Review approval submissions: Check what information is visible to administrators

For Microsoft - My personal opinion​

1. Input validation: The submission form should reject or warn when URLs contain common secret patterns (sig=, key=, token=, etc.)
2. Customer notification: Organizations with exposed credentials should have been proactively notified
3. Documentation: Submission guidelines should explicitly warn against including secrets in URLs and recommend authentication headers instead
4. Display filtering: Even if secrets are submitted, the admin portal should automatically redact query parameters

Questions That Remain​

Customer Notification​

Microsoft has not confirmed whether affected organizations were notified about the exposure. Organizations should proactively:

1. Review their Actionable Message provider submissions
2. Rotate any credentials that may have been exposed in collaboration with the OAM team.
3. Review Logic App or other apps exposed through actionable messages for unexpected traffic patterns

Exposure Duration​

The timeline of when this vulnerability was introduced remains unclear. Organizations should consider credentials potentially exposed since submission date.

Recommendations​

For Affected Organizations​

Get in contact with the OAM team onboardoam@microsoft.com and agree with them when, what, where you should rotate your secrets.

Timeline Summary​

📚 Series Navigation:

• Part 1: Getting Started with Terraform for PowerShell People
• Part 2: Resources, Variables, and State in Terraform (July 22)
• Part 3: Advanced Terraform and PowerShell Integration
• Part 4: Advanced State Management and Collaboration
• Part 5: Testing Terraform Code
• Part 6: Terraform Modules Deep Dive
• Part 7: CI/CD with GitHub Actions ← You are here

Building Enterprise-Grade CI/CD Pipelines for Terraform​

Welcome to the final of our comprehensive 7-part series on Terraform for PowerShell developers! Throughout this series, we have gone from basic concepts to enterprise-grade infrastructure management. Now, we'll bring everything together by implementing CI/CD pipelines using GitHub Actions.

As PowerShell professionals who've likely worked with Azure DevOps, Jenkins, or other CI/CD tools, you'll find GitHub Actions provides familiar concepts with modern, cloud-native approaches (Even if you have never touched either i believe you are still able to follow along). In this final part, we'll create pipelines to deploy our terraform configuration.

For this i have created the following repo that you can follow along in while we go through this post.

Terraform CICD

Prerequicites​

1. App registration: For us to start creating stuff we need an app registration where we are going to use federated credentials
2. Azure subscription: For us to start creating stuff we need access to a subscription for this scenario i have given our app contributor access to my subscription
3. Github Secrets: Setup you github secrets
4. Your config: In the repo i have included code for applying a resource group and a storage account

1. App registration​

Create a new App registration call it something that relates to what you are doing or deployment name maybe your github repo name? (What i am trying to say is the name of the app does not matter to me it only matters for you and your organisation standards)

Once created go to Certificates & secrets click on Federated credentials and Add credential

Done deal now the federated credential is setup specifically to be able to login from the main branch

2. Azure subscription​

Now lets give the app some RBAC access on a subscription Go to a subscription you would like to do something in with terraform go to Access control (IAM) click on Add and Add role assignment and switch to Privileged administrator roles and select Contributor. Click Next and Select members and search for your app registration created in step 1 click Select and click Review + assign and click Review + assign - (Yes you have to click it 2 times)

Done deal now the access is in place next up is our github repo

3. Github Secrets​

To setup our secrets we will need to gather a bit of data for the implementation i am showing in my example we need the following data: AZURE_TENANT_ID = Tenant ID Your tenant id can easily be found on the Overview page in the Microsoft Entra ID blade in Azure AZURE_CLIENT_ID = Application (client) ID from our app created in step 1 AZURE_SUBSCRIPTION_ID = The subscription ID of the subscription you gave our app access to in step 2

Finally go to your Github repository click on Settings click on Secrets and variables and Actions In here Click on New repository secret and add each secret with the name it like above so AZURE_TENANT_ID = Tenant ID AZURE_CLIENT_ID = Application (client) ID AZURE_SUBSCRIPTION_ID = Subscription ID

Done deal

4. Your config​

Finally the magic we will create a github action. This step is quite easy in your repository create a folder called .github within that folder create another folder called workflows Then within this folder create a file called cicd.yml and paste the following into it:

name: Terraform CI/CD Pipeline

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  terraform:
    runs-on: ubuntu-latest

    permissions:
      id-token: write
      contents: read

    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v. 3.1.2 - https://github.com/hashicorp/setup-terraform/commit/b9cd54a3c349d3f38e8881555d616ced269862dd
        with:
          terraform_wrapper: true

      - name: Azure Login
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          
      - name: Terraform Format Check
        run: terraform fmt -check

      - name: Terraform Init
        run: terraform init -input=false

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Test
        id: terraform-test
        run: |
          terraform test || test_exit_code=$?
          echo "test_exit_code=${test_exit_code:-0}" >> $GITHUB_OUTPUT

      - name: Terraform Plan
        run: terraform plan -input=false -out=tfplan

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main'   # only auto-apply on main
        run: terraform apply -input=false -auto-approve tfplan
      
      - name: terraform show apply
        if: github.ref == 'refs/heads/main'   # only auto-apply on main
        run: terraform show -no-color

      - name: Terraform Destroy
        if: github.ref == 'refs/heads/main'   # only auto-apply on main
        run: terraform destroy -auto-approve 

That is it now we have a complete CICD pipeline so lets end the post here.

I am just kidding ofcourse lets go over some of the stuff in this flow

Lets get into the setup and explain the workflow​

First up we are giving the workflow a name this name is what will be shown in our Actions pane in github under All workflows​

name: Terraform CI/CD Pipeline

Second up we have our trigger for our flow​

This piece of code basicly says when there is something new added to a branch named main it will run this flow and below that we also add a trigger for when someone makes a (PR or pull request) to our repository then it will start this action

on:
  push:
    branches:
      - main
  pull_request:

Third we are setting up our actual job​

In this code we are saying this is a job - our jobs name is terraform (Name is up to you i like to keep it simple). Then we are defining what our job will run on so which platform for this i have selected ubuntu-latest.

And finaly we are giving our action some extra permissions to our repository it will get an id-token write which it needs for our azure login later and it gets a contents read permission so it can read what is in our repository

jobs:
  terraform:
    runs-on: ubuntu-latest

    permissions:
      id-token: write
      contents: read

Next we have the exiting part our Steps thing of it like a stairway you take one step at a time So first we checkout our repository with an action made by github

    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

Then we install terraform using a pre built action made by hashicorp

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v. 3.1.2 - https://github.com/hashicorp/setup-terraform/commit/b9cd54a3c349d3f38e8881555d616ced269862dd
        with:
          terraform_wrapper: true

Then we login to Azure using an action made by Microsoft and suppling our secrets from Github that we setup in prereq 3

      - name: Azure Login
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Then we come to the Terraform stuff which makes our whole pipeline First up we also want to make sure that our terraform code is correctly formated with the terraform fmt -check command next we initialize our terraform code basicly the same as installing modules before you can run your code with the command terraform init -input=false Then we validate our configuration with terraform validate so we know that every piece of our code is working as it should

Then we run all our tests by default when running terraform test it will run all files called something.tftest.hcl within a folder called tests Here we are running 2 commands and it is basicly test our terraform code and if it fails outbut the failure to our github action

Then we run terraform plan so we get to see what our deployment will look like.

And the last step for us is to apply the plan BUT we have an if statement and we are looking at a built in variable called github.ref which will return which branch we are in and say that it should only run if the branch we are in is refs/heads/main

And finaly since our terraform apply does not output anything other than the creation process we run terraform show -no-color to show what has been created

      - name: Terraform Format Check
        run: terraform fmt -check

      - name: Terraform Init
        run: terraform init -input=false

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Test
        id: terraform-test
        run: |
          terraform test || test_exit_code=$?
          echo "test_exit_code=${test_exit_code:-0}" >> $GITHUB_OUTPUT

      - name: Terraform Plan
        run: terraform plan -input=false -out=tfplan

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main'   # only auto-apply on main
        run: terraform apply -input=false -auto-approve tfplan
      
      - name: terraform show apply
        if: github.ref == 'refs/heads/main'   # only auto-apply on main
        run: terraform show -no-color

Now in my example workflow i also include a destroy at the end just because i have not included any kind of state storage or anything for this CICD workflow so just to cleanup after my self at the end i have added terraform destroy -auto-approve which just deletes the newly created resource again

      - name: Terraform Destroy
        if: github.ref == 'refs/heads/main'   # only auto-apply on main
        run: terraform destroy -auto-approve 

Now if you wanted some kind of backend implementation you could just edit your providers.tf file in my example and add a section like this Note it will require you to create the below resource by hand

terraform {
  backend "azurerm" {
    tenant_id            = "Your tenant id"
    subscription_id      = "The subscription id the resources is placed in"
    resource_group_name  = "a resource group with a storage account"
    storage_account_name = "Your state config storage account"
    container_name       = "a container within your storage account"
    key                  = "a primary or secondary key to your storage account the secret can be gotten from Github secrets and injected into the workflow as a variable"
    use_azuread_auth     = true # basicly just for your federated credential authentication
    use_oidc             = true # basicly just for your federated credential authentication
  }
}

Now lets take a closer look at what is in the repo​

Our structure looks like this:

Side not i love that you can get AI to create the below structure output for you so it looks pretty

TerraformCICD/
│
├── .github/
│   └── workflows/
│       └── cicd.yml            # GitHub Actions CI/CD workflow
│
├── modules/
│   └── storage-account/        # Modularized storage account
│       ├── main.tf             # Storage account resource definition
│       ├── outputs.tf          # Module outputs
│       └── variables.tf        # Module input variables
│
├── tests/
│   └── storage_account.tftest.hcl  # Test for storage account module
│
├── .gitignore                  # Git ignore file
├── LICENSE                     # MIT License
├── main.tf                     # Main Terraform configuration
└── providers.tf                # Provider configuration

First we have our workflow i will not go deeper into this as we already covered it earlier.

Module​

Then we have a modules folder and within this folder we have one called storage-account

This is a quick module that i have just copy pasted the config directly from the example of creating an azurerm storage account

Reference: Storage account

The only thing i have changed is added the variables.tf file and the outputs.tf file and then made the inputs more dynamic in the main.tf

Just to elaborate all i did was change the static entries to var.variablename

main.tf:

resource "azurerm_storage_account" "storage_account" {
  name                     = var.name
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = var.account_tier
  account_replication_type = var.account_replication_type

  tags = var.tags
}

Then we have our outputs file which just lets terraform know what you want to be able to reference and see when this module has created the storage account just for reference if you want to see all available outputs you can scroll down to Attributes Reference Storage account - Attributes Reference

outputs.tf:

output "name" {
  description = "The name of the storage account."
  value       = azurerm_storage_account.storage_account.name
}

output "id" {
  description = "The ID of the storage account."
  value       = azurerm_storage_account.storage_account.id
}

Finally the biggest hurdle when doing stuff like this is properly making sure that your variables file is on point as this is where basicly all validation happens to your parameters.

For this section the only validating i have setup is just based on the values that are possible to select so we fail when providing our parameters instead of first failing when trying to run our plan or apply.

variables.tf:

variable "name" {
  description = "The name of the storage account"
  type        = string
}

variable "resource_group_name" {
  description = "The name of the resource group"
  type        = string
}

variable "location" {
  description = "The location of the storage account"
  type        = string
}

variable "account_tier" {
  description = "Defines the Tier to use for this storage account. Valid options are Standard and Premium. For BlockBlobStorage and FileStorage accounts only Premium is valid. Changing this forces a new resource to be created."
  type        = string

  validation {
    condition     = contains(["Standard", "Premium"], var.account_tier)
    error_message = "The account_tier must be either 'Standard' or 'Premium'."
  }
}

variable "account_replication_type" {
  description = "Defines the type of replication to use for this storage account. Valid options are LRS, GRS, RAGRS, ZRS, GZRS and RAGZRS. Changing this forces a new resource to be created when types LRS, GRS and RAGRS are changed to ZRS, GZRS or RAGZRS and vice versa."
  type        = string

  validation {
    condition     = contains(["LRS", "GRS", "RAGRS", "ZRS", "GZRS", "RAGZRS"], var.account_replication_type)
    error_message = "The account_replication_type must be one of 'LRS', 'GRS', 'RAGRS', 'ZRS', 'GZRS', or 'RAGZRS'."
  }
}

variable "tags" {
  description = "Tags to assign to the storage account"
  type        = map(string)
  default     = {}
}

Test​

Next up we have our test this test is placed in a folder called tests and the file is called storage_account.tftest.hcl

This is the test that will run when we run terraform test and if there were more those would run aswell If you need more information on testing take a look at this previous post

Part 3: Advanced Terraform and PowerShell Integration

provider "azurerm" {
  features {}
  subscription_id = "e4495bdf-ae79-4c1c-bebc-101ac07ba353"
}

variables {
  resource_group_name = "rg-test-storage"

  storage_account_name     = "testtfstoraeacct1234"
  location                 = "westeurope"
  account_tier             = "Standard"
  account_replication_type = "LRS"

  tags = {
    environment = "Development"
    project     = "GetStartedWithTerraform"
    owner       = "Morten"
  }
}

run "create_storage_account" {
  command = apply

  module {
    source = "./modules/storage-account"
  }

  variables {
    resource_group_name      = var.resource_group_name
    location                 = var.location
    name                     = var.storage_account_name
    account_tier             = var.account_tier
    account_replication_type = var.account_replication_type
    tags                     = var.tags
  }

  assert {
    condition     = output.name == var.storage_account_name
    error_message = "Storage account name did not match expected"
  }

}

Our deployment​

Finally we have our actual deployment this is what is going to be created when running terraform apply

providers.tf

terraform {
  required_version = ">= 1.12.2"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.43.0"
    }
  }
}

provider "azurerm" {
  features {}
  subscription_id = local.subscription_id
}

main.tf

locals {
  subscription_id = "e4495bdf-ae79-4c1c-bebc-101ac07ba353" # Replace with your Azure Subscription ID

  location = "West Europe"
  rg_name  = "GetStartedWithTerraformPart7"

  storage_account_name             = "terraformpart7"
  storage_account_tier             = "Standard"
  storage_account_replication_type = "LRS"

  common_tags = {
    environment = "Development"
    project     = "GetStartedWithTerraform"
    owner       = "Morten"
  }
}

resource "azurerm_resource_group" "rg" {
  name     = local.rg_name
  location = local.location
  tags     = local.common_tags
}

module "storage-account" {
  source                   = "./modules/storage-account"
  name                     = local.storage_account_name
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = local.storage_account_tier
  account_replication_type = local.storage_account_replication_type
  tags                     = local.common_tags
}

In the main file we are first creating a set of local variables needed for doing a fully automated deployment and it is easier to manage all the diffrent names and such when they are at the top and just get referenced further down as long as you give them appropiate name.

Next up we are creating a resource group just using a normal resource block.

And finaly we are using the module that we have created by first writing module "Some name for this resource" {The config}

Then we are referencing the path of the module in a source parameter Note that the module could also be in another repository if you wanted to have a collection of all your modules instead of it all being in a single repo and then just suppling the variables that is defined for that module

And that is it now you have a complete CICD pipeline for deployment.

The Complete Journey Recap​

Your Enterprise Infrastructure Platform​

By combining everything from this series, you now have the knowledge to build a complete infrastructure automation platform.

Final Thoughts​

You've successfully bridged two powerful worlds - the flexibility and familiarity of PowerShell with the declarative power and ecosystem of Terraform. This combination gives you:

• Best of Both Worlds: Leverage PowerShell for complex logic while using Terraform for infrastructure management
• Career Growth: Infrastructure as Code skills are increasingly valuable in modern IT organizations
• Future-Proofing: Position yourself and your organization for cloud-native infrastructure management

The journey from PowerShell scripter/developer to Terraform practitioner represents more than just learning a new tool - it's about embracing modern infrastructure practices that will serve you and your organization for years to come.

Thank you for reading my blog series i really hope that you got some great takeaways from it and that it advances your abilities and your career!

📚 Series Navigation:

• Part 1: Getting Started with Terraform for PowerShell People
• Part 2: Resources, Variables, and State in Terraform
• Part 3: Advanced Terraform and PowerShell Integration
• Part 4: Advanced State Management and Collaboration
• Part 5: Testing Terraform Code
• Part 6: Terraform Modules Deep Dive ← You are here
• Part 7: CI/CD with GitHub Actions (September 9)

Mastering Terraform Modules for PowerShell Users​

With comprehensive testing strategies from Part 5 now mastered, it's time to focus on creating reusable, production-ready infrastructure components. In this part, we'll dive deep into Terraform modules - the equivalent of PowerShell modules for infrastructure code.

As PowerShell professionals, you already understand the power of modularity from building PowerShell modules, functions, and reusable scripts. Terraform modules serve the same purpose for infrastructure code, allowing us to create standardized, testable, and maintainable components. Now that you have testing expertise, we can build modules that are thoroughly validated and enterprise-ready.

PowerShell Modules vs. Terraform Modules​

Let's compare the module concepts:

PowerShell Module Structure​

MyPowerShellModule/
├── MyPowerShellModule.psd1     # Module manifest
├── MyPowerShellModule.psm1     # Module implementation
├── Public/                     # Public functions
│   ├── New-AzureResource.ps1
│   └── Get-AzureResource.ps1
├── Private/                    # Private functions
│   └── helpers.ps1
└── Tests/                      # Tests for the module
    └── MyModule.Tests.ps1

Terraform Module Structure​

my-terraform-module/
├── main.tf           # Main module implementation
├── data.tf           # Data sources
├── variables.tf      # Input variables definition
├── outputs.tf        # Output values definition
├── terraform.tf       # Required providers and versions
├── README.md         # Documentation
└── examples/         # Example usage
    └── basic/
        ├── main.tf
        └── variables.tf

Creating Your First Terraform Module​

Let's create a reusable module for a web application:

# Create module directory structure
New-Item -ItemType Directory -Path ".\modules\resource-group" -Force
New-Item -ItemType File -Path ".\modules\resource-group\main.tf"
New-Item -ItemType File -Path ".\modules\resource-group\variables.tf"
New-Item -ItemType File -Path ".\modules\resource-group\outputs.tf"
New-Item -ItemType File -Path ".\modules\resource-group\terraform.tf"
New-Item -ItemType File -Path ".\main.tf"

Module Files​

# modules/resource-group/variables.tf
variable "name" {
  description = "Name of the web application"
  type        = string
}

variable "location" {
  description = "Azure region where resources will be created"
  type        = string
}

# modules/resource-group/main.tf
resource "azurerm_resource_group" "rg" {
  name     = "example"
  location = "West Europe"
}

# modules/resource-group/outputs.tf
output "id" {
  description = "Id of the resourcegroup"
  value       = azurerm_resource_group.rg.id
}

# modules/resource-group/terraform.tf
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "4.41.0"
    }
  }
  required_version = ">= 1.6.0"
}

Using the Module​

# main.tf
provider "azurerm" {
  features {}
}


module "resource-group" {
  source              = "./modules/resource-group"
  name                = "rg-from-mod"
  location            = "West Europe"
}

Module Design Patterns​

Input Variables (Like PowerShell Parameters)​

In PowerShell functions, we use parameters with validation:

function New-rg{
    [CmdletBinding()]
    param (
        [Parameter(Mandatory=$true)]
        [string]$Name,

        [Parameter(Mandatory=$true)]
        [ValidateSet("westus", "eastus", "northeurope")]
        [string]$Location
    )

    # Function logic here
}

In Terraform, we use input variables with validation:

variable "name" {
  description = "Name of the resource group"
  type        = string

  validation {
    condition     = length(var.name) > 3 && length(var.name) <= 60
    error_message = "Resource group name must be between 4 and 60 characters."
  }
}

variable "location" {
  description = "Azure region where resources will be created"
  type        = string

  validation {
    condition     = contains(["West US", "East US", "North Europe", "West Europe"], var.location)
    error_message = "Allowed values are: West US, East US, North Europe, West Europe"
  }
}

Nested Modules (Like PowerShell Functions Calling Other Functions)​

In PowerShell, we often have functions that call other functions:

function New-WebInfrastructure {
    param (
        [string]$Name,
        [string]$Location
    )

    $resourceGroup = New-AzResourceGroup -Name "$Name-rg" -Location $Location
    $storageAccount = New-StorageAccount -Name $Name -ResourceGroup $resourceGroup.ResourceGroupName
    $webApp = New-WebApp -Name $Name -Location $Location -ResourceGroup $resourceGroup.ResourceGroupName

    return @{
        ResourceGroup = $resourceGroup
        StorageAccount = $storageAccount
        WebApp = $webApp
    }
}

In Terraform, we use nested modules:

module "storage_account" {
  source = "./modules/storage_account"
  name   = "mystorage"
  location = "West Europe"
}

Where the storage_account module might look like:

# modules/storage_account/main.tf
module "resource_group" {
  source              = "./modules/resource-group"
  name                = "rg-from-mod"
  location            = "West Europe"
}

module "storage" {
  source              = "../storage"
  name                = "${var.name}store"
  resource_group_name = module.resource_group.name
  location            = module.resource_group..location
}

output "resource_group" {
  value = module.resource_group
}

output "storage" {
  value = module.storage
}

Module Best Practices​

1. Consistent Structure (Like PowerShell Module Structure)​

Just as PowerShell modules have a recommended structure, so do Terraform modules:

module-name/
├── README.md           # Documentation
├── main.tf             # Main resources
├── data.tf             # Data sources
├── variables.tf        # Input variables
├── outputs.tf          # Output values
├── terraform.tf         # Provider requirements
├── examples/           # Example usage
│   └── basic/
│       └── main.tf
└── test/               # Tests
    └── module_test.tftest

2. Use Local Values for Derived Variables (Like PowerShell Local Variables)​

In PowerShell:

function Deploy-Resources {
    param ($baseName, $env)

    $resourceGroupName = "$baseName-$env-rg"
    $storageAccountName = ($baseName + $env).ToLower() -replace "[^a-z0-9]", ""

    # Use the local variables
}

In Terraform:

locals {
  resource_group_name  = "${var.base_name}-${var.environment}-rg"
  storage_account_name = lower(replace("${var.base_name}${var.environment}", "/[^a-z0-9]/", ""))
}

module "resource_group" {
  source              = "./modules/resource-group"
  name     = local.resource_group_name
  location = var.location
}

module "storage" {
  source              = "../storage"
  name                = local.storage_account_name
  resource_group_name = module.resource_group.name
  location            = module.resource_group..location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

3. Version Your Modules (Like PowerShell Module Versioning)​

In PowerShell, we version our modules in the manifest:

# MyModule.psd1
@{
    ModuleVersion = '1.2.0'
    # ...
}

In Terraform, we can use Git tags for versions and reference them:

module "resource_group" {
  source  = "git::https://github.com/myorg/terraform-modules.git//modules/resource-group?ref=v1.2.0"
  name    = "example"
  # ...
}

Or use the Terraform Registry:

Terraform Registry:.

module "vnet" {
  source  = "Azure/vnet/azurerm"
  version = "2.6.0"
  # ...
}

Creating a Module Library (Like PowerShell Gallery)​

While PowerShell has the PowerShell Gallery, Terraform has module registries.

Private Module Registry​

For organizations, you can set up:

1. Azure DevOps Artifacts
2. GitHub Packages
3. Terraform Cloud Private Registry

Setting up a Simple Git-Based Registry​

Create a repository structure:

terraform-modules/
├── modules/
│   ├── resource-group/
│   │   ├── main.tf
│   │   └── ...
│   ├── storage/
│   │   ├── main.tf
│   │   └── ...
│   └── network/
│       ├── main.tf
│       └── ...
└── README.md

Reference modules in your Terraform configurations:

module "resource_group" {
  source = "git::https://github.com/myorg/terraform-modules.git//modules/resource-group?ref=v1.0.0"
  # ...
}

Module Testing Integration​

As covered in Part 5, testing is crucial for reliable modules. Here's how to integrate testing into your module development workflow:

Testing Module Structure​

modules/resource-group/
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tf
├── README.md
├── examples/
│   ├── basic/
│   │   └── main.tf
│   └── advanced/
│       └── main.tf
└── tests/
    ├── unit.tftest.hcl
    ├── integration.tftest.hcl
    └── variables.auto.tfvars

Unit Tests for Modules​

# modules/storage-account/tests/unit.tftest.hcl

# Mock provider for fast unit testing
override_provider "azurerm" {
  features {}
}

# Mock the resource group that the storage account depends on
override_resource {
  target = azurerm_resource_group.main
  values = {
    name     = "test-rg"
    location = "East US"
    id       = "/subscriptions/test/resourceGroups/test-rg"
  }
}

variables {
  name                = "teststorageacct"
  resource_group_name = "test-rg"
  location           = "East US"
  account_tier       = "Standard"
  replication_type   = "LRS"
  tags = {
    Environment = "Test"
    Department  = "IT"
  }
}

run "test_storage_account_creation" {
  command = plan

  assert {
    condition     = azurerm_storage_account.main.name == var.name
    error_message = "Storage account name should match input variable"
  }

  assert {
    condition     = azurerm_storage_account.main.account_tier == var.account_tier
    error_message = "Storage account tier should match input variable"
  }

  assert {
    condition     = azurerm_storage_account.main.account_replication_type == var.replication_type
    error_message = "Storage account replication type should match input variable"
  }
}

run "test_blob_properties" {
  command = plan

  assert {
    condition     = azurerm_storage_account.main.blob_properties[0].delete_retention_policy[0].days == 7
    error_message = "Default blob retention policy should be 7 days"
  }

  assert {
    condition     = azurerm_storage_account.main.min_tls_version == "TLS1_2"
    error_message = "Minimum TLS version should be 1.2 for security"
  }
}

run "test_output_values" {
  command = plan

  assert {
    condition     = output.storage_account_id != ""
    error_message = "Storage account ID output should not be empty"
  }

  assert {
    condition     = can(regex("^https://.*\\.blob\\.core\\.windows\\.net/$", output.primary_blob_endpoint))
    error_message = "Primary blob endpoint should follow Azure pattern"
  }
}

Integration Tests for Modules​

# modules/storage-account/tests/integration.tftest.hcl

variables {
  name              = "integrationtest"
  resource_group_name = "integration-test-rg"
  location         = "East US"
  account_tier     = "Standard"
  replication_type = "GRS"  # Using geo-redundant storage for integration test
  tags = {
    Environment = "Integration"
    Project     = "Testing"
  }
  allow_blob_public_access = false
  enable_https_traffic_only = true
}

# Create test resource group first
run "setup_resource_group" {
  command = apply

  module {
    source = "../examples/prerequisites"
  }
}

run "test_storage_account_deployment" {
  command = apply

  depends_on = [run.setup_resource_group]

  assert {
    condition     = azurerm_storage_account.main.account_replication_type == var.replication_type
    error_message = "Storage account should use GRS replication as specified"
  }

  assert {
    condition     = azurerm_storage_account.main.allow_blob_public_access == false
    error_message = "Public blob access should be disabled for security"
  }
}

run "test_container_creation" {
  command = apply
  depends_on = [run.test_storage_account_deployment]

  # Test that the containers are created successfully
  assert {
    condition     = length(azurerm_storage_container.containers) >= 1
    error_message = "At least one storage container should be created"
  }

  assert {
    condition     = azurerm_storage_container.containers["data"].name == "data"
    error_message = "A container named 'data' should exist"
  }
}

run "test_network_rules" {
  command = plan

  # Test that network rules are properly configured
  assert {
    condition     = azurerm_storage_account.main.network_rules[0].default_action == "Deny"
    error_message = "Network rules should deny by default for security"
  }

  assert {
    condition     = length(azurerm_storage_account.main.network_rules[0].ip_rules) > 0
    error_message = "At least one IP rule should be configured"
  }
}

PowerShell Module Testing Helpers​

# scripts/Test-TerraformModule.ps1
function Test-TerraformModule {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory)]
        [string]$ModulePath,

        [ValidateSet("unit", "integration", "all")]
        [string]$TestType = "all",

        [switch]$Verbose
    )

    Push-Location $ModulePath
    try {
        Write-Host "Testing Terraform module: $ModulePath" -ForegroundColor Cyan

        switch ($TestType) {
            "unit" {
                Write-Host "Running unit tests..." -ForegroundColor Yellow
                $result = terraform test tests/unit.tftest.hcl
                if ($LASTEXITCODE -ne 0) {
                    throw "Unit tests failed"
                }
            }
            "integration" {
                Write-Host "Running integration tests..." -ForegroundColor Yellow
                $result = terraform test tests/integration.tftest.hcl
                if ($LASTEXITCODE -ne 0) {
                    throw "Integration tests failed"
                }
            }
            "all" {
                Test-TerraformModule -ModulePath $ModulePath -TestType "unit" -Verbose:$Verbose
                Test-TerraformModule -ModulePath $ModulePath -TestType "integration" -Verbose:$Verbose
            }
        }

        Write-Host "All tests passed for module: $ModulePath" -ForegroundColor Green

    } catch {
        Write-Error "Module testing failed: $_"
        throw
    } finally {
        Pop-Location
    }
}

# Test all modules in a directory
function Test-AllTerraformModules {
    param(
        [string]$ModulesPath = "./modules",

        [ValidateSet("unit", "integration", "all")]
        [string]$TestType = "all"
    )

    $modules = Get-ChildItem -Path $ModulesPath -Directory
    $results = @()

    foreach ($module in $modules) {
        try {
            Test-TerraformModule -ModulePath $module.FullName -TestType $TestType
            $results += @{ Module = $module.Name; Status = "Passed" }
        } catch {
            $results += @{ Module = $module.Name; Status = "Failed"; Error = $_.Exception.Message }
        }
    }

    # Summary
    Write-Host "`nTest Results Summary:" -ForegroundColor Blue
    foreach ($result in $results) {
        $color = if ($result.Status -eq "Passed") { "Green" } else { "Red" }
        Write-Host "  $($result.Module): $($result.Status)" -ForegroundColor $color
        if ($result.Error) {
            Write-Host "    Error: $($result.Error)" -ForegroundColor Red
        }
    }

    $passed = ($results | Where-Object { $_.Status -eq "Passed" }).Count
    $total = $results.Count
    Write-Host "`nOverall: $passed/$total modules passed" -ForegroundColor $(if ($passed -eq $total) { "Green" } else { "Red" })

    return $results
}

Module Versioning and Lifecycle Management​

For this i would personally use dependabot to keep watch over new version and automatically create PR's for your module repository.

I will not cover the exact process but i believe this guide from GitHub should cover most circumstances:

Enabling dependabot for your repository.

Conclusion and Next Steps​

In this sixth part of our PowerShell-to-Terraform series, you've mastered creating enterprise-grade, reusable infrastructure modules:

What We've Accomplished:

1. Module Architecture: Structured, testable modules following PowerShell development patterns
2. Testing Integration: Comprehensive module testing using the native testing framework from Part 5
3. Lifecycle Management: Versioning, publishing, and maintaining modules at enterprise scale

PowerShell Developer Advantages: Your PowerShell module development expertise translates perfectly to Terraform modules:

• Similar project structure and organization principles
• Familiar parameter validation and input/output patterns
• Testing approaches that build on your Pester experience
• Version management strategies that mirror PowerShell Gallery patterns

Module Maturity Achieved:

Advanced Patterns Mastered:

• Module Factories: Dynamic infrastructure generation based on configuration
• Composition Strategies: Building complex systems from simple, tested modules
• Integration Testing: End-to-end validation using real infrastructure components

Coming Next: In Part 7 Terraform CICD With GitHub Actions, our final chapter, we'll bring everything together by implementing comprehensive CI/CD pipelines that automatically test, validate, and deploy your modules and infrastructure using GitHub Actions - creating a complete end-to-end automation workflow.

You now have the skills to build and maintain enterprise-grade infrastructure module libraries Congratulations!

📚 Series Navigation:

• Part 1: Getting Started with Terraform for PowerShell People
• Part 2: Resources, Variables, and State in Terraform
• Part 3: Advanced Terraform and PowerShell Integration
• Part 4: Advanced State Management and Collaboration
• Part 5: Testing Terraform Code ← You are here
• Part 6: Terraform Modules Deep Dive
• Part 7: CI/CD with GitHub Actions (September 9)

The Critical Need for Infrastructure Testing​

With enterprise-grade state management and team collaboration from Part 4 now in place, it's time to address one of the most crucial aspects of professional infrastructure management: comprehensive testing.

As PowerShell developers, you understand the importance of testing - but infrastructure testing takes on even greater significance than application testing. A failed PowerShell script might cause inconvenience; failed infrastructure can cost thousands of dollars and impact business operations. The good news? Terraform v1.6+ introduced a native testing framework that brings testing directly into the Terraform ecosystem, making it as natural as writing the infrastructure code itself.

Why Infrastructure Testing Matters More Than Script Testing​

# PowerShell script failure - usually reversible
function Remove-OldFiles {
    param([string]$Path, [int]$DaysOld = 30)

    Get-ChildItem $Path | Where-Object {
        $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysOld)
    } | Remove-Item -Force
}

# If this fails, we can usually recover files from backup

# Terraform resource creation - has real cost and compliance implications
resource "azurerm_virtual_machine" "example" {
  name                = "production-vm"
  location            = "West US"
  resource_group_name = azurerm_resource_group.example.name
  vm_size             = "Standard_DS3_v2"  # $200+/month if this runs!

  # Network, storage, OS configuration...
}

The key differences:

• Financial Impact: Every resource has a cost
• Security Implications: Misconfigurations can expose data
• Compliance Requirements: Infrastructure must meet regulatory standards
• Dependency Complexity: Infrastructure components are interconnected
• Cleanup Difficulty: Some resources can't be easily deleted

Terraform's Native Testing Framework: The PowerShell Developer's Perspective​

Terraform v1.6+ introduced a game-changing native testing framework that brings testing directly into the Terraform ecosystem. No more external tools, complex setups, or learning new languages - you can now write tests in .tftest.hcl files that integrate seamlessly with your infrastructure code.

PowerShell Pester vs. Terraform Native Testing​

As PowerShell developers familiar with Pester, you'll recognize many concepts in Terraform's native testing:

Your First Terraform Test​

Let's start with a simple storage account module and see how to test it:

# modules/storage-account/main.tf
variable "name" {
  description = "Name of the storage account"
  type        = string

  validation {
    condition     = can(regex("^[a-z0-9]{3,24}$", var.name))
    error_message = "Storage account name must be between 3 and 24 characters and contain only lowercase letters and numbers."
  }
}

variable "resource_group_name" {
  description = "Name of the resource group"
  type        = string
}

variable "location" {
  description = "Azure region for resources"
  type        = string
}

variable "sku" {
  description = "Storage account SKU"
  type        = string
  default     = "Standard_LRS"
}

variable "tags" {
  description = "Tags to apply to resources"
  type        = map(string)
  default     = {}
}

resource "azurerm_storage_account" "this" {
  name                     = var.name
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = split("_", var.sku)[0]
  account_replication_type = split("_", var.sku)[1]

  # Security configurations
  https_traffic_only_enabled         = true
  min_tls_version                    = "TLS1_2"
  allow_nested_items_to_be_public    = false

  blob_properties {
    versioning_enabled = true
    delete_retention_policy {
      days = 7
    }
  }

  tags = var.tags
}

output "storage_account_name" {
  description = "The name of the storage account"
  value       = azurerm_storage_account.this.name
}

output "storage_account_id" {
  description = "The ID of the storage account"
  value       = azurerm_storage_account.this.id
}

output "primary_blob_endpoint" {
  description = "The endpoint URL for blob storage"
  value       = azurerm_storage_account.this.primary_blob_endpoint
}