Google Cloud Developer Flashcards

Question

What are some use cases for generative AI in workflow automation?

Answer 1

Answer: Extracting and labeling contracts, classifying feedback, and creating support tickets.

Answer 2

Answer: It can generate code, write unit tests, explain code, fix bugs, complete code, and translate code between languages.

Answer 3

Answer: They provide generative AI features like code generation, code chat, and code completion.

Answer 4

Answer: It can convert code from one programming language to another, following best practices of the new language.

Answer 5

Answer: Gemini is an AI-powered assistant designed to help developers write code faster and more efficiently using generative AI.

Answer 6

Answer: Because it enhances productivity, simplifies complex tasks, and reduces the barrier to developing intelligent, feature-rich applications.

Answer 7

Answer: A developer commits changes into a feature branch in a code repository, which automatically triggers a build service like Cloud Build.

Answer 8

Answer: In Artifact Registry.

Answer 9

Answer: Changes being pushed to the main branch in the code repository.

Answer 10

Answer: It deploys application images to environments like Cloud Run or GKE, supports release strategies (like canary or blue-green), and provides approval workflows and security insights.

Answer 11

Answer: The build is tagged as a release candidate, which can be manually approved for production deployment.

Answer 12

Answer: Continuous deployment skips manual approval and automatically deploys release candidates to production.

Answer 13

Answer: It provides a fully managed, end-to-end software supply chain security solution that protects each step of the CI/CD process.

Answer 14

Answer: It scans for vulnerabilities in container images and packages (like Maven and Go) stored in Artifact Registry and continuously monitors metadata for new vulnerabilities.

Answer 15

Answer: It ensures only trusted images are deployed by verifying that artifacts meet predefined attestation policies.

Answer 16

Answer: It executes builds on Google Cloud infrastructure and maintains verifiable metadata, helping ensure artifacts are built from trusted sources.

Answer 17

What is the main advantage of using containers over virtual machines? Answer: Containers are faster to start and use fewer resources because they don’t require a full operating system instance.

Answer 18

Answer: Packaging and deploying applications in a lightweight, portable, and isolated environment.

Answer 19

Answer: It launches and runs containers, calls into the operating system kernel as needed, and determines the image format.

Answer 20

Answer: Containers can run anywhere—on a developer’s laptop, on-premises VMs, or any cloud—with consistent behavior.

Answer 21

Answer: Application isolation at the OS level, including virtualized CPU, memory, storage, and network resources.

Answer 22

Answer: The application binary and all necessary software dependencies to run the application.

Answer 23

Answer: A fraction of a second.

Answer 24

Answer: To create automated pipelines that build container images and push them to Artifact Registry.

Answer 25

Answer: Artifact Registry

Answer 26

Answer: A build trigger, which can be based on commits to a specific branch or tags in a repository.

Answer 27

Answer: A build configuration file written in YAML or JSON.

Answer 28

Answer: Into the /workspace directory inside the build step’s Docker container.

Answer 29

Answer: It specifies the name of the container image to be created during the build process.

Answer 30

If yes, how? Answer: Yes, it can publish notifications to Pub/Sub, which other services can subscribe to.

Answer 31

Answer: You don’t need to manage your own build infrastructure or install local build tools—everything runs in the cloud.

Answer 32

Answer: Compute Engine

Answer 33

Answer: Cloud Run functions are event-driven, serverless microservices that automatically scale and execute small pieces of code in response to events.

Answer 34

Answer: They support an event-driven, serverless, and highly scalable architecture.

Answer 35

Answer: Cloud Run functions are ideal for lightweight microservices that quickly process data in response to events.

Answer 36

Answer: Billing is based on: Execution duration Number of invocations Provisioned resources (CPU, memory)

Answer 37

Answer: Cloud Storage Pub/Sub Cloud Run functions Vision API Cloud Translation API

Answer 38

Start with serverless (Cloud Run or Functions) unless you have specific infra needs. Choose GKE or Compute Engine for: Stateful apps Custom networking or protocols Special hardware (GPU/TPU) Use App Engine only if: You prefer PaaS simplicity over containers You have legacy apps that fit its model

Answer 39

Containers can move between Cloud Run ↔ GKE Buildpacks can turn source code into containers for deployment Can start serverless, then move to GKE for more control later

Answer 40

Follow-up: Could starting with serverless simplify your MVP and allow you to defer infrastructure complexity until you truly need it?

Answer 41

Follow-up: If you needed to migrate to a hybrid or multicloud setup in the future, how would your initial platform decision impact that journey?

Answer 42

Follow-up: How would observability and performance monitoring guide that decision?

Answer 43

Follow-up: Which platform best aligns with your internal governance, audit, and DevSecOps policies?

Answer 44

Follow-up: Where does abstraction (e.g., containers, Cloud Client Libraries, buildpacks) break down?

Answer 45

Answer: It depends on: Infrastructure control needed Team structure Application requirements Pricing model Future flexibility

Answer 46

15. Answer: They let you focus solely on your code, while Google Cloud manages the infrastructure and scaling.

Answer 47

Answer: Use Cloud Client Libraries for the appropriate language.

Answer 48

Answer: No. Cloud Run functions handle the build and dependency installation automatically.

Answer 49

Answer: Dependencies are listed in a package.json file and are automatically installed.

Answer 50

Answer: It must export its source code as a Node.js module.

Answer 51

Answer: Node.js Python Go Java .NET Ruby PHP

Answer 52

Answer: Events from services like Cloud Storage, Pub/Sub, HTTP requests, or webhooks.

Answer 53

Answer: Yes. They can handle direct HTTP calls from webhooks to trigger microservices.

Answer 54

Answer: Lightweight ETL operations or message processing from a Pub/Sub topic.

Answer 55

Answer: They all scale automatically based on incoming data volume and compute needs.

Answer 56

Answer: Cloud Storage Pub/Sub Cloud Run functions Vision API Cloud Translation API

Answer 57

Answer: Billing is based on: Execution duration Number of invocations Provisioned resources (CPU, memory)

Answer 58

Answer: Cloud Run functions are ideal for lightweight microservices that quickly process data in response to events.

Answer 59

Answer: They support an event-driven, serverless, and highly scalable architecture.

Answer 60

Answer: Cloud Run functions are event-driven, serverless microservices that automatically scale and execute small pieces of code in response to events.

Answer 61

Follow-up: Could starting with serverless simplify your MVP and allow you to defer infrastructure complexity until you truly need it?

Answer 62

Follow-up: If you needed to migrate to a hybrid or multicloud setup in the future, how would your initial platform decision impact that journey?

Answer 63

Follow-up: How would observability and performance monitoring guide that decision?

Answer 64

Follow-up: Which platform best aligns with your internal governance, audit, and DevSecOps policies?

Answer 65

Follow-up: How do tools like Cloud Profiler, Cloud Trace, and Cloud Monitoring complement each other in surfacing root causes?

Answer 66

Follow-up: How would you incorporate golden signals to strike this balance?

Answer 67

Follow-up: Can you describe a use case where trend analysis helped you improve reliability or performance?

Answer 68

Follow-up: What role does Cloud Monitoring’s support for external data sources play in your solution?

Answer 69

Follow-up: How do distributed tracing (Cloud Trace) and structured logging work together to give you a complete picture?

Answer 70

Follow-up: How do distributed tracing (Cloud Trace) and structured logging work together to give you a complete picture?

Answer 71

Follow-up: Can you describe a real-world use case where combining log-based alerts and system metrics helped catch or prevent an issue?

Answer 72

Follow-up: How would you implement structured logging in a microservices-based architecture using Cloud Run or GKE?

Answer 73

Follow-up: How would you identify whether the root cause is in the application logic, a dependency, or infrastructure?

Answer 74

Follow-up: How would Cloud Logging and Managed Service for Prometheus help simplify this setup?

Answer 75

Follow-up: How do managed collectors vs. self-deployed collectors affect scalability, maintenance, and security?

Answer 76

Follow-up: In what scenarios would you prefer to use the Error Reporting API directly?

Answer 77

Follow-up: How would you configure deduplication or error grouping for custom frameworks or edge cases?

Answer 78

Follow-up: How would you navigate from an error in Error Reporting to the root cause in the logs?

Answer 79

Follow-up: Describe a scenario where a recurring error is automatically logged as an issue in a ticketing system like Jira or GitHub Issues.

Answer 80

In a multi-service microservices architecture using different runtimes (e.g., Node.js, Python, Java), how would you design a unified error reporting strategy across services? Follow-up: What role do client libraries and consistent error formatting play in this strategy?

Answer 81

🔑 Core Principles of Loose Coupling Minimize direct dependencies between services/components. Encapsulate functionality so changes in one part don’t break others. Use contracts/interfaces rather than direct implementations. Prefer asynchronous communication over synchronous when possible.

Answer 82

Continuous delivery is a workflow that is triggered when changes are pushed to the main branch in the repository.

Answer 83

Containers start much faster than virtual machines and use fewer resources because each container does not have its own instance of the operating system. 04:20 Instead, developers configure each container with a minimal set of software libraries to do the job. 04:26 A lightweight container runtime does the plumbing jobs needed to allow that container to launch and run, calling into the Kernel as necessary. 04:35 The container runtime also determines the image format. 04:38 Google Kubernetes Engine uses the Docker container runtime, and Docker containers are what we'll focus on in this course.

Answer 84

Efficiency, by specifying CPU and memory requirements of containers, Kubernetes can efficiently pack containers and nodes to efficiently use compute nodes. 03:05 Declarative configuration. 03:08 You can configure the desired state you want to achieve. 03:11 Rather than issuing a series of commands to achieve that desired state Kubernetes will make your system conform to that desired state. 03:20 This greatly reduces the operational complexity of large systems. 03:24 Self-healing, Kubernetes can automatically replace containers that have failed or are failing a health check.

Answer 85

The Cloud Foundation toolkit is designed specifically to meet the compliance and security needs of enterprises. 06:49 By creating a foundational environment using these templates, you can be confident that best practices are implemented out of the box, including key security and governance controls. 06:59 With the Cloud Foundation toolkit, you don't need to spend time developing your own templates and patterns for Google Cloud. 07:05 Instead, you can build on open source templates and focus only on the customizations, which are unique to your company and workloads. 07:13 Developers can move faster and migrations are less time consuming. 07:19 Each template from the Cloud Foundation toolkit can be used independently.

Answer 86

The three correct statements are: ✅ By using Container Registry and Cloud Build, you can create build pipelines that are automatically triggered when you commit code to a repository. ✅ Cloud Build is a fully managed service. You do not need to download all build tools and container images to a build machine or manage build infrastructure. ✅ With Cloud Build, the artifacts produced by each build step are persisted in the /workspace folder and can be used by the following build step.

Answer 87

Terraform enables you to stand up infrastructure. You can treat infrastructure as code.

Answer 88

The two accurate statements about continuous integration (CI) and continuous delivery (CD) are: ✅ Continuous integration is a developer workflow in which developers frequently pull from the master and commit their changes into a feature branch in a source code repository. ✅ Continuous delivery is a workflow that is triggered when changes are pushed to the master repository.

Answer 89

There are two steps. The first step clones a GitHub repository. The second step builds a Docker image based on the contents of the repository.

Answer 90

The two correct statements about Terraform are: ✅ The Cloud Foundation Toolkit provides reference Terraform templates that reflect Google Cloud best practices. ✅ Terraform allows you to build and delete Google Cloud resources in a repeatable fashion.

Answer 91

Cloud Run is a fully managed serverless platform that also runs containerized applications. 01:51 Unlike with GKE, all infrastructure management for Cloud Run is abstracted away. 01:58 Cloud Run automatically scales up and down from zero almost instantaneously, depending on traffic. 02:06 You only pay when your code is running. 02:10 Cloud functions also lets you run your code in the cloud with zero management of servers or containers. 02:18 Write your event-driven code, and Google Cloud manages everything, scaling from zero to planet-scale.

Answer 92

Cloud Run can scale up and down almost immediately in response to traffic spikes. 07:21 Unlike App Engine, you only pay for Cloud Run when you are processing requests, rounded up to the nearest 10th of a second. 07:30 This pricing model can result in significant cost savings for your application. 07:36 App engine is fully supported and it works well for creating web applications and web APIs, but cloud run is often a better choice for those use cases. 07:47 Returning to the question "Where should I run my applications?", the best answer is that you should run each application on the platform that best fits its requirements. 07:59 Most applications written with the Cloud Client Libraries can be easily moved from platform to platform, so you can change your decision later. 08:08 If you do not have complex infrastructure requirements, start with a serverless platform that lets you focus on the application instead of the infrastructure. 08:18 If you later want more control over the infrastructure, you can move your application to a platform that requires more operational effort but provides the needed control or flexibility.

Answer 93

