Free Google Cloud ACE practice test

Existing projects can be moved into an organization and organized into folders without service downtime (option C is true). Once a project belongs to an organization, it cannot be removed to standalone status (option E is true). Option A is false; billing accounts are separate from the organizational hierarchy and don't need reassignment based on org structure. Option D is false; IAM policies don't automatically migrate—you must reapply them as needed in the new structure. Option B is false; project-level quotas are not reset during organizational moves.

Billing exports are configured per billing account (option D is correct), so you must set up each one individually. The exported data is encrypted at rest by default and includes detailed billing information (option A is correct). Option E is false; a billing account can export to one dataset, but you can have multiple datasets. Option C is partially correct but misleading; the dataset doesn't need to be in the billing account's project—it can be in any project you have access to. Option B is false; each billing account export goes to a single dataset.

A billing account is attached directly to one or more projects, not to the organization or folders. While you can have billing accounts at different organizational levels for tracking purposes, the actual billing relationship is project-to-billing-account. Cloud Shell is a tool for CLI access, not a place to attach billing accounts. Folder-level billing attachment is not how GCP billing works structurally.

The critical steps are to immediately revoke/regenerate the compromised key (option A) to stop further abuse, check Audit Logs for unauthorized usage (option C), and update applications to use the new key (option D). Option B is unnecessary if you revoke the key; you can reuse the service account. Option E is important but isn't preventing immediate impact like the key revocation does. Option F is not a GCP best practice; you should focus on internal key management.

Cloud Functions is the best choice because the workload is short-lived (30 seconds), triggered on a schedule, and doesn't require constant availability. You pay only for execution time (0.1-second granularity), making it extremely cost-efficient for sporadic tasks. Cloud Run would work but requires at least one warm instance by default and higher memory overhead. Compute Engine with a continuously running instance wastes money since the task only runs 1 hour per day (60 minutes of compute vs. ~30 seconds of actual work). GKE adds unnecessary orchestration complexity and cost for a simple scheduled task.

Preemptible VMs offer up to 70% cost savings and are ideal for fault-tolerant batch jobs that can tolerate interruptions—this job can simply restart if a node is preempted. This requires minimal application changes. Switching to Coldline won't help since the files are accessed once monthly (within the 30-day threshold where retrieval costs become significant). BigQuery would require redesigning the entire application, not just a component change. Committed use discounts provide savings but less than preemptible VMs and don't offer the same financial upside for variable, short-duration workloads.

BigQuery (option 2) is correct. It's specifically designed for analytical queries over large datasets (500 GB historical + 10 GB daily ingestion). BigQuery can execute 50-100 GB table scans in seconds with partitioning/clustering optimization. Native SQL support meets the ad-hoc query requirement. Option 0 (Cloud SQL) is inappropriate; it's optimized for OLTP (row-level operations), not OLAP (analytical scans). SQL instances would struggle with 50-100 GB table scans in 5 seconds. Option 1 (Bigtable) is a wide-column store optimized for time-series data and single-row/narrow-range queries, not full-table analytical scans. Option 3 (Spanner) is a distributed relational database for transactional consistency at scale, not optimized for analytical queries at BigQuery's performance level.

Option 2 is correct. Secret Manager is the appropriate service for storing sensitive data (API keys). Your container reads the secret at startup using the Secret Manager API. This keeps secrets out of container images and provides audit logging. Option 0 is incorrect; while you can package non-sensitive config in images, hardcoding or passing API keys via environment variables is insecure. Option 1 is incorrect; Cloud Run does not support direct filesystem mounts of Cloud Storage buckets; you would need to implement explicit object download logic. Option 3 is insecure for sensitive data and Cloud Run environment variable size limits (4 KB total) would not accommodate a 2 MB YAML file. Option 4 (Cloud SQL) is overkill for configuration management and adds unnecessary database overhead.

Option 0 is correct. You need a VPC, subnets, and egress firewall rules (direction=EGRESS with specific destination CIDRs/ports). This minimal setup restricts outbound traffic as required. Option 1 adds Cloud NAT, which is unnecessary if instances already have external IPs or you're only restricting outbound destinations via firewall rules (Cloud NAT is for providing outbound NAT to instances without external IPs). Option 2 includes VPC Flow Logs, which is monitoring, not a requirement for traffic restriction. Option 3 includes a load balancer, which is for inbound traffic distribution, not relevant to egress restriction. Note: Firewall rules must be the primary tool here; without them, you cannot restrict outbound traffic.

Correct answer: (D) Object retention policies are immutable for the specified duration. No role or command can bypass retention—the object cannot be deleted until the retention period expires. This is a security feature. Wrong answers: (A) gsutil rm will fail because the object is under retention; (B) Retention policies cannot be modified retroactively and the compliance requirement cannot override the policy; (C) Cloud Audit Logs are for auditing, not policy exceptions.

