Audit AWS Activity with CloudTrail

Create and investigate S3 events with CloudTrail Event history.

Introduction

30 Second Summary

An important change can happen in seconds. Later, memory provides little proof about the person responsible or the exact time.

In this project, you will trace a temporary Amazon S3 bucket through its complete creation-to-deletion lifecycle. AWS CloudTrail Event history links that lifecycle to the responsible IAM identity.

What You'll Build

During your demonstration, you will open real audit records that trace one temporary bucket from creation through deletion.

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

A live resource lifecycle audit that matches your temporary bucket to its real CreateBucket event. You will also match its deletion to the corresponding DeleteBucket event.
An evidence-based investigation that identifies who acted. You can show when the request completed. You can also link its Region, source information, and request details to the affected bucket.
A rehearsed 5 to 7 minute audit demonstration supported by sanitized screenshots that open without internet access.
Secret Mission: Locate a ConsoleLogin event. You will explain the sign-in identity, result, source, and Region caveat.

Are there any prerequisites?

You need an AWS account with an IAM administrator user plus internet access. Keep your existing IAM sign-in URL and credentials ready because this console-only project requires no local software.

Before We Start

Before any console work begins, lock in the evidence your audit demonstration must prove. You will trace one empty temporary Amazon S3 bucket through creation and deletion in AWS CloudTrail Event history, connecting each action to its IAM identity, timestamp, Region, source context, and bucket request details.

Set Up the AWS Console

A reliable audit starts with the intended account identity. The selected Region determines which activity AWS CloudTrail Event history returns.

You'll confirm your IAM user in the AWS Management Console. You'll set one Region before opening Event history.

In this step, get ready to:

Confirm the intended IAM administrator identity.
Set the demonstration Region and prepare a unique bucket name.
Load CloudTrail Event history without creating a trail.

Confirm your IAM identity

CloudTrail records the principal behind each API request. Confirming your demonstration identity now makes the later attribution meaningful.

Your sign-in details stay private throughout this project. Only enter them on your existing IAM user sign-in page.

Visit your existing IAM user sign-in page in your browser.
Keep your credentials off screen during the demonstration.
Keep your full account ID off screen during the demonstration.
Sign in with your existing IAM-user credentials.
Open the account menu in the console header.
Confirm that the displayed IAM user matches the intended administrator identity.
Confirm that the session does not use the root user.
Say, "I am signed in as an IAM user. This matters because CloudTrail should attribute the bucket operations to this identity."

Your AWS Management Console session now has the named IAM identity that CloudTrail should attribute later.

What if this account is restricted?

Your confirmed administrator access is sufficient for this walkthrough.

A restricted identity can use AWSCloudTrail_ReadOnlyAccess to view the CloudTrail console plus recent events.

Creating an Amazon S3 bucket requires s3:CreateBucket. Deleting that bucket requires s3:DeleteBucket.

Organization policies or explicit deny statements can still block those permissions.

Prepare the Region and bucket name

The demonstration uses one Region for the resource activity plus the investigation. This keeps the later event lookup focused.

Select the Region selector in the console header.
Choose Asia Pacific (Mumbai).
Confirm that the console header displays Asia Pacific (Mumbai) for Region code ap-south-1.

Why use one Region?

CloudTrail Event history returns activity for the currently selected Region. Keeping the S3 activity in ap-south-1 gives you one predictable place to investigate.

General purpose bucket names use a shared global namespace. The pattern cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits> uses a random suffix to improve uniqueness.

Create a private note in your usual note-taking app.
Record the current local time in your private note: your current local time.
Exclude your account ID from the bucket name.
Exclude your email address from the bucket name.
Replace each placeholder in the bucket-name pattern with a lowercase value.
Record the completed bucket name in your private note: cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits>.
Record a different backup six-digit suffix in the note: your backup six-digit suffix.

Your private note now contains every value needed to identify the demonstration activity.

Open the baseline Event history

Event history is available automatically without a trail. It provides up to 90 days of regional management events for recent investigations.

Why use Event history?