GKE (Google Kubernetes Engine) Fully managed Kubernetes service provided by Google Cloud. 🔹 Pros: Managed control plane – Google handles the Kubernetes master nodes, upgrades, and patches. Integrated monitoring & logging – Built-in with Google Cloud Operations. Auto-scaling, auto-upgrades, auto-repair – Cluster management is automated. Security – Native integration with IAM, workload identity, and private clusters. Easy setup – One command to spin up a production-ready cluster. Cost-effective options – Includes Autopilot mode where you only pay for running pods. 🔸 Cons: Less control over the master components. Slightly higher cost vs DIY in some environments.

Answer 94

You can describe the compute, memory, network, and storage resources that you want to make available across all the containers required by your applications.

Answer 95

Compute Engine gives you the most flexibility and control over the VM configuration — perfect for: Specialized applications Custom OS requirements High-performance workloads Custom kernel modules, drivers, or legacy dependencies

Answer 96

Applications that have a large and complex codebase Applications that must be run in a container

Answer 97

The ideal execution environment for a containerized application that: Requires automatic scaling And where you prefer not to manage compute infrastructure is: 🟢 Cloud Run ✅ Why Cloud Run? Runs containers (your app is already containerized) Fully managed – no infrastructure or cluster management Automatic scaling – from zero to thousands of instances Supports any language or framework Can be triggered via HTTP, Pub/Sub, etc. 🔍 Why Not the Others? Option Reason It's Less Ideal Cloud Functions Meant for small, function-based apps, not full containers Compute Engine Requires VM management, patching, scaling setup GKE (Kubernetes Engine) Powerful, but you must manage clusters, nodes, and scaling policies

Answer 98

Why Cloud Functions? It’s event-driven — perfect for responding to a Pub/Sub event. Automatically scales with demand. Ideal for small, single-purpose tasks like generating a thumbnail. No need to manage servers or infrastructure. Why not the others? ❌ Google Kubernetes Engine (GKE) Powerful but overkill for a simple event-driven task like this. More ops overhead. ❌ App Engine (flexible environment) Meant for long-running services — not optimized for quick event-driven responses. ❌ Compute Engine Too much manual setup for something lightweight. You’d need to handle instance management, scaling, etc.

Answer 99

Google Kubernetes Engine (GKE) ✅ Why GKE? Supports any network protocol (not just HTTPS) Can run hybrid deployments with on-prem via Anthos or VPN/Interconnect Offers full control over networking, container orchestration, and scaling Works well in multi-cloud and hybrid environments ❌ Why Not the Others? Option Limitations Compute Engine Supports custom protocols, but lacks built-in container orchestration and hybrid capabilities Cloud Functions Only supports HTTP/S or Pub/Sub triggers; no support for arbitrary protocols App Engine (Standard) Only supports HTTP/S; no custom protocol support or hybrid deployment

Answer 100

Answer: Cloud applications should be built for: Global reach (accessible to users worldwide), Scalability and high availability (elastic handling of traffic), Security (implementing best practices and complying with data isolation requirements).

Answer 101

Answer: External dependencies like JAR files or packages should not be stored in the repository because: They bloat the codebase, It’s better to declare them explicitly using dependency managers (e.g., npm for Node.js), It improves portability and manageability.

Answer 102

Answer: Store configuration settings as environment variables, not as constants in source code. This allows different values for dev, test, and production environments without changing code.

Answer 103

Answer: Easier to test, update, and deploy services independently, Services can be scaled separately, Clear mapping to business domains, Improved modularity and reduced interdependencies.

Answer 104

Answer: To reduce perceived slowness for the user, Asynchronous processing avoids delays from remote operations, Event-driven architectures (e.g., Cloud Run functions triggered by Cloud Storage) help manage load better.

Answer 105

Answer: Eventarc (event queue), Pub/Sub (message queue), These tools help with async processing and buffering during traffic spikes.

Answer 106

Answer: Consumers should loosely bind to payloads, Only use necessary fields (e.g., name and email), Avoid reliance on all payload fields to support backward compatibility when APIs evolve.

Answer 107

Answer: Shared state limits scalability, Stateless components allow for: Faster startup, Easier shutdown, Scalability using patterns like Workers or Cloud Run.

Answer 108

Answer: Retry logic with exponential backoff for transient errors, Circuit breakers for long-lasting errors, Graceful degradation (e.g., hiding unavailable features instead of showing errors).

Answer 109

Answer: If a recommendation engine fails, the app could hide the recommendation section instead of showing an error message to the user.

Answer 110

Answer: Caching improves application performance and reduces network latency by storing frequently accessed or computationally expensive data, allowing faster responses to user requests.

Answer 111

Answer: Cloud CDN caches web content using Google’s global edge network, enabling faster delivery of static content by serving it closer to users.

Answer 112

Answer: Apigee provides a proxy layer for backend APIs, offering features like security, rate limiting, analytics, and quotas, making backend services more accessible and manageable.

Answer 113

Answer: Instead of refactoring legacy systems, APIs can expose their functionality, allowing modern consumer apps to interact with them without relying on outdated protocols.

Answer 114

Answer: Logs are continuous streams of application events. Writing logs to stdout lets cloud infrastructure collect, analyze, and trace requests more efficiently, especially for serverless environments.

Answer 115

Answer: Delegate user authentication to external providers (e.g., Google, Facebook, GitHub) using tools like Identity Platform or Firebase Authentication, which support email/password, SAML, OIDC, and MFA.

Answer 116

Answer: It provides tools for logging, error reporting, monitoring, and logs-based metrics, helping monitor application health across multi-cloud environments.

Answer 117

Answer: CI/CD pipelines: Automate testing and deployment, Increase release speed and reliability, Reduce risk of regressions, Enable incremental rollouts and quick rollbacks.

Answer 118

Answer: CI: Automates build and testing on code commits. CD (Delivery): Prepares validated builds for manual deployment. CD (Deployment): Automatically deploys validated builds to production.

Answer 119

Answer: It’s an approach to migrate legacy systems by gradually replacing features with new services. A strangler facade routes requests to either the legacy or new system during the transition.

Answer 120

Answer: Blue-green deployments: Switch traffic between two environments. Canary testing: Gradually release to a subset of users to detect issues early.

Answer 121

Answer: Cloud Build: Detects commits, builds, and runs tests. Artifact Registry: Stores deployment artifacts. Cloud Deploy: Automates deployments to test and prod environments.

Answer 122

Answer: It reduces risk by allowing incremental changes, continuous learning, and avoids major disruptions to business-critical systems.

Answer 123

✅ Embed configuration settings in your source code ✅ Explanation: Embedding configuration settings in source code is considered an anti-pattern because: It reduces flexibility between environments (dev, test, prod). It increases the risk of exposing secrets or sensitive information. It makes updates and deployments more error-prone. Instead, configuration should be managed via environment variables or external configuration management systems. The other options are best practices: ✅ Asynchronous operations improve responsiveness and scalability. ✅ Caching boosts performance and reduces load. ✅ APIs and gateways modernize access to legacy systems securely and efficiently. Let me know if you'd like a full list of cloud app anti-patterns for review.

Answer 124

The correct answer is: ✅ Retry with exponential backoff ✅ Explanation: For transient network issues, the recommended approach is to retry the operation with exponential backoff, which means: Waiting longer between each retry attempt (e.g., 1s, 2s, 4s...). Adding jitter (randomness) to avoid request bursts. Prevents overloading the system and increases chances of recovery. ❌ The other options: Circuit breaker: Better for long-lasting or repeated failures, not short-lived issues. Display the error to the user: Avoid showing raw errors for transient issues; retry silently first. Retry constantly until the call succeeds: Bad practice. Can overload systems and lead to infinite loops or cascading failures.

Answer 125

Answer: Cloud APIs provide programmatic interfaces to Google Cloud services, allowing developers to access features like compute, networking, storage, and machine learning within their applications.

Answer 126

Answer: Cloud APIs can be called using: HTTP requests with JSON payloads, or gRPC requests, which use a compact and efficient binary format.

Answer 127

Answer: gRPC is an open-source remote procedure call (RPC) framework that: Can run across platforms, Uses an efficient binary request format, Offers high performance communication between services.

Answer 128

Answer: The caller must provide application credentials, which are used to authenticate and authorize access to Google Cloud projects and resources.

Answer 129

Answer: The Google Cloud SDK is a set of tools and libraries used to interact with Google Cloud products and services, either from the command line or through language-specific client libraries.

Answer 130

Answer: The SDK tools and libraries use Cloud APIs to send requests and manage resources in Google Cloud.

Answer 131

Answer: The bq CLI is used to interact with BigQuery, mainly for: Running SQL queries, Managing datasets, tables, and other BigQuery resources.

Answer 132

Answer: You can: Create, list, and delete buckets (gcloud storage buckets), Manage objects (gcloud storage objects), Copy, move, list, and delete objects.

Answer 133

Answer: gcloud storage is the preferred tool over gsutil, offering better performance and consistency with other gcloud commands.

Answer 134

Answer: Run: bash Copy Edit gcloud components install kubectl This installs the Kubernetes CLI component.

Answer 135

Answer: Use: bash Copy Edit gcloud components list This shows all components, including their installation and update status.

Answer 136

Answer: bash Copy Edit gcloud compute instances list This command lists all virtual machine instances in the current Google Cloud project

Answer 137

Answer: gcloud: Core tool for managing Google Cloud resources. gsutil: Manages Cloud Storage buckets and objects (being replaced by gcloud storage). bq: Manages BigQuery and runs SQL queries. kubectl: Manages Kubernetes clusters. Tools for emulating services (e.g., Firestore, Pub/Sub), and infrastructure management with Terraform.

Answer 138

Answer: You can: Manage virtual machines, Deploy applications, Create and configure resources like buckets, databases, and networks.

Answer 139

Answer: The gcloud CLI: Automates sending credentials in API calls, Combines multiple API calls into single commands for common tasks, Provides a user-friendly interface for managing resources.

Answer 140

Answer: The gcloud CLI is a command-line tool that allows users to manage Google Cloud services from the terminal or in automated scripts, offering a simpler interface to interact with Cloud APIs.

Answer 141

Answer: Because they: Are easier to use, Follow the natural coding style of each supported language, Automatically handle authentication, retries, and sometimes use gRPC APIs for performance.

Answer 142

Answer: Languages include: Python Node.js Java Go PHP Ruby C++ .NET languages, including C#

Answer 143

Answer: It uses default credentials, typically provided by a service account, to authenticate API calls

Answer 144

Answer: Using the Python Cloud Client Library, you can: Import the storage library, Instantiate a client with default credentials, Create a Cloud Storage bucket programmatically.

Answer 145

Answer: It initializes the Google Cloud SDK by setting up: A default configuration, Selected project and credentials, Command-line readiness to use gcloud tools.

Answer 146

Answer: Command prompt completion Command suggestions Interactive help, which streamlines the CLI experience

Answer 147

Answer: Yes, gcloud CLI commands are fully scriptable, making them ideal for automating deployment and resource management workflows.

Answer 148

Answer: Cloud Shell sessions terminate after 1 hour of inactivity, but your persistent disk is retained and reused in future sessions.

Answer 149

Answer: Cloud Shell includes a code editor based on Theia, allowing you to browse directories and edit files directly within your VM.

Answer 150

Answer: Cloud Code is a set of IDE plugins that streamline cloud application development by integrating: Deployment Debugging Kubernetes and Cloud Run workflows It’s available for Cloud Shell Editor, Visual Studio Code, and JetBrains IDEs (like IntelliJ and PyCharm).

Answer 151

Answer: Manage Cloud APIs and browse code samples, Integrate with Secret Manager, Simplify Kubernetes YAML authoring with autocomplete and inline docs, Develop and deploy Cloud Run services with emulators and explorers.

Answer 152

The correct answers are: ✅ Cloud Client Libraries support a language's natural conventions and styles. ✅ Cloud Client Libraries handle retry logic and authentication. ❓ Explanation of each option: ✅ Cloud Client Libraries support a language's natural conventions and styles. ✔️ True – They are designed to feel idiomatic in each supported language (e.g., Pythonic in Python, Java-style in Java). ❌ Cloud Client Libraries include the Cloud SDK. ✖️ False – The Cloud Client Libraries are separate from the Cloud SDK. The SDK includes tools like gcloud, not the language libraries. ❌ Cloud Client Libraries should only be used when you cannot call Cloud APIs directly. ✖️ False – The libraries are the recommended way to call Cloud APIs, not just a fallback. ❌ Cloud Client Libraries are provided in all languages that can be used on Google Cloud. ✖️ False – They are provided in many popular languages (like Python, Java, Node.js, etc.), but not all possible languages used on Google Cloud.

Answer 153

