Practice Test #1

Cloud Functions is a serverless Functions-as-a-Service product for event-driven code. It does not manage Kubernetes clusters, enforce fleet-wide policies, or provide multi-cluster service mesh and observability. While it can be part of a microservices ecosystem, it cannot centrally govern 24 clusters across on-prem, Google Cloud, and AWS. It’s compute for functions, not a hybrid/multi-cloud Kubernetes management platform.

Cloud Run is a managed serverless container platform that runs stateless HTTP services and jobs. It simplifies deployment and scaling, but it is not a centralized platform for managing existing Kubernetes clusters across multiple environments. It doesn’t provide fleet-wide policy/config management or multi-cluster service mesh governance. Choosing Cloud Run would imply changing the runtime platform rather than centrally managing the current Kubernetes footprint.

Compute Engine provides virtual machines and is foundational infrastructure, but it does not offer Kubernetes fleet management, centralized policy/config enforcement, service mesh, or cross-cluster observability as a unified platform. You could run Kubernetes on VMs, but you would still need a higher-level management solution to meet the requirement of consistent governance across on-prem, Google Cloud, and AWS without relocating workloads.

Incorrect. These APIs still require data input (images and email text) and benefit from validation and preprocessing. For example, you must ensure supported file formats, handle language/encoding, remove signatures/quoted text in emails, and manage edge cases (blurry images, short messages). Managed AI reduces model-building effort, not the need for responsible data handling and quality checks.

Incorrect. AI APIs do not inherently require fewer security permissions. You still must grant appropriate IAM roles (principle of least privilege), manage service accounts, and protect sensitive data. In some cases, using AI services can increase the need for governance (audit logging, data retention policies, DLP considerations, VPC Service Controls) because you are processing potentially sensitive customer communications.

Incorrect. Not all Google Cloud AI offerings require custom training. Many common tasks are covered by pre-trained APIs that work immediately. Custom training is optional and used when you need domain-specific labels, unique terminology, or higher accuracy than general models provide. For this startup’s requirements and timeline, pre-trained APIs are the intended approach.

SRE practices and runbooks improve reliability and incident response (SLIs/SLOs, on-call, playbooks), but they do not provide an external, standardized HTTPS interface. They also don’t inherently deliver authentication, API versioning, or partner-specific rate limiting. SRE would be complementary after the platform is built, not the primary solution to expose and govern partner integrations.

A customized ML model could help predict bike demand or station fullness, but it does not address the requirement to publish and receive real-time events via a secure, versioned HTTPS interface. ML is an analytics enhancement, not an integration control plane. Even if predictions were useful, you would still need an API layer to expose data securely to 300 operators.

A multi-regional shared database could store availability and rental events, but it is not a safe or practical partner integration interface. Databases don’t natively provide standardized API contracts, per-partner authentication models, versioning, or rate limits. Exposing a shared database to 300 external operators increases security risk, complicates governance, and can create performance and quota contention.

A Service-level agreement (SLA) is a customer-facing contract that may specify availability/latency commitments and often includes consequences (credits/penalties) if not met. It is not the metric itself; it’s the formal agreement built on top of internal objectives and indicators. SLAs are typically less strict than internal SLOs to provide a safety margin.

Error reporting is an operational capability (for example, Google Cloud Error Reporting) that aggregates and alerts on application exceptions and crashes. While it can contribute data used to compute an SLI (like error rate), it is not the SRE concept that represents the performance metric itself. It’s a tool/service, not the measurement definition.

A Service-level objective (SLO) is the target value or threshold for an SLI over a time window (for example, “99.9% monthly availability” or “p95 latency < 300 ms during 18:00–22:00”). SLOs define the desired reliability level and drive error budgets, but they are not the metric; they are the goal applied to the metric.

Firestore is a serverless document database suited for app backends, user profiles, and real-time sync. While it scales well and supports multi-region, it is not optimized for petabyte-scale wide-column time-series workloads with extremely high sustained write rates (e.g., 1.2M writes/sec) and the access patterns typical of clickstream/event ingestion. Firestore’s document model and limits make it a less natural fit than Bigtable for this scenario.

