Study guide
9.1 Private Communication, Key Rotation, and Vulnerability Response
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
9.1 Private Communication, Key Rotation, and Vulnerability Response
Key Takeaways Explain This Topic AI
Identity Platform authenticates end users; workload IAM permissions and application resource authorization remain separate.
A namespace alone does not block Pod traffic; NetworkPolicy and mesh authorization need explicit enforcement and testing.
Cloud KMS rotation creates a new key version without automatically re-encrypting old data.
Secret rotation notifications require an implemented rotator and coordinated client adoption.
A vulnerability finding needs triage, remediation, rebuild, controlled release and verification of the actual deployed digest.
Last updated: October 2026
Private Communication, Keys, and Vulnerability Response
Application security is a collection of independent boundaries. A network route can make an endpoint reachable without granting permission to invoke it. An identity token can prove who called without proving which customer's record may be read. Encryption can protect traffic without making vulnerable application code safe. Exam scenarios often become clear when each boundary is named separately.
End-User Identity and Workload Identity
Identity Platform supports application user authentication and identity-provider integration. The backend validates a user token's signature, issuer, audience and expiry using a supported verification library. It then authorizes access to tenant-specific resources in application logic. A signed token containing a user ID does not automatically establish an IAM role on Google Cloud or grant access to another user's order.
A Cloud Run service identity or GKE federated workload principal serves a different purpose: it authorizes the backend's calls to Cloud Storage, databases and other Google APIs. Grant the backend only the required resource roles. The user-facing application must still enforce its own access rules because a powerful server identity can read records that an individual user should not see. Do not forward a user ID string as if it were a verified identity token.
Private Networking and Service Authentication
Direct VPC egress gives Cloud Run an outbound VPC path. It does not change inbound IAM, make another service public, or create a route across every peering. For a private datastore, verify the selected network/subnet, route, firewall rules, DNS and service-specific connection mechanism. Private Service Connect and private services access have different provisioning and reachability models; use the datastore's supported design rather than treating both as interchangeable labels.
On GKE, namespaces organize resources and scope some authorization, but do not automatically isolate traffic. A NetworkPolicy selects Pods and permits specified ingress/egress connections when the cluster's enforcement implementation supports it. For a default-deny design, explicitly allow required DNS, metadata/token access and backing-service paths as appropriate. Test both an allowed caller and a denied caller; an untested policy can silently block the application's credential flow.
Cloud Service Mesh can provide workload-to-workload mutual TLS and policy-controlled communication. Certificates authenticate peers and encrypt transport; authorization policies determine which authenticated workload may call another. Certificate issuance, trust roots and renewal are managed/configured through the chosen mesh. A namespace name or encrypted connection alone is insufficient proof of business authorization. For custom TLS integrations, verify trust, hostname/identity and expiry rather than disabling certificate checks to make a connection succeed.
- Requirement Mechanism Separate check
- Reach a private database Supported VPC/private endpoint route IAM plus database login/SQL grants
Authenticate a Cloud Run caller Audience-correct ID token and Invoker permission Service ingress and application authorization
- Restrict Pod communication Enforced NetworkPolicy Mesh identity/authorization if required
- Authenticate an end user Identity Platform token verification Ownership and tenant scope for each operation
Encrypt with customer-controlled keys Supported KMS/CMEK integration Key location, IAM, version lifecycle and recovery
Secrets and Encryption Keys Have Different Lifecycles
Secret Manager stores secret values and immutable versions, such as an external API password. Its rotation schedule can notify a Pub/Sub topic; application automation must actually create the new credential, update the external system, publish the version and verify client adoption. A rotation notification is not proof that the database password changed. Keep a controlled overlap/rollback period and retire old values only after clients have transitioned.
Cloud KMS manages cryptographic keys and key versions. Rotating a symmetric encryption key selects a new primary version for future encryption; existing ciphertext still depends on the version used to encrypt it. Rotation does not automatically re-encrypt every stored value, disable old versions or delete them. Test decryption and inventory dependencies before destroying a version, because destruction of required key material can make data unrecoverable. Asymmetric signing-key rotation also requires distributing the new public verification key and updating trust; KMS does not automatically rotate asymmetric keys on the same schedule mechanism.
For envelope encryption, an application can encrypt data with a data-encryption key and wrap that key with KMS. Rewrapping and re-encrypting payloads are different operations with different cost and migration implications. Prefer established client libraries/service integrations to hand-written cryptographic protocols. Separate the principal administering keys from the principal allowed to decrypt when the access model requires that distinction.
Resolve Vulnerabilities Through the Artifact Lifecycle
Web Security Scanner can identify supported web-application weaknesses, while Artifact Analysis reports vulnerabilities in supported container/package contents. Security Command Center aggregates findings from configured sources and tiers. These tools are complementary: a clean dependency scan does not establish that an authorization check is correct, and an open network path is not itself a software-package CVE.
Start triage with the affected resource, artifact digest, package/version, severity, exploitability and exposure. Confirm whether the vulnerable artifact is actually deployed. A mutable tag can point to a new image while older running Pods still execute a previous digest. Prioritize exploitable internet-facing findings, but document any exception and expiry rather than silently treating a severity threshold as a complete risk assessment.
Remediation normally means updating the dependency or base image, rebuilding from reviewed source, running tests, rescanning, and releasing the new immutable digest. Review scan errors or unavailable results explicitly; absence of a successful scan is not a clean result. Binary Authorization can require a trusted attestation before deployment, but only if the pipeline creates that attestation after the intended checks and the admission policy requires it.
After rollout, verify the live workload's digest and service behavior, then confirm the finding's current status. Keep the previous safe rollback artifact where appropriate, recognizing that rolling back to a known vulnerable digest may reintroduce the issue. Audit emergency exceptions and check them after the incident. This closes the loop from detection to an observable repair rather than stopping when a dashboard row is marked acknowledged.
Sources checked October 18, 2026: KMS rotation , GKE network policy , Identity Platform documentation , Security Command Center documentation .
Retention, Location, and Organization Policies
At design time, identify the applicable retention and residency requirements before creating storage, backups, logs and build artifacts. Resource-location organization constraints can restrict supported resource creation, but do not automatically move existing data or cover every service path. Public-access prevention and uniform bucket-level access address different Cloud Storage access-control concerns. Check the documented constraint scope and exceptions; a policy display name is not proof of retroactive enforcement.
Distinguish Object Lifecycle Management from retention. Lifecycle rules schedule transitions/deletion under supported conditions, while a retention policy prevents deletion before the required time. A locked retention policy cannot be shortened or removed, so test the intended policy on disposable resources before locking production data. Backups, replication, soft delete and versioning serve different recovery needs and do not replace a required retention control. Verify the location of replicated copies and exported logs independently of the application region.