The correct answers are: ✅ Cloud Code integrates with Secret Manager to securely store sensitive data. ✅ Cloud Code works with both Cloud Run and Kubernetes applications. ❓ Explanation of each option: ❌ Cloud Code's YAML authoring assistance provides autocomplete and inline documentation for Docker files. ✖️ False – The YAML authoring assistance is designed for Kubernetes configuration files, not Dockerfiles. ✅ Cloud Code integrates with Secret Manager to securely store sensitive data. ✔️ True – Cloud Code lets you manage secrets like passwords and API keys securely from within your IDE. ✅ Cloud Code works with both Cloud Run and Kubernetes applications. ✔️ True – Cloud Code supports development, debugging, and deployment for Cloud Run and Kubernetes apps. ❌ Cloud Code is only available in the Cloud Shell editor. ✖️ False – It's available in multiple IDEs, including Cloud Shell Editor, Visual Studio Code, and JetBrains IDEs (like IntelliJ, PyCharm). ❌ Cloud Code is an integrated development environment for creating cloud applications. ✖️ False – Cloud Code is not an IDE itself; it's a plugin/extension that enhances existing IDEs for cloud development.

Answer 154

The correct answer is: ✅ BigQuery ✅ Explanation: BigQuery is a fully managed, serverless data warehouse built for: Complex queries OLAP (Online Analytical Processing) workloads Large-scale analytics Business intelligence tools It can handle terabytes to petabytes of data with high performance and scalability, making it ideal for your described use case. ❌ Why not the others? Bigtable: Best for single-keyed access, IoT, and time-series data, not complex analytical queries. Cloud SQL: Good for OLTP (transactional apps), but not optimized for large-scale analytics or BI workloads. Firestore: A NoSQL document database, great for mobile/web apps, but not designed for analytical queries or massive datasets.

Answer 155

The correct answer is: ✅ Spanner is ideal because it supports strongly consistent reads in addition to horizontal scalability, low latency, and high throughput. ✅ Explanation: Cloud Spanner is the best choice for a globally distributed, high-traffic banking application because it offers: Strong consistency (important for real-time balance updates), Horizontal scalability (supports many users worldwide), Low latency and high throughput, ACID-compliant transactions for reliable financial operations

Answer 156

The correct answer is: ✅ Serve the website's content from a Cloud Storage bucket. ✅ Explanation: Cloud Storage is the ideal solution for serving static website content like: Menus Business hours Location maps Images, HTML, CSS, and JavaScript files It’s: Cost-effective Scalable Simple to set up Can be combined with Cloud CDN for even faster delivery ❌ Why not the others? Bigtable: Designed for massive key-value data and analytics, not static websites. Compute Engine: Can host a web server, but it's overkill and more expensive for static content. Firestore: A NoSQL database for structured data, not for serving static files.

Answer 157

Answer: It means granting only the minimum permissions required for a user or service to perform their job—nothing more.

Answer 158

Answer: IAM principals include: Google Accounts (individual users) Service accounts (for applications or workloads) Google Groups Google Workspace accounts Cloud Identity domain users

Answer 159

Answer: A service account represents an application or compute workload, allowing code running in the cloud to authenticate and access Google Cloud resources securely.

Answer 160

Answer: ❌ No – Google Groups are for managing access policies, but they cannot be used to establish identity or make authenticated requests.

Answer 161

Answer: Both represent a collection of Google Accounts under an organization’s domain. Google Workspace includes access to productivity tools like Gmail and Docs. Cloud Identity does not include those apps, but both can manage permissions for Google Cloud resources.

Answer 162

Answer: A role is a collection of permissions. You assign roles to principals, and they inherit all the permissions in that role.

Answer 163

Answer: ❌ No – You must assign a role, and permissions are granted as part of that role.

Answer 164

Answer: Basic roles: Broad, project-wide (e.g., Viewer, Editor) Predefined roles: Granular, maintained by Google (e.g., run.invoker) Custom roles: User-defined for specific, fine-grained access control

Answer 165

Answer: When predefined roles are too permissive, and you want to enforce least privilege by selecting only the permissions needed for a specific task.

Answer 166

Answer: When predefined roles are too permissive, and you want to enforce least privilege by selecting only the permissions needed for a specific task.

Answer 167

Answer: BigQuery is a fully managed, serverless enterprise data warehouse designed for analytics. It supports: Machine learning Geospatial analysis Business intelligence (BI) It excels at OLAP workloads, scanning terabytes in seconds and petabytes in minutes

Answer 168

Answer: Big data exploration Real-time analytics Reporting with BI tools OLAP workloads

Answer 169

Answer: Read/write latency Typical data size Storage type (e.g., structured vs unstructured) Ideal vs non-ideal use cases Scalability and performance needs

Answer 170

Answer: Yes — by splitting your data into multiple databases, you can work around the size limits that apply to a single instance.

Answer 171

Answer: Spanner is a fully managed, horizontally scalable relational database offering: Strong consistency Multi-region replication 5-nines (99.999%) SLA It’s built for mission-critical OLTP applications.

Answer 172

Answer: Apps that need: Relational or semi-structured data High availability Strong consistency Transactional reads and writes at global scale

Answer 173

High performance PostgreSQL compatibility Automatic scaling and high availability AlloyDB Auth Proxy for secure access

Answer 174

Answer: It uses a local client proxy that securely connects to the Cloud SQL instance via a secure tunnel, removing the need to configure IPs or SSL certificates.

Answer 175

Answer: Cloud SQL is a managed relational database service that supports: MySQL PostgreSQL SQL Server It handles replication, backups, and failover automatically.

Answer 176

Answer: Supports billions of rows, thousands of columns Sparsely populated tables No downtime during reconfiguration HBase API compatibility

Answer 177

Answer: Bigtable is ideal for: Operational and analytical applications, Large-scale key-value lookups, Workloads requiring sub-10ms latency, such as user behavior tracking and IoT data ingestion.

Answer 178

Answer: Data is stored in documents, which are grouped into collections. Documents can contain nested objects and subcollections.

Answer 179

Answer: Firestore is a fully managed, serverless, NoSQL document database optimized for: Web and mobile apps, Real-time updates, Offline sync, Applications requiring flexible, hierarchical data structures.

Answer 180

Answer: Authentication verifies who you are (your identity). Authorization defines what you can do (your permissions), managed by IAM.

Answer 181

Answer: API keys – For low-security, read-only access. OAuth tokens for user accounts – Based on user login credentials. OAuth tokens for service accounts – Based on assigned IAM roles and key pairs.

Answer 182

Answer: Only for low-security, read-only APIs, since a compromised API key provides long-term access and is hard to revoke securely.

Answer 183

Answer: A service account represents an application or workload, not a person. It is identified by a unique email address and is used to authenticate and authorize programmatic access to Google Cloud resources.

Answer 184

Answer: Using an RSA public/private key pair, where the private key can be stored in a JSON key file. This key is used to generate access tokens.

Answer 185

Answer: Credential leakage – e.g., committing a key to a public repository. Privilege escalation – a bad actor could grant themselves more access. Identity masking – malicious activity might be attributed to the service account, hiding the real user.

Answer 186

Answer: Avoid using downloaded keys whenever possible. Use workload identity, attached service accounts, or Cloud IAM roles directly to authenticate securely.

Answer 187

Answer: Use the default service account or an attached service account with appropriate IAM roles, avoiding downloaded keys and using built-in mechanisms for secure authentication.

Answer 188

Answer: Whether the application is running on Google Cloud or outside Google Cloud.

Answer 189

Answer: Attach a user-managed service account directly to the Compute Engine instance or serverless service (like Cloud Run).

Answer 190

Answer: ✅ Workload Identity, which allo

Answer 191

Answer: Run: bash Copy Edit gcloud auth application-default login This generates user credentials that Application Default Credentials (ADC) can use for local development.

Answer 192

Answer: It allows applications running outside Google Cloud (e.g., on-premises or multi-cloud) to authenticate securely using external identity providers, without requiring a service account key.

Answer 193

Answer: ADC is a mechanism that automatically finds and uses the best available credentials for your application in a specific environment, in this order: GOOGLE_APPLICATION_CREDENTIALS environment variable Local user credentials (gcloud auth application-default login) Attached service account (on GCP)

Answer 194

Answer: They pose security risks, including: Credential leakage Privilege escalation Identity masking

Answer 195

Answer: gcloud auth login: Authenticates for CLI use (e.g., running gcloud commands). gcloud auth application-default login: Authenticates for code-level API access via ADC.

Answer 196

Answer: Secret Manager provides a secure and centralized way to store, manage, and access sensitive information like: API keys Passwords Certificates

Answer 197

The correct answer is: ✅ You can leverage federated identity management by using Firebase Authentication. ✅ Explanation: Firebase Authentication provides a secure, drop-in authentication system that supports: Federated identity providers (Google, Facebook, GitHub, etc.) Email/password sign-in Multi-factor authentication (MFA) User management out of the box It allows you to avoid building a custom auth system while securely managing user sign-in flows. ❌ Why not the others? OAuth 2.0: Used for delegated access to other services (e.g., access a user’s Google Drive), not primarily for sign-in to your own app. Giving employees read permissions: Irrelevant to user authentication; this is about IAM roles for project access. Identity-Aware Proxy (IAP): Best for controlling access to web apps for corporate/internal users, not for user authentication in public-facing applications.

Answer 198

Answer: Using "latest" retrieves the most recent version of the secret, which is helpful when your app always needs the current valid credential without specifying version numbers.

Answer 199

he correct answer is: ✅ You can use Identity-Aware Proxy to provide application-level access. ✅ Explanation: Identity-Aware Proxy (IAP) allows you to control access to web applications and VMs based on the identity of the user, without requiring a VPN. It: Authenticates users with Google Identity or other identity providers, Enforces access control policies, Provides secure, zero-trust access to apps from anywhere. This is ideal for secure remote access to internal applications like an expense reporting system. ❌ Why not the others? OAuth 2.0: Used for authorizing apps to access resources on behalf of a user, not for access control to internal apps. Firebase Authentication: Good for public-facing user auth, but not intended for enterprise access control to internal apps. Giving employees read permissions: Grants access to Google Cloud resources, not application-level access.

Answer 200

The correct answer is: ✅ Attach a service account to your application. ✅ Explanation: For production applications running on Cloud Run, the recommended and secure method is to: Attach a service account with the minimum required IAM permissions to the Cloud Run service. This allows Application Default Credentials (ADC) to automatically detect and use the attached service account without needing to manage keys. ❌ Why not the others? Use a service account key: ❌ Not recommended — managing and securing keys is risky and error-prone. Use "gcloud auth application-default login": ❌ Intended for local development, not production. Use workload identity federation: ❌ Used for external environments (on-premises or multi-cloud), not needed for apps running within Google Cloud.

Answer 201

Answer: ✅ Yes — You can use tools like TensorFlow, PyTorch, or Vertex AI to build and deploy custom models tailored to your business needs.

Answer 202

This allows: Easy integration with web and mobile apps, No need for machine learning expertise or model training, Language-agnostic implementation. ❌ Why not the others? Google Cloud Console: Used for testing or managing APIs, not for programmatic invocation in apps. gcloud CLI: Useful for setup or one-time commands, but not meant for application logic. TensorFlow: Used for building and training custom ML models, not for calling pre-trained APIs.

Answer 203

The correct answer is: ✅ Use the REST API. ✅ Explanation: Pre-trained ML APIs like Vision API, Natural Language API, Speech-to-Text, and Translation API are designed to be invoked via REST APIs from your application. You send a JSON request and receive a JSON response. This allows: Easy integration with web and mobile apps, No need for machine learning expertise or model training, Language-agnostic implementation. ❌ Why not the others? Google Cloud Console: Used for testing or managing APIs, not for programmatic invocation in apps. gcloud CLI: Useful for setup or one-time commands, but not meant for application logic. TensorFlow: Used for building and training custom ML models, not for calling pre-trained APIs.

Answer 204

The correct answer is: ✅ Video Intelligence API ✅ Explanation: The Video Intelligence API is specifically designed to: Label entities in videos, Detect entities at the video, shot, or frame level, Annotate video files stored in Cloud Storage, Help identify what appears in the video and when it appears. Perfect for use cases like: Content tagging Search and retrieval Content moderation

Answer 205

The correct answers are: ✅ Continuous delivery is a workflow that is triggered when changes are pushed to the main branch in the repository. ✅ If all tests pass, builds generated from continuous integration in a feature branch can be released on a production environment. ✅ Explanation of correct answers: Continuous delivery means that validated builds (after passing CI tests) are automatically prepared for deployment when changes reach the main branch. With CI, builds from feature branches are tested and can be released to production if tests pass and policies allow, typically via manual approval or automated CD. ❌ Why the other options are incorrect: "Developers must use GitHub" – ❌ False. CI/CD works with many version control systems, not just GitHub (e.g., GitLab, Bitbucket, Cloud Source Repositories). "Google Cloud pipelines automatically provide best security practices" – ❌ False. While Google Cloud provides tools for secure CI/CD, you must configure and enforce best security practices (e.g., secrets management, artifact signing, access control). "CI means developers pull from main and commit to a feature branch" – ❌ Misleading. In CI, developers typically commit to feature branches, but CI builds are triggered when changes are pushed to the shared branch, not just based on pull actions.

Answer 206

