GCP

Google Cloud KMS – Key Management & Encryption

~ Last updated on : ~ jayendrapatil

Google Cloud KMS Key Management Service

  • Google Cloud KMS – Key Management Service provides a centralized, scalable, fast cloud key management service to manage encryption keys
  • KMS helps apply hardware security modules (HSMs) effortlessly to the most sensitive data by just a toggle between software- and hardware-protected encryption keys with the press of a button.
  • KMS provides support for external keys using Cloud External Key Manager to protect the data in Google Cloud and separate the data from the key
  • Cloud KMS supports multiple protection levels:
    • SOFTWARE – keys protected by software
    • HSM – keys protected by Cloud HSM hardware security modules
    • EXTERNAL – keys managed in an external key manager via Cloud EKM over the internet
    • EXTERNAL_VPC – keys managed in an external key manager via Cloud EKM over a VPC network
  • Cloud KMS now supports post-quantum cryptography (PQC) algorithms to help protect against future quantum computing threats (see Post-Quantum Cryptography section below)

Cloud KMS Keys, Keys Versions, and Key Rings

  • A Cloud KMS key is a named object containing one or more key versions, along with metadata for the key.
  • A key exists on exactly one key ring tied to a specific location.
  • After creation, a key cannot be moved to another location or exported.
  • As of March 2026, keys and key versions can now be deleted (previously only key versions could be destroyed, not deleted). Deleted key names cannot be reused.

Google Cloud KMS Keys, Key Rings, and Key VersionsKey

  • A named object representing a cryptographic key that is used for a specific purpose. The key material – the actual bits used for cryptographic operations – can change over time as new key versions are created
  • Key is the most important object for understanding KMS usage.
  • Key purpose and other attributes of the key are connected with and managed using the key.
  • IAM permissions and roles can be used to allow and deny access to keys
  • Cloud KMS supports both asymmetric keys and symmetric keys.
    • Symmetric key
      • is used for symmetric encryption to protect some corpus of data for e.g., using AES-256 to encrypt a block of plaintext.
    • Asymmetric key
      • consists of a public and private key.
      • can be used for asymmetric encryption, or for creating digital signatures.
      • supports ECDSA on Curve25519 in PureEdDSA mode (added April 2024)
  • Cloud KMS also supports:
    • MAC signing keys – for creating and validating MAC digital signatures
    • Key Encapsulation Mechanism (KEM) keys – for post-quantum safe key encapsulation (Preview, Sept 2025)
  • Key’s type (symmetric or asymmetric) can’t be changed after key creation
  • Cloud KMS supports algorithms including AES-256, RSA 2048/3072/4096, EC P256, EC P384, Ed25519, and post-quantum algorithms (ML-DSA-65, SLH-DSA-SHA2-128S, ML-KEM-768, ML-KEM-1024, KEM-XWING)

Key Ring

  • A grouping of keys for organizational purposes.
  • Key ring belongs to Google Cloud project and resides in a specific location
  • Keys inherit IAM policies from the Key Ring that contains them.
  • Grouping keys with related permissions in a key ring allows you to grant, revoke, or modify permissions to those keys at the key ring level without needing to act on each key individually.
  • Key rings provide convenience and categorization
  • To prevent resource name collisions, a key ring cannot be deleted.
  • Key rings and keys do not have billable costs or quota limitations, so their continued existence does not affect costs or production limits.

Key Metadata

  • Includes resource names, properties of KMS resources such as IAM policies, key type, key size, key state, and any other derived data
  • Key metadata can be managed differently than the key material.

Key Version

  • Represents the key material associated with a key at some point in time.
  • Key version is the resource that contains the actual key material.
  • Granting access to a key also grants access to all of its enabled versions. Access to a key version cannot be managed.
  • A key version can be disabled or destroyed without affecting other versions
  • Disabling or destroying a key also disables or destroys each key version.
  • Versions are numbered sequentially, beginning with version 1.
  • When a key is rotated, a new key version is created with new key material.
  • The same logical key can have multiple versions over time, thus limiting the use of any single version.
  • Symmetric keys will always have a primary version. This version is used for encrypting by default, if no version is specified
  • Asymmetric keys do not have primary versions, and a version must be specified when using the key.
  • When Cloud KMS performs decryption using symmetric keys, it identifies automatically which key version is needed to perform the decryption.
  • Key versions can now be deleted (GA March 2026) in addition to being destroyed. Deleted key versions must meet specific deletion criteria.

Key States

  • A key version’s state is always one of the following:
    • Pending generation (PENDING_GENERATION)
      • Applies to asymmetric keys only
      • is still being generated and can’t be used, enabled, disabled, or destroyed yet.
      • KMS will automatically change the state to enabled as soon as the version is ready.
    • Pending import (PENDING_IMPORT)
      • Applies to imported keys
      • Key material is being imported and can’t be used yet.
      • KMS will automatically change the state to enabled once import completes.
    • Enabled (ENABLED)
      • is ready for use.
    • Disabled (DISABLED)
      • may not be used, but the key material is still available, and the version can be placed back into the enabled state.
    • Scheduled for destruction (DESTROY_SCHEDULED):
      • is scheduled for destruction, and will be destroyed soon.
      • can be placed back into the disabled state.
      • Default scheduled destruction duration is 30 days (changed from 24 hours as of June 2024). Custom durations can be configured between 24 hours and 120 days.
    • Destroyed (DESTROYED)
      • is destroyed, and the key material is no longer stored in Cloud KMS.
      • If the key version was used
        • for asymmetric or symmetric encryption, any ciphertext encrypted with this version is not recoverable.
        • for digital signing, new signatures cannot be created.
      • may not leave the destroyed state once entered, except when re-imported (supported since Sept 2021).
      • It takes 45 days from destruction time for key material to be deleted from all Google active and backup systems.
    • Import failed (IMPORT_FAILED)
      • Key import was attempted but failed.
      • The import can be retried.
  • A key version can only be used when it is enabled.
  • Organization policy constraints can require a key version to be disabled before it can be scheduled for destruction (constraints/cloudkms.disableBeforeDestroy)

Google Cloud KMS Key States

Key Rotation

  • For symmetric encryption, periodically and automatically rotating keys is a recommended security practice
  • Cloud KMS does not support automatic rotation of asymmetric keys and has to be done manually
  • With key rotation, data encrypted with previous key versions is not automatically re-encrypted with the new key version.
  • Rotating keys provides several benefits:
    • Limiting the number of messages encrypted with the same key version helps prevent brute-force attacks enabled by cryptanalysis.
    • In the event that a key is compromised, regular rotation limits the number of actual messages vulnerable to compromise.
    • If you suspect that a key version is compromised, disable it and revoke access to it as soon as possible.
    • Regular key rotation helps validate the key rotation procedures before a real-life security incident occurs.
    • Regular key rotation ensures that the system is resilient to manual rotation, whether due to a security breach or the need to migrate your application to a stronger cryptographic algorithm.

Key Hierarchy

Google Cloud KMS Key Hierarchy

  • Data Encryption Key (DEK)
    • A key used to encrypt data.
  • Key Encryption Key (KEK)
    • A key used to encrypt, or wrap, a DEK.
    • All Cloud KMS platform options (software, hardware, and external backends) allow you to control KEK.
  • KMS Master Key
    • The key used to encrypt the KEK.
    • This key is distributed in memory.
    • KMS Master Key is backed up on hardware devices.
  • Root KMS
    • Google’s internal key management service.

Cloud KMS Autokey

  • Cloud KMS Autokey (GA September 2024) simplifies creating and using customer-managed encryption keys (CMEKs) by automating provisioning and assignment.
  • With Autokey, key rings, keys, and service accounts don’t need to be planned and provisioned before they’re needed. Instead, Autokey generates keys on demand as resources are created.
  • Keys created by Autokey use HSM protection level by default and follow recommended practices for:
    • Separation of duties
    • Key rotation
    • Location matching
    • Key specificity
  • Supported services include Cloud Storage, Compute Engine, BigQuery, Secret Manager, Cloud SQL, and Spanner.
  • Autokey supports two key management models:
    • Centralized key management – keys are created in a dedicated key project for all resources in a folder
    • Delegated key management (Autokey for Projects) – keys are created in the same project as the resources they protect (Public Preview, Feb 2026)
  • Autokey has a free tier (since April 2025):
    • 100 free active key versions monthly
    • 10,000 free cryptographic operations monthly
  • Uses a KeyHandle resource model: creating a KeyHandle triggers Autokey to provision a CryptoKey automatically.

Post-Quantum Cryptography (PQC)

  • Cloud KMS supports post-quantum cryptography algorithms to protect against threats from future quantum computers (“harvest now, decrypt later” attacks).
  • PQC Digital Signatures (Public Preview, February 2025):
    • ML-DSA-65 (FIPS 204) – Module-lattice-based digital signature algorithm
    • SLH-DSA-SHA2-128S (FIPS 205) – Stateless hash-based digital signature algorithm
    • These are NIST-approved post-quantum safe algorithms
  • Key Encapsulation Mechanisms (KEMs) (Preview, September 2025):
    • ML-KEM-768 – NIST-standardized lattice-based KEM
    • ML-KEM-1024 – Higher-security variant of ML-KEM
    • KEM-XWING – Hybrid KEM combining classical and post-quantum algorithms
    • KEMs enable sharing secrets resistant to quantum attacks
    • Uses a new key purpose: KEY_ENCAPSULATION
  • Google Cloud network encryption already uses ML-KEM for cryptographic key exchange by default, protecting all customer workloads.

Single-tenant Cloud HSM

  • Single-tenant Cloud HSM (GA December 2025) provides dedicated single-tenant HSM instances for customers requiring the highest level of isolation.
  • Each instance is a cluster of partitions on HSMs in a single Cloud KMS region.
  • Google manages the physical HSMs, but customers have administrative control over their instance.
  • Available in: us-central1, us-east4, europe-west1, europe-west4
  • Creating and managing an instance requires quorum approval with two-factor authentication using keys created and secured outside of Google Cloud.
  • Single-tenant Cloud HSM incurs additional costs beyond standard Cloud HSM pricing.
  • This differs from standard (multi-tenant) Cloud HSM where Google manages shared HSM infrastructure.

Cloud KMS Locations

  • Within a project, Cloud KMS resources can be created in one of many locations.
  • A key’s location impacts the performance of applications using the key
  • Regional
    • data centers exist in a specific geographical place
  • Dual-regional
    • data centers exist in two specific geographical places.
  • Multi-regional
    • data centers are spread across a general geographical area
  • Global
    • special multi-region with its data centers spread throughout the world
  • Reading and writing resources or associated metadata in dual-regional or multi-regional locations, including the global location may be slower than reading or writing from a single region.
  • Cloud KMS is available in 35+ regions worldwide, including recent additions: asia-southeast3 (Jan 2026), europe-north2 (Mar 2025), northamerica-south1 (Nov 2024), and africa-south1 (Jan 2024)

Cloud External Key Manager (Cloud EKM)

  • Cloud EKM lets you use encryption keys managed within a supported external key management system to protect data within Google Cloud.
  • Supports two connectivity options:
    • Cloud EKM over the internet – communicates with external key manager over the internet
    • Cloud EKM over a VPC – communicates via a Virtual Private Cloud network (private endpoint)
  • Coordinated external keys (since March 2023) – allows creating and managing keys in a compatible external key management system directly from Cloud KMS over a VPC network
  • Partner-managed EKM – arrangement where your EKM is managed by a trusted partner
  • Supported EKM partners include Thales CipherTrust, Fortanix, and others
  • Integrates with Key Access Justifications – provides visibility into reasons for each key access request, enabling fine-grained access control based on justification codes

Encryption Metrics and Key Tracking

  • Encryption Metrics Dashboard (GA May 2026) provides visibility into key usage across CMEK integrations.
  • Shows summaries and details of keys used in CMEK integrations and the resources they protect.
  • Supports both centralized and delegated key management models.
  • Project-level key tracking allows viewing which resources are protected by which keys.
  • Available via Google Cloud Console under Security > Key Management.

Organization Policy Constraints

  • Cloud KMS supports several organization policy constraints for governance:
    • constraints/gcp.restrictNonCmekServices – requires CMEK protection for specified services
    • constraints/gcp.restrictCmekCryptoKeyProjects – limits which KMS keys can be used for CMEK
    • constraints/cloudkms.disableBeforeDestroy – requires key version to be disabled before destruction
    • constraints/cloudkms.allowedProtectionLevels – controls which protection levels can be used (e.g., only EXTERNAL or EXTERNAL_VPC)
  • Custom organization policy constraints (Oct 2024) provide more granular control over specific fields for Cloud KMS resources.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Question 1: Your organization requires that all encryption keys used to protect Cloud Storage data are automatically provisioned with HSM protection and follow best practices for key management. Which Cloud KMS feature should you use?

  1. Cloud EKM with VPC
  2. Cloud KMS Autokey
  3. Manual CMEK creation with HSM protection level
  4. Google-managed encryption keys (GMEK)
Show Answer

Answer: 2 – Cloud KMS Autokey automatically provisions CMEK keys with HSM protection level, following best practices for separation of duties, rotation, and key specificity.

Question 2: Your security team is concerned about “harvest now, decrypt later” attacks where encrypted data is captured today and decrypted by future quantum computers. Which Cloud KMS capability helps mitigate this threat?

  1. Symmetric AES-256 encryption
  2. Cloud HSM with FIPS 140-2 Level 3
  3. Post-quantum cryptography (PQC) digital signatures and KEMs
  4. Key rotation every 90 days
Show Answer

Answer: 3 – Cloud KMS supports post-quantum safe algorithms including ML-DSA-65, SLH-DSA-SHA2-128S for digital signatures, and ML-KEM-768/1024 and KEM-XWING for key encapsulation, designed to resist quantum computer attacks.

Question 3: What is the default scheduled destruction duration for Cloud KMS key versions?

  1. 24 hours
  2. 7 days
  3. 30 days
  4. 90 days
Show Answer

Answer: 3 – As of June 2024, the default scheduled destruction duration is 30 days (changed from the previous 24-hour default). Custom durations between 24 hours and 120 days can be configured.

Question 4: Your company needs dedicated HSM hardware with administrative control, where creating instances requires quorum approval with two-factor authentication. Which Cloud KMS offering meets this requirement?

  1. Multi-tenant Cloud HSM
  2. Single-tenant Cloud HSM
  3. Cloud EKM with VPC
  4. Bare Metal HSM
Show Answer

Answer: 2 – Single-tenant Cloud HSM (GA Dec 2025) provides dedicated single-tenant instances with customer administrative control, requiring quorum approval with 2FA for management operations.

Question 5: Which statements about Cloud KMS key deletion are correct? (Choose 2)

  1. Key rings can be deleted
  2. Keys and key versions can be deleted if they meet deletion criteria
  3. Names of deleted keys can be reused
  4. Keys must meet deletion criteria before they can be deleted
  5. Deleted keys are immediately removed from all systems
Show Answer

Answer: 2, 4 – As of March 2026, keys and key versions can be deleted (GA), but they must meet specific deletion criteria. Key rings cannot be deleted, and names of deleted keys cannot be reused.

See also: Google Cloud Security Services Cheat Sheet

References

Google Cloud Encryption – At Rest & In Transit

~ Last updated on : ~ jayendrapatil

