Q:

Why does root cron job script need 'sudo' to run properly?

I'm running this simple script on my Raspberry Pi to auto update so I can forget about it. It also keeps a log that says whether the update was successful. The script is update.sh:
#!/bin/bash
echo "Update starts on: $(date)" >> /home/pi/update.log
 if apt-get update && apt-get upgrade -y; then
    echo "update successful $(date)"  >> /home/pi/update.log
 else
    echo "Couldn't update $(date)" >> /home/pi/update.log
 fi

I added this script to the root crontab by using sudo crontab -e and the cronjob is set to run every day at 6AM
0 6 * * * /home/pi/update.sh

I know that it works to some extent because running sudo ./update.sh in the shell manually runs the commands and leaves a "successful" entry in the log. On the other hand, when ran from the crontab, I always get the "couldn't update" entry. In case it matters, the "update.sh" script was created by the "pi" user and I never changed the permissions, except giving it execution permissions.
I read another question about the same problem and the guy solved it by putting a sudo in front of the command. He admits it's weird because it's already being executed by root, but says it works. I tried adding the sudo and verified it actually works now.
Does anyone know why this happens? Why does it need the sudo if it's already root?

A:

Cron runs commands from a special shell, separate from the user or root shells. This shell does not have access to the same PATH variables as users. Therefore, when running a script as a cron job there are two  options:
A. Specify the full path for every command in the script (I.e. full path to aptitude- cron doesn't know where to look to find "apt-get")
B. Little trick I use- when writing the cron job line, even in the ROOT crontab, append sudo before the script path. This will trick cron into running the script from a root shell instead of the cron shell, which will give it access to all root's PATH variables.

