Use this article to diagnose a failed or partial DigiTrade deployment. The recovery actions described here apply outside the normal deployment and destruction flows. These recovery actions are operationally sensitive, so use them only with a clear reason.
Diagnose by layer
A deployment fails in a specific layer, so matching the symptom to the layer helps narrow the cause.
For an early provisioning failure, inspect the project and enabled APIs because the account may lack permission to create a project, link billing, or enable a service.
For an instance with no outbound internet, inspect networking, specifically Cloud NAT.
When DigiTrade services do not start, inspect the compute instance and its startup script.
When public traffic never reaches a service, inspect the load balancer and network endpoint groups.
When traffic is blocked or marked unhealthy, inspect the health checks and Cloud Armor policies.
The load balancer routes by service health rather than host availability. A health-check failure can resemble an application outage while the compute instance continues running.
Delete the GCP project
A normal terraform destroy removes managed resources but leaves the GCP project container in place. Delete the project directly with the Google Cloud SDK when the project container must also be removed.
Find the project and then delete it.
gcloud projects list
gcloud projects delete <project-id>Confirm the deletion when prompted.
GCP marks the project for deletion and enters a pending-deletion period before final removal. Project deletion is broader and more destructive than terraform destroy because it affects the entire project container. Be certain of the project ID before running the deletion command.
Detach a resource from Terraform state
Removing a resource from state tells Terraform to stop tracking it without deleting the real GCP resource.
Remove the resource from Terraform state.
terraform state rm <resource-address>
For example, stop tracking the project resource with the following command.
terraform state rm google_project.project
Use state removal when state no longer matches reality or when moving a resource to a different Terraform configuration. When moving a resource, remove it from the source state and import it into the destination.
If the matching configuration block remains after detachment, a later plan or apply tries to recreate the resource and can duplicate resources. Manual state changes create drift between the code, state file, and real environment, so keep them deliberate and well documented.
Related