If you can't prove what happened during a security incident — who accessed what, when, and how — then you have no way to fix the damage, prevent it happening again, or explain it to regulators. That is the problem that incident response and forensics solves: it gives you a repeatable, legally defensible process for finding the truth inside your cloud environment, even when things are chaotic.
Jump to a section
A simple way to picture Incident Response and Forensics in GCP
A lead detective arrives at a house where a burglary has just been discovered. Their first job is not to catch the thief — that comes later. First, they must secure the scene. They tape off the front door, stop the homeowners from walking through the living room, and make sure no one touches anything. Why? Because footprints on the carpet, fingerprints on the window frame, and the open drawer are all fragile evidence. One wrong step and the evidence is contaminated, making it useless in court.
Next, the detective carefully photographs every room, logs the position of every disturbed item, and collects physical samples — fibres, fingerprints, DNA — in sterile bags. Each bag gets a label with the exact time, location, and the name of the officer who collected it. This is called the chain of custody. If the chain is broken, a defence lawyer can argue the evidence was tampered with.
Later, the detective analyses the evidence in the lab. They check which window was forced open, what time the alarm system logged, and whether the thieves left any digital traces like a phone signal. Finally, they write a full report that can stand up in court. Every step — secure, document, collect, analyse, report — mirrors exactly what a cloud security engineer does when a breach happens in Google Cloud. The house is the cloud environment. The burglars are the attackers. The evidence is digital logs, snapshots, and memory dumps. The chain of custody is a verified forensic trail that proves nothing has been altered.
Incident response is the structured process you follow when something bad happens in your cloud system — a hacker breaks in, a rogue employee deletes data, or malware starts encrypting files. Forensics is the part of that process where you collect and analyse digital evidence to understand exactly what happened. Together, they turn a panic-inducing emergency into a controlled investigation.
In Google Cloud Platform (GCP), incident response has a standard lifecycle, often described as six phases: Preparation, Detection, Containment, Eradication, Recovery, and Post-Incident Activity. Let us walk through each one.
Preparation happens before any incident. You set up tools, write runbooks (detailed instruction manuals for response steps), and train your team. In GCP, this means enabling Cloud Logging to record all activity, using Cloud Monitoring to set up alerts for suspicious behaviour, and configuring IAM (Identity and Access Management) roles so that only certain people have the power to shut down systems or access forensic data. You also create pre-approved snapshots of critical VMs (Virtual Machines, which are simulated computers running in the cloud) so you can take forensic copies quickly.
Detection is when you discover something is wrong. This could come from a user report, an automated alert from Cloud Monitoring, or a finding from Security Command Center (GCP's security dashboard that scans for vulnerabilities and threats). The key question at this stage is: 'Is this a real incident, or a false alarm?' You gather initial indicators — an unusual IP address connecting, a spike in CPU usage, a user downloading terabytes of data at 3 AM — and decide whether to escalate.
Containment is about stopping the damage from spreading. If a VM is compromised, you might isolate it by removing it from the network using VPC (Virtual Private Cloud) firewall rules or by shutting it down entirely. You might also revoke the compromised user's access keys. The goal is to limit the blast radius — the set of systems the attacker can reach.
Eradication means removing the attacker's foothold. You delete malware, patch the vulnerability they exploited, rotate all potentially compromised credentials, and rebuild affected systems from clean images (a pre-configured snapshot of a healthy OS). In GCP, you might use Compute Engine's instance templates to redeploy a clean VM.
Recovery is the process of returning to normal operations. You restore data from backups, bring systems back online, and verify that the fix works. GCP offers tools like Cloud Storage for backups and Persistent Disk snapshots for quick VM restoration.
Post-Incident Activity is the final phase. You write a detailed incident report, identify the root cause (the fundamental flaw that allowed the attack), and update your runbooks. You also preserve evidence for legal or compliance reasons. This is where forensics becomes critical.
Forensic data collection in GCP involves several specific techniques. Memory capture: If a VM is under active attack, its RAM (Random Access Memory) contains running processes, network connections, and encryption keys. You can use tools like LiME or Google's own memory acquisition scripts to dump RAM to a file for analysis. Disk forensics: You create a forensic copy (a bit-for-bit clone) of a persistent disk using gcloud compute disks snapshot or by attaching the disk to a separate forensic VM as a read-only device. Log analysis: Cloud Logging collects audit logs (who did what), access logs (who connected), and system logs (what the OS recorded). You export these to a separate project or a BigQuery table (BigQuery is GCP's data warehouse for analysing large datasets) so logs cannot be tampered with. Network capture: You can use VPC Flow Logs to record all network traffic metadata, or deploy Packet Mirroring to copy actual packet contents to a collector for deep inspection.
Chain of custody in GCP is maintained by using Cloud Audit Logs, which record every action taken on forensic evidence — who copied a disk, when, and to where. You also hash the evidence (produce a unique digital fingerprint) using SHA-256 (a cryptographic algorithm) and store the hash in a secure location. If anyone later claims the evidence was modified, you can compare the hash to prove it remains unchanged.
The most important principle is preservation of evidence. You must never work on the original disk or the original logs because that changes them. Instead, you always work on copies. This is why GCP allows you to attach disks in read-only mode, export logs to a locked bucket (a storage container that cannot be deleted or overwritten for a set period), and create snapshots that are point-in-time and immutable.
Detect and Verify
Receive an alert from Security Command Center or a user report. Check Cloud Logging to confirm the alert is not a false positive. Identify the affected resources, the user account involved, and the initial indicators of compromise (IOCs) such as unusual IP addresses or API calls.
Contain and Preserve Evidence
Apply the principle of 'contain first, then collect.' Isolate the affected VM by changing VPC firewall rules to block all traffic to it, or by shutting down its network interface. Do NOT shut down the VM yet. Immediately take a forensic snapshot of the persistent disk and, if possible, dump the VM's RAM using a tool like LiME. Export all relevant Cloud Logging entries to a separate forensic project or a locked Cloud Storage bucket.
Eradicate the Threat
Once evidence is safely preserved, remove the attacker's access. Revoke compromised IAM credentials, rotate all API keys and service account keys the user had access to, delete malware from the disk or rebuild the instance from a clean image, and patch the vulnerability that was exploited. Document every action taken.
Perform Forensic Analysis
Attach the forensic snapshot to a dedicated forensic VM in read-only mode. Analyse the disk for malware, attacker scripts, modified files, and evidence of data exfiltration. Query the exported logs in BigQuery to trace the attacker's actions. Correlate with VPC Flow Logs to understand network movements. Use a tool like Autopsy or the Sleuth Kit for file system analysis.
Recover and Restore
Restore clean systems from backups or pre-validated images. Bring services back online gradually, monitoring for any recurrence of the incident. Test that patching and credential rotation have fully resolved the vulnerability. Update runbooks based on lessons learned.
Report and Post-Incident Review
Write a detailed incident report that includes the timeline, root cause, evidence chain of custody, actions taken, and recommendations. Share with stakeholders, legal, and possibly regulators. Update your security policies and runbooks. Schedule a follow-up review to ensure all improvements are implemented.
Consider a real scenario: Acme Corp runs its e-commerce platform on GCP. One Tuesday morning, the head of security gets an alert from Security Command Center: a privileged user account called 'j.doe@acmecorp.com' just created a Compute Engine instance in a project that has no legitimate use, and that instance is communicating with a known malicious IP address in Eastern Europe.
The security engineer's immediate steps are:
Verify the alert by checking Cloud Logging for the exact API calls made by the account.
Contain the threat by immediately disabling the IAM user account and applying a VPC firewall rule that blocks all outbound traffic from the suspicious instance.
Take a forensic snapshot of the instance's persistent disk before doing anything else, because if they shut it down normally, the RAM is lost and the disk might be cleaned up.
Next, the engineer creates a separate forensic project in a different GCP organisation to store evidence safely. They export the Cloud Logging entries for the last 30 days into a BigQuery table in that forensic project. They also copy the snapshot to a different region so it survives a region-wide outage.
The engineer then attaches the snapshot to a clean forensic VM running a specialised Linux distribution for forensics. They mount the disk as read-only and begin analysis. They search for malware by scanning file hashes (cryptographic fingerprints) against known malware databases. They check the bash history to see what commands the attacker ran. They examine temporary files and browser histories for attacker tools.
Meanwhile, another team member interviews 'j.doe' — it turns out their laptop was infected with a keylogger, and the attacker stole their GCP service account key file. The engineer rotates all credentials associated with that service account and all API keys that user had access to.
After eradicating the malware by rebuilding the affected instance from a clean image, the team writes the incident report. They attach the chain of custody log showing each action taken on the evidence, including who took the snapshot, when, and the SHA-256 hash that proves it hasn't been tampered with. The report is shared with senior management and the legal team in case law enforcement or a regulator asks for it.
The key tools used in this scenario include:
Security Command Center for threat detection
Cloud Logging and Cloud Audit Logs for activity records
Compute Engine snapshots for disk forensics
BigQuery for log analysis
Cloud Key Management Service (Cloud KMS) for managing encryption keys used to protect forensic data at rest
The PCSE exam tests incident response and forensics in GCP in several specific ways. First, you will encounter scenario-based questions where you must choose the correct order of steps in the incident response lifecycle. The exam loves to give you a messy situation and ask: 'What should you do FIRST?' The trap is that many candidates pick 'Eradicate the threat' because it sounds urgent, but the correct answer is always 'Contain the threat' or 'Preserve the evidence' — containment and evidence preservation come before eradication.
Second, the exam tests your knowledge of forensic techniques in GCP. Key concepts to memorise include:
Taking a forensic snapshot of a disk must happen before shutting down the instance, because shutting down clears RAM and changes disk contents.
Use 'gcloud compute disks snapshot' and 'gcloud compute instances export' to create evidence.
Attach the snapshot to a separate forensic VM in read-only mode to avoid altering the evidence.
Export logs to a different project or a locked Cloud Storage bucket to preserve them.
Use 'gcloud logging read' or BigQuery to query logs.
Third, the exam tests chain of custody. You must know that Cloud Audit Logs track every action on resources, and that hashing evidence with SHA-256 is the standard way to prove integrity. A common question asks: 'You suspect a persistent disk contains evidence of a breach. What two steps must you take to preserve the chain of custody?' The correct answer: 'Create a snapshot of the disk and compute its SHA-256 hash, then store the hash in a secure location such as a separate project's Cloud Storage bucket with immutable access controls.'
Fourth, the exam tests the difference between 'live forensics' (taking data from a running system, like memory dumps) and 'dead forensics' (taking data from powered-off systems or disks). In GCP, live forensics is more difficult because you have to interact with the running instance without changing its state — you typically use specialised tools or third-party software. Dead forensics is simpler: you snapshot disks and analyse them offline.
Fifth, the exam loves to test what you should do when you suspect an insider threat. The trap answer is 'Immediately terminate the user's account' — but the better answer is 'First, isolate the user's resources and take forensic snapshots of their running instances, then disable the account.' Why? Because terminating the account might trigger a script that deletes evidence.
Key definitions to memorise:
Containment: limiting damage
Eradication: removing the cause
Chain of custody: documented trail of evidence handling
Forensic image: bit-for-bit copy of a disk
Memory dump: capture of RAM contents
Hash: cryptographic fingerprint (e.g., SHA-256)
The exam will also ask about GCP-specific services:
Cloud Memorystore: not used for forensics, but you need to know it exists so you do not confuse it.
Cloud Storage with Retention Policy: used to lock evidence buckets.
Data Loss Prevention (DLP) API: used to scan for sensitive data, not for forensics per se.
The six phases of incident response in GCP are Preparation, Detection, Containment, Eradication, Recovery, and Post-Incident Activity, and they must be followed in order.
Always take a forensic snapshot of a persistent disk before shutting down a compromised VM, because shutdown destroys volatile evidence in RAM.
Export Cloud Logging entries to a separate project or a locked Cloud Storage bucket during an incident to prevent attackers from tampering with log evidence.
Chain of custody in GCP is maintained through Cloud Audit Logs and by computing SHA-256 hashes of evidence, stored securely away from the evidence itself.
Forensic analysis in GCP must be performed on copies of evidence (snapshots attached in read-only mode), never on the original live system.
Memory forensics (capturing RAM) is essential for finding encryption keys, running processes, and active network connections that are not stored on disk.
When an insider threat is suspected, isolate the user's resources and take forensic snapshots before disabling the account, to prevent automated evidence deletion.
These come up on the exam all the time. Here's how to tell them apart.
Live Forensics
Captures volatile data like RAM and running processes
Performed on a VM that is still powered on
Requires specialised tools to minimise changes to the system
Dead Forensics
Only analyses data on persistent storage (disk)
Performed on a shut-down or offline VM or disk snapshot
Easier to perform without altering evidence; no volatile data captured
Cloud Logging
Records API calls (who did what, when, how)
Useful for understanding user and service account actions
Can be exported to BigQuery or Cloud Storage for long-term analysis
VPC Flow Logs
Records network traffic metadata (source/destination IP, port, protocol)
Useful for understanding network-level connections and exfiltration paths
Does not capture packet contents; only metadata (sampled at a configurable rate)
Disk Snapshot
Captures entire persistent disk at a point in time
Includes deleted files in unallocated space
Does not capture RAM contents like encryption keys or running processes
Memory Dump
Captures contents of RAM (volatile memory)
Contains currently running processes, network connections, and decrypted data
Does not include files on disk unless they were mapped into memory
Containment
Focuses on stopping the incident from spreading
Does not remove the attacker's tools or access yet
First priority: limit blast radius using firewall rules or disabling accounts
Eradication
Focuses on removing the attacker's foothold completely
Involves deleting malware, patching vulnerabilities, rotating credentials
Happens only after evidence is preserved and containment is achieved
Mistake
I can just shut down the hacked VM and then take a disk snapshot for forensics — that is the safest approach.
Correct
Shutting down a VM destroys the RAM contents and may trigger scripts that alter the disk. The correct order is: take a snapshot while the VM is still running (or use a live memory capture), then isolate the VM, then analyse the snapshot on a separate forensic VM.
Beginners think 'shut it down' is the most cautious move because they equate it with stopping the attack. They do not realise that RAM contains the most volatile evidence and that modern malware often wipes itself when a shutdown signal is detected.
Mistake
Cloud Logging is automatically tamper-proof, so I do not need to export logs separately during an incident.
Correct
Cloud Logging is highly durable, but logs are not automatically immutable. An attacker with sufficient permissions (e.g., project owner) can delete or modify log entries. During an incident, you must export logs to a separate project or a locked Cloud Storage bucket with a retention policy before the attacker can tamper with them.
This mistake comes from over-trusting cloud providers' defaults. Beginners assume GCP protects everything by default, but the shared responsibility model means the customer must manage access controls for logs.
Mistake
Forensics in the cloud is basically the same as forensics on a physical computer.
Correct
Cloud forensics differs because you cannot physically seize hardware, you have to rely on API-driven snapshots and logs, the hypervisor can affect evidence, and you must consider shared tenancy (other customers on the same physical host). You also need to account for cloud-specific artifacts like metadata, labels, and service account tokens.
This misconception arises because beginners compare the cloud to a virtual machine on their own laptop. They miss the complexities of multi-tenant infrastructure and the lack of physical access.
Mistake
If I take a disk snapshot, that is a perfect forensic image — it captures everything I need.
Correct
A disk snapshot captures only the persistent disk at a point in time. It does not capture RAM (volatile memory), network connections, running processes, or encryption keys stored in memory. For a complete forensic picture, you also need a memory dump and network flow logs.
Beginners often think 'disk = everything' because they are used to forensics on powered-off computers. In a running cloud instance, the disk is just one part of the story.
Mistake
Once the incident is contained and eradicated, the forensic process is done and I can delete the evidence.
Correct
Evidence must be preserved for legal, regulatory, and insurance purposes for years after the incident. Deleting it early can result in legal liability, loss of insurance coverage, or inability to respond to future audits or lawsuits.
This mistake comes from a problem-solving mindset: fix the issue, move on. Beginners do not appreciate that incident response has a long-tail regulatory and legal dimension.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
You can and should perform live forensics on a running VM to capture volatile data like RAM, running processes, and active network connections. Shutting it down destroys that data. Take a memory dump and a disk snapshot while it is still running, then isolate it.
Store evidence in a separate GCP project that only the forensic team has access to. Use Cloud Storage with a retention policy to prevent deletion or overwriting. Compute a SHA-256 hash of each piece of evidence and store the hash in a separate secure location. Enable Cloud Audit Logs on the evidence project to track every access.
A memory dump is a capture of the contents of a computer's RAM at a specific moment. It is important because it contains encryption keys, decrypted data, running processes, network connections, and sometimes malware that does not write itself to disk. Without it, you miss the attacker's active state.
You can use standard forensic tools like Autopsy, the Sleuth Kit, and Volatility for memory analysis on GCP VMs. However, you also need GCP-specific tools and APIs: 'gcloud' commands for snapshots, BigQuery for log analysis, and Cloud Storage for evidence storage. Some organisations use third-party tools like Google's own Chronicle or partner solutions.
The biggest mistake is panicking and shutting down the VM immediately, which destroys volatile evidence and may trigger malware that deletes itself. Always contain the threat first (e.g., block network access) and collect evidence before taking any destructive actions.
You've finished Incident Response and Forensics in GCP. Continue through the PCSE study guide to build a complete picture of the exam.
Done with this chapter?