How to enforce 24-hour service account keys in a centralized project?
Short answer
C Enforce the iam.serviceAccountKeyExpiryHours org policy at 24 hours and deny service account key creation everywhere except pj-sa.
Question
You recently discovered that your developers are using many service account keys during their development process. While you work on a long term improvement, you need to quickly implement a process to enforce short-lived service account credentials in your company. You have the following requirements: • All service accounts that require a key should be created in a centralized project called pj-sa. • Service account keys should only be valid for one day. You need a Google-recommended solution that minimizes cost. What should you do?
Key Takeaways
The question tests org policy enforcement of service account key lifetime and creation; the trap is choosing a rotation job that automates keys but does not cap their lifetime.
Enforcing short-lived service account credentials means combining a 24-hour key-expiry constraint with a key-creation denial scoped to all projects except pj-sa. The page confirms option C as the Google-recommended, cost-minimal enforcement path.
Common mistake: Choosing a Cloud Run or Kubernetes rotation job (A or B) because it sounds automated, even though rotation does not guarantee any key expires within 24 hours.
Expert Analysis
Why the Answer Is Correct
Option C applies theiam.serviceAccountKeyExpiryHours org policy constraint at 24 hours, which caps every service account key lifetime at one day, and combines it with the iam.disableServiceAccountKeyCreation constraint excepted on pj-sa. That pairing forces all newly created keys into the centralized project while ensuring any key that exists there expires within the required 24-hour window. This is a native Organization Policy enforcement mechanism, so it avoids custom rotation code and extra runtime cost, matching the Google-recommended and minimal-cost requirements. It directly satisfies both stated requirements without relying on periodic jobs or manual processes.Why the Other Options Are Wrong
Option A includes the correct key-creation denial with apj-sa exception, but its Cloud Run rotation job does not enforce a maximum key lifetime; a key could remain valid longer than 24 hours between rotations and the job adds operational cost. Option B relies on a Kubernetes CronJob and disables service account attachment instead of capping key expiry, so it neither centralizes key creation in pj-sa nor guarantees one-day credentials. Option D attempts a DENY org policy over key lifetime, but the iam.serviceAccountKeyExpiryHours constraint does not support DENY values, and disabling service account attachment is unrelated to key lifetime enforcement.Community Comment Notes
Several learners, including qannik and joao_01, converge on option C because it uses org policy to enforce a 24-hour key lifetime and to deny key creation outsidepj-sa. niedobry adds a decisive technical point: the expiry constraint "does not accept DENY values," which rules out option D. scanner2 points readers to the official restricting-service-accounts documentation for both the key-expiry limit and key-creation disablement. One commenter argued for option A, but that approach only rotates keys and does not actually guarantee the one-day expiry requirement. Official Reference
Exam Strategy
When a question asks for a Google-recommended, low-cost way to enforce service account key lifetime, prioritize built-in org policy constraints over custom rotation pipelines. Look for the two controls: maximum key expiry hours and key-creation denial with a project exception.
Frequently Asked Questions
Why can't I use a DENY org policy for service account key expiry?
The iam.serviceAccountKeyExpiryHours constraint does not accept DENY values, so option D is invalid at the policy level. Use the supported expiry-hours constraint instead.
Does a Cloud Run rotation job enforce a 24-hour key lifetime?
No; rotation creates replacement keys on a schedule but does not cap each key's lifetime, and it adds runtime cost, so option A misses the enforcement requirement.
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 7
-
qannik 👍 5 Answered CYou can use an org policy to enforce a 24-hour lifetime for service account keys. You can use an org policy to deny service account key creation, with an exception for the pj-sa project. This is a Google-recommended solution and it is relatively inexpensive.
-
scanner2 👍 3 Answered CC is correct. https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#limit_key_expiry https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts#disable_service_account_key_creation
-
niedobry 👍 3Answer is C. Constraint: constraints/iam.serviceAccountKeyExpiryHours does not accept DENY values so D can not be correct.
-
Captain1212 👍 3c is the coorect answer
-
joao_01 👍 3 Answered CIts C, makes sense
Show 2 more comments
-
3arle 👍 3 Answered Cit should be C
-
838f01a 👍 1 Answered AWhy A is correct The requirements are: Service account keys should only exist in a centralized project pj-sa. Keys should be short-lived (1 day). Use a Google-recommended approach. Minimize cost. A practical solution is: Enforce the organization policy that disables service account key creation across the organization, with an exception for pj-sa. Use a lightweight, serverless mechanism (such as a Cloud Run Job) to automatically: Create replacement keys. Delete keys older than 24 hours. Run on a schedule. This gives centralized control and keeps costs low because Cloud Run only incurs charges when the job executes.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All ACE Questions
Access 84 questions with complete answers and detailed explanations.
View Full ACE Practice Test →