Associate Cloud Engineer practice questions with answers

Answer: B) Open Cloud Shell from the Google Cloud console

Cloud Shell is a browser-based terminal with gcloud preinstalled and a 5 GB persistent $HOME directory, so it needs no local installation and keeps files between sessions.

• AIncorrect. This gives a working gcloud environment, but it means installing software locally, which the user wants to avoid.
• BCorrect. Cloud Shell opens a browser-based terminal with the Google Cloud CLI preinstalled. It provides 5 GB of free persistent disk mounted as the user's $HOME directory, so files kept there persist between sessions.
• CIncorrect. Cloud Code is an IDE extension, so the user would have to install an IDE and the extension locally. That breaks the no-installation requirement.
• DIncorrect. Cloud Build runs non-interactive build steps in temporary environments. It isn't an interactive shell, and it doesn't keep a home directory between runs.

Answer: A) gcloud auth login

gcloud auth login authorizes the gcloud CLI with a user account. application-default login sets up ADC for client libraries, activate-service-account authorizes a service account, and config set account only switches between accounts that already have credentials.

• ACorrect. gcloud auth login starts a browser-based sign-in, then stores the user's credentials and makes that account the active account for gcloud CLI commands.
• BIncorrect. This command gets user credentials for Application Default Credentials (ADC), which Google client libraries in your own code use. The gcloud CLI doesn't use ADC, and this command has no effect on the accounts set up by gcloud auth login.
• CIncorrect. This command authorizes gcloud with a service account, usually through a --key-file. It doesn't authorize the developer's personal user account.
• DIncorrect. This command sets the core/account property, which switches the active account among principals that already have stored credentials. It doesn't perform a sign-in or get new credentials.

Answer: A) The Cloud Resource Manager API

Projects, folders and organizations are managed through the Cloud Resource Manager API. Service-specific APIs such as Service Usage, Cloud Billing and Cloud Asset Inventory work with projects that already exist, or with what's inside them.

• ACorrect. The Cloud Resource Manager API manages the resource hierarchy containers themselves. Its projects and folders endpoints (for example, POST to cloudresourcemanager.googleapis.com/v3/projects or /v3/folders) create, update, move and delete projects and folders. gcloud projects create and gcloud resource-manager folders create call this API.
• BIncorrect. Cloud Asset Inventory searches, exports and monitors metadata about existing resources and IAM policies. It reports on the hierarchy but can't create projects or folders.
• CIncorrect. The Service Usage API enables and disables services (APIs) inside a project that already exists. It doesn't create the project or its parent folder.
• DIncorrect. The Cloud Billing API manages billing accounts and links projects to them. Linking billing is often the next step after creating a project, but this API can't create projects or folders.

Answer: A) Cloud SQL

For a fully managed relational database running MySQL or PostgreSQL with standard SQL and ACID transactions, choose Cloud SQL. Firestore also offers ACID transactions, but it is a NoSQL document database.

• ACorrect. Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server. It supports standard SQL, relational schemas, and ACID transactions, so it fits an operational order-processing workload.
• BIncorrect. Firestore does support ACID transactions, but it is a NoSQL document database. It is not a relational database with a relational schema, and it can't run as MySQL or PostgreSQL.
• CIncorrect. BigQuery is a serverless data warehouse built for large-scale analytical queries. It is not meant to be the operational transactional database for an order-processing application, and it isn't MySQL or PostgreSQL.
• DIncorrect. Memorystore is a managed in-memory key-value store, typically used for caching. It is not a relational database that supports standard SQL and relational schemas.

Answer: A) It automates extracting the existing app into containers for GKE or Cloud Run without a rewrite, often in days instead of months

Migrate to Containers automates moving VM-based apps into containers on GKE or Cloud Run without a rewrite, which makes the first move much faster and less risky than manual refactoring. It does not re-architect the app into microservices.

• ACorrect. Migrate to Containers automates moving workloads from VMs into containers that run on GKE or Cloud Run, without rewriting or re-architecting the app. Google positions this as much faster than manual refactoring. The team can still refine the containers later.
• BIncorrect. Migrate to Containers containerizes the existing application as it is. It does not redesign a monolith into microservices, which still takes manual re-architecture work.
• CIncorrect. GKE and Cloud Run run any compatible container image, including ones built by hand from a Dockerfile. Migrate to Containers is optional.
• DIncorrect. Managed instance groups are a Compute Engine VM feature. Migrate to Containers targets containers on GKE or Cloud Run, not VM instance groups.

Answer: A) Attach an optional aspect containing the owner and cost center to the dataset's automatically created system entry

