GCP Security Engineer key terms

A guardrail set at the organization, folder, or project level that restricts how resources can be configured, such as blocking public bucket access or limiting allowed locations. It applies regardless of IAM permissions, so even owners cannot override it within the enforced scope.

The binding document attached to a resource that maps principals to roles and is evaluated to grant access. It is additive; a principal gains the union of permissions from every binding that matches, and deny policies can subtract from that union.

A policy that explicitly blocks specified permissions for principals, evaluated before allow policies and taking precedence over any grant. It is typically managed centrally by an admin and can carry exception principals that remain unaffected by the denial.

A policy that limits which resources a principal can access, regardless of roles granted elsewhere. It narrows the effective scope of a workforce identity, helping contain the blast radius of compromised or overly broad credentials across an organization.

The act of obtaining short-lived credentials for a service account by calling the generateAccessToken or generateIdToken method, authorized through the roles/iam.serviceAccountTokenCreator role. It avoids distributing long-lived keys and is logged as the impersonating principal.

A mechanism that lets external workloads, such as those on AWS, Azure, or GitHub, exchange their native credentials for short-lived Google Cloud tokens without a service account key. Trust is configured through a workload identity pool and provider.

A rule on a workload identity pool provider that restricts which external tokens are accepted, based on claims such as repository, branch, or subject. It prevents any workload in the external system from exchanging its token for Google Cloud access.

A downloadable public/private key pair that authenticates as a service account. Keys are long-lived, easily leaked, and hard to rotate at scale; organization policy can disable their creation, and Google recommends federation or impersonation instead.

A role you define yourself, listing specific permissions to grant least privilege when predefined roles are too broad. It can be created at project or organization level, and its permissions must be contained in the set the creator is allowed to grant.

A Google-managed role, such as roles/storage.objectViewer, whose permission set is maintained and updated by Google. Predefined roles are the default choice for granting access and are usually preferred over basic roles for least privilege.

One of the original coarse roles: Owner, Editor, or Viewer. They grant very broad permissions across a project, including many not needed for a task, so security guidance restricts their use to narrow cases such as billing administration.

A single entry in an IAM allow policy that associates one or more principals with one role, optionally limited by an IAM condition. Multiple bindings accumulate, so auditing effective access means reviewing every binding on the resource and its ancestors.

A CEL expression attached to a role binding that grants access only when attributes such as request time, resource name, or access level match. It enables time-bound or resource-scoped access within a single binding.

A reusable rule in Access Context Manager describing request attributes like IP range, device state, or user identity. Access levels are referenced by IAM conditions and by VPC Service Controls perimeter rules to decide whether a request is trusted.

The service where you define access levels and service perimeters used for context-aware access and VPC Service Controls. It provides the building blocks that other enforcement points reference when deciding whether a request is allowed.

A security boundary that surrounds Google Cloud services and their data, blocking access from outside the perimeter even when IAM would otherwise allow it. It mitigates data exfiltration and is configured through service perimeters and access levels.

The boundary defined by VPC Service Controls that encloses specified projects and restricts which services and networks can reach the protected resources. Traffic crossing the boundary is denied unless explicitly permitted by ingress or egress rules.

A VPC Service Controls rule that allows specified identities, sources, or access levels from outside a service perimeter to reach resources inside it. Without a matching ingress rule, cross-boundary requests are denied by default.

A VPC Service Controls rule that permits resources inside a service perimeter to reach specified external destinations or identities. It is used sparingly because it widens the exfiltration path the perimeter is meant to close.

A configuration where a host project owns subnets and a central network team manages them, while service projects attach their resources to those subnets. It centralizes network policy and firewall control across many projects.

A rule that permits or denies traffic to or from VM instances based on direction, priority, protocol, port, and source or destination. Rules are stateful and evaluated by priority, with the first matching rule deciding the outcome.

A firewall policy attached at organization or folder level that is evaluated before VPC firewall rules and can enforce consistent rules across many projects. It supports delegation so folder admins can add rules without changing the parent policy.

A policy applied to a load balancer backend that filters HTTP traffic using IP allow and deny lists, geo-based rules, and preconfigured WAF rules for threats such as SQL injection. It also supports rate limiting and bot management.

A service that enforces identity and context checks on requests to applications and VMs before traffic reaches them, using IAM roles and access levels. It enables zero-trust access to internal apps without exposing them to the public internet.

A mechanism to privately reach Google APIs or producer services through an internal IP endpoint inside your VPC, without public internet exposure or peering. It gives consumers a private endpoint while producers keep control of published services.