A signed URL provides time-limited, cryptographically signed access to a specific object. The partner can access the object via the URL without a Google account, and the URL automatically expires after the defined period (24 hours here). Updating the bucket's IAM policy requires the partner to have a Google identity and grants persistent access (not time-limited without later revoking it). Making the object publicly readable removes all access controls and exposes it to anyone with the URL — not a controlled, partner-specific solution. VPC Service Controls restrict access to Google APIs based on network and project boundaries; they are designed for internal Google Cloud workloads, require the partner to have a GCP project/identity, and do not create time-limited access.

Correct answer: (C) Cloud Logging agent continuously streams logs in real-time to Cloud Logging, ensuring all logs are preserved even if the instance is terminated. This is the standard GCP approach for log aggregation. Wrong answers: (A) Hourly backups may miss recent logs and require storage management; (B) Shutdown scripts are unreliable during forced termination (scale-down often uses hard termination); (D) Persistent disks persist but do not aggregate logs centrally, defeating the purpose of log preservation for analysis.

Option 3 is best because it combines two key fixes: (1) increasing the ack deadline gives the subscriber more time to process before redelivery, and (2) implementing idempotency ensures that any redelivered messages are handled gracefully without duplicates. Option 0 is incorrect—message retention period doesn't affect ack deadlines; it only controls how long undelivered messages are kept. Option 1 is a partial fix (increasing ack deadline is correct) but doesn't address handling duplicate redeliveries. Option 2 is overkill and unnecessary; the issue isn't topic throughput but subscriber processing speed.

Option 2 is the safest approach for zero-downtime upgrades in a production environment. By creating a new node pool, you can migrate workloads gradually and safely, minimizing risk. Option 0 is dangerous—upgrading the master first creates version skew, and immediately upgrading all nodes causes downtime. Option 1 relies on auto-upgrades which you don't control and may not be fast enough. Option 3 violates the GKE upgrade sequence; the master must be upgraded before nodes. In GKE, the master is always upgraded first, but for minimal downtime with existing workloads, the blue-green node pool approach (option 2) is preferred.

The three most likely causes of scheduling failures despite high CPU are: (0) the node pool has reached its max node limit, preventing autoscaling from adding more nodes; (2) Pods request more resources than available nodes can provide, blocking scheduling even if nodes exist; and (3) autoscaling is disabled or misconfigured, so no new nodes are created. Option 1 is unlikely—API server overload typically manifests as slow API responses, not Pod scheduling failures. Option 4 is a possibility but less common than resource request mismatches or autoscaler misconfiguration. Option 5 refers to machine type size, which is a configuration issue not a scaling response issue.

To meet the requirements, you must (0) increase the Cloud Logging retention policy to at least 730 days to comply with the 2-year retention mandate, and (1) create a sink to export logs to Cloud Storage so they can be archived cheaply after 90 days. Option 2 is redundant—you simply update the existing policy; you don't delete and recreate. Option 3 is a supporting step but not strictly necessary for exporting logs to Cloud Storage (the sink itself handles the export). Option 4 (BigQuery) is an alternative but not necessary if Cloud Storage is the target. Option 5 (storage.admin) is overly permissive; 'storage.objectCreator' is sufficient.

roles/viewer (Project Viewer) grants read-only access to all project resources, including the ability to list Cloud Storage buckets, without any write permissions — satisfying least privilege for this task. roles/storage.objectViewer allows reading object data and metadata inside buckets but does NOT grant permission to list buckets at the project level. roles/storage.legacyBucketReader is a bucket-level role (not project-level) and grants read access to a specific bucket's metadata and objects. roles/storage.admin grants full control over all Storage resources, violating least privilege.

The correct answer is that iam.serviceAccounts.create is not included in the Editor role. While Editor is a broad role, it does not include the ability to create service accounts; only the Owner role and specific IAM Admin roles (like roles/iam.serviceAccountAdmin) include that permission. Custom roles cannot override primitive roles. Blanket deny policies would show in a policy query. Folder-level organization policies would appear in a constraint search.

The correct answer is to enable Data Access logs. Admin Activity logs record administrative actions like creating datasets or changing IAM policies, but not query execution. Data Access logs record when data is read, which includes BigQuery queries. These logs are disabled by default and must be explicitly enabled. Increasing retention period does not add new data. The logging.viewer role allows viewing logs but doesn't enable them. The Cloud Console query history is a separate feature and not an audit log.

The correct answer is option 3. The Monitoring Viewer role (roles/monitoring.viewer) provides read-only access to monitoring data across projects, which is the least-privilege way to allow a service account to read metrics from another project. Option 1 is incorrect because granting Editor is excessive and violates the principle of least privilege. Option 2 is incorrect because Compute Viewer is for viewing compute resources themselves, not monitoring metrics, and API keys are not used for service account authentication. Option 4 is incorrect because Workload Identity is primarily for GKE pods to authenticate to Google Cloud APIs within the same cluster; while it can work cross-project, it's not the standard approach for a service account in one project accessing another. Option 5 describes a valid mechanism but is more complex than needed here; the direct role grant (option 3) is simpler and equally secure.