Knowledge Catalog creates system entries for BigQuery datasets automatically. To add business context such as an owner, attach optional aspects to the system entry, because its required aspects can't be modified.

• ACorrect. Knowledge Catalog creates system entries for BigQuery datasets automatically. You can add business metadata to a system entry only through optional aspects.
• BIncorrect. BigQuery datasets get system entries automatically, so no lake or zone is needed for them to appear. Attaching an asset also doesn't add owner or cost-center metadata.
• CIncorrect. Custom entries are for sources the catalog doesn't ingest automatically. The dataset already has a system entry, so a custom entry would be a duplicate record that isn't connected to it.
• DIncorrect. Knowledge Catalog manages the required aspects of system entries. You can read them but can't modify them.

Answer: C) gcloud compute instances add-metadata web-1 --metadata-from-file=startup-script=setup.sh

Use gcloud compute instances add-metadata to change the startup-script metadata on one existing VM without recreating it. The updated script runs at the next boot, or you can rerun it manually.

• AThis command sets project-wide metadata, which applies to every VM in the project that has no instance-level value for the key. It is not limited to web-1.
• BThe create command provisions a new VM. It fails if an instance named web-1 already exists in the zone, and it cannot change the metadata of an existing instance.
• Cadd-metadata adds or updates metadata keys, such as startup-script, on an existing instance and leaves other keys unchanged. The new script runs at the next boot, or it can be rerun right away on the VM with 'sudo google_metadata_script_runner startup'.
• DLabels are key-value tags for organizing resources and tracking costs. They are not instance metadata, and the guest environment does not run them as startup scripts.

Answer: A) kubectl apply -f deployment.yaml

kubectl apply -f creates or updates resources from a declarative manifest file. get-credentials only configures kubectl access, kubectl expose creates a Service, and kubectl run imperatively starts a single Pod.

• Akubectl apply -f applies a manifest file to the cluster. It creates the resources if they don't exist and updates them if they do, so the cluster matches the declared configuration. This is the declarative way to deploy a workload to GKE.
• Bkubectl expose creates a Service for a Deployment that already exists so it can be reached. It does not read a manifest file or create the Deployment itself.
• CThis command fetches cluster credentials and configures kubectl to use the cluster. The team has already done that, and the command does not deploy any workload.
• Dkubectl run imperatively starts a single Pod from an image given on the command line. It does not apply the team's declarative manifest or create a Deployment with the specified replica count.

Answer: A) An SSL policy attached to the load balancer's target HTTPS proxy, with the appropriate settings

The TLS versions and cipher suites a load balancer accepts from clients are set by an SSL policy with a minimum TLS version, attached to the target HTTPS or SSL proxy.

• ACorrect. An SSL policy sets the TLS protocol versions and cipher suites the load balancer will negotiate with clients. If the policy's minimum TLS version is 1.2 and it is attached to the target HTTPS proxy, clients that only support older versions are refused.
• BIncorrect. A certificate gives the load balancer its identity for TLS. Switching to a Google-managed certificate doesn't change which TLS protocol versions the load balancer will negotiate.
• CIncorrect. VPC firewall rules filter on IP address, protocol and port. They can't see which TLS version is negotiated, and client traffic to an external Application Load Balancer ends at Google's frontends, not at VPC firewall rules.
• DIncorrect. The backend service protocol controls the connection from the load balancer to the backends. The requirement is about client-to-load-balancer connections, which the SSL policy on the target proxy controls.

Answer: A) Customize the backend's cache key to exclude the utm_* query string parameters

Cloud CDN's default cache key is the full request URI, so query parameters that don't affect the response split the cache. Excluding them in a custom cache key raises the hit ratio.

• ACorrect. By default Cloud CDN uses the full request URI as the cache key, so every URL variant with different parameters is cached as a separate entry. Excluding parameters that don't change the response lets those requests share one cached object.
• BIncorrect. More backend capacity helps the origin handle cache misses, but it does not change how many requests are served from the cache. The hit ratio stays the same.
• CIncorrect. The private directive tells shared caches such as Cloud CDN not to store the response, so the hit ratio would go down.
• DIncorrect. This is basically the default full-URI behavior that is splitting the cache. Keeping every parameter means each URL variant is still a separate cache miss.

Answer: A) The run.googleapis.com/request_count metric, filtered to the new revision and grouped by response_code_class to compare its 5xx share

In a Cloud Run canary, judge the new revision by its own request metrics: filter request_count by revision and response_code_class. A service-wide aggregate can hide the canary's errors.

