Question

Difficulty: Very hardSecrets Management and Service Account Lifecycle Security

An enterprise financial institution is auditing its Google Cloud security posture to enforce strict service account lifecycle governance and credential protection. The security team discovered that developers are generating downloadable JSON service account keys for local debugging and using primitive IAM roles across multi-project environments. Furthermore, a legacy application on Compute Engine instances requires access to sensitive third-party API credentials stored in Secret Manager, with an organizational mandate to enforce automated secret rotation and prevent key exfiltration. Which TWO security controls and architecture pattern changes should you implement to satisfy these compliance mandates while adhering to Google-recommended practices? (Select TWO.)

  1. Enforce the IAM organization policy constraint `iam.disableServiceAccountKeyCreation` at the organization level, and configure Workload Identity Federation or service account impersonation using short-lived credentials for developer access.Answer
  2. B
    Grant developers the Service Account Admin role (`roles/iam.serviceAccountAdmin`) on the project level so they can manage service account credentials without creating raw key files.
  3. Configure Secret Manager with Cloud Pub/Sub topics to trigger Cloud Functions for automated secret version rotation, and grant the Cloud Run/Function service account Secret Manager Secret Accessor permissions on the target secret.Answer
  4. D
    Assign the primitive Owner role (`roles/owner`) to the compute service accounts executing the rotation functions to ensure uninhibited access across all storage resources and third-party APIs.
  5. E
    Deploy Customer-Supplied Encryption Keys (CSEK) for Secret Manager secrets to eliminate the need for Google Cloud KMS key lifecycle management and automatic IAM policy checks.

Answer

Enforce the IAM organization policy constraint `iam.disableServiceAccountKeyCreation` while providing developers short-lived credentials via service account impersonation, and automate Secret Manager secret rotation using Pub/Sub notifications paired with Cloud Functions configured with fine-grained Secret Manager roles.
Enforcing the `iam.disableServiceAccountKeyCreation` organizational policy mitigates credential leakage risks by meangingfully preventing the creation of long-lived JSON keys, pushing developers toward short-lived credentials via service account impersonation. Additionally, coupling Secret Manager with Pub/Sub topics and Cloud Functions enables automated end-to-end credential rotation using fine-grained Cloud IAM roles.

Step-by-Step Solution

1
Analyze service account key compliance requirements
Identify that downloading long-lived JSON keys creates significant security risks and violates organizational governance.
Preventing service account key creation via organizational policy `iam.disableServiceAccountKeyCreation` forces developers to adopt secure identity delegation mechanisms such as short-lived IAM credentials and Workload Identity.
2
Evaluate automated secret lifecycle management
Determine the Google Cloud recommended secret rotation mechanism.
Secret Manager natively integrates with Cloud Pub/Sub to trigger automated rotation workflows via Cloud Functions or Cloud Run, maintaining secret freshness while leveraging least-privilege IAM roles like `roles/secretmanager.secretAccessor`.
3
Eliminate antipatterns and primitive role usage
Reject primitive IAM roles and CSEK configurations.
Primitive roles grant excessive privileges, and CSEK is not supported for Secret Manager, whereas CMEK or standard Secret Manager encryption with Cloud KMS is the proper architecture.

Key Concept

Service Account Lifecycle Hardening and Secret Manager Automated Rotation Architecture
Rate this question