Pular para o conteúdo

Simulado · GCP

Simulado Google Cloud Professional Cloud Security Engineer

50
questões
120
minutos
70%
para passar no simulado
59
questões no banco

Resposta curta

O simulado de Google Cloud Professional Cloud Security Engineer tem 50 questões em 120 minutos, com nota de corte de 70%, conforme configurado aqui. O jeito mais rápido de saber se você está pronto é fazer uma prova completa no relógio e ler a nota por domínio, não só o total.

Domínios cobrados

  • Configuring Network Security
  • Ensuring Compliance
  • Managing Identity and Access Management
  • Managing Operations
  • Ensuring Data Protection

Questões de exemplo, com explicação

Três questões do banco, abertas para ler.

Questão 1 · Managing Identity and Access Management

An application running on a GKE workload in project-app needs to read objects from a bucket in project-data. The platform team wants the pod to authenticate as a dedicated Google service account, scoped to only that bucket, with no service account keys mounted into the cluster. Which configuration correctly achieves keyless, least-privilege access?

  1. Create a service account key for the Google service account and mount it as a Kubernetes Secret in the pod, granting the account roles/storage.admin at the project level.
  2. Assign the GKE node's default Compute Engine service account roles/storage.objectViewer at the organization level so every pod inherits the access.
  3. Use the node's metadata server with the default service account and grant it roles/editor on project-data so the pod can read the bucket.
  4. Enable GKE Workload Identity, bind the Kubernetes service account to the Google service account via the iam.workloadIdentityUser role, and grant that Google service account roles/storage.objectViewer on the target bucket only. ✓ (correta)
Por que esta é a correta

GKE Workload Identity maps a Kubernetes service account to a Google service account through the iam.workloadIdentityUser binding, providing keyless authentication; granting roles/storage.objectViewer on just the bucket satisfies least privilege. Mounting a service account key as a Secret reintroduces a static credential the team explicitly wants to avoid, and roles/storage.admin at project level is far broader than read access. Granting the node's default service account objectViewer at the org level shares one identity across all pods (no per-workload isolation) and over-scopes to the entire organization. Using the default service account with roles/editor on the project both fails to isolate the workload and grants sweeping write/modify permissions, violating least privilege.

Questão 2 · Configuring Network Security

A SaaS provider hosts a database service inside its own VPC (the 'producer'). A customer wants applications in their separate VPC (the 'consumer') to connect to that service using a private internal IP in the consumer's address space, without VPC peering, without exposing the service to the internet, and with no risk of overlapping CIDR ranges between the two VPCs. Which mechanism satisfies all of these constraints?

  1. Establish VPC Network Peering between the consumer and producer VPCs and rely on internal routing to reach the database
  2. Use Private Service Connect: the producer publishes a service attachment and the consumer creates a PSC endpoint (forwarding rule) with an internal IP in their own VPC that maps to the producer's service ✓ (correta)
  3. Expose the database behind an internal TCP load balancer in the producer VPC and share it via Shared VPC with the consumer project
  4. Deploy a Cloud VPN tunnel between the two VPCs and advertise the database subnet over BGP using Cloud Router
Por que esta é a correta

Private Service Connect (PSC) is purpose-built for private service producer/consumer connectivity: the consumer gets an endpoint with an internal IP from their OWN VPC's range mapped to the producer's published service attachment, with no VPC peering and therefore no requirement that CIDR ranges be non-overlapping — which directly satisfies every constraint. VPC Network Peering would create direct routing between the VPCs but requires non-overlapping CIDR ranges and merges routing/visibility between the two networks, violating the 'no overlap risk' and isolation goals, so it is a weaker fit. A Cloud VPN tunnel with Cloud Router also requires non-overlapping advertised ranges, adds tunnel/BGP overhead, and is intended for hybrid or cross-network IP connectivity rather than publishing a managed service privately. Shared VPC is an organizational construct for sharing one VPC across projects within the same org; it does not connect two independent VPCs (a third-party SaaS producer and a customer) and does not solve the overlap or service-publishing problem.

Questão 3 · Ensuring Data Protection

A fintech company runs a Compute Engine fleet that stores regulated customer records on Persistent Disks. The compliance team mandates that Google must never be able to decrypt the disks without the company's involvement, and that the company must hold the raw key material entirely outside Google Cloud, supplying it on every API call. They explicitly do not want Cloud KMS to store any version of their key. Which data-protection mechanism satisfies this requirement for the Persistent Disks?

  1. Customer-Managed Encryption Keys (CMEK) backed by a Cloud KMS software key with manual rotation
  2. Google's default Google-Managed Encryption Keys (GMEK) with disk-level encryption enabled
  3. Customer-Supplied Encryption Keys (CSEK), where the raw key is passed in each request and never stored by Google ✓ (correta)
  4. Cloud External Key Manager (Cloud EKM) pointing at a third-party key manager via a CMEK reference
Por que esta é a correta

CSEK is the only option where the customer supplies raw AES key material directly with each Compute Engine or Cloud Storage API request and Google never persists it, exactly matching the 'hold the key outside Google, supply it every call, KMS stores nothing' requirement. CMEK backed by a Cloud KMS software key is wrong because the key material is created and stored inside Cloud KMS, so Google does retain it (the requirement explicitly forbids KMS storing any version). Cloud EKM is wrong because, although the key material lives in an external manager, EKM is exposed through a CMEK key reference and the key is not passed raw on each request; it is fetched over a managed connection, and it is configured as a KMS key resource rather than per-call supplied material. Default GMEK is wrong because Google generates and fully controls those keys, which is the opposite of 'Google must never decrypt without the company's involvement.'

Faça o simulado completo

  • 50 questões sorteadas do banco, com cronômetro de 120 minutos
  • Nota por domínio e revisão de cada questão
  • Tutor de IA para conversar sobre cada questão que você errar
  • O que você errou alimenta seu plano de estudo
Começar simulado

Simulado independente e não oficial. GCP e o nome da prova são marcas de seus donos; o UpSkillScore não é afiliado a eles. Formato e nota de corte são a configuração do simulado no UpSkillScore, não uma declaração oficial.

Perguntas frequentes

Quantas questões tem o simulado de Google Cloud Professional Cloud Security Engineer?

Tem 50 questões e limite de 120 minutos. A nota de corte do simulado é 70%.

Este é o exame oficial de Google Cloud Professional Cloud Security Engineer?

Não. É um simulado independente, montado para espelhar a estrutura da prova real. Ele não substitui o exame oficial.

Preciso de conta para fazer?

Você lê a estrutura e as questões de exemplo sem conta. Fazer o simulado completo cronometrado, a nota por domínio e o tutor de IA exigem conta.