StackScopes
Problem
Infrastructure review usually begins with a Terraform plan, CloudFormation change set, or configuration diff. Those artifacts explain what a deployment system intends to create, update, replace, or delete. They do not automatically explain which workloads depend on the affected resources, which teams own those workloads, whether the proposed action crosses a shared control, or how quickly customer-facing behavior could change.
A one-line security-group edit can interrupt a scheduled worker in another account. Replacing a subnet can affect interface endpoints used for secret retrieval. Changing a KMS policy can block a recovery process that runs rarely and is absent from recent telemetry. The syntax of the edit may be small while its operational context is broad.
Code and cloud state can also disagree. Imported resources, console changes, remote state, cross-repository outputs, and service defaults create drift between declared and actual topology. A review limited to source code misses live dependents. A review limited to inventory misses the exact proposed transition.
Teams need a way to bring these views together without replacing engineering judgment with an opaque risk score.
What We Built
StackScopes Change Impact Preflight normalizes a proposed infrastructure change, resolves it against the current cloud digital twin, and evaluates relevant dependency paths before deployment. It treats the proposal, live topology, relationship evidence, temporal state, ownership, and recovery constraints as parts of one review context.
The system recognizes additions, in-place updates, replacements, and deletions. A new resource becomes a proposed graph node. A deleted resource remains visible as an existing node marked for removal. Replacement is modeled as a transition between old and proposed identities rather than flattened into unrelated create-and-delete events.
Impact is grouped into operationally meaningful categories:
- Directly changed resources
- First-order dependent workloads
- Transitive application or platform paths
- Shared control dependencies
- Security and identity paths
- Potential customer or tenant-facing capabilities
- Deployment and recovery dependencies
The output is explainable. A reviewer can inspect which changed attribute initiated a finding, which graph edges were followed, where each relationship came from, when evidence was observed, and which assumptions remain unresolved.
Change Impact Preflight does not automatically guarantee a safe deployment or independently approve production action. It organizes evidence for accountable human review.
How It Works
Normalize the proposal
StackScopes ingests the useful structure of a Terraform plan, CloudFormation change set, or another approved change description. It captures resource address, type, account, Region, proposed action, changed fields, before-and-after values, source revision, and unknown values. Sensitive values remain masked and unnecessary payload content is excluded.
Unknowns stay explicit. If a value will resolve only during deployment, the analysis identifies which conclusions depend on it instead of inventing a result.
Resolve live identity
The system maps planned objects to live resources using provider identifiers, ARNs, state bindings, stack metadata, account, Region, tags, and deployment history. Name-only matches are treated cautiously because names can repeat across environments and replacements can reuse them.
If several live candidates match, the ambiguity is visible. For critical work, a scoped read-only refresh can update the changed resource and its surrounding topology before review.
Select semantic traversal rules
Different changes need different graph questions. A route change follows subnet associations, egress paths, endpoints, and workloads. A role-policy change follows identities, required actions, resource policies, and recovery access. A queue change follows producers, consumers, dead-letter paths, retention, and alarms.
StackScopes traverses typed relationships rather than treating every reachable node as equally affected. Cycles are bounded, repeated nodes are not counted as distinct impact, and potential paths remain separate from observed paths.
Evaluate context
The preflight considers environment, criticality, shared-resource status, failure-domain independence, evidence confidence, freshness, time-to-impact, detectability, rollback feasibility, and recovery complexity. Severity and confidence remain separate. A low-confidence path to a critical control deserves investigation; a high-confidence test-resource edit may remain low priority.
Preserve a decision record
The analyzed plan digest, topology baseline, findings, reviewer decisions, and validation conditions can be retained together. If the plan changes before apply, the preflight should run again. After deployment, discovered state can be compared with both baseline and proposal.
Output and Evidence
The primary output is a review summary that answers:
- What is changing?
- Which live resources were resolved?
- Which capabilities or workloads may be affected?
- Which paths are direct, transitive, shared, or recovery-related?
- What evidence supports each path?
- How fresh is that evidence?
- What is unknown or contradictory?
- Which rollout, approval, and verification controls are relevant?
A finding might state that removal of a security-group rule affects a shared group attached to two production workloads, with one matching connection observed during a defined telemetry window. The evidence panel can show the planned attribute, group attachment, candidate network path, observation timestamp, and ownership source.
The system does not claim that an observed connection captures every low-frequency path, nor that an allowed policy proves successful use. Evidence type and limitations remain visible.
Outputs can also include suggested controls: stage a replacement before removal, run a targeted connectivity check, extend observation through a scheduled workload, confirm a role with the owning team, or pause before deleting an old resource. These are decision aids, not autonomous commands.
Why It Matters
Cloud changes fail at the boundaries between code, live state, and organizational context. Change Impact Preflight gives reviewers a common view of all three.
Platform teams can identify shared controls before a local pull request becomes a cross-team incident. SREs can define verification around predicted failure paths. Security teams can tighten access while seeing which production identities rely on it. Engineering leaders can require evidence-based review for destructive or broadly shared changes without applying the same ceremony to every update.
The result is not risk-free deployment. It is a more deliberate decision: known dependents are visible, uncertainty is named, rollback assumptions are challenged, and approval is tied to the proposal that was actually analyzed.
Preflight also creates a feedback loop. After deployment, the team can compare predicted relationships with the resulting topology and verification evidence. A missed consumer can improve an inference rule; a false positive can reveal stale configuration or an overly broad traversal. This turns change review into a source of better dependency knowledge rather than a one-time gate.
Operational Guardrails
- Discovery is designed around read-only access.
- Sensitive plan values are minimized and masked.
- Findings expose source, confidence, and observation time.
- Partial collection is displayed as a coverage gap.
- Unknown plan values are never silently guessed.
- A changed plan requires renewed analysis.
- Production-impacting actions remain human-approved.
- Optional remediation uses a separate, narrowly scoped execution boundary.
- Post-deployment verification compares actual state with the reviewed proposal.
FAQ
Is Change Impact Preflight the same as a Terraform plan?
No. A plan describes proposed infrastructure actions. Preflight connects those actions to live topology, dependencies, owners, customer-facing capabilities, and recovery constraints.
Can StackScopes prove that a change is safe?
No model can prove all application behavior or external conditions. StackScopes presents known paths, evidence, assumptions, and gaps so accountable reviewers can make a better-informed decision.
What happens when topology data is stale?
Freshness is shown in the finding. A scoped refresh can update affected resources, and incomplete scopes reduce confidence rather than being presented as complete.
Does StackScopes apply the change?
Preflight is an analysis workflow. Any controlled remediation or deployment action requires a separate authorization path, policy boundaries, and human approval.
Related StackScopes links
StackScopes keeps operational evidence, timestamps, assumptions, and confidence visible. Production-impacting recovery remains subject to policy and human approval.