Google Cloud Data Encryption

  • Encryption is a process that takes legible data as input (often called plaintext) and transforms it into an output (often called ciphertext) that reveals little or no information about the plaintext
  • Encryption can be used to protect data in three states:
    • Encryption at Rest protects the data from a system compromise or data exfiltration by encrypting data while stored.
    • Encryption in Transit: protects the data if communications are intercepted while data moves between the site and the cloud provider or between two services.
    • Encryption in Use: protects the data when it is being used by servers to run computations, using hardware-based Trusted Execution Environments (TEEs) such as Confidential Computing.

Encryption at Rest

  • Google uses several layers of encryption to protect customer data at rest.
  • All customer content stored at rest is encrypted, without any action required from the customer, using one or more encryption mechanisms.
  • All data stored in Google Cloud is encrypted at the storage level using AES-256
  • Google encrypts data prior to it being written to disk.

Google Cloud Encryption At Rest Options

Google Cloud Default Encryption

  • Data for storage is split into chunks
  • Each chunk is encrypted with a unique Data Encryption Key (DEK)
  • Two chunks will not have the same encryption key, even if they are part of the same Cloud Storage object, owned by the same customer, or stored on the same machine
  • If a chunk of data is updated, it is encrypted with a new key, rather than by reusing the existing key
  • Data encryption keys are stored with the data because of the high volume of keys at Google, and the need for low latency and high availability
  • Backups are encrypted using a separate DEK
  • Data encryption keys are encrypted with (“wrapped” by) Key Encryption Keys (KEK) also referred to as Envelope Encryption
  • KEKs are stored centrally inside Google’s Key Management Service (KMS)
  • Having a smaller number of KEKs than DEKs and using a central KMS makes storing and encrypting data at Google scale manageable, and allows tracking and controlling data access from a central point.
  • KEKs are not exportable from Google’s KMS by design; all encryption and decryption with these keys must be done within KMS
  • KMS can automatically rotate KEKs at regular time intervals
  • KMS maintains an active key with a set of historical keys for decryption
  • Google uses a common cryptographic library, Tink, which incorporates the FIPS 140-2 validated module, BoringCrypto, to implement encryption consistently across almost all Google Cloud products.

Google Cloud Default Data Encryption

Google Cloud Default Decryption

  • Service makes a call to the storage system for the data it needs.
  • The storage system identifies the chunks in which that data is stored (the chunk IDs) and where they are stored.
  • For each chunk, the storage system pulls the wrapped DEK stored with that chunk and sends it to KMS for unwrapping.
  • The storage system verifies that the identified job is allowed to access that data chunk based on a job identifier, and using the chunk ID
  • KMS verifies that the storage system is authorized both to use the KEK associated with the service and to unwrap that specific DEK.
  • KMS passes the unwrapped DEK back to the storage system, which decrypts the data chunk and passes it to the service.

Google Cloud Decryption

Cloud Key Management Service (Cloud KMS)

  • Cloud KMS helps centralize management of encryption keys
  • Google’s Key Management Service is redundant and globally distributed.
  • Cloud KMS allows the customer to manage the encryption keys (CMEK)
  • A CMEK or Customer Managed Encryption Key can be used in both server-side encryption (SSE) and client-side encryption (CSE).
  • CMEK key can be used with KMS encrypt/decrypt and also be attached to a bucket, GCE disk, etc.
  • CMEK supports importing your own key material, which is useful for migrations.
  • Cloud KMS supports multiple protection levels:
    • SOFTWARE – cryptographic operations performed in software (FIPS 140-3 Level 1 validated)
    • HSM (Multi-tenant) – keys stored in Google-owned FIPS 140-2 Level 3 validated Hardware Security Modules
    • HSM_SINGLE_TENANT – keys stored in dedicated HSM partitions exclusively for a single customer (introduced 2025)
    • EXTERNAL – keys generated and stored in an external key management system, accessed over the internet
    • EXTERNAL_VPC – keys in an external system accessed over a VPC network for better availability
  • Cloud KMS now supports permanent key deletion (GA, Feb 2026) – allows deleting CryptoKeys and CryptoKeyVersions permanently. Deleted key names cannot be reused.

Cloud KMS Autokey

  • Cloud KMS Autokey (GA, 2024) simplifies creating and using CMEKs by automating provisioning and assignment.
  • Autokey automatically creates key rings, keys, and service accounts on demand when resources are created.
  • Eliminates the need to pre-plan and provision keys before they are needed.
  • Incorporates recommended best practices for key management automatically, including key rotation, separation of duties, and appropriate key granularity.
  • Supported services include Cloud Storage, Compute Engine, BigQuery, Cloud Run, Secret Manager, and more.
  • Autokey reduces operational toil for teams managing CMEK at scale.

Post-Quantum Cryptography in Cloud KMS

  • Cloud KMS now supports quantum-safe digital signatures (Preview, Feb 2025) using NIST post-quantum standards:
    • ML-DSA-65 (FIPS 204) – Module-Lattice-Based Digital Signature Algorithm
    • SLH-DSA-SHA2-128s (FIPS 205) – Stateless Hash-Based Digital Signature Algorithm
  • Cloud KMS supports post-quantum Key Encapsulation Mechanisms (KEMs) (Preview, 2025):
    • ML-KEM-768 and ML-KEM-1024 – Module-Lattice-Based Key Encapsulation
    • KEM-XWING – hybrid key encapsulation combining X25519 and ML-KEM
  • These capabilities protect against “Harvest Now, Decrypt Later” attacks where adversaries capture encrypted data today intending to decrypt it with future quantum computers.
  • Google Cloud network encryption already uses ML-KEM by default for all internal cryptographic key exchanges, protecting customer workloads automatically.

Single-Tenant Cloud HSM

  • Single-Tenant Cloud HSM (introduced 2025) provides dedicated HSM partitions exclusively for a single customer.
  • Designed for workloads requiring FIPS 140-2 Level 3 validation with cryptographic isolation from other customers.
  • Each instance is a dedicated cluster of HSM partitions distributed across multiple zones within a region for high availability.
  • Instance administrators have administrative control over the instance.
  • Keys can be generated by Google or imported into the single-tenant instance.
  • Useful for highly regulated industries (financial services, healthcare, government) requiring exclusive hardware isolation.

Cloud External Key Manager (Cloud EKM)

  • Cloud EKM allows using encryption keys managed in a supported external key management partner service.
  • Two connectivity options:
    • EKM over the internet (EXTERNAL protection level) – keys accessed via the internet
    • EKM over VPC (EXTERNAL_VPC protection level) – keys accessed over a VPC network for better availability and security
  • Google Cloud never accesses external key material.
  • Supported by many CMEK-integrated services.
  • Organization policies can restrict key creation to only EXTERNAL or EXTERNAL_VPC types for compliance requirements.

Customer-Supplied Encryption Keys (CSEKs)

  • Customer-Supplied Encryption Keys (CSEK) allows you to supply your own encryption keys. Google uses the key to protect the Google-generated keys used to encrypt and decrypt your data.
  • CSEK is supported only by Cloud Storage and Compute Engine.
  • CSEK Encryption
    • User provides a raw CSEK as part of an API call.
    • The key is transmitted from the Google front end to the storage system’s memory
    • This key is used as the Key Encryption Key (KEK) in Google Cloud Storage for the data.
  • CSEK Decryption
    • Raw CSEK is used to unwrap wrapped chunk keys, to create raw chunk keys in memory.
    • These are used to decrypt data chunks stored in the storage systems.
    • These keys are used as the data encryption keys (DEK) in Google Cloud Storage for your data.
  • Raw CSEK, CSEK-derived keys, and raw chunk/disk keys are never stored on disk unencrypted.
  • Raw chunk/disk keys are stored wrapped with CSEK-derived keys, and with Google keys where automatic restart is used. Google does not permanently store your keys on its servers.

Google Cloud Encryption At Rest Decision Tree

Encryption in Transit

  • Google applies several security measures to help ensure the authenticity, integrity, and privacy of data in transit.
    • Authentication: data source verification, either a human or a process, and destination.
    • Integrity: ensures data sent arrives at its destination unaltered.
    • Encryption: ensures data is unintelligible to keep it private.
  • Data in transit inside a physical boundary controlled by or on behalf of Google is generally authenticated but not necessarily encrypted.
  • Data is encrypted and authenticated in transit at one or more network layers when it moves outside physical boundaries not controlled by Google or on behalf of Google.
  • Depending on the connection that is being made, Google applies default protections to data in transit for e.g., communications are secured between the user and the Google Front End (GFE) using TLS.
  • Google Cloud customers with additional requirements for encryption of data over WAN can choose to implement further protections for data as it moves from a user to an application or VM to VM. These protections include IPSec tunnels, Gmail S/MIME, managed SSL certificates, and service mesh mTLS.
  • Google uses Application Layer Transport Security (ALTS) for mutual authentication and transport encryption of RPC communications within Google’s infrastructure.
  • Google Cloud network encryption now uses post-quantum key exchange (ML-KEM) by default to protect data in transit between Google facilities.

Google Cloud Encryption In Transit

  • [Connection A] – User to Google Front End
    • Google accepts requests from around the world using a globally distributed system called the Google Front End (GFE)
    • GFE terminates traffic for incoming HTTP(S), TCP, and TLS proxy traffic, provides DDoS attack countermeasures, and routes and load balances traffic to the Google Cloud services themselves.
    • User requests to customer applications can be routed through a Google Cloud HTTP(S) or TCP/SSL Proxy Load Balancer external load balancer
    • Google automatically encrypts traffic between GFEs and the backends load balancers that reside within VPC networks
    • Certificate Manager provides automated provisioning and management of TLS certificates for load balancers, including Google-managed certificates with automatic renewal.
  • [Connection B] – User to customer application hosted on Google Cloud
    • Cloud VPN or Interconnect can help secure a direct connection to a VM using an external IP or network load balancer IP. As the connection does not go through GFE, it’s not encrypted by default.
  • [Connection C] – Virtual Machine to Virtual Machine
    • VM to VM connections are encrypted if they leave a physical boundary, and are authenticated within the physical boundary.
    • VM to VM traffic, using external IP addresses, is not encrypted by default, and its security is provided at the user’s discretion
  • [Connection D] – Virtual Machine to Google Cloud Service
    • Connectivity to Google APIs and services can be protected using Private Google Access or Private Service Connect
    • From the VM to the GFE, Google Cloud services support protecting these connections with TLS by default
  • [Connection E] – Google Cloud Service to Google Cloud Service
    • Routing from one Google service to another takes place on Google Cloud network backbone and may require routing traffic outside of physical boundaries controlled by or on behalf of Google
    • Connections between these services are encrypted if they leave a physical boundary, and authenticated within the physical boundary.

Encryption in Use – Confidential Computing

  • Confidential Computing protects data while it is being processed using hardware-based Trusted Execution Environments (TEEs).
  • Encrypts data in memory, ensuring even the cloud provider cannot access data during processing.
  • Confidential VMs encrypt the memory contents of virtual machines using:
    • AMD SEV (Secure Encrypted Virtualization) – N2D machine series
    • AMD SEV-SNP (Secure Nested Paging) – provides additional memory integrity protection
    • Intel TDX (Trust Domain Extensions) – GA on C3 machine series (Sept 2024), creates isolated trust domains
  • Confidential VMs with NVIDIA H100 GPUs (Preview, Oct 2024) – protects AI/ML workloads with GPU-level TEEs, ensuring data remains protected throughout the entire processing pipeline.
  • Confidential GKE Nodes – extends Confidential Computing to Kubernetes workloads.
  • Confidential Space – enables multi-party computation where multiple organizations can collaborate on data without exposing raw data to each other.
  • Supports remote attestation for verifying the integrity of the execution environment.
  • Enables encryption of data across its entire lifecycle: at rest, in transit, and in use.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your organization requires that encryption keys used in Google Cloud must never be accessible to Google. Which encryption option should you use?
    1. Google default encryption
    2. Customer-Managed Encryption Keys (CMEK)
    3. Customer-Supplied Encryption Keys (CSEK)
    4. Cloud External Key Manager (Cloud EKM)

    Answer: d. Cloud EKM keys are stored in an external key management system and Google Cloud never accesses the key material.

  2. A financial services company needs dedicated HSM hardware that is not shared with other customers. Which Cloud KMS protection level should they select?
    1. SOFTWARE
    2. HSM (Multi-tenant)
    3. HSM_SINGLE_TENANT
    4. EXTERNAL_VPC

    Answer: c. Single-Tenant Cloud HSM provides dedicated HSM partitions exclusively for a single customer with cryptographic isolation.

  3. Your security team is concerned about “Harvest Now, Decrypt Later” attacks from future quantum computers. Which Cloud KMS feature addresses this?
    1. AES-256 symmetric encryption
    2. Cloud HSM with FIPS 140-2 Level 3
    3. Post-quantum Key Encapsulation Mechanisms (KEMs)
    4. Customer-Supplied Encryption Keys

    Answer: c. Post-quantum KEMs (ML-KEM-768, ML-KEM-1024, KEM-XWING) are designed to protect against future quantum computing threats.

  4. Which of the following is true about Cloud KMS Autokey? (Select TWO)
    1. It creates key rings and keys on demand when resources are created
    2. It only works with Cloud Storage
    3. It requires manual provisioning of service accounts
    4. It incorporates recommended best practices for key management automatically
    5. It replaces Cloud EKM

    Answer: a, d. Autokey automates key provisioning on demand and follows recommended best practices automatically.

  5. Which Google Cloud technology protects data while it is being processed in memory?
    1. Cloud KMS with CMEK
    2. Confidential Computing with Confidential VMs
    3. Customer-Supplied Encryption Keys
    4. Cloud Armor

    Answer: b. Confidential VMs use hardware-based TEEs (AMD SEV, AMD SEV-SNP, Intel TDX) to encrypt data in memory during processing.

  6. Your organization wants to automate TLS certificate lifecycle management for load balancers. Which service should you use?
    1. Cloud KMS
    2. Certificate Manager
    3. Cloud Armor
    4. Secret Manager

    Answer: b. Certificate Manager provides automated provisioning, management, and renewal of TLS certificates for Google Cloud load balancers.

References

Google Cloud SCC – Security Command Center

~ Last updated on : ~ jayendrapatil

Google Cloud Security Command Center – SCC

📋 Last Updated: June 2026 – Updated with SCC service tier changes (Enterprise tier deprecation May 2026), new services (AI Protection, Model Armor, Cloud Run Threat Detection, Agent Platform Threat Detection), renamed services (Cloud DLP → Sensitive Data Protection), deprecated features (Forseti Security archived, Rapid Vulnerability Detection shut down), multicloud support (AWS/Azure), Gemini AI integration, and V2 API migration.
  • Security Command Center (SCC) is Google Cloud’s comprehensive security and risk management platform.
  • SCC helps generate curated insights that provide a unique view of incoming threats and attacks to the assets.
  • Assets include organizations, projects, folders, instances, and applications.
  • SCC displays possible security risks, called findings, that are associated with each asset.
  • Findings come from security sources that include SCC’s built-in services (Security Health Analytics, Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection, Cloud Run Threat Detection), integrated services like Sensitive Data Protection and Web Security Scanner, third-party partners, and custom security detectors.
  • SCC is available in three service tiers: Standard, Premium, and Enterprise.
  • SCC supports multicloud environments — connecting to AWS and Azure for threat detection, vulnerability assessment, and misconfiguration detection (Enterprise tier).
  • As of December 2024, new SCC activations must use V2 of the Security Command Center API only.

