On-Premises Applications Accessing Google Cloud Without Hardcoded Credentials?
Your organization has a centralized identity provider that is used to manage human and machine access. You want to leverage this existing identity management system to enable on-premises applications to access Google Cloud without hard coded credentials. What should you do?
Community Votes
83% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The exam tests your ability to distinguish between human and machine identity federation, with the common trap being misreading applications as requiring workforce solutions.
This question tests the distinction between Workload and Workforce Identity Federation for secure cloud access. Community consensus confirms Workload Identity Federation is correct for non-human application access.
Option B is frequently chosen because test-takers overlook the word applications and incorrectly assume any centralized identity provider integration requires Workforce Identity Federation.
Community Discussion (6 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Workload Identity Federation enables non-human entities like on-premises applications to exchange external tokens for short-lived Google Cloud credentials. By configuring a workload identity pool and mapping attributes from your centralized identity provider, applications can securely access Google Cloud services without managing long-term API keys or service account keys. This aligns directly with Google Cloud zero-trust architecture and eliminates hardcoded credentials entirely. As noted in the discussion, this feature is specifically designed for automated workloads rather than human users.Why the Other Options Are Wrong
Option B configures Workforce Identity Federation, which is strictly intended for human employees accessing Google Cloud via corporate SSO, not automated applications. Option A deploys Secure Web Proxy, which controls outbound web traffic but does not solve the underlying credential management problem for direct API access. Option C implements Identity-Aware Proxy, which provides application-level firewall protection and access control but does not handle external identity federation or replace hardcoded backend credentials. Each alternative addresses network security or human access patterns instead of machine identity federation.Community Comment Notes
Multiple high-voted comments emphasize the keyword applications as the deciding factor between Workload and Workforce Identity Federation. Contributors correctly point out that Workload Identity Federation handles machines while Workforce handles people, leading to a strong consensus around Option D. One dissenting comment mistakenly focused only on the word identity without considering the workload context, which was quickly outweighed by technical explanations. The voting distribution clearly reflects this shared understanding of Google Cloud IAM best practices.Official Reference
Exam Strategy
Always scan for the actor type when evaluating Identity Federation options in PCSE exams. Map humans, employees, or SSO to Workforce Identity Federation, and scripts, workloads, or on-premises apps to Workload Identity Federation to avoid costly reading comprehension traps.
Frequently Asked Questions
Why isn't Workforce Identity Federation suitable for on-premises applications?
Workforce Identity Federation is designed exclusively for human users logging into Google Cloud consoles or APIs. Applications require Workload Identity Federation to exchange machine tokens for temporary service account credentials.
Can Workload Identity Federation replace all hardcoded service account keys?
Yes, it allows workloads to request short-lived OAuth2 tokens instead of storing static JSON key files. This significantly reduces the attack surface and eliminates manual key rotation overhead.