Event history needs no setup. Its recent activity remains independent of trails or event data stores.

A trail supports ongoing event delivery. This demonstration only needs a recent regional lookup.

Open a new browser tab.
Visit the CloudTrail console.
Confirm that the console Region remains Asia Pacific (Mumbai).
Choose Event history in the left navigation pane.
Leave the default Read only filter set to false.
Confirm that the events table loads successfully.
Leave Create trail untouched.
Leave the CloudTrail Lake event data store controls untouched.

You'll see recent write management events in the table. The exact rows depend on activity in your AWS account.

Event history not loading?

Confirm that CloudTrail remains set to Asia Pacific (Mumbai).
Return to the account menu to verify the intended IAM administrator identity.
Use Help me diagnose this Event history problem..

Before your final check, which Region plus filter value should establish the baseline for this audit?

Check that the console header shows Asia Pacific (Mumbai).
Check that the Event history table remains loaded.
Check that Read only remains set to false.
Confirm that this setup created no trail or event data store.

Your audit baseline is ready. No CloudWatch integration or KMS customer key has been created.

Your identity, Region, Event history baseline, and private demonstration note are ready. Next up, you'll generate the first S3 activity for your audit story.

Create the Temporary S3 Bucket

Your AWS Management Console session now uses the intended IAM administrator in a consistent Region. CloudTrail Event history remains ready in Asia Pacific (Mumbai).

This step creates the source action for your audit investigation. You will create one temporary Amazon S3 bucket with a private configuration.

The S3 bucket list proves that the resource exists. CloudTrail later supplies the identity and request context behind that visible result.

In this step, get ready to:

Open the S3 general purpose bucket creation page.
Apply a private configuration with no optional features.
Create the bucket and record the successful action.

Open the S3 bucket creation page

A general purpose bucket provides the temporary resource for this audit story. You will create it in the same Region used by Event history.

Open a new browser tab.
Open the Amazon S3 console in that tab.
Confirm the navigation bar still shows Asia Pacific (Mumbai).
Choose General purpose buckets in the left navigation pane.
Choose Create bucket.
Keep the default shared global namespace when the namespace choice appears.

You will see the Create bucket page for a general purpose bucket in Asia Pacific (Mumbai).

Apply the private bucket configuration

The demonstration only needs an empty bucket that generates one auditable creation action. Safe defaults keep the resource private while avoiding extra services.

Set AWS Region to Asia Pacific (Mumbai) ap-south-1.
Enter your prepared bucket name in the Bucket name field: cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits>.
Leave Copy settings from existing bucket unused.
Keep Object Ownership set to ACLs disabled.
Confirm Bucket owner enforced is shown.
Keep all four options enabled under Block Public Access settings for this bucket.

Why keep these defaults?

Bucket owner enforced gives the bucket owner control through policies. Disabled ACLs remove a separate access-control mechanism from this temporary resource.

Block Public Access keeps the bucket private. This protects the demonstration bucket from public exposure.

Leave Bucket Versioning set to Disabled.
Leave Tags empty.
Keep Default encryption set to Server-side encryption with Amazon S3 managed keys (SSE-S3).
Leave S3 Object Lock set to Disabled.

Your page now describes a private bucket with no versioning or tags. It also uses SSE-S3 encryption without Object Lock.

Create and record the bucket

Choosing Create bucket sends a bucket-level API request to S3. CloudTrail records that write action as a management event.

Keep the cost footprint small

Creating an AWS resource can feel like a billing commitment. AWS does not charge for creating a bucket.

S3 console browsing can generate standard requests. This walkthrough keeps the bucket empty and limits activity to the audit demonstration.

Choose Create bucket.

✔️ The bucket was created

Great work. Your source action now exists as a real S3 bucket.

ⓧ The name is unavailable

General purpose bucket names use a shared global namespace. Another AWS account can already own the name you prepared.

Return to the Bucket name field.
Replace only the six-digit suffix with the backup suffix from your private note.
Choose Create bucket again.

Bucket creation still blocked?