Security Command Center Service Tiers

  • Standard — Basic security and compliance posture management for Google Cloud. Offered at no additional charge. Includes limited Security Health Analytics detectors and basic vulnerability scanning.
  • Premium — Everything in Standard, plus advanced security posture management, attack path simulations, full threat detection (Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection), compliance monitoring, and Security Health Analytics with all detectors. Available at organization or project level.
  • Enterprise — Complete multi-cloud CNAPP (Cloud-Native Application Protection Platform) security including Google Security Operations (SIEM/SOAR) integration, case management, playbooks, CIEM, Mandiant Attack Surface Management, and multicloud support (AWS, Azure).

⚠️ SCC Enterprise Tier Deprecation

The Security Command Center Enterprise service tier was deprecated on May 21, 2026, and will shut down on or after May 21, 2027.

Organizations using the Enterprise tier will automatically move to the Premium tier on or after the shutdown date. Contact your Google Cloud account representative for migration guidance.

Security Command Center Features

Asset Discovery and Inventory

  • Discover assets, data, and Google Cloud services across the organization and view them in one place.
  • Asset management in SCC now leverages Cloud Asset Inventory for asset queries and discovery.
  • Note: The legacy SCC Asset API endpoints were deprecated (June 2023) and shut down (June 2024). Use Cloud Asset Inventory for asset management operations.

Sensitive Data Identification

  • Sensitive Data Protection (formerly Cloud Data Loss Prevention/Cloud DLP) integrates with SCC.
  • Sensitive Data Protection discovery provides continuous data monitoring to identify where sensitive data resides across BigQuery, Cloud Storage, and Datastore.
  • Identify which storage buckets contain sensitive and regulated data.
  • Prevent unintended exposure and ensure access is on need-to-know basis.

Application Vulnerability Detection

  • Web Security Scanner integrates automatically with SCC.
  • Uncover common vulnerabilities like cross-site scripting (XSS), outdated libraries, mixed content, and other OWASP Top Ten vulnerabilities.

Access Control Monitoring

  • Help ensure the appropriate access control policies are in place across the Google Cloud resources and get alerted when policies are misconfigured or unexpectedly change.
  • Cloud Infrastructure Entitlement Management (CIEM) identifies principal accounts that are misconfigured, have excessive permissions, or are granted sensitive permissions (Enterprise tier).
⚠️ Note: Forseti Security, the open-source security toolkit previously integrated with SCC, has been archived and is no longer maintained. Its repository is read-only. Use SCC’s built-in Security Health Analytics and security posture management features as alternatives.

Threat Detection

  • Identify threats like botnets, cryptocurrency mining, anomalous reboots, suspicious network traffic, malware, and identity-based attacks with built-in detection technology.
  • Multiple specialized threat detection services provide layered defense (see SCC Services section below).

Third-party Security Tool Inputs

  • Integrate output from existing security tools like Cloudflare, CrowdStrike, Prisma Cloud by Palo Alto Networks, Qualys, and others into SCC.
  • Integrating output can help detect:
    • DDoS attacks
    • Compromised endpoints
    • Compliance policy violations
    • Network attacks
    • Instance vulnerabilities and threats

Real-time Notifications and Exports

  • Get SCC alerts through Pub/Sub notification integration.
  • Continuous Exports to Pub/Sub, BigQuery, and Cloud Logging for automated finding management.
  • Real-time chat notifications via email, SMS, or messaging platforms.

Security Command Center Services

  • Security Health Analytics provides managed vulnerability assessment scanning that automatically detects the highest severity vulnerabilities and misconfigurations across Google Cloud assets. Supports custom modules for organization-specific detectors. Maps detectors to compliance standards (NIST, HIPAA, PCI-DSS, CIS).
  • Web Security Scanner — custom and managed scans provide information about application vulnerability findings like outdated libraries, cross-site scripting, mixed content, and additional OWASP Top Ten detectors (Premium/Enterprise).
  • Sensitive Data Protection (formerly Cloud DLP) — discovers, classifies, and protects sensitive data across BigQuery, Cloud Storage, and Datastore.
  • Google Cloud Armor — protects Google Cloud deployments against threats like DDoS attacks, XSS, and SQL injection.
  • Event Threat Detection — monitors the organization’s Cloud Logging stream to detect threats including Malware, Cryptomining, Brute Force SSH, credential leaks, IAM anomalies, data exfiltration, and more. Supports custom modules for custom threat detection rules.
  • Container Threat Detection — detects runtime attacks in Container-Optimized OS node images on GKE, including malicious binaries, reverse shells, and container escapes.
  • Virtual Machine Threat Detection (VMTD) — scans Compute Engine VMs at the hypervisor level without requiring agents to detect cryptomining, kernel-mode rootkits, and malware. Also supports AWS EC2 instances.
  • Cloud Run Threat Detection — detects runtime attacks in Cloud Run containers, including malicious binaries, reverse shells, fileless execution, and container escapes (Premium/Enterprise).
  • Agent Platform Threat Detection (Preview) — detects runtime attacks on agents deployed and managed through Agent Runtime, including credential theft, code execution, and data exfiltration by AI agents.
  • Sensitive Actions Service — detects actions taken in Google Cloud that could be damaging if performed by a malicious actor (Premium/Enterprise).
  • Anomaly Detection — identifies security anomalies for projects and VM instances, like potential leaked credentials and cryptocurrency mining.

Advanced Security Features (Premium/Enterprise)

Attack Path Simulations and Risk Assessment

  • Attack Path Simulations identify and prioritize vulnerability and misconfiguration findings by simulating paths an attacker could take to reach high-value resources.
  • Attack Exposure Scores help prioritize remediation by quantifying risk to high-value resources.
  • Toxic Combinations detect groups of risks that, when occurring together, create exploitable paths to high-value resources. Uses virtual red teaming to discover previously unseen attack combinations.
  • Risk Reports provide downloadable reports on the organization’s risk posture.

Security Posture Management

  • Security Posture allows defining and deploying security postures to monitor security status, address posture drift, and detect unauthorized changes.
  • Includes predefined posture templates for CIS Benchmark, ISO 27001, NIST 800-53, PCI DSS, and secure AI.
  • Infrastructure as Code (IaC) Validation — validates Terraform plans against organization policies and Security Health Analytics detectors before deployment.

AI Protection and Model Armor

  • AI Protection helps manage security posture for AI workloads by detecting threats and mitigating risks to the AI asset inventory.
  • Model Armor screens LLM prompts and responses for security and safety risks, protecting against prompt injection, sensitive data leakage, and harmful content.
  • Agent Platform Threat Detection detects threats specific to agentic AI workloads, including credential theft, unauthorized API calls, and data exfiltration by AI agents.

Gemini in Security Command Center

  • Gemini AI provides natural language summaries of findings and recommended remediation steps.
  • AI-powered investigation assistance helps security teams understand and respond to threats faster.
  • Supports natural language queries for finding analysis.

Compliance Management

  • Compliance Manager — define, deploy, monitor, and audit controls and frameworks for security and compliance obligations.
  • Data Security Posture Management (DSPM) — evaluate, deploy, and audit data security frameworks to govern access and use of sensitive data.
  • Supports frameworks including CIS Controls v8, CIS GCP Foundations Benchmark, NIST 800-53, ISO 27001, PCI DSS, and HIPAA.

Multicloud Support (Enterprise Tier)

  • Connect to AWS and Azure for configuration and resource data collection.
  • Detect threats, vulnerabilities, and misconfigurations across multiple cloud providers.
  • Attack exposure scores and attack paths work for external cloud high-value resources.
  • Vulnerability Assessment for AWS detects vulnerabilities in Amazon EC2 instances and ECR images.
  • Cloud Infrastructure Entitlement Management (CIEM) identifies misconfigured identities across cloud providers.

Web Security Scanner

  • Web Security Scanner identifies security vulnerabilities in App Engine, Google Kubernetes Engine (GKE), and Compute Engine web applications.
  • Web Security Scanner crawls the application, following all links within the scope of the starting URLs, and attempts to exercise as many user inputs and event handlers as possible.
  • Web Security Scanner only supports public URLs and IPs that aren’t behind a firewall.
  • Web Security Scanner errs on the side of underreporting and doesn’t display low confidence alerts, to avoid distraction with false positives.
  • It does not replace a manual security review, and it does not guarantee that the application is free from security flaws.
  • Web Security Scanner managed scans are configured and managed by Security Command Center and scan public web endpoints for vulnerabilities weekly (Premium/Enterprise tier).
  • Web Security Scanner custom scans allow scheduling and running custom scans on deployed applications (all tiers).
  • Detects vulnerabilities including XSS, outdated libraries, clear-text passwords, mixed content, and additional OWASP Top Ten categories (Premium/Enterprise).

Deprecated and Removed Features

  • Forseti Security — The open-source security toolkit has been archived and is no longer maintained by Google. Use SCC’s built-in Security Health Analytics and security posture management.
  • Rapid Vulnerability Detection — Preview service was deprecated (May 2024) and shut down (July 2024).
  • SCC Asset API — Legacy asset management endpoints deprecated (June 2023) and shut down (June 2024). Use Cloud Asset Inventory instead.
  • Security marks for asset allowlists — No longer affects Security Health Analytics processing after April 2025. Use mute rules instead.
  • SCC Enterprise tier — Deprecated May 21, 2026. Will shut down on or after May 21, 2027. Organizations will move to Premium tier.
  • Anomaly Detection (standalone) — Being replaced by more specialized detection services (Event Threat Detection, VM Threat Detection).

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your organization needs to detect cryptocurrency mining on Compute Engine VMs without installing any agents. Which SCC service should you enable?
    1. Event Threat Detection
    2. Container Threat Detection
    3. Virtual Machine Threat Detection
    4. Security Health Analytics
    Show Answer

    Answer: c – Virtual Machine Threat Detection (VMTD) operates at the hypervisor level and can detect cryptomining, rootkits, and malware without requiring guest-level agents.

  2. Which SCC feature identifies groups of security issues that, when combined, create exploitable attack paths to high-value resources?
    1. Security Health Analytics
    2. Toxic Combinations
    3. Event Threat Detection
    4. Anomaly Detection
    Show Answer

    Answer: b – Toxic Combinations detects groups of risks that, when occurring together in a particular pattern, create a path to high-value resources that an attacker could potentially exploit.

  3. Your organization wants to detect runtime attacks in Cloud Run containers. Which SCC service provides this capability?
    1. Container Threat Detection
    2. Cloud Run Threat Detection
    3. Event Threat Detection
    4. Web Security Scanner
    Show Answer

    Answer: b – Cloud Run Threat Detection specifically detects runtime attacks in Cloud Run containers, including malicious binaries, reverse shells, and fileless execution.

  4. Which SCC service tier provides multicloud support for detecting threats and vulnerabilities in AWS and Azure environments?
    1. Standard
    2. Premium
    3. Enterprise
    4. All tiers
    Show Answer

    Answer: c – The Enterprise tier provides multicloud CNAPP security with support for AWS and Azure environments, including threat detection, vulnerability assessment, and misconfiguration detection.

  5. Your organization needs to protect AI/LLM workloads from prompt injection attacks and sensitive data leakage. Which SCC service should you use?
    1. AI Protection
    2. Model Armor
    3. Sensitive Data Protection
    4. Event Threat Detection
    Show Answer

    Answer: b – Model Armor screens LLM prompts and responses for security and safety risks, specifically protecting against prompt injection, sensitive data leakage, and harmful content.

  6. Which statement about SCC’s asset management is correct as of 2024?
    1. SCC provides its own Asset API for querying all organization assets
    2. Asset discovery runs every hour automatically
    3. Cloud Asset Inventory should be used for asset management operations
    4. Forseti Security handles all asset monitoring
    Show Answer

    Answer: c – The legacy SCC Asset API was deprecated and shut down in 2024. Cloud Asset Inventory is now the recommended service for asset management operations.

  7. Which SCC feature validates Terraform configurations against security policies before deployment?
    1. Security Posture
    2. Infrastructure as Code (IaC) Validation
    3. Security Health Analytics custom modules
    4. Compliance Manager
    Show Answer

    Answer: b – IaC Validation validates Terraform plans against organization policies and Security Health Analytics detectors before deployment, catching misconfigurations before resources are created.

  8. What happens to organizations using the SCC Enterprise tier after May 21, 2027?
    1. They lose all SCC access
    2. They are automatically moved to the Standard tier
    3. They are automatically moved to the Premium tier
    4. They must purchase a new license
    Show Answer

    Answer: c – The SCC Enterprise tier was deprecated on May 21, 2026, and will shut down on or after May 21, 2027. Organizations will automatically move to the Premium tier.

References

Google Cloud DDoS Protection – Armor & Shield

~ Last updated on : ~ jayendrapatil

Google Cloud DDoS Protection and Mitigation

  • A Denial of Service (DoS) attack is an attempt to render the service or application unavailable to the end-users.
  • With Distributed Denial of Service (DDoS) attacks, the attackers use multiple resources (often a large number of compromised hosts/instances) to orchestrate large-scale attacks against targets.
  • Successfully thwarting and handling DDoS attacks is a shared responsibility between Google Cloud and you.
  • DDoS defense involves deploying detection systems, implementing barriers, and being able to absorb attacks by scaling in order to prevent attackers from overwhelming or disabling access to the services or applications.
  • Google Cloud Armor is Google Cloud’s primary DDoS protection and Web Application Firewall (WAF) service, providing always-on Layer 3/4 DDoS protection and configurable Layer 7 application security.

Google Cloud Armor

  • Google Cloud Armor is the managed DDoS protection and WAF service that defends applications behind Google Cloud load balancers.
  • Provides always-on Layer 3 and Layer 4 (L3/L4) volumetric and network protocol-based DDoS attack protection.
  • Integrates with Global external Application Load Balancer, Classic Application Load Balancer, Regional external Application Load Balancer, External passthrough Network Load Balancer, Global external proxy Network Load Balancer, Cloud CDN, and Media CDN.
  • Offers Web Application Firewall (WAF) with preconfigured rules for OWASP Top 10 protection.
  • Supports IP allowlists/denylists, geo-based access control, custom rules using a flexible rules language, and request header-based filtering.

Cloud Armor Standard vs. Cloud Armor Enterprise

  • Cloud Armor Standard
    • Pay-as-you-go pricing model (per policy, per rule, per request).
    • Always-on L3/L4 volumetric and network protocol-based DDoS attack protection.
    • Access to WAF capabilities including preconfigured WAF rules for OWASP Top 10.
    • Automatically enrolled for all projects with external Application Load Balancer or external proxy Network Load Balancer.
  • Cloud Armor Enterprise (formerly Managed Protection Plus)
    • Available in two pricing models: Annual ($3,000/month per billing account) and Paygo ($200/month per project).
    • Includes all Standard features plus:
      • Bundled Cloud Armor WAF usage
      • Third-party named IP address lists
      • Google Threat Intelligence for Cloud Armor
      • Adaptive Protection for Layer 7 endpoints
      • Advanced network DDoS protection for passthrough endpoints (external passthrough NLB, protocol forwarding, VMs with public IPs)
      • DDoS attack visibility telemetry
      • Hierarchical security policies
    • Annual tier additionally includes DDoS bill protection and DDoS response team access (requires DDoS posture review for subscriptions after Sept 3, 2024).

Adaptive Protection

  • Uses machine learning to detect and mitigate Layer 7 (application-layer) DDoS attacks such as HTTP floods.
  • Monitors traffic patterns and automatically recommends new Cloud Armor rules when anomalous activity is detected.
  • Can automatically deploy suggested rules to block detected attacks.
  • Provides alerting in Cloud Armor Standard; full mitigation capabilities require Cloud Armor Enterprise.
  • Best suited for volumetric L7 protection.

