Detect Cloud Storage Deletions

Build an email alert for Cloud Storage bucket deletions using audit logs.

Introduction

30 Second Summary

A single deletion can remove shared files in seconds. Without a warning, the loss can sit unnoticed until someone needs the missing data.

In this project, you will build a Google Cloud alert that detects when someone deletes a Cloud Storage bucket. You will turn the recorded event into a Cloud Monitoring incident with an email notification in your inbox.

What You'll Build

You'll watch a harmless test deletion travel from Logs Explorer to an open Cloud Monitoring incident with an email that links back to the exact audit event.

By the end of this project, you'll have:

A repeatable way to find a bucket deletion inside its Admin Activity audit log.
An enabled log-based alerting policy that converts future deletion events into actionable incidents.
A proven event-to-email workflow that traces an open incident back to its exact audit entry.
Secret Mission: Narrow the alert to match deletions performed by your temporary playground user.

Are there any prerequisites?

Access requires an active KodeKloud subscription. You also need a web browser, a phone for MFA, and a personal email inbox.

Before We Start

Before any console work, lock in the security signal behind this project. You will monitor Cloud Storage Admin Activity audit events that use the storage.buckets.delete permission because an unauthorized bucket deletion can cause data loss.

Set Up the Playground and Notification Channel

A deletion alert only helps when every Google Cloud Console page points to the intended temporary project. KodeKloud does not document whether every playground grants the alerting permissions this workflow needs.

The KodeKloud GCP Playground provides temporary credentials that are valid for three hours. A private browser window keeps those credentials separate from your personal Google Cloud account.

You will confirm the dedicated project in Cloud Storage. You will repeat that check in Cloud Logging.

You will finish by saving an email notification channel in Cloud Monitoring. This capability check happens before you create any test events.

In this step, get ready to:

Start the temporary playground session in a private browser window.
Confirm the dedicated project across the required console pages.
Save an email notification channel for future incident delivery.

Start the temporary playground session

Temporary credentials isolate this lab from your personal Google Cloud access. KodeKloud asks for a phone number to enable MFA after you sign in.

Launch an incognito or private browser window.
Sign in to your KodeKloud account inside that window.
Start the GCP Playground from the KodeKloud dashboard.
Use the issued temporary credentials to sign in to Google Cloud Console.
Enter your phone number when the MFA prompt requests it.

You are through the first gate. The console now shows your temporary Google Cloud session inside the private window.

Confirm the project across console pages

The project selector controls which project's resources or logs each page shows. A matching value across the console keeps the future audit trail in the correct sandbox.

Click the project selector in the console's top bar.
Select the dedicated project whose name starts with clgcporg.
Record the full selected project name here: your clgcporg project name.
Use the console search bar to open Cloud Storage.
Select Buckets from the Cloud Storage navigation.
Confirm the project selector shows your clgcporg project name.
Use the console search bar to open Logs Explorer in a second browser tab.
Confirm the project selector on Logs Explorer shows your clgcporg project name.

Both pages now show your clgcporg project name. This proves that future storage events and log searches stay inside the same temporary project.

Save the email notification channel

An email notification channel tells Cloud Monitoring where to send an incident notice. Using a personal inbox gives the later incident a destination you can verify.

Stop at the sandbox gate

A request to attach billing can look like a normal setup step. In this managed sandbox, it means you should stop.

Stop if the console asks you to attach personal billing.
Stop if the console reports a permission problem.
Stop if Edit notification channels is unavailable.
Leave the managed project's IAM configuration unchanged.
Leave the managed project's billing configuration unchanged.

Use the console search bar to open the Monitoring Alerting page in a third browser tab.
Confirm the project selector shows your clgcporg project name.
Click Edit notification channels.
Click Add new in the Email section.
Enter your personal email address.
Enter Learning alerts as the description.
Click Save.

How Is the Channel Tested?

Cloud Monitoring does not provide a test option for notification channels.

A matching alerting policy later proves delivery. Cloud Monitoring opens an incident before sending the notification.

Before you check, where do you expect the saved address to appear?

Return to the Monitoring Alerting page.
Select Edit notification channels.
Locate the Email section.
Confirm your personal email address appears in the section.
Confirm the channel's description is Learning alerts.

You will see your personal email address in the Email section. Its description is Learning alerts.

That capability gate is cleared. Your temporary project now has the destination needed for future incident notifications.

Your playground session is active with the correct project selected across all three console pages. Next, you will create a harmless bucket-deletion event so you can find its audit record.

Generate and Find a Deletion Audit Log

Your saved email channel gives Cloud Monitoring a destination for future notifications. Now you need a real deletion event to trace.