Confirm that your AWS session still uses the intended IAM administrator.
Check whether an organization policy or explicit deny blocks s3:CreateBucket.
Ask for help with the creation failure: Help me diagnose why my private S3 bucket creation is blocked.

Update the bucket-name entry in your private note to the exact successful value: cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits>.
Record the approximate creation time in your private note: your approximate creation time.
Leave the bucket empty.

Before you check, consider whether the exact bucket name should appear in Asia Pacific (Mumbai).

Return to General purpose buckets.
Search for cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits>.

You will see the exact bucket name listed in Asia Pacific (Mumbai). This confirms that the creation action succeeded in ap-south-1.

Choose the matching bucket name.
Confirm the Objects area contains no uploaded objects.
Return to General purpose buckets for the checkpoint.

The empty Objects view confirms that the bucket contains no data. The bucket list confirms that the exact demonstration resource exists in the intended Region.

Your empty private bucket now gives the audit story a real AWS action to investigate. Next, you will use CloudTrail Event history to find the corresponding creation record.

Investigate the CreateBucket Event

The bucket is now live in Amazon S3. That visible result confirms the console request completed.

AWS CloudTrail Event history supplies the missing audit context for that resource. This investigation connects the creation to the responsible IAM identity.

A reliable audit conclusion needs a precise match because Event history covers many account actions. Fresh events can also take time to arrive.

In this step, get ready to:

Test how useful the current write-event list is for this investigation.
Match the bucket creation to its audit event.
Explain the identity details and request evidence in the event record.

Test the unfiltered history

Before you check the list, consider whether the bucket action will stand out among recent account activity.

Switch back to the CloudTrail tab from earlier.
Confirm the console header shows Asia Pacific (Mumbai).
Confirm the Read only filter remains set to false.
Scan the current write-event rows to decide whether you can identify the bucket action confidently.

The bucket action is buried among unrelated write events. That shortfall is the intended lesson.

An unfiltered event list is weak audit evidence. Event history searches one lookup attribute plus a time range.

Select Lookup attributes.
Choose Event name.
Enter CreateBucket.
Set the time-range type to Relative range.
Set the relative range to 1 hour.

Waiting here can feel uncertain. CloudTrail typically delivers an event within 5 minutes of the API call.

That timing is not guaranteed.

Refresh the results periodically until a recent CreateBucket row appears.

You should see a recent CreateBucket row with its event time and user name. Resource information can also appear when available.

Still Waiting for the Event?

Reconfirm that CloudTrail is set to Asia Pacific (Mumbai).
Keep Relative range set to 1 hour.
Check that CreateBucket uses the exact capitalization shown here.
Help me find my delayed CloudTrail event.

Open the matching event safely

Several CreateBucket rows can share the same action name. Your recorded creation time narrows the candidates.

Compare each matching row's event time with the approximate creation time in your private note.
Compare the matching row's user name with your intended demonstration identity.
Choose the CreateBucket event name in the matching row.
Inspect the event details summary.
Review the Resources referenced table when it is populated.
Scroll to Event record.
Find requestParameters in the JSON payload.
Confirm bucketName matches the exact bucket name in your private note.

You have the crucial link: the live request names the same bucket as your private note. The event now connects the visible S3 change to a specific identity.

Several CreateBucket Rows?

Match the event time to the approximate creation time you recorded.
Match the user name to the IAM identity used for the demonstration.
Use requestParameters.bucketName as the primary link to the bucket.
Help me distinguish the matching CreateBucket event.

Explain the JSON evidence

A CloudTrail event record uses JSON to preserve identity details and request context. The live record is authoritative for your account.

Use this sanitized example as a reading guide:

{
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/example-student",
    "accountId": "123456789012",
    "userName": "example-student"
  },
  "eventTime": "2026-09-03T10:15:30Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "CreateBucket",
  "awsRegion": "ap-south-1",
  "sourceIPAddress": "203.0.113.10",
  "requestParameters": {
    "bucketName": "cloudtrail-audit-demo-example-482193"
  },
  "responseElements": null,
  "readOnly": false,
  "eventType": "AwsApiCall",
  "managementEvent": true,
  "eventCategory": "Management"
}