Advanced Network DDoS Protection

  • Provides always-on attack detection and mitigation for volumetric network and protocol DDoS attacks (SYN floods, UDP floods, DNS reflection, NTP amplification).
  • Protects workloads using external passthrough Network Load Balancers, protocol forwarding, and VMs with public IP addresses.
  • Standard network DDoS protection is always enabled; advanced protection adds deeper inspection and mitigation for these passthrough endpoints.
  • Requires Cloud Armor Enterprise enrollment.

Rate Limiting

  • Cloud Armor rate limiting restricts requests from clients within specified time intervals.
  • Supports two actions:
    • Throttle – Enforces a maximum request limit per client or across all clients.
    • Rate-based ban – Temporarily bans clients that exceed a user-configured threshold for a configured period.
  • Rate limiting keys include IP address, HTTP headers, XFF IP, and combinations of multiple keys.
  • Helps mitigate brute-force attacks, credential stuffing, and application-layer DDoS.

Bot Management

  • Cloud Armor integrates with reCAPTCHA Enterprise for bot detection and management at the network edge.
  • Capabilities include:
    • Manual challenge (reCAPTCHA challenge page) – Redirects suspicious users for reCAPTCHA assessment.
    • Frictionless assessment – Filters traffic based on reCAPTCHA token scores without user interaction.
  • Cloud Armor deciphers reCAPTCHA tokens inline with no additional request/response to the reCAPTCHA service.
  • Based on token attributes, Cloud Armor can allow, deny, rate-limit, or redirect requests.

Google Threat Intelligence

  • Provides curated threat intelligence feeds including:
    • Tor exit nodes – Known Tor exit node IP addresses.
    • Known malicious IPs – IP addresses associated with malicious activity.
    • Search engines – IP addresses of legitimate search engine crawlers.
    • VPN providers – Low-reputation VPN provider IPs.
    • Public cloud IP ranges – IP ranges from major cloud providers.
  • Available with Cloud Armor Enterprise.

Hierarchical Security Policies

  • Allow security policies to be configured at the organization, folder, and project levels.
  • Enables centralized security teams to enforce baseline WAF and DDoS protection across multiple projects.
  • Higher-level policies are evaluated before project-level policies.
  • Requires Cloud Armor Enterprise enrollment.
  • Generally available as of 2025.

DDoS Protection and Mitigation Best Practices

Reduce the Surface Attack

  • Provision an isolated and secure piece using Google Cloud VPC.
  • Isolate and secure using subnetworks and networks, firewall rules, tags, and IAM.
  • Open access for only required ports and protocols using firewall rules and/or protocol forwarding.
  • Anti-spoofing protection for the private network (IP addresses) is provided by default.
  • Google Cloud automatically provides isolation between virtual networks.

Isolate the Internal Traffic from the External World

  • Deploy instances without public IPs unless necessary.
  • Set up a NAT gateway or SSH bastion to limit the number of instances that are exposed to the internet.
  • Deploy Internal Load Balancing for the internal client instances accessing internally deployed services to avoid exposure to the external world.

DDoS Protection using Proxy-based Load Balancing

  • With HTTP(S) Load Balancing or SSL proxy Load Balancing, Google infrastructure mitigates and absorbs many Layer 4 and other attacks, such as SYN floods, IP fragment floods, port exhaustion, etc.
  • HTTP(S) Load Balancing with instances in multiple regions can help disperse the attack across instances around the globe.
  • Attach Cloud Armor security policies to backend services behind the load balancer for Layer 7 DDoS protection and WAF capabilities.

Scale to Absorb the Attack

  • Google Frontend Infrastructure – GFE
    • With Google Global Cloud Load Balancing, the GFE terminates user traffic, automatically scales to absorb certain types of attacks (e.g., SYN floods) before they reach the compute instances.
  • Anycast-based Load Balancing
    • HTTP(S) Load Balancing and SSL proxy Load Balancing enable a single anycast IP to front-end the deployed backend instances in all regions.
    • User traffic is directed to the closest backend with capacity.
    • In the event of a DDoS attack, it increases the surface area to absorb this attack by moving traffic to instances with available capacity in any region where backends are deployed.
  • Autoscaling
    • A sufficient number of backend instances should be provisioned and autoscaling configured to handle spikes in traffic.
    • In the event of a sudden traffic spike, the load balancing proxy layer will distribute the traffic across all the backends with available capacity.
    • In parallel, the autoscaler ramps up the backends inline with traffic that needs to be handled.

DDoS Protection with CDN Offloading

  • Cloud CDN acts as a proxy between the clients and the origin servers.
  • For cacheable content, Cloud CDN caches and serves this content from points-of-presence (POPs) closer to the users as opposed to sending them to backend servers (instances).
  • In the event of DDoS attack for cacheable content, the requests are sent to POPs all over the globe as opposed to the origin servers, thereby providing a larger set of locations to absorb the attack.
  • Media CDN can also be used for streaming and large-scale content delivery with built-in DDoS protection.

Deploy Cloud Armor Security Policies

  • Use Cloud Armor security policies to define rules for allowing, denying, throttling, or redirecting traffic.
  • Enable Adaptive Protection for ML-based L7 DDoS detection and automatic rule recommendations.
  • Configure rate limiting rules to protect against volumetric application-layer attacks and brute-force attempts.
  • Use preconfigured WAF rules to protect against OWASP Top 10 attacks (SQL injection, XSS, etc.).
  • Leverage Google Threat Intelligence feeds to block known malicious IPs and Tor exit nodes.
  • Third-party DDoS protection solutions can also be deployed from Google Cloud Marketplace.

App Engine Deployment

  • App Engine is designed to be a fully multi-tenant system and implements a number of safeguards intended to ensure that a single bad application will not impact the performance or availability of other applications.
  • App Engine sits behind the GFE which mitigates and absorbs many Layer 4 and below attacks, such as SYN floods, IP fragment floods, port exhaustion, etc.
  • Use App Engine firewall rules to specify IP addresses/ranges to block from accessing the application(s).
  • Note: The legacy dos.yaml configuration was deprecated and shut down in April 2022. DoS rules were auto-migrated to App Engine Firewall rules.

Google Cloud Storage

  • Use Signed URLs to control access if users do not need a Google account to access Google Cloud Storage resources.

API Rate-limiting and Resource Quotas

  • API rate limits define the number of requests that can be made to the Google Compute Engine API.
  • Compute Engine enforces quotas on resource usage to protect the community of Google Cloud users by preventing unforeseen spikes in usage.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.

Question 1: Your company hosts a web application on Google Cloud behind a Global External Application Load Balancer. You need to protect the application from Layer 7 DDoS attacks with minimal manual intervention. What should you do?

  1. Enable Cloud Armor Standard and create IP denylist rules manually
  2. Subscribe to Cloud Armor Enterprise and enable Adaptive Protection
  3. Deploy a third-party DDoS solution from Google Cloud Marketplace
  4. Configure autoscaling to absorb all attack traffic
Show Answer

Answer: B –

Cloud Armor Enterprise with Adaptive Protection uses machine learning to automatically detect L7 DDoS attacks and recommend (or auto-deploy) mitigation rules, requiring minimal manual intervention.

Question 2: You need to protect VMs with public IP addresses and external passthrough Network Load Balancers from volumetric network DDoS attacks. Which Cloud Armor feature should you enable?

  1. Adaptive Protection
  2. Rate Limiting
  3. Advanced Network DDoS Protection
  4. Preconfigured WAF rules
Show Answer

Answer: C –

Advanced Network DDoS Protection specifically defends passthrough endpoints (external passthrough NLB, protocol forwarding, VMs with public IPs) against volumetric network and protocol DDoS attacks. It requires Cloud Armor Enterprise.

Question 3: Your organization wants to enforce baseline DDoS protection and WAF rules across all projects in a specific folder. What Cloud Armor feature should you use?

  1. Rate limiting rules at the project level
  2. Hierarchical security policies
  3. Google Threat Intelligence named IP lists
  4. Network edge security policies
Show Answer

Answer: B –

Hierarchical security policies allow configuring Cloud Armor WAF and DDoS protection at the organization, folder, and project level, enabling centralized enforcement across multiple projects.

Question 4: You want to distinguish between human users and automated bots accessing your application behind Cloud Armor. Which feature combination should you use?

  1. Rate limiting with IP-based throttling
  2. Cloud Armor bot management with reCAPTCHA Enterprise integration
  3. Google Threat Intelligence Tor exit node blocking
  4. Preconfigured WAF rules for OWASP Top 10
Show Answer

Answer: B –

Cloud Armor bot management integrates with reCAPTCHA Enterprise to assess incoming requests using advanced risk analysis, distinguishing between human users and automated clients with frictionless assessment or manual challenges.

Question 5: Which of the following are included in Cloud Armor Standard without requiring Cloud Armor Enterprise? (Choose TWO)

  1. Always-on L3/L4 DDoS protection for load-balanced endpoints
  2. Adaptive Protection with automatic rule deployment
  3. Preconfigured WAF rules for OWASP Top 10
  4. Advanced Network DDoS Protection for passthrough endpoints
  5. DDoS bill protection credits
Show Answer

Answer: A, C

Cloud Armor Standard includes always-on L3/L4 DDoS protection and access to preconfigured WAF rules. Adaptive Protection (full), Advanced Network DDoS Protection, and DDoS bill protection require Cloud Armor Enterprise.

References

Sensitive Data Protection – Cloud DLP Features

~ Last updated on : ~ jayendrapatil

Google Cloud Sensitive Data Protection (formerly Cloud DLP)

📢 Service Rebranding (2023): Cloud Data Loss Prevention (Cloud DLP) is now part of Sensitive Data Protection, a family of services designed to help discover, classify, and protect sensitive data. The API name remains the same: Cloud Data Loss Prevention API (DLP API).

  • Sensitive Data Protection (formerly Cloud DLP) is a fully managed service designed to help discover, classify, and protect the most sensitive data inside and outside Google Cloud.
  • Sensitive Data Protection helps inspect the data to gain valuable insights and make informed decisions to secure your data.
  • It effectively reduces data risk with de-identification methods like masking, tokenization, and encryption.
  • It seamlessly inspects and transforms structured and unstructured data.
  • Sensitive Data Protection is deeply integrated into Security Command Center Enterprise risk engine for continuous data monitoring, high-value asset identification, vulnerability analysis, and attack scenario simulation.
  • Supports data in Google Cloud (BigQuery, Cloud Storage, Cloud SQL, Datastore), multicloud (Amazon S3, Azure Blob Storage), and external sources via hybrid jobs.

Sensitive Data Protection Services

  • Sensitive Data Protection is a family of services comprising three core capabilities:
    • Discovery – Automatically discovers, classifies, and profiles data across organizations, folders, or projects.
    • Inspection – Detects and classifies sensitive data in content, storage, and images.
    • De-identification – Transforms sensitive data to reduce risk while retaining utility.

Sensitive Data Protection Discovery Service

  • The discovery service continuously and automatically discovers, classifies, and profiles data across an organization.
  • Discovery helps understand the location and nature of data, including shadow data that might not be subject to proper governance.
  • Discovery generates data profiles at project, table, and column levels providing:
    • Data classifications (infoTypes detected)
    • Sensitivity levels and data risk levels
    • Data size and shape
    • Data security posture
    • Estimated null proportion and uniqueness (at column level)
  • Supported Data Sources:
    • BigQuery (GA since April 2022) – including BigLake tables
    • Cloud SQL (GA since March 2024)
    • Cloud Storage (GA since June 2024)
    • Amazon S3 (Sept 2024) – requires Security Command Center Enterprise with AWS connector
    • Azure Blob Storage (April 2025) – requires Security Command Center Enterprise with Azure connector
    • Vertex AI datasets (GA Feb 2025) – profiles training and tuning data for sensitivity
    • Vertex AI tuning jobs (Feb 2026)
  • Discovery can automatically attach tags to resources based on calculated data sensitivity, enabling IAM conditions to grant or deny access based on data sensitivity.
  • Discovery can detect unencrypted secrets (passwords, authentication tokens) in Cloud Functions and Cloud Run environment variables, reporting findings to Security Command Center.
  • Discovery findings can be published to Security Command Center, Dataplex Universal Catalog (Knowledge Catalog), and BigQuery.
  • Supports subscription pricing mode for predictable costs regardless of data growth.
  • Scan configurations are manageable via Terraform (since June 2024).

Data Security Posture Management (DSPM)

  • DSPM provides a data-centric view of Google Cloud security, integrated with Security Command Center.
  • DSPM lets you continuously identify and reduce data risk by understanding what sensitive data you have, where it is stored, and if its use aligns with security and compliance requirements.
  • Starts with a data map providing a birds-eye view of data across your environment, its sensitivity level, and default security posture.
  • Sensitive Data Protection discovery feeds sensitivity signals into DSPM for default data risk assessment.

Sensitive Data Protection Actions

  • An action occurs after a Sensitive Data Protection job completes successfully or, in the case of emails, on error.
  • Supported action types:
    • Save findings to BigQuery (inspection and risk jobs)
    • Save findings to Cloud Storage (inspection jobs – added Aug 2025)
    • Publish to Pub/Sub (inspection and risk jobs)
    • Publish to Security Command Center (risk jobs and discovery)
    • Add Dataplex Catalog aspects based on insights from data profiles (replaced Data Catalog integration)
    • Publish to Google Cloud’s operations suite (risk jobs)
    • Notify by email (inspection and risk jobs)
    • Send inspection results to Dataplex Universal Catalog (Knowledge Catalog) as aspects (Sept 2025)

⚠️ Deprecated Action: “Publish to Data Catalog” was deprecated on September 30, 2025. Data Catalog was discontinued on January 30, 2026, replaced by Knowledge Catalog (formerly Dataplex Universal Catalog). Use “Add Dataplex Catalog aspects” instead.

