Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Gauge your current knowledge
Gauge your current knowledge
Identity and Access Management (IAM) is the framework that controls who can take action on specific Google Cloud resources. The principle of least privilege is a core security concept: users receive only the minimum permissions needed to do their jobs. This reduces the risk of accidental changes or security breaches.
Google Cloud provides three types of roles to manage permissions. Primitive roles like Owner, Editor, and Viewer offer broad, project-wide permissions that are often too powerful for daily tasks. Instead, administrators should use predefined roles, which give granular access to specific services, or custom roles that bundle exactly the permissions a team needs. Custom roles are useful when no predefined role matches a unique business requirement.
The resource hierarchy determines how permissions are applied and inherited. Access can be granted at the organization, folder, or project level, and these permissions flow down to all child resources. To enforce least privilege, grant access at the lowest possible level, such as a specific Cloud Run service or an Artifact Registry repository. Service accounts are special identities for applications and automated systems. Using conditional role bindings can restrict these accounts further, allowing actions only when specific criteria, like resource names or attributes, are met. The Policy Analyzer helps administrators search through allow policies to understand which principals have access to which resources, making it easier to identify and remove unnecessary permissions.
The Google Cloud resource hierarchy organizes cloud assets like a file system. It starts with the Organization node at the top, followed by Folders, Projects, and finally individual Resources. This structure provides a clear chain of ownership and is the foundation for applying security policies across an enterprise. By binding the lifecycle of a resource to its parent, administrators keep security settings consistent as the environment grows.
Policy inheritance means security settings applied at a higher level automatically flow down to all child resources. The effective policy for any resource is the union of permissions granted directly to it and those inherited from its ancestors. Permissions are additive, so a user gains all rights granted at every level. This allows broad access control at the folder level while maintaining specific rules for individual projects. The Organization Policy Service enforces specific configurations across the hierarchy using constraints. These constraints set global guardrails, such as domain-restricted sharing, which limits which external identities can be granted access. Organization policies are also inherited by descendants but can be superseded by more specific rules at lower levels when necessary.
To implement the principle of least privilege, administrators must carefully place IAM roles within the hierarchy. While allow policies grant permissions, deny policies can explicitly prevent certain actions regardless of any other granted roles. Deny policies are always evaluated before allow policies, providing a powerful tool for strict security. Best practices include using a single organization node to reduce management overhead, implementing standardized naming conventions, and keeping bootstrapping resources in separate folders. Administrators should also use folders to segregate environments: Production for live workloads, Staging for testing, and Development for experimentation.
Service accounts are non-human accounts used by applications and virtual machines to access Google Cloud resources. Default service accounts should be avoided because they often have broad permissions that increase risk. Instead, developers should create custom service accounts tailored to specific tasks and workloads.
Applying the principle of least privilege to non-human identities means granting only the permissions a service needs to function. Administrators should use custom IAM roles instead of broad basic roles like "Editor," regularly identify and remove unused service accounts, and use IAM tags to conditionally allow or deny access based on resource labels. Managing service account keys is a major challenge because they are long-lived credentials that can be leaked. Organizations should require regular key rotation and monitor for unauthorized usage. Whenever possible, use short-lived credentials or service account impersonation to avoid the dangers of static keys.
For containerized environments, Workload Identity for GKE provides the most secure way to manage non-human identities. This feature links Kubernetes service accounts to Google Cloud service accounts, allowing applications to authenticate automatically without storing keys inside container images or as Kubernetes secrets. Finally, organization policies help enforce security standards, such as disabling the creation of new service account keys, and Cloud Audit Logs ensure all actions taken by these accounts are recorded for monitoring and incident response.
The Google Cloud resource hierarchy starts with an organization at the root, followed by folders and projects. By applying rules at different levels, administrators can set consistent security guardrails across their entire company. The Organization Policy Service provides centralized control using constraints, which are specific restrictions on Google Cloud services. Administrators use Google’s built-in managed constraints or create custom constraints for finer control. These policies help prevent misconfigurations and control costs by limiting actions, such as restricting where resources can be created.
A key feature is policy inheritance, where rules applied at a higher level automatically flow down to all child resources. While lower levels inherit these rules, administrators can override them if needed. The final effective policy on any resource combines its own settings with those inherited from its ancestors. To manage these policies, a user needs the Organization Policy Administrator role at the organization level.
The Google Cloud resource hierarchy organizes resources into a tree: the Organization is the top-level root representing a company. Folders are optional groupings below the organization, useful for representing departments or environments. Projects sit at the base and are required to use any Google Cloud service, containing resources like storage buckets. Identity and Access Management (IAM) policies flow down this hierarchy. A role granted at the organization level applies to every folder and project within it. The effective policy for a resource combines permissions granted directly to it and permissions inherited from its ancestors. This allows centralized control but requires careful design to follow the principle of least privilege, granting roles at the lowest possible level.
Best practices include using a single organization node to maintain central visibility, creating separate "bootstrap" folders for management tools, and using standardized naming conventions across all resources to simplify management.
The Organization is the root node created by linking a domain through Cloud Identity or Google Workspace. It provides centralized visibility and control over all resources. Folders and Projects are the main tools for grouping and isolating resources. Folders are optional and can contain other folders or projects, making them ideal for separating business units or environments like Production and Development. Projects are mandatory containers where service resources are created and run.
Policy Inheritance means security rules, including IAM allow policies and Organization policies, applied at a higher level automatically apply to all child resources. Deny policies can be used at lower levels to create specific exceptions. Designing for Administrative Isolation uses folders to create logical boundaries, such as separate folders for different teams or environments. This allows granting specific administrative roles without giving access to everything else. Billing is managed by linking projects to Cloud Billing accounts, and using Labels (key-value pairs) on resources allows granular cost tracking across departments.
Google Cloud automatically protects data at rest using default encryption with the AES-256 algorithm. This applies at multiple layers, including the infrastructure, storage device, and backup levels. To manage encryption at scale, Google uses envelope encryption, where a Data Encryption Key (DEK) encrypts each chunk of data and a Key Encryption Key (KEK) encrypts the DEK. Storing the encrypted DEK near the data keeps latency low while the central KEKs remain securely managed in a protected repository.
For organizations that need more control, Customer-Managed Encryption Keys (CMEK) allow you to manage your own keys through Cloud Key Management Service (KMS). This gives you control over the key lifecycle, including rotation and destruction. Key benefits include administrative control over rotation schedules and access policies, auditing of key usage, and compliance with regulations that require customer key ownership. Customer-Supplied Encryption Keys (CSEK) let you provide your own raw keys for services like Compute Engine, offering the highest level of control but placing a heavy administrative burden because Google does not store these keys. Many organizations now use Cloud External Key Manager (EKM) to keep keys in a third-party system outside Google Cloud while maintaining better availability.
Google protects data in transit using mutual authentication and encrypted internal communications. Short-lived tickets prove that a service is acting on behalf of a specific user. Choosing the right encryption strategy depends on balancing operational efficiency with compliance needs. Default encryption works for a fully managed service with no extra cost, while CMEK and CSEK are essential for businesses that must legally prove exclusive control over their cryptographic material.
Cloud Key Management Service (Cloud KMS) is the central tool for managing cryptographic keys across Google Cloud. It handles the entire key lifecycle: Key Creation generates new cryptographic material within a specific location, Automated Rotation periodically creates new key versions to reduce risk, and Key Retirement disables or destroys keys that are no longer in use. Properly managing these stages prevents long-term exposure if a single key version is compromised.
Identity and Access Management (IAM) enforces the principle of least privilege by granting specific roles at the key or key ring level. For example, the Cloud KMS Admin role allows key maintenance, while the CryptoKey Encrypter/Decrypter role is strictly for using the keys. Key Access Justifications adds an extra layer of security by requiring a reason code for every key access request. This works with Access Approval to give organizations full visibility and control over when and why their data is decrypted. For sensitive items like passwords or API keys, Google recommends using Secret Manager instead of Cloud KMS, choosing the right tool for the specific type of sensitive information.
Secret Manager is a centralized service for storing and managing sensitive information like API keys, passwords, and certificates. By using this tool, organizations decouple sensitive configuration from application source code, keeping credentials out of version control systems. This makes it easier to manage, audit, and secure sensitive metadata across different cloud environments. Secret Manager uses envelope encryption, with a Data Encryption Key (DEK) encrypted by a Key Encryption Key (KEK) managed through Cloud KMS.
Controlling who can see secrets is handled through IAM and the Principle of Least Privilege. Developers should avoid static keys and instead use Workload Identity or Service Accounts to gain programmatic access. Restricting access to the minimum necessary subset of secrets prevents unauthorized users from seeing sensitive data. Security experts recommend avoiding environment variables or local file systems to store secrets. Instead, applications should pull secrets directly from the Secret Manager API using official client libraries. Key administration tasks include Secret Rotation to periodically update credentials, Versioning to manage rollbacks, and Auditing to monitor access logs.
The Google Cloud resource hierarchy organizes cloud assets starting with the Organization at the top, followed by Folders and Projects. Rules and policies applied at higher levels are automatically inherited by all resources below them. Implementing a separation of duties ensures that no single user holds too much control. Security administrators assign specific IAM roles based on precise job functions to balance power and responsibility. For example, Organization Admins govern the overall structure, Folder Administrators manage specific departments, and Project Owners control application-level resources.
To keep sensitive data from leaving trusted networks, organizations deploy VPC Service Controls to establish a service perimeter around authorized projects. A single, unified perimeter reduces complexity. Organization policies apply constraints to restrict which services can be used, mandate Customer-Managed Encryption Keys (CMEK) , or disable external service account keys. For stronger enforcement, deny policies explicitly block certain actions even if an allow policy exists elsewhere. Administrators can also use just-in-time privileged access to grant temporary elevated permissions only when a specific task requires it.
Splitting responsibilities between Google Workspace administrators and Google Cloud administrators ensures that no single person possesses total control over the enterprise. Organizations should use pre-built administrative roles instead of broad super admin privileges and manage access via security groups rather than individual accounts. When critical changes must occur, multi-party authorization workflows mandate that sensitive actions receive independent validation from distinct authorized parties. Privileged Access Manager (PAM) acts as the primary tool to manage just-in-time elevation requests, which can also be automated using service accounts within DevOps pipelines.
Google Cloud generates comprehensive audit logs, specifically Admin Activity logs and Data Access logs. Security teams use Security Command Center to ingest these logs and detect anomalous behaviors, such as unexpected service account delegation chains. Event Threat Detection automatically scans log streams to identify potential breaches and instantly trigger alerts when highly privileged accounts are activated. During emergencies, teams rely on highly privileged breakglass access accounts that require split operations—two distinct people must provide credentials and multi-factor authentication tokens to unlock them. Access is temporary and automatically revoked.
Administrative isolation keeps high-level management tasks separate from daily operational duties. Organizations should limit the number of super admin accounts and restrict their use to rare, non-routine tasks. Administrators perform daily work using specific pre-built or custom roles, distributing critical responsibilities across separate identities. Enforcing the principle of least privilege relies on precise role granularity, restricting permissions to the smallest possible scope, such as a single project or resource. Security teams must regularly review GCP role recommendations to identify and strip away excessive or unused permissions. When temporary elevated access is required, Privileged Access Manager grants just-in-time access for a restricted duration based on a validated business justification.
Even with strict boundaries, organizations must plan for emergency scenarios by maintaining dedicated breakglass access accounts. These identities bypass standard workflows but remain under constant, strict monitoring and require multi-party approvals before activation. The system automatically triggers high-priority alerts the moment a breakglass account is used. Finally, protecting virtual machines requires isolating service accounts and managing OS Login. Restricting the creation of external service account keys ties administrative actions back to a user’s central identity, and enabling OS Login prevents metadata-based key abuse, ensuring every command is fully auditable.
Google Cloud provides a suite of security controls that work together to protect resources. Auditing is foundational: Cloud Audit Logs record every action taken on resources, with Admin Activity logs capturing configuration changes and Data Access logs tracking reads and modifications to data. Security teams use these logs with Security Command Center and Event Threat Detection to identify suspicious behavior.
VPC Service Controls create a service perimeter around authorized projects, preventing data exfiltration by blocking requests that originate from outside the perimeter. This is a key tool for protecting sensitive data in managed services like BigQuery and Cloud Storage. Context-aware access uses the Identity-Aware Proxy (IAP) and Access Context Manager to grant access based on user identity, device state, and location, rather than just network IP. Organization policy applies constraints across the resource hierarchy to enforce rules such as disabling service account key creation or requiring CMEK. Hierarchical firewall policies allow administrators to define firewall rules at the organization or folder level, which are then inherited by all projects and VPC networks below. This centralizes network security management and ensures consistent traffic control across the entire enterprise.
Cloud Key Management Service (Cloud KMS) is Google Cloud's central service for managing cryptographic keys. When organizations use Customer-Managed Encryption Keys (CMEK) , they control the key lifecycle through Cloud KMS rather than relying on Google’s default encryption. Administrators create key rings and keys within specific locations, set rotation schedules, and manage access using IAM roles at the key or key ring level. For example, the Cloud KMS Admin role allows key maintenance, while the CryptoKey Encrypter/Decrypter role is limited to encryption and decryption operations.
The key lifecycle includes creation, where cryptographic material is generated; rotation, where new key versions are automatically created on a schedule to limit the impact of a compromise; and retirement, where keys can be disabled or destroyed. Key Access Justifications require a reason code for every key access request, giving organizations visibility into why data is being decrypted. This feature integrates with Access Approval to provide explicit approval workflows. Cloud KMS supports envelope encryption, where a Data Encryption Key (DEK) encrypts data and a Key Encryption Key (KEK) encrypts the DEK. The DEK is stored near the data, while the KEK remains securely in Cloud KMS. This design keeps latency low and centralizes control over key material.
Secure remote access in Google Cloud moves beyond traditional VPNs by using identity-based controls. Identity-Aware Proxy (IAP) verifies a user's identity and context before granting access to applications and VMs. Instead of opening network ports, IAP acts as a gatekeeper that validates credentials and device attributes. This allows organizations to provide secure remote access without exposing resources to the public internet. Chrome Enterprise Premium extends these capabilities by adding endpoint verification and data loss prevention through the Chrome browser.
Service account impersonation lets a user or application temporarily act as a service account to perform a task. This avoids the need to share long-lived service account keys. Instead, the impersonator obtains short-lived tokens through IAM, which reduces the risk of credential leakage. Workload Identity Federation allows workloads running outside Google Cloud—such as on-premises or in another cloud—to authenticate without storing service account keys. It exchanges tokens from an external identity provider for Google Cloud tokens, enabling secure access across hybrid environments. These techniques together ensure that access is granted based on verified identity and context, not static network perimeters.
Securing the software supply chain means protecting every step from code development to production deployment. Google Cloud provides tools to ensure that only trusted, verified code reaches production. Artifact Registry stores container images and other artifacts with built-in vulnerability scanning. Binary Authorization enforces that only images signed by trusted authorities can be deployed to Google Kubernetes Engine (GKE) or Cloud Run. This creates a chain of trust from the developer to the running service.
Teams should integrate security into CI/CD pipelines using Cloud Build and Cloud Deploy. Pipeline steps can include static analysis, dependency scanning, and signing of artifacts. Assured Open Source Software provides verified packages for common dependencies, reducing the risk of compromised components. By combining these services, organizations can enforce policies such as requiring all images to be scanned and signed before deployment, and they can automatically block deployments that violate those policies. Audit logs record every action, providing a complete trail for compliance and incident response.
Securing AI workloads involves protecting the models themselves, the data they use, and the infrastructure they run on. Model Armor protects AI models from adversarial attacks and unauthorized extraction. It monitors model inputs and outputs to detect malicious requests that could alter behavior or leak proprietary information. Sensitive Data Protection (formerly DLP) helps organizations discover, classify, and de-identify sensitive data before it is used to train or serve models. This ensures compliance with privacy regulations and prevents exposure of personal or confidential information.
Secure model deployment requires strict access controls and encrypted communication. Models should be served through Vertex AI endpoints that are protected by IAM and VPC Service Controls. Only authorized applications and users should be able to invoke the model. Inputs and outputs should be logged for auditing, and model versions should be tracked to enable rollbacks if a security issue is discovered. By applying these controls, organizations can safely use AI while minimizing the risk of data leaks, model theft, or malicious manipulation.
Customer-Managed Encryption Keys (CMEK) give you control over your own encryption keys in Google Cloud, which is important for meeting security and compliance rules. You organize these keys into *…
Customer-Managed Encryption Keys (CMEK) give you control over your own encryption keys in Google Cloud, which is important for meeting security and compliance rules. You organize these keys into *…
Cloud Build is a managed service on Google Cloud that automates the software build process. It helps organizations reach higher SLSA (Supply-chain Levels for Software Artifacts) levels by prov…
Cloud Build is a managed service on Google Cloud that automates the software build process. It helps organizations reach higher SLSA (Supply-chain Levels for Software Artifacts) levels by prov…
Google Cloud automatically protects data at rest using default encryption, which requires no user setup. This encryption uses the AES-256 algorithm and applies at multiple layers, including the …
Google Cloud automatically protects data at rest using default encryption, which requires no user setup. This encryption uses the AES-256 algorithm and applies at multiple layers, including the …
VPC Service Controls creates a service perimeter, which is a security boundary around your projects and resources. Its main job is to prevent data exfiltration, meaning it stops sensitive data…
VPC Service Controls creates a service perimeter, which is a security boundary around your projects and resources. Its main job is to prevent data exfiltration, meaning it stops sensitive data…
The Google Cloud resource hierarchy is a structured way to manage resources, starting with an organization at the root. This hierarchy includes folders and projects, which act as containers …
The Google Cloud resource hierarchy is a structured way to manage resources, starting with an organization at the root. This hierarchy includes folders and projects, which act as containers …
The Google Cloud resource hierarchy organizes cloud assets starting with the Organization at the top, followed by Folders and Projects. Rules and policies applied at higher levels are …
The Google Cloud resource hierarchy organizes cloud assets starting with the Organization at the top, followed by Folders and Projects. Rules and policies applied at higher levels are …
Identity and Access Management (IAM) is a security framework that allows administrators to control who can take action on specific resources. The principle of least privilege is a core security …
Identity and Access Management (IAM) is a security framework that allows administrators to control who can take action on specific resources. The principle of least privilege is a core security …
Identity-Aware Proxy (IAP) serves as a central gatekeeper for applications and virtual machines in Google Cloud. It creates an identity-centric perimeter that checks a user's identity and the cont…
Identity-Aware Proxy (IAP) serves as a central gatekeeper for applications and virtual machines in Google Cloud. It creates an identity-centric perimeter that checks a user's identity and the cont…
Google Cloud automatically encrypts data at rest, but for more control, you can use Customer-Managed Encryption Keys (CMEK). These keys are managed through **Cloud Key Management Service (Cloud KM…
Google Cloud automatically encrypts data at rest, but for more control, you can use Customer-Managed Encryption Keys (CMEK). These keys are managed through **Cloud Key Management Service (Cloud KM…
StudyCerts
StudyCerts