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