Sensitive Data Protection Key Concepts

  • Classification is the process to inspect the data and know what data we have, how sensitive it is, and the likelihood.
  • De-identification is the process of removing identifying information from data.
  • De-identification techniques supported:
    • Redaction: Deletes all or part of a detected sensitive value.
    • Replacement: Replaces a detected sensitive value with a specified surrogate value.
    • Masking: Replaces a number of characters of a sensitive value with a specified surrogate character, such as a hash (#) or asterisk (*).
    • Pseudonymization/Tokenization: Replaces sensitive data values with cryptographically generated tokens. Supports:
      • CryptoReplaceFfxFpeConfig – Format-preserving encryption
      • CryptoDeterministicConfig – Deterministic encryption for consistent tokenization
      • CryptoHashConfig – One-way cryptographic hashing
    • Built-in Tokenization (Jan 2025): Serverless API endpoints for on-the-fly tokenization without managing third-party deployments, hardware, or VMs. Fully regionalized for compliance.
    • Generalization: Abstracts a distinguishing value into a more general, less distinguishing value to preserve data utility while reducing identifiability.
    • Bucketing: “Generalizes” a sensitive value by replacing it with a range of values. (For example, replacing a specific age with an age range.)
    • Date shifting: Shifts sensitive date values by a random amount of time.
    • Time extraction: Extracts or preserves specified portions of date and time values.
    • Dictionary replacement: Replaces each detected sensitive value with a random value from a provided word list.

Sensitive Data Protection InfoTypes

  • Sensitive Data Protection uses information types — or infoTypes — to define what it scans for.
  • An infoType is a type of sensitive data, such as a name, email address, telephone number, identification number, credit card number, and so on.
  • An infoType detector is the corresponding detection mechanism that matches an infoType’s matching criteria.
  • InfoType detectors are used in scan configurations to determine what to inspect for and how to transform findings.
  • Supported infoType detector types:
    • Built-in infoType detectors — specified by name, include country-specific and globally applicable data types. Categories include:
      • PII (names, addresses, phone numbers, dates of birth)
      • Financial (credit cards, bank accounts, tax IDs)
      • Credentials & secrets (API keys, passwords, auth tokens, encryption keys)
      • Medical data (medical records, health info)
      • Government IDs (passports, driver’s licenses, national IDs)
      • Document type classifiers (finance, legal, medical, R&D, source code)
      • Image/Object infoTypes (faces, signatures, passports, photo IDs, barcodes, license plates, persons, whiteboards)
      • Image safety classifiers (violence, sexually explicit/suggestive content)
    • General infoType detectors — broader categories (e.g., CREDIT_CARD_DATA, MEDICAL_DATA, GOVERNMENT_ID) that cover multiple specific infoTypes.
    • Custom infoType detectors, defined by you:
      • Small custom dictionary detectors — simple word lists, ideal for several tens of thousands of words or phrases.
      • Large custom dictionary detectors — generated from large lists stored in Cloud Storage or BigQuery, ideal for up to tens of millions of words.
      • Regular expressions (regex) detectors — detect matches based on regex patterns.
      • Custom metadata label detectors (March 2026) — detect specific client-provided metadata labels.
  • Inspection rules to fine-tune scan results:
    • Exclusion rules — decrease findings (including ExcludeByHotword for column-name-based exclusion and image-based exclusion rules).
    • Hotword rules — increase quantity or change likelihood of findings.
    • Adjustment rules (GA Feb 2026) — customize likelihood based on context, supporting both text and image operations.
  • InfoType versioning — control which detection model to use via InfoType.version: latest, stable, or legacy.
  • Likelihood levels used for confidence scoring:
    • LIKELIHOOD_UNSPECIFIED: Default value; same as POSSIBLE.
    • VERY_UNLIKELY
    • UNLIKELY
    • POSSIBLE
    • LIKELY
    • VERY_LIKELY

Classification and De-identification

  • Sensitive Data Protection can classify, redact, and de-identify sensitive data contained in text-based content, images, and content stored in Google Cloud storage repositories.
  • Text Classification and De-identification
    • Text Classification returns classification findings.
    • Text Redaction produces output with sensitive data removed using a placeholder.
    • Conversational content inspection (June 2026) — supports inspecting and de-identifying conversational content via the Conversation ContentItem type.
    • Batched content inspection (June 2026) — supports inspecting and de-identifying batched content via BatchContentItem.
  • Image Classification and Redaction
    • Uses Optical Character Recognition (OCR) technology to recognize text prior to classification.
    • Inspection — inspects base64-encoded images for specified infoTypes, returns detected InfoTypes with pixel coordinates and bounding boxes.
    • Redaction — masks sensitive data findings with opaque rectangles (configurable color).
    • Object detection and redaction (July 2025) — detects and redacts sensitive objects (barcodes, license plates, persons, whiteboards) in images.
  • Storage Classification
    • Scans data stored in Cloud Storage, Datastore, BigQuery, and Cloud SQL.
    • Supports scanning of binary, text, image, Microsoft Word, PDF, Apache Avro files, and archive files.
    • Detects sensitive data in headers and footers of rich document types.
    • Unrecognized file types are scanned as binary files.
  • Date Handling — if dates are considered PII:
    • Using generalization or bucketing (can reduce date utility)
    • Using date shifting which randomly shifts dates but preserves sequence and duration.

Re-identification Risk Analysis

  • Risk analysis is the process of analyzing sensitive data to find properties that might increase the risk of subjects being identified.
  • Risk analysis methods can be used before de-identification to help determine an effective strategy, or after de-identification to monitor for changes or outliers.
  • Supported risk metrics:
    • k-anonymity — measures whether individuals can be distinguished from at least k-1 other individuals.
    • l-diversity — extends k-anonymity by ensuring diversity of sensitive values within each equivalence class.
    • k-map estimation — estimates re-identification risk based on quasi-identifiers.
    • δ-presence (delta-presence) — risk metric for when membership in the dataset is itself sensitive.

Sensitive Data Protection Templates

  • Templates help decouple configuration information from the implementation of requests.
  • Templates provide a robust way to manage large-scale rollouts.
  • Two types of templates:
    • Inspection Templates: Templates for saving configuration for inspection scan jobs, including what predefined or custom detectors to use.
    • De-identification Templates: Templates for saving configuration for de-identification jobs, including infoType and structured dataset transformations.
  • Discovery scans can be configured to reprofile data when the inspection template changes (since Feb 2024).

AI and Generative AI Protection

  • Sensitive Data Protection extends to AI workloads to help organizations safely unlock data value at every stage of the AI journey.
  • Vertex AI Discovery (GA Feb 2025) — discovers and profiles sensitivity of training and tuning data in Vertex AI datasets.
  • Context-aware inspection — understands data context even within images and rich documents for effective AI agent data access control.
  • Fine-grained data minimization for:
    • AI model training and fine-tuning data preparation
    • Runtime protection for chat, data collection, and generative AI prompts/responses
    • Ensuring adherence to regulations and internal policies
  • Integrated with AI Protection framework for security posture management of AI workloads.

Integration with Security Command Center

  • Sensitive Data Protection is deeply integrated into Security Command Center Enterprise risk engine.
  • Publishes the following finding types:
    • Data sensitivity and Data risk — calculated sensitivity and risk levels of profiled tables.
    • PUBLIC_SENSITIVE_DATA — publicly accessible resources with sensitive data.
    • SECRETS_IN_STORAGE — secrets detected in environment variables.
    • SENSITIVE_DATA_CMEK_DISABLED — sensitive data without customer-managed encryption.
  • Security Command Center can automatically prioritize resources based on data sensitivity.
  • Discovery is included in Security Command Center Enterprise tier (since Nov 2024).

Regional Endpoints and Data Residency

  • Regional endpoints (GA Aug 2024) keep data at rest, in use, and in transit within a specified region.
  • Available in 35+ regions globally including multi-regions (asia, europe, us).
  • Content methods process data synchronously in memory — data is not stored on Google Cloud.
  • Storage methods process data in the same region where it resides.

Compliance and Security

  • Certifications: ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018, PCI DSS, HIPAA BAA, MTCS SS 584.
  • Supports GDPR compliance with built-in and custom infoType detectors applicable to EU data.
  • Data encryption in transit and at rest follows Google Cloud encryption standards.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A healthcare company needs to de-identify patient records stored in BigQuery before sharing them with researchers. They need to preserve the format of Social Security numbers for application compatibility while making them non-reversible without the key. Which de-identification technique should they use?
    1. Masking
    2. Redaction
    3. Format-preserving encryption (CryptoReplaceFfxFpeConfig)
    4. Date shifting
    Show Answer

    Answer: c – Format-preserving encryption maintains the format while encrypting the value.

  2. An organization wants to continuously monitor all their BigQuery, Cloud Storage, and Cloud SQL data across all projects for sensitive data without setting up individual scan jobs. What should they use?
    1. Sensitive Data Protection inspection jobs with scheduled triggers
    2. Sensitive Data Protection discovery service at the organization level
    3. Cloud DLP content inspection API
    4. Security Command Center vulnerability scanning
    Show Answer

    Answer: b – The discovery service automatically and continuously discovers, classifies, and profiles data across the organization.

  3. A company is building a generative AI application and needs to ensure that sensitive PII is not included in prompts sent to their LLM. Which Sensitive Data Protection capability should they use?
    1. Discovery service profiling
    2. Risk analysis jobs
    3. Content inspection and de-identification API
    4. Storage classification jobs
    Show Answer

    Answer: c – Content inspection and de-identification processes data synchronously and can be used at runtime to inspect and redact sensitive data from AI prompts and responses.

  4. A financial institution wants to automatically restrict access to BigQuery tables containing highly sensitive data. Which Sensitive Data Protection feature should they configure?
    1. De-identification templates
    2. Discovery with automatic sensitivity-based tagging and IAM conditions
    3. Inspection templates with Pub/Sub actions
    4. Risk analysis jobs with email notifications
    Show Answer

    Answer: b – Discovery can automatically attach tags based on data sensitivity, and IAM conditions can grant or deny access based on these tags.

  5. A security team needs to discover if any Cloud Functions or Cloud Run services have unencrypted secrets in their environment variables. Which feature should they enable?
    1. Storage inspection jobs targeting Cloud Functions
    2. Sensitive Data Protection secrets discovery with Security Command Center integration
    3. Custom infoType detectors for password patterns
    4. Cloud Audit Logs monitoring
    Show Answer

    Answer: b – Sensitive Data Protection can automatically discover unencrypted secrets in Cloud Functions and Cloud Run environment variables and report findings to Security Command Center.

  6. An enterprise using Security Command Center Enterprise wants to profile their Amazon S3 data for sensitive information. What prerequisite is required?
    1. A VPN connection between GCP and AWS
    2. An AWS connector in Security Command Center with Sensitive Data Protection permissions
    3. A hybrid job trigger configured in Sensitive Data Protection
    4. Amazon S3 data must be replicated to Cloud Storage first
    Show Answer

    Answer: b – Multicloud discovery for Amazon S3 (and Azure Blob Storage) requires Security Command Center Enterprise with the appropriate cloud connector configured.

  7. Which of the following are valid de-identification techniques in Sensitive Data Protection? (Choose 3)
    1. Masking
    2. Format-preserving encryption
    3. Dictionary replacement
    4. Data replication
    5. Column deletion
    Show Answer

    Answer: a, b, c – Masking, format-preserving encryption, and dictionary replacement are all supported de-identification techniques.

Reference

Google Cloud IAP – Identity-Aware Proxy & Zero Trust

~ Last updated on : ~ jayendrapatil

Google Cloud Identity-Aware Proxy – IAP

  • Identity-Aware Proxy (IAP) allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
  • IAP intercepts web requests sent to the application, authenticates the user making the request using the Google Identity Service, and only lets the requests through if they come from an authorized user. In addition, it can modify the request headers to include information about the authenticated user.
  • IAP helps establish a central authorization layer for applications accessed by HTTPS to use an application-level access control model instead of relying on network-level firewalls.
  • IAP is designed to enforce the BeyondCorp security model, which establishes a zero-trust perimeter on the public internet for secure, remote work without the need for a traditional VPN.
  • Access policies can be defined centrally and applied to all of the applications and resources.
  • IAP policies scale across the organization.
  • IAP supports multiple identity sources:
    • Google Accounts – Google Cloud users with Google Accounts are redirected through the Google Account sign-in flow.
    • Workforce Identity Federation (GA – Feb 2025) – External IdP users (employees, partners, contractors) authenticate through their own IdP using IAM, without needing to sync identities into Cloud Identity.
    • Identity Platform – Supports a wide range of external identity providers:
      • Email/password
      • OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.)
      • SAML
      • OIDC
      • Phone number
      • Custom
      • Anonymous
  • Google Cloud does not charge for IAP (with some exceptions), and it can be enabled without requiring a BeyondCorp Enterprise license (as of January 2024).

IAP Supported Resources

  • App Engine – Standard and Flexible environments
  • Cloud Run – Directly on services (no load balancer needed, Preview April 2025) or via load balancer (GA since April 2023)
  • Compute Engine – Via Cloud Load Balancing (external and internal HTTPS load balancers)
  • Google Kubernetes Engine (GKE) – Via Cloud Load Balancing
  • On-premises applications – Via IAP connector with Cloud Interconnect or VPN
  • Agent Gateway (GA – June 2026) – Securing agent-to-anywhere egress for AI agents in Gemini Enterprise Agent Platform

How IAP Works

Google Cloud Identity-Aware Proxy Compute GKE

  • Only users with the correct IAM role can access application or resource protected by IAP.
  • Users are subject to the fine-grained access controls implemented by the product in use without requiring a VPN.
  • When a user tries to access an IAP-secured resource, IAP performs authentication and authorization checks.
  • Authentication
    • Requests to the Google Cloud resources come through App Engine, Cloud Run, Cloud Load Balancing (External and Internal HTTPS), or internal HTTP load balancing.
    • If IAP is enabled, information about the protected resource is sent to the IAP authentication server which includes information like the project number, the request URL, and any IAP credentials in the request headers or cookies.
    • IAP supports multiple sign-in methods: Google Account sign-in flow, Workforce Identity Federation (external IdP sign-in), or Identity Platform (email/social).
    • After authentication, the user’s browser stores a token in a browser cookie for future sign-ins.
    • If the request credentials are valid, the authentication server uses those credentials to get the user’s identity (email address and user ID).
    • The authentication server then uses the identity to check the user’s IAM role and check if the user is authorized to access the resource.
  • Authorization
    • After authentication, IAP applies the relevant IAM policy to check if the user is authorized to access the requested resource.
    • User with IAP-secured Web App User role (roles/iap.httpsResourceAccessor) on the Cloud Console project where the resource exists is authorized to access the application.
    • When you turn on IAP for a resource, it automatically creates an OAuth 2.0 client ID and secret (for Google-managed OAuth clients).
    • You can also use authorization policies (Preview – Sept 2024) to delegate authorization decisions to IAP and IAM.
  • For on-premises apps, the requests are routed through the IAP connector which forwards the request through a site-to-site connection established with Cloud Interconnect from Google Cloud to the on-premises network.

IAP for Cloud Run

  • IAP can be enabled directly on Cloud Run services in a single click, with no load balancers required and at no added cost (Preview – April 2025).
  • Alternatively, IAP can be configured on a load balancer with a Cloud Run backend (GA since April 2023).
  • IAP cannot be enabled on both the Cloud Run service and the load balancer simultaneously.
  • When IAP is enabled directly on Cloud Run, it protects all ingress paths including the default run.app URL and any configured load balancer URL.
  • Some integrations (e.g., Pub/Sub) might stop working if IAP is enabled directly on Cloud Run.
  • Cloud Run enforces IAP policies before performing IAM checks on the IAP service account.

Context-Aware Access

  • Context-aware access provides secure access based on user identity, device posture, network location, geographic location, and other contextual attributes.
  • Supports access control for:
    • Google Cloud console and APIs – First layer of defense for protecting infrastructure access.
    • Virtual Machines (VMs) – Enables administrative SSH/RDP access to VMs with robust context-aware controls.
    • Web applications – Provides continuous authorization and authentication for web apps in Google Cloud and other clouds.
  • Access levels can be defined based on:
    • IP address and subnet
    • Device security status (encryption, OS version, screen lock)
    • Geographic location
    • Time of day
    • URL host and path (via IAM conditions)
  • Access levels are enforced by adding them as IAM conditions on IAP-secured resources.

TCP Forwarding

  • IAP TCP forwarding allows establishing an encrypted tunnel over which SSH, RDP, and other traffic can be forwarded to VM instances.
  • VM instances don’t need public IP addresses – IAP TCP forwarding eliminates the need for bastion hosts.
  • The TCP forwarding feature prevents administrative services from being openly exposed to the internet.
  • IAP wraps the SSH connection inside HTTPS before forwarding the connection to the VM.
  • WebSocket support for managing Compute Engine resource sessions is available (April 2024).
  • Requires the iap.tunnelInstances.accessViaIAP permission, included in the IAP-secured Tunnel User role (roles/iap.tunnelResourceAccessor).
  • Firewall rules must allow traffic from the IAP TCP IP range 35.235.240.0/20.
  • Can be secured with VPC Service Controls for additional protection.

