Cloud Digital Leader Trust and security with Google Cloud Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use the same SSH key for all Compute Engine instances.

  Why it's wrong here

  Sharing a single SSH key across all Compute Engine instances collapses access management into one point of failure; if the private key is exfiltrated, every instance is compromised. It also prevents per-user accountability, since use of the shared key cannot be traced to an individual person, and forces a blanket rotation for all instances even if only one user leaves. Best practice is to use unique keys per user or integrate with OS Login / Cloud IAP to provide identity-based access.

• ✓

  Grant minimal permissions to users and services using IAM roles.

  Why this is correct

  IAM roles provide granular, auditable control over who can perform specific actions on specific resources, and granting only the minimum permissions needed (least privilege) contains the blast radius of a compromised account or service. Predefined roles like roles/viewer or custom roles with targeted permissions allow you to align access with actual job duties, reducing the chance of accidental or malicious damage. This is a cornerstone of Google Cloud security and is far more effective than managing broad permissions or long-lived credentials.

• ✗

  Export service account keys and use them in on-premises applications for authentication.

  Why it's wrong here

  Exporting service account keys converts a managed cloud identity into a static, long-lived secret that remains valid until manually rotated. Distributing that key to on-premises systems expands the trust boundary far beyond GCP, making it difficult to control access or revoke privileges if the external environment is breached. Google recommends avoiding the creation and export of service account keys entirely, and instead using workload identity federation or short-lived OAuth tokens to authenticate on-premises workloads.

• ✗

  Rotate service account keys every month.

  Why it's wrong here

  Monthly key rotation is not a universal or sufficient security practice; the real risk is the existence of long-lived static keys, regardless of how frequently they are replaced. A rotated key may still have been leaked, and rotation only protects against future misuse—it does not detect or neutralize an active compromise. Modern GCP best practice is to avoid the use of service account keys altogether by leveraging workload identity federation or auto-rotated, short-lived credentials, which eliminate the need for manual rotation schedules.

• ✓

  Enable VPC Flow Logs for all subnets.

  Why this is correct

  VPC Flow Logs capture per-interface metadata about IP traffic within and into your VPC, recording source/destination, protocol, ports, and packet counts. Enabling them for all subnets gives your security team comprehensive visibility for detecting anomalies like port scans, data exfiltration, or lateral movement, and provides an evidence trail for forensic analysis and compliance audits. While there is a cost for log ingestion and storage, the security value of having full network telemetry generally outweighs that overhead.

Go deeper

Related to this question