Terraform plan on PR failing with state drift in Azure DevOps

General Discussion
1

We are configuring an Azure DevOps pipeline to run terraform plan on pull requests. The plan step fails immediately because the remote state in the Genesys Cloud backend contains resources not defined in the current branch. The standard workflow requires a refresh before the plan, but the provider does not seem to support a plan-only mode that ignores existing state differences. How do we force a clean plan against the current branch state without triggering a full apply?

2

Don’t fight the remote state lock. Run a refresh step before plan in your pipeline.

task: TerraformCLI@0
inputs:
command: ‘refresh’
workingDirectory: ‘$(System.DefaultWorkingDirectory)/terraform’
backendServiceArm: ‘genesys-cloud-sa’
environmentServiceNameAzureRM: ‘genesys-cloud-sa’

task: TerraformCLI@0
inputs:
command: ‘plan’
workingDirectory: ‘$(System.DefaultWorkingDirectory)/terraform’
backendServiceArm: ‘genesys-cloud-sa’
environmentServiceNameAzureRM: ‘genesys-cloud-sa’
commandOptions: ‘-input=false -lock=false’


The issue isn't that the vider lacks a plan-only mode. It's that `terraform plan` implicitly runs a refresh against the state file you pointed it at. If that state file has resources your branch doesn't define, the plan shows drift. You can't just ignore it unless you want to delete things you didn't mean to.

Running `terraform refresh` as a separate step updates the local state to match the actual Genesys Cloud environment. Then the subsequent `plan` compares that clean, refreshed state against your current config. It should show zero changes if your code matches reality.

Make sure your Azure DevOps service connection has the right OAuth scopes. The refresh step needs `queue:read` and `user:read` at minimum, depending on what resources you manage. If the refresh fails with a 401, the plan step will never run correctly anyway.

Also check if someone else has the state lock held. Genesys Cloud backends sometimes hold locks longer than expected. Adding `-lock=false` to the plan command bypasses that, but it's a band-aid. Fix the lock source instead.