he correct answers are: ✅ With Cloud Build, the artifacts produced by each build step are persisted in the /workspace folder and can be used by the following build step. ✅ By using Artifact Registry and Cloud Build, you can create build pipelines that are automatically triggered when you commit code to a repository. ✅ Explanation of correct answers: Cloud Build /workspace folder: Each build step runs in a container, but they all share the /workspace directory. This allows intermediate files or artifacts to pass between steps. Cloud Build + Artifact Registry: You can set up triggers so that builds run automatically when code is committed. Cloud Build can build and test the app, then push container images or other artifacts to Artifact Registry.

Answer 207

Answer: When developers commit code to a feature branch, a service like Cloud Build is triggered to build the application.

Answer 208

Answer: The code is built and container images are created. Images are deployed to staging (e.g., GKE or Cloud Run) for integration and performance tests. If tests pass, the build is marked as a release candidate and may be manually approved for production deployment.

Answer 209

Answer: It helps track application performance in production, so you can validate new deployments or roll back quickly if issues arise.

Answer 210

Answer: A fully managed, end-to-end software supply chain security solution that protects every stage of the CI/CD process.

Answer 211

Answer: Binary Authorization uses attestations to ensure only trusted, verified images are deployed. It enforces policies to block unverified images from being released.

Answer 212

Answer: It scans artifacts in Artifact Registry for vulnerabilities, offering on-demand and automated scanning for container images and packages like Maven and Go.

Answer 213

The correct answer is: ✅ Saturation, Latency, Traffic, Errors ✅ Explanation: These four signals are part of the "Golden Signals" of monitoring, which are widely recommended by Google’s Site Reliability Engineering (SRE) practices. They help ensure your application’s health and performance: Saturation – How full your system is (e.g., CPU, memory, queue usage). Latency – Time taken to process a request. Traffic – Demand on the system (e.g., number of requests per second). Errors – Rate of failed requests. ❌ Why the others are incorrect: Security and Contrast are not among the golden signals. Throttling might be a useful metric in some contexts but is not one of the core four golden signals.

Answer 214

You want to stream logs into Cloud Logging from third-party applications running on Compute Engine instances. What service should you consider? Cloud Monitoring Cloud Trace Error Reporting Ops Agent

Answer 215

The correct answer is: ✅ Error Reporting ✅ Explanation: Error Reporting automatically aggregates and analyzes errors from your applications and displays: Stack traces Error frequency Affected services and versions Notifications and alerts This helps you quickly identify, triage, and debug application issues.

Answer 216

The correct answer is: ✅ Ops Agent ✅ Explanation: The Ops Agent is the recommended agent for collecting both logs and metrics from third-party applications and system services running on Compute Engine instances. It is: Optimized for performance Capable of structured and unstructured log ingestion Fully integrated with Cloud Logging and Cloud Monitoring ❌ Other options explained: Cloud Trace: Used for analyzing request latency, not for log streaming. Cloud Monitoring: Visualizes metrics but does not collect logs directly from applications. Error Reporting: Aggregates and displays application errors, but relies on logs being ingested—it doesn't collect logs itself.

Answer 217

he correct answers are: ✅ Responds to events that occur in your cloud infrastructure ✅ Uses event triggers for various services like Pub/Sub, and Cloud Storage ✅ Can be triggered from Eventarc sources ✅ Explanation of correct answers: Responds to events that occur in your cloud infrastructure: Event-driven functions react to changes such as file uploads, database updates, or Pub/Sub messages. Uses event triggers for various services like Pub/Sub, and Cloud Storage: Google Cloud Functions and Cloud Run can be triggered by native events from services like Pub/Sub, Cloud Storage, Firestore, etc. Can be triggered from Eventarc sources: Eventarc routes events from a wide range of sources (e.g., Firebase, Cloud Audit Logs, custom apps) to services like Cloud Run and Cloud Functions.

Answer 218

The correct answers are: ✅ Is integrated with Cloud Logging ✅ Is a scalable functions-as-a-service platform ✅ Can be used to extend Cloud services ✅ Explanation of correct answers: Is integrated with Cloud Logging: Cloud Run automatically writes logs to Cloud Logging, making it easy to monitor and debug services. Is a scalable functions-as-a-service platform: Cloud Run is serverless, meaning it scales automatically based on incoming requests — from zero to thousands of instances. Can be used to extend Cloud services: Cloud Run can be triggered by Eventarc, Pub/Sub, or HTTP requests, making it great for extending services like Cloud Storage, Firestore, or even third-party APIs.

Answer 219

The correct answers are: ✅ Can be integrated with Cloud databases ✅ Supports seamless authentication with IAM ✅ Are triggered by HTTP requests and events from Cloud Services ✅ Can be locally developed and tested ✅ Explanation of correct answers: Can be integrated with Cloud databases: Cloud Run functions can easily connect to services like Cloud SQL, Firestore, and BigQuery using environment variables and client libraries. Supports seamless authentication with IAM: Cloud Run integrates with IAM to control who can invoke your service and access other Google Cloud services securely. Are triggered by HTTP requests and events from Cloud Services: Cloud Run services can be invoked via HTTP, or automatically triggered by events using Eventarc, Pub/Sub, or Cloud Scheduler. Can be locally developed and tested: You can run Cloud Run containers locally using tools like the Cloud SDK (gcloud), Docker, or Cloud Code in VS Code/JetBrains. ❌ Incorrect option: Uses a fixed pricing model – ❌ False Cloud Run uses pay-per-use pricing, based on the actual resources consumed (CPU, memory, requests, and execution time). It scales to zero when idle. Would you like a development template or guide for setting up local testing of a Cloud Run function? You said: An HTTP function: (Select three). Can be used to implement a webhook. Can only be invoked with authentication credentials. Is triggered by a request made to its URL endpoint. Must send back an HTTP response. ChatGPT said: The correct answers are: ✅ Can be used to implement a webhook ✅ Is triggered by a request made to its URL endpoint ✅ Must send back an HTTP response ✅ Explanation of correct answers: Can be used to implement a webhook: HTTP functions are ideal for webhooks, since they respond to incoming HTTP requests from external systems. Is triggered by a request made to its URL endpoint: Every HTTP function has a public (or secured) URL that clients use to trigger the function. Must send back an HTTP response: HTTP functions are request-response based and must return a response, such as a status code, message, or data. ❌ Incorrect option: Can only be invoked with authentication credentials – ❌ False While authentication can be required (based on IAM settings), you can configure HTTP functions to allow unauthenticated access (e.g., for public APIs or webhooks). Would you like a sample HTTP function setup in Python or Node.js?

Answer 220

The correct answers are: ✅ Can be used to implement a webhook ✅ Is triggered by a request made to its URL endpoint ✅ Must send back an HTTP response ✅ Explanation of correct answers: Can be used to implement a webhook: HTTP functions are ideal for webhooks, since they respond to incoming HTTP requests from external systems. Is triggered by a request made to its URL endpoint: Every HTTP function has a public (or secured) URL that clients use to trigger the function. Must send back an HTTP response: HTTP functions are request-response based and must return a response, such as a status code, message, or data. ❌ Incorrect option: Can only be invoked with authentication credentials – ❌ False While authentication can be required (based on IAM settings), you can configure HTTP functions to allow unauthenticated access (e.g., for public APIs or webhooks).

Answer 221

Answer: An idempotent function produces the same result when called multiple times, which is essential for safely retrying failed invocations without side effects.

Answer 222

Answer: Because the CPU becomes inaccessible after the function terminates. Any lingering activity could interfere with subsequent invocations, causing errors and unexpected behavior.

Answer 223

Answer: The temp files are stored in in-memory storage, which persists between invocations. Not deleting them may lead to memory exhaustion and cold starts.

Answer 224

Answer: HTTP functions must always return an HTTP response. Event-driven functions should return or report an error explicitly. Avoid using process.exit() (Node.js) or sys.exit() (Python).

Answer 225

Answer: Cold starts occur when a function instance needs to be initialized from scratch. You can reduce them by: Avoiding unnecessary imports Using global variable caching Setting a minimum instance count

Answer 226

Answer: Because the function environment is reused between invocations, caching reduces connection overhead and improves performance.

Answer 227

Answer: Use the --retry flag during deployment or enable the Retry on failure option in the Cloud Console.

Answer 228

Answer: Retries are good for transient errors (e.g., timeouts, network failures), but should be avoided for persistent bugs, which would cause infinite retry loops unless conditions are added to stop them.

Answer 229

Answer: Follow the principle of least privilege Use user-managed service accounts instead of default ones Assign minimal necessary permissions to each function

Answer 230

Answer: You can configure a function to handle multiple simultaneous requests per instance. This reduces cold starts but requires your code to be thread-safe and stateless.

Answer 231

Answer: A new immutable revision is created. By default, all traffic routes to the latest revision, but you can split traffic between revisions or roll back to a previous one.

Answer 232

Answer: Instances scale up or down based on traffic You can set min and max instance counts per revision More than the max may be briefly allowed during rollout

Answer 233

✅ Select one. A. Previous revision is overwritten B. A new revision is created C. All traffic is paused D. Scaling is reset to zero ✅ Correct Answer: B Explanation: Each deployment creates a new, immutable revision of the function.

Answer 234

✅ Select one. A. To enable auto-scaling B. To give each function minimal, isolated access C. To support concurrency D. To reduce memory usage ✅ Correct Answer: B Explanation: User-managed service accounts allow granular access control per function.

Answer 235

✅ Correct Answer: C Explanation: Use the --retry flag or console option to enable retries for event-driven functions.

Answer 236

✅ Select one. A. Application bugs B. Authentication errors C. Transient errors like network timeouts D. Missing environment variables ✅ Correct Answer: C Explanation: Transient issues (e.g., timeouts or unreachable services) often succeed on retry.

Answer 237

✅ Select two. A. Load only necessary dependencies B. Initialize all variables globally C. Cache connections and clients in global scope D. Use process.exit() to clean up faster ✅ Correct Answers: A, C Explanation: Avoiding unnecessary imports and caching expensive objects improves cold start performance.

Answer 238

? ✅ Select one. A. Too many concurrent requests B. Retrying failed invocations C. Creating and initializing a new execution environment D. Logging to Cloud Logging ✅ Correct Answer: C Explanation: A cold start happens when a new instance of a function needs to be initialized.

Answer 239

✅ Select one. A. Use process.exit() or sys.exit() B. Let the function time out C. Throw an exception D. Return explicitly or implicitly ✅ Correct Answer: D Explanation: Explicit or implicit return is recommended. Forceful exits may cause errors.

Answer 240

✅ Select one. A. It triggers autoscaling B. It causes memory leaks and cold starts C. It blocks incoming requests D. It prevents retries ✅ Correct Answer: B Explanation: Files persist between invocations and consume memory, possibly causing cold starts.

Answer 241

✅ Correct Answer: C Explanation: HTTP functions must always send a response; otherwise, they run until timeout.

Answer 242

Correct Answer: B Explanation: Idempotent functions return the same result when called multiple times, making retries safe.

Answer 243

The three correct statements about using environment variables with Cloud Run functions are: ✅ Are provided during function deployment. ✅ Are key-value pairs that are accessed by the function code at runtime. ✅ Can be stored in a YAML file, whose filename can be provided during function deployment. ✅ Explanation: Provided during function deployment: You can define environment variables using the --set-env-vars flag in the gcloud CLI or via the Cloud Console when deploying a function. Key-value pairs accessible at runtime: The function accesses these environment variables using standard language-specific methods (e.g., os.environ['VAR_NAME'] in Python). Stored in a YAML file: You can store environment variables in a YAML or .env.yaml file and load them during deployment using --env-vars-file.

Answer 244

The two correct statements are: ✅ A function can be triggered when a Firestore document is created, updated, or deleted. ✅ To trigger a function, you must specify an event type and the document path. ✅ Explanation: Firestore triggers support events such as create, update, delete, and write on documents. To set up a trigger, you must define: An event type (e.g., create) A document path (e.g., users/{userId}) ❌ Incorrect statements: "A function can only be triggered on changes to an individual Firestore document" – ❌ You specify a document path pattern, so triggers can apply to multiple documents using wildcards (e.g., users/{userId}). "A function cannot be triggered when a Firestore document is deleted" – ❌ Deletion events are supported. "A function can be triggered when a specific field in a Firestore document is changed" – ❌ Firestore triggers operate at the document level, not at the field level.

Answer 245

The two correct methods of making a secret available to a Cloud Run function are: ✅ Mount the secret as a volume so that the function can access the secret from a file. ✅ Provide the secret as an environment variable when deploying the function. ✅ Explanation: Mount as a volume: You can mount a secret from Secret Manager as a file inside the container, allowing the function to read it at runtime. Environment variable: You can inject secrets as environment variables when deploying the function using the --set-secrets flag (e.g., gcloud run deploy --set-secrets). ❌ Incorrect statements: "Provide the secret name and value as query parameters to the function" – ❌ This is insecure and not recommended. Secrets should never be passed in query strings. "Secrets cannot be accessed from Cloud Run functions" – ❌ Cloud Run functions can securely access secrets from Secret Manager.