What Does This Event Record Show?

The userIdentity object identifies the principal that made the request. Its type, arn, accountId, and userName fields provide the identity evidence.
The eventTime field records the UTC date and time when the request completed.
The eventSource field identifies the service that received the request. Your S3 event should show s3.amazonaws.com.
The eventName field identifies the requested API action. This event should show CreateBucket.
The awsRegion field identifies the Region that received the request. The main demonstration should show ap-south-1.
The sourceIPAddress field records the request's source address. Treat this value as potentially sensitive.
The requestParameters object contains the input sent to S3. Its bucketName value is the primary link to your demonstration bucket.
The responseElements field contains returned details when available. A value of null does not prove that the action failed.
The eventType, readOnly, managementEvent, and eventCategory fields classify this as a write management API call.
The raw resources field is optional. Use Resources referenced as supporting evidence when the table is populated.

Before you make the final check, consider which field offers the strongest link between the event and your bucket.

Identify the acting IAM principal from userIdentity.
Match eventTime to the approximate creation time in your private note.
Verify eventSource displays s3.amazonaws.com.
Verify eventName displays CreateBucket.
Verify awsRegion displays ap-south-1.
Confirm requestParameters identifies the exact bucket from your private note.
Read sourceIPAddress without displaying it to your audience.
Classify the record using eventType, readOnly, managementEvent, and eventCategory.

These checks answer who acted, what happened, when it happened, where the request went, and which bucket it targeted.

Interpret responseElements only when response details are present.
Treat resources or Resources referenced as supporting evidence only when present.

You should see CreateBucket, s3.amazonaws.com, and ap-south-1 in the live record. requestParameters should identify the exact bucket from your private note.

Strong work. The visible S3 bucket is now tied to its creator through the exact API request.

Hide the full account ID before capturing the event.
Hide IAM ARN details before capturing the event.
Hide sourceIPAddress before capturing the event.

The creation event now tells a complete audit story. Next, you'll test whether CloudTrail preserves the same evidence after the bucket disappears.

Delete the Bucket and Confirm the Audit Trail

Your CreateBucket investigation in AWS CloudTrail connected the bucket action to the real IAM identity. The audit story currently covers only the resource's creation.

The empty bucket still exists in Amazon S3. Deleting it produces a second write management event that completes the resource lifecycle.

In this step, get ready to:

Delete only the empty temporary bucket.
Investigate the exact DeleteBucket event for the former bucket.
Give an evidence-based conclusion using both lifecycle records.

Delete the empty demonstration bucket

An S3 general purpose bucket must be empty before deletion. Your demonstration bucket meets that requirement because no objects were uploaded.

Bucket deletion is permanent, so taking a moment here is sensible. The exact-name check keeps the action limited to your empty demonstration bucket.

Switch back to the Amazon S3 tab from earlier.
Confirm the navigation bar shows Asia Pacific (Mumbai).
Choose General purpose buckets in the left navigation pane.
Choose the exact bucket name saved in your private note.
Confirm that no objects are listed for this demonstration bucket.
Return to General purpose buckets.

The next confirmation removes the bucket from S3. Your private note preserves the exact name needed to verify the deletion.

Select the option button next to the exact demonstration bucket.
Choose Delete.
Enter the exact bucket name from your private note in the confirmation field.
Choose Delete bucket.

The deletion request is complete when S3 no longer returns the bucket in the list.

Before you search, consider whether S3 should find a resource that has just been deleted.

Search the General purpose buckets list using the exact name from your private note.

You should see no matching bucket. The empty demonstration resource is now deleted.

Bucket Still Visible?

Refresh the bucket list if the deleted name still appears.
Confirm that your search uses the exact name from your private note.
Return to the demonstration bucket if deletion was blocked.
Confirm that no objects are listed.
Help me diagnose why my empty demonstration bucket still appears after deletion.

Find the DeleteBucket event

