Professional Cloud Security Engineer
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
A security engineer is configuring automated, server-to-server data ingestion from an external enterprise SaaS application (Salesforce) into Google Cloud services. The integration must synchronize enterprise records continuously in the background without interactive user authentication.
The organization's security policy defines the following requirements:
Which OAuth 2.0 configuration should the engineer implement to meet these requirements?
Configure the OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE), specify a web callback URL, and require end-user consent for every token generation request.
Configure the OAuth 2.0 Implicit Grant flow, store the returned access tokens in Cloud Storage, and assign broad administrative scopes across all resource endpoints.
Configure the OAuth 2.0 JWT Bearer flow using an asymmetric 2048-bit RSA key pair, upload the public certificate to the external client app, set permitted users to "Admin approved users are pre-authorized", and grant API and offline access scopes.
Configure the OAuth 2.0 Client Credentials flow using a generated consumer key and consumer secret, set permitted users to "All users may self-authorize", and configure full IP relaxation.
Configure the OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE), specify a web callback URL, and require end-user consent for every token generation request.
Configure the OAuth 2.0 Implicit Grant flow, store the returned access tokens in Cloud Storage, and assign broad administrative scopes across all resource endpoints.
Configure the OAuth 2.0 JWT Bearer flow using an asymmetric 2048-bit RSA key pair, upload the public certificate to the external client app, set permitted users to "Admin approved users are pre-authorized", and grant API and offline access scopes.
The OAuth 2.0 JWT Bearer Token Flow (defined in RFC 7523) provides an automated, server-to-server authentication mechanism where a client application signs a JSON Web Token (JWT) using an asymmetric private key. The target authorization server verifies the signature against a pre-registered public X.509 certificate, eliminating the need for shared static secrets or interactive user logins.
server.key) to sign authorization assertions and uploading the corresponding public certificate (server.crt) to the external application, the integration eliminates static shared secrets (client_secret), protecting against credential leaks and interception.Manage user data via APIs and refresh_token, offline_access) ensures appropriate data extraction capabilities while the refresh token policy maintains continuous synchronization until administrative revocation.Compared to symmetric client credential flows or user-interactive authorization code flows, the JWT Bearer flow provides the strongest security posture for unattended server-to-server integrations by combining public key infrastructure (PKI) with explicit administrative pre-authorization.
Configure the OAuth 2.0 Client Credentials flow using a generated consumer key and consumer secret, set permitted users to "All users may self-authorize", and configure full IP relaxation.