A junior engineer accidentally deleted a project. Later, they realize they need to restore it. What must be true for project deletion to be reversible?
Trap 1: The user must have the Owner role at the organization level
To delete a project, the caller needs the resourcemanager.projects.delete permission, which is granted by the Project Owner or Editor role, not necessarily by the Organization Owner. An organization-level owner does have this permission, but it is not a prerequisite; a user with only project-level Owner can delete that project directly. Thus, requiring an organization-level Owner is incorrect; the relevant authority is at the project scope.
Trap 2: The project must be within the first 7 days of creation
The recovery window for a deleted Google Cloud project is 30 days, not 7 days, and the project's creation date has no bearing on its deletability. Any project, regardless of how recently it was created, can be deleted and later restored by calling the undelete operation within the 30-day grace period. The 7-day figure is a common point of confusion; it is not part of the project deletion or recovery process.
Trap 3: The project must not have any active resources
A project can be deleted even while it contains active resources such as Compute Engine instances, Cloud Storage buckets, or GKE clusters. Deleting a project schedules all of its resources for permanent deletion along with the project, so the presence of active resources does not block deletion. The only project-level condition that must be satisfied is that billing is disabled; the resource inventory itself is irrelevant to the deletion request.
- A
The user must have the Owner role at the organization level
Why wrong: To delete a project, the caller needs the resourcemanager.projects.delete permission, which is granted by the Project Owner or Editor role, not necessarily by the Organization Owner. An organization-level owner does have this permission, but it is not a prerequisite; a user with only project-level Owner can delete that project directly. Thus, requiring an organization-level Owner is incorrect; the relevant authority is at the project scope.
- B
The billing account must have been disabled before deletion
For a project to be deleted, its billing account must first be disabled or detached; the Google Cloud API refuses deletion when a billing account is actively attached to the project. The console automation performs this step during the deletion flow, but if you are using the resourcemanager.projects.delete method, you must ensure billing is suspended beforehand. After deletion, the project remains in a recoverable state for 30 days, after which it is permanently removed.
- C
The project must be within the first 7 days of creation
Why wrong: The recovery window for a deleted Google Cloud project is 30 days, not 7 days, and the project's creation date has no bearing on its deletability. Any project, regardless of how recently it was created, can be deleted and later restored by calling the undelete operation within the 30-day grace period. The 7-day figure is a common point of confusion; it is not part of the project deletion or recovery process.
- D
The project must not have any active resources
Why wrong: A project can be deleted even while it contains active resources such as Compute Engine instances, Cloud Storage buckets, or GKE clusters. Deleting a project schedules all of its resources for permanent deletion along with the project, so the presence of active resources does not block deletion. The only project-level condition that must be satisfied is that billing is disabled; the resource inventory itself is irrelevant to the deletion request.