Answer 246

✅ Correct Answer: C Explanation: Workflows is a serverless orchestration platform for coordinating services and APIs in a defined sequence.

Answer 247

✅ Correct Answers: A, C Explanation: Workflows can be defined in YAML or JSON format.

Answer 248

✅ Correct Answer: B Explanation: Serverless VPC Access lets Cloud Run functions communicate securely with resources like VMs or Memorystore using internal IPs.

Answer 249

✅ Correct Answers: A, B, D Explanation: You must enable the API Create and configure a connector in the correct region The connector must be in the same region as the function

Answer 250

he three correct statements about Cloud Run function triggers are: ✅ Multiple functions can be triggered by the same trigger settings. ✅ Triggers are specified during function deployment. ✅ An event trigger reacts to cloud events. ✅ Explanation: Multiple functions can be triggered by the same trigger settings → Yes, multiple functions can listen to the same event source, like a Pub/Sub topic or Cloud Storage bucket. Triggers are specified during function deployment → When deploying a function, you define the trigger type and source using the Google Cloud Console or gcloud CLI. An event trigger reacts to cloud events → Event triggers use Eventarc to react to events from services like Firestore, Cloud Storage, Pub/Sub, etc.

Answer 251

The three correct statements about Workflows are: ✅ Workflows is serverless. ✅ Workflows can combine services or functions hosted on Cloud Run. ✅ A workflow step can be defined to make an HTTP call to a URL. ✅ Explanation: Workflows is serverless → It runs in a fully managed environment, requiring no infrastructure management. Workflows can combine services or functions hosted on Cloud Run → You can orchestrate Cloud Run, Cloud Functions, external APIs, and other Google Cloud services. A workflow step can be defined to make an HTTP call to a URL → Workflows can invoke HTTP endpoints, including Cloud Run functions or third-party services.

Answer 252

he two correct reasons for using Serverless VPC Access are: ✅ To connect Cloud Run functions to internal resources in a VPC network. ✅ To send requests and receive responses using internal DNS and IP addresses. ✅ Explanation: Connect to internal resources → Serverless VPC Access enables Cloud Run functions to reach internal services like Compute Engine VMs, Memorystore, or private databases that aren’t exposed to the internet. Use internal DNS/IPs → It ensures communication stays private by allowing functions to resolve and access resources via internal IPs and DNS. ❌ Incorrect reasons: "To expose requests and responses to and from a VPC network to the internet" → This is the opposite of what Serverless VPC Access is meant for—it enables private, not public, connectivity. "To enable Cloud Run functions to access external HTTP endpoints" → Cloud Run functions can already access external endpoints without Serverless VPC Access.

Answer 253

The two correct statements about an HTTP trigger are: ✅ Enables a function to respond to HTTP requests. ✅ Generates a URL when it is assigned to a function. ✅ Explanation: Enables a function to respond to HTTP requests → HTTP triggers are used to invoke Cloud Run functions via GET, POST, PUT, DELETE, etc. Generates a URL → When an HTTP trigger is assigned, Cloud Run automatically generates an HTTPS endpoint for the function. ❌ Incorrect statements: "Does not support the DELETE HTTP request method" → ❌ Incorrect — HTTP triggers do support all standard methods including DELETE. "Enables a function to respond to events from cloud infrastructure" → ❌ Incorrect — That applies to event-driven triggers (e.g., Pub/Sub, Firestore, Cloud Storage), not HTTP triggers.

Answer 254

Correct Answers: B, C Explanation: Identity-based controls (IAM) handle who can access, while network-based controls manage from where functions can be invoked.

Answer 255

Correct Answer: B Explanation: OAuth 2.0 access tokens are used for authenticating API calls to Cloud Run.

Answer 256

✅ Correct Answer: C Explanation: The Cloud Functions Invoker role (roles/cloudfunctions.invoker) allows calling HTTP functions.

Answer 257

✅ Correct Answer: C Explanation: The Google-signed ID token must include the audience field (aud) set to the receiving function’s URL.

Answer 258

✅ Correct Answer: C Explanation: Always use a custom service account in production with only the minimum required permissions.

Answer 259

✅ Correct Answer: C Explanation: CMEKs let you manage encryption for data at rest used by Cloud Run functions.

Answer 260

✅ Correct Answer: C Explanation: If a CMEK is disabled or destroyed, access to the protected data is permanently blocked.

Answer 261

✅ Correct Answers: B, C Explanation: CMEK encrypts:

Answer 262

✅ Correct Answers: B, D Explanation: You must: Grant service accounts access to the key Create a CMEK-enabled Artifact Registry in the same region as your function

Answer 263

✅ Correct Answer: D Explanation: CMEKs are stored using Cloud KMS, not directly in Cloud Storage.

Answer 264

The three correct statements about function identity are: ✅ Every function is associated with a runtime service account that serves as its identity. ✅ The App Engine default service account is used as the default runtime service account for Cloud Run functions (1st gen). ✅ The Compute Engine default service account is used as the default runtime service account for Cloud Run functions. ❌ Incorrect statement: "In production environments, you should use a runtime service account for a function’s identity with the maximum set of permissions." 🚫 Incorrect: In production, you should follow the principle of least privilege and assign only the minimum required permissions to the service account.

Answer 265

The correct answer is: ✅ Egress setting to route all traffic through a Serverless VPC connector. ✅ Explanation: Egress settings control outbound traffic from Cloud Run functions. To route all outbound traffic through a VPC network, you must use: Egress setting: "All traffic" with a Serverless VPC Access connector. ❌ Incorrect options: "Ingress setting to allow internal traffic and traffic from Cloud Load Balancing" → Ingress controls incoming traffic, not outbound. "Ingress setting to allow all traffic" → Again, this is about who can call your function. "Egress setting to route traffic only to private IPs through a Serverless VPC connector" → This routes only private traffic through the connector—not all traffic.

Answer 266

When a Customer-Managed Encryption Key (CMEK) is disabled or destroyed: New function instances cannot be created because Cloud Run cannot decrypt the function's container image or configuration data. As a result, any execution that triggers the creation of a new instance will fail. However, already-running (active) instances may continue to work as long as they don’t require access to encrypted resources. ❌ Incorrect options: "Executions of the function that are already in progress are terminated" → Not necessarily. Already-running instances can continue if no additional decryption is needed. "There is no impact to the function" → ❌ Disabling or destroying the key definitely impacts new deployments or scaling. "Active instances of the function are shut down" → Active instances are not immediately shut down, but future operations may fail.

Answer 267

The correct answers are: ✅ Use network-based access controls. ✅ Use identity-based access controls. ✅ Explanation: To limit access to Cloud Run functions, you can use: Identity-based access controls Uses IAM roles and permissions to control who can invoke or manage your functions. Example: Assigning the roles/cloudfunctions.invoker role to specific users or service accounts. Network-based access controls Configure ingress settings to allow only internal traffic or traffic through Cloud Load Balancing. You can also use VPC Service Controls for added protection. ❌ Incorrect options: Use an encryption key → Encryption (e.g., CMEK) protects data at rest, not access control. Use a username and password → Not a supported authentication method for Cloud Run functions. Use HTTPS → HTTPS encrypts communication, but doesn't restrict access by itself.

Answer 268

The correct answers are: ✅ Cloud Functions Developer ✅ Cloud Functions Viewer ✅ Cloud Functions Invoker ✅ Cloud Functions Admin ✅ Explanation of each role: Cloud Functions Admin (roles/cloudfunctions.admin) Full control over Cloud Functions, including deploy, update, and delete. Cloud Functions Developer (roles/cloudfunctions.developer) Can create and update functions but cannot delete them or change IAM policies. Cloud Functions Viewer (roles/cloudfunctions.viewer) Read-only access to view function metadata and configurations. Cloud Functions Invoker (roles/cloudfunctions.invoker) Allows invoking (executing) Cloud Functions — often used for HTTP or event-driven triggers. ❌ Incorrect option: Cloud Functions Reader → ❌ Not a valid predefined IAM role in Google Cloud.

Answer 269

The correct answers are: ✅ Allocate the minimum set of permissions required to develop and use your functions. ✅ Ensure that a function sends requests only to a subset of your other functions that are needed to perform its job. ✅ Limit the number of user and service accounts that can access the function. ✅ Explanation of each best practice: Minimum Permissions (Principle of Least Privilege): Grant only the exact permissions needed—nothing more. This minimizes risk. Targeted Communication Between Functions: Functions should only talk to specific other functions they actually need to interact with. This improves security and clarity of access paths. Limit Access: Fewer service accounts and users with access reduces the attack surface and enforces better control.

Answer 270

The correct answers are: ✅ Remove any unused dependencies from the function source. ✅ In your function code, reuse objects with global variables. ✅ Set a minimum number of instances when deploying your function. ✅ Explanation of each best practice: Remove unused dependencies: Reduces cold start time and deployment size, improving overall function performance. Reuse objects with global variables: Caching expensive resources (like DB connections or API clients) in the global scope allows them to be reused across invocations, reducing latency. Set a minimum number of instances: Keeps a certain number of instances "warm" and ready to serve requests, which reduces cold starts. ❌ Incorrect option: "Initialize global variables in your function code eagerly" → ❌ Wrong. You should initialize them lazily, only when needed, to reduce cold start latency.

Answer 271

The correct answers are: ✅ If enabled, causes the function to be retried on failure for up to 7 days. ✅ Can be enabled or disabled in Google Cloud console or with the gcloud CLI. ✅ Explanation: Retries for up to 7 days: If retries are enabled, event-driven functions will retry failures automatically for up to 7 days or until successful execution. Configuration methods: You can enable or disable retry behavior during deployment via: Google Cloud Console (checkbox) gcloud CLI using the --retry flag ❌ Incorrect options: "Is enabled by default" → ❌ Retry is disabled by default. You must explicitly enable it. "Is supported for both HTTP and event-driven functions" → ❌ Retry is only supported for event-driven functions, not HTTP functions.

Answer 272

The correct answer is: ✅ Set the minimum and maximum number of function instances during deployment. ✅ Explanation: Cloud Run functions scale automatically, but you can control their scaling behavior by: Setting a minimum number of instances to keep some instances warm and reduce cold starts. Setting a maximum number of instances to avoid overwhelming downstream services (e.g., databases) or limit cost. You can configure this during deployment using: The Google Cloud Console, or The gcloud CLI with flags like --min-instances and --max-instances. ❌ Incorrect options: "Because there are no servers to manage, functions cannot be scaled." → ❌ False. Serverless functions do scale, and you can control that behavior. "Use a common configuration to control the scaling behavior of all of your functions." → ❌ Scaling is configured per function, not globally. "Function scaling is handled automatically and cannot be controlled." → ❌ While scaling is automatic, it can be tuned with min/max instance settings.

Answer 273

The correct answer is: ✅ You can split traffic between different revisions of a function. ✅ Explanation: Cloud Run creates a new revision each time you deploy a function. Revisions are immutable — you cannot change a revision once deployed. You can roll back by routing traffic to a previous revision. You can also split traffic between revisions (e.g., 90% to new, 10% to old) for canary deployments or gradual rollouts. ❌ Incorrect options: "You cannot roll back a function to a prior revision." → ❌ False. You can roll back by re-routing traffic. "When a function is deployed, a new revision is not automatically created." → ❌ False. Every deployment creates a new revision. "You can change an existing revision of a deployed function." → ❌ False. Revisions are immutable — any changes require a new deployment.

Answer 274

The correct answers are: ✅ Persistent HTTP connections. ✅ Serverless VPC Access connectors to connect your cloud function to project resources. ✅ Explanation: Persistent HTTP connections: Reusing connections reduces CPU time and improves latency by avoiding repeated connection setups on each invocation. Serverless VPC Access connectors: Allow functions to access internal resources (like databases or VMs) within a VPC using internal IPs and DNS, keeping traffic secure and private. ❌ Incorrect option: "Local scope to initialize and store network connections and API client objects." → ❌ While global scope is preferred to cache objects across invocations, local scope does not help with connection reuse or performance optimization.

Answer 275

The correct answer is: ✅ A. Instrument your microservices by installing the OpenTelemetry tracing package. Update your application code to send traces to Trace for inspection and analysis. Create an analysis report on Trace to analyze user requests. ✅ Why A is correct: Cloud Trace (part of Google Cloud Operations) is designed specifically to analyze latency and performance of distributed systems. OpenTelemetry is a standard way to collect traces and metrics across microservices. Traces help you visualize request paths, identify slow spans, and pinpoint bottlenecks in complex applications. ❌ Why the others are not ideal: B. Cloud Logging is useful for debugging and diagnostics, but not optimized for latency analysis or tracing across distributed microservices. C. Cloud Monitoring dashboards are great for system-level metrics (CPU, memory, etc.), but won’t give you per-request span data for identifying slow paths in HTTP requests. D. tcpdump/Wireshark provides very low-level network traffic data. It's not scalable or appropriate for application-level latency investigation in microservices, and not viable in managed environments like GKE.