Cloud Storage records bucket deletions in Admin Activity audit logs. This step tests whether that record alone produces an incident or email.

In this step, get ready to:

Create an empty Standard bucket in us-central1.
Delete the bucket to generate an Admin Activity event.
Narrow Logs Explorer to the deletion event and inspect the recorded actor.

Create the baseline bucket

An empty baseline bucket gives you a harmless resource for generating a real deletion event. Cloud Storage bucket names are shared globally.

Six random digits make your bucket name more likely to be unique. The bucket contains no files.

Switch back to the Cloud Storage Buckets page from earlier.
Click Create.

You will see the bucket creation form for the temporary project whose name starts with clgcporg.

Enter nw-alert-baseline-<six-random-digits> in the bucket name field.
Select us-central1 for the bucket location.

The location summary now shows us-central1. The remaining settings already use safe defaults for this empty test resource.

Confirm the storage class shows Standard.
Click Create.

You will see nw-alert-baseline-<six-random-digits> on the bucket list.

Good work. Your empty baseline bucket is ready to produce a safe deletion event.

Bucket name unavailable?

Replace the six random digits in nw-alert-baseline-<six-random-digits> with a new set.
Keep the name lowercase.
Use only lowercase letters, numbers, or hyphens.

Help me fix the rejected Cloud Storage bucket name.

Delete the empty bucket

Deleting a resource can feel risky. This bucket is empty and exists only to generate the audit event.

Select the checkbox beside nw-alert-baseline-<six-random-digits>.
Click Delete.

The confirmation overlay identifies the empty bucket that is about to be removed.

Complete the requested confirmation for deleting the bucket and its contents.
Click Delete again.

The bucket disappears from the list. The deletion action has now occurred inside your temporary project.

Find and narrow the audit log

Logs Explorer lets you search the records produced by Google Cloud services. You will begin with all Admin Activity logs before narrowing the results using evidence from the live deletion entry.

Switch back to the Logging Logs Explorer page from earlier.
Enter this Admin Activity query in the query editor:

log_id("cloudaudit.googleapis.com/activity")

What does this query do?

The log_id("cloudaudit.googleapis.com/activity") query returns activity audit logs. This wide first pass gives you the live evidence needed to build a precise filter.

Audit-log delivery can take a few minutes. A short delay here means the deletion record is still reaching Logs Explorer.

Click Run query.

You will see recent Admin Activity entries. The bucket deletion appears as a Cloud Storage entry whose service is storage.googleapis.com.

Deletion entry still missing?

Wait a few minutes for the audit event to arrive.
Click Run query again.
Confirm the selected project still starts with clgcporg.

Help me find my Cloud Storage deletion event in Logs Explorer.

Expand the newest Cloud Storage entry.
Click the storage.googleapis.com value.
Select Show matching entries.

Logs Explorer updates the query and reloads the results. Every remaining entry now matches the Cloud Storage service.

Expand the newest result.
Click the storage.buckets.delete permission value.
Select Show matching entries again.

The query narrows to Cloud Storage bucket deletions. Your baseline event remains in the results.

Expand the newest deletion result.
Expand authenticationInfo.
Find the temporary user's email beside principalEmail.

The expanded event shows storage.googleapis.com as the serviceName. Its authorizationInfo section shows storage.buckets.delete as the required permission.

Why is the deletion still recorded?

Admin Activity audit logs are enabled by default. Google Cloud stores them in the project's _Required log bucket.

Deleting the Cloud Storage bucket does not remove its audit trail. That retained record lets an operator investigate who performed the action.

Before you check the response surfaces, make a mental prediction about whether this recorded deletion has opened an incident or sent an email.

Switch back to the Monitoring Alerting page from earlier.
Check the page for an open incident associated with the baseline bucket deletion.
Check your personal inbox for a deletion alert email.

You will find no incident and no alert email. The audit event exists as a passive record.

This gap is intentional

Cloud Logging recorded the destructive action successfully. No alerting policy exists to watch that record and start a response.

Switch back to Logs Explorer from earlier.
Expand the newest bucket-deletion result.

You will see the narrowed Admin Activity event with storage.googleapis.com, storage.buckets.delete, and the temporary user's principalEmail.

Your deletion now has a focused audit trail that identifies the service, permission, and actor. Next up, you will turn this passive evidence into an active email alert.

Create the Email Alert

Your baseline bucket deletion is visible in Logs Explorer. The Admin Activity audit event proves that Google Cloud recorded the destructive action.

No service is watching that event yet. This leaves the deletion disconnected from a response workflow.