Cloud Data Fusion is a managed data integration/ETL service (based on CDAP) used to build pipelines that move and transform data between systems. It does not provide the underlying low-latency, high-throughput operational storage required here. In this architecture, Data Fusion could help ingest/transform data into Bigtable/BigQuery, but it cannot replace the database layer needed for sub-10 ms writes at massive scale.

Cloud SQL is a managed relational database (MySQL/PostgreSQL/SQL Server). It is ideal for transactional relational workloads but is constrained by vertical scaling and read replicas; it is not designed for horizontally scaling to millions of writes per second with sub-10 ms latency across regions. Schema evolution and migrations are also more complex in relational systems compared to sparse wide-column stores for evolving event attributes.

Video Intelligence API is intended for analyzing video content with prebuilt capabilities such as label detection, shot change detection, and object tracking in videos. The question is about training a custom classifier on PNG image files, not extracting insights from video streams. It does not provide a no-code workflow for building a bespoke image classification model from labeled still images. Therefore, it does not fit either the data type or the custom training requirement.

BigQuery ML is primarily used to build machine learning models with SQL on data stored in BigQuery, especially structured or tabular datasets. Although it is a managed ML option, it is not the standard service for training custom image classifiers directly from large PNG datasets in Cloud Storage. The scenario specifically requires image-based supervised learning without writing model code, which is what AutoML Vision is built for. Using BigQuery ML here would be a mismatch in both data modality and intended workflow.

Looker is a business intelligence and analytics platform used for dashboards, reporting, and data exploration. It can help visualize results from a machine learning system, but it does not train custom computer vision models. The requirement is to build an image classifier from labeled crop leaf images using a fully managed service. Because Looker is not a model training service, it is not an appropriate choice.

GPS coordinates collected every 5 seconds are typically structured time-series data: each event has consistent fields such as timestamp, latitude, longitude, and bike identifier. While the dataset is high-volume and high-velocity, it still fits a defined schema and is readily stored/analyzed in systems like BigQuery or time-series pipelines.

Daily station utilization percentages by station are structured metrics. They naturally fit into a table with columns like station_id, date, and utilization_percent. This data is straightforward for reporting and trend analysis in BigQuery or Looker, and it is not considered unstructured.

Inventory tables with SKU codes, quantities, and reorder thresholds are classic structured relational data. They have a well-defined schema and are typically stored in relational databases or managed services. This is the opposite of unstructured data and is easy to query with SQL.

SQL injection is an application-layer technical exploit where an attacker manipulates poorly validated inputs to execute unintended database queries. It targets software vulnerabilities in code and input handling, not human behavior. While it is a serious risk, it is not a social-engineering method and does not align with the phishing-simulation context described (lures, clicks).

Overheating rack servers is a form of physical sabotage or environmental attack. It could cause outages or equipment damage, but it is not social engineering because it does not rely on deceiving employees into taking an action. The scenario focuses on staff clicking links from simulated lures, which points to phishing rather than physical threats.

A botnet-driven flood is a Distributed Denial of Service (DDoS) attack focused on exhausting resources and degrading availability. It is primarily a technical, volumetric attack against infrastructure and network capacity, not a human-deception tactic. It does not fit the context of employees clicking links or being tricked into revealing credentials.

Creating external accounts to query the production database violates least privilege and significantly increases security risk (credential leakage, SQL injection surface, network exposure). It also makes usage-based billing and throttling harder because databases aren’t designed as public multi-tenant billing endpoints. This approach can degrade reliability by allowing uncontrolled query patterns that impact operational workloads.

Selling monthly CSV downloads is a form of data distribution, but it doesn’t satisfy real-time access needs and doesn’t align with “requests per day at peak.” It also limits monetization flexibility (no per-request billing, limited tiering) and creates operational overhead for generating, hosting, and supporting bulk exports. It’s not a cloud-first, scalable integration pattern.

Migrating to a non-relational database is not required to share data securely or to implement usage-based billing. The key requirement is controlled access and metering, which is solved by an API management pattern. A migration adds cost, risk, and time, and may not improve security or monetization by itself unless there are separate performance/scaling needs.