GCP Associate Cloud Engineer Practice Test

Google Cloud Directory Sync (GCDS) is designed to automate provisioning for Cloud Identity or Google Workspace. It regularly reads user and group objects from an LDAP source such as Active Directory and creates, updates, or deletes the corresponding accounts in Cloud Identity. Because GCDS copies only metadata-not passwords-authentication continues to occur against Active Directory when SAML or Google Credential Provider for Windows is configured. Identity federation alone does not provision users, bulk CSV uploads require ongoing manual work, and a custom Cloud Functions solution would duplicate the fully-supported GCDS capabilities and still require maintenance.

To restrict SSH so that only the bastion host can reach the front-end VMs you need an ingress rule that allows traffic coming from the bastion host and to the web-tagged instances. A service account can be used as the source in an ingress rule, while network tags identify the target instances. The action must be allow, and the protocol/port must be limited to tcp:22 for SSH. An egress rule would control traffic leaving the VMs, not traffic entering them. Using 0.0.0.0/0 or an external IP as the source is overly permissive, and a deny rule would block, not permit, the required access.

Cloud Asset Inventory keeps a time-series database of Google Cloud resources and their IAM policies. It lets you query or export the state of an asset at a past timestamp, making it ideal for reconstructing historical configurations such as earlier IAM policies on a Cloud Storage bucket. Cloud Audit Logs and Cloud Logging store event and log data, not full asset state. Cloud Monitoring tracks metrics, not resource configurations.

Using kubectl, the flag --all-namespaces (short form -A) tells the client to query every namespace rather than the default namespace. The command "kubectl get pods -A" therefore prints a consolidated table of all Pods in the cluster regardless of namespace, letting you quickly see where the sidecar is present. The other commands are incorrect: specifying --namespace="*" or -n all is not valid syntax; "kubectl get all -n kube-system" only shows resources in the kube-system namespace; and "kubectl get pods --all" is not a supported flag, so it would return an error.

Memorystore for Redis is a fully managed, in-memory data store that speaks the native Redis protocol. When you create an instance in Standard Tier, the service automatically provisions a replica in a different zone within the same region, replicates data asynchronously to that replica, and performs automatic failover if the primary node becomes unavailable. Because Google operates the service, there is no need for customers to handle cluster installation, patching, or failover scripting, satisfying the minimal-operations requirement.

Cloud SQL and Cloud Bigtable are durable databases, not low-latency in-memory caches, and they do not support Redis commands. Running a self-managed Redis StatefulSet on GKE could meet the protocol requirement but leaves failover, monitoring, and maintenance tasks to your team, conflicting with the low-operations mandate.

The createdBefore condition expects a calendar date formatted as YYYY-MM-DD and interprets that date at 00:00:00 UTC. Any object whose creation time is strictly earlier than that instant is selected by the rule. Therefore, to target objects uploaded before 1 July 2022 you must specify 2022-07-01. Supplying a timestamp, a locale-specific date such as 07/01/2022, or an ISO date-time string will cause the configuration to be rejected because they do not match the required syntax.

A lifecycle management rule is the simplest, fully managed way to automate storage-class transitions without touching application code. A rule with the action SetStorageClass set to Coldline and the condition age = 180 automatically rewrites each eligible object's metadata when it turns 180 days old, changing its class in place. Object retention policies or versioning do not switch storage classes; they only restrict deletions or keep older versions. Scheduled jobs or manual gsutil commands add operational overhead and are unnecessary when lifecycle rules natively support this transition.

The Compute Engine autoscaler can scale a MIG using any Cloud Monitoring metric when you add a custom-metric utilization rule. The Pub/Sub metric "pubsub.googleapis.com/subscription/num_undelivered_messages" is a gauge that represents the current number of unacknowledged messages. By setting utilizationTargetType to GAUGE_PER_INSTANCE, the autoscaler keeps the metric value per VM near the specified target-in this case 500 messages per instance-causing the group to scale out when backlog per VM exceeds 500 and scale in when it drops below that threshold. CPU-based, load-balancer-based, or schedule-based policies would not react to message backlog spikes.

Cloud Trace lets you build an on-the-fly analysis by filtering the trace list with a span name expression such as span:"cloudspanner.googleapis.com/BeginTransaction". When you apply this filter and sort the results by latency, the list shows only the traces that contain that specific Spanner span, ordered from slowest to fastest. By scanning the latency column (or switching to the histogram view) you can immediately see whether traces that include this span are consistently slower than normal traffic. Creating external dashboards, uptime checks, or log-based metrics could add insight but would require additional configuration and would not directly correlate span-level latency across existing traces.

The gcloud compute images create command is used to build custom images. When the source is a snapshot you must supply the --source-snapshot flag, not --source-disk. The --family flag assigns the image to an image family, and --storage-location defines the geographic location where the image file is kept. Therefore the command that uses gcloud compute images create with --source-snapshot prod-app-snap, --family appserver, and --storage-location europe-west1 is correct. The other options either use the wrong gcloud resource (snapshots instead of images), specify an invalid flag such as --region or --source-disk, or omit the required --storage-location flag.

