I have a cron job that needs to use the root password. I can enter the root password into the actual crontab entry but my concern is:

1- does cron use a file to store jobs?
2- if it does, is the crontab file encrypted or not?

If cron uses a file and it is encrypted then I feel comfortable having the root password stored in root's cron file (since you have to be root to access the cron file anyways).

However, if the crontab file is not encrypted then I don't feel comfortable storing the password in the crontab. If this is the situation, what are secure alternatives to utilizing the root password in automated jobs?

The crontab file is NOT encrypted.

In most cases, each user on the system has access to their own crontab. If you su to root and do a crontab -e, this will be roots crontab file. Another solution is just placing the sh script ( or whatever language ) in the /etc/cron.hourly directory. You should not script any passwords in any script, nor should you have to. Each crontab is run as that user. I usually use the cron directories on linux, but on other unix boxes, they don't usually have them. If you want to see the setup of the crontab file do a: man -S 5 crontab

Another situation that I have is I want to do a master mysqldump of all of my tables. I already have a working script that will do it. However, that script requires the password to be typed into the actual command that is run. I know that the Linux root password is not the same as the MySQL password but the problem is the same. I don't want to have the password to a MySQL user, that has access to every table, written in a plain text file.

Is there a way to do this securely?

How about creating a mysql user that only has sufficient permissions to run mysqldump? That way if the password escaped into the wild, no real damage could occur.

This kind of thing should be avoided if possible. However if you really must have this user have passwordless root priveleges and you have to set it up in sudo:
#visudo
or (avoid this if possible as it basically gives that user full root priveleges)

Actually sudo may not be applicable to this particular problem. The users we are talking about are mysql users, which are not the same thing as system users and sudo doesn't work with mysql users.