Review Terraform Catalog Deployment Evidence
Reply CMP Blog - ARTICLE 2 (September 2026)
A first successful Apply can hide the biggest risk in a self-service catalog: the platform team may promote a path that only worked once, under conditions nobody has proved are repeatable.
A business unit asks to roll out a “standard environment” catalog item to several product teams. The pilot gives the platform team two signals: one Azure deployment applied successfully, and another was blocked before Plan because the Deployment was not ready.
The easy answer is: “The module works. Fix the blocked one and open the catalog item.”
The safer answer is: “Not yet. First, prove the deployment path is repeatable.”
A completed Apply tells you something ran. It does not prove the requested resource, module path, runner, state, credentials, permissions, policy gate, provider scope, and execution evidence are fit for self-service.
Completion is not the control point
Self-service provisioning is an operating contract, not just a Terraform run.
The consumer expects a governed route to request a known pattern. The platform team expects the request to use approved code, controlled credentials, policy checks, and reviewable execution evidence. Finance and security teams expect the result to land in the right scope with enough ownership and control context to manage later.
That is why “green” is too thin as a promotion criterion. A catalog item can apply successfully because one experienced operator chose the right values, one runner was already configured, one state container was reachable, or one cloud connection had broader access than the intended self-service route should allow.
A failed or blocked run can be equally useful. A readiness block is not a module defect. A policy block may be the guardrail working. A provider permission error may show the catalog path has not been tested with the access model intended for normal users.
Review the path, not only the run
After a Plan, Apply, failure, or block, the first question should be:
Can we explain enough of what happened to decide whether this catalog item should be promoted, remediated, retested, or held back?
For the rollout request, compare the successful Apply and the blocked deployment against the same evidence model. If both used the same module record, repository path, and intended provider scope, the block may show a setup issue to fix. If they used different paths, credentials, or cloud scopes, the team does not yet have one repeatable pattern. It has separate events that need separate review.
A seven-part evidence review
Use this checklist before treating a Terraform-backed catalog item as ready for wider self-service.
1. Request and module record
Record what was requested: environment type, target provider, required inputs, and expected resource pattern. Then tie the request to the module record and repository path that served it.
Do not use a successful run from one Terraform path as evidence for another catalog route.
2. Runner status
The runner is part of the evidence chain. Review which customer-owned runner handled the operation, whether it was ready before Plan or Apply, and whether it reported status and evidence.
If a deployment was blocked before execution because the runner was not ready, classify it as readiness evidence, not a Terraform failure.
3. Protected state
Terraform state proves continuity between runs. Check where state is configured, whether access is appropriate, and whether the deployment path can read, write, and lease state as required.
In Reply CMP provisioning, every Deployment needs one customer-owned runner and one protected Azure Blob state location. Plan and Apply are blocked until both runner and state are ready, which makes setup readiness visible in the review.
4. Credential purpose
Do not reduce credentials to “access worked.” Separate the dispatch credential from cloud connections.
The dispatch credential starts the configured Azure DevOps pipeline or GitHub workflow. Cloud connections linked to the Deployment are used by Terraform providers and state. That distinction answers different control questions: what started the workflow, what Terraform could manage, and which connection was used for state.
5. Permissions and policy gate
Policy and permissions are part of repeatability. Check whether intended requesters and reviewers have the Reply CMP permissions needed for modules, credentials, and Deployments. Check whether the cloud connection has the provider permissions needed for target resources and state.
Then review the policy result. A deployment that only works for administrators may not be ready for the users it is meant to serve.
6. Provider scope
A common review model does not make Azure, AWS, and GCP interchangeable.
Confirm the provider target explicitly. Module inputs, provider aliases, permissions, state expectations, and operating assumptions can differ by provider. Evidence from an Azure deployment should not be used as proof that the same catalog path is ready for AWS or GCP unless those provider-specific assumptions have been reviewed.
7. Execution evidence
Finally, review the run evidence: Plan status, Apply status, failure message, runner-reported status, policy result, and troubleshooting classification.
The useful record is not “success” or “failed.” It should read like a decision trail:
Standard environment requested; module path confirmed; runner ready; protected state configured; dispatch credential started the workflow; provider and state connections confirmed; policy passed; Apply evidence available; promote with normal controls.
Or:
Standard environment requested; module path confirmed; Plan blocked because runner and state were not ready; no Terraform evidence available; remediate Deployment setup and rerun before promotion.
Where Reply CMP fits
Reply CMP supports governed provisioning through policy-gated resources, Terraform-backed modules, customer-owned runners, and protected state configuration.
The documented provisioning setup uses a GitHub or Azure DevOps repository for runner files, an Azure subscription with an existing Storage account and private Blob container for Terraform state, an active read-write Azure Connection that can manage target resources and access state blobs, and Reply CMP permissions to manage provisioning modules, credentials, and Deployments.
In each Deployment, the Runner & state view shows the runner, callback trust, and the Azure Connection used for state. Reply CMP blocks Plan and Apply until runner and state are ready. It also separates credential purposes: dispatch credentials start the configured pipeline or workflow, while cloud connections linked to the Deployment are used by Terraform providers and state.
That does not automate judgement. It gives reviewers the control points they need to decide whether a catalog route is repeatable enough for self-service.
Decide by evidence class
Evidence still needs interpretation. A policy can be too strict or too loose. A role assignment can be missing. A module can work in one subscription and fail in another because provider scope changed. The habit is to classify before acting.
Promote for self-service
Evidence pattern
Request, module path, runner, state, credentials, permissions, policy, provider scope, and execution evidence are consistent.
Next action
Publish or expand availability with normal review controls.
Remediate and rerun
Evidence pattern
Module path is valid, but runner, state, inputs, or execution evidence are incomplete.
Next action
Fix setup or inputs, then run Plan or Apply again.
Correct permission or policy
Evidence pattern
Evidence points to missing platform permission, cloud role, state access, or policy mismatch.
Next action
Adjust access or policy, then retest with intended users.
Hold the item
Evidence pattern
Provider scope is unclear, credentials are wrong-purpose or too broad, or reviewers cannot prove what ran.
Next action
Keep unavailable until the control record is reviewable.
Self-service catalogs scale when teams can trust the route, not just the last run. A successful Apply is evidence. It is not the whole review.