Granting the predefined role roles/compute.instanceAdmin.v1 on the project lets members of the [email protected] group create, start, stop, and modify Compute Engine instances and attached disks. The role does not include broad permissions to administer other services, change billing, or delete the project, making it the least-privileged fit. Granting Editor or Owner at any level would give far more permissions than required, while assigning the Compute Admin role at the organization level would exceed the scope and violate least privilege.

Cloud Profiler does not gather data automatically from GKE workloads. The application process itself must load the Cloud Profiler language agent so that it can sample stack traces and send them to the Profiler backend. In GKE, the agent typically is added by including the Profiler Java agent JAR and setting the appropriate startup options or environment variables. In addition, the Kubernetes service account used by the Pods must have the roles/cloudprofiler.agent IAM role so the agent can write profile data. Simply enabling the API or relying on the Ops Agent running on the nodes does not activate profiling for in-process code, and there is no cluster-level flag or external trace-collection script that will populate Cloud Profiler.

Because the simulations are short-lived, fault-tolerant, and restartable from checkpoints, they match the use case that Spot VMs (previously called preemptible VMs) are designed for. Re-creating the instance template to specify Spot VMs and using that template in the existing managed instance group immediately provides the steep Spot-pricing discount-often 60-91 percent compared with on-demand instances. Spot VMs cannot be live-migrated or automatically restarted, but that is acceptable for this workload, and the MIG will attempt to re-provision instances if capacity is available. The other options either keep full-price VMs, rely on committed use contracts, or change machine characteristics without gaining the larger cost savings that Spot pricing offers.

A Deployment controller manages ReplicaSets to keep the desired number of identical Pods running. It offers built-in support for rolling updates, can automatically roll back if the new Pods fail readiness checks, and records revision history to enable easy rollbacks. A single Pod lacks orchestration capabilities, a Service only provides stable networking, and a StatefulSet focuses on ordered, unique Pods with stable identities-none of which directly handles stateless rolling updates and replica management.

VM Manager's patch management feature lets you schedule recurring patch deployments without recreating the VMs. Enabling the OS Config API in each project and ensuring the OS Config agent is present on every VM allows you to create a weekly patch deployment resource that automatically executes every Wednesday at 02:00. VM Manager stores execution history and compliance data that can be exported for audit purposes. Installing a third-party tool or rebuilding instances is unnecessary, and startup scripts only apply once when a VM boots, so they cannot guarantee weekly execution.

Generating a V4 signed URL meets every requirement. A signed URL embeds a cryptographic signature created by a service account that already has storage.objects.get permission. Anyone who possesses the URL can download only the specified object, and the URL automatically expires after the duration you set (up to 7 days with V4). Signed URLs work even when Uniform bucket-level access is enabled because they do not rely on ACLs, and they are allowed under Public access prevention because access is authenticated by the signature. Granting allUsers IAM access would violate Public access prevention, object ACLs cannot be used while Uniform bucket-level access is on, and making the bucket public is disallowed and insecure.

A custom-mode VPC starts with only the two implied rules: allow-egress (priority 65535) and deny-ingress (priority 65535). Because the deny rule applies to all ingress traffic, even packets whose source is another subnet in the same network are blocked. To enable internal communication you need an ingress rule that explicitly allows traffic whose source is the network's private address space (for example 10.0.0.0/8, which includes both subnets). Any priority number lower than 65535 overrides the implied deny rule; 65534 is sufficient. An egress rule is unnecessary because egress is already allowed, and using 0.0.0.0/0 as the source would open the network to the public internet.

Spot VMs are billed at discounts of up to 91 % compared with on-demand pricing, but they can be preempted at any time. Using a managed instance group of Spot VMs lets Compute Engine automatically recreate any VM that is preempted, so capacity is quickly restored. By defining a custom machine type with 4 vCPUs and 8 GB RAM and an autoscaler that maintains an aggregate 16 vCPUs, you preserve the required total compute while roughly halving per-VM cost in addition to the Spot discount-easily exceeding the 70 % savings target. Keeping the original e2-standard-8 size on Spot VMs would save money but risks throughput loss during preemption because capacity is not automatically recovered. Cloud Run's maximum request timeout is 60 minutes, so it cannot handle a three-hour HPC batch job, and switching to on-demand C2 instances would increase costs instead of reducing them.

The Storage Object Viewer role (roles/storage.objectViewer) contains just the permissions needed to list and read objects, and nothing more. Granting it on the specific bucket limits the scope of access to exactly the required resource. The Editor and Storage Admin roles include many additional permissions across the entire project, violating least-privilege guidance. Giving the project's default Compute Engine service account Owner access is both overly broad and applied to the wrong principal.

Data Access audit logs are disabled by default. To enable them, you add an auditConfig block to the project's IAM policy (or use the IAM-&-Admin > Audit Logs page) that specifies the service name and the log types. Setting the auditConfig for the service storage.googleapis.com with logType values DATA_READ and DATA_WRITE instructs Cloud Logging to record who reads or writes Cloud Storage objects. The other options do not activate Data Access logging: merely enabling an API, creating a sink, or changing bucket-level settings will not turn on these audit logs.