The deleted resource has disappeared from S3. Its DeleteBucket API activity should arrive in CloudTrail Event history as a write management event.

A short wait is normal here. CloudTrail typically delivers an event within 5 minutes of the API call.

Switch back to the AWS CloudTrail tab from earlier.
Confirm the console header shows Asia Pacific (Mumbai).
Choose Event history in the left navigation pane.
Choose the X at the right of the current CreateBucket lookup.
Choose Event name from Lookup attributes.
Enter the full value DeleteBucket.
Choose Relative range.
Select 1 hour.

The lookup now targets deletion events from the last hour in ap-south-1.

Before you refresh, consider whether the deletion event can identify a bucket that no longer exists in S3.

Refresh the results until a recent DeleteBucket event appears.
Choose the newest matching DeleteBucket event.

The event details establish the action's identity, time, service, and Region.

Confirm eventName is DeleteBucket.
Confirm eventTime aligns with the deletion.
Confirm userIdentity identifies the actual IAM user.
Confirm eventSource is s3.amazonaws.com.
Confirm awsRegion is ap-south-1.

Those fields establish who performed the deletion through S3 in the expected Region.

Inspect sourceIPAddress without exposing its value.
Confirm requestParameters identifies the exact former bucket name from your private note.
Confirm readOnly is false.
Confirm managementEvent is true.

You now have a verified DeleteBucket record tied to the exact former bucket. That completes the destructive half of your audit story.

Deletion Event Not Appearing?

Keep CloudTrail set to Asia Pacific (Mumbai).
Keep Relative range set to 1 hour.
Confirm that the lookup contains the exact value DeleteBucket.
Refresh periodically because delivery timing is not guaranteed.
Help me find my missing DeleteBucket event.

Conclude the bucket lifecycle

The creation record establishes the beginning of the bucket lifecycle. The deletion record establishes its end.

How the Evidence Fits Together

The userIdentity field answers who acted.
The eventName field answers what happened.
The eventTime values establish the action order.
The eventSource field identifies S3 as the receiving service.
The awsRegion field places both requests in ap-south-1.
The sourceIPAddress field provides the recorded source context.
The bucket name in requestParameters links both actions to the same resource.
The value false in readOnly establishes a write operation.
The value true in managementEvent establishes management-event classification.

CloudTrail Event history keeps these management records in its rolling 90-day window. Event history provides this evidence without a trail.

Refer to the verified CreateBucket evidence from earlier.
Keep the current DeleteBucket event details visible.

Before you rehearse, consider whether the records can prove the full lifecycle after the S3 resource is gone.

Deliver a 30-second lifecycle conclusion using every evidence category above.

Your conclusion should answer every audit question from the evidence framework. It should finish with the rolling 90-day availability of both records.

The bucket lifecycle is now fully supported by CloudTrail evidence. Next up, you'll rehearse the timed audit story. You'll also prepare offline backup screenshots.

Rehearse the Audit Story

The bucket is gone from Amazon S3. Your verified AWS CloudTrail records still reconstruct its complete lifecycle.

A live demonstration has two reliability risks. Fresh events can be delayed. The AWS Management Console can also become unavailable when your audience is watching.

A timed rehearsal keeps the audit story within 5 to 7 minutes. Sanitized offline screenshots give you a tested backup for every important piece of evidence.

In this step, get ready to:

Rehearse the create, investigate, delete, investigate, and conclusion sequence within 5 to 7 minutes.
Prepare readable offline screenshots with sensitive details cropped or masked.
Test recovery actions for the failures that could interrupt the demonstration.

Rehearse the timed audit sequence

Your audit story has six beats. Each beat advances from a visible AWS action to evidence that identifies the responsible identity and affected bucket.

Before you start the timer, do you expect the complete audit story to fit within seven minutes if a fresh event is delayed?

