nerdexam
Google

PROFESSIONAL-DATA-ENGINEER · Question #390

You are migrating a large number of files from a public HTTPS endpoint to Cloud Storage. The files are protected from unauthorized access using signed URLs. You created a TSV file that contains the…

The correct answer is C. Create a new TSV file for the remaining files by generating signed URLs with a longer validity period. Split the TSV file into multiple smaller files and submit. Option C is correct because the HTTP 403 errors are caused by signed URL expiration - the transfer job ran long enough that the original signed URLs (which have a limited validity window) expired mid-job, causing the remaining files to return "Forbidden." Generating new signed…

Submitted by noor.lb· Mar 30, 2026Building and operationalizing data processing systems

Question

You are migrating a large number of files from a public HTTPS endpoint to Cloud Storage. The files are protected from unauthorized access using signed URLs. You created a TSV file that contains the list of object URLs and started a transfer job by using Storage Transfer Service. You notice that the job has run for a long time and eventually failed. Checking the logs of the transfer job reveals that the job was running fine until one point, and then it failed due to HTTP 403 errors on the remaining files. You verified that there were no changes to the source system. You need to fix the problem to resume the migration process. What should you do?

Options

  • ASet up Cloud Storage FUSE, and mount the Cloud Storage bucket on a Compute Engine instance. Remove the completed files from the TSV file. Use a shell
  • BRenew the TLS certificate of the HTTPS endpoint. Remove the completed files from the TSV file and rerun the Storage Transfer Service job.
  • CCreate a new TSV file for the remaining files by generating signed URLs with a longer validity period. Split the TSV file into multiple smaller files and submit
  • DUpdate the file checksums in the TSV file from using MD5 to SHA256. Remove the completed files from the TSV file and rerun the Storage Transfer Service

How the community answered

(26 responses)
  • A
    15% (4)
  • B
    4% (1)
  • C
    77% (20)
  • D
    4% (1)

Explanation

Option C is correct because the HTTP 403 errors are caused by signed URL expiration - the transfer job ran long enough that the original signed URLs (which have a limited validity window) expired mid-job, causing the remaining files to return "Forbidden." Generating new signed URLs with a longer validity period resolves the root cause, and splitting the TSV into smaller batches ensures each subset completes before its URLs expire.

Option A is wrong because Cloud Storage FUSE is used to mount GCS buckets as a local filesystem - it doesn't help transfer files from an external HTTPS endpoint and does nothing to fix expired signed URL authorization.

Option B is wrong because TLS certificate expiration causes SSL handshake failures or certificate errors, not HTTP 403s - the 403 is an authorization failure, which points to signed URL expiration, not a certificate issue.

Option D is wrong because MD5 vs. SHA256 checksums are for data integrity verification, not access control - changing the checksum algorithm has no effect on whether the server authorizes the request.

Memory tip: When you see signed URLs + 403 errors after a long-running job, think "the clock ran out." Signed URLs are time-bombs - they expire. The fix is always to regenerate them with a longer (or sufficient) validity window before retrying.

Topics

#Cloud Storage Transfer Service#Signed URLs#Data Migration#Troubleshooting

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full PROFESSIONAL-DATA-ENGINEER Practice