GCP
Google Associate Cloud Engineer
296+ kostenlose Übungsfragen mit KI-verifizierten Antworten
Alle Fragen &
Antworten kostenlos
Detaillierte
ErklärungGCP
296+ kostenlose Übungsfragen mit KI-verifizierten Antworten
Alle Fragen &
Antworten kostenlosDetaillierte
Erklärung
Der echten
Prüfung am nächstenKI-gestützt
Jede Google Associate Cloud Engineer-Antwort wird von 3 führenden KI-Modellen kreuzverifiziert, um maximale Genauigkeit zu gewährleisten. Erhalte detaillierte Erklärungen zu jeder Option und tiefgehende Fragenanalysen.
Your team runs a Linux build server on a Compute Engine VM named build-ci-07 (Ubuntu 22.04 LTS) in us-central1-b with an external IP of 34.118.52.10, and a freelance penetration tester connected to your corporate network via an IPsec VPN (10.20.0.0/16) needs temporary SSH access within the next 24 hours but does not have a Google account; what should you do to grant access securely and quickly?
Incorrect. IAP for TCP forwarding (and gcloud compute ssh via IAP) requires the user to authenticate to Google Cloud and have appropriate IAM permissions (e.g., IAP-secured Tunnel User plus Compute permissions). Since the tester has no Google account, they cannot complete the identity and authorization steps needed to establish an IAP tunnel, even if it would otherwise be the most secure pattern.
Incorrect/incomplete. Using gcloud compute ssh also requires Google authentication (a Google account) to call the Compute Engine API and manage ephemeral keys/metadata. Additionally, directly targeting the VM’s public IP can encourage opening SSH to the internet; the safer approach is to restrict SSH to the VPN CIDR and use standard SSH with a provided public key rather than relying on gcloud.
Correct. Standard SSH key-based access works without a Google account. The tester generates a key pair and shares only the public key; you add it at the instance level (metadata) or to ~/.ssh/authorized_keys for a temporary user. You can enforce the 24-hour window by setting an expiration on the metadata SSH key and by limiting firewall rules to allow tcp:22 only from 10.20.0.0/16.
Incorrect and insecure. A private key must never be shared; it is the secret that proves identity. If the tester sends you their private key, you could impersonate them, and the key could be exposed in transit or storage, violating basic security practices and most compliance standards. Also, SSH authentication uses the private key on the client side; adding a private key to the server is not the correct model.
Core concept: This question tests secure, temporary SSH access to a Compute Engine VM when the user does not have a Google identity. It focuses on OS Login/IAP vs traditional SSH key management via instance/project metadata and Linux authorized_keys. Why the answer is correct: Because the tester does not have a Google account, they cannot authenticate to Google Cloud IAM, which is required for Identity-Aware Proxy (IAP) TCP forwarding and for gcloud-based SSH flows that rely on Google identity. The fastest secure approach is to use standard SSH: have the tester generate an SSH key pair, provide you only the public key, and you add it to the VM (preferably instance-level metadata for least privilege and easy removal, or directly to the target user’s ~/.ssh/authorized_keys). This grants access without creating a Google account and can be revoked quickly by removing the key. Key features / best practices: - Use instance-level SSH keys (metadata) for scoped, temporary access rather than project-wide keys. - Set an expiration on metadata SSH keys (supported format includes an expireOn field) to enforce the 24-hour requirement. - Restrict network exposure: since the tester is on your corporate network via IPsec VPN (10.20.0.0/16), ensure firewall rules allow tcp:22 only from that CIDR, not from the internet, even though the VM has an external IP. - Prefer a dedicated temporary Linux user with limited sudo, and log access (Cloud Logging/OS logs) for auditability. Common misconceptions: - “Use IAP” sounds most secure, but it requires the user to authenticate with Google (IAM). Without a Google account, they cannot use IAP. - “Just SSH to the public IP” is quick, but if you open SSH broadly it increases attack surface; it also doesn’t solve authentication unless you still manage keys. - Sharing private keys is never acceptable; private keys must remain private. Exam tips: On ACE, if a user lacks a Google identity, you generally cannot use IAM-gated access methods (IAP, OS Login). Fall back to SSH public key distribution, scope it narrowly (instance-level), time-bound it (key expiration), and pair it with firewall restrictions (source ranges) to meet security and speed requirements in real-world operations.
You need to configure an automated policy for a specific dual-region Cloud Storage bucket so that project documents are transitioned to Archive storage after 180 days and then permanently deleted exactly 730 days (2 years) after their creation; how should you set up the policy?
Incorrect. It assumes the Delete Age condition is relative to the previous lifecycle action (transition at 180 days), so it subtracts 180 from 730 and uses 550. In Cloud Storage lifecycle, Age is always measured from the object’s creation time, not from when it was transitioned. This would delete objects at 550 days after creation, violating the 2-year requirement.
Correct. Configure two Cloud Storage lifecycle rules using Age conditions measured from object creation: SetStorageClass to ARCHIVE at Age 180, and Delete at Age 730. This matches the requirement to transition after 180 days and delete 730 days after creation. This is the standard, fully managed approach and works the same for dual-region buckets.
Incorrect. gsutil rewrite is a manual/one-time operation to rewrite objects (often used to change storage class, encryption, or metadata). It does not create an automated ongoing policy for future objects. Also, setting Delete to 550 days repeats the same Age misunderstanding as option A and would delete too early.
Incorrect. While 730 days matches the desired deletion age, gsutil rewrite still does not implement an automated lifecycle policy; it only rewrites existing objects at the time you run it. It also doesn’t address the required automatic transition to Archive at 180 days for all objects over time.
Core Concept: This question tests Cloud Storage Object Lifecycle Management. Lifecycle rules let you automatically transition objects between storage classes (e.g., Standard to Archive) and delete objects based on conditions such as Age (days since object creation), creation date, or newer versions. This is an operations-focused control to manage cost and retention without custom scripts. Why the Answer is Correct: The requirement is: (1) transition to Archive after 180 days, and (2) permanently delete exactly 730 days after creation. In Cloud Storage lifecycle, an Age condition is evaluated relative to the object’s creation time, not relative to when a previous lifecycle action occurred. Therefore, you must configure two separate rules with Age conditions measured from creation: - Rule 1: Age = 180, action SetStorageClass = ARCHIVE - Rule 2: Age = 730, action Delete This ensures deletion occurs at 730 days from creation regardless of the earlier transition. Key Features / Best Practices: Lifecycle policies are enforced by Cloud Storage automatically (no cron jobs, no Compute). They apply per bucket (including dual-region buckets) and scale with no additional infrastructure. Using Archive after 180 days aligns with cost optimization (Google Cloud Architecture Framework: cost optimization and operational excellence). Deletion at 730 days enforces retention/cleanup. Note that lifecycle actions are not guaranteed to execute at an exact timestamp; they are applied asynchronously, typically within a day, so “exactly” in exam context means “based on Age=730,” not “to-the-second.” Common Misconceptions: A common trap is subtracting 180 from 730 and setting Delete at 550 days, assuming the delete timer starts after the storage-class transition. That is incorrect because Age is always since creation. Another misconception is using gsutil rewrite; rewrite changes storage class by copying/rewriting objects and is not an automated ongoing policy. Exam Tips: For retention/transition questions, default to Cloud Storage lifecycle rules. Remember: Age/CreatedBefore are evaluated from object creation time. Use multiple rules for multiple milestones. Also distinguish lifecycle management (automated policy) from one-time administrative commands (gsutil rewrite) and from retention policies/holds (which prevent deletion rather than schedule it).
You manage a single custom-mode VPC named 'corp-net' in project alpha-prod with one subnetwork 'asia-pri' in asia-southeast1 (10.20.0.0/20). A Compute Engine VM 'app-1' (10.20.0.5) in this subnet exposes an internal-only HTTPS service on TCP 8443 that must not be publicly reachable. You must deploy a new VM in southamerica-east1 that needs private access to 'app-1'. You want a Google-recommended solution with minimal operational overhead and no public exposure. What should you do?
Correct. A single VPC network is global, so adding a southamerica-east1 subnet to corp-net lets the new VM communicate privately with app-1 over internal IP routing. This is minimal operational overhead: no VPN, no peering, no load balancer required. You only need to ensure firewall rules permit tcp:8443 from the new subnet (or specific VM identity) to app-1, keeping the service non-public.
Incorrect. An internal TCP/UDP load balancer is regional and intended to provide a stable internal VIP and distribute traffic to backends in the same region (or via specific cross-region designs, which add complexity). It also doesn’t solve the core need because the bigger issue is network connectivity between two VPCs (sa-net and corp-net). This option introduces unnecessary components and higher operational overhead.
Incorrect. Cloud VPN is not needed for connectivity between subnets in the same VPC; GCP already provides private routing across regions within one VPC. Building a VPN between two regions inside the same VPC is unnecessary complexity, adds cost, and increases operational burden (tunnel management, routing, monitoring). VPN is appropriate for on-prem-to-cloud or VPC-to-VPC connectivity, not intra-VPC.
Incorrect. VPC peering connects two separate VPCs privately, but it’s more complex than simply using one VPC with multiple subnets. It also introduces administrative overhead and limitations (no transitive routing, separate firewall rule management per VPC). Since you already have corp-net and only need a new VM in another region, creating another VPC and peering is not the minimal, Google-recommended approach.
Core Concept: This question tests how Google Cloud VPC networking works across regions. A single VPC network is global, while subnets are regional. Resources in different regions can communicate privately over Google’s backbone as long as they are in the same VPC (or connected via supported private connectivity) and firewall rules allow it. Why the Answer is Correct: Option A is the Google-recommended, lowest-ops approach: extend the existing custom-mode VPC (corp-net) by creating a new regional subnet in southamerica-east1, then place the new VM there. Because both VMs are in the same VPC, they can route to each other using internal RFC1918 addresses (10.20.0.5) without any public IPs, VPNs, or peering. This keeps the HTTPS service internal-only and minimizes operational overhead. Key Features / Configurations: - Create a non-overlapping subnet range (10.20.16.0/20 is valid given 10.20.0.0/20 already exists). - Ensure firewall rules allow ingress to app-1 on tcp:8443 from the new VM’s source range (e.g., 10.20.16.0/20) using network tags or service accounts for least privilege. - Do not assign external IPs if you want to reduce accidental public exposure; rely on internal DNS/IP. - This aligns with Google Cloud Architecture Framework guidance: prefer simple, managed, least-complex designs; use private connectivity and least-privilege firewalling. Common Misconceptions: Many assume cross-region private connectivity requires Cloud VPN (option C). In GCP, that’s only needed to connect different networks (on-prem to VPC, or VPC-to-VPC via HA VPN), not for two subnets inside the same VPC. Others may think VPC peering (option D) is needed, but peering is for connecting separate VPCs and adds constraints (no transitive routing, separate firewall administration). Exam Tips: - Remember: VPC = global; subnet = regional. - Same VPC across regions provides private routing by default; you mainly manage firewall rules. - Choose solutions that avoid unnecessary components (VPN, peering, load balancers) when simple VPC design suffices. - For “internal-only service,” focus on internal IPs + restrictive firewall rules, not public load balancers.
Your company runs a public Nginx download service on a Managed Instance Group of three Compute Engine VMs in us-central1, and the project hosts several other workloads; you need to receive an email when Google Cloud’s measured egress network charges attributable to those Nginx instances exceed 120 dollars for the current calendar month; what should you do?
A project-level budget can email when total project spend reaches a threshold, but it cannot reliably isolate only the egress charges from the Nginx MIG when the project hosts other workloads. Even if you filter by service, you still may include egress from other VMs/services. This fails the “attributable to those Nginx instances” requirement and risks false positives/negatives.
A billing account budget is even broader than a project budget and is intended for overall spend governance across projects. While budgets support some filtering, it’s not designed to attribute costs to a specific MIG’s instances within a project. This would alert on unrelated spend and does not meet the requirement for Nginx-instance-specific egress charges.
Billing export to BigQuery with resource-level cost details provides authoritative billed costs and (when enabled/available) resource identifiers/labels to attribute spend to specific instances. Querying network egress SKUs for the labeled Nginx instances and summing for the current month precisely matches the requirement. Cloud Scheduler + Cloud Function provides periodic evaluation and email notification without managing servers.
Estimating egress charges from Nginx access logs is not equivalent to Google Cloud’s billed egress. Logs reflect application payload sizes, not necessarily billable bytes, and won’t capture network billing nuances (tiered pricing, overhead, retries, partial responses, other egress paths). This approach is error-prone, operationally brittle, and contradicts the requirement for Google’s measured charges.
Core Concept: This question tests Cloud Billing cost attribution and alerting at a resource/workload level. Budgets and alerts in Cloud Billing are primarily scoped to a billing account (or project) and can be filtered, but they do not natively alert on “charges attributable to a specific Managed Instance Group’s instances” unless you have a reliable way to attribute costs to those resources (labels/resource-level cost data). Why the Answer is Correct: Option C uses Cloud Billing export to BigQuery with resource-level cost details, then programmatically aggregates only the relevant network egress SKUs for the Nginx instances (identified via labels, instance IDs, or MIG-related labels) for the current calendar month. This directly matches the requirement: “Google Cloud’s measured egress network charges attributable to those Nginx instances” and excludes other workloads in the same project. Scheduling hourly checks and emailing on threshold breach provides timely notification. Key Features / Best Practices: - Cloud Billing export to BigQuery provides authoritative, measured costs (not estimates). - Resource-level cost attribution (when available) enables filtering by labels/resource identifiers, aligning with the Google Cloud Architecture Framework’s operational excellence principle (measurable operations and actionable alerts). - Cloud Scheduler + Cloud Functions is a common serverless pattern for periodic compliance/finance checks. - Label the MIG template/instances (e.g., app=nginx-download) to make cost attribution robust. Common Misconceptions: Many assume budgets can alert on any subset of resources inside a project. In practice, budgets are best for overall spend (billing account/project/service) and may not isolate a specific MIG’s egress charges. Another misconception is that log-based estimation (Option D) equals billed egress; it won’t account for CDN/proxying, protocol overhead, retries, compression, or Google’s billing SKUs and tiering. Exam Tips: - If the requirement says “measured charges” and “attributable to specific resources,” think Billing export (BigQuery) and labels/resource-level cost data. - Use budgets for broad spend control; use exports + analytics for fine-grained attribution. - Watch for “current calendar month” wording: your query must filter by invoice month/time window and handle partial-month accrual. - Consider quotas/cost: BigQuery queries and scheduled functions incur small costs; keep queries efficient (partitioned tables, filtered date ranges).
Your company is launching a high-traffic digital ticketing API in a new Google Kubernetes Engine (GKE) regional cluster in us-central1 with cluster autoscaling enabled (minimum 2 nodes, maximum 20 nodes), and the application can scale from 3 to 50 pods during peak events; you must expose the API to the public over HTTPS using a single global public IPv4 address without modifying application code, and you want Google-managed TLS certificates to terminate HTTPS while supporting rolling updates and pod autoscaling. What should you do?
Correct. A Kubernetes Service used with GKE Ingress allows Google Cloud to provision an external HTTP(S) load balancer in front of the application. That load balancer can be assigned a single reserved global static IPv4 address, which directly satisfies the requirement for one global public endpoint. Google-managed certificates can be attached so TLS is terminated at the load balancer and certificate provisioning and renewal are handled automatically by Google. This approach also works well with rolling updates and autoscaling because the load balancer sends traffic only to healthy, ready backends as pods and nodes change over time.
Incorrect. A ClusterIP Service is only reachable from within the cluster or connected internal networks and is not a public internet endpoint. Public DNS cannot meaningfully point clients to a private ClusterIP and make the service internet-accessible. This option also does not provide a global public IPv4 address or a Google-managed HTTPS termination point. As a result, it fails both the networking and TLS requirements in the scenario.
Incorrect. Exposing a NodePort on every node and publishing all node IPs in DNS does not provide a single global public IPv4 address, which is explicitly required. It is also operationally fragile because cluster autoscaling adds and removes nodes, causing the set of node IPs to change over time. DNS-based distribution does not provide managed Layer 7 HTTPS features such as centralized TLS termination, health-aware request routing, and proper backend draining during updates. This design therefore does not meet the reliability, manageability, or certificate requirements.
Incorrect. Running HAProxy in a pod and forwarding traffic through one node’s external IP creates an unnecessary custom load-balancing layer and introduces a likely single point of failure. One node IP is not equivalent to a Google-managed global anycast IPv4 address, and the design would require you to manage failover, health checks, and proxy lifecycle yourself. It also bypasses the native GKE Ingress integration that supports managed TLS certificates and seamless backend updates. This option adds complexity while failing to meet the stated global public endpoint and managed HTTPS goals.
Core concept: This question tests how to expose a GKE workload publicly over HTTPS using Google Cloud Load Balancing with Kubernetes Ingress, while meeting requirements for a single global IPv4 address, Google-managed TLS, and compatibility with autoscaling and rolling updates. Why the answer is correct: Option A uses the standard GKE pattern: a Service (commonly NodePort when used with Ingress) plus a Kubernetes Ingress that provisions a Google Cloud external HTTP(S) Load Balancer. This load balancer is global (anycast) and can be assigned a single reserved global static IPv4 address. Using Google-managed certificates (via GKE Ingress + ManagedCertificate or Certificate Manager integration, depending on cluster version) allows Google to provision/renew TLS automatically and terminate HTTPS at the load balancer—no application code changes required. Key features and best practices: - Global external HTTP(S) Load Balancer: provides a single global IPv4, cross-region edge termination, and L7 routing. - Google-managed TLS: simplifies operations and aligns with the Google Cloud Architecture Framework’s reliability and security pillars (automated cert lifecycle, strong defaults). - Works with GKE autoscaling: the Ingress LB targets node instance groups (or NEGs when enabled). As cluster autoscaler adds/removes nodes and HPA scales pods, the backend membership updates automatically. - Rolling updates: Kubernetes Deployments update pods gradually; the load balancer health checks and readiness gates ensure traffic only reaches ready endpoints. Common misconceptions: - Confusing Service IP types: a ClusterIP is internal-only and not reachable from the public internet. - Thinking DNS can “load balance” by listing node IPs: nodes are ephemeral under autoscaling and this breaks the single global IP requirement. - Building custom LBs (HAProxy) inside the cluster: adds operational burden, creates single points of failure, and doesn’t provide a global anycast IP or managed TLS. Exam tips: When you see “single global public IPv4,” “HTTPS,” and “Google-managed certificates” for GKE, the expected solution is Ingress with an external HTTP(S) Load Balancer and a reserved global static IP. Remember: ClusterIP is internal; NodePort is typically paired with Ingress; and avoid DIY load balancers for production-grade, autoscaled GKE services.
Möchtest du alle Fragen unterwegs üben?
Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.
You plan to migrate the following on-premises workloads to Google Cloud: • One Microsoft SQL Server Always On cluster supporting a 12 TB transactional database for a global user base with peak 45,000 writes/second • Apache Pulsar handling ~1.5 million messages per minute for event streaming and fan-out • A self-managed PostgreSQL instance used exclusively for BI dashboards and ad-hoc analytics (7 years of data, ~40 TB compressed) You must adopt Google-recommended, fully managed services that minimize operational overhead, provide global scalability, and offer built-in high availability with cross-region consistency targets (RPO≈0, ≥99.99% availability). What should you do?
Cloud SQL for SQL Server reduces ops, but it is primarily regional and typically relies on HA within a region plus cross-region DR (read replicas/backup/restore) rather than globally distributed strong consistency with near-zero RPO. Pub/Sub and BigQuery are correct choices for streaming and analytics, but the transactional database requirements (global scale, very high writes, cross-region consistency, ≥99.99%) push you toward Spanner instead of Cloud SQL.
Spanner + Pub/Sub + BigQuery best matches the stated requirements. Spanner is Google’s managed, horizontally scalable, strongly consistent, multi-region relational database designed for global OLTP and high availability. Pub/Sub is the managed service for high-throughput event ingestion and fan-out, replacing Pulsar without broker management. BigQuery is the managed analytics warehouse suited for large historical datasets and ad-hoc BI queries, minimizing operational overhead.
Spanner is appropriate for the global transactional database, but Memorystore is not a replacement for Pulsar. Memorystore (Redis/Memcached) is an in-memory cache with optional replication, not a durable streaming platform with subscriptions, retention, and fan-out semantics. Also, moving a 40 TB analytics workload into Cloud SQL would increase operational burden and likely underperform/cost more for ad-hoc analytics compared to BigQuery’s columnar, serverless warehouse model.
This option mismaps two workloads. Memorystore cannot replace Pulsar’s durable event streaming and fan-out. Cloud SQL for both SQL Server and PostgreSQL is managed, but it does not inherently deliver the global, strongly consistent, multi-region availability and near-zero RPO implied by the requirements for the transactional system. Additionally, using Cloud SQL for large-scale analytics (40 TB, ad-hoc queries) is typically inferior to BigQuery in scalability and operational simplicity.
Core Concept: This question tests choosing Google-recommended fully managed data services that meet extreme scale plus multi-region high availability and near-zero RPO. The key distinction is between regional managed databases (Cloud SQL) versus globally distributed, strongly consistent databases (Cloud Spanner), and between streaming/event fan-out (Pub/Sub) versus caching (Memorystore) and analytics warehousing (BigQuery). Why the Answer is Correct: For the 12 TB global transactional system with very high write throughput and cross-region consistency targets (RPO≈0, ≥99.99%), Cloud Spanner is the managed service designed for horizontal scaling, multi-region deployments, and strong consistency with high availability SLAs when configured appropriately (multi-region instance configuration). Cloud SQL for SQL Server is managed but is primarily regional with read replicas/DR patterns; it does not natively provide the same global, strongly consistent, multi-region active-active characteristics implied by the requirements. For Apache Pulsar’s ~1.5M messages/min with fan-out, Pub/Sub is Google’s fully managed global messaging service supporting high throughput, at-least-once delivery, ordering (when needed), and cross-region durability without running brokers. For the 40 TB compressed PostgreSQL used for BI/ad-hoc analytics, BigQuery is the recommended fully managed analytics warehouse: columnar storage, separation of compute/storage, built-in high availability, and native BI integrations. It avoids operational overhead of tuning/partitioning/vacuuming a large Postgres instance for analytics. Key Features / Configurations: Cloud Spanner: choose a multi-region instance configuration, size nodes/processing units for write throughput, design schema for distributed writes (avoid hot-spotting), and use Spanner’s strong consistency and automatic replication. Pub/Sub: use topics/subscriptions for fan-out, consider ordering keys only if required, and tune ack deadlines/flow control. BigQuery: partition/cluster tables for 7 years of data, use BI Engine if needed for dashboard acceleration, and control costs with reservations or autoscaling. Common Misconceptions: Cloud SQL is “fully managed,” but it is not the best fit for globally consistent, ultra-high write workloads with 99.99%+ multi-region expectations. Memorystore is often confused with streaming; it is an in-memory cache, not a durable event bus. Exam Tips: Map workload type to service: global OLTP with strong consistency → Spanner; event streaming/fan-out → Pub/Sub; large-scale analytics/BI → BigQuery. Watch for keywords like “global,” “RPO≈0,” and “≥99.99%” which usually imply multi-region native services rather than regional HA plus DR.
During a quarterly compliance audit at a fintech company, you must determine exactly which principals can currently view customer data stored in the Google Cloud project pay-ops-prod. The data resides in 9 Cloud Storage buckets and 15 BigQuery datasets, with access assigned via predefined and custom IAM roles at the project, bucket, and dataset levels; you need an action that identifies who has read/view permissions now without scanning data contents or relying on historical access logs—what should you do?
Data Access audit logs are for recording actual reads of data (e.g., object reads, BigQuery table reads) after logging is enabled. They do not directly enumerate who currently has permission, and they won’t help if you need an entitlement snapshot without relying on historical access. Also, if logs weren’t enabled previously, you cannot reconstruct past access from them.
Correct. Reviewing IAM policy bindings at the project, bucket, and dataset levels and mapping roles (predefined and custom) to read/view permissions is the right way to determine current effective access. This approach identifies principals who are authorized now, without scanning data contents or depending on audit history. It also supports analyzing inherited permissions and broad roles that include read access.
Identity-Aware Proxy protects access to web applications and services exposed through supported HTTPS entry points, not direct data-plane authorization for Cloud Storage buckets or BigQuery datasets. Cloud Storage and BigQuery access is determined by IAM, and for Cloud Storage potentially also by legacy ACLs when uniform bucket-level access is disabled. Reviewing IAP settings would therefore not provide an authoritative list of principals who can read objects or view/query dataset contents. It addresses a different control plane and would miss the actual permissions relevant to this audit.
Cloud DLP is designed to discover and classify sensitive data by scanning content (or sampling) and producing findings about data types and risk. It does not generate an authoritative report of which principals have access. Additionally, the question explicitly forbids scanning data contents, which is central to DLP’s purpose.
Core Concept: This question tests authorization analysis in Google Cloud: determining which principals currently have effective read access to Cloud Storage buckets and BigQuery datasets by evaluating access policies and the permissions included in granted roles. It is about identifying who can access the data now, not who accessed it historically, and not about inspecting the data itself. Why the Answer is Correct: To determine exactly which principals can currently view customer data, you must inspect the current access configuration at every relevant scope and map granted roles to the underlying read permissions. For BigQuery, that means reviewing IAM bindings at the project and dataset levels and checking whether predefined or custom roles include permissions such as bigquery.tables.getData or related metadata/view permissions. For Cloud Storage, that means reviewing project- and bucket-level IAM bindings and, if uniform bucket-level access is not enabled, also checking bucket and object ACLs because they can independently grant read access. This produces a present-time entitlement view without relying on historical logs or scanning data contents. Key Features / Best Practices: Use IAM policy inspection through the Console, gcloud, or APIs for the project and each bucket and dataset. Expand custom roles to verify whether they include read/view permissions, and account for inherited access from broader project-level roles. For Cloud Storage, verify whether uniform bucket-level access is enabled; if it is not, include legacy ACLs in the review because IAM alone would not show all effective readers. Also consider group membership and special principals such as allUsers or allAuthenticatedUsers when calculating effective access. Common Misconceptions: Audit logs show who actually accessed data after logging was enabled, not everyone who is authorized right now. Cloud DLP classifies and inspects data content rather than reporting entitlements. IAP is unrelated to direct authorization for Cloud Storage buckets and BigQuery datasets. Exam Tips: When a question asks 'who can access now,' think current IAM policies, resource-level grants, custom-role permission expansion, and any service-specific access mechanisms such as Cloud Storage ACLs when UBLA is disabled. When it asks 'who accessed,' think audit logs. Always distinguish entitlement analysis from activity analysis.
Your security team needs to grant SSH access to a single VM named edge-proxy-01 in project film-prod-2468 (zone europe-west1-b) only for members of the Google Group qa1 (8 users), ensuring they cannot access any other VM in the project and preferring a Google-recommended, centrally managed approach that works from Cloud Shell without distributing private keys; what should you do?
Correct. Enabling `enable-oslogin=true` on edge-proxy-01 switches SSH authorization to OS Login for that VM. Granting the qa1 Google Group `compute.osLogin` scoped to the instance allows only those users to SSH to that specific VM and nowhere else in the project. Using Cloud Shell with `gcloud compute ssh` works without distributing private keys because access is tied to Google identity and IAM.
Incorrect. OS Login enablement is good, but changing the VM’s service account to “No service account” is unrelated to user SSH access. Service accounts control what the VM can access (outbound API calls), not who can SSH in. Also, this option does not explicitly grant the qa1 group OS Login permissions scoped to the instance, so it fails the access-control requirement.
Incorrect. Blocking project-wide SSH keys can help limit inherited metadata keys, but generating and distributing unique SSH keys to each user violates the requirement to avoid private key distribution and is not the Google-recommended centrally managed approach. It also increases operational burden (rotation, revocation, auditing) compared to OS Login with IAM and Google Groups.
Incorrect and insecure. Sharing a single private key among multiple users breaks accountability and non-repudiation, making it impossible to attribute actions to individual users. It also violates best practices for key management and the requirement to avoid distributing private keys. Even with project-wide keys blocked, this approach is not centrally managed via IAM and is operationally risky.
Core Concept: This question tests OS Login and IAM-based SSH access control in Compute Engine. OS Login is Google’s recommended approach to centrally manage Linux SSH access using IAM identities (including Google Groups) rather than distributing and managing SSH keys via instance/project metadata. Why the Answer is Correct: Option A enables OS Login on only the target VM (edge-proxy-01) and grants the qa1 Google Group the appropriate OS Login IAM role scoped to that single instance. This ensures members can SSH to that VM and not to other VMs in the project, because they lack OS Login permissions elsewhere. It also satisfies the requirement to work from Cloud Shell without distributing private keys: users can run `gcloud compute ssh`, which uses their Google identity and OS Login to provision ephemeral SSH credentials. Key Features / Best Practices: - Instance-level metadata `enable-oslogin=true` limits the behavior to one VM, aligning with least privilege. - IAM binding at the instance resource (not project) restricts access to only that VM. - Google Groups can be used directly in IAM policies, simplifying management for 8 users. - Cloud Shell + `gcloud compute ssh` integrates cleanly with OS Login and avoids manual key distribution. - This aligns with Google Cloud Architecture Framework security principles: centralized identity, least privilege, and auditable access (Cloud Audit Logs for IAM changes and OS Login activity). Common Misconceptions: Many assume “Block project-wide SSH keys” is the best security control. While it can reduce key sprawl, it still relies on key generation/distribution and does not provide the same centralized, IAM-driven access model as OS Login. Another misconception is that removing a VM service account affects SSH access; it does not. Exam Tips: - For “centrally managed SSH” and “no private key distribution,” think OS Login. - To restrict SSH to a single VM, scope IAM bindings to the instance, not the project. - Remember role selection: `compute.osLogin` is for standard SSH; `compute.osAdminLogin` is for sudo/admin access. Choose the least-privileged role that meets the requirement.
In your company’s Google Cloud organization, the qa-analytics-123 project contains 12 custom IAM roles that you must replicate exactly (same role IDs, titles, and permissions) to a new staging project stg-analytics-123 in the same organization, and you want to accomplish this in the fewest possible steps without promoting the roles to the organization level or manually re-selecting permissions; what should you do?
Correct. gcloud iam roles copy is intended to duplicate a custom role definition from one parent (project) to another. It preserves the permissions and metadata, and you can keep the destination at the project level (stg-analytics-123) to meet the requirement of not promoting roles to the organization. It also avoids manually re-selecting permissions, minimizing errors and steps.
Incorrect. Copying roles to the organization would change the scope from project-level to org-level, making the roles available to all projects. The question explicitly says not to promote the roles to the organization level. While org-level roles can be useful for standardization, it violates the stated constraint and is not the most appropriate action here.
Incorrect. The Google Cloud Console does not reliably provide a simple “clone/copy role from another project with the same role ID” workflow that meets the “replicate exactly” and “fewest steps” requirements. Even if you can base a role on an existing one, you typically still end up editing and saving per role, and exact ID preservation across projects is not the primary console path.
Incorrect. Manually creating 12 roles and re-selecting permissions is time-consuming and error-prone, and it directly contradicts the requirement to avoid manual permission selection. This approach increases the risk of configuration drift between QA and staging, and it is not aligned with best practices for repeatable IAM configuration.
Core concept: This question tests IAM custom role management and portability. Custom roles are scoped either to a project or an organization. Project-level custom roles live under projects/PROJECT_ID/roles/ROLE_ID and are not automatically available in other projects. To replicate roles “exactly” (same role IDs, titles, permissions) into another project with minimal effort, you should use the gcloud CLI role copy capability. Why the answer is correct: Option A uses gcloud iam roles copy to copy each custom role definition from qa-analytics-123 to stg-analytics-123. This is the fewest-step approach that preserves the role definition without manually reselecting permissions. It also keeps the roles at the project scope, satisfying the requirement to not promote them to the organization level. The copy operation is designed for this use case: duplicating an existing custom role into a different parent resource (another project). Key features / best practices: - Custom roles are resources with metadata (roleId, title, description, stage) and a permissions list. Copying avoids human error and ensures parity between environments (QA vs staging). - You must have appropriate permissions such as iam.roles.get on the source and iam.roles.create (and potentially iam.roles.update) on the destination project. - Role IDs must be unique within the destination project. Copying “exactly” implies the destination project does not already have roles with the same IDs. - From an Architecture Framework perspective (Security, Reliability, Operational Excellence), using automation/CLI reduces drift and improves repeatability across environments. Common misconceptions: Some assume roles must be elevated to the organization to share across projects (option B). That’s unnecessary and violates the requirement. Others look for a Console “clone role” workflow (option C), but the Console typically requires creating/editing roles and may not provide a true bulk/clone-from-project feature that preserves IDs without manual steps. Exam tips: - Remember the scope boundary: project custom roles are not reusable across projects unless copied or recreated. - Prefer gcloud/automation for repeatable IAM configuration and to avoid permission-selection mistakes. - If a question says “fewest steps” and “replicate exactly,” look for a direct copy/export-import mechanism rather than manual recreation.
Your team is deploying a real-time telemetry aggregator on Cloud Run in us-central1 that must process events from a Pub/Sub topic named iot-telemetry within 2 seconds of publish, handle bursty loads up to 25,000 messages per minute with at-least-once delivery, and require authenticated requests using your own service account while keeping minimum instances at 0; to follow Google-recommended practices, what should you do?
This works functionally but is not Google-recommended when Pub/Sub can push directly to Cloud Run. It introduces an extra hop (Pub/Sub -> Cloud Functions -> Cloud Run), increasing latency risk against the 2-second requirement and adding cost and operational complexity. It also creates another component to scale and secure, and can become a bottleneck during bursts if the function invocation or outbound HTTP calls throttle.
A pull subscription requires the Cloud Run service to actively poll Pub/Sub. That usually implies a continuously running worker or scheduled polling, which conflicts with keeping minimum instances at 0 and can increase end-to-end latency. While it can be made to work, it is not the recommended serverless pattern for Cloud Run event ingestion from Pub/Sub, especially for near-real-time delivery.
This is the recommended pattern: Pub/Sub push subscription delivers messages to Cloud Run over HTTPS, and OIDC authentication uses a dedicated service account. Granting Cloud Run Invoker to that service account ensures only Pub/Sub (using that identity) can invoke the service. It supports scale-to-zero, low latency, and burst handling via Cloud Run autoscaling and Pub/Sub retries (at-least-once).
Running Cloud Run for GKE plus a sidecar relay is unnecessary complexity for this requirement and not aligned with managed serverless best practices. It adds cluster management overhead, networking considerations, and additional components that can fail. It also undermines the simplicity and cost model of Cloud Run fully managed, and is unlikely to be the intended Associate-level solution.
Core concept: This question tests the recommended integration pattern between Pub/Sub and Cloud Run, specifically push delivery to an HTTPS endpoint with authenticated invocation using OIDC, while preserving Cloud Run’s scale-to-zero behavior and meeting low-latency, bursty throughput requirements. Why the answer is correct: Option C uses a Pub/Sub push subscription that delivers messages directly to the Cloud Run service’s HTTPS endpoint. Pub/Sub push is event-driven (no polling), which helps meet the “within 2 seconds of publish” requirement and supports bursty loads (25,000 messages/min) by letting Pub/Sub fan out deliveries while Cloud Run autoscaling adds instances as needed. At-least-once delivery is inherent to Pub/Sub; Cloud Run must be idempotent and return 2xx only after successful processing to avoid redelivery. The requirement “authenticated requests using your own service account” is met by configuring the push subscription to attach an OIDC token minted for a dedicated service account, and granting that service account the Cloud Run Invoker role on the service. This is the Google-recommended practice for securing Cloud Run endpoints invoked by Pub/Sub. Key features and configurations: - Pub/Sub push subscription to Cloud Run HTTPS URL in the same region (us-central1) to reduce latency. - OIDC token authentication: configure the push subscription with a service account; Cloud Run validates IAM via Cloud Run Invoker. - Keep min instances at 0: push delivery works with scale-to-zero; polling patterns often require always-on compute. - Throughput controls: tune Cloud Run concurrency and max instances; consider Pub/Sub ack deadline and retry/backoff behavior. Common misconceptions: - Using Cloud Functions as a relay (Option A) adds an unnecessary hop, extra cost, and additional failure modes; it’s not the recommended architecture when Pub/Sub can push directly to Cloud Run. - Pull subscriptions (Option B) seem straightforward but require a polling worker, which conflicts with scale-to-zero and can increase latency. - Complex GKE-based relays (Option D) are over-engineered for an Associate-level scenario and undermine Cloud Run’s managed simplicity. Exam tips: When you see “Pub/Sub to Cloud Run” plus “authenticated requests” and “min instances 0,” think: Pub/Sub push subscription + OIDC token + Cloud Run Invoker on a dedicated service account. Also remember Pub/Sub is at-least-once, so design idempotent handlers and only return 2xx on success.
Möchtest du alle Fragen unterwegs üben?
Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.
Your organization runs a low-latency telemetry collector on Google Kubernetes Engine (GKE) in us-central1 with cluster autoscaling enabled. The application listens on TCP port 7000 and has 5 replicas. A separate Compute Engine VM named parser-1 runs in the same region but in a different VPC named analytics-vpc (CIDR 10.20.0.0/16) than the GKE cluster's VPC named stream-vpc (CIDR 10.10.0.0/16). There is no VPC peering or Cloud VPN between the networks, and the IP ranges do not overlap. The VM must initiate TCP connections to the collector service. You want the simplest solution with the least operational effort. What should you do?
Correct. A Service of type LoadBalancer exposes the collector on a managed external TCP load balancer with a stable public IP. Since there is no peering/VPN between the VPCs, parser-1 can still initiate outbound TCP connections to the external IP on port 7000. externalTrafficPolicy=Cluster improves availability because any node can receive traffic and forward to ready pods even as replicas move during autoscaling.
Incorrect. A dual-NIC proxy VM with iptables forwarding is complex and high-ops: you must manage routing, firewall rules, NAT/forwarding, health, scaling, and patching of the proxy. It also introduces a single point of failure unless you build HA. This is not the simplest solution and is generally an anti-pattern compared to managed load balancing or managed private connectivity options.
Incorrect for “least operational effort.” An internal load balancer would be reachable only over private connectivity. Creating VPC peering adds setup and ongoing network management (routes, IAM permissions, potential DNS considerations). While it can be a good private design, it is not the simplest given the requirement and the absence of existing connectivity.
Incorrect. While restricting sources is a good security idea, Cloud Armor is not the straightforward control for a TCP Network Load Balancer created by a GKE Service type LoadBalancer. Cloud Armor is primarily used with HTTP(S) load balancing and certain proxy LBs. For TCP NLB, you typically rely on VPC firewall rules and other controls; this option is misleading and not the simplest correct approach.
Core concept: This question tests GKE Service exposure patterns across networks without private connectivity. With no VPC peering/VPN/Interconnect between stream-vpc and analytics-vpc, the VM cannot reach any private (RFC1918) IPs in the GKE VPC. Therefore, the collector must be exposed via a reachable endpoint, most simply a public external load balancer IP. Why the answer is correct: Option A uses a GKE Service of type LoadBalancer, which provisions a Google Cloud external TCP/UDP Network Load Balancer (for a TCP service like port 7000). The VM in analytics-vpc can initiate outbound connections to the Service’s external IP over the internet (or Google’s edge) without any network-to-network plumbing. This is the least operational effort: no peering, no routing changes, no proxy VM, and it works with cluster autoscaling because the Service continuously tracks healthy backends (nodes/pods via kube-proxy/health checks). Key features and best practices: - Service type LoadBalancer provides a stable VIP and managed load balancing. - externalTrafficPolicy=Cluster allows any node to accept traffic and forward to ready pods across the cluster, improving resilience when pods move due to autoscaling/updates. - You still should restrict access using VPC firewall rules on the nodes (for the LB health checks and traffic) and/or Kubernetes NetworkPolicy if applicable; but the core connectivity requirement is met with minimal setup. Common misconceptions: - “Internal” load balancers (Option C) are not reachable across isolated VPCs; they require private connectivity such as VPC peering/VPN. - Cloud Armor (Option D) is commonly assumed to protect any load balancer, but Cloud Armor is primarily for HTTP(S) Load Balancing and some proxy-based LBs; it is not the right/simple control for a basic TCP Network Load Balancer created by a GKE Service. - Building a transit proxy (Option B) can work but adds operational burden and is generally discouraged versus managed connectivity. Exam tips: When two VPCs have no peering/VPN and IP ranges don’t overlap, assume only public endpoints are reachable. For GKE, the simplest cross-network access is usually Service type LoadBalancer with an external IP. Use internal load balancers only when private connectivity exists. Also remember that autoscaling favors solutions that don’t depend on fixed node IPs or manual backend management.
Your team runs a video-recommendation API on a managed instance group behind an HTTP(S) load balancer, with autoscaling configured to add instances when average CPU utilization exceeds 75% and to stop scaling out when CPU drops to 75% or the group reaches a maximum of 6 VMs; HTTP health checks use an initial delay of 20 seconds, but each VM takes about 2 minutes and 40 seconds to finish startup scripts and accept requests, and during traffic spikes you notice the group repeatedly adds more instances than necessary because new VMs are not yet serving traffic and CPU on existing VMs stays high. You want to keep the instance group size appropriate during autoscaling while maintaining the same performance targets. What should you do?
Setting the maximum number of instances to 1 effectively disables horizontal scaling for the managed instance group. That directly conflicts with the requirement to maintain the same performance targets during traffic spikes, because the service would no longer be able to add capacity as load increases. It treats the symptom by preventing growth rather than fixing the timing problem that causes unnecessary scale-out. This would likely increase latency and errors under peak demand.
Reducing the maximum number of instances to 3 is just a smaller cap and does not address why the autoscaler keeps adding instances in the first place. If startup time remains long, existing VMs can still stay above the CPU threshold while new VMs are not yet helping, so the group may still scale inefficiently until it hits the lower cap. That creates a risk of underprovisioning during legitimate spikes. Capacity limits are not the right fix when the root cause is delayed readiness.
A TCP health check only verifies that the instance is accepting connections on a port, not that the HTTP application is fully initialized and able to serve requests correctly. For a web API behind an HTTP(S) load balancer, HTTP health checks are more appropriate because they can validate application-level readiness. Switching to TCP could make instances appear healthy too early, causing traffic to be sent before the service is actually ready. It also does not directly solve the autoscaling timing issue caused by long startup time.
Increasing the delay to 180 seconds is the only option that aligns system timing with the VM's real startup duration of about 160 seconds. That reduces the mismatch between when instances are created and when they are actually ready to contribute capacity, which helps prevent repeated scale-out during traffic spikes. In exam terms, this is the closest available answer to configuring a proper warm-up or initialization period. It preserves the existing performance target while addressing the startup lag that causes overscaling.
Core concept: This question is about managed instance group (MIG) autoscaling behavior when instances take significant time to initialize before they can serve traffic. The key issue is that newly created VMs are not ready for about 2 minutes and 40 seconds, so the autoscaler should ignore their metrics during that warm-up period to avoid repeatedly scaling out based on CPU from only the already-serving instances. Why correct: The best choice among the options is to increase the delay to 180 seconds so the system better aligns with the actual startup time. This helps prevent newly created instances from being treated as available too early and reduces the chance that the autoscaler keeps adding more VMs while existing instances remain overloaded. Although in practice the autoscaler initialization period is the more precise setting for this behavior, this option is the closest match to the intended fix in the provided choices. Key features: - MIG autoscaling based on CPU can overreact if new instances are still starting up and not yet contributing capacity. - Startup scripts and application warm-up time must be accounted for when tuning scaling-related timing. - Health and readiness signals should reflect when an instance can actually serve production traffic. - Proper warm-up timing reduces oscillation and unnecessary scale-out events. Common misconceptions: - Simply lowering the maximum number of instances does not solve the root cause and can hurt performance during spikes. - TCP health checks are less suitable than HTTP checks for application readiness because they only confirm port reachability. - Health checks and autoscaler warm-up are related operationally, but they are not the same mechanism. Exam tips: On Google Cloud exam questions, when autoscaling adds too many instances during startup delays, look for settings related to initialization time, warm-up periods, or readiness. Prefer solutions that align scaling behavior with actual application readiness rather than artificially capping capacity.
You are launching a real-time logistics tracking service on Google Kubernetes Engine (GKE Autopilot) in us-central1 that requires MongoDB-specific document queries and replica set transactions. The database must be fully managed with 24/7 vendor support, a published 99.95% uptime SLA, automated backups with at least 7-day retention, and private connectivity (VPC peering) to your GKE workloads; it should handle approximately 2,000 reads per second and 500 writes per second without you managing virtual machines. You want to deploy this through a Google Cloud–integrated offering to simplify billing and support; what should you do?
Cloud Bigtable is a fully managed, highly scalable NoSQL database, but it is not MongoDB and does not provide MongoDB document query semantics, replica set behavior, or MongoDB multi-document transactions. Using the HBase API does not satisfy the requirement for MongoDB-specific features. While Bigtable can handle high throughput and offers strong availability characteristics, it fails the core compatibility requirement.
MongoDB Atlas from Google Cloud Marketplace is the best fit: it is a fully managed MongoDB service with MongoDB-native queries, replica sets, and transactions. It offers published SLAs (commonly 99.95% for production tiers), automated backups with configurable retention, and optional 24/7 support. It supports private connectivity to your VPC via VPC peering, and Marketplace procurement simplifies billing and vendor engagement.
Running MongoDB on standalone Compute Engine VMs is self-managed: you must handle OS and MongoDB patching, backups, monitoring, scaling, and failover/replica set operations. It does not meet the requirement of “fully managed with 24/7 vendor support and a published 99.95% uptime SLA” in the managed-service sense, and it contradicts the desire to avoid managing virtual machines.
A Managed Instance Group improves VM availability and scaling for stateless workloads, but MongoDB is stateful and requires careful replica set configuration, persistent disks, backups, and coordinated failover. You still manage VMs and the database lifecycle, which violates the requirement for a fully managed database with vendor SLA/support and automated backups. MIGs are not a substitute for a managed database service.
Core Concept: This question tests choosing a managed database that matches a specific API/workload requirement (MongoDB document queries and replica set transactions) while meeting operational requirements (SLA, backups, support) and integrating with Google Cloud for networking and billing. It also implicitly tests understanding GKE Autopilot constraints: you should avoid self-managed stateful databases on VMs when a managed service exists. Why the Answer is Correct: MongoDB Atlas on Google Cloud Marketplace is the Google Cloud–integrated, fully managed MongoDB service designed for MongoDB-specific features (document model, query language, indexes, replica sets, multi-document transactions). Atlas provides published SLAs (including 99.95% for many production tiers), automated backups with configurable retention (>=7 days), and 24/7 vendor support options. It supports private connectivity to your VPC via VPC peering/PrivateLink-style connectivity (Atlas VPC peering on GCP), allowing your GKE Autopilot workloads in us-central1 to access the database privately without public IP exposure. It also satisfies the “no VM management” requirement and simplifies procurement through Marketplace (consolidated billing and streamlined support engagement). Key Features / Configurations: - Deploy Atlas in the same region (us-central1) to reduce latency and egress. - Configure Atlas cluster tier sized for ~2,000 reads/s and 500 writes/s and enable replica set/high availability. - Enable automated backups with at least 7-day retention and verify point-in-time restore requirements. - Set up Atlas VPC peering to the GKE VPC, and restrict access via IP access lists / network policies. - Align with Google Cloud Architecture Framework: reliability (SLA, multi-zone), security (private connectivity, least privilege), and operational excellence (managed backups/patching). Common Misconceptions: A common trap is choosing Bigtable because it is highly scalable and managed, but it is not MongoDB and does not support MongoDB query semantics or replica set transactions. Another trap is running MongoDB on Compute Engine/MIG to “control everything,” but that violates the requirement for a fully managed service with vendor SLA/support and increases operational burden (patching, backups, failover, upgrades). Exam Tips: When a question explicitly requires a specific database API/behavior (MongoDB queries, replica sets, transactions), prioritize a managed offering that natively provides it. For GKE Autopilot, prefer managed databases over self-hosted stateful systems. Also watch for keywords like “Marketplace,” “integrated billing,” “VPC peering,” “SLA,” and “no VM management”—these strongly indicate a partner-managed service such as MongoDB Atlas via Marketplace.
Your team operates a regional managed instance group of 12 Compute Engine VMs behind a global external HTTP(S) load balancer to serve a video-transcoding API that receives about 2,500 requests per minute, and you have a new application build that you want to roll out gradually during business hours while the service is handling live traffic; you must ensure that serving capacity does not decrease at any time during the rollout and downtime is not allowed—what should you do?
maxSurge=0 and maxUnavailable=1 allows the managed instance group to remove one existing VM before creating a replacement. That means the group can temporarily drop from 12 serving instances to 11, which is a direct reduction in available capacity during the rollout. Because the service is already handling live traffic, this violates the requirement that serving capacity must not decrease at any time. It also fails the zero-downtime intent because the update policy explicitly permits an unavailable instance during the rollout.
maxSurge=1 and maxUnavailable=0 is the correct rolling update policy when you must avoid any reduction in serving capacity. With this configuration, the managed instance group creates one additional VM above the target size before removing any existing VM, so capacity temporarily increases from 12 to 13 during each step. The new instance is allowed to initialize and pass health checks before the old instance is deleted, which is essential when the MIG is behind an external HTTP(S) load balancer. This gives you a controlled, gradual rollout during live traffic while maintaining zero unavailable instances throughout the update.
Creating a second managed instance group with 12 updated instances and attaching it to the same backend service can provide zero downtime, but it does not inherently perform a gradual rollout. Once the new backend becomes healthy, the load balancer may begin distributing traffic across both groups according to balancing behavior rather than a controlled step-by-step instance replacement policy. It also doubles capacity and operational complexity, whereas a MIG rolling update with surge directly supports gradual in-place rollout while guaranteeing no reduction in serving capacity. For this exam scenario, the built-in rolling update mechanism is the more precise and appropriate solution.
Simply updating the instance template on the managed instance group does not change existing VMs; only newly created instances use the new template. If you then manually delete the current instances, the group recreates them, but without a defined rolling update policy you do not control how many instances can become unavailable at once. That can reduce serving capacity and create disruption while the replacements boot and pass health checks. This approach therefore does not guarantee a gradual rollout or preservation of capacity during business hours.
Core Concept: This question tests Compute Engine Managed Instance Group (MIG) rolling updates and how to perform a zero-downtime deployment behind an HTTP(S) load balancer. The key controls are the rolling update policy parameters maxSurge and maxUnavailable, which determine whether capacity can temporarily increase and whether any instances may be taken out of service during the update. Why the Answer is Correct: To guarantee that serving capacity does not decrease at any time and that downtime is not allowed, you must ensure that zero instances are unavailable during the rollout. Setting maxUnavailable=0 enforces that the MIG will not proactively take any instance out of service until replacement capacity is ready. However, if you also set maxSurge=0, the group cannot create extra instances to replace old ones first; it would be forced to remove an instance to make room, which violates the “no capacity decrease” requirement. Therefore, the correct approach is a rolling update with maxSurge=1 and maxUnavailable=0, which temporarily increases the group size (e.g., from 12 to 13) to bring up a new VM, wait for it to become healthy (including load balancer health checks), and only then delete one old VM. Key Features / Best Practices: - MIG rolling updates support gradual rollout during business hours by controlling update rate and disruption. - maxSurge provides temporary extra capacity; maxUnavailable controls allowed reduction in serving instances. - With a global external HTTP(S) load balancer, only healthy instances receive traffic; ensure health checks and readiness are correct so new VMs aren’t marked healthy prematurely. - Consider quotas (regional instance quota, CPU quota) because surge requires additional VM capacity during the update. Common Misconceptions: - “Rolling update” alone does not guarantee no capacity loss; the policy values matter. - Blue/green with a second MIG can work but is heavier operationally and not required when a surge-based rolling update meets the requirement. Exam Tips: When you see “no downtime” and “capacity must not decrease,” look for maxUnavailable=0 and a positive maxSurge. If the question emphasizes simplicity and using built-in features, prefer MIG rolling updates over building a parallel stack unless explicitly required.
Your media company plans to migrate an internal video review tool currently running on two Ubuntu VMs (each 4 vCPU, 16 GB RAM, 200 GB SSD) and a standalone MySQL 8 server (4 vCPU, 26 GB RAM, 1 TB SSD) to Google Cloud within the next quarter; the target design uses Compute Engine for the app VMs and Cloud SQL for MySQL with high availability, automated daily backups, and 7-day point-in-time recovery, and you must produce a 12-month cost estimate within an hour without provisioning any resources, capturing costs for VM instances, persistent disks, Cloud SQL (including HA and backups), and intra-region network egress. What should you do?
Exporting SKUs to a spreadsheet can theoretically produce an estimate, but it’s not the recommended or fastest approach for an exam scenario with a one-hour deadline. It’s easy to miss components (e.g., Cloud SQL HA doubling compute, backup storage, PITR/binary log storage, disk pricing differences by region). It also increases risk of formula errors and outdated pricing, making it less suitable than the Pricing Calculator.
A prebuilt “Web Application” template is typically traffic/requests-based and may not accurately reflect a lift-and-shift style sizing based on existing VM specs and a specifically configured Cloud SQL HA + backups + 7-day PITR requirement. Templates can be helpful for rough sizing, but this question requires explicit capture of VM instance types, disk sizes, HA configuration, and backup/PITR costs, which is better handled with custom line items.
Creating a pilot and extrapolating from Billing reports requires provisioning resources, which the question explicitly forbids. Even if allowed, a 30-minute load test at 25% traffic is not a reliable basis for annualized costs because it may not represent steady-state utilization, storage growth, backup retention, or HA standby costs. This approach is slower, operationally heavier, and less aligned with quick planning requirements.
This is the correct approach: use the Google Cloud Pricing Calculator and add Compute Engine and Cloud SQL items that match the target design and current sizing assumptions. You can specify region, machine types, SSD persistent disks, Cloud SQL for MySQL with HA (regional), storage size, and include backup/PITR-related storage assumptions. The calculator provides monthly and 12-month subtotals and supports adding network egress estimates, meeting all constraints.
Core Concept: This question tests cost estimation and solution planning using the Google Cloud Pricing Calculator, specifically for Compute Engine, Persistent Disk, and Cloud SQL for MySQL with high availability (HA), backups, and point-in-time recovery (PITR). It also checks that you can produce an estimate quickly without deploying resources. Why the Answer is Correct: Option D is correct because the Pricing Calculator is the intended tool to generate a fast, defensible 12-month estimate without provisioning anything. You can add separate line items for the two application VMs (Compute Engine instances) and their SSD persistent disks, then add a Cloud SQL for MySQL instance configured for HA (regional), storage size, and backup/PITR settings. The calculator provides monthly and 12‑month subtotals and allows region selection, which is essential because pricing varies by region. It also supports adding estimated network egress (including intra-region where applicable) as part of the estimate. Key Features / Best Practices: Compute Engine costs are driven by machine type (vCPU/RAM), hours, and disk type/size (SSD PD). Cloud SQL costs include instance (vCPU/RAM), storage, and HA (regional) which effectively provisions a primary and standby in different zones. Automated daily backups and PITR (binary logging) can increase storage consumption and cost; the calculator lets you model backup storage and retention assumptions. For networking, intra-region egress can still be billable depending on traffic path (e.g., cross-zone or certain service-to-service patterns), so including it explicitly in the estimate aligns with good planning practices from the Google Cloud Architecture Framework (cost optimization and reliability). Common Misconceptions: People often think exporting SKUs (Option A) is faster, but it’s error-prone and time-consuming to maintain, and it’s easy to miss HA, backup, or PITR-related cost components. Others assume templates (Option B) will capture everything, but templates are traffic-driven and may not map cleanly to fixed VM specs and Cloud SQL HA/PITR requirements. Running a pilot (Option C) violates the constraint of “without provisioning any resources” and won’t reliably capture steady-state costs in 30 minutes. Exam Tips: When the question demands a quick estimate with no deployment, choose the Pricing Calculator with explicit line items matching the target architecture. Watch for requirements like HA, backups, PITR, disk types/sizes, and region selection—these are common exam cues that you must model specific configuration-driven costs rather than rely on generic templates or empirical billing data.
Möchtest du alle Fragen unterwegs üben?
Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.
Your compliance team has contracted an external penetration tester to review all resources in the Google Cloud project proj-audit-789 for 7 days and must ensure they cannot modify anything. Your organization has the Organization Policy constraint Domain Restricted Sharing configured at the organization node to allow only accounts in the corp.example.com Cloud Identity domain. How do you provide the tester with read-only visibility to that project without violating the policy?
Incorrect. A personal Google Account (often gmail.com) is outside the allowed corp.example.com domain. With Domain Restricted Sharing enabled at the organization level, you will be prevented from adding that principal to the project IAM policy, even with a read-only role like Viewer. The role choice is irrelevant because the policy blocks the identity itself.
Incorrect. Although roles/iam.securityReviewer is a read-only role, it does not bypass Domain Restricted Sharing. If the tester’s Google Account is not in corp.example.com, you cannot grant it any IAM binding on the project. Additionally, Security Reviewer is more limited than Viewer and may not provide the broad resource visibility implied by “review all resources.”
Correct. Creating a temporary Cloud Identity user in the approved corp.example.com domain complies with Domain Restricted Sharing. Granting roles/viewer provides broad read-only access across many Google Cloud services, aligning with the requirement that the tester must not be able to modify resources while still being able to inspect configurations and assets during the 7-day engagement.
Partially aligned but not the best answer. A temporary corp.example.com user would satisfy Domain Restricted Sharing, but roles/iam.securityReviewer is narrower and focused on IAM/security posture visibility. The question states the tester must “review all resources,” which typically requires broader read-only access than Security Reviewer provides. Viewer is the more appropriate read-only role for comprehensive project visibility.
Core concept: This question tests IAM identity types and Organization Policy constraints—specifically Domain Restricted Sharing (DRS). DRS restricts which principals can be granted IAM access based on their domain, typically allowing only users/groups/service accounts from approved Cloud Identity/Google Workspace domains. Why the answer is correct: Because DRS is configured at the organization node to allow only accounts in corp.example.com, you cannot grant project-level IAM roles to an external tester’s personal Google Account (gmail.com) or any account outside the allowed domain. To provide access without violating policy, you must use an identity that belongs to corp.example.com. Creating a temporary Cloud Identity user in corp.example.com for the tester satisfies the DRS constraint. Then granting the Viewer role (roles/viewer) on proj-audit-789 provides broad read-only visibility across most Google Cloud resources, meeting the requirement that they “cannot modify anything,” while still allowing them to inspect configurations. Key features / best practices: - Domain Restricted Sharing is enforced at IAM policy binding time; disallowed principals cannot be added even if you are an owner. - Use least privilege and time-bound access: create a temporary user, grant only required roles, and remove access after 7 days. In practice, you can also use an access approval/workflow and audit logs to track activity. - Viewer is a general read-only role across many services; it’s commonly used for auditors/assessors who need visibility but no write permissions. Common misconceptions: - “Security Reviewer is read-only so it’s better.” It is read-only, but it is narrower (security/IAM-focused) and may not provide visibility to all resources a penetration tester needs to review. - “Using their Google Account is fine if it’s read-only.” DRS blocks the principal regardless of role; the domain restriction is about who can be granted access, not what permissions they get. Exam tips: When you see Domain Restricted Sharing, first determine whether the principal’s domain is allowed. If not, the only compliant options are to use an identity in an allowed domain (temporary Cloud Identity user, group membership in that domain, or an allowed service account where appropriate). Then choose the least-privilege role that still meets the stated visibility requirements—Viewer for broad read-only, Security Reviewer for security posture review only.
In Cloud Shell, your default project is dev-sbx-1234 and your organization has about 200 projects; without changing the default configuration, you must use gcloud to output only the currently enabled Google Cloud APIs for the production project whose display name is "orion-billing-prod"—what should you do?
Correct. You must identify the project ID for the project whose display name is "orion-billing-prod" because gcloud services operations are scoped to a project ID/number. Then gcloud services list --project <PROJECT_ID> lists only the currently enabled APIs for that project. This approach does not change the active configuration in Cloud Shell and is the standard, safe way to target a different project for a single command.
Incorrect. gcloud init is an interactive workflow that typically updates your active configuration (including the default project), which violates the requirement to not change the default configuration. Additionally, gcloud services list --available lists services that are available to enable, not the services currently enabled in the project, so it does not meet the “currently enabled APIs” requirement.
Incorrect. gcloud info shows environment and active account details, but enabled APIs are a project-level setting, not an account-level setting. Also, gcloud services list does not use an --account flag to determine which project’s enabled services to list; it uses the active project or --project. This option misunderstands the resource hierarchy and scoping model.
Incorrect. gcloud projects describe <PROJECT_ID> can verify a project once you already know the project ID, but it does not help you discover the correct project ID from a display name. More importantly, gcloud services list --available again lists APIs that could be enabled, not those currently enabled. This fails the main requirement even if the project were correctly identified.
Core Concept: This question tests gcloud CLI project scoping and the Service Usage API surface exposed via gcloud services. Specifically, it focuses on how to list only enabled APIs for a project that is not your current default project in Cloud Shell, without changing your active configuration. Why the Answer is Correct: In Cloud Shell, gcloud commands run against the active (default) project unless you explicitly override it. You are told not to change the default configuration, so you should not run commands that alter the active project (for example, gcloud init or gcloud config set project). The production project is identified by display name ("orion-billing-prod"), but gcloud services list requires a project identifier to scope the request. Therefore, the correct workflow is: (1) find the project ID (or project number) that corresponds to the display name using gcloud projects list (optionally filtered), then (2) run gcloud services list --project <PROJECT_ID> to list enabled services for that project. Key Features / Best Practices: - gcloud services list (without --available) lists enabled APIs/services for the target project. - Use --project to target a non-default project without modifying configuration, aligning with least surprise and operational safety. - With ~200 projects, you can filter: gcloud projects list --filter="name=orion-billing-prod" --format="value(projectId)" to quickly extract the ID. - This aligns with the Google Cloud Architecture Framework operational excellence principle: make safe, reversible changes and avoid unnecessary configuration drift in shared environments like Cloud Shell. Common Misconceptions: - Confusing --available with enabled services: --available shows services that could be enabled, not what is currently enabled. - Thinking account scoping affects enabled APIs: APIs are enabled per project, not per user account. - Using gcloud init: it changes configuration and is unnecessary for a one-off query. Exam Tips: - Memorize the pattern: “Need to act on a non-default project? Use --project.” - Remember: display name is not the same as project ID; many gcloud commands require project ID/number. - For API enablement questions, distinguish between listing enabled services (gcloud services list) vs listing available services (gcloud services list --available).
Your financial services platform stores monthly PDF statements in a Cloud Storage bucket with Object Versioning enabled, and to reduce costs you need a policy that transitions only noncurrent object versions after 30 days, while those previous versions are read once a month for compliance reports and are occasionally amended at month-end, so what should you configure?
Coldline is typically best for data accessed no more than once per quarter and has a 90-day minimum storage duration. Because the scenario states noncurrent versions are read once a month for compliance and sometimes accessed again at month-end, Coldline can lead to higher retrieval costs and potential early-deletion charges if versions are replaced or deleted before 90 days. It targets noncurrent versions correctly, but the storage class is a poorer fit.
Nearline is designed for infrequently accessed data that is typically read about once per month, matching the compliance reporting pattern. A lifecycle rule that transitions only noncurrent versions after 30 days reduces storage cost while keeping the current version in Standard for normal operations. Nearline’s 30-day minimum storage duration also aligns with the “after 30 days” requirement, making this the best overall cost/performance match.
This option changes all objects (including the current versions) to Coldline after 30 days, which violates the requirement to transition only noncurrent versions. It could also negatively impact access costs and latency for the active/current statements. Additionally, Coldline’s 90-day minimum storage duration makes it risky if objects are amended and rewritten, potentially creating new versions and leaving older ones subject to early-deletion charges.
This option changes all objects to Nearline after 30 days, which still fails the key requirement: only noncurrent versions should transition. Current statements may need more frequent access, and moving them to Nearline could increase retrieval costs and operational friction. While Nearline is the right class for monthly access, the scope of the lifecycle rule is wrong because it affects current versions as well.
Core Concept: This question tests Cloud Storage Object Versioning and Lifecycle Management, specifically using lifecycle conditions that target noncurrent (older) object versions and selecting an appropriate storage class based on access patterns and cost tradeoffs. Why the Answer is Correct: You need to transition only noncurrent versions after 30 days, not the live/current version. Because previous versions are read once a month for compliance reports and may be accessed again at month-end for amendments, the access pattern is roughly monthly. Nearline Storage is designed for data accessed less than once per month, with lower storage cost than Standard and lower access/early-deletion penalties than Coldline. Therefore, a lifecycle rule that changes noncurrent versions to Nearline after 30 days best matches “monthly reads” while still reducing cost. Key Features / Configuration Details: Cloud Storage lifecycle rules can apply to noncurrent versions by using conditions such as “number of newer versions” and/or “days since noncurrent time” (often expressed as “daysSinceNoncurrentTime”). With Object Versioning enabled, you can keep the current version in Standard for frequent/active use while transitioning only older versions. Nearline has a 30-day minimum storage duration; moving versions after 30 days aligns with that model. This is consistent with the Google Cloud Architecture Framework’s cost optimization principle: choose the lowest-cost storage tier that still meets access and performance requirements. Common Misconceptions: Coldline can look attractive because it is cheaper per GB, but it is optimized for data accessed at most once per quarter and has a 90-day minimum storage duration. With monthly compliance reads, Coldline can increase retrieval and early-deletion costs and may not be cost-optimal overall. Another common mistake is transitioning “all objects” rather than only noncurrent versions, which could degrade performance/cost for the actively used current statements. Exam Tips: 1) Map access frequency to storage class: Standard (frequent), Nearline (monthly), Coldline (quarterly), Archive (yearly+). 2) For versioned buckets, ensure lifecycle rules explicitly target noncurrent versions when the requirement says “previous versions only.” 3) Watch for minimum storage duration charges (Nearline 30 days, Coldline 90 days, Archive 365 days) and align lifecycle timing accordingly.
You plan to host a geospatial tile-rendering backend on Compute Engine; traffic averages 150 concurrent render jobs but spikes to 1,500 during quarterly map releases, and customers must be able to submit jobs 24/7 without interruption or CPU throttling. Your SLO requires 99.9% availability across at least two zones in us-central1, and you want to follow Google-recommended practices so capacity scales automatically without manual intervention. What should you do?
Multiple standalone VMs with a CPU alert threshold still requires manual action to add capacity (or scripting not mentioned). Standalone instances also lack managed autohealing and consistent rollout via instance templates. It doesn’t address the requirement for Google-recommended automatic scaling practices, and it doesn’t explicitly ensure multi-zone high availability across at least two zones in us-central1.
Replacing VMs with high-CPU instances is a vertical scaling approach that is slower and potentially disruptive (instance replacement/restart). It still relies on manual intervention and doesn’t inherently provide multi-zone resilience or managed autohealing. Vertical scaling also won’t handle a 10x spike as effectively as horizontal scaling with autoscaling instance counts.
Using an instance group is closer, but the option says you increase instances “whenever you see high CPU utilization,” which is manual and violates the requirement for automatic scaling without intervention. It also doesn’t specify spanning two zones; a zonal instance group would not meet the SLO requirement for availability across at least two zones in us-central1.
A managed instance group spanning two zones (regional MIG) is the recommended Compute Engine pattern for high availability and elasticity. Autoscaling based on average CPU utilization automatically adds/removes instances to match demand spikes without manual work. MIGs also support autohealing, rolling updates, and consistent configuration via instance templates, aligning with Google best practices and the stated 99.9% multi-zone SLO.
Core Concept: This question tests Compute Engine scalability and high availability using Managed Instance Groups (MIGs), multi-zone deployment, and autoscaling. It also implicitly tests understanding of avoiding manual intervention and meeting an availability SLO. Why the Answer is Correct: A regional (multi-zone) Managed Instance Group in us-central1 can distribute instances across at least two zones, so a single-zone failure doesn’t take the service down, supporting a 99.9% availability target when paired with proper health checks and load balancing. Autoscaling based on average CPU utilization automatically adds instances during quarterly spikes (1,500 concurrent jobs) and scales back during normal load (150 jobs), meeting the requirement for automatic capacity management without manual intervention. Key Features / Configurations: 1) Regional MIG spanning two (or more) zones in us-central1 to satisfy “across at least two zones.” 2) Autoscaler policy using average CPU utilization (or a custom metric like queue depth if jobs are queued) to scale out/in automatically. 3) Instance template to ensure consistent VM configuration and rapid, repeatable scaling. 4) Health checks and autohealing so unhealthy VMs are recreated automatically. 5) Use non-preemptible VMs (standard on-demand) to avoid interruption; avoid overcommitted/shared-core machine types if “no CPU throttling” is a hard requirement. Common Misconceptions: Options that mention “standalone instances” or “increase when you see high CPU” imply manual operations, which violates the requirement for automatic scaling. Also, simply resizing to high-CPU machines doesn’t address sudden spikes well and can still leave you underprovisioned or cause disruptive replacements. Exam Tips: When you see: (1) variable traffic, (2) need for automatic scaling, and (3) multi-zone availability requirements, the default recommended pattern is a Managed Instance Group (often regional) with autoscaling and autohealing. For job-processing workloads, consider whether CPU is the best scaling signal; however, on the ACE exam, “autoscaling based on average CPU utilization” is the canonical answer unless queue-based metrics are explicitly introduced.
Your retail startup operates two Cloud Run services in us-central1 and europe-west1 that emit about 1.5 million structured JSON log entries per day, and you need a scalable, Google-recommended approach to retain at least 30 days of logs, run standard SQL queries over the logs, and build time-series charts to detect latency and HTTP status trends while minimizing operational overhead and cost; what should you do?
Pushing logs to BigQuery can enable SQL and dashboards, but it increases operational overhead (building/maintaining export pipelines, handling failures, schema evolution, partitioning, and access controls). It can also raise costs due to streaming inserts or export jobs and BigQuery storage/query charges. This is not the most Google-recommended “minimal ops” approach when Log Analytics can provide SQL directly on log buckets.
Cloud Logging and Logs Explorer are excellent for real-time troubleshooting, filtering, and ad-hoc investigation, but Logs Explorer is not positioned as the primary solution for “standard SQL queries” across 30 days of high-volume logs. While you can create some charts, the question explicitly calls for SQL analytics and scalable trend analysis with minimal overhead, which is better met by Log Analytics on a log bucket.
This is the recommended approach: keep Cloud Run’s default logging to Cloud Logging, configure a log bucket with 30+ day retention, and enable Log Analytics to query logs using SQL without exporting. It minimizes operational overhead (no custom pipelines), supports scalable analytics, and enables building charts/dashboards for latency and HTTP status trends. You can further optimize cost by routing only needed logs into the analytics-enabled bucket.
Cloud SQL is a relational database intended for transactional workloads, not high-volume log ingestion and analytics. Ingesting 1.5 million log entries/day would require custom ingestion code, careful schema design, and ongoing database operations (scaling, maintenance, indexing). Querying time-series log analytics in Cloud SQL is typically less efficient and more expensive than using Cloud Logging’s native analytics capabilities.
Core Concept: This question tests Google Cloud’s recommended logging architecture for serverless workloads: Cloud Run -> Cloud Logging (log buckets) with Log Analytics enabled to query logs using SQL and build operational dashboards with minimal ops. It aligns with the Google Cloud Architecture Framework’s Operational Excellence (observability) and Cost Optimization pillars. Why the Answer is Correct: Cloud Run writes request and application logs automatically to Cloud Logging. By configuring a log bucket with a 30+ day retention policy and enabling Log Analytics on that bucket, you can run standard SQL queries directly over log entries without exporting to another system. Log Analytics provides a BigQuery-like SQL experience over logs while keeping the operational model simple (no ETL pipelines, no custom scripts). You can then create charts (e.g., latency distributions, error rates by HTTP status) using Logging’s analytics/charting capabilities and/or connect to Cloud Monitoring dashboards for time-series visualization. Key Features / Configurations: 1) Log buckets and retention: Set retention to at least 30 days (per bucket) and use sinks if you want to route specific logs (e.g., only Cloud Run request logs) into a dedicated bucket for cost control. 2) Log Analytics: Enable on the bucket to query logs with SQL (group by status, compute p95 latency, filter by region/service). 3) Multi-region services: Logs from us-central1 and europe-west1 can be centralized into a single bucket (or separated by region) using sinks and filters. 4) Low operational overhead: Managed ingestion, storage, and querying; no database administration. Common Misconceptions: Exporting to BigQuery (Option A) can work, but it adds pipeline management, potential ingestion costs, and schema/partitioning decisions. Logs Explorer alone (Option B) is great for troubleshooting but is not the best fit for “standard SQL queries” and long-term analytics at scale. Cloud SQL (Option D) is not designed for high-volume log analytics and would be costly and operationally heavy. Exam Tips: When you see “Cloud Run logs,” “retain X days,” “SQL over logs,” and “minimize ops,” think: Cloud Logging buckets + retention + Log Analytics. Use sinks/filters to control volume and cost, and remember that analytics use cases often prefer managed logging analytics over building custom export pipelines unless there’s a strong downstream requirement.
Lernzeitraum: 1 month
I could count probably like 15+ question exactly the same on the real exam. Cloud pass always the best pratical exam questions.
Lernzeitraum: 1 month
Thank you for the excellent source for preparing for cert exams, detail explanation really helped. Passed the exam.
Lernzeitraum: 1 month
Got my cert after going though the practice questions. I have a background in GCP so it was a bit easy to grasp for me.
Lernzeitraum: 1 month
This helped my pass the ACE on 1/12 , highly recommended.
Lernzeitraum: 1 month
Passed the exam in first attempt!
Professional
Professional
Associate
Foundational
Professional
Professional
Professional
Professional
Professional
Professional
Lade Cloud Pass herunter und erhalte kostenlosen Zugang zu allen Google Associate Cloud Engineer-Übungsfragen.
Möchtest du alle Fragen unterwegs üben?
Kostenlose App holen
Lade Cloud Pass kostenlos herunter – mit Übungstests, Fortschrittsverfolgung und mehr.