Practice Test 4
Practice Test 4
Return to review
Attempt 1
All knowledge areas
All questions
Question 1: Incorrect
Your company migrated its data warehousing solution from its on-premises data
centre to Google Cloud 3 years ago. Since then, several teams have worked on
different data warehousing and analytics needs, and have created numerous
BigQuery datasets. The compliance manager is concerned at the possibility of PII
data being present in these datasets and has asked you to identify all datasets that
contain us_social_security_number column. How can you most efficiently identify
all datasets that contain us_social_security_number column?
(Correct)
(Incorrect)
Write a custom script that uses bq commands to loop through all data sets and
identify those containing us_social_security_number column.
Explanation
Search for us_social_security_number in Data Catalog. is the right answer.
Data Catalog is a fully managed and scalable metadata management service that
empowers organizations to discover quickly, understand, and manage all their data. It
offers a simple and easy-to-use search interface for data discovery, a flexible and
powerful cataloguing system for capturing both technical and business metadata, and a
strong security and compliance foundation with Cloud Data Loss Prevention (DLP) and
Cloud Identity and Access Management (IAM) integrations. The service automatically
ingests technical metadata for BigQuery and Cloud Pub/Sub. It allows customers to
capture business metadata in schematized format via tags, custom APIs, and the UI,
offering a simple and efficient way to catalogue their data assets. You can perform a
search for data assets from the Data Catalog home page in the Google Cloud Console.
See https://cloud.google.com/data-catalog/docs/how-to/search, for example.
All other options are manual, error-prone, time-consuming, and should be avoided.
Question 2: Correct
You work for a multinational conglomerate that has thousands of GCP projects
and a very complex resource hierarchy that includes over 100 folders. An external
audit team has requested to view this hierarchy to fill out sections of a report. You
want to enable them to view the hierarchy while ensuring they can’t do anything
else. What should you do?
Add all individual auditors to an IAM group and grant the group
roles/iam.roleViewer IAM role.
Add all individual auditors to an IAM group and grant the group roles/browser
IAM role.
(Correct)
Explanation
Grant all individual auditors roles/iam.roleViewer IAM role. is not right.
roles/iam.roleViewer provides read access to all custom roles in the project and doesn't
satisfy our requirement of viewing organization hierarchy.
Ref: https://cloud.google.com/iam/docs/understanding-roles
Add all individual auditors to an IAM group and grant the group
roles/iam.roleViewer IAM role. is not right.
roles/iam.roleViewer provides read access to all custom roles in the project and doesn't
satisfy our requirement of viewing organization hierarchy.
Ref: https://cloud.google.com/iam/docs/understanding-roles
Add all individual auditors to an IAM group and grant the group
roles/browser IAM role. is the right answer.
roles/browser Read access to browse the hierarchy for a project, including the folder,
organization, and Cloud IAM policy. This role doesn't include permission to view
resources in the project. And you follow Google recommended practices by adding
users to the group and group to the role. Groups are a convenient way to apply an
access policy to a collection of users. You can grant and change access controls for a
whole group at once instead of granting or changing access controls one at a time for
individual users or service accounts. You can also easily add members to and remove
members from a Google group instead of updating a Cloud IAM policy to add or
remove users.
Ref: https://cloud.google.com/iam/docs/understanding-roles
Ref: https://cloud.google.com/iam/docs/overview
Question 3: Incorrect
Your company stores terabytes of image thumbnails in Google Cloud Storage
bucket with versioning enabled. An engineer deleted a current (live) version of an
image and a non-current (not live) version of another image. What is the outcome
of this operation?
The deleted current version becomes a non-current version. The deleted non-
current version is deleted permanently.
(Correct)
The deleted current version becomes a non-current version, and a lifecycle rule is
applied to transition to Nearline Storage after 30 days. A lifecycle rule is applied
on the deleted non-current version to transition to Nearline Storage after 30 days.
The deleted current version becomes a non-current version, and a lifecycle rule is
applied to delete after 30 days. A lifecycle rule is applied on the deleted non-
current version to delete after 30 days.
(Incorrect)
Explanation
The deleted current version becomes a non-current version. The deleted non-
current version is deleted permanently. is the right answer.
In buckets with object versioning enabled, deleting the live version of an object creates
a noncurrent version while deleting a noncurrent version deletes that version
permanently.
Ref: https://cloud.google.com/storage/docs/lifecycle#actions
Question 4: Correct
You have developed an enhancement for a photo compression application running
on the App Engine Standard service in Google Cloud Platform, and you want to
canary test this enhancement on a small percentage of live users before
completely switching off the old version. How can you do this?
Deploy the enhancement in a GKE cluster and enable traffic splitting in GCP
console.
Deploy the enhancement as a new version of the application and enable traffic
splitting in GCP console.
(Correct)
Deploy the enhancement as a new application in App Engine Standard and enable
traffic splitting in GCP console.
Deploy the enhancement in a GCE VM and enable traffic splitting in GCP console.
Explanation
Deploy the enhancement in a GKE cluster and enable traffic splitting in GCP
console. is not right.
When you can achieve this natively in GCP app engine using versions, there is no need
to do it outside App Engine.
Ref: https://cloud.google.com/appengine/docs/standard/python/splitting-traffic
Question 5: Incorrect
Your company has three GCP projects – development, test and production – that
are all linked to the same billing account. Your finance department has asked you
to set up an alert to notify the testing team when the Google Compute Engine
service costs in the test project exceed a threshold. How should you do this?
Ask your finance department to grant you the Billing Account Administrator IAM
role. Set up a budget and an alert in the billing account.
Ask your finance department to grant you the Project Billing Manager IAM role.
Set up a budget and an alert in the billing account.
Ask your finance department to grant you the Project Billing Manager IAM role.
Set up a budget and an alert for the test project in the billing account.
(Incorrect)
Ask your finance department to grant you the Billing Account Administrator IAM
role. Set up a budget and an alert for the test project in the billing account.
(Correct)
Explanation
Ask your finance department to grant you the Project Billing Manager IAM
role. Set up a budget and an alert for the test project in the billing
account. is not right.
Project Billing Manager role allows a user to attach the project to the billing account,
but does not grant any rights over resources. This role does not provide user
permissions to view spending, create budgets and alerts.
Ref: https://cloud.google.com/billing/docs/how-to/billing-access#overview-of-cloud-
billing-roles-in-cloud-iam
Ask your finance department to grant you the Project Billing Manager IAM
role. Set up a budget and an alert in the billing account. is not right.
Project Billing Manager role allows a user to attach the project to the billing account,
but does not grant any rights over resources. This role does not provide user
permissions to view spending, create budgets and alerts.
Ref: https://cloud.google.com/billing/docs/how-to/billing-access#overview-of-cloud-
billing-roles-in-cloud-iam
Ask your finance department to grant you the Billing Account Administrator
IAM role. Set up a budget and an alert in the billing account. is not right.
Billing Account Administrator role enables a user to view the spend and set budget
alerts. But the budget here isn't scoped to the test project. Since the single billing
account is linked to all three projects, this results in budget alerts being triggered for
Compute Engine usage on all three projects - which is against our requirements.
Ref: https://cloud.google.com/billing/docs/how-to/billing-access#overview-of-cloud-
billing-roles-in-cloud-iam
Ref: https://cloud.google.com/billing/docs/how-to/budgets#budget-scope
Ask your finance department to grant you the Billing Account Administrator
IAM role. Set up a budget and an alert for the test project in the billing
account. is the right answer.
Billing Account Administrator role enables a user to view the spend and set budget
alerts. Also, the budget here is scoped to a single project. Therefore, when the compute
engine costs exceed the threshold in the project, we send an alert, and this only works
for the scoped project, and not all projects linked to the billing account.
Ref: https://cloud.google.com/billing/docs/how-to/billing-access#overview-of-cloud-
billing-roles-in-cloud-iam
Ref: https://cloud.google.com/billing/docs/how-to/budgets#budget-scope
Question 6: Incorrect
Your company stores terabytes of image thumbnails in Google Cloud Storage
bucket with versioning enabled. You want to cut down the storage costs and you
spoke to the image editing lab to understand their usage requirements. They
inform you that they access noncurrent versions of images at most once a month
and are happy for you to archive these objects after 30 days from the date of
creation, however, there may be a need to retrieve and update some of these
archived objects at the end of each month. What should you do?
(Incorrect)
(Correct)
Explanation
We don't know what the current storage class is. In the absence of this information and
considering the four options provided, it is safe to assume that objects are currently in
Regional or Multi-Regional buckets. We want to archive noncurrent versions after 30
days, and you need to read and modify on average once per month.
Question 7: Correct
Your company has two GCP organizations – one for development (and test)
resources, and another for production resources. Each GCP organization has a
billing account and several GCP projects. The new CFO doesn’t like this billing
structure and has asked your team to consolidate costs from all GCP projects onto
a single invoice as soon as possible. What should you do?
Have both the billing account export their billing data to a single BigQuery
dataset.
Link all projects from production GCP organization to the billing account used by
development GCP organization.
(Correct)
Move all projects from both organizations into a new GCP organization and link all
the projects to a new billing account in the new GCP organization.
Move all the projects from production GCP organization into development GCP
organization and link them to the development billing account.
Explanation
Have both the billing account export their billing data to a single BigQuery
dataset. is not right.
Cloud Billing export to BigQuery enables you to export detailed Google Cloud billing
data (such as usage and cost estimate data) automatically throughout the day to a
BigQuery dataset that you specify. Then you can access your Cloud Billing data from
BigQuery for detailed analysis or use a tool like Google Data Studio to visualize your
data. Exporting billing data from both the GCP organizations into a single BigQuery
dataset can help you have a single view of the billing information; however, it doesn't
result in a consolidated invoice, which is our requirement.
Move all the projects from production GCP organization into development GCP
organization and link them to the development billing account. is not right.
While the result is what we need, migrating projects from production into development
GCP organization is not straightforward and takes a lot of time. Our requirements state
we would like to do this as soon as possible, but this option isn't quick.
Move all projects from both organizations into a new GCP organization and
link all the projects to a new billing account in the new GCP
organization. is not right.
While the result is what we need, migrating projects from both organizations into a new
single organization is not straightforward and takes a lot of time. Our requirements state
we would like to do this as soon as possible, but this option isn't quick.
Link all projects from production GCP organization to the billing account
used by development GCP organization. is the right answer.
This option is the quickest that lets us achieve our end requirement of having all GCP
billing in a single invoice. Linking the production projects to development billing
account can be very quick and can be scripted using gcloud.
Ref: https://cloud.google.com/logging/docs/reference/tools/gcloud-logging
Question 8: Correct
Your company processes gigabytes of image thumbnails every day and stores
them in your on-premises data centre. Your team developed an application that
uses these image thumbnails with GCP services such as AutoML vision and pre-
trained Vision API models to detect emotion, understand text and much more. The
Cloud Security team has created a service account with the appropriate level of
access; however, your team is unaware of how to authenticate to the GCP Services
and APIs using the service account. What should you do?
Configure your on-premises application to use the service account username and
password credentials.
Create an IAM user with the appropriate permissions and use the username and
password in your on-premises application.
Run gcloud iam service-accounts keys create to generate a JSON key file for the
service account and configure your on-premises application to present the JSON
key file.
(Correct)
Explanation
Configure your on-premises application to use the service account username
and password credentials. is not right.
Service accounts do not have passwords.
Ref: https://cloud.google.com/iam/docs/service-accounts
Create an IAM user with the appropriate permissions and use the username and
password in your on-premises application. is not right.
Granting a user similar set of permissions lets them impersonate service accounts and
access all resources the service account has access. However, you should use a service
account to represent a non-human user that needs to authenticate and be authorized to
access data in Google APIs. Typically, service accounts are used in scenarios such as:
Running workloads that are not tied to the lifecycle of a human user.
Your application assumes the identity of the service account to call Google APIs so that
the users aren't directly involved.
Ref: https://cloud.google.com/iam/docs/understanding-service-accounts
Run gcloud iam service-accounts keys create to generate a JSON key file for
the service account and configure your on-premises application to present
the JSON key file. is the right answer.
To use a service account outside of Google Cloud, such as on other platforms or on-
premises, you must first establish the identity of the service account. Public/private key
pairs provide a secure way of accomplishing this goal. You can create a service account
key using the Cloud Console, the gcloud tool, the serviceAccounts.keys.create() method,
or one of the client libraries.
Ref: https://cloud.google.com/iam/docs/creating-managing-service-account-keys
Question 9: Incorrect
An external partner working on a production issue has asked you to share a list of
all GCP APIs enabled for your GCP production project – production_v1. How
should you retrieve this information?
(Incorrect)
(Correct)
Execute gcloud services list --available to retrieve a list of all services enabled for
the project.
Execute gcloud info to retrieve the account information and execute gcloud services list
--account {Account} to retrieve a list of all services enabled for the project.
Explanation
Execute gcloud init production_v1 to set production_v1 as the current
project in gcloud configuration and execute gcloud services list --available
to retrieve a list of all services enabled for the project. is not right.
--available return the services available to the project to enable and not the services that
are enabled. This list will include any services that the project has already enabled plus
the services that the project can enable.
Ref: https://cloud.google.com/sdk/gcloud/reference/services/list
Also, to set the current project, you need to use gcloud config set project {project id}
Ref: https://cloud.google.com/sdk/gcloud/reference/config/set
gcloud init is used for initializing or reinitializing gcloud configurations.
https://cloud.google.com/sdk/gcloud/reference/init
Execute gcloud info to retrieve the account information and execute gcloud
services list --account {Account} to retrieve a list of all services enabled
for the project. is not right.
We aren't passing any project id to the command so it would fail with the error shown
below. (n.b. it is possible this command succeeds if you have an active gcloud
configuration that has set the project so rather than accepting value from --project
parameter, the command would obtain the project info from the gcloud configuration.
The command shown below is run when no configuration is active).
which would get all the enabled services for the project.
Question 10: Incorrect
Your colleague is learning about docker images, containers and Kubernetes, and has
recently deployed a sample application to a GKE cluster. Although the sample
application is responding to requests, one of the pods is pending, and they are not sure
why. They shared with you the following configuration files used for deploying the
application and the output from their Cloud Shell instance.
1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4. name: demo-deployment
5. spec:
6. selector:
7. matchLabels:
8. app: demo
9. replicas: 2
10. template:
11. metadata:
12. labels:
13. app: demo
14. spec:
15. containers:
16. - name: demo
17. image: demo:2.7
18. ports:
19. - containerPort: 8080
1. apiVersion: v1
2. kind: Service
3. metadata:
4. name: demo-service
5. spec:
6. ports:
7. - port: 80
8. targetPort: 8080
9. protocol: TCP
10. selector:
11. app: demo
Your colleague has asked you to help them identify why the pod is in a pending state.
How should you proceed with the investigation?
Check for error messages from demo-deployment Deployment object.
(Incorrect)
(Correct)
Explanation
Check for error messages from demo-service Service object. is not right.
The question states we have a problem with the deployment. Checking/Reviewing the
status of the service object isn't of much use here.
Check for error messages from demo-deployment Deployment object. is not right.
Describing the details of the deployment shows us how many of the pods are available
and unavailable but does not show errors/warnings related to a specific pod.
Update ACLs on each container image to provide read-only access to the service
account used by GKE nodes in your project.
(Incorrect)
Enable full access to all Google APIs under Access Scopes when provisioning the
GKE cluster.
Grant the Storage Object Viewer IAM role on the GCR Repo project to the service
account used by GKE nodes in your project.
(Correct)
In the central GCR repo project, grant the Storage Object Viewer role on the Cloud
Storage bucket that contains the container images to a service account and
generate a P12 key for this service account. Configure the Kubernetes service
account to use this key for imagePullSecrets.
Explanation
Here's some info about where Container Registry stores images and how access is
controlled.
Container Registry uses Cloud Storage buckets as the underlying storage for container
images. You control access to your images by granting appropriate Cloud Storage
permissions to a user, group, service account, or another identity. Cloud Storage
permissions granted at the project level apply to all storage buckets in the project, not
just the buckets used by Container Registry. To configure permissions specific to
Container Registry, grant permissions on the storage bucket used by the registry.
Container Registry ignores permissions set on individual objects within the storage
bucket.
Ref: https://cloud.google.com/container-registry/docs/access-control
Enable full access to all Google APIs under Access Scopes when provisioning
the GKE cluster. is not right.
Selecting Allow full access to all Cloud APIs does not provide access to GCR images in a
different project. Suppose the Google Kubernetes Engine cluster and the Container
Registry storage bucket are in the same Google Cloud project. In that case, the Compute
Engine default service account is configured with the appropriate permissions to push or
pull images. But if the cluster is in a different project or if the VMs in the cluster use a
different service account, you must grant the service account the appropriate
permissions to access the storage bucket used by Container Registry.
Ref: https://cloud.google.com/container-registry/docs/using-with-google-cloud-
platform
In this scenario, since there is no mention of the service account. Therefore, we have to
assume we are using a default service account that hasn't been provided permissions to
access the storage bucket used by Container Registry in another project, so the image
pull isn't going to work. You would end up with an error like:
In the central GCR repo project, grant the Storage Object Viewer role on the
Cloud Storage bucket that contains the container images to a service account
and generate a P12 key for this service account. Configure the Kubernetes
service account to use this key for imagePullSecrets. is not right.
It is technically possible to do it this way but using the JSON key and not P12 key as
mentioned in this option. If you would like to understand how to do this, please look at
these blogs.
Ref: https://medium.com/hackernoon/today-i-learned-pull-docker-image-from-gcr-
google-container-registry-in-any-non-gcp-kubernetes-
5f8298f28969 Ref: https://medium.com/@michaelmorrissey/using-cross-project-gcr-
images-in-gke-1ddc36de3d42
Moreover, this approach is suitable for accessing GCR images in a non-Google Cloud
Kubernetes environment. While it can be used in GKE too, it is not as secure as using
Role Bindings since it involves downloading service account keys and setting them up as
secret in Kubernetes.
Grant the Storage Object Viewer IAM role on the GCR Repo project to the
service account used by GKE nodes in your project. is the right answer.
Granting the storage object viewer IAM role in the project where images are stored to
the service account used by the Kubernetes cluster ensures that the nodes in the cluster
can Read Images from the storage bucket. It would be ideal to restrict the role binding
further to provide access just to the Cloud Storage bucket that is used as the underlying
storage for container images. This approach aligns with the principle of least privilege.
For more information about Storage Object Viewer IAM Role for GCR, refer:
https://cloud.google.com/container-registry/docs/access-control#permissions_and_roles
Deploy the workload on a node pool with preemptible compute engine instances
and GPUs attached to them.
(Correct)
Explanation
Enable GKE cluster node auto-provisioning. is not right.
Node auto-provisioning automatically manages a set of node pools on the user's behalf.
Without Node auto-provisioning, GKE considers starting new nodes only from the set of
user-created node pools. With node auto-provisioning, new node pools can be created
and deleted automatically. This in no way helps us with our requirements.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-provisioning
Deploy the workload on a node pool with preemptible compute engine instances
and GPUs attached to them. is not right.
You can use preemptible VMs in your GKE clusters or node pools to run batch or fault-
tolerant jobs that are less sensitive to the ephemeral, non-guaranteed nature of
preemptible VMs. In contrast, we have long-running and non-restartable jobs, so
preemptible VMs aren't suitable for our requirement.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/preemptible-vms
(Correct)
(Incorrect)
Grant the user roles/iam.securityAdmin IAM role.
Explanation
Grant the user roles/iam.roleAdmin IAM role. is not right.
roles/iam.roleAdmin is an administrator role that provides access to all custom roles in
the project. This role doesn't include permissions needed to manage service accounts.
Ref: https://cloud.google.com/iam/docs/understanding-roles#roles-roles
Configure a NodePort service on port 443 for the application and set up a dynamic
pool of DNS A records on the application DNS to achieve round-robin load
balancing.
(Incorrect)
Configure a NodePort service for the application and use an Ingress service to
open it to the public.
(Correct)
Configure a ClusterIP service for the application and set up a DNS A record on the
application DNS to point to the IP service.
Configure an HAProxy service for the application and set up a DNS A records on
the application DNS to the public IP address of the node that runs HAProxy.
Explanation
Configure a ClusterIP service for the application and set up a DNS A record
on the application DNS to point to the IP service. is not right.
Configure an HAProxy service for the application and set up a DNS A records
on the application DNS to the public IP address of the node that runs
HAProxy. is not right.
HAProxy is a popular Kubernetes ingress controller. An Ingress object is an independent
resource, apart from Service objects, that configures external access to a service’s pods.
Ingress Controllers still need a way to receive external traffic. You can do this by
exposing the Ingress Controller as a Kubernetes service with either NodePort or
LoadBalancer type. You can't use public IP of the node the HAProxy is running on as this
may be running in any node in the Kubernetes Cluster. In a majority of scenarios, these
nodes do not have public IPs. They are meant to be private, and the pods/deployments
are accessed through Service objects.
Ref: https://www.haproxy.com/blog/dissecting-the-haproxy-kubernetes-ingress-
controller/
Configure a NodePort service on port 443 for the application and set up a
dynamic pool of DNS A records on the application DNS to achieve round-robin
load balancing. is not right.
Kubernetes Service of type NodePort uses a port in the range 30000-32767, we can’t
configure it for port 443. This option also requires downstream clients to have an
awareness of all of your nodes’ IP addresses, since they will need to connect to those
addresses directly. In other words, they won’t be able to connect to a single, proxied IP
address. And this is against our requirement of "a public IP address".
Ref: https://kubernetes.io/docs/concepts/services-networking/service/
Ref: https://www.haproxy.com/blog/dissecting-the-haproxy-kubernetes-ingress-
controller/
Configure a NodePort service for the application and use an Ingress service
to open it to the public. is the right answer.
This option meets all the requirements. When you create an Ingress object, the GKE
Ingress controller creates a Google Cloud HTTP(S) Load Balancer and configures it
according to the information in the Ingress and its associated Services. You have a
choice between an Internal HTTP(s) Load Balancer and External HTTP(s) Load Balancer,
and as we require to expose the service to the public, we need to use external HTTP(s)
Load Balancer.
Ref: https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#overview
With (Global) Cloud Load Balancing, a single anycast IP front-ends all your backend
instances in regions around the world. It provides cross-region load balancing, including
automatic multi-region failover, which gently moves traffic in fractions if backends
become unhealthy.
Ref: https://cloud.google.com/load-balancing/
The ingress accepts traffic from the cloud load balancer and can distribute the traffic
across the pods in the cluster.
Ref: https://kubernetes.io/docs/concepts/services-networking/ingress/
Some additional info: To deploy an external load balancer in Ingress, you use the gce
ingress class. (For an internal load balancer, you would use gce-internal ingress class.)
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-
ingress#creating_an_ingress
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/internal-load-balance-
ingress#step_4_deploy_ingress
Cloud Run.
(Correct)
Explanation
Cloud Run on GKE. is not right.
Cloud Run on GKE can scale the number of pods to zero. The number of nodes per
cluster cannot scale to zero, and these nodes are billed in the absence of requests.
Ref: https://cloud.google.com/serverless-options
GKE with horizontal pod autoscaling and cluster autoscaler enabled. is not
right.
Like above, while you can set up the pod autoscaler to scale back the pods to zero, the
number of nodes per cluster cannot scale to zero, and these nodes are billed in the
absence of requests. If you specify the minimum node pool size of zero nodes, an idle
node pool can scale down completely. However, at least one node must always be
available in the cluster to run system Pods.
Ref: https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler
Ask all staff to create Cloud Identity accounts using their Google email address
and require them to re-use their AD password for Cloud Identity account.
(Correct)
Create a custom script that synchronizes identities between Active Directory and
Cloud Identity. Use Google Cloud Scheduler to run the script regularly.
Ask your operations team to export identities from active directory into a comma-
separated file and use GCP console to import them into Cloud Identity daily.
Explanation
Create a custom script that synchronizes identities between Active Directory
and Cloud Identity. Use Google Cloud Scheduler to run the script
regularly. is not right.
You could do this, but this process is manual, error-prone, time-consuming, and should
be avoided especially when there is a service/tool that does it out of the box with
minimal configuration.
Ask your operations team to export identities from active directory into a
comma-separated file and use GCP console to import them into Cloud Identity
daily. is not right.
You could do this, but like above this process is manual, error-prone, time-consuming,
and should be avoided especially when there is a service/tool that does it out of the box
with minimal configuration.
Ask all staff to create Cloud Identity accounts using their Google email
address and require them to re-use their AD password for Cloud Identity
account. is not right.
If you let employees create accounts, your organization no longer has full control over
the Google accounts used. This approach has several other issues concerning
creating/managing user accounts and should be avoided.
(Incorrect)
Make the table smaller by removing email_address and add another index on
user_id column to speed up the data retrieval.
(Correct)
Explanation
Update the primary key (user_id) to not have sequential values. is the right
answer.
You should be careful when choosing a primary key to not accidentally create hotspots
in your database. One cause of hotspots has a column whose value monotonically
increases as the first key part because this results in all inserts occurring at the end of
your keyspace. This pattern is undesirable because Cloud Spanner divides data among
servers by key ranges, which means all your inserts will be directed at a single server
that will end up doing all the work.
Ref: https://cloud.google.com/spanner/docs/schema-design#primary-key-prevent-
hotspots
All other options make no sense. The problem is with the sequentially increasing values
in the primary key and removing email_address or adding another index isn't going to
fix the problem.
(Correct)
(Incorrect)
Explanation
Local SSD and GKE Cluster Management Fee. is not right.
You don't need to add an estimated cost for cluster management as the calculator
automatically applies this. At the time of writing this, GKE clusters accrue a management
fee of $0.10 per cluster per hour, irrespective of cluster size or topology. One zonal
cluster per billing account is free. GKE cluster management fees do not apply to Anthos
GKE clusters.
Ref: https://cloud.google.com/kubernetes-engine/pricing
Local SSD, Snapshot Storage and Persistent disk storage. is the right answer.
The pricing calculator for Kubernetes Engine offers us the ability to add GPUs as well as
specify Local SSD requirements for estimation. GPUs don't help us with our requirement
of high IOPS, but Local SSD does.
Ref: https://cloud.google.com/products/calculator
GKE offers always-encrypted local solid-state drive (SSD) block storage. Local SSDs are
physically attached to the server that hosts the virtual machine instance for very high
input/output operations per second (IOPS) and very low latency compared to persistent
disks. Ref: https://cloud.google.com/kubernetes-engine Once you fill in the local SSD
requirement, you can fill in persistent disk storage and snapshot storage.
Question 19: Correct
Your colleague is learning about docker images, containers and Kubernetes, and has
recently deployed a sample application to a GKE You deployed a demo application on a
GKE cluster that uses preemptible nodes. The deployment has 2 replicas, and although
the demo application is responding to requests, the output from Cloud Shell shows one
of the pods is pending state.
1. kubectl get pods -l app=demo
2.
3. NAME READY STATUS RESTART AGE
4. demo-deployment-8998dab376-brm68 0/1 Pending 0 29m
5. demo-deployment-8998dab376-kpg18 1/1 Running 0 29m
The node got preempted before the pod could be started fully. GKE cluster master
is provisioning a new node.
The pod in the pending state is too big to fit on a single preemptible VM. The
node pool needs to be recreated with a bigger machine type.
The pod in the pending state is unable to download the docker image.
Cluster autoscaling is not enabled, and the existing (only) node doesn’t have
enough resources for provisioning the pod.
(Correct)
Explanation
The node got preempted before the pod could be started fully. GKE cluster
master is provisioning a new node. is not right.
Our question states that we provisioned a Google Kubernetes Engine cluster with
preemptible node pool. If the node is pre-empted, the status wouldn’t be pending, it
would be terminating/terminated.
The pod in the pending state is unable to download the docker image. is not
right.
If the node pool has permission issues when pulling the container image, the other pod
would not be in Running status. And the status would have been ImagePullBackOff if
there was a problem pulling the image.
The pod in the pending state is too big to fit on a single preemptible VM.
The node pool needs to be recreated with a bigger machine type. is not right.
If the resource requests in Pod specification are too large to fit on the node, the other
pod would not be in Running status, i.e. both pods should have been in pending status
if this was the case.
Ref: The pending Pod's resource requests are too large to fit on a single node of the
cluster.
Cluster autoscaling is not enabled, and the existing (only) node doesn’t
have enough resources for provisioning the pod. is the right answer.
When you have a deployment with some pods in running and other pods in the
pending state, more often than not it is a problem with resources on the nodes. Here's a
sample output of this use case. We see that the problem is with insufficient CPU on the
Kubernetes nodes, so we have to either enable auto-scaling or manually scale up the
nodes.
Transfer the data from Cloud Storage to Cloud Datastore and advise the business
analysts to run their SQL queries in Cloud Datastore.
Point a BigQuery external table at the Cloud Storage bucket and advise the
business analysts to run their SQL queries in BigQuery.
(Correct)
Transfer the data from Cloud Storage to HDFS. Configure an external table in Hive
to point to HDFS and advise the business analysts to run their SQL queries in Hive.
Transfer the data from Cloud Storage to BigQuery and advise the business analysts
to run their SQL queries in BigQuery.
(Incorrect)
Explanation
Transfer the data from Cloud Storage to Cloud Datastore and advise the
business analysts to run their SQL queries in Cloud Datastore. is not right.
Datastore is a highly scalable NoSQL database, and although it supports SQL like
queries, it doesn't support SQL. Moreover, there is no out of the box way for
transforming the AVRO file from cloud storage into the Cloud Datastore entity. So we
have to do in a bespoke way which adds to our cost and time.
Ref: https://cloud.google.com/datastore
Transfer the data from Cloud Storage to HDFS. Configure an external table in
Hive to point to HDFS and advise the business analysts to run their SQL
queries in Hive. is not right.
Like Cloud Datastore, Hive doesn't directly support SQL; it provides HiveQL (HQL) which
is SQL-like.
Transfer the data from Cloud Storage to BigQuery and advise the business
analysts to run their SQL queries in BigQuery. is not right.
Like the above two, while it is possible to build a solution that transforms and loads data
into the target, BigQuery, which is not a trivial process and involves cost and time. GCP
provides an out of the box way to query AVRO files from Cloud Storage, and this should
be preferred.
Point a BigQuery external table at the Cloud Storage bucket and advise the
business analysts to run their SQL queries in BigQuery. is the right answer.
BigQuery supports querying Cloud Storage data in several formats such as CSV, JSON,
AVRO, etc. You do this by creating a Big Query external table that points to a Cloud
Storage data source (bucket). This solution works out of the box, involves minimal effort,
minimal cost, and is quick.
https://cloud.google.com/bigquery/external-data-cloud-storage
Regional Storage Class.
(Correct)
Explanation
Nearline Storage Class. is not right.
Nearline Storage is a low-cost, highly durable storage service for storing infrequently
accessed data. Nearline Storage is ideal for data you plan to read or modify on average
once per month or less. Nearline storage is more expensive than Coldline Storage which
is more suitable for our requirements.
https://cloud.google.com/storage/docs/storage-classes#nearline
(Correct)
Explanation
Grant roles/iam.roleAdmin IAM role to all members of the compliance team. is
not right.
roles/iam.roleAdmin provides access to all custom roles in the project. This option
doesn't fit our requirement of Compliance team being able to approve requests.
Grant roles/iam.roleAdmin IAM role to the compliance team group. is not right.
roles/iam.roleAdmin provides access to all custom roles in the project. This option
doesn't fit our requirement of Compliance team being able to approve requests.
Assign roles/run.invoker role (Cloud Run Invoker role) on your Cloud Run
application to a service account. Set up a Cloud Pub/Sub subscription on the topic
and configure it to use the service account to push the message to your Cloud Run
application.
(Correct)
Deploy your application to Google Cloud Run on GKE. Set up a Cloud Pub/Sub
subscription on the topic and deploy a sidecar container in the same GKE cluster to
consume the message from the topic and push it to your application.
Trigger a Cloud Function whenever the topic receives a new message. From the
Cloud Function, invoke Cloud Run.
Explanation
Trigger a Cloud Function whenever the topic receives a new message. From the
Cloud Function, invoke Cloud Run. is not right.
Both Cloud functions and Cloud Run are serverless offerings from GCP, and they are
both capable of integrating with Cloud Pub/Sub. It is pointless to invoking Cloud
Function from Cloud Run.
Deploy your application to Google Cloud Run on GKE. Set up a Cloud Pub/Sub
subscription on the topic and deploy a sidecar container in the same GKE
cluster to consume the message from the topic and push it to your
application. is not right.
Like above, you need cloud Run Invoker role on the service account.
Ref: https://cloud.google.com/run/docs/tutorials/pubsub
Also, our question states the application on Cloud Run processes messages from a
Cloud Pub/Sub topic; whereas in this option, we are utilizing a separate container to
process messages from the topic. So this doesn't satisfy our requirements.
Assign roles/run.invoker role (Cloud Run Invoker role) on your Cloud Run
application to a service account. Set up a Cloud Pub/Sub subscription on the
topic and configure it to use the service account to push the message to
your Cloud Run application. is the right answer.
This exact process is described in
https://cloud.google.com/run/docs/tutorials/pubsub
You create a service account.
gcloud iam service-accounts create cloud-run-pubsub-invoker \
--display-name "Cloud Run Pub/Sub Invoker"
You then give the invoker service account permission to invoke your service:
gcloud run services add-iam-policy-binding pubsub-tutorial \
--member=serviceAccount:cloud-run-pubsub-invoker@PROJECT_ID.iam.gserviceaccount.
com \
--role=roles/run.invoker
And finally, you create a Pub/Sub subscription with the service account:
gcloud pubsub subscriptions create myRunSubscription --topic myRunTopic \
--push-endpoint=SERVICE-URL/ \
--push-auth-service-account=cloud-run-pubsub-invoker@PROJECT_ID.iam.gserviceacco
unt
Provision the compute engine instance on the default settings, then scale it as per
sizing recommendations.
(Incorrect)
(Correct)
Provision the compute engine instance on the default settings, then modify it to
have 64 vCPUs.
Use Xeon Scalable Processor (Skylake) as the CPU platform when provisioning the
compute engine instance.
Explanation
Provision the compute engine instance on the default settings, then modify
it to have 64 vCPUs. is not right.
You can't increase the vCPUs to 64 without changing the machine type. While it is
possible to set machine type using gcloud, this would mean downtime for the mission-
critical application while the upgrade happens, which is undesirable.
Ref: https://cloud.google.com/compute/docs/instances/changing-machine-type-of-
stopped-instance
Provision the compute engine instance on the default settings, then scale it
as per sizing recommendations. is not right.
Since the application is mission-critical, we want to ensure that this application has all
the required resources from the beginning. Starting with the default settings provisions
an n1-standard-1 machine that has just 1 vCPU and our mission-critical application
would be severely constrained for resources.
Use Xeon Scalable Processor (Skylake) as the CPU platform when provisioning
the compute engine instance. is not right.
Selecting an Intel Skylake CPU processor does not guarantee the compute engine
instance 64 vCPUs.
Ref: https://cloud.google.com/compute/docs/cpu-platforms
Share the VPC from one of the projects and have the VMs in the other project use
the shared VPC. Ensure both projects belong to the same GCP organization.
(Correct)
Create a new VPC and move all VMs to the new VPC. Ensure both projects belong
to the same GCP organization.
Ensure you have the Administrator role on both projects and move all instances to
two new VPCs.
Ensure you have the Administrator role on both projects and move all instances to
a single new VPC.
Explanation
Share the VPC from one of the projects and have the VMs in the other project
use the shared VPC. Ensure both projects belong to the same GCP
organization. is the right answer.
All other options make no sense. Shared VPC allows an organization to connect
resources from multiple projects to a common Virtual Private Cloud (VPC) network so
that they can communicate with each other securely and efficiently using internal IPs
from that network. When you use Shared VPC, you designate a project as a host project
and attach one or more other service projects to it.
Ref: https://cloud.google.com/vpc/docs/shared-vpc
Store new data in Multi-Regional Storage Class, and add a lifecycle rule to
transition data older than 30 days to Coldline Storage Class.
Store new data in Regional Storage Class, and add a lifecycle rule to transition
data older than 30 days to Nearline Storage Class.
Store new data in Multi-Regional Storage Class, and add a lifecycle rule to
transition data older than 30 days to Nearline Storage Class.
Store new data in Regional Storage Class, and add a lifecycle rule to transition
data older than 30 days to Coldline Storage Class.
(Correct)
Explanation
Our requirements are one region, archival after 30 days and data to be accessed
annually.
Store new data in Multi-Regional Storage Class, and add a lifecycle rule to
transition data older than 30 days to Coldline Storage Class. is not right.
When used in a multi-region, Standard Storage is appropriate for storing data that is
accessed around the world, such as serving website content, streaming videos,
executing interactive workloads, or serving data supporting mobile and gaming
applications. This is against our requirement of one region. Moreover, this is expensive
compared to standard Regional storage.
Ref: https://cloud.google.com/storage/docs/storage-classes#standard
Store new data in Multi-Regional Storage Class, and add a lifecycle rule to
transition data older than 30 days to Nearline Storage Class. is not right.
When used in a multi-region, Standard Storage is appropriate for storing data that is
accessed around the world, such as serving website content, streaming videos,
executing interactive workloads, or serving data supporting mobile and gaming
applications. This is against our requirement of one region. Moreover, this is expensive
compared to standard Regional storage.
Ref: https://cloud.google.com/storage/docs/storage-classes#standard
Store new data in Regional Storage Class, and add a lifecycle rule to
transition data older than 30 days to Nearline Storage Class. is not right.
While selecting Regional Storage is the right choice, archiving to Nearline is not the
most optimal. We have a requirement to access data annually, whereas Nearline Storage
is ideal for data you plan to read or modify on average once per month or less. Nearline
storage is more expensive than Coldline Storage which is more suitable for our
requirements.
https://cloud.google.com/storage/docs/storage-classes#nearline
Store new data in Regional Storage Class, and add a lifecycle rule to
transition data older than 30 days to Coldline Storage Class. is the right
answer.
Regional Storage is the right fit for our requirements (one geographic region) and
archiving to Coldline storage is the most cost-efficient solution. Coldline Storage is a
very-low-cost, highly durable storage service for storing infrequently accessed data.
Coldline Storage is ideal for data you plan to read or modify at most once a quarter.
Since we have a requirement to access data once a quarter and want to go with the
most cost-efficient option, we should select Coldline Storage.
Ref: https://cloud.google.com/storage/docs/storage-classes#coldline
Enable OS Login by adding a metadata tag to the instance with key: enable-
oslogin and value: TRUE. Ask the analysts to SSH to the instance through Cloud
Shell.
Block project-wide public SSH keys from the instance to restrict SSH only through
instance-level keys. Use ssh-keygen to generate a key for each analyst, distribute
the keys to the analysts and ask them to SSH to the instance with their key from
putty.
Block project-wide public SSH keys from the instance to restrict SSH only through
instance-level keys. Use ssh-keygen to generate a single key for all analysts,
distribute the key to the analysts and ask them to SSH to the instance with the key
from putty.
(Incorrect)
Enable OS Login by adding a metadata tag to the instance with key: enable-
oslogin and value: TRUE, and grant roles/compute.osLogin role to the analysts
group. Ask the analysts to SSH to the instance through Cloud Shell.
(Correct)
Explanation
You have multiple ways to connect to instances. More information can be found here:
https://cloud.google.com/compute/docs/instances/access-overview
Block project-wide public SSH keys from the instance to restrict SSH only
through instance-level keys. Use ssh-keygen to generate a key for each
analyst, distribute the keys to the analysts and ask them to SSH to the
instance with their key from putty. is not right.
Generating SSH keys for users is fine, but unless the SSH keys are added to the instance,
users would not be able to SSH to the server. If you need your instance to ignore
project-wide public SSH keys and use only the instance-level keys, you can block
project-wide public SSH keys from the instance. This option only allows users whose
public SSH key is stored in instance-level metadata to access the instance.
Ref: https://cloud.google.com/compute/docs/instances/adding-removing-ssh-
keys#edit-ssh-metadata
Block project-wide public SSH keys from the instance to restrict SSH only
through instance-level keys. Use ssh-keygen to generate a single key for all
analysts, distribute the key to the analysts and ask them to SSH to the
instance with the key from putty. is not right.
While this is possible, sharing SSH keys is a strict NO from a security point of view as this
breaks auditing. Should one of the analysts create a disaster (either accidental or
malicious), your security admin would be unable to identify which of the users in the
analyst group caused the issue.
Enable OS Login by adding a metadata tag to the instance with key: enable-
oslogin and value: TRUE. Ask the analysts to SSH to the instance through
Cloud Shell. is not right.
After you enable OS Login on one or more instances in your project, those VMs accept
connections only from user accounts that have the necessary IAM roles in your project
or organization. In this case, since we have not granted either of these roles -
roles/compute.osLogin or roles/compute.osAdminLogin role, users of analyst group
can't SSH to the server.
Ref: https://cloud.google.com/compute/docs/instances/managing-instance-
access#configure_users
Enable OS Login by adding a metadata tag to the instance with key: enable-
oslogin and value: TRUE, and grant roles/compute.osLogin role to the
analysts group. Ask the analysts to SSH to the instance through Cloud
Shell. is the right answer.
After you enable OS Login on one or more instances in your project, those VMs accept
connections only from user accounts that have the necessary IAM roles in your project
or organization. In this case, we are granting the group compute.osLogin which lets
them log in as non-administrator account. And since we are directing them to use Cloud
Shell to ssh, we don't need to add their SSH keys to the instance metadata.
Ref: https://cloud.google.com/compute/docs/instances/managing-instance-
access#configure_users
Ref: https://cloud.google.com/compute/docs/instances/managing-instance-
access#add_oslogin_keys
Run Redis on a single Google Compute Engine instance of type n1-standard-1, and
configure Redis to use 32GB SSD persistent disk as caching backend.
Set up Redis on a custom compute engine instance with 32 GB RAM and 6 virtual
CPUs.
Create a Kubernetes deployment from Redis image and run it in a GKE Cluster on a
node pool with a single n1-standard-32 instance.
(Incorrect)
Use Cloud Memorystore for Redis instance replicated across two zones and
configured for 32 GB in-memory cache.
(Correct)
Explanation
Requirements
1. latency sensitive
2. 30 GB in-memory cache
4. Cost-effective
Create a Kubernetes deployment from Redis image and run it in a GKE Cluster
on a node pool with a single n1-standard-32 instance. is not right.
Without going into details of the feasibility of this option, let’s assume for now that this
option is possible. But this option is quite expensive. An instance with machine type n1-
standard-32 is over-provisioned for this requirement with 32 vCPUs and 120 GB
Memory. At the time of writing, just the compute cost for a single n1-standard-32
instance is $1.5200 per hour in the Iowa region.
Ref: https://cloud.google.com/compute/all-pricing
In comparison, the cost of GCP Cloud Memorystore is $0.023 per GB-hr or $0.736 for
32GB per hour. Plus, you need to take into consideration the Cluster charges for GKE,
setting up high availability as a single instance is a single point of failure etc. which
shoots up the costs.
Ref: https://cloud.google.com/memorystore.
Use Cloud Memorystore for Redis instance replicated across two zones and
configured for 32 GB in-memory cache. is the right answer.
This option is the only one that fits the requirements. Cloud Memorystore is a fully
managed in-memory data store service for Redis built on scalable, secure, and highly
available infrastructure managed by Google. Use Memorystore to build application
caches that provide sub-millisecond data access.
Ref: https://cloud.google.com/memorystore
Memorystore for Redis instance pricing is charged per GB-hour, and you can scale as
needed. You can also specify eviction (maxmemory) policies to restrict the rest of
processes to 2GB or the reverse proxy to 30GB or both; you can select a suitable
maxmemory policy to handle scenarios when memory is full.
Ref: https://cloud.google.com/memorystore/docs/reference/redis-
configs#maxmemory_policies
Create a new GPU enabled node pool with the required specification, and
configure node selector on the pods with key: cloud.google.com/gke-accelerator
and value: nvidia-tesla-k80.
(Correct)
Terminate all existing nodes in the node pools and create new nodes with the
required GPUs attached.
Create a dedicated GKE cluster with GPU enabled node pool as per the required
specifications, and migrate the ML jobs to the new cluster.
(Incorrect)
Add a metadata tag to the pod specification with key: accelerator and value: tesla-
gpu.
Explanation
Add a metadata tag to the pod specification with key: accelerator and value:
tesla-gpu. is not right.
There are two issues with this approach. One - the syntax is invalid. Two - You cannot
add GPUs to existing node pools.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/gpus
Terminate all existing nodes in the node pools and create new nodes with the
required GPUs attached. is not right.
There are two issues with this approach.
One - recreating all nodes to enable GPUs makes the cluster very expensive. Only the
ML team needs access to GPUs to train their models. Recreating all nodes to enable
GPUs helps your ML team use them, but they are left unused for all other workloads yet
cost you money.
Two - Even though your nodes have GPUs enabled, you still have to modify pod
specifications to request GPU. This step isn't performed in this option.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/gpus
Create a dedicated GKE cluster with GPU enabled node pool as per the
required specifications, and migrate the ML jobs to the new cluster. is not
right.
While this works, it increases the cost as you now pay the Kubernetes cluster
management fee for two clusters instead of one. GKE clusters accrue a management fee
that is per cluster per hour, irrespective of cluster size or topology.
Ref: https://cloud.google.com/kubernetes-engine/pricing
Create a new GPU enabled node pool with the required specification, and
configure node selector on the pods with key: cloud.google.com/gke-
accelerator and value: nvidia-tesla-k80. is the right answer.
This option is the most optimal solution for the requirement. Rather than recreating all
nodes, you create a new node pool with GPU enabled. You then modify the pod
specification to target particular GPU types by adding node selector to your workload's
Pod specification. You still have a single cluster, so you pay Kubernetes cluster
management fee for just one cluster, thus minimizing the cost.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/gpus
Ref: https://cloud.google.com/kubernetes-engine/pricing
Example:
apiVersion: v1
kind: Pod
metadata:
name: my-gpu-pod
spec:
containers:
- name: my-gpu-container
image: nvidia/cuda:10.0-runtime-ubuntu18.04
command: ["/bin/bash"]
resources:
limits:
nvidia.com/gpu: 2
nodeSelector:
cloud.google.com/gke-accelerator: nvidia-tesla-k80 # or nvidia-tesla-p100 or
nvidia-tesla-p4 or nvidia-tesla-v100 or nvidia-tesla-t4
(Correct)
(Incorrect)
Explanation
Deploy the application on a Shielded VM. is not right.
Shielded VMs are virtual machines (VMs) on Google Cloud hardened by a set of security
controls that help defend against rootkits and boot kits. Using Shielded VMs helps
protect enterprise workloads from threats like remote attacks, privilege escalation, and
malicious insiders. But shielded VMs don't offer protection for accidental termination of
the instance.
Ref: https://cloud.google.com/shielded-vm
Grant a custom role with just the required query permissions to the analysts’
group.
(Correct)
Grant a custom role with just the required query permissions to all the analysts.
Explanation
Grant roles/bigquery.dataOwner IAM role to the analysts’ group. is not right.
roles/bigquery.dataEditor is a BigQuery Data Editor role which when applied to a
dataset provides permissions to read the dataset's metadata and to list tables in the
dataset; Create, update, get, and delete the dataset's tables. When applied at the project
or organization level, this role can also create new datasets. We want to grant users
query access but not modify/delete.
Grant a custom role with just the required query permissions to all the
analysts. is not right.
This option might work, but this is a manual, error-prone, time-consuming, and adds to
operational overhead. If GCP provides a primitive role that is fit for purpose, this should
be preferred over creating custom roles.
Grant a custom role with just the required query permissions to the
analysts’ group. is not right.
This option might work, but like above this is a manual, error-prone, time-consuming,
and adds to operational overhead. If GCP provides a primitive role that is fit for purpose,
this should be preferred over creating custom roles.
Grant roles/bigquery.user IAM role to the analysts’ group. is the right answer.
roles/bigquery.user is a BigQuery User role, which when applied to a project provides
the ability to run jobs, including queries, within the project. A member with this role can
enumerate their jobs, cancel their jobs, and enumerate datasets within a project.
Ref: https://cloud.google.com/iam/docs/understanding-roles#bigquery-roles
Add the auditors’ account to the predefined project viewer IAM role.
(Correct)
Add the auditors’ account to a custom IAM role that has view-only permissions on
all the project services.
Add the auditors’ account to a custom IAM role that has view-only permissions on
all the project resources.
(Incorrect)
Add the auditors’ account to the predefined service viewer IAM role.
Explanation
Add the auditors’ account to the predefined project viewer IAM role. is the
right answer
The primitive role roles/viewer provides read access to all resources in the project. The
permissions in this role are limited to Get and list access for all resources. As we have an
out of the box role that exactly fits our requirement, we should use this.
Ref: https://cloud.google.com/resource-manager/docs/access-control-proj
It is advisable to use the existing GCP provided roles over creating custom roles with
similar permissions as this becomes a maintenance overhead. If GCP modifies how
permissions are handled, or adds/removes permissions, the default GCP provided roles
are automatically updated. However, the responsibility is with us for custom IAM roles,
which adds to the operational overhead and should be avoided.
Ask the third-party provider to enable SAML for the application and set the
credentials to the service account credentials.
Have a single person from the procurement team access the document signing
system with the service account credentials.
Register the application as a password vaulted app and set the credentials to the
service account credentials.
(Correct)
Ask the third-party provider to enable OAuth 2.0 for the application and set the
credentials to the service account credentials.
Explanation
Ask the third party provider to enable SAML for the application and set the
credentials to always use service account credentials. is not right.
The application may or may not support SAML. Moreover, you can't set the credentials
in SAML integration to always use a particular account. The authentication is carried out
by IdP such as GSuite or a third-party identity provider. Since users are prohibited from
sharing the service account credentials, they wouldn't be able to sign in through the IdP
with the service account credentials.
Ask the third party provider to enable OAuth 2.0 for the application and set
the credentials to always use service account credentials. is not right.
The application may or may not support OAuth 2.0. Moreover, you can't set the
credentials in SAML integration to always use a particular account. The authentication is
carried out by IdP such as GSuite or a third-party identity provider. Since users are
prohibited from sharing the service account credentials, they wouldn't be able to sign in
through the IdP with the service account credentials.
Have a single person from the procurement team access the document signing
system with the service account credentials. is not right.
While this would prevent password reuse, it goes against our requirements and results
in a single person dependency.
Register the application as a password vaulted app and set the credentials
to the service account credentials. is the right answer.
As a G Suite or Cloud Identity administrator, the password vaulted apps service enables
you to manage access to some of the apps that don't support federation and that are
available to users on the User Dashboard. The password vaulted apps service saves login
credential sets for applications and assigns those credential sets to users through group
association. When a user has access to one of these applications through a group, they
can sign in to the application through the user dashboard, or they can sign in directly
from the specific application. This functionality is possible by leveraging Chrome or
Firefox extensions/plugins. When adding an app to the password vaulted apps service,
you can search and choose from the available web-based applications in the app library,
or you can add a custom app. You can then manage usernames and passwords safely
while providing users in your organization with quick one-click access to all of the apps
they already use.
Ref: https://support.google.com/cloudidentity/answer/9178974?hl=en
(Correct)
Explanation
Grant roles/billing.User IAM role to the finance group. is not right.
This role has very restricted permissions, so you can grant it broadly, typically in
combination with Project Creator. These two roles allow a user to create new projects
linked to the billing account on which the role is granted.
Ref: https://cloud.google.com/billing/docs/how-to/billing-access
Grant roles/billing.Viewer IAM role to the finance group. is the right answer.
Billing Account Viewer access would usually be granted to finance teams; it provides
access to spending information but does not confer the right to link or unlink projects
or otherwise manage the properties of the billing account.
Ref: https://cloud.google.com/billing/docs/how-to/billing-access
Add a metadata tag with key: logs-destination and value: bq://pt-logs, and grant
the VM service accounts BigQuery Data Editor role on the pt-logs dataset.
Configure a job in BigQuery to fetch all Compute Engine logs from Stackdriver. Set
up Cloud Scheduler to trigger a Cloud Function every day at midnight. Grant the
Cloud Function the BigQuery jobUser role on the pt-logs dataset and trigger the
BigQuery job from Cloud Function.
(Incorrect)
Create an export for Compute Engine logs in Cloud Logging and set up BigQuery
pt-logs dataset as sink destination.
(Correct)
Create an export for all logs in Cloud Logging and set up a Cloud Pub/Sub topic as
the sink destination. Have a Cloud Function trigger based on the messages in the
topic and configure it to send logs Compute Engine service to BigQuery pt-logs
dataset.
Explanation
Add a metadata tag with key: logs-destination and value: bq://pt-logs, and
grant the VM service accounts BigQuery Data Editor role on the pt-logs
dataset. is not right.
Among other things, roles/bigquery.dataEditor lets you Create, update, get, and delete
the dataset's tables. However, setting a metadata tag logs-destination to bq://pt-logs
does not affect how the logs are generated or forwarded. The stack driver agent is
already installed, so the logs are forwarded to stack driver logging and not to the
BigQuery dataset. Metadata entries are key-value pairs and do not influence this
behaviour.
Ref: https://cloud.google.com/compute/docs/storing-retrieving-metadata
Create an export for all logs in Cloud Logging and set up a Cloud Pub/Sub
topic as the sink destination. Have a Cloud Function trigger based on the
messages in the topic and configure it to send logs Compute Engine service
to BigQuery pt-logs dataset. is not right.
While the result meets our requirement, this option involves more steps; it is inefficient
and expensive. Triggering a cloud function for each log message and then dropping
messages that are not relevant (i.e. not compute engine logs) is inefficient. We are
paying for cloud function execution for all log entries when we are only interested in
compute engine logs. Secondly, triggering a cloud function and then have that insert
into the BigQuery dataset is also inefficient and expensive when the same can be
achieved directly by configuring BigQuery as the sink destination - we don't pay for
cloud function executions. Using this option, we are unnecessarily paying for Cloud
Pub/Sub and Cloud Functions.
Ref: https://cloud.google.com/logging/docs/export/configure_export_v2
Ref: https://cloud.google.com/logging/docs/view/advanced-queries
Create an export for Compute Engine logs in Cloud Logging and set up
BigQuery pt-logs dataset as sink destination. is the right answer.
In stack driver logging, it is possible to create a filter just to query the compute engine
logs which is what we are interested.
Ref: https://cloud.google.com/logging/docs/view/advanced-queries
You can then export these logs into a sink that has the BigQuery dataset configured as
the destination.
https://cloud.google.com/logging/docs/export/configure_export_v2
This way, just the logs that we need are exported to BigQuery. This option is the most
efficient of all options and uses features provided by GCP out of the box.
Configure a firewall rule to allow inbound (ingress) UDP traffic on port 636 from
0.0.0.0/0 for the network tag allow-inbound-udp-636, and add this network tag to
the LDAP server Compute Engine Instance.
(Correct)
Configure a firewall route called default-allow-udp and have the next hop as the
LDAP server Compute Engine Instance.
(Incorrect)
Add default-allow-udp network tag to the LDAP server Compute Engine Instance.
Configure a firewall rule to allow outbound (egress) UDP traffic on port 636 to
0.0.0.0/0 for the network tag allow-outbound-udp-636, and add this network tag
to the LDAP server Compute Engine Instance.
Explanation
Configure a firewall route called default-allow-udp and have the next hop as
the LDAP server Compute Engine Instance. is not right.
Google Cloud routes define the paths that network traffic takes from a virtual machine
(VM) instance to other destinations. These destinations can be inside your Google Cloud
Virtual Private Cloud (VPC) network (for example, in another VM) or outside it. Routes
aren't a suitable solution for our requirement as we need to enable EXTERNAL clients to
reach our VM on port 636 using UDP.
Ref: https://cloud.google.com/vpc/docs/routes
Add default-allow-udp network tag to the LDAP server Compute Engine
Instance. is not right.
Tags enable you to make firewall rules and routes applicable to specific VM instances,
but default-allow-udp is not a network tag that GCP provides. The default network tags
provided by GCP are default-allow-icmp, default-allow-internal, default-allow-RDP and
default-allow-ssh. In this scenario, we are assigning a tag to the instance with no
network rules, so there would be no difference in the firewall behaviour.
Ref: https://cloud.google.com/vpc/docs/add-remove-network-tags
Configure a firewall rule to allow outbound (egress) UDP traffic on port 636
to 0.0.0.0/0 for the network tag allow-outbound-udp-636, and add this
network tag to the LDAP server Compute Engine Instance. is not right.
We are interested in enabling inbound traffic to our VM, whereas egress firewall rules
control outgoing connections from target instances in your VPC network.
Ref: https://cloud.google.com/vpc/docs/firewalls#egress_cases
Configure a firewall rule to allow inbound (ingress) UDP traffic on port 636
from 0.0.0.0/0 for the network tag allow-inbound-udp-636, and add this
network tag to the LDAP server Compute Engine Instance. is the right answer.
This option fits all the requirements. Ingress firewall rules control incoming connections
from a source to target instances in your VPC network. We can create an ingress firewall
rule to allow UDP port 636 for a network tag. And when we assign this network tag to
the instance, the firewall rule applies to the instances, so traffic is accepted on port 636
using UDP. Although not specified in this option, it has to be assumed that the source
for the firewall rule is set to 0.0.0.0/0, i.e. all IP ranges so that external clients are allowed
to connect to this VM.
Ref: https://cloud.google.com/vpc/docs/firewalls#ingress_cases
Update the deployment manager template to add a metadata tag with key:
daemon-system and value: DaemonSet manifest YAML.
Add a new type provider in Deployment Manager for Kubernetes APIs and use the
new type provider to create the DaemonSet resource.
(Correct)
Explanation
Update the deployment manager template to add a metadata tag with key:
daemon-system and value: DaemonSet manifest YAML. is not right.
Metadata entries are key-value pairs and do not influence this behaviour.
Ref: https://cloud.google.com/compute/docs/storing-retrieving-metadata
Ref: https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
But this involves using the compute engine service, which is an additional service. We
require to achieve using the fewest possible services, and as you'll notice later, the
correct answer uses fewer services.
Have the Runtime Configurator create a RuntimeConfig resource with the
DaemonSet definition. is not right.
You can configure the GKE nodes (provisioned by Deployment manager) to report their
status to the Runtime Configurator, and when they are UP, you can run a task to create a
DaemonSet. While this is possible, it involves one additional service - to run a task, e.g.
using Cloud Functions, etc. We require to achieve using the fewest possible services, and
as you'll notice later, the correct answer uses fewer services.
Here is some more info about Runtime Configurator. The Runtime Configurator feature
lets you define and store data as a hierarchy of key-value pairs in Google Cloud
Platform. You can use these key-value pairs as a way to:
For example, imagine a scenario where you have a cluster of nodes that run a startup
procedure. During startup, you can configure your nodes to report their status to the
Runtime Configurator, and then have another application query the Runtime
Configurator and run specific tasks based on the status of the nodes.
The Runtime Configurator also offers a Watcher service and a Waiter service. The
Watcher service watches a specific key pair and returns when the value of the key pair
changes, while the Waiter service waits for a specific end condition and returns a
response once that end condition has been met.
Ref: https://cloud.google.com/deployment-manager/runtime-configurator
Add a new type provider in Deployment Manager for Kubernetes APIs and use
the new type provider to create the DaemonSet resource. is the right answer.
A type provider exposes all resources of a third-party API to Deployment Manager as
base types that you can use in your configurations. If you have a cluster running on
Google Kubernetes Engine, you could add the cluster as a type provider and access the
Kubernetes API using Deployment Manager. Using these inherited API, you can create a
DaemonSet. This option uses just the Deployment Manager to create a DaemonSet and
is, therefore, the right answer.
Ref: https://cloud.google.com/deployment-manager/docs/configuration/type-
providers/creating-type-provider
Question 38: Correct
To prevent accidental security breaches, the security team at your company has
enabled Domain Restricted Sharing to limit resource sharing in your GCP
organization to just your cloud identity domain. The compliance department has
engaged an external auditor to carry out the annual audit, and the auditor
requires read access to all resources in the production project to fill out specific
sections in the audit report. How can you enable this access?
Create a new Cloud Identity account for the auditor and grant them roles/viewer
IAM role on the production project.
(Correct)
Grant the auditors’ Google account roles/viewer IAM role on the production
project.
Create a new Cloud Identity account for the auditor and grant them
roles/iam.securityReviewer IAM role on the production project.
Explanation
Grant the auditors’ Google account roles/viewer IAM role on the production
project. is not right.
Since the auditor's account is not part of your company's Cloud Identity domain, the
auditor can not access resources from your GCP projects. Domain restriction constraint
can be used in organization policies to limit resource sharing based on domain. This
constraint allows you to restrict the set of identities that are allowed to be used in Cloud
Identity and Access Management policies. In this scenario, since we are restricting based
on the Cloud Identity domain, only the users in the Cloud Identity domain can access
GCP services.
https://cloud.google.com/resource-manager/docs/organization-policy/restricting-
domains
Create a new Cloud Identity account for the auditor and grant them
roles/iam.securityReviewer IAM role on the production project. is not right.
Creating a temporary account for the auditor in your cloud identity is the right approach
as this makes the auditor part of the Cloud identity domain and the organization policy
in place lets the auditor access resources. However, the role granted here is not suitable;
it provides permissions to list all resources and Cloud IAM policies. Note that list
permissions only allow you to list but not view resources. You need to get permission to
view the resources.
Ref: https://cloud.google.com/iam/docs/understanding-roles#iam-roles
Create a new Cloud Identity account for the auditor and grant them
roles/viewer IAM role on the production project. is the right answer.
The primitive viewer role provides permissions for read-only actions that do not affect
the state, such as viewing (but not modifying) existing resources or data. This fits our
requirements.
Also, adding the auditor to Cloud Identity ensures that Organization Policy for Domain
Restricted Sharing doesn't block them from accessing resources.
Ref: https://cloud.google.com/iam/docs/understanding-roles#primitive_role_definitions
Configure the pods to use containerd as the runtime by adding a node selector
with key: cloud.google.com/gke-os-distribution and value:cos_containerd.
Detect vulnerabilities in the application container images in GCR repo by using the
Container Analysis API.
Create a new (non-default) node pool with sandbox type set to gvisor and
configure the deployment spec with a runtimeClassName of gvisor.
(Correct)
(Incorrect)
Explanation
Have your applications use trusted container images by enabling Binary
Authorization. is not right.
Binary Authorization is a deploy-time security control that ensures only trusted
container images are deployed on Google Kubernetes Engine (GKE). With Binary
Authorization, you can require images to be signed by trusted authorities during the
development process and then enforce signature validation when deploying. By
enforcing validation, you can gain tighter control over your container environment by
ensuring only verified images are integrated into the build-and-release process. This
option doesn’t help us with the requirement.
Ref: https://cloud.google.com/binary-authorization
Create a new (non-default) node pool with sandbox type set to gvisor and
configure the deployment spec with a runtimeClassName of gvisor. is the right
answer.
GKE Sandbox provides an extra layer of security to prevent untrusted code from
affecting the host kernel on your cluster nodes when containers in the Pod execute
unknown or untrusted code. Multi-tenant clusters and clusters whose containers run
untrusted workloads are more exposed to security vulnerabilities than other clusters.
Examples include SaaS providers, web-hosting providers, or other organizations that
allow their users to upload and run code. When you enable GKE Sandbox on a node
pool, a sandbox is created for each Pod running on a node in that node pool. Also,
nodes running sandboxed Pods are prevented from accessing other Google Cloud
services or cluster metadata. Each sandbox uses its userspace kernel. With this in mind,
you can make decisions about how to group your containers into Pods, based on the
level of isolation you require and the characteristics of your applications.
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-
pods#enabling-new
Ref: https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-
pods#sandboxed-application
Question 40: Correct
Your company has several business-critical applications running on its on-premises
data centre, which is already at full capacity, and you need to expand to Google
Cloud Platform to handle traffic bursts. You want to virtual machine instances in
both on-premises data centre and Google Cloud Compute Engine to communicate
via their internal IP addresses. What should you do?
Create a new GCP project and a new VPC and make this a shared VPC with the on-
premises network. Allow applications in the data centre to scale to Google Cloud
on the shared VPC.
Create a new VPC in GCP with a non-overlapping IP range and configure Cloud
VPN between the on-premises network and GCP. Allow applications in the data
centre to scale to Google Cloud through the VPN tunnel.
(Correct)
Add bastion hosts in GCP as well as on-premises network and set up a proxy
tunnel between the bastion hosts in GCP and the bastion hosts in the on-premises
network. Allow applications in the data centre to scale to Google Cloud through
the proxy tunnel.
Create a new GCP project and a new VPC and enable VPC peering between the new
VPC and networks in the data centre.
Explanation
Create a new GCP project and a new VPC and make this a shared VPC with the
on-premises network. Allow applications in the data centre to scale to
Google Cloud on the shared VPC. is not right.
Shared VPC allows an organization to connect resources from multiple projects to a
common Virtual Private Cloud (VPC) network so that they can communicate with each
other securely and efficiently using internal IPs from that network. When you use Shared
VPC, you designate a project as a host project and attach one or more other service
projects to it. This in no way helps us connect to our on-premises network.
Ref: https://cloud.google.com/vpc/docs/shared-vpc
Create a new GCP project and a new VPC and enable VPC peering between the
new VPC and networks in the data centre. is not right.
Google Cloud VPC Network Peering allows internal IP address connectivity across two
Virtual Private Cloud (VPC) networks regardless of whether they belong to the same
project or the same organization. VPC Network Peering enables you to connect VPC
networks so that workloads in different VPC networks can communicate internally.
Traffic stays within Google's network and doesn't traverse the public internet. This
doesn't help us connect to our on-premises network.
Ref: https://cloud.google.com/vpc/docs/vpc-peering
Add bastion hosts in GCP as well as on-premises network and set up a proxy
tunnel between the bastion hosts in GCP and the bastion hosts in the on-
premises network. Allow applications in the data centre to scale to Google
Cloud through the proxy tunnel. is not right.
Bastion hosts provide an external facing point of entry into a network containing private
network instances. Bastion hosts are primarily for end users so they can connect to an
instance that does not have an external IP address through a bastion host.
Ref: https://cloud.google.com/compute/docs/instances/connecting-advanced
Create a new VPC in GCP with a non-overlapping IP range and configure Cloud
VPN between the on-premises network and GCP. Allow applications in the data
centre to scale to Google Cloud through the VPN tunnel. is the right answer.
Cloud VPN securely connects your on-premises network to your Google Cloud (GCP)
Virtual Private Cloud (VPC) network through an IPsec VPN connection.
Ref: https://cloud.google.com/vpn/docs/concepts/overview
In a new GCP project, enable the required GCP services and APIs, and deploy the
necessary production resources.
(Correct)
Deploy the production resources in a new subnet within the existing GCP project.
(Incorrect)
Set up a shared VPC between test GCP project and production GCP project, and
configure both test and production resources to use the shared VPC to achieve
maximum isolation.
Explanation
Set up a shared VPC between test GCP project and production GCP project, and
configure both test and production resources to use the shared VPC to
achieve maximum isolation. is not right.
A Shared VPC allows an organization to connect resources from multiple projects to a
common Virtual Private Cloud (VPC) network so that they can communicate with each
other securely and efficiently using internal IPs from that network. This goes totally
against the recommendations of the security team.
Ref: https://cloud.google.com/vpc/docs/shared-vpc
Deploy the production resources in a new subnet within the existing GCP
project. is not right.
You can't achieve complete isolation between test and production environments. When
configuration access in Cloud SQL, while you can grant any application access to a
Cloud SQL instance by authorizing the public IP addresses that the application uses to
connect, you can not specify a private network (for example, 10.x.x.x) as an authorized
network. The compute engine instances use their private IP addresses to reach out to
Cloud SQL. Because of the above limitation, we can't prevent the test compute engine
instances reaching out to production MySQL and vice versa. Since the security team has
forbidden the existence of network routes between these 2 environments, having the
production and test environments in a single project is not an option.
https://cloud.google.com/sql/docs/mysql/connect-external-app#appaccessIP
In a new GCP project, enable the required GCP services and APIs, and deploy
the necessary production resources. is the right answer.
This aligns with Google's recommended practices. By creating a new project, we achieve
complete isolation between test and production environments; as well as isolate this
production application from production applications of other departments.
Ref: https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-
organizations#define-hierarchy
Synchronize data within your LDAP server with Google Cloud Directory Sync.
Use secure LDAP to authenticate the legacy application and ask users to sign in
through Gmail.
(Correct)
Modify the legacy application to use SAML and ask users to sign in through Gmail.
(Incorrect)
Modify the legacy application to use OAuth 2.0 and ask users to sign in through
Gmail.
Explanation
Modify the legacy application to use SAML and ask users to sign in through
Gmail. is not right.
Modifying a legacy application to use SAML can be quite challenging. In any case, this is
a time consuming and error-prone task and is very expensive.
Modify the legacy application to use OAuth 2.0 and ask users to sign in
through Gmail. is not right.
Modifying a legacy application to use OAuth 2.0 can be quite challenging. In any case,
this is a time consuming and error-prone task and is very expensive.
Synchronize data within your LDAP server with Google Cloud Directory Sync. is
not right.
This option isn't going to help with the legacy LDAP protocol authentication unless the
application is modified to work with either Cloud Identity or GSuite. And your company
is looking for a cost-effective solution while minimizing developer effort, so this isn't
suitable.
Use secure LDAP to authenticate the legacy application and ask users to sign
in through Gmail. is the right answer.
Secure LDAP enables authentication, authorization, and user/group lookups for LDAP-
based apps and IT infrastructure. Secure LDAP uses the same user directory for both
SaaS and LDAP-based applications, so people can use the same Cloud Identity
credentials they use to log in to services like G Suite and other SaaS apps as they do to
log into traditional applications. Applications and IT infrastructure that use LDAP can be
configured to leverage Cloud Identity’s secure LDAP service instead of an existing legacy
identity system—end-users don't have to change how they access their apps.
Ref: https://cloud.google.com/blog/products/identity-security/cloud-identity-now-
provides-access-to-traditional-apps-with-secure-ldap
Retrieve the information from Cloud Logging console by filtering admin activity
logs for Cloud Spanner IAM roles.
(Correct)
Retrieve the details from the policies section in the IAM console by filtering for
Cloud Spanner IAM roles.
(Incorrect)
Retrieve the information from Cloud Monitoring console by filtering data logs for
Cloud Spanner IAM roles.
Explanation
Retrieve the information from Cloud Monitoring console by filtering data
logs for Cloud Spanner IAM roles. is not right.
Monitoring collects metrics, events, and metadata from Google Cloud and lets you
generate insights via dashboards, charts, and alerts. It can't provide information on
when a role has been granted to a user.
Ref: https://cloud.google.com/monitoring/docs
Retrieve the details from the policies section in the IAM console by
filtering for Cloud Spanner IAM roles. is not right.
You can't find the role bindings and the timestamps in the policies.
https://cloud.google.com/iam/docs/overview
{
action: "ADD"
role: "roles/spanner.admin"
member: "user:[email protected]"
}
Move to BigQuery flat rate and purchase the required number of query slots.
(Correct)
Create a separate GCP project for each department and configure billing settings
on each project to pick up the costs for queries ran by their analytics team.
Separate the data of each department and store it in BigQuery in their GCP
project.
(Correct)
Replicate the data in all GCP projects & have each department query data from
their GCP project instead of the central BigQuery project.
Explanation
Once your data is loaded into BigQuery, you are charged for storing it. Storage pricing is
based on the amount of data stored in your tables when it is uncompressed. BigQuery
doesn't charge for the query execution based on the output of the query (i.e. bytes
returned) but on the number of bytes processed (also referred to as bytes read or bytes
scanned) to arrive at the output of the query. You are charged for the number of bytes
processed whether the data is stored in BigQuery or in an external data source such as
Cloud Storage, Google Drive, or Cloud Bigtable. On-demand pricing is based solely on
usage. You are charged for the bytes scanned even if your query itself doesn't return
any data.
Ref: https://cloud.google.com/bigquery/pricing
Create a separate GCP project for each department and configure billing
settings on each project to pick up the costs for queries ran by their
analytics team. is not right.
The bytes scanned is not expected to go down by splitting the users into multiple
projects so this wouldn't reduce/control the costs.
Ref: https://cloud.google.com/bigquery/pricing
Replicate the data in all GCP projects & have each department query data
from their GCP project instead of the central BigQuery project. is not right.
Creating separate copies of the BigQuery data warehouse for each business unit is
going to increase your costs. Not only is this expected to reduce the bytes scanned, but
this is also going to increase the storage costs as we are now storing double the amount
of data.
Ref: https://cloud.google.com/bigquery/pricing
Separate the data of each department and store it in BigQuery in their GCP
project. is the right answer.
By splitting the dataset into multiple datasets per department, the bytes scanned during
the query execution is smaller and this significantly reduces the costs. Splitting the data
might actually result in duplicating some data across multiple data sets, but as pointed
out in the Big Cost Optimization article, the storage costs are insignificant compared to
the data retrieval costs.
Ref: https://cloud.google.com/bigquery/pricing
Ref: https://cloud.google.com/bigquery/docs/best-practices-
costs#materialize_query_results_in_stages
Move to BigQuery flat rate and purchase the required number of query
slots. is the right answer.
This pricing option is best for customers who desire cost predictability. Flat-rate
customers purchase dedicated resources for query processing and are not charged for
individual queries. BigQuery offers flat-rate pricing for customers who prefer a stable
cost for queries rather than paying the on-demand price per TB of data processed. You
can choose to use flat-rate pricing using BigQuery Reservations. When you enrol in flat-
rate pricing, you purchase slot commitments - dedicated query processing capacity,
measured in BigQuery slots. Your queries consume this capacity, and you are not billed
for bytes processed. If your capacity demands exceed your committed capacity,
BigQuery will queue up slots, and you will not be charged additional fees.
Ref: https://cloud.google.com/bigquery/pricing#flat_rate_pricing
Have your operations engineer execute a script in Cloud Shell to export this
information to Cloud Storage every day just before midnight.
Use gcloud to set up two gcloud configurations – one for each project. Write a
script to activate the development gcloud configuration, retrieve the list of
compute engine instances, then activate production gcloud configuration and
retrieve the list of compute engine instances. Schedule the script using cron.
(Correct)
Have your operations engineer export this information from GCP console to Cloud
Datastore every day just before midnight.
Use gsutil to set up two gcloud configurations – one for each project. Write a
script to activate the development gcloud configuration, retrieve the list of
compute engine instances, then activate production gcloud configuration and
retrieve the list of compute engine instances. Schedule the script using cron.
Explanation
Have your operations engineer execute a script in Cloud Shell to export this
information to Cloud Storage every day just before midnight. is not right.
You want an automated process, but this is a manual activity that needs to be executed
daily.
Have your operations engineer export this information from GCP console to
Cloud Datastore every day just before midnight. is not right.
You want an automated process, but this is a manual activity that needs to be executed
daily.
Use gsutil to set up two gcloud configurations – one for each project. Write
a script to activate the development gcloud configuration, retrieve the list
of compute engine instances, then activate production gcloud configuration
and retrieve the list of compute engine instances. Schedule the script using
cron. is not right.
The gsutil config command applies to users who have installed gsutil as a standalone
tool and is used for obtaining access credentials for Cloud Storage and writes a
boto/gsutil configuration file containing the obtained credentials along with several
other configuration-controllable values.
Ref: https://cloud.google.com/storage/docs/gsutil/commands/config
It is not used for creating gcloud configurations. You use gcloud config to do that.
https://cloud.google.com/sdk/gcloud/reference/config/configurations/create
Use gcloud to set up two gcloud configurations – one for each project. Write
a script to activate the development gcloud configuration, retrieve the list
of compute engine instances, then activate production gcloud configuration
and retrieve the list of compute engine instances. Schedule the script using
cron. is the right answer.
You can create two configurations - one for the development project and another for
the production project. And you do that by running "gcloud config configurations
create" command.
https://cloud.google.com/sdk/gcloud/reference/config/configurations/create
In your custom script, you can load these configurations one at a time and execute
gcloud compute instances list to list Google Compute Engine instances in the project
that is active in the gcloud configuration.
Ref: https://cloud.google.com/sdk/gcloud/reference/compute/instances/list
Once you have this information, you can export it in a suitable format to a suitable
target, e.g. export as CSV or export to Cloud Storage/BigQuery/SQL, etc.
Disable G Suite Sign in, enable Cloud Identity Sign in, and add their email address
to Cloud Identity. Grant the necessary roles to the Cloud Identity account.
(Correct)
Run G Suite to Cloud Identity migration tool to convert G Suite Accounts into
Cloud Identity accounts. Grant the necessary roles to the Cloud Identity account.
(Incorrect)
Explanation
Assign the necessary roles to their G Suite email address. is the right answer.
You can use Cloud Identity or G Suite to create and manage users in GCP
Ref: https://cloud.google.com/iam/docs/faq
Since all users in the organization already have a G Suite account, we should grant the
roles to their G Suite email addresses for users that need access to GCP services.
(Correct)
Explanation
Execute gcloud builds submit --tag gcr.io/gcr_proj/tranquillity from Cloud
shell. is not right.
This command tags the image as tranquillity:latest, but we want to tag the image as
tranquillity:v1.
Ref: https://cloud.google.com/sdk/gcloud/reference/builds/submit
Execute gcloud builds submit --tag gcr.io/app_prod/tranquillity from Cloud
shell. is not right.
This command tags the image as tranquillity: latest, but we want to tag the image as
tranquillity:v1. This command also uploads the image to the wrong project.
Ref: https://cloud.google.com/sdk/gcloud/reference/builds/submit
Update the SAML integrations on the existing third-party apps to use Google as
the Identity Provider (IdP).
Enable OAuth 2.0 with Okta OAuth Authorization Server for desktop and mobile
applications.
Enable OAuth 2.0 with Okta OAuth Authorization Server for web applications.
Configure a SAML SSO integration with Okta as the Identity Provider (IdP) and
Google as the Service Provider (SP).
(Correct)
Explanation
Update the SAML integrations on the existing third-party apps to use Google
as the Identity Provider (IdP). is not right.
The question states that you want to use the company's existing Identity provider for
SSO, not Google.
Ref: https://cloud.google.com/identity/solutions/enable-sso
Enable OAuth 2.0 with Okta OAuth Authorization Server for desktop and mobile
applications. is not right.
OAuth 2.0 credentials are needed for an OAuth 2.0 flow, not SAML flow.
See https://oauth.net/2/ for more information about OAuth 2.0, which is quite a popular
protocol for SSO. Enabling OAuth 2.0 for mobile and desktop apps does not affect how
users login into GCP console.
Ref: https://cloud.google.com/identity/solutions/enable-sso
Enable OAuth 2.0 with Okta OAuth Authorization Server for web
applications. is not right.
OAuth 2.0 credentials are needed for an OAuth 2.0 flow, not SAML flow.
See https://oauth.net/2/ for more information about OAuth 2.0, which is quite a popular
protocol for SSO. Enabling OAuth 2.0 for Web apps does not affect how users login into
GCP console.
Ref: https://cloud.google.com/identity/solutions/enable-sso
Configure a SAML SSO integration with Okta as the Identity Provider (IdP)
and Google as the Service Provider (SP). is the right answer.
This option fits the requirement. You configure applications (service providers) to accept
SAML assertions from the company's existing identity provider and users in Cloud
Identity can sign in to various applications through the third-party single sign-on (SSO)
identity provider. It is important to note that user authentication occurs in the third-
party IdP, so the absence of a Gmail login is not an issue for signing in.
Ref: https://cloud.google.com/identity/solutions/enable-sso
If you have a third-party IdP, you can still configure SSO for third-party apps in the
Cloud Identity catalogue. User authentication occurs in the third-party IdP, and Cloud
Identity manages the cloud apps.
To use Cloud Identity for SSO, your users need Cloud Identity accounts. They sign in
through your third-party IdP or using a password on their Cloud Identity accounts.
(Correct)
Create a new subnet with a bigger overlapping range to automatically move all
instances to the new subnet. Then, delete the old subnet.
Create a new project and a new VPC. Share the new VPC with the existing project
and configure all existing resources to use the new VPC.
Create a new subnet with a bigger non-overlapping range. Move all instances to
the new subnet and delete the old subnet.
(Incorrect)
Explanation
Expand the subnet IP range. is the right answer.
The subnet mask of the existing subnet is 255.255.255.224, which means the max
possible addresses are 32. Therefore, the net prefix is /27, i.e. 5 bits free, so 2 to the
power of 5 is 32 IP Addresses.
As per IETF (Ref: https://tools.ietf.org/html/rfc1918), the supported internal IP Address
ranges are
A prefix of 27 is a very small subnet and could be in any of the ranges above, and all
ranges have scope to accommodate a higher prefix.
A prefix of 26 gives you 64 IP Addresses, i.e. 32 IP address more and we just need 30
more. So, expanding the subnet to a prefix of 26 should give us the required capacity.
And GCP lets you do exactly that running a gcloud command
https://cloud.google.com/sdk/gcloud/reference/compute/networks/subnets/expand-ip-
range
Add a metadata tag to the instance with key: windows-password and password as
the value, and RDP with these details.
Generate a JSON key for the default GCE service account and RDP with this key.
(Incorrect)
Explanation
Add a metadata tag to the instance with key: windows-password and password
as the value, and RDP with these details. is not right.
It is not possible to specify a windows password at the time of creating windows VM
instance. You can generate Windows passwords using either the Google Cloud Console
or the gcloud command-line tool. Alternatively, you can generate passwords
programmatically with API commands, but all these methods assume that you have an
existing windows instance.
Ref: https://cloud.google.com/compute/docs/instances/windows/creating-passwords-
for-windows-instances#gcloud
Generate a JSON key for the default GCE service account and RDP with this
key. is not right.
This option is not a supported method of authentication for logging into the VM. You
can generate Windows passwords using either the Google Cloud Console or the gcloud
command-line tool. Alternatively, you can generate passwords programmatically with
API commands.
Ref: https://cloud.google.com/compute/docs/instances/windows/creating-passwords-
for-windows-instances#gcloud
Ref: https://cloud.google.com/compute/docs/instances/windows/creating-passwords-
for-windows-instances#gcloud