Workforce Identity Federation with IAP

  • Generally available since February 2025.
  • Allows using an external identity provider (IdP) to authenticate and authorize a workforce (employees, partners, contractors) using IAM.
  • Users can securely access services deployed on Google Cloud or on-premises without needing to sync identities into Cloud Identity.
  • Supports SAML and OIDC-based external IdPs (e.g., Microsoft Entra ID, Okta, etc.).
  • Service account JWT authentication is also supported for Workforce Identity Federation configured applications (GA – Feb 2025).
  • Configuration involves setting up a workforce pool and provider, creating an OAuth client ID and secret, and enabling IAP to use Workforce Identity Federation.

Programmatic Authentication

  • Service accounts can use JSON Web Tokens (JWTs) to programmatically access resources protected by IAP (GA – May 2024).
  • Provides a streamlined authentication process for workloads accessing IAP-protected applications and services.
  • Path wildcard support in the aud (audience) field is available when using service account JWT authentication (GA – Oct 2025).
  • Programmatic OAuth clients can be allowlisted for programmatic access.
  • Google-managed OAuth clients can be used for simplified setup.

Custom OAuth Clients

  • Custom OAuth clients can be configured via Google Cloud console (GA – March 2026).
  • Required for:
    • Configuring IAP for users outside of an organization.
    • Customizing the OAuth consent screen with custom branding.
    • Providing default OAuth clients for inherited applications across all IAP-protected resources at the organization or project level.
  • Note: The IAP OAuth Admin API was deprecated on January 22, 2025, and reached end-of-life on September 21, 2025. OAuth clients are now configured via the Cloud console or IAP settings directly.

IAP for Agent Gateway

  • Generally available since June 2026.
  • IAP supports securing agent-to-anywhere egress for AI agents in Gemini Enterprise Agent Platform.
  • Agent Gateway acts as the network entry and exit point for all agent interactions, enforcing security and governance policies.
  • Security administrators can grant IAM privileges to source agents by binding IAM allow and deny policies on Agent Registry service instances.
  • Agent Gateway services include MCP servers, destination agents, and endpoints.
  • IAP enforces IAM allow and deny policies for agent traffic within Agent Platform.

Securing with Signed Headers

  • IAP can be configured to use JSON Web Tokens (JWT) to make sure that a request to the app is authorized.
  • By default, only headers x-goog-authenticated-user-{email,id} are passed and can be easily forged to bypass IAP.
  • It protects App from:
    • IAP being accidentally disabled;
    • Misconfigured firewalls;
    • Access from within the project.
  • IAP JWT provides a more secure alternative by verifying the header, payload, and signature of the JWT, which is in the HTTP request header x-goog-iap-jwt-assertion.
  • Signed headers provide secondary security in case someone bypasses IAP.
  • Use signed headers for App Engine (flexible and standard), Compute Engine, GKE, and Cloud Run applications.

IAP Best Practices

  • Don’t use a third-party CDN in front of the application. CDNs may cache content and serve cached pages to unauthenticated users.
  • Make sure all requests to Compute Engine or GKE are routed through the load balancer.
  • Use signed headers for App Engine, Compute Engine, GKE, and Cloud Run applications.
  • Configure firewall rules to protect against traffic that doesn’t come through the load balancer.
  • If using IAP on a load balancer with Cloud Run, disable the run.app URL or use ingress controls to block traffic from outside your network.
  • Don’t enable IAP on both the load balancer and the Cloud Run service simultaneously.
  • Use context-aware access with access levels for granular, attribute-based access control.
  • Use Workforce Identity Federation instead of syncing external identities to Cloud Identity where possible.

Your Responsibilities

  • IAP secures authentication and authorization of all requests to Cloud Run, App Engine, Cloud Load Balancing (HTTPS), and internal HTTP load balancing.
  • If enabling IAP on a load balancer, verify whether the backend resources can be accessed directly.
  • If the backend resource is a VM, configure firewall rules to protect against traffic that doesn’t come through the load balancer. IAP doesn’t protect against activity within a project (e.g., another VM inside the project).
  • If the backend resource is a Cloud Run service, disable the run.app URL or use ingress controls.
  • Update your app to use signed headers or use the App Engine standard environment Users API.

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A company wants to allow employees to access internal web applications without a VPN while ensuring only authenticated and authorized users can reach the apps. The apps are hosted on Compute Engine behind an HTTPS load balancer. What should they use?
    1. Cloud Armor with rate limiting
    2. Identity-Aware Proxy (IAP)
    3. VPC Service Controls
    4. Cloud NAT
    Show Answer

    Answer: b

    IAP provides application-level access control using the BeyondCorp zero-trust model, eliminating the need for VPN access.

  2. Your organization uses an external IdP (Microsoft Entra ID) for employee authentication. You want these employees to access IAP-protected applications without syncing identities to Cloud Identity. What feature should you configure?
    1. Identity Platform with OIDC
    2. Cloud Identity directory sync
    3. Workforce Identity Federation with IAP
    4. OAuth 2.0 client credentials
    Show Answer

    Answer: c

    Workforce Identity Federation (GA Feb 2025) allows using external IdPs with IAP without syncing to Cloud Identity.

  3. A developer wants to programmatically access an IAP-protected API from a service running on Compute Engine. What authentication method should they use?
    1. API key
    2. OAuth 2.0 user credentials
    3. Service account JWT
    4. Firebase authentication token
    Show Answer

    Answer: c

    Service accounts can use JWTs to programmatically access IAP-protected resources (GA since May 2024).

  4. You are securing a Cloud Run application with IAP and don’t want to incur load balancer costs. What is the best approach?
    1. Use Cloud Armor instead of IAP
    2. Enable IAP directly on the Cloud Run service
    3. Place a reverse proxy in front of Cloud Run
    4. Use VPC Service Controls
    Show Answer

    Answer: b

    IAP can be enabled directly on Cloud Run services without a load balancer (Preview since April 2025), at no added cost.

  5. Your security team wants to restrict access to an IAP-protected application to only company-managed devices with encrypted storage, from specific IP ranges. What should you configure?
    1. OAuth scopes
    2. VPC firewall rules
    3. Context-aware access with access levels
    4. Cloud Armor security policies
    Show Answer

    Answer: c

    Context-aware access allows defining access levels based on device attributes, IP address, and other contextual signals.

  6. An administrator wants to SSH into a private VM (no public IP) without setting up a bastion host. What IAP feature enables this?
    1. IAP signed headers
    2. IAP TCP forwarding
    3. IAP context-aware access
    4. IAP OAuth client
    Show Answer

    Answer: b

    IAP TCP forwarding creates an encrypted tunnel for SSH/RDP access to VMs without requiring public IPs or bastion hosts.

  7. What is the primary purpose of verifying IAP signed headers (JWT) in your application code?
    1. To improve application performance
    2. To provide secondary security if IAP is bypassed
    3. To enable load balancing
    4. To authenticate service accounts
    Show Answer

    Answer: b

    Signed headers provide secondary security protection against scenarios where IAP might be accidentally disabled, firewalls misconfigured, or access occurs from within the project.

  8. In the Gemini Enterprise Agent Platform, how does IAP protect AI agent communications? (Choose 2)
    1. By encrypting all agent data at rest
    2. By enforcing IAM allow and deny policies on Agent Registry services
    3. By securing agent-to-anywhere egress through Agent Gateway
    4. By managing agent source code
    Show Answer

    Answer: b, c

    IAP for Agent Gateway (GA June 2026) enforces IAM policies and secures agent-to-anywhere egress within Agent Platform.

References

Google Cloud Security Services Cheat Sheet

~ Last updated on : ~ jayendrapatil

Cloud Armor

  • Cloud Armor protects the applications from multiple types of threats, including distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
  • Cloud Armor is offered in two service tiers: Cloud Armor Standard and Cloud Armor Enterprise (previously Managed Protection Plus).
  • Cloud Armor Standard includes:
    • Pay-as-you-go pricing
    • Always-on L3/L4 volumetric and protocol-based DDoS protection
    • Global and regional security policies
    • Preconfigured WAF rules (OWASP Top 10)
  • Cloud Armor Enterprise includes all Standard features plus:
    • Adaptive Protection with full ML-based L7 DDoS detection and suggested rules
    • Advanced network DDoS protection for external network LBs, protocol forwarding, and VMs with public IPs
    • Threat intelligence integration
    • Bot management with reCAPTCHA Enterprise integration
    • DDoS bill protection
    • Named IP lists
  • Cloud Armor supports applications deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Security policies protect applications running behind a load balancer from DDoS and other web-based attacks
  • Backend service can have only one security policy associated with it
  • Prioritized rules define configurable match conditions, actions (allow or deny) and order in a security policy
  • Cloud Armor provides Preview mode that helps evaluate and preview the rules before going live.
  • Hierarchical Security Policies (GA Oct 2025) facilitate centralized control at the organization and folder level, enabling policy delegation and consistent enforcement across projects.
  • Enhanced WAF inspection (GA Feb 2026) expands request body inspection from 8 KB to 64 KB for all preconfigured WAF rules, improving detection of sophisticated malicious content.
  • Adaptive Protection uses ML to automatically detect and suggest mitigations for L7 DDoS attacks. Full alerts (with suggested rules) require Cloud Armor Enterprise; Standard provides basic alerts only.
  • Rate Limiting supports throttle and ban actions based on per-client request rates.

Cloud Identity-Aware Proxy

  • Identity-Aware Proxy (IAP) allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
  • IAP is based on the BeyondCorp zero-trust security model, establishing a zero-trust perimeter on the public internet for secure remote work without the need for a traditional VPN.
  • IAP intercepts web requests sent to the application, authenticates the user making the request using Google Identity Service, and only lets the requests through if they come from an authorized user. In addition, it can modify the request headers to include information about the authenticated user.
  • IAP helps establish a central authorization layer for applications accessed by HTTPS to use an application-level access control model instead of relying on network-level firewalls.
  • IAP uses Google identities and IAM and can leverage external identity providers as well like OAuth with Facebook, GitHub, Microsoft, SAML, etc.
  • IAP can be configured to use JSON Web Tokens (JWT) as signed headers to make sure that a request to the app is authorized and doesn’t bypass IAP.
  • IAP for Cloud Run (2025) enables IAP directly on Cloud Run services in a single click, with no load balancers required and at no added cost for IAP itself.
  • Google Cloud does not charge for IAP (with some exceptions for programmatic workloads at high scale).
  • Note: The IAP OAuth Admin API was deprecated in January 2025 and shut down in September 2025. Use the IAM API for IAP resource management.

Sensitive Data Protection (formerly Cloud DLP)

  • Cloud Data Loss Prevention (Cloud DLP) has been renamed to Sensitive Data Protection (SDP), now encompassing a broader family of services for discovering, classifying, and protecting sensitive data.
  • Sensitive Data Protection is a fully managed service designed to help discover, classify, and protect the most sensitive data.
  • provides two key features:
    • Classification is the process to inspect the data and know what data we have, how sensitive it is, and the likelihood.
    • De-identification is the process of removing, masking, replacing information from data.
  • uses information types – or infoTypes – to define what it scans like credit card numbers, email addresses, etc.
  • provides various built-in infoType detectors and supports custom ones
  • supports inspection rules to fine-tune scan results using:
    • Exclusion rules decrease the number of findings
    • Hotword rules increase the quantity or change the likelihood value of findings
  • provides likelihood, which indicates how likely it is that a piece of data matches a given infoType like VERY_LIKELY or POSSIBLE, etc.
  • supports Text Classification and Reduction
  • supports Image Classification and Reduction, where the image is handled using its base64 encoded version
  • supports storage classification with scans on data stored in Cloud Storage, BigQuery, Datastore, and Cloud SQL
  • supports scanning of binary, text, image, Microsoft Word, PDF, and Apache Avro files
  • supports Templates to decouple configuration from implementation and manage large-scale rollouts
  • Discovery Service (continuous monitoring) automatically discovers, classifies, and profiles data across the organization, folder, or project, identifying where sensitive and high-risk data reside.
  • Discovery for Vertex AI (2025) extends automated data discovery to Vertex AI datasets and tuning jobs, helping understand data sensitivity in AI training and fine-tuning data.
  • Conversational content inspection (2026) supports inspecting and de-identifying conversational content within ContentItem requests.
  • Sensitive Data Protection is deeply integrated with Security Command Center, feeding data risk insights into the SCC risk engine.
  • Note: Integration with Data Catalog was deprecated (Sept 2025) and discontinued (Jan 2026). SDP discovery results now flow to Security Command Center instead.

Security Command Center – SCC

  • is a Security and risk management platform for Google Cloud
  • helps generate curated insights that provide a unique view of incoming threats and attacks to the assets, which include organization, projects, instances, and applications
  • displays possible security risks, called findings, that are associated with each asset.
  • is available in three tiers: Standard, Premium, and Enterprise (Enterprise is deprecated, shutting down May 21, 2027)
  • SCC Standard Tier (Enhanced, April 2026) is now automatically enabled for eligible customers and includes:
    • AI Protection dashboard with detection of unprotected Gemini inference and guardrail violations
    • 44+ misconfiguration checks based on Google Cloud Security Essentials (GCSE) framework
    • Agentless critical vulnerability scanning
    • Graph-driven risk insights
    • Data Security Posture Management (DSPM) for Vertex AI, BigQuery, and Cloud Storage
    • Compliance Manager with automated monitoring against GCSE
  • SCC Premium Tier adds:
    • Full Security Health Analytics vulnerability scanning
    • Event Threat Detection
    • Container Threat Detection
    • Virtual Machine Threat Detection
    • Cloud Run Threat Detection
    • Attack path simulation and risk scoring
  • provides built-in services:
    • Security Health Analytics provides managed vulnerability assessment scanning that can automatically detect the highest severity vulnerabilities and misconfigurations across assets.
    • Web Security Scanner custom scans provide granular information about application vulnerability findings like outdated libraries, XSS, etc.
    • Sensitive Data Protection (formerly Cloud DLP) discovers, classifies, and protects sensitive data
    • Cloud Armor protects Google Cloud deployments against threats
    • Container Threat Detection can detect the most common container runtime attacks
    • Virtual Machine Threat Detection scans VMs to detect potentially malicious applications such as cryptocurrency mining software, kernel-mode rootkits, and malware
    • Cloud Run Threat Detection continuously monitors Cloud Run resources to detect common runtime attacks
    • Event Threat Detection monitors the organization’s Cloud Logging stream and consumes logs to detect Malware, Cryptomining, brute-force attacks, and identity-based attacks
    • Phishing Protection helps prevent users from accessing phishing sites by classifying malicious content that uses the brand and reporting the unsafe URLs to Google Safe Browsing
    • Continuous Exports, which automatically manage the export of new findings to Pub/Sub.
  • Note: The Anomaly Detection service has been replaced by Event Threat Detection and VM Threat Detection capabilities.
  • Note: Forseti Security (open-source toolkit) has been archived and is no longer maintained. Use SCC built-in services instead.
  • Note: SCC Enterprise tier was deprecated May 21, 2026 and will shut down May 21, 2027. Organizations will automatically move to Premium tier.