Return to the CloudTrail tab from earlier.
Confirm that the console header shows Asia Pacific (Mumbai).
Remove the current DeleteBucket filter by selecting the X at its right.
Start a timer on your Mac.
Use 0:00 to 0:40 to introduce Event history.
Say, "Event history is enabled automatically and shows recent management events. No trail is required for this investigation."
Capture the unfiltered Event history table as your baseline screenshot.

What Does the Opening Establish?

The baseline shows that recent management events are available without creating a trail. Its unrelated write activity also explains why your investigation needs an exact lookup.

Return to the S3 tab from earlier during the 0:40 to 1:45 part of the rehearsal.
Confirm that the console header shows Asia Pacific (Mumbai).
Choose General purpose buckets in the left navigation pane.
Choose Create bucket.
Keep the default shared global namespace.
Enter the exact bucket name from your Private Demonstration Note.
Leave Copy settings from existing bucket unused.
Keep ACLs disabled with Bucket owner enforced.

Why Keep the Earlier Configuration?

The rehearsal uses the same private configuration as your original demonstration. This keeps the audience focused on the audit evidence while the bucket stays empty.

Keep all four Block Public Access settings enabled.
Leave Bucket Versioning disabled.
Leave Tags empty.
Keep Server-side encryption with Amazon S3 managed keys (SSE-S3).
Leave S3 Object Lock disabled.
Say, "This console action calls the S3 API and creates a write management event."
Choose Create bucket.

Is the Bucket Name Unavailable?

Replace only the six-digit suffix with the backup value in your Private Demonstration Note.
Choose Create bucket again.
Help me recover from an unavailable bucket name.

You should see the private demonstration bucket in the General purpose buckets list. That visible resource is the source action for your rehearsed investigation.

Avoid uploading any objects to the bucket.
Capture the General purpose buckets list with the exact bucket name visible.
Keep the bucket Region visible in the screenshot.

Return to the CloudTrail tab from earlier during the 1:45 to 3:30 part of the rehearsal.
Choose Event history in the left navigation pane.
Choose Event name from Lookup attributes.
Enter CreateBucket as the full lookup value.
Set Relative range to 1 hour.
Refresh the results until the matching event appears.
Capture the filtered Event history with the matching row visible.

Keep the Story Moving

This wait can take a few minutes. CloudTrail typically delivers an event within 5 minutes of the API call. Delivery within that period is not guaranteed.

Use the verified creation event from earlier if the fresh event has not arrived. Your audience still sees authoritative evidence without waiting through silence.

Select the matching row using its event time and IAM user.
Choose the matching CreateBucket event name.
Capture the event details summary.
Scroll to Event record.
Capture the JSON with userIdentity, eventTime, eventSource, eventName, awsRegion, and requestParameters visible.
Confirm that requestParameters.bucketName identifies the exact demonstration bucket.
Say, "The event identifies who performed the action, when, where, from which source, and with which bucket name."

What Does the Creation Record Prove?

The actual userIdentity attributes the action to the IAM principal.
The eventTime places the action at its recorded UTC time.
The awsRegion places the request in ap-south-1.
The requestParameters.bucketName value links the request to your demonstration bucket.

Return to the S3 tab from earlier during the 3:30 to 4:30 part of the rehearsal.
Confirm that the demonstration bucket remains empty.
Select the option button beside the exact demonstration bucket.
Choose Delete.
Enter the exact bucket name on the Delete bucket page.
Say, "I am now generating a destructive management action against the same resource."
Choose Delete bucket.

The temporary bucket is deleted again. Its new deletion action now joins the earlier lifecycle evidence.

Return to the General purpose buckets list.
Search for the exact deleted bucket name.
Capture the list showing that the bucket cannot be found.

You should find no matching bucket in S3. The destructive action is complete before you investigate its record.

Return to the CloudTrail tab from earlier during the 4:30 to 6:15 part of the rehearsal.
Remove the current lookup using the X at the right of the filter.
Choose Event name from Lookup attributes.
Enter DeleteBucket as the full lookup value.
Set Relative range to 1 hour.
Refresh the results until the matching event appears.
Capture the filtered Event history with the matching deletion row visible.

Preserve the Demonstration Pace

