Google Associate Cloud Engineer

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.”

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.

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.

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.

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.

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.

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.

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.