Prepare and test your skills
Prepare and test your skills
Configuring network perimeter controls combines private certificates, distributed firewalls, identity checks, and edge load balancing into one enforcement chain. Traffic flows from internet clients to the edge, then through identity verification, then to network filtering on the destination workload. Each layer evaluates a different signal so a failure in one layer does not grant full access.
Certificate Authority Service (CA Service) is Google Cloud's managed private public key infrastructure (PKI) service for issuing, renewing, and revoking internal certificates. An administrator creates a root certificate authority (CA) and subordinate CAs, defines certificate templates for allowed domains and validity periods, and maintains revocation through certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) responders. Certificate Manager (opens in a new tab) requests certificates from a CA Service pool, stores them as certificate resources, and binds them to a load balancer target proxy through a certificate map.
A certificate map binds hostnames to certificates for the target proxy. During the Transport Layer Security (TLS) handshake, the load balancer selects the certificate whose map entry matches the client's requested hostname. Map entries take precedence over Compute Engine SSL certificates on the same proxy, and if no entry matches, the proxy presents the primary certificate defined in the map. Google-managed certificates renew automatically, while self-managed certificates require a monitored workflow of tracking expiry in Cloud Monitoring, generating a certificate signing request, submitting it to the CA, and rebinding the new certificate in one UpdateCertificateMapEntry call to avoid a gap.
Domain authorization controls how issuance proves control of a domain. Load balancer authorization needs no DNS change but requires the global load balancer to be publicly reachable on port 443 and does not support wildcards. DNS authorization requires adding a CNAME record but supports wildcard certificates, works behind a content delivery network (CDN) or on nonstandard ports, and can provision before cutover.
Exam tip: Wildcard certificates require DNS authorization; load balancer authorization does not support wildcards and requires internet access to the load balancer on port 443.
Cloud Next Generation Firewall (Cloud NGFW) (opens in a new tab) is distributed stateful filtering enforced on every virtual machine (VM) instance. Rules are organized in hierarchical firewall policies at the organization and folder levels and in global, regional, and Virtual Private Cloud (VPC) firewall rules at the network level. A rule targets VMs by Identity and Access Management (IAM)-governed Tags, service accounts, or network tags, so only VMs tagged frontend can reach VMs tagged backend without routing through a central appliance.
Design separates north-south traffic between the internet or on-premises and Google Cloud from east-west traffic between tiers inside Google Cloud. Three-tier designs place presentation, application, and data in separate segments and require firewall authorization for tier-to-tier flows to block lateral movement. Private-only VMs reach Google APIs through Private Service Connect or Private Google Access, and reach the internet through Secure Web Proxy for HTTP(S) with identity controls or through Cloud NAT otherwise. Identity-Aware Proxy (IAP) adds user and device verification on top of network reachability: IAP authenticates every user and device and authorizes by role, device posture, and location, while a firewall rule must still allow the IAP traffic path to reach the protected VM.
Secure delivery places the correct load balancer at the correct boundary and filters before traffic reaches backends. Global external Application Load Balancers handle HTTP, HTTPS, HTTP/2, and optionally QUIC for Layer 7 routing, while global external proxy Network Load Balancers handle TCP and SSL proxy traffic and regional passthrough Network Load Balancers handle TCP and UDP. In Premium Tier, traffic enters the Google point of presence closest to the user and travels over Google's backbone; in Standard Tier, traffic enters in the region where resources are deployed.
Google Cloud Armor (opens in a new tab) attaches to backend services to allow, deny, throttle, rate-based ban, or redirect at the edge. Rules match Layer 3 through Layer 7 attributes such as IP, geography, autonomous system number, path, method, headers, and body, and are evaluated in priority order. A backend service can hold one backend security policy plus one edge security policy, but never two backend policies. For internal traffic, managed Envoy proxies for internal Application Load Balancers run in a proxy-only subnet and allow ingress by default, so restriction requires an explicit low-priority deny to 0.0.0.0/0 plus higher-priority allows for approved clients and Google health-check ranges.
Application layer inspection on Cloud NGFW adds Layer 7 analysis of domains, URLs, and TLS sessions on top of Layer 3 and Layer 4 firewall decisions. The firewall policy first evaluates network attributes, then a zonal firewall endpoint scans the payload against threat signatures. Tuning aligns signatures, actions, and logging to application criticality and feeds findings into continuous monitoring.
The firewall endpoint is the Cloud NGFW inspection point that reads application identity after initial firewall evaluation. Traffic subject to inspection follows a fixed order. First, firewall policy rules in hierarchical or global network policies match traffic to and from VM instances or Google Kubernetes Engine (GKE) clusters. Second, matched packets are intercepted and sent to the firewall endpoint in the same zone. Third, the endpoint scans against configured threat signatures for anti-spyware, vulnerability protection, and antivirus. Fourth, the endpoint applies the action from the associated security profile, such as block or alert.
Two objects control behavior. A security profile of type threat-prevention defines overrides for specific threats and can exist at organization or project level. A security profile group bundles profiles for use by firewall rules and can contain a maximum of one profile per threat-prevention type. A firewall rule references the group to enable inspection, so the rule selects which traffic to inspect and the group defines how threats are handled. This inspection is available only through firewall policies, not legacy VPC firewall rules.
Granular application rules depend on least-privilege Layer 3 and Layer 4 allows because the endpoint only receives traffic the firewall policy forwards. A base rule defines network, direction, action, target tags, source ranges, and protocol with ports. Common hardened patterns are fw-allow-health-check for TCP port 80 from 35.191.0.0/16 and 130.211.0.0/22, fw-allow-proxy-only-subnet for TCP port 80 from the proxy-only subnet to backends, and fw-allow-ssh for TCP port 22 restricted to administrator addresses rather than 0.0.0.0/0. Hardened baselines also block generic access to DNS, HTTP, FTP, LDAP, SMTP, database, and cache ports and enforce deny-all egress where required.
When inspection is enabled, the endpoint reads the uri field for domain and subdomain, the sni field in SessionLayerDetails for Server Name Indication, and protocolVersion for TLS version. The domain source depends on HTTP version: versions below HTTP/1 and HTTP1 use the first host header, while HTTP2 uses the authority pseudo-header or header, continuation, or push_promise frames because the host header is optional. Observed TLS values include TLS1_0, TLS1_1, TLS1_2, and TLS1_3. A rule can therefore allow two services sharing one IP and port 443 to be treated differently by domain, SNI, and TLS version.
Exam tip: A connection with Layer 7 logging produces two logs in order — first the VPC firewall rules logging entry, then the separate networksecurity.googleapis.com/firewall_url_filter log from the networksecurity.googleapis.com/FirewallEndpoint resource.
URL filtering logs (opens in a new tab) record the Layer 7 verdict separately from the firewall policy rules log that records the network decision. The firewall log carries source and destination IP and ports, protocol, and inspection time. The URL filtering log carries domain, traffic source and destination, connection 5-tuple, intercepting instance identity, and detection time. To view endpoint output, query Cloud Logging Logs Explorer for log name networksecurity.googleapis.com/firewall_url_filter.
Logs flow from Cloud NGFW to Cloud Logging, then through a Log Router sink to a Cloud Storage bucket such as gcp-ngfw-logs, then into Google Security Operations through a configured feed where parser version 2.0 normalizes fields into the Unified Data Model (UDM). Prerequisites are a Security Operations instance, an active Cloud NGFW deployment, and permissions to read logs, create sinks, and manage the bucket. Once normalized, connection, threat, rule, and network fields support hunting, detection on anomalous domains or SNI patterns, and playbooks for containment. Repeated allows to a denied domain, sudden rule-hit growth, new SNI values, or TLS downgrades signal misconfiguration or emerging attack and trigger rule tightening.
Private and public addressing defines whether a workload is reachable only inside Google Cloud or directly from the internet. A Virtual Private Cloud (VPC) (opens in a new tab) network is a global isolated partition with its own subnets, routes, and firewall rules. Resources receive an internal IP from the subnet range and communicate privately when firewall rules permit, while an external IP adds both outbound and inbound internet connectivity and expands the perimeter to that resource.
A VPC network connects subnets across regions over Google's private backbone, with the trust boundary at the VPC edge. Enterprises use separate VPCs to isolate development, staging, and production and to give business units autonomous administration. Best practice is to make each VPC as broad as the administrative and security boundary allows, then add finer isolation with firewall rules, because spanning services across many VPCs increases overhead.
Subnets allocate internal IPv4 addresses from RFC 1918 private ranges, from privately used public IP addresses (PUPIs) used only internally, and from internal IPv6 ranges that are not publicly routable. The same private address can exist in multiple VPCs without conflict, which conserves scarce space. Reuse is safe only while those VPCs are neither peered nor connected by hybrid connectivity, because exchanged routes with overlapping ranges cause conflicts. IPv6 subnets are supported only in custom mode VPCs; auto mode and legacy networks must first convert to custom mode. Alias IP ranges give multiple internal addresses to one VM interface, and VPC-native GKE uses alias IPs so every Pod IP is routable in the VPC without Network Address Translation (NAT).
| Component | Source of internal address |
|---|---|
| Node | Primary IP range of the node pool subnet |
| Pod | Pod CIDR delivered as alias IP ranges on the node |
| Service ClusterIP | Dedicated secondary range in the cluster VPC |
| Control plane | Internal range in a Google-managed tenant project, typically via Private Service Connect |
| Load balancer | Internal load balancers use the cluster subnet primary range; external load balancers use public addresses |
Controlling exposure means denying per-VM external IPs by policy and using managed gateways for required flows. Organization policy constraints block creation of forwarding rules with external IPs and limit which VMs can receive external addresses, shifting perimeter ownership from developers to the organization. Private-only VMs still reach Google services through Private Service Connect or Private Google Access enabled per subnet. For outbound internet, Cloud NAT translates many private sources to a small set of shared regional addresses for outbound-initiated sessions only, while Secure Web Proxy proxies HTTP(S) with identity controls.
| Outbound option | How traffic flows | Choose when |
|---|---|---|
| Direct external IP | Traffic flows directly between VM and internet in both directions | Only resources that must accept direct inbound internet connections |
| Cloud NAT | Traffic flows from private VM to regional NAT gateway, then to internet with shared NAT IPs | Private VMs need general outbound access or fixed egress IPs without per-VM public addresses |
| Secure Web Proxy | Traffic flows from private VM through proxy to HTTP(S) destinations with policy applied | Web egress requires user or workload identity controls |
Private Service Connect (opens in a new tab) for Google APIs creates a consumer endpoint with an internal address and forwarding rule targeting an API bundle such as vpc-sc or all-apis, plus a private Cloud DNS zone for googleapis.com. so names resolve to the endpoint. Firewall rules control which workloads can reach the endpoint, which is finer control than subnet-wide Private Google Access. For hybrid access, on-premises hosts reach the endpoint over Cloud VPN or Cloud Interconnect. Use restricted.googleapis.com at 199.36.153.4/30 and 2600:2d00:0002:1000::/56 to allow only VPC Service Controls-supported APIs, and use private.googleapis.com or all-apis only when non-supported APIs are also needed.
Exam tip: Cloud NAT allows outbound-initiated sessions from private VMs and permits stateful return traffic, but it does not assign an inbound public address — unsolicited traffic from the internet cannot reach a VM through Cloud NAT alone.
Continue with this study guide: Differentiating between private and public IP addressing.
Configuring web application firewalls combines edge filtering for web traffic with project-wide minimum filters for integrated tool traffic. Google Cloud Armor (opens in a new tab) security policies inspect incoming traffic before it reaches backends behind the load balancer, while Model Armor floor settings inspect tool calls and responses inside the project. Together they stop volumetric floods and unsafe content before backends or models process them.
Model Armor floor settings are project-wide minimum security filters that apply the same checks to all tool calls and responses in the project. The floor setting lives at projects/PROJECT_ID/locations/global/floorSetting and requires the Model Armor API modelarmor.googleapis.com to be enabled. Enforcement is configured by enabling the API, selecting the project, starting Cloud Shell for CLI access, setting the endpoint override, and then creating or updating the floor-setting resource.
For Google MCP servers, the floor setting attaches the GOOGLE_MCP_SERVER integrated service with INSPECT_AND_BLOCK, which inspects prompts and responses and blocks matches, plus ENABLED for the malicious-URI filter and MEDIUM_AND_ABOVE for the Responsible AI Dangerous filter. Traffic flows from the agent through Model Armor inspection to the MCP server and back through inspection to the agent. If agent and server are in different projects, floor settings in both projects cause dual invocation against each project's minimum. Removing the integrated service disables automatic scanning for MCP, but edits to a shared floor setting can affect other integrated services such as Vertex AI.
Cloud Armor rate limiting throttles excessive requests to endpoints such as /login, /checkout, or search APIs. A rule defines a threshold over a time window, for example 100 requests per minute, and a key such as client IP or header value. When one key exceeds the threshold, Cloud Armor returns HTTP 429 Too Many Requests instead of forwarding to the backend. This protects against credential stuffing, scraping, and Layer 7 denial-of-service without blocking normal users under the limit.
reCAPTCHA Enterprise, part of Fraud Defense, scores bot risk so Cloud Armor can challenge or block automation before authentication. For websites, reCAPTCHA runs on the page, generates an action-token for actions such as checkout, the application attaches the token to a predefined header before expiry within 30 minutes, Cloud Armor evaluates token attributes, and Cloud Armor allows, challenges, or blocks before the load balancer forwards to the backend. Account defenses add risk scores on login and password reset, SMS toll-fraud checks before sending messages, breach-data checks on submitted passwords, and transaction feedback to train site models. The default rule should deny with 403 or 404 so unmatched traffic is blocked at the edge.
Exam tip: Cloud Armor rate limiting throttles over-limit clients with 429 Too Many Requests, while the policy default deny blocks unwanted traffic with 403 or 404.
Service-level enforcement attaches directly to a backend service fronted by a global external or Classic Application Load Balancer. The load balancer exposes a global Anycast IP, terminates TLS, applies host and path routing, and then applies Cloud Armor before forwarding to the backend. Because the policy binds to one backend service, each service can carry unique Layer 7 filtering, threat intelligence, and Adaptive Protection behavior.
Hierarchical policies separate ownership from enforcement across many projects. A hierarchical policy is created at the organization or folder level but takes effect only when associated with an organization, folder, or project node, after which all protected resources at and under that node inherit the rules. Service-level policies support allow, deny, redirect with GOOGLE_RECAPTCHA and EXTERNAL_302, throttle, and rate-based ban, while hierarchical policies support allow, deny, redirect with only EXTERNAL_302, and Goto next to pass control to the next rule or policy level. Effective enforcement for a backend is the union of inherited hierarchical rules and directly attached service-level rules.
Continue with this study guide: Configuring web application firewalls (e.g., Google Cloud Armor).
Secure Web Proxy is a managed outbound path that isolates private workloads from direct internet access while scaling egress capacity. Traffic flows from clients to Envoy proxies, from the proxies through a Cloud NAT gateway, and then to the external destination, while policy and TLS inspection control what is allowed. Logs and metrics flow to monitoring and analytics for detection and response.
The managed path keeps workloads behind two boundaries: proxy termination and NAT translation. Envoy proxies in a Google-managed proxy-only subnet terminate client connections and create new connections toward the destination, so clients never connect directly externally. The Cloud NAT gateway then maps the proxy-only subnet range to external addresses, so the internet sees only NAT addresses. The NAT configuration attaches to a Cloud Router in the same VPC network and region and is scoped to the proxy-only subnet.
A proxy-only subnet reserves addresses for Google-managed proxies. There can be only one active proxy-only subnet for a given purpose per region per network, using purpose REGIONAL_MANAGED_PROXY with role ACTIVE for regional architectures and GLOBAL_MANAGED_PROXY with role ACTIVE for cross-region patterns. Do not assign forwarding-rule or backend addresses from this range. Integration follows an order: create the proxy-only subnet first, create the Cloud Router next in the same network and region, create the Cloud NAT gateway with endpoint type managed proxy load balancers, and enable dynamic port allocation after the gateway exists with 2048 minimum and 4096 maximum ports per VM.
| Allocation model | Choose when | Tradeoff |
|---|---|---|
| Automatic allocation | External backend does not require an allowlist of Google Cloud IPs | Addresses scale on demand; egress IPs are not predictable |
| Manual allocation | External backend requires an allowlist of specific Google Cloud IPs | Predictable egress identity; team must size pool or risk one-to-one NAT exhaustion and HTTP 5xx failures |
The GatewaySecurityPolicy is the control point where allow, deny, and inspection rules are defined for outbound web traffic. The Secure Web Proxy gateway instance attaches to that policy and inspects traffic routed to it. A TLS inspection policy lets the proxy decrypt and inspect outbound traffic by referencing a Certificate Authority Service pool in the same region and granting the Google-managed service account service-[PROJECT_NUMBER]@gcp-sa-networksecurity.iam.gserviceaccount.com the roles/privateca.certificateManager role.
A next-hop gateway uses SECURE_WEB_GATEWAY type with routingMode: NEXT_HOP_ROUTING_MODE, so VPC routes steer traffic transparently without per-client proxy configuration. Default explicit mode requires each workload to send traffic to the proxy. The gateway listens on ports 80 and 443 by default and can listen on all ports 1 to 65535 with all_ports: true only for next-hop gateways. Static routes match destination range and network tags and need priority numerically lower than the default internet route 1000, while policy-based routes match source and destination ranges and require a second default-routing route with numerically lower priority, for example priority 1 for default routing and 2 for the proxy route.
Exam tip: Use automatic NAT addresses unless an external allowlist forces manual addresses, and never size a manual pool smaller than the assigned Envoy proxy count or 5xx failures can occur.
Proxy health depends on NAT capacity. Cloud Monitoring watches the nat_allocation_failed gateway metric to detect port exhaustion, which is distinct from an intentional policy deny. Load balancer and proxy logs record outcomes including rejected early-data requests with HTTP 425 Too Early. For third-party telemetry, Netskope web transaction logs flow from the tenant to a Cloud Storage bucket every 240 seconds, then to Google Security Operations through a Cloud Storage V2 feed for conversion to Unified Data Model events.
Threat intelligence (opens in a new tab) from Google Threat Intelligence lets policy dynamically deny malicious domains and IPs instead of relying only on static lists. Mature operations connect intelligence to enforcement and response through ingestion feeds, Unified Data Model parsing, response integrations that act on detections, starter playbooks for automated response, and Security Command Center findings exchange. Limits shape design: next-hop gateways support HTTP(S) and TCP proxy traffic only, only one next-hop Secure Web Proxy can exist per VPC network per region, and an all_ports: true gateway cannot coexist with another proxy instance in the same network and region.
Continue with this study guide: Deploying Secure Web Proxy.
Configuring Cloud DNS security settings protects name resolution against spoofing, hijacking, and leakage. Public zones use Domain Name System Security Extensions (DNSSEC) signing so validators reject forged answers, while private zones keep internal names inside authorized VPC networks. Server policies, peering, and logging then control hybrid lookups and expose anomalous query patterns.
DNSSEC on a Cloud DNS managed public zone adds cryptographic signing so validating resolvers reject forged responses. The zone signs with a Key Signing Key (KSK) and Zone Signing Key (ZSK), and trust is completed only after Delegation Signer (DS) records are published at the registrar so the parent zone trusts the child. When a domain uses Cloud Domains, DNS provider and DNSSEC options change through Edit DNS details, which exposes dsState such as DS_RECORDS_UNPUBLISHED. Choose Cloud DNS when Google-managed signing and centralized IAM are needed; choose custom name servers only when records and signing must stay with a third party.
Zone integrity is perimeter protection because Cloud Identity and Google Workspace accounts are identified by a primary DNS domain. Ownership is proven by a special DNS record, while MX records control mail routing and added records can enable super admin password reset. An attacker who modifies MX records can reroute mail, and an attacker who adds records can take over the account. Administrative access therefore uses least privilege: Managed DNS Project Viewer views zones and records, Managed DNS Project Admin creates and updates them, the number of administrators for the primary domain stays as small as the number of super admins, and activity is audited.
Cloud DNS private managed zones are authoritative zones visible only to authorized VPC networks. A workload outside an authorized VPC cannot resolve names in the zone even if it knows the fully qualified name, which keeps internal service names off the public internet. Cross-VPC DNS peering extends controlled resolution without publishing records: an administrator creates a private peering zone in the consumer VPC that forwards lookups for a namespace to the producer VPC where authoritative records live. If the target network is deleted, matching queries fail.
DNS peering for private services access lets VPC workloads resolve service-producer suffixes without public DNS, except for Cloud SQL, and requires the Cloud DNS API dns.googleapis.com to be enabled. The suffix must be a complete domain with trailing dot, for example example.com.. Hybrid resolution over Cloud VPN or Interconnect adds routing care: the producer imports eligible routes from the VPC, so exported custom routes that overlap Private Google Access ranges can misroute producer traffic intended for Google services unless overlapping exports are avoided or VPC Service Controls enforces perimeter routing. Inbound and outbound DNS server policies govern lookup direction, alternative name servers provide the next hop, and query logging supports detection of domain generation algorithm traffic. Disjoint domains that are not subdomains of each other prevent verification conflicts between staging and production identity accounts.
Exam tip: A DNS peering suffix must include the trailing dot — example.com. is valid, example.com is not.
Continue with this study guide: Configuring Cloud DNS security settings.
Continually monitoring and restricting configured APIs keeps calls to Google APIs on internal paths, allows only approved services, and detects anomalous invocation. Private domains and service perimeters control where API traffic can flow, audit and network logs record who called what and how traffic moved, and organization policies with key restrictions limit how credentials can be used.
Private and restricted API domains are internal entry points routable only from within Google Cloud. private.googleapis.com reaches a broad set including APIs that do not support VPC Service Controls. restricted.googleapis.com at 199.36.153.4/30 and 2600:2d00:0002:1000::/56 reaches only VPC Service Controls-supported APIs and blocks Workspace APIs and web apps such as Gmail and Docs. A Cloud DNS response policy can override names such as *.run.app and *.cloudfunctions.net to return restricted addresses with TTL 300, so requests from inside the VPC stay inside the VPC and reach only perimeter-enforced services.
Perimeter-compliant Cloud Run services attach to the VPC with Direct VPC egress or a Serverless VPC Access connector, route all egress through the VPC, and allow only internal ingress, because ingress set to all disables VPC Service Controls enforcement. Cloud Tasks enforces the same boundary: dispatches to compliant run.app and functions.net targets are allowed, while non-compliant or non-Cloud Run targets fail with TARGET_TYPE_NOT_PERMITTED_FOR_VPC. Interdependent services such as Sensitive Data Protection with its scanned stores, Dataform with BigQuery, and Looker with its data sources must sit in the same perimeter or use explicit ingress, egress, or perimeter bridges, otherwise scans and writes cross the boundary.
Cloud Audit Logs is the authoritative who-did-what record. Admin Activity logs record ADMIN WRITE operations that modify configuration, including organization policy changes, and are always written and cannot be disabled. Data Access logs record ADMIN READ, DATA READ, and DATA WRITE operations such as IAP request evaluations and must be explicitly enabled, appearing only after enablement and traffic. Both types must be reviewed together because Admin Activity alone misses read-heavy and data-plane abuse.
Network telemetry validates the network effect. VPC Flow Logs records a sample, typically 50% or less, of flows from VM instances including GKE nodes, with logging enabled per subnet. Firewall Rules Logging attributes allow or deny decisions to a specific rule and must be enabled per rule. Log-based alerts in Cloud Logging flag unauthorized VM creation or privilege escalation, while IAP access review in Logs Explorer checks data_access entries, where a blue i marks authorized access and an orange !! marks unauthorized access, and inspects protoPayload access levels to compare what the requester met against what the resource requires. Exports to Cloud Storage retain evidence, with equivalent access controls on the destination as in Logs Explorer.
Exam tip: Admin Activity audit logs are always on and cannot be disabled, while Data Access logs and Firewall Rules Logging must be explicitly enabled and produce entries only after enablement and traffic.
Organization restrictions (opens in a new tab) including Restrict Service Usage enforce an approved API allowlist down the organization, folder, and project hierarchy. A child cannot enable a service the parent denied without an exception. Governed names include bigquery.googleapis.com, storage.googleapis.com, compute.googleapis.com, iam.googleapis.com, secretmanager.googleapis.com, and apikeys.googleapis.com. Enabling an API requires serviceusage.services.enable through Owner or Service Usage Admin, and if restriction is in use the API must be on the allowed list.
API key restrictions (opens in a new tab) bind a key to application type such as HTTP referrer or mobile app, to network source such as IP ranges, and to specific API targets. If any dimension mismatches, the client-to-Google API request is denied. Keys must be sent in the x-goog-api-key header, not as a URL query parameter, never hardcoded in client code or repositories, and instead added by a backend server. Continuous checks flag keys with no restriction, no service restriction, age over 90 days, or any unnecessary static key. Lifecycle hygiene deletes unneeded keys, isolates keys per team and application, rotates every 90 days by creating, switching, then deleting, and migrates production authorization to IAM and short-lived service account credentials.
Continue with this study guide: Continually monitoring and restricting configured APIs.
DNS authorization should be used when you need wildcard certificates, operation behind a content delivery network (CDN) or on nonstandard ports, or provisioning before cutover. It requires adding a CNAME record, while load balancer authorization needs no DNS change but requires the global load balancer to be publicly reachable on port 443 and does not support wildcards.
Identity-Aware Proxy (IAP) adds user and device verification on top of network reachability by authenticating every user and device and authorizing by role, device posture, and location. A Cloud Next Generation Firewall (Cloud NGFW) firewall rule must still allow the IAP traffic path to reach the protected virtual machine.
Cloud NAT should be used when private virtual machines need general outbound access or fixed egress IPs without per-VM public addresses, translating many private sources to shared regional addresses for outbound-initiated sessions only. Secure Web Proxy should be used when web egress requires user or workload identity controls because it proxies HTTP and HTTPS destinations with policy applied.
Admin Activity logs record ADMIN WRITE operations that modify configuration and are always written and cannot be disabled. Data Access logs record ADMIN READ, DATA READ, and DATA WRITE operations and must be explicitly enabled, appearing only after enablement and traffic.
Last updated