How to Fix HTTP 403 Errors from Expired Signed URLs in Storage Transfer Service?

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?

Set 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 script to iterate through the TSV file and download the remaining URLs to the FUSE mount point.
Renew the TLS certificate of the HTTPS endpoint. Remove the completed files from the TSV file and rerun the Storage Transfer Service job.
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 them as separate Storage Transfer Service jobs in parallel. Source Reference Answer
Update 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 job.

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The exam tests whether you can diagnose that a 403 error on a previously working transfer means expired signed URL authorization, not TLS, checksum, or infrastructure problems.

When a Storage Transfer Service job migrating files from signed URLs starts failing with HTTP 403 errors mid-run, the signed URLs have most likely expired. The community unanimously recommends regenerating signed URLs with a longer validity period in a new TSV file and running the remaining files as parallel transfer jobs.

The most common wrong choice is option A (Cloud Storage FUSE plus a shell script) because it looks like a practical workaround, but it abandons the managed Storage Transfer Service, does not scale to large migrations, and still fails once the signed URLs expire.

Community Discussion (6 comments)

raaad 👍 7 Selected: C

It addresses the likely issue: that the signed URLs have expired or are otherwise invalid. By creating a new TSV file with freshly generated signed URLs (with a longer validity period), you're ensuring that the Storage Transfer Service has valid authorization to access the files. - Splitting the TSV file and running parallel jobs might help in managing the workload more efficiently and overcoming any limitations related to the number of files or transfer speed.

srivastavas08 👍 6

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 them as separate Storage Transfer Service jobs in parallel. Here's why: HTTP 403 errors: These errors indicate unauthorized access, but since you verified the source system and signed URLs, the issue likely lies with expired signed URLs. Renewing the URLs with a longer validity period prevents this issue for the remaining files. Separate jobs: Splitting the file into smaller chunks and submitting them as separate jobs improves parallelism and potentially speeds up the transfer process. Avoid manual intervention: Options A and D require manual intervention and complex setups, which are less efficient and might introduce risks. Longer validity: While option B addresses expired URLs, splitting the file offers additional benefits for faster migration.

Pime13 👍 1 Selected: C

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 them as separate Storage Transfer Service jobs in parallel. The HTTP 403 errors likely occurred because the signed URLs expired before the transfer could complete. By generating new signed URLs with a longer validity period, you can ensure that the URLs remain valid for the duration of the transfer. Splitting the TSV file into smaller files and submitting them as separate jobs can help manage the load and reduce the risk of timeouts or other issues

iooj 👍 2 Selected: C

got this one on the exam, aug 2024, passed

Matt_108 👍 3 Selected: C

Option C - agree with Raaad

scaenruy 👍 2 Selected: C

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

Signed URLs embed an expiration timestamp, and a TSV-based URL list transfer can run for hours on a large file set. The job worked initially, then failed with HTTP 403 on the remaining objects, which is the classic signature of signed URLs expiring while the transfer was still running — 403 means the request's authorization is no longer accepted. Since the source system was verified unchanged, expired credentials are the only remaining root cause. Option C fixes this directly by regenerating signed URLs with a longer validity period for the remaining files, and splitting the TSV into smaller files run as parallel jobs shortens each job's runtime so URLs are less likely to expire again. Community comments unanimously support C, with a 100% vote share.

Why the Other Options Are Wrong

Option A replaces Storage Transfer Service with a manual Cloud Storage FUSE mount and shell script; it is an unmanaged workaround that does not scale for large migrations and, critically, does nothing about the expired signed URLs, so downloads would still fail with 403. Option B blames the TLS certificate, but certificate problems produce TLS handshake or connection errors, not HTTP 403, which is an application-level authorization failure. Option D changes checksums from MD5 to SHA256, but checksums govern data integrity verification, not access authorization, and a checksum mismatch would surface as a different error, not 403 Forbidden. None of A, B, or D addresses the authorization expiry that the logs point to.

Community Comment Notes

Comment [1] (7 likes) articulates the core reasoning: freshly generated signed URLs with a longer validity period restore valid authorization, and splitting the TSV improves workload management. Comment [2] (6 likes) confirms that 403 indicates unauthorized access due to expired signed URLs given the source system was unchanged. Comment [3] reports seeing this exact question on the August 2024 exam and passing, validating C as the current expected answer. The vote distribution is 100% for C with no dissenting options proposed in the comments.

Official Reference

Exam Strategy

When a transfer that ran fine starts failing with HTTP 403, immediately think 'authorization expired,' not infrastructure or integrity. Signed URLs are time-limited, so long-running jobs can outlive the URLs listed in the TSV file. Choose the answer that fixes the root cause inside the managed service — regenerate URLs with longer validity and parallelize — over manual workarounds like FUSE mounts or shell scripts.

Related Analysis

← Back to PDE Study Guide