Google Cloud Architect: Security Architecture

Security architecture is about 17.5% of the current Google Professional Cloud Architect exam, but security also appears throughout network, data, migration, implementation, and operations objectives. The dedicated domain covers IAM, resource hierarchy, key and secret management, separation of duties, auditing, VPC Service Controls, context-aware access, organization policy, hierarchical firewall policy, secure remote access, software supply chain security, and AI security.

The architect’s job is to make those controls reinforce one another. IAM should reflect the resource hierarchy. Network controls should reflect traffic intent. Keys and secrets should have separate ownership from application code. Audit evidence should be protected. Remote administration should not depend on unmanaged long-lived credentials. AI services should inherit the same identity, data, and monitoring discipline as the rest of the environment.

Cloud identity and access provides the foundation for roles and least privilege; Google Cloud security architecture then layers hierarchy, organization policy, network controls, data protection, and monitoring around that identity model.

Anchor security in the organization and project model

Organizations, folders, and projects are both management and trust structures. Use them to create clear ownership, policy inheritance, and separation between environments or workloads that should not share the same administrators. Projects are particularly useful as boundaries for APIs, billing, quotas, IAM, and lifecycle.

Landing-zone design embeds security guardrails in the foundation before projects multiply. Retrofitting hierarchy and policy after hundreds of projects exist is much harder than establishing repeatable project creation and shared-service patterns early.

Design IAM around least privilege and short-lived trust

Grant roles at the lowest practical scope, use groups for human access, and use service identities for workloads. Avoid persistent service-account keys when federation or managed identity patterns can provide short-lived credentials. Use impersonation and controlled elevation to reduce permanent administrative privilege.

The permission model should document who can modify IAM itself. A system is not least-privilege if many users can simply grant themselves broader access. High-impact role grants and policy changes deserve stronger approval and monitoring.

Use organization policy and firewall hierarchy as guardrails

Organization Policy constrains resource configuration, while IAM controls who can perform actions. Hierarchical firewall policy can apply network controls at organization or folder scope. These tools are powerful because they reduce dependence on every project team making the same correct decision.

Central guardrails should be specific and tested. A rule that blocks a legitimate deployment without a usable exception path encourages bypass. Model expected workload patterns, pilot the constraint, monitor violations, and make the exception owner and expiration visible.

Protect data with layered controls, not encryption slogans

Google Cloud encrypts data by default, but the exam guide expects deeper design decisions around Cloud KMS, customer-managed encryption keys, secret management, and data security. Determine when customer-managed keys are required, who administers them, what happens if a key is disabled, and how application identities gain permission to use them.

Secrets should not be hard-coded into source or deployment artifacts. Use managed secret storage and define rotation and access review. Separate the people who can administer keys or secrets from those who can change the protected workload when the risk model requires it.

Use perimeter and context controls where data sensitivity justifies them

VPC Service Controls can reduce data-exfiltration risk for supported services by creating service perimeters. Context-aware access can use additional context to make access decisions. These controls complement IAM rather than replace it, and they can disrupt legitimate service interactions if the architecture is not mapped carefully.

Document service-to-service dependencies, developer workflows, CI/CD, and support paths before enforcing a perimeter. Monitor denied requests and use a controlled exception process rather than broadening access whenever an integration fails.

Secure remote administration without broad network exposure

The guide names Identity-Aware Proxy, service-account impersonation, Chrome Enterprise Premium, and Workload Identity Federation as examples of secure remote access. The architectural principle is to authenticate and authorize the user or workload explicitly instead of exposing management surfaces to broad networks and relying on location alone.

Administrative paths should generate evidence: who accessed what, under which identity, with which privilege, and from which context. Break-glass access can exist, but it should be limited, monitored, and tested before the emergency.

Treat software supply chain and AI as security domains

Security does not end when infrastructure is provisioned. Build pipelines, artifact integrity, dependency provenance, deployment identity, and change approval affect whether trusted code reaches production. The current PCA guide also names Model Armor, Sensitive Data Protection, and secure model deployment, reflecting the growing AI attack and data-exposure surface.