Answer 276

The correct answer is: ✅ A. Host the application on GKE, and use Identity-Aware Proxy (IAP) with Cloud Load Balancing and Google-managed certificates. ✅ Why A is correct: This approach meets all the requirements: Managed services: GKE, Cloud Load Balancing, Google-managed SSL certificates, and IAP are all managed. Authentication: Identity-Aware Proxy (IAP) offloads authentication and access control at the load balancer layer, so you don’t have to build it into your app. SSL offload: Google-managed certificates terminate SSL at the global load balancer, offloading encryption/decryption from your app. Scalability and security: This architecture is scalable, secure, and aligned with best practices for zero-trust networking.

Answer 277

The correct answer is: ✅ B. Configure the sender application to publish the outgoing emails in a message to a Pub/Sub topic. Update the Cloud Run function configuration to consume the Pub/Sub queue. ✅ Why B is the best option: Pub/Sub decouples the sender from the email-sending process, making the system more resilient. Messages published to Pub/Sub are persisted until successfully acknowledged, reducing the chance of email loss. Cloud Run can be triggered by Pub/Sub, which is designed for event-driven, at-least-once delivery — ideal for background tasks like sending emails. This pattern is asynchronous, scalable, and fault-tolerant. ❌ Why the other options are not ideal: A. Increase the Cloud Run function’s timeout to nine minutes → ❌ This only helps for long-running processes, but does not prevent email loss if the function fails or the service returns HTTP 500 errors. C. Retry every one second if a request fails → ❌ Aggressive retries can cause rate-limiting or overload, and manual retry logic is brittle. Better to use Pub/Sub’s built-in retry capabilities. D. Use Memorystore to queue messages → ❌ Memorystore (Redis) is not a message queue. It lacks durability guarantees and is not designed for message-based triggering or retry logic.

Answer 278

The correct answer is: ✅ A. Generate a signed URL that grants read access to the bucket. Allow users to access the URL after authenticating through your web application. ✅ Why A is the best option: Signed URLs allow you to grant temporary, time-limited access to specific Cloud Storage objects without requiring the user to have a Google Account. You can generate the URL after authenticating the user through your app, giving you full control over access logic. Ideal for anonymous users and private media that needs access control. ❌ Why the other options are not ideal: B. Configure Identity-Aware Proxy (IAP) → ❌ IAP requires users to have a Google identity, which is not suitable for anonymous users. C. Grant the Storage Object Viewer IAM role to allUsers → ❌ This makes the bucket public to the internet, defeating the purpose of access control. D. Use Cloud Armor with named IP list → ❌ IP-based access control is inflexible and insecure, especially for anonymous, internet-wide users. It also doesn’t protect individual object access.

Answer 279

✅ Correct answer: C. Create a new Cloud Spanner instance for every build. Load the required data. Delete the Cloud Spanner instance after the test is complete. ✅ Why C is correct: Cloud Spanner is a global, strongly consistent, horizontally scalable database. To avoid test interference and support parallel test execution, isolated environments are essential. Creating a dedicated Cloud Spanner instance per build ensures: No concurrency issues between builds Clean state for each test Accurate performance evaluation Spanner instances are ephemeral in this context—created before the test, destroyed after. ❌ Why the other options are less ideal: A. Restore data after each test in a shared instance ❌ Risk of race conditions and interference between concurrent builds. ❌ Adds complexity and overhead in state management. B. Create a new project for every build ❌ Project creation is slow (can take minutes). ❌ Introduces unnecessary resource management complexity (IAM, billing, quotas). D. Use the Cloud Spanner emulator ❌ The emulator is not suitable for performance testing. It does not replicate Spanner's scalability, consistency, or performance characteristics. Would you like a sample Cloud Build YAML that sets this up for testing Spanner instances?

Answer 280

Here’s why B is the best choice: ✅ Cloud Service Mesh (such as Anthos Service Mesh or Istio) provides advanced traffic management features, like: A/B testing and canary deployments Traffic splitting based on weights Fine-grained routing rules and observability ✅ This setup allows you to: Deploy two versions of the app simultaneously. Send a small portion of traffic to the new version (e.g., 10%). Validate the behavior in production without affecting most users. Perform a gradual rollout or rollback depending on test re

Answer 281

Correct answer: A. Cloud Run 🧠 Reasoning: You need to choose a compute option that: Handles persistent gRPC connections Scales rapidly to handle bursty traffic (e.g., paydays) Supports long-lived sessions (up to 30 minutes) Has low operational overhead and cost Doesn't require managing infrastructure manually 🔍 Option Analysis: A. Cloud Run — ✅ Best Fit ✅ Supports gRPC natively, including bidirectional streaming ✅ Automatic scaling — handles bursts gracefully (perfect for paydays) ✅ Pay-per-use pricing — great for variable traffic ✅ Supports long-lived requests (up to 60 minutes) ✅ Very low operational overhead — no servers or clusters to manage ➡️ Ideal for backend services that handle individual session-based gRPC connections. B. Cloud Run functions — ❌ Not Suitable ❌ Not designed for persistent connections ❌ Best for short-lived event-driven functions (not 30-minute calls) ❌ No gRPC support in current Cloud Functions (1st or 2nd gen) C. GKE Standard — ❌ Overkill ✅ Can handle gRPC and scaling with proper configuration ❌ High operational complexity — you manage nodes, networking, autoscaling, etc. ❌ More expensive and requires significant setup and maintenance D. Compute Engine — ❌ Too Manual ✅ Can support gRPC ❌ Manual scaling ❌ You manage VMs, updates, load balancing ❌ Poor fit for bursty workloads or high scaling needs ✅ Conclusion: Use Cloud Run It gives you everything you need: gRPC support Long call durations Auto-scaling

Answer 282

You are developing a new application. You want the application to be triggered only when a given file is updated in your Cloud Storage bucket. Your trigger might change, so your process must support different types of triggers. You want the configuration to be simple so that multiple team members can update the triggers in the future. What should you do? A. Configure a Cloud Run function that executes your application and is triggered when an object is updated in Cloud Storage. B. Create an Eventarc trigger that monitors your Cloud Storage bucket for a specific filename, and set the target as Cloud Run. C. Configure a Firebase function that executes your application and is triggered when an object is updated in Cloud Storage. D. Configure Cloud Storage events to be sent to Pub/Sub, and use Pub/Sub events to trigger a Cloud Build job that executes your application.

Answer 283

Correct answer: D. Create a Google service account and a Kubernetes service account. Configure Workload Identity on the GKE cluster, and reference the Kubernetes service account on the application Deployment. 🧠 Explanation: This question is about granting secure, least-privilege access to BigQuery from a GKE workload — while following Google-recommended best practices. 🔍 Option Analysis: A. Use service account JSON key in Secret Manager — ❌ Not best practice Storing long-lived credentials like service account keys in Secret Manager is better than hardcoding, but still not recommended. Google Cloud strongly recommends avoiding downloading and managing keys whenever possible. B. Add service account JSON key as Kubernetes secret — ❌ Risky This is a legacy approach and poses security risks (keys can be leaked, rotated incorrectly, etc.). It goes against the principle of least privilege and secure identity federation. C. Use init container to fetch key from Secret Manager — ❌ Still uses a service account key Slightly more secure than B, but still uses a long-lived service account key, which is discouraged. Extra complexity with key management and lifecycle. D. Workload Identity with GKE — ✅ Recommended 🔐 Most secure and scalable method to authenticate workloads in GKE. 🔄 Eliminates the need to manage service account keys. 🧠 Integrates IAM with Kubernetes Service Accounts using identity federation. 👌 Google's best practice for accessing Google Cloud APIs from GKE workloads. ✅ How it works: Enable Workload Identity on the GKE cluster. Create a Google service account with BigQuery access. Create a Kubernetes service account in your namespace. Bind the GCP IAM service account to the Kubernetes service account using an IAM policy binding. Reference the KSA in your Deployment YAML. The Go app will use Application Default Credentials (ADC) via the Workload Identity to access BigQuery securely.

Answer 284

✅ Correct answer: D. 🧠 Explanation: You're building a Java Web Server that needs to access Google Cloud Storage on behalf of users using their Google identities. This is a classic case for using OAuth 2.0 Authorization Code Flow, which is the standard Google-recommended approach for server-side web applications. ✅ Why D is correct: ✅ OAuth Consent Screen: This is required to let users authorize access to their Google account (and permissions to use services like Cloud Storage). ✅ Authorization Code: After the user consents, Google returns an authorization code to your server (not to the browser cookies). ✅ Token Exchange: Your server securely exchanges the authorization code for an access token by making a call to Google’s OAuth token endpoint. ✅ Access Token Usage: Your backend app uses this access token to call the Cloud Storage API on the user's behalf. This process is secure, standard, and follows best practices for web server applications. ❌ Why the other options are wrong: A: Asking for and storing user passwords violates Google policies and security best practices. Never handle raw credentials. B: Same issue as A – you're handling usernames and passwords directly, which is insecure and not supported by Google. C: Although it starts off correctly with the OAuth consent screen, it wrongly suggests the authorization code is stored in cookies and used directly by the user to authenticate to Google APIs. That’s not how OAuth 2.0 works.

Answer 285

Correct answer: B. Change your application’s logging library to the Cloud Logging library, and configure your application to export logs to Cloud Logging. 🧠 Explanation: Since your application is already running on Google Kubernetes Engine (GKE) and you want the simplest method to export logs with metadata about each request, the best solution is to: Use the Cloud Logging client library for your application’s language (e.g., Java, Go, Python). This client automatically adds metadata such as trace IDs, severity, timestamps, resource labels (e.g., GKE pod, cluster, namespace), etc. Logs are sent directly to Cloud Logging without needing to manage external agents or parse log files. ❌ Why the other options are incorrect: A. JSON output: This requires you to manually add metadata and format logs, which is more complex and error-prone. C. Fluent Bit: This is not the simplest option. Fluent Bit or Fluentd can be used for custom log pipelines but require extra setup and maintenance. D. CSV format: Not supported by Cloud Logging, and doesn’t provide structured logging or automatic metadata enrichment.

Answer 286