A subnet setting that lets VMs without external IP addresses reach Google APIs and services through internal routing. It avoids exposing instances to the internet while still allowing calls to Cloud Storage and other APIs.

A logical grouping of cryptographic keys in Cloud Key Management Service, tied to a location. Key rings organize keys for management and IAM, and keys within them can be rotated without changing the ring.

An encryption key you create and control in Cloud KMS, used to encrypt data in supported services instead of Google-managed keys. You control its IAM policy, rotation, and lifecycle, including disabling or destroying it.

Cloud External Key Manager, which keeps key material in a third-party external key manager while Google Cloud uses the key through a registered external key. It supports separation of duties and external control over key material.

A Cloud KMS key protection level where key material is stored in hardware security modules that are FIPS 140-2 Level 3 validated. It is chosen for workloads requiring hardware-backed key protection within Google Cloud.

The scheduled replacement of a key's backing material while retaining older versions for decryption. Rotation limits the data exposed if a key version leaks and is configured with a rotation period on the key.

A service for storing, versioning, and accessing sensitive values such as API keys and passwords, with IAM-controlled access and audit logging. Applications retrieve secrets at runtime instead of embedding them in code or config.

An immutable revision of a secret's value in Secret Manager. Adding a new version lets you rotate credentials while keeping prior versions available for rollback, and access can be granted per version.

The practice of labeling data by sensitivity, such as public, internal, confidential, or restricted, so controls like encryption, access, and retention can be applied consistently. It underpins decisions about where data may reside and who may read it.

A service that discovers, classifies, and de-identifies sensitive data such as personal information using built-in or custom infoTypes. It can scan storage and streams, and its findings support compliance reporting and masking workflows.

A detector in Sensitive Data Protection that identifies a category of sensitive data, such as email addresses, credit card numbers, or custom patterns. InfoTypes drive discovery findings and de-identification transformations.

Logs recording administrative activity, data access, system events, and policy denials across Google Cloud. Admin Activity logs are always on, while Data Access logs are often disabled by default and must be enabled per service.

An audit log recording reads and writes of user data, such as object reads or row fetches. It is disabled by default because of volume and cost, so enabling it selectively is a common exam decision.

A configuration that routes matching log entries from a project, folder, or organization to a destination such as Cloud Storage, BigQuery, or Pub/Sub. Organization-level sinks aggregate logs centrally for retention and analysis.

A storage container in Cloud Logging that holds log entries for a defined retention period and location. Buckets can be locked to prevent deletion or modification, supporting immutable retention for compliance.

The central dashboard for security findings, misconfigurations, and vulnerabilities across an organization. Findings from built-in detectors and partner tools are aggregated, prioritized, and can drive automated remediation.

A Security Command Center detector that scans resources for misconfigurations and policy violations, such as public buckets or open firewall rules. Findings include severity and remediation guidance.

A Security Command Center capability that analyzes audit and system logs for suspicious activity, such as anomalous IAM grants or malware signals. It produces findings that security teams triage alongside misconfiguration findings.

A service that applies controls, such as data residency and personnel access restrictions, to a folder to help meet regulatory frameworks. It enforces constraints automatically and monitors the folder for drift.

A published standard or regulation, such as PCI DSS, HIPAA, or ISO 27001, that defines controls an organization must satisfy. Google publishes mappings and audit reports so customers can inherit and evidence relevant controls.

A third-party audit document, available through Compliance Reports Manager, describing how Google Cloud meets a framework's controls. Customers use these reports as evidence in their own audits rather than testing Google's infrastructure directly.

The requirement that data be stored and processed in specified geographic locations. It is enforced through location constraints in organization policy and through Assured Workloads, which limits where resources can be created.

The principle that data is subject to the laws and governance of the jurisdiction where it resides. It goes beyond location by considering who can access the data, which drives choices like Cloud EKM and Assured Workloads.

The root of the Google Cloud resource hierarchy, above folders and projects, where organization policies, IAM, and log sinks can be applied to inherit down. It typically maps to a company's identity domain.

The principle of granting only the permissions needed for a task, for the shortest time, to reduce the impact of mistakes or compromise. It is implemented through predefined or custom roles, conditions, and short-lived credentials.

Tokens with a limited lifetime, such as OAuth access tokens from impersonation or federation, rather than permanent keys. They reduce exposure because a leaked token expires quickly and is tied to an audited exchange.