The verified deletion record from earlier remains valid evidence if the newest event is delayed. Match it through the recorded time and exact former bucket name.

Select the matching row using its event time and IAM user.
Choose the matching DeleteBucket event name.
Capture the event details with the request evidence visible.
Confirm that requestParameters.bucketName identifies the exact former bucket.
Say, "The resource is gone, but the deletion evidence remains available for audit and investigation."
Use 6:15 to 7:00 to deliver your conclusion.
Say, "CloudTrail provides accountability, supports security reviews, and helps administrators investigate changes without relying on memory or screenshots of the resource itself."
Stop the timer after your conclusion.

Record the final duration in your Private Demonstration Note.
Add any rehearsal improvements to the same note.

You should finish between 5 and 7 minutes. You have now rehearsed the full resource lifecycle as one evidence-based audit story.

Outside the Time Window?

Use the verified event rows during your next timed attempt.
Limit each record explanation to identity, action, time, Region, source context, and bucket evidence.
Repeat the rehearsal until the timer finishes between 5 and 7 minutes.
Help me shorten my CloudTrail audit demonstration.

Prepare the offline backup evidence

Each screenshot supports one sentence in your live explanation. A complete sequence lets you continue even when the console or internet connection stops cooperating.

Protect Sensitive Details

Account IDs and source IP addresses can reveal unnecessary identity or network information. Access key IDs must stay outside the presentation.

Keep the event action and bucket evidence readable. Remove unrelated resources that do not support your audit story.

Backup Screenshot Sequence

Your offline backup follows the same order as the live investigation:

Baseline CloudTrail Event history before filtering.
S3 General purpose buckets showing the created bucket.
Event history filtered for CreateBucket.
The CreateBucket event details summary.
The CreateBucket Event record with the identity and request evidence.
S3 General purpose buckets after deletion.
Event history filtered for DeleteBucket.
The DeleteBucket event details with its request evidence.
The optional trail architecture explanation.

Add a separate line to your Private Demonstration Note showing AWS activity -> CloudTrail trail -> S3 bucket -> CloudTrail log files.
Capture that line as the optional architecture image.
Crop or mask sensitive account IDs in every backup image.
Crop or mask any visible access key IDs.
Crop or mask visible source IP addresses.
Crop unrelated resources from each image.
Keep each relevant event name readable.
Keep the exact bucket evidence readable.

The architecture image explains what a trail would add. Your project still has no trail or trail-log bucket.

Arrange the screenshots in the same order as the live sequence.
Save the sanitized images together on your Mac.
Turn off Wi-Fi on your Mac.
Open every backup image in sequence.
Check that each action name is readable.
Check that each bucket reference is readable.
Check that every sensitive value is cropped or masked.
Turn Wi-Fi back on after the offline test.

That backup is ready for presentation conditions. Every important piece of evidence now opens without an internet connection.

Is a Screenshot Hard to Read?

Recapture the view with the relevant row or field near the centre.
Increase the visible size of the JSON before capturing its replacement.
Help me improve an unreadable audit screenshot.

Drill the recovery plan

A recovery plan protects the pace of your presentation when the live path changes. Each response returns your audience to verified evidence without adding another AWS service.

Rehearse the delayed-event response using the correct Region and the 1 hour range.
Rehearse the handoff from a delayed event to the matching verified record or sanitized screenshot.
Rehearse the Region correction by returning S3 to Asia Pacific (Mumbai).
Rehearse the Region correction by returning CloudTrail to Asia Pacific (Mumbai).
Rehearse a missing-event lookup using the full event name with exact capitalization.
Rehearse a multiple-match lookup using the event time and IAM user.
Rehearse a multiple-match lookup using requestParameters.bucketName as the final correlation.

Permission Evidence to Cite

Your confirmed administrator access supports this demonstration.
A restricted identity can use AWSCloudTrail_ReadOnlyAccess for CloudTrail console viewing.
Bucket creation requires s3:CreateBucket.
Bucket deletion requires s3:DeleteBucket.
Organization policies or explicit deny statements can still block an operation.