✅ Correct answer: C. Store user data in a Cloud Storage bucket. 🧠 Explanation: Cloud Shell ephemeral disks are not suitable for storing sensitive or persistent data. Cloud Storage is: Durable and persistent. Easy to integrate with Cloud Shell (via gsutil or the Cloud Console). Requires minimal code changes — simply replace local file paths with a Cloud Storage URI (e.g., gs://your-bucket-name/filename). Secure, with support for IAM, audit logging, and encryption (including CMEK if needed). ❌ Why the other options are incorrect: A. Cloud Shell home disk: While more persistent than the ephemeral disk, it can still be deleted after 120 days of inactivity — not reliable for sensitive, long-term storage. B. Persistent disk in a Compute Engine instance: Adds operational complexity — requires managing VMs, networking, and security. D. BigQuery tables: Designed for structured analytics, not general-purpose file or object storage. Overkill unless the data will be queried.

Answer 287

✅ Correct answer: D. Configure Cloud Build to run the unit tests, using the specific service account as the build agent. If the code passes the tests, Cloud Build deploys the Cloud Run function. 🧠 Explanation: This option ensures that: Unit tests run before any deployment. The deployment only happens if tests pass, which enforces quality control. The deployment uses the correct service account, which has the required permissions. The entire process is automated, secure, and aligned with CI/CD best practices. ❌ Why the other options are incorrect: A. Sending a manual approval adds human error and delays. It doesn’t ensure that only passing code is deployed automatically. B. Running unit tests after deployment defeats the purpose of preventing bad code from being deployed in the first place. C. Involves manual deployment by a developer, which bypasses automation and the permissions restriction.

Answer 288

✅ Correct answer: C. Use the Pub/Sub emulator. 🧠 Explanation: Using the Pub/Sub emulator is the best option for cost-effective and reliable unit testing: No cost: The emulator runs locally and avoids charges from the actual Pub/Sub service. Reliable and repeatable: It enables deterministic testing scenarios, including verifying message order. Faster feedback loop: No need to interact with real infrastructure. Simulates real Pub/Sub behavior for development and testing, without external dependencies. ❌ Why the other options fall short: A. Create a topic and subscription for each tester: Costly and hard to manage. Doesn’t ensure ordered processing or reliability. B. Implement a mocking framework: Useful in some cases, but doesn’t test actual Pub/Sub message handling logic or ordering behavior like the emulator can. D. Add a filter by tester to the subscription: This helps isolate messages but doesn’t help test order or reduce cost.

Answer 289

Correct Answer: C. Deploy your application on GKE with Cloud Service Mesh. Use traffic splitting to direct a subset of user traffic to the new version based on the user-agent header. 🧠 Explanation: You want fine-grained control to direct traffic based on user attributes (like operating system). GKE with Cloud Service Mesh (formerly Istio) supports advanced traffic management features, including: Traffic splitting by HTTP headers, like User-Agent. Canary deployments and staged rollouts. Fast rollback by updating routing rules. The User-Agent header contains OS info, so this lets you test new versions with users on specific operating systems. ❌ Why the other options don’t fit: A. Cloud Run + revision tag traffic splitting Traffic splitting in Cloud Run is based on percentages, not user attributes like headers. B. Compute Engine + Traffic Director Traffic Director allows load balancing but doesn't support fine-grained header-based routing without a lot of extra setup. D. Cloud Run + traffic weights Again, this is percentage-based, and cannot route based on request content (like User-Agent).

Answer 290

✅ Correct Answer: A. Create three Cloud Run functions as three backend services exposed using an HTTPS load balancer. 🧠 Explanation: You want each URL path (/students, /teachers, /classes) to invoke a different function. This means: You need routing logic to direct traffic based on the URL path. Cloud Run does not support native path-based routing across multiple services. The best solution is to: Deploy each function as a separate Cloud Run service. Use an HTTPS Load Balancer with URL map rules to route traffic to each function based on the path. ❌ Why the other options don't work: B. One Cloud Run function exposed directly You could handle routing in your application code, but the question specifies that each path should invoke a different function, not just different logic in one function. C. One Cloud Run function as a backend service exposed via load balancer Again, this implies only one deployed function is handling all routes, which doesn't meet the requirement. D. Three Cloud Run functions exposed directly This lacks centralized routing. Each function would need its own domain or custom routing logic in your client — not ideal for a unified API.

Answer 291

✅ Correct Answers: A and F 🔍 Explanation: You need to expose multiple services in a GKE cluster under different HTTP paths using a single IP address, accessible via Cloud Interconnect (i.e., internal access). ✅ A. Create a Gateway with the Gateway Class Name: gke-l7-rilb specification. This sets up a Regional Internal Layer 7 Load Balancer (RILB), perfect for routing HTTP traffic to multiple backend services based on path or host rules. Required for internal access via Cloud Interconnect. ✅ F. Create an HTTPRoute pointing to both Services. Defines HTTP path-based routing to each of your GKE services. HTTPRoute is part of the GKE Gateway API, used with the Gateway to direct traffic correctly. ❌ Why the others are incorrect: B. Service with networking.gke.io/load-balancer-type: "Internal" Only gives you an L4 Internal Load Balancer, which doesn't support HTTP path-based routing. C. Service of type LoadBalancer By default, this creates a public IP, which won’t work with Cloud Interconnect unless additional setup is done — and it’s not needed here. D. Service of type NodePort Exposes individual Pods directly on each node, not ideal for centralized access or L7 routing. E. Service with selector matching both Deployments You cannot route path-based traffic to different backends this way. You’d just combine them into one backend, which breaks the separation by path.

Answer 292

Correct Answer: A. ✅ A. Deploy each microservice as a Deployment. Expose the Deployment in the cluster using a Service, and use the Service DNS name to address it from other microservices within the cluster. This is the Google-recommended and Kubernetes-native approach. Deployment: Manages the replica count and handles rolling updates. ClusterIP Service: Exposes the Deployment internally within the cluster (default Service type). DNS Resolution: Kubernetes automatically creates a DNS name for the Service (..svc.cluster.local), allowing uniform access regardless of replicas.

Answer 293

Correct Answer: D. 🔐 D. Store the Secret in Secret Manager. Create a Google service account to read the Secret from Secret Manager. Create a Kubernetes service account to run the container. Use Workload Identity to authenticate as the Google service account. This is the most secure and recommended Google Cloud approach: Secret Manager: Secure, managed service for storing secrets. Workload Identity: Allows GKE workloads to authenticate as a Google service account without using long-lived credentials. No secrets exposed via Kubernetes API: Avoids risk of API server exposure. IAM-based access: Fine-grained control over who/what can access the secret. ❌ Why the other options are not ideal: A. Kubernetes Secret + env variable Secrets are base64 encoded and can be accessed through the Kubernetes API, which does not meet the requirement of not revealing the secret that way. B. GKE Application-layer Secrets Encryption This encrypts Kubernetes secrets at rest, but the secret can still be retrieved via the Kubernetes API by authorized users — so it doesn’t meet the requirement. C. Store secret in KMS + mount JSON key This involves managing long-lived service account keys, which is a security risk and goes against best practices. 🔐 Summary: Use Secret Manager for secure storage and Workload Identity for secure, keyless access from GKE workloads. It's scalable, manageable, and compliant with Google's security recommendations. Would you like a YAML or Terraform example for this setup?

Answer 294

Correct Answer: C. The AuthorizationPolicy of your cluster is blocking HTTP requests for specific paths within your application. 🧠 Explanation: You mentioned that: Some HTTP requests between pods are working, while others (to specific URLs) are failing. You are using Istio with: mTLS Istio AuthorizationPolicy Kubernetes NetworkPolicy

Answer 295

Correct Answers: B and E 🧠 Explanation: To authenticate microservices in GKE to access Google Cloud APIs following best practices, you should use Workload Identity instead of relying on service account keys. ✅ B. Enable Workload Identity on the cluster This is Google's recommended approach. Workload Identity allows Kubernetes service accounts to act as Google service accounts, enabling secure and manageable identity-based access to GCP APIs without using keys. ✅ E. Use gcloud to bind the Google service accounts and the Kubernetes service accounts using roles/iam.workloadIdentityUser This step is essential to link the GKE identity to the GCP identity. The roles/iam.workloadIdentityUser role allows a Kubernetes service account to impersonate the linked Google service account. ❌ Why the other options are incorrect: A. Use the service account attached to the GKE node ❌ This is not recommended because all pods on the node share the same identity, which violates the principle of least privilege. C/D. Access or store service account keys in Secret Manager ❌ Using downloaded service account keys is discouraged due to security risks (e.g., key leakage). Workload Identity eliminates the need for managing and rotating keys manually.

Answer 296

Correct Answer: C. Deploy a Horizontal Pod Autoscaler, and scale based on the CPU load. 🧠 Explanation: Horizontal Pod Autoscaler (HPA) is designed to automatically scale the number of pods in a Kubernetes deployment based on observed metrics like CPU utilization or custom metrics. CPU load is one of the most common, supported, and simplest metrics to use for autoscaling. Since this is a stateless, distributed service, it's ideal for horizontal scaling. Given the tight timeline (two weeks), using HPA with CPU metrics ensures: Minimal configuration and changes Native support in GKE Proven reliability ❌ Why the other options are less suitable: A. Vertical Pod Autoscaler (VPA), CPU load VPA adjusts resource requests/limits of pods, not the number of pods. It can cause pod restarts and is not ideal for stateless services needing quick autoscaling. B. VPA, custom metric Same issue as above, plus custom metrics require more setup (e.g., Prometheus + Adapter), which isn't ideal for a short timeline. D. HPA, custom metric While valid for advanced use cases, it requires more setup and monitoring infrastructure (like Prometheus + Metrics Server + Custom Metrics Adapter).

Answer 297

Correct Answer: D. Store the session information in Memorystore for Redis, and store the shopping cart information in Firestore. 🧠 Explanation: Google-recommended best practices for modern web apps suggest separating session state from application instances and using fully managed, scalable, and low-latency services. Let's break down why D is the best fit: ✅ Memorystore for Redis (for session management): Ideal for short-lived, fast-access data like session tokens or user session data. Low latency with in-memory storage. 30-minute inactivity expiration fits perfectly with Redis TTL (Time to Live). Fully managed, scalable, and easy to integrate with GKE, App Engine, or Cloud Run. ✅ Firestore (for shopping cart storage): NoSQL database ideal for semi-structured data like shopping carts. Built-in real-time updates, offline support, and strong consistency. Allows cart persistence across sessions. Scales automatically and is cost-effective for ecommerce-style applications. ❌ Why the other options are not ideal: A. Local memory + cookie-based affinity Not fault-tolerant or scalable. Session lost if instance crashes or scales down. Session stickiness doesn’t guarantee resilience. B. Cloud Storage per-session object Not optimal for fast, transactional data like cart interactions. High-latency for frequent updates. C. BigQuery Built for analytics, not transactional operations. Slower and more expensive for frequent reads/writes.

Answer 298

The correct answers are: ✅ A. Use the Bucket Lock feature to set the retention policy on the data. ✅ D. Create a lifecycle management policy to set the storage class to Coldline for objects older than 14 days. ✅ Explanation: A. Use the Bucket Lock feature Required to enforce the 7-year retention policy. Prevents deletion or modification of objects before the specified retention period ends. Meets compliance and audit requirements. D. Lifecycle policy to Coldline for objects older than 14 days Coldline is optimized for infrequently accessed data (like yearly audits). Lifecycle rules automatically move older objects to cheaper storage tiers, saving costs. Moving objects after 14 days ensures performance for recent access and savings for long-term retention. ❌ Why the other options are incorrect: B. Run a scheduled job Manual and error-prone. Lifecycle policies are preferred for automatic and reliable data tiering. C. Create a JWT for access JWTs are used for short-lived access tokens, not a storage class or access management strategy for Coldline buckets. E. Use Nearline Nearline is for access about once a month. Coldline is more cost-effective for annual access (e.g., external audits).

Answer 299

The correct answers are: ✅ A. Set a retention policy on the bucket with a period of 7 years. ✅ D. Create an object lifecycle policy on the bucket that moves objects from Standard Storage to Archive Storage after 3 years. ✅ Explanation: A. Set a retention policy on the bucket with a period of 7 years This ensures compliance by preventing deletion or modification of objects for at least 7 years. Meets regulatory requirements for data retention. D. Create a lifecycle policy to move objects to Archive Storage after 3 years Archive Storage is the lowest-cost storage tier, ideal for rarely accessed data (less than once per year). Automatically transitioning objects after 3 years optimizes cost while keeping data accessible when needed. ❌ Why the other options are incorrect: B. Use IAM Conditions with creation time in prefix IAM Conditions don’t guarantee data retention or protection against deletion — they only control access, not lifecycle or compliance. C. Enable Object Versioning Object versioning protects against accidental deletion, but it doesn’t enforce retention or cost optimization. It could actually increase storage costs if old versions pile up. E. Use Cloud Run with Cloud Scheduler This is overly complex and unnecessary. Google Cloud Storage lifecycle management policies already provide this functionality natively and more efficiently.

Answer 300

The correct answer is: ✅ A. Build the application with Firestore as the database. Deploy the application to Cloud Run. ✅ Explanation: Cloud Run Fully managed and serverless, so you only pay when your application is running. Auto-scales instantly and automatically based on incoming traffic — including scaling down to zero when there's no traffic, which minimizes cost. Firestore Serverless NoSQL database with automatic scaling and real-time capabilities. Ideal for web applications with unpredictable workloads. ❌ Why not the others? B. GKE Standard Offers autoscaling, but you still pay for control plane and base node pool resources, even during idle times. C. GKE Autopilot Better than Standard in terms of cost-efficiency, but not as cost-effective as Cloud Run for bursty traffic that frequently scales to zero. D. Compute Engine managed instance group More manual setup and not serverless; higher baseline costs due to VM overhead even with autoscaling.

Answer 301

he correct answer is: ✅ A. Enable the Container Analysis API to conduct vulnerability scans on images in Artifact Registry. ✅ Explanation: Container Analysis API is a managed Google Cloud service that automatically scans container images stored in Artifact Registry or Container Registry for known vulnerabilities (CVEs). It integrates seamlessly with your CI/CD pipeline and doesn't slow down development, satisfying the requirement of not impacting software development agility. Scans are done automatically after image push, with findings available in the Cloud Console or via API. ❌ Why not the others? B. Cloud Run service triggered on check-in: This would require custom development, does not integrate directly with container image scanning, and is not an efficient or managed solution. C. Disallowing non-commercial base images: This limits developer flexibility and doesn't provide active CVE scanning, which is the key requirement. D. Using Cloud Monitoring to review Cloud Build output: This is manual and reactive, and not a proper CVE scanning solution. It lacks automation and doesn't meet the requirement for agility.

Answer 302

The correct answer is: ✅ B. Use your programming language logger to write logs to Standard output (stdout) and Standard error (stderr) streams. ✅ Explanation: Cloud Run automatically captures anything written to stdout and stderr and sends it to Cloud Logging. This approach requires minimal code changes and no extra configuration. It's the Google-recommended best practice for logging in serverless environments like Cloud Run. ❌ Why not the others? A. Import the Cloud Logging library: While valid, it's more complex and requires additional maintenance. Using stdout/stderr is simpler and achieves the same result. C. Expose log files via a URL: This is manual, insecure, and not scalable or efficient. D. Using cron to copy logs to Cloud Storage: This is unnecessary overhead and doesn’t integrate with Cloud Logging, which is the desired logging backend.

Answer 303

✅ D. Use Private Google Access ✅ Explanation: Private Google Access allows VM instances without public IP addresses (internal-only) to reach Google APIs and services (like Cloud Storage) over the internal network. This is the recommended way to securely access Google services without exposing your VM to the internet. ❌ Why not the others? A. Carrier Peering: Used for connecting your on-prem network to Google over a service provider’s network. Not applicable for internal GCP VM access. B. VPC Network Peering: Allows private connectivity between two VPCs, not for accessing Google services. C. Shared VPC: Helps share VPC resources across projects but doesn’t solve the issue of accessing Google APIs privately.

Answer 304

✅ C. Use Cloud Profiler to determine which functions within the application take the longest amount of time. ✅ Explanation: Cloud Profiler is a low-overhead sampling-based tool that helps you analyze the performance of your application in production. It identifies which parts of your code consume the most CPU or memory, helping you pinpoint bottlenecks without modifying your application. This is the most efficient and least intrusive way to diagnose performance issues in production. ❌ Why not the others? A. File a ticket with Cloud Support: Premature. Support would first ask for diagnostics—use Cloud Profiler or other tools first. B. Cloud Debugger: Helps inspect application state but isn’t optimal for performance profiling or identifying slow functions. D. Add logging commands: Useful, but requires code changes and is more manual compared to using Cloud Profiler.

Answer 305

B. You configured your Serverless VPC Access connector in a different region than your Cloud Run service. ✅ Explanation: Cloud Run needs to use a Serverless VPC Access connector to communicate with Memorystore, which only has internal IP addresses. One critical requirement is that the connector must be in the same region as the Cloud Run service. If the connector is in a different region, Cloud Run won’t be able to connect to Memorystore, resulting in a 502 Bad Gateway error due to backend connection failure. ❌ Why not the others? A. Memorystore has no public IP: True, but this is expected. It’s by design, and that’s why you use Serverless VPC Access. C. Firewall rule issue: Cloud Run to Memorystore access via the connector doesn’t usually require custom firewall rules unless you've added very restrictive policies. D. Different subnet: Different subnets are fine, as long as they're in the same region. The region mismatch is the real issue.

Answer 306

✅ Correct answer: C. Create a new Filestore instance, and mount the volume as an NFS PersistentVolume. 🔍 Explanation: Since multiple instances of the microservice need read/write access to a shared file, and you want to avoid rewriting the application, you need a POSIX-compliant shared file system. Filestore is Google Cloud’s managed NFS solution, which integrates well with GKE via PersistentVolumes. This allows the existing app code that relies on shared file access to continue functioning without significant refactoring. ❌ Why not the other options? A. Cloud Storage with FUSE: Not recommended for applications with concurrent read/write or low-latency file access needs. GCS is object storage, not a true file system. B. Persistent Disk (PD): PDs can only be attached read-write by a single node at a time. Not suitable for multi-writer scenarios. D. ConfigMap: Meant for static, configuration data, and is read-only when mounted as a volume. Not suitable for read/write operations by the app.

Answer 307

Correct answer: B. Create one Pub/Sub topic. Create one pull subscription per audit service instance. 🔍 Explanation: To decouple the authentication and audit services and scale efficiently, you want: A single Pub/Sub topic to centralize event ingestion from all auth service instances. Multiple pull subscribers (one per audit service instance) to allow parallel processing and scalability. Pull subscriptions are ideal for horizontal scaling, especially when audit service instances increase or decrease dynamically. 💡 Key Pub/Sub Best Practices: Single topic is better than one-per-producer to keep system design simple and avoid topic explosion. Multiple subscribers sharing a subscription helps balance load across instances. Pull subscriptions allow the subscriber to control when and how much to consume (important during traffic spikes). Pub/Sub automatically load balances messages across subscriber instances of the same pull subscription. ❌ Why not the other options? A. One pull subscription only: Doesn't allow horizontal scaling of the audit service — all messages go to a single consumer. C. One push subscription: Push model requires endpoint management, isn't ideal for scalable, high-throughput use cases. D. One topic per authentication instance: Overcomplicates the architecture. Managing many topics and subscriptions makes scaling harder.

Answer 308

Correct answer: B. Retrieve the access token from the metadata server and pass the value in the Authorization header. 🔍 Explanation: Since your application is running on Cloud Run and making REST API calls directly (because there's no Cloud Client Library support), you need to authenticate those API requests using an OAuth 2.0 access token. The correct and secure way to do this is: Retrieve the access token for the associated service account from the Cloud Run metadata server endpoint: http Copy Edit GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token Headers: Metadata-Flavor: Google Extract the access_token from the response and include it in your request headers: http Copy Edit Authorization: Bearer ACCESS_TOKEN This method works regardless of programming language, and it's the Google-recommended approach for authenticating from a Cloud Run (or any GCE-based) environment. ❌ Why not the other options? A. API key: Not secure for production, and not sufficient for many authenticated API calls (especially for data-modifying operations). C. Use API key in GOOGLE_APPLICATION_CREDENTIALS: API keys are not used this way and don’t work as service account credentials. D. Use gcloud auth application-default print-access-token: This is intended for local development, not for production use in Cloud Run.

Answer 309

Correct answer: C. Use an OAuth Client ID and https://www.googleapis.com/auth/drive.file scope to obtain an access token for each user. 🔍 Explanation: Since your web application writes to the user's personal Google Drive, regardless of their account domain, you need to authenticate on behalf of the user — not as a service account. 🔐 OAuth 2.0 is the correct flow for user data. OAuth Client ID is used to identify your application to Google's OAuth 2.0 system. The https://www.googleapis.com/auth/drive.file scope allows the app to read and write files created or opened by the app, which is ideal for limiting permissions to only what's needed. You’ll use OAuth 2.0 Consent Screen and obtain the user's access token after they grant permission. This approach works across any Google user — even those outside your organization or domain. ❌ Why not the others? A. OAuth Client ID with delegated domain-wide authority: Only applies to G Suite/Workspace admin-level delegation for users within a domain, not for public user apps. B. Service account with domain-wide delegation: Also applies only within a domain — doesn't work for arbitrary Google users. D. Service account with Drive scope and JWT: Service accounts are not authorized to write to a user’s personal Drive unless used in conjunction with domain-wide delegation (which again only works in G Suite environments and not for public users).

Answer 310

Correct answer: B. Publish the votes to Pub/Sub, and use a Dataflow pipeline to insert the counts and votes into BigQuery. Display the results in Google Data Studio. 🔍 Why this is the best solution: You're dealing with: High-volume, time-bound event ingestion (votes in 30-minute windows), Scalable, real-time data processing, and Storage for future analysis/reporting. This makes Pub/Sub + Dataflow + BigQuery the ideal pipeline. ✔ Breakdown of the correct approach: Pub/Sub: Handles massive, real-time streaming ingestion of vote events. Dataflow (Apache Beam): Performs windowed aggregations (e.g., count votes per topic per 30-minute window), transforms, filters, and routes data. BigQuery: Stores both raw votes and aggregated results for long-term querying and reporting. Google Data Studio (now Looker Studio): Visualizes BigQuery data in real time for stakeholders. ❌ Why the other options are not ideal: A. Memorystore + Cloud Run + BigQuery: Memorystore isn’t designed for long-term or massive-scale write-heavy workloads. It’s in-memory only — no persistence by default. Not a good fit for vote counting + historical analysis. C. Pub/Sub + Cloud Run + Cloud Storage: Cloud Storage isn’t ideal for queryable data. You'll have to manually parse logs or files for analytics. No built-in time-windowed aggregation. D. Firestore + CSV + Sheets: Firestore may struggle at scale without careful sharding. Manual CSV + Sheets is not scalable or real-time. Not suited for high-velocity, analytical workloads. Let me know if you'd like help building a simple Beam pipel

Answer 311

Correct answer: C. Have the Cloud Build step write the Cloud Run function results to a file and return 0. Add a step after the Cloud Run function deletion that checks whether the file contains the expected results and fails if it doesn't. 🔍 Why this works best: The issue is that Cloud Build stops executing further steps when a step fails (i.e., exits with a non-zero code). That means if your test step fails, the cleanup step to delete the Cloud Run function is never reached. ✔ Why option C is the best solution: You prevent Cloud Build from failing early by making the test step always return 0 (success). Instead of failing immediately, the test writes its result (e.g., response body or status code) to a file. Then, after the deletion step, you add a final step to evaluate the result file and explicitly fail the build if needed. This guarantees that: Cleanup always runs, regardless of test success. You can still fail the build based on test results — just in the final step. ❌ Why the other options don’t work: A. Change the order to delete before test: This defeats the purpose — you need the function to exist for the test. B. waitFor option: This controls execution order, not error handling. If the test step fails, no further steps are run, regardless of waitFor. D. Use environment variable to store result: Environment variables in Cloud Build aren’t shared across steps. Each step runs in a separate container, so this won’t work as intended.

Answer 312

Correct answer: B. Enable Cluster Autoscaler on the GKE cluster, and configure the Horizontal Pod Autoscaler (HPA) to autoscale the workload based on CPU load. 🔍 Why this is correct: To automatically adjust the number of nodes and pods based on CPU usage in a GKE cluster: Cluster Autoscaler handles the number of nodes in the cluster. Horizontal Pod Autoscaler (HPA) adjusts the number of pods in a deployment or replica set based on metrics like CPU utilization. This combination ensures: Pods scale up/down as CPU load increases or decreases. If more pods are scheduled than the cluster can handle, the Cluster Autoscaler will provision more nodes. ❌ Why the other options are incorrect: A. Modify the MIG only: GKE manages node groups for you. You shouldn't manually modify Managed Instance Groups (MIGs). It doesn't address pod-level scaling. C. HPA with custom metrics is valid, but the question is about CPU, so you don't need custom metrics — built-in CPU utilization is sufficient. D. Vertical Pod Autoscaler (VPA) adjusts resource requests (like CPU/memory) for individual pods — it doesn’t scale pod count. It also doesn’t replace HPA in most scenarios and doesn’t help with node scaling.

Answer 313

✅ Correct answer: C. Verify that application errors are being written to stderr. 🔍 Explanation: Cloud Run integrates automatically with Cloud Logging and Error Reporting. However, Error Reporting only picks up logs that contain properly formatted error messages written to stderr. For Java applications: Exceptions and errors should be logged to stderr, and in a format that Error Reporting can recognize (e.g., including a stack trace). ❌ Why the other options are incorrect: A. Cloud Monitoring libraries are not required for Error Reporting to work. Error Reporting reads logs from Cloud Logging. B. There's no need to manually verify a regional storage bucket — Cloud Run handles log routing to Cloud Logging automatically. D. System.out.println writes to stdout, not stderr, so it won’t trigger Error Reporting for errors. ✅ Best Practice for Java on Cloud Run: Use a logging framework like SLF4J, Logback, or java.util.logging, and make sure it writes exceptions to stderr with stack traces for proper error detection. Let me know if you want a quick example of how to log Java exceptions properly in Cloud Run!

Answer 314

Correct answer: C. Cloud Spanner 🔍 Explanation: Cloud Spanner is Google Cloud’s fully managed, horizontally scalable, globally distributed relational database that provides: Global consistency (strong consistency across all regions) High availability and fault tolerance SQL support and ACID transactions Automatic scaling as your user base grows These features make it ideal for global, multi-player games where users from different regions interact with shared data (like trading points), and where consistency, performance, and uptime are critical. ❌ Why not the others? A. BigQuery: Meant for analytics, not for transactional, low-latency, real-time workloads like game data and user interactions. B. Cloud SQL: A managed MySQL/PostgreSQL service, but not built for global distribution or scalability. It would hit performance limits quickly in a global scenario. D. Cloud Bigtable: Great for very high-throughput workloads (like telemetry), but it's not relational, doesn’t support SQL or multi-row transactions, and not ideal for global consistency.

Answer 315

Correct answer: D. Use traffic splitting to have a smaller part of the users test out new features, and slowly adjust traffic splitting until all users get the new features. 🔍 Explanation: Cloud Run supports traffic splitting, which allows you to: Deploy a new version of your service Gradually roll it out to a percentage of users (e.g., 5%, 10%, 50%) Monitor performance and behavior Quickly roll back if any issues arise This approach lets you release features safely and iteratively, minimizing risk without needing expensive load testing.

Answer 316

✅ Correct answer: A. Deploy the website on Cloud Run and use traffic splitting. 🔍 Explanation: Since: Your website is currently on Compute Engine You can't modify the application code The marketing team wants A/B/C testing (3 designs) The best solution is to migrate the site to Cloud Run and use traffic splitting, which allows you to: Deploy multiple versions (revisions) of your site Distribute traffic among them (e.g., 33%, 33%, 34%) without needing to change application logic Easily monitor conversion rates across versions ❌ Why not the others? B. Deploy as three separate revisions: You still need traffic splitting, which is part of Option A. C & D. Cloud Run functions: Functions are designed for event-driven tasks, not ideal for full website hosting.