For AI systems, map training or grounding data, prompt and tool access, model endpoints, secrets, user identity, and logging. An agent that can invoke enterprise tools needs explicit authorization boundaries and monitoring just like any other privileged application.

Audit for control effectiveness and recovery, not just compliance evidence

Cloud risk management highlights failure patterns that appear when controls exist only on paper. In Google Cloud, log administrative changes, protect the logs, review high-risk events, test access revocation, and verify that backup or recovery workflows still work when security controls are active.

Good security architecture is operable under pressure. Incident responders should know how to contain an identity, preserve evidence, rotate credentials or keys, and restore service without disabling every guardrail. Designing those actions in advance is part of the Professional Cloud Architect responsibility.

Security controls also need failure-mode design. If a key service, identity provider, policy engine, or security perimeter is unavailable or misconfigured, decide whether the workload should fail closed, degrade safely, or use an emergency path. Those decisions should be tested so operators do not discover during an incident that the only recovery procedure requires bypassing the control they are trying to preserve.

Compliance architecture starts with data classification and ownership. Before applying controls, identify which data is regulated, where it is allowed to reside, who can administer it, and which evidence auditors require. This prevents teams from applying the most restrictive controls everywhere while still missing the sensitive dataset that actually requires stronger protection.

Security telemetry should be routed and retained according to investigation needs. Administrative activity, identity changes, key use, network policy changes, workload alerts, and data-access events may have different retention and access requirements. Protect the evidence from unauthorized deletion or modification and make sure responders can query it without receiving unnecessary production privileges.

Supply-chain controls should extend from source to deployment. Protect repositories, build identities, artifact registries, provenance, and deployment permissions. A runtime with strong network and IAM controls can still be compromised if an attacker can introduce a malicious artifact through the delivery pipeline. Conversely, secure build provenance does not remove the need for runtime least privilege and monitoring.

Security review should include availability impact. A restrictive control that blocks a critical dependency can become an outage; an emergency bypass that is never tested can become an uncontrolled risk. Model how identity, key, perimeter, and network policies behave during failover and recovery so the organization can remain secure without making restoration impossible.

Architects should also set an exception budget. Repeated one-off exemptions are evidence that a baseline control or platform workflow does not fit actual workloads. Track exception categories, owners, expiration, and root cause. Where patterns repeat, improve the platform or create a supported pattern instead of permanently widening access around the control.

Network security architecture should make east-west as well as north-south traffic visible. Shared VPC, hierarchical firewall policy, private service access, and service perimeters can reduce exposure, but only if teams understand which workloads are allowed to communicate and why. Treat broad internal connectivity as a design decision, not a default trust zone.

Sensitive Data Protection and data-classification workflows can help identify where stronger controls are needed, but discovery should connect to action. Define how findings affect access, masking, retention, alerting, or migration decisions. Scanning without ownership and remediation produces inventory, not risk reduction.

Security architecture should include decommissioning. When a project, workload, or integration is retired, remove identities, keys, secrets, firewall rules, federation trust, data copies, DNS entries, and monitoring exceptions that no longer serve a purpose. Stale access paths are often less visible than active systems and therefore easier to forget.

Incident containment should be modeled by identity and resource boundary. Know whether responders can disable a compromised principal, isolate a project, restrict a service perimeter, rotate a key, or block a network path without taking unrelated workloads offline. Strong hierarchy and segmentation make containment more precise; flat privilege and shared projects make every emergency action broader and riskier.

Security controls should be represented in architecture decision records alongside their assumptions. If a design relies on a specific federation trust, perimeter rule, hierarchical firewall policy, customer-managed key, or audit-retention setting, record who owns it and what would invalidate the assumption. This keeps security from becoming invisible infrastructure that future teams accidentally bypass when they change the application.

Security architecture should be reviewed after organizational change as well as technical change. New subsidiaries, vendors, regions, and support models can alter trust boundaries even when the application diagram looks identical. Revalidate hierarchy, federation, data residency, and administrative scope when those business boundaries move.