In this step, you'll convert the live query into a log-based alerting policy. Cloud Monitoring can then open an incident for each future match. Your saved email notification channel carries the alert to your inbox.

In this step, get ready to:

Create an alerting policy from the live deletion query.
Configure the policy's response settings.
Verify the policy is enabled in Monitoring.

Start from the live deletion filter

The current filter already isolates the Cloud Storage deletion event you care about. Reusing that evidence keeps the alert focused on the proven audit signal.

Switch back to the Logs Explorer page from earlier.
Click Run query.
Open Actions in the Query results toolbar.
Select Create log alert.

You'll see the alert policy form populated with your narrowed bucket-deletion filter.

How Does a Log-Based Alert Work?

The policy watches for new log entries that match its filter. A match opens an incident in Cloud Monitoring.

The selected notification channel sends that incident to your email address. This turns a stored audit event into an active response signal.

Configure the response details

A policy name helps responders identify the affected action. Responder guidance gives them a clear first question during an investigation.

Enter Cloud Storage bucket deletion in the Alert Policy Name field.
Enter confirm who deleted the bucket and whether the change was authorized as the responder guidance.
Click Preview logs.

You should see the baseline deletion from earlier in the preview. This confirms that the policy's filter still matches the event you used to build it.

No Logs in the Preview?

An empty preview usually means that part of the live filter was removed.

Confirm the query still includes log_id("cloudaudit.googleapis.com/activity").
Confirm the query still includes storage.googleapis.com.
Confirm the query still includes storage.buckets.delete.
Run Preview logs again.

Help me restore the bucket-deletion filter in Logs Explorer.

Finish the alert configuration

The notification interval controls how frequently repeated matches can send notifications. The autoclose duration closes an inactive incident after the selected period.

Select 5 min as the minimum time between notifications.
Set the incident autoclose duration to 30 min.

The form should now show a five-minute notification interval. It should also show a thirty-minute incident autoclose duration.

Select the saved Email channel with the description Learning alerts.
Click Save.

Can't Save the Policy?

A permission or billing message means the temporary project lacks the required sandbox capability.

Stop without changing IAM or billing.
Record the message as a KodeKloud sandbox limitation.
End the lab safely.

Help me understand whether this message is a sandbox permission or billing limitation.

That's the key detection layer in place. Your temporary project now has an enabled policy ready to evaluate future bucket deletions.

Before you check the policies list, do you expect your new alert to appear as enabled?

Return to the Logs Explorer page from earlier.
Open Actions.
Select Manage log alerts.

You'll see Cloud Storage bucket deletion listed on the Monitoring Policies page. Its Enabled toggle is on.

Your email alert is configured. Next, you'll trigger a fresh deletion event to prove that the policy opens an incident and delivers a notification.

Trigger and Investigate the Incident

Your log-based alerting policy is enabled in Cloud Monitoring. It is ready to watch the Cloud Storage signal you isolated earlier.

A saved policy remains unproven until a fresh matching event exercises it. In this step, you will trigger that event and trace the resulting incident back to its audit log.

In this step, get ready to:

Create a second empty Standard bucket in us-central1.
Delete the second bucket after the policy is active.
Investigate the incident from its email notification to the matching audit log.

Create a fresh trigger bucket

A new bucket gives the policy a clean post-activation event. A different name from the baseline bucket makes the trigger easy to identify during the investigation.

Switch back to the Cloud Storage Buckets page from earlier.
Click Create.

You'll see the bucket creation form for the selected temporary project.

Enter nw-alert-trigger-<six-random-digits> as the globally unique lowercase bucket name.
Select us-central1 as the bucket location.

The form now identifies your trigger bucket in the permitted sandbox region.

Retain Standard storage.
Retain the remaining safe defaults.

The form now describes an empty Standard bucket in us-central1.

Click Create.

Good, your fresh trigger bucket is now visible on the Buckets page.

Bucket name unavailable?

Replace the six random digits with a different six-digit sequence.
Check that every letter in the bucket name is lowercase.
Check that the bucket name only uses lowercase letters, numbers, or dashes.

Help me choose a valid unique trigger bucket name.

Delete the trigger bucket

Deleting this bucket writes a fresh Admin Activity audit log. The enabled policy can now evaluate the event because the deletion happens after the policy became active.

Select the checkbox beside nw-alert-trigger-<six-random-digits>.
Click Delete.

The deletion confirmation overlay opens for your trigger bucket.

Confirm that the empty test bucket and its contents can be deleted.

Before the final confirmation, pause on whether the active policy should treat this deletion differently from the baseline event.

Click Delete again.

You'll return to the bucket list. nw-alert-trigger-<six-random-digits> is no longer listed.