DDoS Protection and Mitigation

  • Distributed Denial of Service (DDoS) Protection and Mitigation is a shared responsibility between Google Cloud and the Customer
  • DDoS attack is an attempt to render the service or application unavailable to the end-users using multiple sources
  • DDoS Protection and Mitigation Best Practices
    • Reduce the Attack Surface
      • Isolate and secure network using VPC, subnets, firewall rules, tags and IAM
      • Google provides Anti-spoofing protection and Automatic isolation between virtual networks
    • Isolate Internal Traffic
      • Use private IPs and avoid using Public IPs
      • Use NAT Gateway and Bastion host
      • Use Internal Load Balancer for internal traffic
    • Enable Proxy-based Load Balancing
      • HTTP(S) or SSL proxy load balancer uses GFE that helps mitigate and absorb layer 4 and other attacks
      • Disperse traffic across multiple regions
    • Scale to Absorb the Attack
      • Use GFE for protection
      • Use Anycast-based load balancing to provide single anycast IP to FE
      • Use Autoscaling to scale backend services as per the demand
    • Protection using CDN Offloading
      • CDN acts as a proxy and can help render cache content reducing the load on the origin servers
    • Deploy Cloud Armor for WAF and DDoS Protection
      • Cloud Armor Enterprise provides advanced DDoS protection, adaptive protection, and DDoS bill protection
    • App Engine Deployment
      • A fully multi-tenant system with isolation
    • Google Cloud Storage
      • Use signed URLs to access Google Cloud Storage
    • API Rate Limiting
      • Define rate limiting based on the number of allowed requests
      • API Rate limits are per applied per-project basis
      • Cloud Armor supports rate limiting with throttle and ban actions
    • Resource Quotas
      • Quotas help prevent unforeseen spikes in usage

Access Context Manager

  • Access Context Manager allows organization administrators to define fine-grained, attribute-based access control for projects and resources
  • helps prevent data exfiltration
  • helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
  • helps define desired rules and policy but isn’t responsible for policy enforcement. The policy is configured and enforced across various points, such as VPC Service Controls.
  • supports custom organization policies (GA 2025) for creating custom constraints beyond the built-in access levels.
  • supports individual VPC network members in a perimeter and ingress rules to authorize specific VPC networks to access a perimeter.
  • works with Chrome Enterprise Premium (formerly BeyondCorp Enterprise) for context-aware access that integrates device trust, user identity, and location into access decisions.

Model Armor (New – 2025)

  • Model Armor is a Google Cloud service designed to enhance the security and safety of AI applications that use Large Language Models (LLMs).
  • Works by proactively screening LLM prompts and responses, protecting against various risks and ensuring responsible AI practices.
  • Key capabilities:
    • Prompt injection detection — detects and blocks prompt injection and jailbreak attempts
    • Sensitive data protection — detects and prevents exposure of PII, financial info, and credentials in prompts and responses
    • Content safety — filters harmful, toxic, or inappropriate content
    • Policy enforcement — identifies and reports potential policy violations and can actively block actions
  • Protects all LLMs (including Gemini, OpenAI, Anthropic, Llama, and more) via a REST API.
  • Offers no-code in-line protection integrated with Google Cloud services including Gemini Enterprise Agent Platform.
  • Can integrate with Agent Gateway for securing agentic AI workflows (2026).
  • Integrated with Security Command Center for AI security posture visibility.

