A customer's internal security team must manage its own encryption keys for encrypting data on Cloud Storage and decides to use customer-supplied encryption keys (CSEK). How should the team complete…

Question

Options

• AUpload the encryption key to a Cloud Storage bucket, and then upload the object to the same
• BUse the gsutil command line tool to upload the object to Cloud Storage, and specify the location
• CGenerate an encryption key in the Google Cloud Platform Console, and upload an object to Cloud
• DEncrypt the object, then use the gsutil command line tool or the Google Cloud Platform Console

• A
  3% (1)
• B
  71% (22)
• C
  16% (5)
• D
  10% (3)

Explanation

Option B is correct because CSEK requires you to provide your own AES-256 key at the time of the upload operation - gsutil supports this via the -o flag (specifying your key in a .boto config or via --encryption-key), and Google uses the key to encrypt the object server-side but never stores the key itself.

Why the others are wrong:

• A is a critical security mistake - uploading your encryption key to Cloud Storage defeats the entire purpose of CSEK; Google would then control the key.
• C is incorrect because CSEK keys are not generated in the GCP Console; Google never generates or manages CSEK keys - you generate them yourself, externally.
• D describes client-side encryption before upload, which is a different pattern entirely (not CSEK). CSEK means Google performs the encryption server-side using your supplied key - you don't pre-encrypt the object yourself.

Memory tip: Think of CSEK as "Bring Your Own Key to the upload call." The key travels with the request (not stored anywhere in GCP), so the only correct workflow is specifying it at upload time via gsutil or the API - never stored in a bucket, never generated by Google.

No community discussion yet for this question.