Simulasikan pengalaman ujian sesungguhnya dengan 50 soal dan batas waktu 90 menit. Berlatih dengan jawaban terverifikasi AI dan penjelasan detail.
Didukung AI
Setiap jawaban diverifikasi silang oleh 3 model AI terkemuka untuk memastikan akurasi maksimum. Dapatkan penjelasan detail per opsi dan analisis soal mendalam.
A global retail company needs to centralize ingestion of custom application logs from 3 GKE clusters (total 150 microservices), 200 Compute Engine VMs, and 12 Cloud Run services. Requirements: accept JSON-formatted payloads with custom fields and resource labels; create log-based metrics for alerting; query and manage retention in a single place; avoid third-party collectors beyond the Google Ops Agent. Which Google Cloud tool should the company use?
Dialogflow is a conversational AI platform for building chatbots and voice assistants. It does not ingest infrastructure/application logs, provide centralized log querying, or manage log retention. It also has no native concept of log-based metrics for operational alerting across GKE, Compute Engine, and Cloud Run. It’s unrelated to observability requirements in this scenario.
Cloud Logging is Google Cloud’s centralized log management service. It natively ingests logs from GKE and Cloud Run and can ingest VM logs via the Google Ops Agent. It supports structured JSON payloads with custom fields, resource labels, and powerful querying in Logs Explorer. It also enables log-based metrics for Cloud Monitoring alerting and supports centralized retention management using log buckets, sinks, and views.
Cloud SDK is a set of command-line tools (like gcloud) and libraries used to manage Google Cloud resources. While it can help configure logging components, it is not a centralized logging platform and does not provide log ingestion pipelines, retention controls, or log-based metrics. It’s tooling, not the operational logging service required by the question.
Data Catalog is a metadata management and data discovery service for datasets (e.g., BigQuery tables, Pub/Sub topics, files in Cloud Storage). It helps with governance and search of data assets, not operational log ingestion, querying, or retention. It does not create log-based metrics for alerting and is not used to centralize application logs from GKE/VMs/Cloud Run.
Core Concept: This question tests Google Cloud’s centralized observability stack, specifically Cloud Logging (part of Google Cloud Operations suite) for ingesting, storing, querying, and managing logs across heterogeneous compute (GKE, Compute Engine, Cloud Run) and for creating log-based metrics used by alerting. Why the Answer is Correct: Cloud Logging is the native service to centralize logs from multiple Google Cloud resources in one place. GKE, Compute Engine (via Ops Agent), and Cloud Run integrate directly with Cloud Logging. It supports structured JSON logs, custom fields, and resource labels (via monitored resource types and labels), enabling consistent querying and filtering across 150 microservices, 200 VMs, and 12 Cloud Run services. Cloud Logging also supports log-based metrics, which can be used with Cloud Monitoring alerting policies—meeting the requirement for alerting without third-party collectors. Key Features / How it Meets Requirements: 1) Ingestion: GKE and Cloud Run automatically export container/service logs to Cloud Logging; Compute Engine uses the Google Ops Agent to collect and send logs. 2) Structured logging: JSON payloads are preserved as structured fields, enabling advanced queries in Logs Explorer and programmatic access. 3) Log-based metrics: You can create counter/distribution metrics from filters on logs (including custom JSON fields) and then alert in Cloud Monitoring. 4) Central management and retention: Use Log Buckets, Sinks, and Views to manage access and retention centrally. Configure bucket retention (e.g., 30/90/365 days) and route subsets to different buckets or to BigQuery/Cloud Storage for longer retention and analytics. 5) Governance: IAM controls, CMEK options for some logging storage scenarios, and organization-level aggregation via aggregated sinks support enterprise operations aligned with the Google Cloud Architecture Framework’s operational excellence and security pillars. Common Misconceptions: Some may think “Cloud SDK” is needed to ship logs, but it’s a CLI/tooling suite, not a logging backend. Others may confuse Data Catalog (metadata) or Dialogflow (conversational AI) with operational logging. Exam Tips: When you see requirements like “centralize logs,” “query in one place,” “structured JSON,” “log-based metrics,” and “alerting,” the default answer is Cloud Logging (often paired with Cloud Monitoring). Also note the constraint “avoid third-party collectors beyond Ops Agent” strongly points to native Cloud Operations tooling.
A regional nonprofit with 12 offices and 650 staff must roll out email, calendaring, and a document collaboration suite within 14 days, meet a 99.9% availability target, stay under a $12,000 monthly IT budget, and has only one part-time sysadmin; they want the provider to handle upgrades, backups, security baselines, and scaling so the team can focus on using the apps. In this scenario, which cloud service model is the best fit, and why would choosing SaaS be appropriate?
This describes PaaS: a balance where you deploy code while the provider manages underlying servers/OS. It’s useful for custom applications (e.g., App Engine, Cloud Run) but does not directly deliver a complete email/calendaring/document suite. The nonprofit’s need is to adopt a ready-made collaboration product quickly, not to build and operate one, so PaaS is not the best fit.
This is SaaS and matches the scenario precisely. The nonprofit wants the provider to run the full application stack: updates, backups, security baselines, scaling, and high availability—while the organization focuses on using the tools. Google Workspace is a typical SaaS example for email, calendaring, and document collaboration, enabling rapid rollout and predictable per-user pricing within a tight budget and limited admin capacity.
This describes IaaS: maximum control over VMs, networking, storage, and operating systems (e.g., Compute Engine). While flexible, it requires significant operational work to meet 99.9% availability (multi-zone design, patching, monitoring), plus backups and upgrades. With only a part-time sysadmin and a 14-day deadline, IaaS would add complexity and risk, and likely increase ongoing operational costs.
This suggests a strategy of dynamically shifting between flexibility and provider management, which is not a standard service model choice for delivering a collaboration suite. While organizations can mix SaaS/PaaS/IaaS across workloads, the question asks for the best fit for this specific need. The nonprofit’s requirements strongly point to SaaS rather than an approach that implies frequent model changes.
Core Concept: This question tests cloud service models (SaaS vs PaaS vs IaaS) and matching them to business constraints: rapid rollout, high availability, limited IT staff, predictable costs, and a desire for the provider to manage operations. Why the Answer is Correct: SaaS (Software as a Service) is the best fit because the nonprofit needs a complete email, calendaring, and document collaboration suite in 14 days with 99.9% availability, while having only one part-time sysadmin and a strict monthly budget. With SaaS, the provider operates the full application stack (application, runtime, OS, infrastructure), including upgrades, patching, backups, security baselines, and scaling. This directly aligns to the requirement that “the provider handle upgrades, backups, security baselines, and scaling so the team can focus on using the apps.” In Google Cloud terms, this typically maps to Google Workspace for Gmail, Calendar, Drive, and Docs, which is designed for fast deployment and minimal customer operations. Key Features / Best Practices: SaaS offerings provide built-in SLAs (often meeting or exceeding 99.9%), centralized admin controls, and security capabilities such as MFA/2-Step Verification, SSO/SAML, DLP and retention (plan-dependent), and audit logs. Operational tasks like capacity planning, server maintenance, and software version management are handled by the vendor, supporting the Google Cloud Architecture Framework principle of “operational excellence” by reducing undifferentiated heavy lifting. Cost is typically per-user/per-month, which improves predictability versus building and operating equivalent systems on IaaS/PaaS. Common Misconceptions: PaaS can sound attractive because it reduces server management, but it’s meant for building/deploying custom applications—not adopting a ready-made collaboration suite. IaaS offers maximum control, but it increases operational burden (patching, backups, HA design), which conflicts with the staffing and timeline constraints. “Dynamic shifting” between models is not a primary selection criterion for this scenario. Exam Tips: When requirements emphasize fastest time-to-value, minimal IT operations, vendor-managed updates/availability, and standard business functions (email/docs), choose SaaS. If the question emphasizes custom code deployment without managing servers, think PaaS. If it emphasizes OS/network control, think IaaS. Always map constraints (staffing, SLA, timeline, budget predictability) to the shared responsibility model.
Your telemedicine startup is expanding to 40 countries and must keep all imaging files and EMR records for Brazilian residents stored within Brazil due to local health data residency rules; clinicians worldwide are allowed to view this data, and your target p95 latency for viewers is under 250 ms from any continent. You need to choose an architecture and deployment approach that meets these requirements while enabling global access. What should you do?
A provider that operates only in Brazil may help with residency, but it does not address the need for efficient worldwide access. Without a broad global network, optimized routing, and mature global delivery capabilities, it is less likely to support strong user experience for clinicians on multiple continents. The question requires both compliance and global performance, not just local storage.
This is incorrect because replicating the imaging and EMR data across multiple continents conflicts with the requirement that Brazilian residents’ records be stored within Brazil. Cross-continent copies of the regulated dataset would generally create a residency and compliance problem. Faster reads do not matter if the architecture violates the core legal requirement.
This is the best option because it is the only one that directly combines in-country storage commitments with worldwide access. A large public cloud provider can keep the authoritative imaging and EMR records in Brazil while clinicians globally access the application over the provider’s global network and load-balancing infrastructure. The important distinction is that access can be global even when the regulated data remains stored only in Brazil. Contractual guarantees and regional deployment controls are also important for demonstrating compliance with residency requirements.
A single private data center in Brazil may keep the data in-country, but it is a poor fit for global access at scale. Users on distant continents would still face latency limits, and a single site also creates availability and resiliency concerns. The option focuses narrowly on location control while failing to address the worldwide access requirement.
Core concept: This question tests the difference between data residency and global access. The regulated requirement is that Brazilian residents’ imaging files and EMR records must remain stored in Brazil, while clinicians in other countries still need to access them with acceptable performance. The best answer is the option that preserves Brazil as the authoritative storage location and uses a provider with strong global networking and access capabilities rather than one that replicates the records internationally. Why correct: Option C is the best choice because it explicitly addresses both compliance and worldwide access. A major public cloud provider can contractually and operationally support storing the records in a Brazil region while allowing clinicians around the world to connect over a high-performance global network. The key point is that the records themselves remain stored in Brazil; global access does not require copying the regulated dataset to other continents. Key features: - Store the authoritative imaging and EMR data in a Brazil region using regional storage and databases. - Use provider controls such as region selection, organization policies, IAM, encryption, and audit logging to support residency and healthcare governance requirements. - Rely on the provider’s global backbone, load balancing, and optimized routing for worldwide access to applications and APIs. - If any acceleration or caching is used, it must be carefully limited so it does not violate the requirement that the regulated records remain stored within Brazil. Common misconceptions: A common mistake is assuming that low-latency global access always means replicating or caching the data worldwide. For regulated health records, that can violate residency rules. Another misconception is that private cloud is automatically better for compliance; in practice, compliance depends on where data is stored and what contractual and technical controls exist. Exam tips: When a question combines in-country storage with global users, prefer the answer that keeps the system of record in the required geography and uses a large provider’s global access capabilities. Be cautious with any option that explicitly replicates data across continents. Also avoid answers that satisfy residency but ignore performance and global reach.
An online sports streaming platform needs to process clickstream events in real time (average 15,000 events per second with bursts up to 180,000 events per second during playoffs), apply sliding-window aggregations and enrichment, and load the results into BigQuery with end-to-end latency under 5 seconds; the team does not want to manage clusters or worker VMs and requires a fully managed service that automatically scales compute with streaming throughput. Which Google Cloud product should they use?
Pub/Sub is a fully managed global messaging service ideal for ingesting clickstream events at high throughput and buffering bursts. However, Pub/Sub alone does not provide sliding-window aggregations, enrichment, or transformation logic. It is typically the source feeding a stream processor (like Dataflow) that performs computations before writing to BigQuery. So it’s necessary in the architecture, but not sufficient as the single product requested.
Dataflow is Google Cloud’s fully managed, autoscaling stream/batch processing service. It supports event-time processing, sliding windows, stateful aggregations, and enrichment, and it integrates directly with Pub/Sub and BigQuery. It meets the requirement of sub-5-second end-to-end latency when properly designed and avoids cluster/VM management because Google operates the workers and scaling behavior. This matches the need for automatic scaling during playoff bursts.
Data Catalog is a managed metadata and data governance service used to discover, classify, and manage metadata for datasets across Google Cloud (e.g., BigQuery tables, Pub/Sub topics, files in Cloud Storage). It does not process streaming events, perform aggregations, or load data into BigQuery. It may complement an analytics platform for governance, but it is not a real-time processing solution.
Dataprep by Trifacta (and its successors in the Google Cloud ecosystem) focuses on interactive, visual data preparation and transformation, typically for batch or exploratory workflows. It is not designed for high-throughput, low-latency streaming pipelines with sliding windows and sub-5-second end-to-end requirements. It also doesn’t provide the same streaming autoscaling execution model needed for 180,000 events/sec bursts.
Core Concept: This question tests knowledge of Google Cloud’s fully managed streaming data processing for real-time analytics: ingesting events, performing windowed aggregations/enrichment, and writing to BigQuery with very low latency—without managing infrastructure. Why the Answer is Correct: Dataflow is the correct product because it is Google Cloud’s fully managed stream and batch data processing service (based on Apache Beam) that supports event-time processing, sliding/tumbling windows, stateful processing, and exactly-once semantics (when configured appropriately). It can ingest from Pub/Sub, apply sliding-window aggregations and enrichment in real time, and write results to BigQuery with end-to-end latency targets like <5 seconds, assuming proper pipeline design and resource sizing. Crucially, Dataflow is serverless from an operations perspective: you do not manage clusters or worker VMs, and it automatically scales workers based on throughput, which matches the requirement for bursts up to 180,000 events/sec. Key Features / Best Practices: - Streaming pipelines with Apache Beam windowing (sliding windows), triggers, watermarks, and late data handling. - Autoscaling and dynamic work rebalancing to handle bursty traffic. - Native connectors: Pub/Sub source and BigQuery sink; use BigQuery Storage Write API (where applicable) for higher-throughput, lower-latency streaming writes. - Reliability and performance: choose appropriate worker machine types, enable Streaming Engine (when suitable) to reduce worker memory pressure, and design idempotent writes or use exactly-once patterns. - Architecture Framework alignment: operational excellence (managed service), performance efficiency (autoscaling), and reliability (managed execution, checkpointing). Common Misconceptions: Pub/Sub is often mistaken as the full solution because it is the ingestion layer, but it does not perform transformations, windowed aggregations, or enrichment. Dataprep is for interactive/visual data preparation, not low-latency streaming. Data Catalog is metadata management, not processing. Exam Tips: When you see “sliding-window aggregations,” “real-time enrichment,” “load into BigQuery,” and “no cluster/VM management with autoscaling,” think Dataflow. Pairing Pub/Sub (ingest) + Dataflow (process) + BigQuery (analytics) is a common streaming reference architecture on the Digital Leader exam.
A city transit authority trained a model to forecast peak ridership for 210 stations using 18 months of tap-in/out logs (5.6 million events) stored in BigQuery and refreshed daily, but to speed up feature engineering they omitted available station metadata (e.g., neighborhood type, accessibility level) and context fields (e.g., holiday indicator, major event flags), after which the model’s MAE was consistently >25% worse than baseline—what data quality dimension best explains the poor performance?
Validity refers to whether data conforms to defined rules and constraints (correct types, formats, ranges, allowed values). Examples include timestamps in valid formats, station IDs matching a reference list, or ridership counts not being negative. In the scenario, there’s no indication of rule violations; the issue is that useful fields were intentionally left out, not that existing fields are invalid.
Accuracy is about whether the data values correctly represent the real world (e.g., tap-in/out events are correctly captured, counts aren’t systematically underreported, station assignments aren’t wrong). Poor model MAE might tempt you to pick accuracy, but the prompt points to omitted metadata/context rather than incorrect logs. The data could be accurate yet still insufficiently informative for forecasting.
Timeliness measures whether data is current and available when needed. The logs are stored in BigQuery and refreshed daily, which generally supports timely forecasting. Timeliness problems would look like delayed ingestion, missing recent days, or late-arriving events causing the model to train on stale patterns. Here, the degradation is tied to excluding context features, not data freshness.
Completeness is the extent to which all required data is present to support the intended use case. By omitting station metadata and contextual indicators (holidays, major events), the dataset lacks key drivers of ridership variability. This reduces feature richness and predictive power, leading to worse MAE. In ML, completeness often means having the right coverage of entities, time periods, and explanatory attributes.
Core concept: This question tests data quality dimensions that affect ML outcomes, especially feature completeness in analytics/ML pipelines on Google Cloud (BigQuery as the source, daily refresh). In the Google Cloud Architecture Framework, this maps to building reliable data foundations and ensuring data is fit for purpose before modeling. Why the answer is correct: The team intentionally omitted available station metadata (neighborhood type, accessibility level) and contextual fields (holiday indicator, major event flags) to speed up feature engineering. That means the training dataset is missing important explanatory variables that strongly influence ridership patterns. When key fields are absent, the model has less signal to learn from, leading to higher error (MAE >25% worse than baseline). This is a classic “completeness” issue: the dataset does not include all necessary attributes to represent the real-world phenomenon. Key features / best practices: In BigQuery-centric ML workflows (e.g., BigQuery ML or exporting to Vertex AI), completeness is improved by joining dimension tables (station metadata) and adding derived context features (calendar tables, holiday/event flags). Best practices include maintaining a feature store or curated feature tables, using data validation checks (e.g., required columns present, non-null rates), and monitoring feature availability/drift over time. Daily refresh supports timeliness, but completeness ensures the model has the right breadth of information. Common misconceptions: “Accuracy” can sound like the model is inaccurate, but accuracy is a data quality dimension about whether recorded values reflect reality (e.g., wrong tap counts), not whether you included enough fields. “Validity” is about conformance to rules/types/ranges (e.g., timestamps in correct format). “Timeliness” is about being up to date; the logs are refreshed daily, so timeliness is not the primary issue. Exam tips: When a scenario mentions missing fields, omitted attributes, or not capturing important context, think “completeness.” When it mentions wrong values, think “accuracy.” When it mentions format/range violations, think “validity.” When it mentions stale/late-arriving data, think “timeliness.”
Ingin berlatih semua soal di mana saja?
Unduh Cloud Pass gratis — termasuk tes latihan, pelacakan progres & lainnya.
A satellite-imaging startup needs to accelerate training for a TensorFlow segmentation model with 150 million parameters; each epoch currently takes 45 minutes on general-purpose VMs with GPUs, and the team’s goal is to reduce epoch time to under 12 minutes without changing the training code or framework. Which domain-specific hardware on Google Cloud is designed specifically to speed up machine learning training for this use case?
Bare Metal Solution provides dedicated physical servers in Google Cloud for workloads needing specific hardware, low-level control, or licensing/latency requirements. It is not a domain-specific ML accelerator and does not inherently speed up TensorFlow training compared to using specialized accelerators like TPUs. It’s typically used for migrating legacy enterprise workloads (e.g., certain databases, SAP, or proprietary systems), not for accelerating deep learning training.
Preemptible/Spot VMs are a pricing and capacity option that can significantly reduce compute cost, but they do not provide specialized ML acceleration by themselves. They can be interrupted, which can slow overall time-to-train unless checkpointing and fault tolerance are well designed. They might help run more parallel experiments cheaply, but they are not “designed specifically” to speed up ML training per epoch.
Cloud TPUs are Google’s domain-specific hardware designed to accelerate machine learning workloads, especially TensorFlow training. They offer very high throughput for matrix operations and can scale across multiple TPU chips for faster training times. For a large segmentation model, moving from general-purpose VMs with GPUs to TPUs is a common way to reduce epoch duration substantially while staying within the TensorFlow ecosystem.
Containers (e.g., Docker on GKE or Cloud Run) are an application packaging and deployment technology. They improve portability, consistency, and operational management, but they do not inherently accelerate model training. Containers can run on CPUs, GPUs, or TPUs, but the performance gain comes from the underlying accelerator, not from containerization itself. Therefore, containers are not the domain-specific hardware requested.
Core Concept: This question tests knowledge of Google Cloud’s domain-specific accelerators for machine learning (ML) training. In Google Cloud, the purpose-built hardware for accelerating TensorFlow training workloads is Cloud TPU (Tensor Processing Unit). Why the Answer is Correct: The startup needs to reduce epoch time significantly (45 minutes to under 12) and cannot change training code or framework. Cloud TPUs are designed specifically to accelerate large-scale ML training, particularly for TensorFlow, by providing high-throughput matrix multiplication and optimized interconnect for distributed training. Because TPUs are integrated with TensorFlow (and supported via standard TensorFlow/Keras APIs), teams can often move training to TPUs with minimal code changes compared to rewriting for a different framework. For an exam-level interpretation, “without changing the training code or framework” aligns best with TPUs as the domain-specific ML training hardware on Google Cloud. Key Features / Best Practices: Cloud TPUs provide: - Specialized ML compute (systolic arrays) optimized for dense linear algebra common in deep learning. - High-bandwidth memory and fast TPU interconnects for scaling training across multiple TPU chips/pods. - Strong TensorFlow ecosystem support (TPU-enabled TensorFlow, Keras, and common training patterns). Architecturally, this maps to the Google Cloud Architecture Framework’s Performance Optimization and Cost Optimization pillars: use the right compute for the workload, and scale efficiently to meet time-to-train targets. Common Misconceptions: It’s tempting to pick Spot/Preemptible VMs because they are “faster/cheaper,” but they primarily reduce cost, not per-epoch time, and can be interrupted. Containers help packaging and portability, not raw training acceleration. Bare Metal Solution is for specialized legacy or licensing needs and does not provide ML-specific acceleration. Exam Tips: When you see “domain-specific hardware for ML training” on Google Cloud, think “TPU.” GPUs are general-purpose accelerators; TPUs are purpose-built for training/inference of neural networks. Also distinguish cost levers (Spot VMs) from performance levers (TPUs, higher-end GPUs, distributed training).
A manufacturing company trains a Vertex AI AutoML image classification model on 250,000 product photos to detect defects and later discovers that 8% of the training labels were incorrect due to a data pipeline merge error; what is the most likely impact on the model’s predictions?
Increased risk of privacy leaks is not the most direct or likely impact of incorrect training labels. Privacy risks typically come from using sensitive data improperly, weak access controls, or models memorizing identifiable information (e.g., PII) and exposing it through outputs. A label merge error changes correctness of ground truth, not confidentiality. While any ML system can have privacy considerations, mislabeled data primarily harms prediction quality rather than increasing data exposure.
Incorrect labels introduce label noise, which directly degrades supervised learning. The model is trained to match wrong targets for a meaningful portion of examples (~20,000 out of 250,000). This typically reduces accuracy and harms metrics like precision/recall, increasing false positives/negatives in defect detection. AutoML can optimize architecture and hyperparameters, but it cannot compensate for systematically wrong ground truth; better labels and pipeline validation are required.
Decreased model compatibility is unrelated to label correctness. Compatibility concerns usually involve whether a model can be deployed to a target environment (edge vs cloud), supported formats, latency/throughput requirements, or integration with serving infrastructure. A label merge error does not change the model’s runtime requirements or supported deployment options; it changes what the model learns, affecting performance rather than compatibility.
Decreased model training time is not a likely outcome of mislabeled data. Training time in Vertex AI AutoML is driven by dataset size, image resolution, chosen training budget, and compute resources. Incorrect labels do not reduce the number of images or the compute required. If anything, noisy labels can make learning less efficient and may require more experimentation or retraining cycles, increasing overall time to reach acceptable performance.
Core Concept: This question tests data quality and label correctness in supervised machine learning, specifically Vertex AI AutoML image classification. In supervised learning, the model learns a mapping from images (features) to labels (ground truth). If the ground truth is wrong, the model is trained to reproduce incorrect targets, which directly affects predictive performance. Why the Answer is Correct: If 8% of the training labels are incorrect due to a pipeline merge error, the training set contains label noise. Label noise reduces the signal-to-noise ratio in the learning process: the model receives contradictory supervision (similar images mapped to different labels, or defective items labeled as non-defective and vice versa). The most likely impact is increased risk of inaccuracy—lower precision/recall, more false positives/false negatives, and poorer generalization to new product photos. With 250,000 images, 8% represents ~20,000 mislabeled examples, which is substantial and can measurably degrade model quality, especially for edge cases and minority defect classes. Key Features / Best Practices: Vertex AI AutoML can help with training and evaluation, but it cannot “fix” incorrect ground truth. Best practices include: validating labels (human review, consensus labeling), using data validation checks in pipelines, monitoring training/validation metrics for unexpected drops, and using confusion matrices to identify systematic label issues. From the Google Cloud Architecture Framework perspective, this aligns with Operational Excellence and Reliability: build robust data pipelines, implement quality gates, and continuously monitor model performance and data drift. Common Misconceptions: It’s tempting to associate “bad data” with privacy leaks, but incorrect labels are primarily a quality issue, not a security issue. Another misconception is that AutoML will automatically overcome label errors; while large datasets can be somewhat robust to small noise, 8% can still meaningfully harm accuracy. Training time is also not expected to decrease; if anything, noisy labels can make optimization harder, but it typically doesn’t reduce training duration. Exam Tips: For ML questions, map the issue to the ML lifecycle stage: labeling errors affect model quality/accuracy. Privacy leaks relate to exposure of sensitive data or membership inference risks, not mislabeled classes. Compatibility is about deployment/runtime constraints, not training labels. When you see “incorrect labels,” the default impact to choose is degraded accuracy/performance.
A fintech company migrating to Google Cloud configures IAM so that billing clerks receive only the BigQuery Data Viewer role on 3 specific datasets and no write permissions to any other 12 datasets or projects, enforced via IAM Conditions tied to a finance Google Group and restricted to office hours (09:00–18:00); which security principle best describes granting just the minimum permissions required for their duties?
Cyber resilience focuses on an organization’s ability to withstand, respond to, and recover from cyber incidents (e.g., backups, disaster recovery, incident response processes, redundancy). While limiting permissions can reduce impact, the scenario is not about recovery or continuity planning. It is specifically about restricting access rights for a role, which aligns more directly with least privilege than resilience.
Zero-trust is a broader security model: “never trust, always verify,” typically involving continuous authentication/authorization, strong identity signals, device posture, and context-aware access. IAM Conditions (like time restrictions) can support a zero-trust approach, but the question’s key phrase is granting the minimum permissions required for duties. That principle is least privilege, not the overall zero-trust model.
Least privilege means granting identities only the minimum permissions needed to perform their job, and nothing more. In Google Cloud, this is implemented by selecting the narrowest role (BigQuery Data Viewer), scoping it to the smallest resource set (only 3 datasets), avoiding broader project-level permissions, and optionally adding IAM Conditions (office hours) to further reduce unnecessary access. This exactly matches the scenario.
Security by default refers to systems and services being configured securely out of the box (secure defaults, baseline protections, guardrails). While Google Cloud provides many secure defaults, the scenario is about deliberate, fine-grained permission assignment and conditional access for a specific job function. That is an access control design choice aligned with least privilege rather than a default configuration principle.
Core Concept: This question tests the security principle of least privilege as applied through Google Cloud IAM. It also touches IAM Conditions (attribute-based access control) and resource-level permissions in BigQuery (dataset-level roles). Why the Answer is Correct: The scenario explicitly describes granting billing clerks only the minimum permissions needed: BigQuery Data Viewer on only 3 specific datasets, with no write permissions elsewhere, and further restricting when access is valid (office hours) using IAM Conditions tied to a finance Google Group. This is a textbook example of least privilege: users receive only the permissions required to perform their job, scoped as narrowly as possible (role, resource, and time). Key Features / Best Practices: - IAM roles: BigQuery Data Viewer is a predefined role intended for read-only access to BigQuery data. - Resource scoping: Applying permissions at the dataset level (instead of project-wide) reduces blast radius and aligns with the Google Cloud Architecture Framework’s security principle of minimizing access and limiting scope. - Group-based access: Binding roles to a Google Group simplifies lifecycle management (join/leave group) and reduces administrative overhead. - IAM Conditions: Adds contextual constraints (e.g., time-based access) to further reduce risk. Conditions complement least privilege by making access not only minimal, but also conditional. Common Misconceptions: - Zero-trust can sound similar because it emphasizes continuous verification and context-aware access, but the question asks specifically about “granting just the minimum permissions required,” which is least privilege. - “Security by default” refers to secure baseline configurations and safe defaults, not tailoring permissions to job duties. - “Cyber resilience” is about preparing for, responding to, and recovering from incidents, not permission minimization. Exam Tips: When you see phrases like “only the permissions needed,” “no more than necessary,” “scoped to specific resources,” or “restricted access,” think least privilege. If the question emphasizes verifying every request, device posture, or continuous authentication, think zero-trust. If it emphasizes backups, DR, incident response, and recovery objectives, think resilience. If it emphasizes default secure settings and guardrails, think security by default.
A municipal transit agency operates a 20-year-old on-prem scheduling system and has a budget cap of $10,000 for integration this fiscal year, with no ability to replace the core system for the next 12 months. A private operator partner runs a modern optimization platform in their own cloud environment and needs secure, programmatic access to route and ridership data (~1.2 million records/day) without the agency migrating or rehosting the legacy app. What solution should the agency choose to make their data accessible to the partner platform?
Compute Engine provides virtual machines to run workloads on Google Cloud. It could host middleware that queries the legacy system and exposes endpoints, but the VM itself is not the primary solution concept being tested. It also introduces operational overhead (patching, scaling, security hardening) and can exceed a small integration budget if you build a custom integration stack. The question is about making data accessible, best met by an API approach.
Anthos is a hybrid/multi-cloud application platform for modernizing and operating Kubernetes-based workloads consistently across environments. While Anthos can help manage hybrid deployments, it is not necessary to expose legacy on-prem data to a partner, and it is typically far beyond a $10,000 integration effort. Anthos is a modernization and operations platform, not the simplest integration mechanism for a legacy system.
An API is the correct choice because it provides a secure, programmatic interface for the partner to access route and ridership data without migrating or rehosting the legacy scheduling application. An API layer can enforce authentication/authorization, rate limits, logging, and versioning, and can be implemented as a thin wrapper around existing exports or queries. This matches the constraints: minimal change, low cost, and partner-ready integration.
Google Kubernetes Engine (GKE) is a managed Kubernetes service for running containerized applications. Choosing GKE implies containerizing and operating services, which is unnecessary for the stated requirement and conflicts with the constraint of not replacing or rehosting the legacy system. While you could build an API service on GKE, the exam-relevant concept is the API interface itself, not the container orchestration platform.
Core Concept - The question tests integration and interoperability: exposing data from a legacy, on-premises system to an external partner securely and programmatically without migrating or modernizing the core application. In Google Cloud terms, this is an API-led integration pattern (often implemented with an API gateway/management layer), not a compute or container modernization choice. Why the Answer is Correct - An application programming interface (API) is the most direct, lowest-disruption way to provide controlled, programmatic access to route and ridership data while leaving the 20-year-old scheduling system in place. The partner needs ongoing access (~1.2M records/day), which is well-suited to a REST/JSON (or similar) interface that can be called from their cloud environment. An API can be placed in front of the legacy data source (or a replicated/exported dataset) and can enforce authentication, authorization, throttling, and auditing—key requirements when sharing municipal data with a third party. It also aligns with the $10,000 integration cap because it avoids rehosting, refactoring, or platform migration. Key Features - In practice, agencies commonly implement this using an API gateway and identity controls (e.g., OAuth 2.0/JWT, service accounts, mTLS), plus rate limiting/quotas to protect the legacy system. API management can provide versioning, monitoring, and developer onboarding. If the legacy system cannot handle direct query load, the API can serve from an exported/replicated store (batch or incremental) while keeping the core system untouched. This approach supports the Google Cloud Architecture Framework principles of security (least privilege, strong auth), reliability (shielding the legacy backend), and cost optimization (minimal change, pay only for what’s used). Common Misconceptions - Compute Engine, GKE, and Anthos are often chosen when people think “put something on Google Cloud,” but the requirement explicitly says no rehosting/migrating the legacy app for 12 months. Those options are infrastructure/app-platform solutions, not the integration interface itself. Exam Tips - When a question emphasizes “secure, programmatic access,” “partner integration,” and “no migration,” think “API” (and optionally API management) rather than compute or Kubernetes. Also note budget and timeline constraints: integration patterns that wrap existing systems usually win over modernization platforms.
A logistics startup is migrating 120 microservices and 300 VMs to Google Cloud; during the first 30 days they need out-of-the-box observability—without custom agents or dashboards—to understand system health and performance across services; in this context, what does out-of-the-box observability refer to?
This option describes project management reporting, not observability. Sprint burndown charts and delivery dates help teams track work progress and release planning, but they do not provide telemetry about whether services are healthy or performing well in production. Observability is concerned with runtime signals such as logs, metrics, and error conditions from systems. Therefore, this option is outside the scope of cloud operations monitoring.
This is correct because observability refers to understanding the behavior and health of running systems through telemetry such as metrics, logs, and performance signals. The phrase “out-of-the-box” means the startup wants immediate visibility using default or prebuilt Google Cloud capabilities rather than first designing custom dashboards or deploying a separate observability platform. In a migration scenario with many microservices and VMs, this kind of built-in monitoring is valuable for quickly identifying errors, latency issues, and resource problems. Option B matches that definition by focusing on health, performance, and logs for cloud-hosted infrastructure and applications using default tools.
This option is about customer sentiment and product feedback rather than technical system visibility. NPS scores and app store reviews can indicate whether users are happy, but they do not explain infrastructure health, service latency, or application failures. Observability focuses on internal operational data that helps engineers diagnose and understand system behavior. Because this option measures business perception instead of runtime telemetry, it is not the correct meaning of out-of-the-box observability.
This option refers to financial management and cost analysis, not observability. Auditing cloud spend and forecasting future costs are important FinOps activities, but they do not tell engineers whether services are available, fast, or error-free. The question specifically asks about understanding system health and performance across services during migration. That makes cost reporting irrelevant to the core concept being tested here.
Core Concept: This question tests “out-of-the-box observability” in Google Cloud, which is primarily delivered through Google Cloud Operations Suite (formerly Stackdriver): Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, and Error Reporting. Observability means being able to understand system health and performance from telemetry (metrics, logs, traces) across infrastructure and applications. Why the Answer is Correct: The scenario emphasizes the first 30 days of a migration of many microservices and VMs and requires observability “without custom agents or dashboards.” Out-of-the-box observability refers to using default, built-in monitoring and logging capabilities that work immediately with minimal setup. In Google Cloud, many services automatically emit platform metrics and logs, and Cloud Operations provides default dashboards, alerting policies, and service views (for example, GKE and many managed services integrate natively). This aligns directly with option B: monitoring health, performance, and logs using default tools. Key Features: - Default metrics and logs: Google Cloud services produce system and service metrics and audit logs automatically. - Cloud Monitoring: prebuilt dashboards, uptime checks, alerting, and SLO-style monitoring patterns. - Cloud Logging: centralized log storage, Log Explorer, and default log ingestion for many services. - Service-centric troubleshooting: traces/profiles/errors can be enabled to diagnose latency and failures; for some environments, additional instrumentation may be needed, but the question explicitly asks what the term refers to. - Best practice alignment: The Google Cloud Architecture Framework emphasizes operational excellence—monitoring, alerting, and reliability practices early in the lifecycle, especially during migrations. Common Misconceptions: People sometimes confuse observability with project management (agile burndown), customer sentiment (NPS/reviews), or financial governance (cost forecasting). Those are important business functions, but they are not observability. Another misconception is that observability always requires custom dashboards and agents; while deeper application-level telemetry may require instrumentation, “out-of-the-box” specifically means default capabilities available immediately. Exam Tips: On Digital Leader exams, map keywords: “observability,” “system health,” “performance,” “logs,” and “across services” strongly indicate Cloud Operations Suite. “Out-of-the-box” signals minimal configuration and prebuilt views rather than custom-built dashboards or bespoke agents. Also distinguish observability from FinOps (cost), DevOps planning (sprints), and customer analytics (NPS).
Masa belajar: 1 month
시험 문제랑 많이 유사해서 좋았어요. 강의 다 듣고난 후에 문제 찾기 어려웠는데 앱 너무 잘 이용했네요
Masa belajar: 1 month
Good questions and explanations. The resource is very similar to the real exam questions. Thanks.
Masa belajar: 1 month
This is exactly what you need to pass the GCP CDL exam. The look and feel are exactly how you would experience the real exam. The questions are very similar and you'll even find a few on the exam itself. I would recommend this for anyone looking to obtain this certification. The exam is not an easy one, so the explanations to the questions are very helpful to solidify your understanding and help.
Masa belajar: 2 months
I used Cloud Pass to prepare for the GCP CDL exam, and it made a huge difference. The practice questions covered a wide range of scenarios I actually saw on the test. The explanations were clear and helped me understand how LookML and data modeling work in real projects. If you focus on understanding the logic behind each question, this app is more than enough to pass.
Masa belajar: 1 month
Cloud Pass was my main study tool for the GCP CDL exam, and I passed on the first try. The questions were realistic and helped me get comfortable with Looker concepts, permissions, explores, and model structures. I especially liked that I could reset my progress and re-solve the tricky questions. Strongly recommend this for anyone targeting CDL.
Unduh Cloud Pass dan akses semua soal latihan Google Cloud Digital Leader secara gratis.
Ingin berlatih semua soal di mana saja?
Dapatkan aplikasi gratis
Unduh Cloud Pass gratis — termasuk tes latihan, pelacakan progres & lainnya.
