Google Cloud Developer: Secure Applications from Code to Production

A product team deploys a Google Cloud application that uses an API to accept customer requests, places slow tasks on a queue and asks a foundation model to draft a suggested response. The prototype works, but production reveals duplicated messages, accidental disclosure of customer context, and no clear way to reverse a model or schema change. The Professional Cloud Developer role exists at this boundary: writing software is not enough unless the application can operate securely, reliably and predictably when dependencies fail.

Google's current Professional Cloud Developer description explicitly includes cloud-native application design, testing, deployment, service integration, and generative AI APIs and AI-assisted development tools. That breadth should not be confused with a generic programming interview. Candidates need to reason about Google Cloud runtimes, workload identity, event handling, data consistency, testing, and monitoring while recognizing which responsibilities remain in the application even when services are fully managed.

Design services around stable contracts and ownership

A service boundary is useful when it corresponds to a distinct responsibility, data owner or scaling need. Splitting one simple application into many microservices can increase latency and incident complexity without improving delivery. Design an API contract that defines inputs, outputs, authentication, errors, timeouts and compatibility behavior. For state-changing operations, specify idempotency rules so an automatic retry cannot create two invoices or issue the same customer credit twice. A robust service makes failure behavior part of the interface, not an afterthought.

In a support application, separate case retrieval from suggested response generation and from the action that sends a message. The first two can fail or retry without changing customer state; the final action requires a clear authorization boundary. Define correlation identifiers through the request path and use structured errors that clients can interpret safely. Version API schemas deliberately as applications and integrations evolve. A deployed endpoint is not a reliable contract unless clients can handle the failures it can actually return.

Select Cloud Run, GKE and VMs from runtime needs

Cloud Run simplifies deployment and scaling for suitable stateless, containerized or event-driven work. GKE is appropriate when the team needs the orchestration and control provided by Kubernetes; Compute Engine can suit software with operating-system dependencies or custom instance requirements. None removes the need to manage code quality, secrets, concurrency limits and downstream back pressure. Match task duration, network connectivity, application startup, scaling behavior and operational skills to the deployment model.

A file-conversion task might run as a managed job, while the request API uses autoscaled containers and the database stays a managed transactional service. Measure cold start, concurrent requests and the time an upstream service waits for completion. Long-running tasks should not consume a web request indefinitely if a queue and asynchronous status model are more robust. Evaluate which signals show the workload is healthy: accepted work, completed work, correct results, latency and user-facing errors all matter.

Model data and events so retries are safe

Cloud SQL, Firestore, Spanner, Pub/Sub and Cloud Storage have different access semantics. A relational transaction can preserve a group of updates; an asynchronous message may be delivered more than once. Consumers therefore need stable identifiers and deduplication or idempotent processing. Ordering guarantees must be understood for the specific system, and event handlers should tolerate late arrivals when the business process requires it. Do not equate a successful publish response with successful completion of the downstream business task.

For the support workflow, allocate a case ID and a version for updates. If a network timeout occurs after the database commit, a retried request should return the existing result rather than create a second case. Store large attachments in appropriate object storage, not in a bloated database row by default. Think through partial failure between file upload, metadata insertion, and event publication. Design reconciliation tasks that can discover unfinished states and repair them without guessing at customer intent.

Separate application configuration from source and deployable images. A public environment variable may be suitable for a nonsecret feature flag, but sensitive tokens require controlled storage and rotation. A failed deployment sometimes results from a value injected at build time when the service expects it at runtime. Inventory which parameters vary by environment, who may change them and how a rollback restores their prior values. This reduces a common class of errors in which identical code behaves unpredictably across staging and production because no one can reconstruct the configuration actually used.

Use service identity and secrets deliberately

Runtime code should authenticate using an appropriate workload identity rather than shipping static administrator credentials. IAM roles control what a service may call, while application authorization controls what a particular user may request. These are not the same boundary. A highly privileged service account can allow one tenant to access another tenant's records if the application forgets authorization checks. Manage secrets with a controlled system and avoid logging tokens, confidential prompts, or raw personal data as a troubleshooting shortcut.

Test an endpoint with a user whose access should be denied even though the service itself is authorized to read the database. Verify tenant scoping in both retrieval and update methods. Rotate test credentials and observe whether processes pick up changed secrets safely. Protect build pipelines and container image provenance: a compromised dependency or overly broad deployment identity can defeat runtime safeguards. Effective development security is enforced through code, platform permissions and release process together.

Integrate generative AI without giving it authority

A foundation model can draft answers, classify messages, or extract data, but it should not decide who may query a customer account or execute a high-impact action. Keep trusted instructions separate from user and retrieved content, constrain available tools, and validate generated outputs before sending them to other systems. Grounded retrieval can improve accuracy but depends on correct document access and freshness. Model output can still be incomplete or fabricated; business rules and explicit approval gates must remain outside the model.

When the support assistant proposes a refund, show the employee the source case details and applicable policy, then have an authorized transaction service perform the approved refund. Test prompt-injection text inside an uploaded document to ensure it cannot alter permissions or send information externally. Monitor changes to answer quality and latency after model updates. AI prompting and grounding are engineering concerns because they affect user trust, data safety and the reproducibility of application behavior.

Build tests that cover faults and contracts

Unit tests verify local logic, integration tests exercise actual service boundaries, and end-to-end tests confirm customer-visible outcomes. Cloud development also needs performance and security tests matched to likely failure modes. Mocking every dependency can conceal the very permissions, network policies and serialization behaviors that fail in production. Use realistic test identities and synthetic data that preserve the relationships of the real system without exposing customers.

Test duplicate Pub/Sub deliveries, unavailable database connections, cold starts, expired credentials, malformed model output and incompatible API clients. Verify rollback for application images, and handle schema changes with a forward-compatible migration strategy. A green build is evidence that certain tests passed, not proof that a release will be safe. Ensure the release candidate can be associated with a reproducible image, configuration version and approval record.

Observe the request from the customer backward

Metrics, logs and traces explain different parts of runtime behavior. A 200 status code may indicate that a request was accepted while the customer job never completed. Follow a correlation ID from gateway to application, queue, worker, model call and database write. Measure successful business outcomes and error budget consumption, not just request traffic. Alerts should distinguish a provider outage from application exceptions and have clear owners.

If customer responses arrive late, inspect queue age, worker concurrency, model latency, retries and database waits before scaling one component. A sudden spike in errors after a deployment may justify rapid rollback, but preserve enough evidence to investigate the root cause. Logging must avoid exposing personal data and secrets. Operations and observability are related to development because a team cannot maintain software it cannot diagnose.

Consider cancellation and concurrency in a long-running task. If a user submits the same job twice, the application should be able to identify a duplicate and return a stable status. If the user cancels after processing has begun, the workflow needs a defined policy for partial output and any already committed side effects. A queue can preserve work while a worker is unavailable, but it does not understand whether a refund or notification is safe to repeat. These rules belong in business code and tests, regardless of which managed runtime executes the function.

Demonstrate an application that survives a bad day

Create a small service that accepts a request, validates user authorization, stores a durable job identifier and generates a recommendation asynchronously. Simulate a dropped response after commit, duplicate event delivery, an inaccessible bucket and a delayed model call. Explain which outcomes are safe to retry, which need human review, and how the customer learns that work was accepted or failed. Show how to deploy a compatible version and restore the previous image without losing user state.

The decisive test is not the happy-path screenshot but the ability to explain behavior under error. Document API schema, identity permissions, release pipeline, test cases and monitoring. A Professional Cloud Developer needs application judgment across the entire lifecycle, especially where managed cloud infrastructure stops and the team's own business logic begins.