Manage resources and drift

A discovered resource is something ScrinCloud can see in an approved read-only scope. A managed resource has a deliberate ScrinCloud management binding that can connect cloud identity, canvas context, Terraform address, observed state, and audit history.

Management should always be intentional. Discovery alone does not adopt a resource, and drift alone does not authorize changing it.

Typical time

20–35 minutes

You need

Reviewed discovery evidence

Outcome

A governed next decision

Understand the key terms

• Discovered resource: provider metadata found during an approved run.
• Managed resource: a resource deliberately linked to ScrinCloud management context.
• Desired state: the approved configuration your design or Terraform revision intends.
• Observed state: sanitized configuration read from the provider.
• Drift: a meaningful difference between desired and observed state.
• Reconciliation: the governed decision to accept, restore, or otherwise resolve that difference.

Drift can come from an approved emergency change, a manual console update, automation outside ScrinCloud, or desired configuration that is no longer current.

Before you begin

Confirm:

• the correct project and workspace;
• a completed, reviewed discovery run;
• the resource owner and environment;
• the provider resource identity;
• whether Terraform already owns the resource;
• whether an active incident or approved change explains the difference; and
• who must review a reconciliation or apply.

Do not adopt a resource merely because it appeared in discovery.

Step 1: Open Discovery Operations in the correct scope

1. Open Discovery Operations.
2. Select the project.
3. Select the cloud account.
4. Select the region.
5. Choose the intended workspace or Project-level scope.
6. Review the summary cards:
   • Managed Resources;
   • Drift Reports;
   • Reconciliation;
   • Unsupported Resources; and
   • Activity & Audit.
7. Confirm the counts and recommended next actions belong to the intended scope.

Manage 1 of 7 · Screenshot placeholder

Confirm Discovery Operations scope

Show project, account, region, workspace, and the five summary cards in Discovery Operations.

Future capture briefUse synthetic project, connection, region, and workspace labels. Hide provider account IDs, tenant details, and real operational counts.

Step 2: Review the Managed Resources list

Open Managed Resources and read each row:

• Resource name and Resource type;
• provider and region;
• linked canvas node, or Not linked;
• Terraform address, or Not mapped;
• management state;
• sync status; and
• last observed time.

Use the row actions to:

• View resource;
• Open on canvas;
• View Terraform mapping;
• Refresh resource; or
• View drift.

A missing canvas node or Terraform mapping is important context. Do not assume that a row is fully governed only because its management state says managed.

Manage 2 of 7 · Screenshot placeholder

Review management and sync state

Show Managed Resources with canvas link, Terraform mapping, management state, sync status, last observed time, and row actions.

Future capture briefUse synthetic resource names and masked provider IDs. Include one fully mapped row and one safe Not linked or Not mapped example.

Step 3: Open a managed-resource detail

Choose View resource and confirm:

1. the binding ID and provider resource identity;
2. provider, region, and resource type;
3. canvas node link;
4. Terraform address;
5. management and sync state;
6. last observed or synchronized time;
7. Desired and observed state guidance;
8. relationships; and
9. sync and audit history.

The operations page shows sanitized operational facts. Raw provider payloads are intentionally not displayed.

If ownership, Terraform address, or canvas context is wrong, stop before refreshing or preparing any reconciliation.

Manage 3 of 7 · Screenshot placeholder

Verify the managed-resource binding

Show a managed-resource detail drawer with safe identity, canvas link, Terraform mapping, sync state, observed time, relationships, and audit guidance.

Future capture briefUse a synthetic binding and mask cloud identifiers. Never show raw observed payloads, credentials, state files, customer values, or internal storage paths.

Step 4: Refresh observed state carefully

Use Refresh resource when you need a current provider observation:

1. Confirm no incident or maintenance window makes the current state temporarily misleading.
2. Confirm the selected resource and provider scope.
3. Choose Refresh resource.
4. Wait for the refresh action to finish.
5. Review the new sync status and last observed time.
6. Open View drift if a difference is reported.

Refreshing reads provider state and updates ScrinCloud evidence. It is not a Terraform apply and should not be described as one.

Manage 4 of 7 · Screenshot placeholder

Refresh sanitized observed state

Show Refresh resource in progress followed by updated sync status and last observed time.