• ACorrect. Cloud Run writes request_count against the cloud_run_revision resource, and it can be filtered by revision and by response_code_class. This shows the canary's own 5xx ratio next to the stable revision's, which is the telemetry to watch before raising the traffic percentage.
• BIncorrect. Here the stable revision carries 90% of traffic. Combining every revision dilutes the canary's errors, so a problem that affects only the new revision can be hidden in the service-wide rate.
• CIncorrect. Instance count shows how the revision is scaling, not whether its requests succeed. A revision can have plenty of instances and still return many 5xx responses.
• DIncorrect. Audit logs record configuration changes such as updating the traffic split. They don't measure how many requests the new revision serves successfully or with errors.

Answer: B) Increase the disk size while the VM keeps running, then extend the partition and file system from the guest OS

You can increase a Compute Engine persistent disk's size while the VM is running, so no stop is needed. On a non-boot data disk, you must then extend the partition and file system in the guest OS before the extra capacity can be used.

• AThe resize would work, but stopping the VM isn't needed. Compute Engine lets you increase a persistent disk's size while it is attached to a running VM, so this causes downtime for no reason. You would also still need to extend the file system.
• BCorrect. You can increase a persistent disk's size at any time, even while it is attached to a running VM. For a non-boot disk, you must then extend the file system (for example, with resize2fs or xfs_growfs) before the new space can be used.
• CThis adds space, but it is slower and more disruptive than needed. The application has to stop using the disk while it is swapped, and the file system on the new disk may still need to be extended. An online resize does the job without a snapshot.
• DThe online resize is the right first step, but this option is incomplete. For a non-boot disk, the documentation says you must extend the file system after resizing. Until then, the guest OS can't use the new space.

Answer: A) Envelope encryption

Encrypting data with a local DEK and then wrapping that DEK with a Cloud KMS KEK is called envelope encryption.

• ACorrect. In envelope encryption, a data encryption key (DEK) encrypts the data, and a key encryption key (KEK) in Cloud KMS encrypts, or wraps, the DEK. The wrapped DEK can then be stored safely with the encrypted data.
• BIncorrect. With CSEK, you supply your own raw key material directly to services such as Cloud Storage or Compute Engine. It does not describe wrapping a locally generated DEK with a Cloud KMS key.
• CIncorrect. Cloud EKM lets you use keys that are kept in a supported external key management partner. It is a choice about where keys live, not the name of the DEK-wrapping pattern.
• DIncorrect. Key rotation creates new primary key versions on a schedule. It controls a key's lifecycle and does not describe using one key to encrypt the data and another to wrap that key.

Answer: A) Attach a user-managed service account that has only a read role on the bucket, and set the cloud-platform access scope

For least privilege, attach a user-managed service account that has only the IAM roles the workload needs, and use the cloud-platform access scope. Don't rely on the broadly privileged default service account, narrowed scopes, or downloaded key files.

• ACorrect. Google recommends attaching a user-managed service account at creation time (for example, with gcloud compute instances create --service-account=EMAIL --scopes=cloud-platform). You then limit access by granting that service account only the IAM roles it needs, such as Storage Object Viewer on the bucket.
• BIncorrect. Access scopes are a legacy mechanism and set an upper limit on OAuth tokens, but the default service account still holds the broad Editor role. Google recommends the cloud-platform scope with a narrowly scoped service account, so that IAM roles control access.
• CIncorrect. SSH keys control who can log in to the VM. They don't give the application an identity for calling Google Cloud APIs such as Cloud Storage.
• DIncorrect. Service account keys are long-lived credentials that create security risk, and Google advises against them. Attaching a service account lets the VM get short-lived credentials from the metadata server instead.

Answer: A) A subject of kind Group named with the email address of a payments Google Group that is nested in gke-security-groups

Google Groups for RBAC lets a RoleBinding use kind: Group with a Google Group's email address, provided the feature is enabled on the cluster and the group is nested in gke-security-groups. Every member of the group then gets the bound role's permissions.

• ACorrect. With Google Groups for RBAC enabled, a RoleBinding can use kind: Group with a Google Group's email address, as long as that group is a member of the gke-security-groups group. Every member of the group gets the role's permissions, so access follows group membership.
• BIncorrect. Kubernetes service accounts are workload identities. Sharing one service account's token among people removes individual accountability and isn't how you grant human users access.
• CIncorrect. IAM roles aren't RBAC subjects. A Group subject must be the email address of a Google Group that is nested in gke-security-groups. An IAM role name doesn't identify any set of users to Kubernetes RBAC.
• DIncorrect. A User subject identifies a single principal, such as one email address. A project ID isn't a user identity, and binding at project scope wouldn't limit access to the payments team.