DVA-C02 Troubleshooting and Optimization Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Delete the S3 bucket and restart the copy operation.

  Why it's wrong here

  Deleting the S3 bucket and restarting the copy operation is an extremely inefficient and counterproductive approach. This action would discard all previously uploaded files and the progress made before the interruption, necessitating a complete re-upload of the entire dataset. Such a strategy wastes significant network bandwidth, prolongs the overall transfer time, and is entirely unnecessary when more intelligent resume mechanisms are available.

• ✓

  Use the aws s3 sync command to synchronize the source directory with the S3 bucket.

  Why this is correct

  The aws s3 sync command is the most appropriate and efficient solution for resuming an interrupted file transfer to S3. It intelligently compares the source directory with the S3 bucket, identifying only files that are new, have changed content (based on size and modification time), or are missing from the destination. This ensures that only the necessary data is transferred, minimizing bandwidth usage and significantly reducing the time required to complete the operation.

• ✗

  Use the cp command with the --recursive flag to copy the remaining files.

  Why it's wrong here

  Using aws s3 cp --recursive to copy the remaining files after an interruption is inefficient because this command does not inherently track transfer state or skip already uploaded objects. When re-executed, it would attempt to re-upload all files from the source directory, including those that were successfully transferred before the interruption. This leads to redundant data transfer, increased network consumption, and a longer overall completion time compared to a synchronization command.

• ✗

  Increase the --cli-read-timeout value in the AWS CLI configuration and retry the original command.

  Why it's wrong here

  Increasing the --cli-read-timeout value might prevent the specific timeout error that initially interrupted the operation, but it does not address the underlying inefficiency of the aws s3 cp command for resuming transfers. Even with an extended timeout, retrying the original cp command would still attempt to re-upload all files from the source directory, including those already present in the S3 bucket. This results in redundant data transfer and does not provide an intelligent resume capability.