Future capture briefUse a synthetic managed resource and safe timestamps. Do not capture raw provider data, cloud account IDs, or background service details.

Step 5: Read a Drift Report

Open Drift Reports. For each active report, review:

• drift ID and managed-resource binding;
• resource type;
• severity;
• drift status;
• number of changed fields;
• detection time; and
• the recommendation Review and decide.

Choose Review drift to compare sanitized differences:

• field or property name;
• desired value;
• observed cloud value; and
• safe context about the difference.

Check for an approved change or incident before deciding what the desired state should become.

Manage 5 of 7 · Screenshot placeholder

Compare desired and observed state

Show Drift Reports and a detail drawer with severity, status, changed fields, Desired value, and Observed cloud value.

Future capture briefUse synthetic non-secret configuration values. Mask resource and binding IDs and exclude raw provider payloads or customer operational data.

Step 6: Choose the correct drift response

The available actions can include:

• Accept cloud change: prepare a reconciliation preview that proposes updating governed desired context to match the reviewed cloud change.
• Ignore with reason: record why no current change should be made.
• Open on canvas: locate the resource in its design context.

Before choosing:

1. confirm who made the cloud change;
2. confirm whether it was approved;
3. assess service, security, cost, and policy impact;
4. compare desired and observed values;
5. decide whether desired state should change or the live resource should eventually be restored; and
6. record a clear business reason.

Accept cloud change creates a proposal for review. It does not immediately change Terraform or apply to the provider.

Manage 6 of 7 · Screenshot placeholder

Choose a governed drift response

Show Review drift actions with Accept cloud change, Ignore with reason, and Open on canvas.

Future capture briefUse a medium-severity synthetic example and a short safe reason. Do not show a real incident, user identity, customer resource, or approval record.

Step 7: Review the reconciliation proposal

Open Reconciliation after preparing an accepted-cloud-change preview.

1. Locate the proposal.
2. Review the resource and proposed action.
3. Confirm the status is Ready for review.
4. Review the risk level.
5. Confirm the required gates:
   • approval required for apply;
   • validation required;
   • plan required;
   • policy review required; and
   • cost review where relevant.
6. Open the proposal or diff.
7. Do not continue to an apply until the normal Terraform review and approval path is complete.

The proposal is evidence and intent, not a live infrastructure mutation.

Manage 7 of 7 · Screenshot placeholder

Review reconciliation gates

Show a Ready for review reconciliation row with risk, approval, validation, plan, policy, and cost requirements.

Future capture briefUse a synthetic proposal and masked identifiers. Keep all review gates visible and do not show real plan output, approver identity, or provider data.

Check your result

The workflow has a safe outcome when:

• project, account, region, and workspace scope are correct;
• the managed-resource binding, canvas link, and Terraform mapping are understood;
• observed state was refreshed only when appropriate;
• every active drift field has been reviewed;
• an approved change or incident has been checked;
• the decision and reason are recorded; and
• any reconciliation remains behind validation, plan, policy, cost, approval, and apply controls.

Common blockers

No managed resources appear

Confirm you selected the correct project, account, region, and workspace. Discovery alone does not create a management binding; review the supported results and approved adoption workflow.

The resource says Not linked or Not mapped

The canvas node or Terraform address is missing. Resolve ownership and mapping before treating the resource as fully governed.

Refresh resource fails

Test the provider connection, check its allowed region and read permissions, then retry. Do not broaden access until the required read capability is identified and approved.

A drift report has no field-level differences

The report may still contain a safe status, severity, or reason. Record the limited evidence and do not guess which field changed.

Accept cloud change is unavailable

The report may no longer be active, your role may not permit the action, or the resource may lack required management context. Open the detail and follow the displayed reason.

A difference was caused by an emergency change

Confirm the incident and approved owner. Decide through normal review whether to preserve the cloud change in desired state or restore the approved configuration later.

Someone asks to “clear” drift immediately

Do not overwrite live infrastructure or accept a cloud change only to remove the indicator. Review business, security, cost, and operational impact first.

Where to go next

Use the normal governed path for any resulting Terraform work:

1. review or update the architecture;
2. validate the saved design;
3. prepare a Terraform revision;
4. run policy and plan checks;
5. obtain required approval; and
6. apply only through the approved delivery workflow.

Continue with Review plans safely.