Good, your fresh bucket-deletion trigger is now live.

Verify and investigate the incident

The incident proves Cloud Monitoring evaluated the fresh log entry. The email proves your saved notification channel delivered the signal outside the console.

Logs Explorer provides the evidence behind the alert. It lets you connect the incident to the exact deletion event.

This final signal can take a few minutes while Cloud Monitoring evaluates the new log. A short delay is expected.

Before you check, pause on where you expect this one deletion to appear across your response path.

Wait a few minutes.
Switch back to the Monitoring Alerting page from earlier.
Refresh the Alerting page.
Check the inbox for your saved personal email address.

You'll see an open Cloud Storage bucket deletion incident on the Alerting page. Your inbox receives an email notification for the same incident.

You have now proven the full response path from fresh deletion to open incident to email notification.

Still waiting for the incident?

Wait a few more minutes.
Refresh the Alerting page.
Refresh your email inbox.
Switch back to Logs Explorer.
Open Actions.
Select Manage log alerts.
Confirm that Cloud Storage bucket deletion remains enabled.

Help me troubleshoot the missing incident or email notification.

Open the email notification.
Click View incident.
Review the incident's Logs pane.
Click View in Logs Explorer.
Expand the newest matching entry.

You'll see an Admin Activity entry for the deletion of nw-alert-trigger-<six-random-digits>. The entry comes from storage.googleapis.com.

Inside authorizationInfo, the permission value is storage.buckets.delete. The principal email identifies the temporary KodeKloud user.

Because this is Admin Activity, the audit entry remains in _Required. The incident now leads directly back to the evidence that triggered it.

Secret mission

Scope the Alert to One Actor

Your bucket-deletion alert currently watches every actor in the temporary project. In this mission, you will derive an identity filter from a live audit event. You will apply it to the existing policy so the alert watches only the temporary KodeKloud user.

Clean Up Your Resources

The resources in your temporary KodeKloud Google Cloud Playground are expected to cost $0. Choose whether to keep, pause, or delete the remaining alerting resources.

Resources you used:

The enabled Cloud Storage bucket deletion log-based alerting policy in Cloud Monitoring.
The saved email notification channel with the description Learning alerts.

The two empty Cloud Storage test buckets are already deleted. Their Admin Activity audit logs remain in _Required because those logs cannot be disabled or deleted.

Keep everything running

No action is needed. Choose this option if you want the actor-scoped policy to stay active for the remainder of the playground session.

The Cloud Storage bucket deletion policy remains enabled.
The Learning alerts email notification channel remains connected to the policy.

Pause - I'll come back to this later

A paused policy preserves your actor-scoped filter and notification settings for the rest of the session.

Return to the Logs Explorer page from earlier.
Open Actions in the Query results toolbar.
Select Manage log alerts to open the Monitoring Policies page.
Switch the Enabled toggle off for Cloud Storage bucket deletion.

That's your clean pause point. Your saved policy configuration remains available for the rest of the session.

Delete - I don't want to use this again

Deleting this setup permanently removes the policy and its notification channel from the temporary project. Your Admin Activity audit logs in _Required remain untouched.

Return to the Logs Explorer page from earlier.
Open Actions in the Query results toolbar.
Select Manage log alerts to open the Monitoring Policies page.
Find Cloud Storage bucket deletion on the Monitoring Policies page.
Open More options for the policy.
Select Delete.
Confirm the policy deletion by clicking Delete.

The policy should disappear from the Monitoring Policies page. The email channel is now available for deletion.

Return to the Alerting page from earlier.
Select Edit notification channels.
Find Learning alerts in the Email section.
Click the delete control beside Learning alerts.
Confirm the channel deletion in the dialog.

You should no longer see Learning alerts in the Email section. The retained audit logs remain available until the temporary playground session ends.

Nice Work!

Excellent work! Your actor-scoped Google Cloud alert now turns a Cloud Storage bucket deletion into an actionable Cloud Monitoring incident delivered to your inbox.

What you learned:

Built an evidence-driven query in Logs Explorer from a real Admin Activity audit log. Used the live event fields to isolate bucket deletions.
Converted the query into an enabled log-based alerting policy. Routed each match to the Learning alerts email notification channel. Configured 5 min between notifications. Set incidents to autoclose after 30 min.
Verified end-to-end detection by triggering a fresh incident from a second bucket deletion. Opened the incident's Logs pane. Traced the signal back to the matching audit entry.
Secret Mission: Scoped the alert to the temporary KodeKloud user. Derived the identity filter from the live authenticationInfo.principalEmail value.

Ready to quiz yourself?