FIPS 140-2 / 140-3 Validated

  • The NIST developed the Federal Information Processing Standard (FIPS) Publication 140-2 (and its successor FIPS 140-3) as a security standard that sets forth requirements for cryptographic modules, including hardware, software, and/or firmware, for U.S. federal agencies.
  • FIPS 140-2/140-3 Validated certification was established to aid in the protection of digitally stored unclassified, yet sensitive, information.
  • Google Cloud Platform uses a FIPS 140-2 validated encryption module called BoringCrypto in its production environment.
  • Google’s BoringCrypto module has also received a FIPS 140-3 certificate (#4735), reflecting the transition to the newer standard.
  • Certifications issued under FIPS 140-2 remain valid and acceptable for federal compliance programs until their expiration date.
  • Data in transit to the customer and between data centers, and data at rest are encrypted using FIPS 140-2 validated encryption (or newer).
  • BoringCrypto module that achieved FIPS 140-2/140-3 validation is part of the BoringSSL library.
  • BoringSSL library as a whole is not FIPS validated
  • In order to operate using only FIPS-validated implementations:
    • Google’s Local SSD storage product is automatically encrypted with NIST approved ciphers, but Google’s current implementation for this product doesn’t have a FIPS validation certificate. If you require FIPS-validated encryption on Local SSD storage, you must provide your own encryption with a FIPS-validated cryptographic module.
    • Google automatically encrypts traffic between VMs that travels between Google data centers using NIST-approved encryption algorithms, but this implementation does not have a FIPS validation certificate. If you require this traffic to be encrypted with a FIPS-validated implementation, you must provide your own.
    • Clients connecting to Google infrastructure with TLS clients must be configured to require use of secure FIPS-compliant algorithms; if the TLS client and GCP’s TLS services agree on an encryption method that is incompatible with FIPS, a non-validated encryption implementation will be used.
    • Applications built and operated on GCP might include their own cryptographic implementations; in order for the data they process to be secured with a FIPS-validated cryptographic module, you must integrate such an implementation yourself.
  • All Google Cloud regions and zones currently support FIPS 140-2 validated encryption.
  • GKE supports FIPS 140-2 validated encryption using BoringCrypto, with nodes configured to use FIPS-compliant cryptographic modules.

Related Posts

Google Cloud Armor – WAF, DDoS Protection & Rate Limiting

~ Last updated on : ~ jayendrapatil

Google Cloud Armor – Security Policies, WAF Rules, DDoS Protection & Rate Limiting

Google Cloud Armor is GCP’s web application firewall (WAF) and DDoS protection service. This cheat sheet covers Cloud Armor security policies, preconfigured WAF rules (OWASP Top 10), rate limiting, bot management with reCAPTCHA, Adaptive Protection, hierarchical policies, and Cloud Armor Enterprise vs Standard tiers — essential for GCP certification exams including Associate Cloud Engineer and Professional Cloud Architect.

🔄 Major Updates (2024-2026)

  • Cloud Armor Enterprise (formerly Managed Protection Plus) is now the premium tier with advanced DDoS, Threat Intelligence, and Adaptive Protection features.
  • Cloud CDN, Media CDN, and Cloud Storage are now supported via edge security policies.
  • Regional internal Application Load Balancer support is now GA (Oct 2024).
  • Hierarchical Security Policies for organization/folder-level policy management are GA (Oct 2025).
  • Enhanced WAF inspection up to 64 KB request body is GA (Feb 2026).
  • Match Condition Builder for visual CEL expression creation (March 2026).
  • Google Cloud Armor helps protect the applications from multiple types of threats, including distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
  • Google Cloud Armor is offered in two service tiers: Cloud Armor Standard and Cloud Armor Enterprise.
  • Cloud Armor provides always-on protection from L3 and L4 volumetric and network protocol-based DDoS attacks for applications behind supported load balancers.
  • Cloud Armor supports applications deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Cloud Armor security policies can be attached to the following load balancers:
    • Global external Application Load Balancer (HTTP/HTTPS)
    • Classic Application Load Balancer (HTTP/HTTPS)
    • Regional external Application Load Balancer (HTTP/HTTPS)
    • Regional internal Application Load Balancer (HTTP/HTTPS)
    • Global external proxy Network Load Balancer (TCP/SSL)
    • Classic proxy Network Load Balancer (TCP/SSL)
    • External passthrough Network Load Balancer (TCP/UDP)
    • Cloud CDN (via edge security policies)
    • Media CDN (via edge security policies)

Cloud Armor Standard vs Cloud Armor Enterprise

  • Cloud Armor Standard
    • Pay-as-you-go pricing model
    • Always-on L3/L4 volumetric and protocol-based DDoS protection
    • Access to Cloud Armor WAF rule capabilities including preconfigured WAF rules for OWASP Top 10
    • Integration with Cloud CDN and Media CDN
    • Adaptive Protection (alerting only)
  • Cloud Armor Enterprise (formerly Managed Protection Plus)
    • Available in two pricing models: Annual ($3000/month per billing account) and Paygo ($200/month per project)
    • All features of Cloud Armor Standard
    • Bundled Cloud Armor WAF usage (rules, policy, and requests)
    • Third-party named IP address lists
    • Google Threat Intelligence for Cloud Armor
    • Adaptive Protection for L7 endpoints (full capabilities)
    • Advanced network DDoS protection for passthrough endpoints, protocol forwarding, and VMs with public IP addresses
    • DDoS attack visibility telemetry
    • Hierarchical security policies
    • DDoS bill protection (Annual only)
    • DDoS response team services (Annual only, with eligibility requirements)

Security Policies

  • Security policies protect applications by providing Layer 7 filtering and scrubbing incoming requests for common web attacks before traffic reaches load-balanced backend services or backend buckets.
  • Each security policy is made up of a set of rules configurable on attributes from Layer 3 through Layer 7.
  • Rules can filter traffic based on conditions such as IP address, IP range, region code, request headers, and more using Common Expression Language (CEL).
  • A backend service can have only one security policy associated with it.
  • Types of Security Policies:
    • Backend security policies (CLOUD_ARMOR) – filter HTTP requests targeting backend services before they hit origin servers
    • Edge security policies (CLOUD_ARMOR_EDGE) – filter HTTP requests targeting backend services (including Cloud CDN-enabled) and backend buckets (Cloud Storage) before requests are served from cache
    • Network edge security policies – filter traffic at the network edge for external passthrough NLB, protocol forwarding, and VMs with public IPs (Enterprise only)
    • Regional backend security policies – for regional internal Application Load Balancers

Security Policy Rules

  • Prioritized rules define configurable match conditions, actions, and order in a security policy.
  • Rule evaluation order is determined by rule priority, from the lowest number to the highest number.
  • Security policies are made up of rules that allow or prohibit traffic from IP addresses or ranges defined in the rule.
  • Rule Actions: allow, deny (with configurable HTTP status codes), throttle, rate-based ban, redirect.
  • Cloud Armor provides Preview mode that helps evaluate and preview the rules before going live.
  • Match Condition Builder (2026) allows creating complex CEL expressions visually without writing raw code.

Preconfigured WAF Rules

  • Preconfigured rules are complex WAF rules with dozens of signatures compiled from open source industry standards.
  • Help protect web applications from common attacks and mitigate the OWASP Top 10 risks.
  • Rule source is OWASP ModSecurity Core Rule Set (CRS) 4.22.
  • Can inspect up to the first 64 KB of request body content (configurable: 8 KB, 16 KB, 32 KB, 48 KB, or 64 KB) – GA as of Feb 2026.
  • Preconfigured rules can be tuned to disable noisy or unnecessary signatures.
  • Note: XML body parsing is not supported by Cloud Armor preconfigured WAF rules.

Rate Limiting

  • Rate limiting helps protect applications from a large volume of requests that could flood instances and block legitimate users.
  • Supports throttle action (rate limits requests per client) and rate-based ban action (temporarily bans clients exceeding a threshold).
  • Supports granular rate limiting with the ability to combine multiple keys.
  • Rate limiting keys include: IP address, HTTP headers, HTTP cookies, XFF IP, region code, ASN, JA4 fingerprint (GA June 2025).
  • Also supports internal service security policies for service mesh with global server-side rate limiting per client (Preview, July 2025).

Bot Management

  • Cloud Armor integrates natively with reCAPTCHA Enterprise for bot management.
  • Provides automated protection for applications from bots and helps stop fraud inline and at the edge.
  • Based on reCAPTCHA token attributes, Cloud Armor can allow, deny, rate-limit, or redirect incoming requests.
  • Helps detect and mitigate automated threats without impacting legitimate users.

Adaptive Protection

  • Adaptive Protection helps protect applications and services from L7 distributed DDoS attacks by analyzing patterns of traffic to backend services.
  • Detects and alerts on suspected attacks, and generates suggested WAF rules to mitigate such attacks.
  • Can be enabled on a per-security policy basis.
  • Granular models for Adaptive Protection are GA (July 2024), allowing more precise detection.
  • Cloud Armor Standard: alerting only. Cloud Armor Enterprise: full Adaptive Protection capabilities with automatic rule suggestions.
  • Supports automatic deployment of suggested rules.

Hierarchical Security Policies

  • Hierarchical security policies extend Cloud Armor WAF and DDoS protection beyond individual projects (GA October 2025).
  • Can be attached at the organization, folder, or project level.
  • Facilitate centralized control, enhanced consistency, operational efficiency, and effective delegation of security policy management.
  • Require Cloud Armor Enterprise enrollment for all projects that inherit the policy.
  • Support organization-scoped address groups (GA September 2025).

Advanced Network DDoS Protection

  • Available only to Cloud Armor Enterprise subscribers.
  • Provides additional protections for workloads using external passthrough Network Load Balancers, protocol forwarding, or VMs with public IP addresses.
  • Provides always-on attack monitoring and alerting, targeted attack mitigations, and mitigation telemetry.

Google Threat Intelligence

  • Cloud Armor integrates with Google Threat Intelligence to allow or block traffic based on categories of threat intelligence data.
  • Available for global external Application Load Balancers and classic Application Load Balancers.
  • Also supported in globally scoped edge security policies for Media CDN (GA September 2025).
  • Requires Cloud Armor Enterprise.

How Google Cloud Armor Works

Google Cloud Armor

  • Cloud Armor provides always-on DDoS protection against network or protocol-based volumetric DDoS attacks for applications behind supported load balancers.
  • Cloud Armor’s DDoS protection is always-on inline, scaling to the capacity of Google’s global network.
  • Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
  • Cloud Armor security policies help allow or deny access at the Google Cloud edge, as close as possible to the source of incoming traffic.
  • Prevents unwelcome traffic from consuming resources or entering the VPC networks.
  • Backend services have access to security policies to enforce custom Layer 7 filtering policies, including pre-configured WAF rules.
  • Backends to the backend service can be:
    • VM instances in an instance group
    • Zonal network endpoint groups (zonal NEGs)
    • Internet network endpoint groups (internet NEGs)
    • Serverless NEGs
    • Hybrid connectivity NEGs
  • For hybrid or multi-cloud architectures, backends must be internet NEGs or hybrid connectivity NEGs.
  • Cloud Armor also protects serverless NEGs when traffic is routed through a load balancer.

Google Cloud Armor

GCP Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Your company offers a popular gaming service. Your instances are deployed with private IP addresses, and external access is granted through a global load balancer. You believe you have identified a potential malicious actor, but aren’t certain you have the correct client IP address. You want to identify this actor while minimizing disruption to your legitimate users. What should you do?
    1. Create a Cloud Armor Policy rule that denies traffic and review necessary logs.
    2. Create a Cloud Armor Policy rule that denies traffic, enable preview mode, and review necessary logs.
    3. Create a VPC Firewall rule that denies traffic, enable logging and set enforcement to disabled, and review necessary logs.
    4. Create a VPC Firewall rule that denies traffic, enable logging and set enforcement to enabled, and review necessary logs
  2. Your organization is experiencing a sudden spike in traffic to a web application behind a global external Application Load Balancer. Cloud Armor Adaptive Protection has detected a potential L7 DDoS attack and generated a suggested WAF rule. What should you do?
    1. Immediately apply the suggested rule in deny mode.
    2. Review the suggested rule, apply it in preview mode first, verify it targets attack traffic, then enable it.
    3. Disable the application until the attack subsides.
    4. Increase the number of backend instances to absorb the traffic.
  3. You need to protect multiple projects in your organization with a consistent set of Cloud Armor security policies. The security team wants centralized control while allowing individual project teams some flexibility. What should you use?
    1. Duplicate the same security policy in each project manually.
    2. Use a shared VPC with a single security policy.
    3. Use Cloud Armor hierarchical security policies at the organization or folder level.
    4. Create a Terraform module that deploys the same policy to all projects.
  4. You want to protect your Cloud CDN-enabled backend service from malicious requests before they are served from Google’s cache. Which type of Cloud Armor security policy should you use?
    1. Backend security policy (CLOUD_ARMOR)
    2. Edge security policy (CLOUD_ARMOR_EDGE)
    3. Network edge security policy
    4. Regional backend security policy
  5. Your company wants to rate-limit API requests to prevent abuse while allowing legitimate traffic. You need to limit requests per client based on a combination of IP address and a specific HTTP header. What Cloud Armor feature should you use?
    1. Preconfigured WAF rules
    2. Adaptive Protection
    3. Rate limiting with multiple keys (IP + HTTP header)
    4. Bot management with reCAPTCHA Enterprise
  6. You need advanced network DDoS protection for workloads behind an external passthrough Network Load Balancer. What is required?
    1. Cloud Armor Standard tier is sufficient.
    2. Attach a backend security policy to the NLB.
    3. Enroll the project in Cloud Armor Enterprise and enable advanced network DDoS protection for the region.
    4. Use Cloud Armor preconfigured WAF rules on the NLB.

References

GCP Professional Cloud Network Engineer Cert Path

Google Cloud - Professional Cloud Network Engineer Certification
~ Last updated on : ~ jayendrapatil

Google Cloud – Professional Cloud Network Engineer Certification Learning Path

📋 2025/2026 Exam Updates

  • Exam Restructured (April 24, 2025): The PCNE exam has been restructured and streamlined for greater focus and reduced repetition.
  • New Exam Delivery Provider (March 2026): Google Cloud certifications have transitioned from Kryterion to Pearson VUE for exam delivery.
  • New Topics Added: Cloud Next Generation Firewall (Cloud NGFW), Secure Web Proxy, Private Service Connect, Network Connectivity Center, and Cross-Cloud Interconnect are now explicitly covered.
  • Updated Load Balancing Naming: Google Cloud has updated load balancer names — HTTP(S) Load Balancer is now “Application Load Balancer,” TCP/SSL Proxy is now “proxy Network Load Balancer,” and Network LB is now “passthrough Network Load Balancer.”

Google Cloud – Professional Cloud Network Engineer certification exam focuses on the design, implementation, and management of Google Cloud network infrastructure. This includes designing network architectures for high availability, scalability, resiliency, and security.

Google Cloud – Professional Cloud Network Engineer Certification Summary

  • Has 50-60 questions to be answered in 2 hours.
  • Registration fee: $200 (plus tax where applicable)
  • Available in English and Japanese
  • Delivered through Pearson VUE — online-proctored or at a testing center
  • Covers a wide range of Google Cloud services mainly focusing on network services
  • Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using Google Cloud
  • Hands-on is a MUST — if you have not worked on GCP before, make sure you do lots of labs else you would be absolutely clueless for some of the questions and commands
  • The exam assesses your ability to:
    • Design and plan a Google Cloud Virtual Private Cloud (VPC) network
    • Implement a VPC network
    • Configure managed network services
    • Configure and implement hybrid and multi-cloud network interconnectivity
    • Manage, monitor, and troubleshoot network operations
    • Configure, implement, and manage a cloud network security solution

Google Cloud – Professional Cloud Network Engineer Certification Resources

Google Cloud – Professional Cloud Network Engineer Certification Topics

Network Services

  • Refer Google Cloud Networking Services Cheat Sheet
  • Virtual Private Cloud
    • Understand Virtual Private Cloud (VPC), subnets, and host applications within them
    • VPC Routes determine the next hop for the traffic. HINT: It can be defined for specific tags as well. More specific takes priority.
    • Firewall rules control the traffic to and from instances. HINT: Rules with lower integers indicate higher priorities. Firewall rules can be applied to specific tags or service accounts.
    • Cloud Next Generation Firewall (Cloud NGFW) — The modern firewall management framework that includes:
      • Hierarchical firewall policies — Applied at organization and folder levels for consistent enforcement across multiple VPC networks
      • Network firewall policies — Applied at VPC network level, replacing legacy VPC firewall rules
      • Cloud NGFW Enterprise (powered by Palo Alto Networks) — Provides intrusion detection/prevention (IDS/IPS) and TLS inspection
      • HINT: Understand the evaluation order — Hierarchical policies → Network policies → VPC firewall rules. “goto_next” action delegates to the next level.
    • VPC Peering allows internal or private IP address connectivity across two VPC networks regardless of whether they belong to the same project or the same organization. HINT: VPC Peering uses private IPs and does not support transitive peering
    • Shared VPC allows an organization to connect resources from multiple projects to a common VPC network so that they can communicate with each other securely and efficiently using internal IPs from that network HINT: VLAN attachments and Cloud Routers for Interconnect must be created in the host project
    • Understand the concept of internal and external IPs and the difference between static and ephemeral IPs
    • VPC Subnets support primary and secondary (alias) IP range
    • Primary IP range of an existing subnet can be expanded by modifying its subnet mask, setting the prefix length to a smaller number.
    • Private Access options for services allow instances with internal IP addresses to communicate with Google APIs and services.
    • Private Google Access allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface. HINT: Private Google Access is enabled on the subnet and not on the VPC level
    • Private Service Connect — Allows consumers to access managed services privately from inside their VPC network using an internal IP endpoint. Supports accessing Google APIs, published services, and third-party services (e.g., Elastic, MongoDB, Snowflake). HINT: PSC provides an alternative to VPC peering with better security isolation and no shared scaling dependencies.
    • VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.
    • Firewall Rules Logging enables auditing, verifying, and analyzing the effects of the firewall rules HINT: Default implicit ingress deny rule is not captured by firewall rules logging. Add an explicit deny rule
    • Resources within a VPC network can communicate with one another by using internal IPv4 addresses
    • IPv6 Support — VPC networks and subnets support dual-stack (IPv4 and IPv6) configuration. Understand internal IPv6 (ULA) and external IPv6 (GUA) addressing.
  • Hybrid Connectivity
  • Cloud VPN
    • Cloud VPN provides secure connectivity from the on-premises data center to the GCP network through the public internet. Cloud VPN does not provide internal or private IP connectivity
    • Understand what are the requirements to setup Cloud VPN.
    • Cloud VPN is quick to setup and test hybrid connectivity
    • Understand limitations of Cloud VPN esp. 3Gbps limit per tunnel. How it can be improved with multiple tunnels.
    • Cloud VPN requires non overlapping primary and secondary IPs address between on-premises and GCP VPC networks
    • Cloud VPN HA provides a highly available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
    • HA VPN IPv6 Support — HA VPN now supports dual-stack (IPv4_IPV6) and IPv6-only gateway types. Multiprotocol BGP (MP-BGP) enables exchanging IPv6 routes over IPv4 BGP sessions and vice versa.
    • Classic VPN Dynamic Routing Deprecation (August 1, 2025): BGP/dynamic routing for Classic VPN tunnels is deprecated. If your workloads require BGP for VPN connectivity, you must use HA VPN. Classic VPN only supports policy-based and route-based (static) configurations going forward.
  • Cloud Interconnect
    • Cloud Interconnect provides direct connectivity from the on-premises data center to GCP network
    • Dedicated Interconnect provides a direct physical connection between the on-premises network and Google’s network. Supports 10 Gbps or 100 Gbps connections (400G announced at Cloud Next ’25 for AI workloads)
    • Partner Interconnect provides connectivity between the on-premises and VPC networks through a supported service provider. Supports 50Mbps to 50 Gbps
    • Understand Dedicated Interconnect vs Partner Interconnect and when to choose
    • Know Interconnect as the reliable high speed, low latency, and dedicated bandwidth option.
    • Cloud Monitoring monitors interconnect links. Circuit Operational Status metric threshold tracks the circuits while Interconnect Operational Status metric tracks all the links
    • Cross-Cloud Interconnect — Provides high-bandwidth dedicated connectivity between Google Cloud and another cloud provider (AWS, Azure, Oracle Cloud). Enables building multicloud architectures with private, SLA-backed connections. HINT: Use Cross-Cloud Interconnect for multicloud connectivity; use Dedicated/Partner Interconnect for on-premises connectivity.
    • Cross-Site Interconnect (GA) — Transparent, on-demand Layer 2 connectivity between on-premises sites leveraging Google’s global infrastructure.
  • Cloud Router
    • Cloud Router provides dynamic routing using BGP with HA VPN and Cloud Interconnect
    • Cloud Router Global routing mode provides visibility to resources in all regions
    • Cloud Router uses Multi-exit Discriminator (MED) value to route traffic. The same MED value results in Active/Active connection and different MED results in Active/Passive connection
    • Supports Multiprotocol BGP (MP-BGP) for exchanging IPv4 and IPv6 routes over a single BGP session
  • Network Connectivity Center
    • Network Connectivity Center (NCC) provides a hub-and-spoke model for network connectivity management in Google Cloud
    • Supports VPC spokes for inter-VPC connectivity without needing VPC peering
    • Supports hybrid spokes (Cloud VPN, Interconnect VLAN attachments, Router appliances) for connecting on-premises and other cloud networks
    • Enables using Google’s network as a wide area network (WAN) for data transfer between on-premises or multi-cloud sites
    • HINT: NCC provides transitive connectivity through the hub, overcoming VPC peering’s non-transitive limitation
  • Cloud NAT
    • Cloud NAT allows VM instances without external IP addresses and private GKE clusters to send outbound packets to the internet and receive any corresponding established inbound response packets.
    • Requests would not be routed through Cloud NAT if they have an external IP address
  • Cloud Peering
    • Google Cloud Peering provides Direct Peering and Carrier Peering
    • Peering provides a direct path from the on-premises network to Google services, including Google Cloud products that can be exposed through one or more public IP addresses — does not provide a private dedicated connection
  • Cloud Load Balancing
    • Google Cloud Load Balancing provides scaling, high availability, and traffic management for your internet-facing and private applications.
    • Understand Google Load Balancing options and their use cases — which is global/regional, external/internal, and what protocols they support.
    • Updated Load Balancer Naming (2023+):
      • Application Load Balancer (formerly HTTP(S) Load Balancer) — Layer 7, supports HTTP/HTTPS/HTTP2/HTTP3(QUIC)
        • Global external Application Load Balancer
        • Regional external Application Load Balancer
        • Cross-region internal Application Load Balancer
        • Regional internal Application Load Balancer
      • Proxy Network Load Balancer (formerly TCP/SSL Proxy Load Balancer) — Layer 4 proxy
        • Global external proxy Network Load Balancer
        • Regional external proxy Network Load Balancer
        • Cross-region internal proxy Network Load Balancer
        • Regional internal proxy Network Load Balancer
      • Passthrough Network Load Balancer (formerly Network Load Balancer / Internal TCP/UDP LB) — Layer 4, pass-through
        • External passthrough Network Load Balancer — regional, external
        • Internal passthrough Network Load Balancer — regional, internal
    • Cloud Load Balancing supports health checks with managed instance groups
  • Cloud CDN
    • Understand Cloud CDN as the global content delivery network
    • Know CDN works with global external Application Load Balancer (formerly HTTP(S) LB)
    • Media CDN — Optimized for large-scale media delivery (video streaming, gaming downloads). Separate from Cloud CDN.
    • Cache is not removed if the underlying origin data is removed. Cache has to be invalidated explicitly, or is removed once expired.
    • Cloud CDN does not compress but serves response from the origin as is. HINT: As LB adds Via header some web server do not compress response and must be configured to ignore the Via header
  • Cloud DNS
    • Understand Cloud DNS and its features
    • Supports migration or importing of records from on-premises using JSON/YAML format
    • Supports DNSSEC, a feature of DNS, that authenticates responses to domain name lookups and protects the domains from spoofing and cache poisoning attacks
    • Supports DNS routing policies (weighted round-robin, geolocation, failover)

Identity Services

  • Cloud Identity and Access Management
    • Identify and Access Management – IAM provides administrators the ability to manage cloud resources centrally by controlling who can take what action on specific resources.
    • Compute Network Admin does not provide access to SSL certificates and firewall rules. Need to assign Security Admin role
    • Understand IAM-governed tags for firewall policy rules (replacing network tags for newer policies)

Compute Services

  • Compute services like Google Compute Engine and Google Kubernetes Engine are lightly covered more from the networking aspects
  • Google Compute Engine
    • Google Compute Engine is the best IaaS option for compute and provides fine grained control
    • Difference between managed vs unmanaged instance groups and auto-healing feature
    • Regional Managed Instance group helps spread load across instances in multiple zones within the same region providing scalability and HA
    • Managed Instance group helps perform canary and rolling updates
    • Managed Instance group autoscaling can be configured on CPU or load balancer metrics or custom metrics.
    • Managing access using OS Login or project and instance metadata
  • Google Kubernetes Engine
    • Google Kubernetes Engine, powered by the open-source container scheduler Kubernetes, enables you to run containers on Google Cloud Platform.
    • Understand GKE Networking in detail
    • Understand GKE Cluster types based on networking — VPC-Native clusters (recommended, uses alias IPs) vs Routes-based clusters (legacy)
    • Understand GKE VPC-Native cluster IP Allocation
    • Private clusters help isolate nodes from having inbound and outbound connectivity to the public internet by providing nodes with internal IP addresses only.
    • GKE Dataplane V2 — eBPF-based dataplane providing better network policy enforcement, observability, and performance

Security Services

  • Cloud Armor
    • Cloud Armor protects applications from multiple types of threats, including DDoS attacks and application attacks like XSS and SQLi
    • Cloud Armor Enterprise (formerly Managed Protection Plus) — Provides advanced DDoS protection, Adaptive Protection, threat intelligence, and bot management with insurance-backed DDoS protection
    • Adaptive Protection — ML-based detection of L7 DDoS attacks that automatically suggests and can auto-deploy mitigation rules
    • Works with global external Application Load Balancer; with GKE needs to be configured with GKE Ingress
    • Can be used to block/allow IPs, geolocation-based access control, rate limiting, and bot management
    • Supports preview mode to understand patterns without blocking the users
    • Supports preconfigured WAF rules for OWASP Top 10
    • Google Threat Intelligence integration for IP reputation feeds
  • Secure Web Proxy
    • Secure Web Proxy is a cloud-first, secure web gateway that helps monitor and secure egress web traffic (HTTP/HTTPS)
    • Provides URL filtering, TLS inspection, and logging for outbound traffic from VMs and GKE pods
    • Replaces the need for third-party proxy appliances for egress filtering
    • HINT: Secure Web Proxy is for egress traffic control; Cloud Armor is for ingress traffic protection
  • VPC Service Controls
    • Creates security perimeters around Google Cloud resources to mitigate data exfiltration risks
    • Restricts access to Google Cloud services and resources within defined perimeters
    • HINT: VPC Service Controls protect against data exfiltration from Google Cloud services, not network-level traffic

Network Monitoring and Operations

  • Network Intelligence Center
    • Provides a comprehensive network monitoring, verification, and optimization platform
    • Connectivity Tests — Diagnoses connectivity issues between source and destination endpoints
    • Performance Dashboard — Monitors network performance metrics (latency, packet loss) across Google Cloud
    • Network Topology — Visualizes the network infrastructure and traffic flows
    • Firewall Insights — Identifies overly permissive or shadowed firewall rules
  • Cloud Logging and Monitoring
    • VPC Flow Logs, Firewall Rules Logging, Cloud NAT logs, and DNS logs for network troubleshooting
    • Cloud Monitoring for setting up alerts on network metrics

All the Best !!