PCD question patterns
Find a pattern
Each row is wording that keeps showing up in questions, with the answer it usually points to in green. Tap a row to see why.
In this list
No pattern matches that. Try a service name, such as CodeDeploy or Config.
Choosing a platform and design
-
Deploy the container or source to Cloud Run.
It is fully managed, scales to zero and needs no cluster or VM management.
-
Use GKE (Autopilot to avoid node management).
Cloud Run does not expose Kubernetes primitives.
-
Run it on Compute Engine, in a managed instance group for scaling.
Only VMs give full OS control.
-
Put a global external Application Load Balancer with a serverless NEG in front, adding Cloud CDN and Cloud Armor.
The load balancer provides the edge features Cloud Run lacks natively.
-
Use a passthrough Network Load Balancer.
It does not terminate connections or alter source IP.
-
Enable cookie or header session affinity on the backend service.
It is best effort; shared state still belongs in Memorystore or a database.
-
Cache-aside with Memorystore and a TTL.
It serves hot reads from memory with low latency.
-
Deploy with --no-traffic, shift percentages with update-traffic, and revert to the previous revision if errors rise.
Revisions are immutable, so rollback is only a traffic change.
APIs and asynchronous design
-
Use API Gateway with an OpenAPI spec.
It is lightweight and managed.
-
Use Apigee API proxies and API products.
These are full API management features API Gateway lacks.
-
Publish to a Pub/Sub topic with a subscription per consumer.
Each subscription gets every message and absorbs bursts.
-
Use a Cloud Tasks queue with rate limits and named tasks.
It controls dispatch rate and retries per task.
-
Orchestrate with Workflows.
It handles state, conditions, retries and callbacks without custom code.
-
Use an Eventarc Cloud Storage trigger to Cloud Run.
Direct events are delivered as CloudEvents.
-
Use an Eventarc Cloud Audit Logs trigger.
Audit logs capture API calls; data events need Data Access logs enabled.
Security and identity
-
Attach a dedicated service account and let ADC use it.
The metadata server supplies short-lived tokens.
-
Configure a workload identity pool and provider.
It exchanges external tokens for short-lived credentials with no keys.
-
Map each Kubernetes service account to IAM.
Avoids sharing node service account permissions.
-
Store them in Secret Manager and mount into the workload.
It versions secrets and supports rotation notifications.
-
Use the Auth Proxy or connector with the Cloud SQL Client role.
IAM authorises and the tunnel is encrypted.
-
Use Identity Platform.
It is the customer identity service.
-
Enable Identity-Aware Proxy on the load balancer or Cloud Run service.
Access is checked per user identity and context.
-
Require attestations such as built-by-Cloud-Build.
Deploy-time policy blocks unattested images.
-
Set a retention policy and lock it.
A locked policy cannot be shortened or removed.
-
Add lifecycle rules by age.
Rules automate tiering and deletion.
-
Generate a V4 signed URL with short expiry.
It grants time-limited access; maximum 7 days.
-
Enable scanning in Artifact Registry.
Images are scanned on push and updated as new CVEs appear.
-
Apply NetworkPolicies, or use Cloud Service Mesh for mTLS.
They restrict pod-to-pod traffic.
Data and storage
-
Use Spanner multi-region.
It gives external consistency at scale.
-
Use hashed, UUID or bit-reversed keys (Spanner, Bigtable).
Sequential keys concentrate writes on one split.
-
Read from the primary, or accept replica lag.
Cloud SQL, AlloyDB and multi-cluster Bigtable replicas are eventually consistent.
-
Use the Storage Write API with committed streams.
It supports exactly-once, unlike best-effort legacy streaming.
Build, test and deploy
-
Define a workstation configuration and cluster.
Managed, secure environments with no code on laptops.
-
gcloud run deploy --source . or gcloud builds submit --pack.
Buildpacks detect the language.
-
Add a test step before pushing; non-zero exit fails the build.
Images are pushed only after all steps succeed.
-
Run builds in a private worker pool.
It runs inside your VPC.
-
Use Cloud Build SLSA provenance and verify with Binary Authorization.
It is a signed attestation of source and builder.
-
Give the subscription's service account roles/run.invoker and configure OIDC.
Authenticated push needs a token and permission.
-
Add a startup probe or raise thresholds.
Startup probe pauses other probes until the app is up.
-
Use a readiness probe.
Failure removes the pod from endpoints without restarting it.
-
Use an HPA with an external metric for undelivered messages.
CPU does not track queue depth.
-
Set CPU requests on the pods.
Utilization is relative to requests.
-
Use a Cloud Deploy pipeline with targets, canary and approvals.
It tracks releases and rollouts.
Calling APIs and troubleshooting
-
gcloud services enable SERVICE.googleapis.com.
Calls fail until the API is enabled in the project.
-
Retry idempotent calls with capped exponential backoff and jitter.
It avoids synchronized retries; do not retry 4xx permanent errors.
-
Create one pool per instance and cap instances times concurrency times pool size.
Each instance consumes connections.
-
De-duplicate on message or event ID; consider exactly-once pull.
Delivery is at-least-once.
-
Propagate trace headers and set the trace log field.
All spans share the trace ID.
-
Review grouped errors by service version.
It groups stack traces and flags new errors.
-
Run a Gemini Cloud Assist investigation.
It correlates telemetry and suggests causes; verify results.
Now spot them in real questions. Practice sets use the same wording.
Practise 20 questions