Rehearse the permission-error explanation using the access details above.
Rehearse the bucket-name conflict response using only the backup six-digit suffix.
Rehearse the deletion-failure response by confirming that the selected demonstration bucket is empty.
Rehearse the absent resources response using Resources referenced when it is populated.
Rehearse the absent resources response using requestParameters.bucketName as the primary link.
Rehearse the console-failure response using the numbered offline screenshots.
State that the screenshots came from your completed rehearsal.

Before the final check, do you think CloudTrail can still reconstruct the lifecycle while the S3 bucket remains deleted?

Return to the CloudTrail tab from earlier.
Choose Event history.
Choose Event name from Lookup attributes.
Enter CreateBucket as the full lookup value.
Set Relative range to 1 hour.
Open the verified creation event.
Confirm that its request details identify the exact demonstration bucket.

You should retrieve the verified creation record in ap-south-1 with its actual identity and request evidence.

Return to Event history.
Remove the current lookup using the X at the right of the filter.
Choose Event name from Lookup attributes.
Enter DeleteBucket as the full lookup value.
Keep Relative range set to 1 hour.
Open the verified deletion event.
Confirm that its request details identify the same former bucket.

You should retrieve the verified deletion record with its identity and former bucket evidence.

Return to the S3 tab from earlier.
Choose General purpose buckets.
Search for the exact demonstration bucket name.

You should find no matching bucket in S3. Both management events remain available in CloudTrail Event history.

Your audit demonstration is ready. You can now deliver a timed lifecycle investigation with readable evidence and a tested recovery path for every expected interruption.

Secret mission

Investigate a ConsoleLogin Event

Extend your audit story from resource changes to authentication. Locate a Region-dependent ConsoleLogin event. Explain the identity evidence without changing your main S3 demonstration.

Clean Up Your Resources

Your temporary Amazon S3 bucket is already deleted, so no project resource remains active. Viewing AWS CloudTrail Event history has no CloudTrail charge, although ordinary S3 console browsing can generate standard requests.

Resources you used:

Temporary empty Amazon S3 general purpose bucket named cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits>, deleted on the main path.

The CreateBucket, DeleteBucket, and optional ConsoleLogin records remain in Event history. AWS manages their rolling 90-day retention.

Keep everything running

No action needed. Choose this if you want to review the audit evidence before it leaves the rolling 90-day Event history window.

Leave the verified CreateBucket and DeleteBucket records unchanged in Asia Pacific (Mumbai).
Leave the optional ConsoleLogin record unchanged in its applicable sign-in Region.

Pause - I'll come back to this later

Stop after the audit investigation. The deleted bucket leaves no project resource to pause.

Close the Amazon S3 console tab.
Close the CloudTrail console tab.
Keep the private demonstration note and sanitized offline screenshots for your next rehearsal.

Delete - I don't want to use this again

The destructive part is already complete. This check confirms that the exact demonstration bucket remains absent.

Return to the Amazon S3 console in Asia Pacific (Mumbai).
Choose General purpose buckets in the left navigation pane.
Search for cloudtrail-audit-demo-<yourname>-<yyyymmdd>-<sixdigits> in the buckets list.
Confirm that the exact bucket cannot be found.
Leave CloudTrail Event history unchanged.

That closes the loop. The temporary bucket is gone while the audit evidence remains.

Nice Work!

You did it! You reconstructed an Amazon S3 bucket lifecycle with AWS CloudTrail Event history.

You've learned how to:

Create a private empty S3 bucket through the AWS Management Console. Delete it after verifying that it contains no objects.
Find the real CreateBucket record in CloudTrail Event history. Repeat the lookup for DeleteBucket. Use the audit evidence to identify the responsible IAM identity. Confirm the affected bucket through the request details.
Deliver a rehearsed 5 to 7 minute audit story backed by sanitized offline screenshots. Use a tested recovery plan when live conditions interrupt the demonstration.
Secret Mission: Extended your audit investigation through the optional challenge.

Ready to quiz yourself?