What should you do?

Your company has an Active Directory domain.
All the servers in the company run either Windows Server 2008 R2 or Windows Server 2003.
A Windows Server 2003 server named Server1 runs Microsoft SQL Server 2005 SP2 and Microsoft Windows SharePoint Services (WSS) 2.0.
The company plans to migrate to WSS 3.0 SP2 on a Windows Server 2008 R2 server named Server2.
You need to migrate the configuration and content from Server1 to Server2.
What should you do?

A.
Back up the SharePoint configuration and content from Server1. Install WSS 3.0 SP2 on Server2.
Restore the backup from Server1 to Server2.

B.
Upgrade Server1 to Windows Server 2008 R2. Back up the SharePoint configuration and content from Server1. Install WSS 3.0 SP2 on Server2. Restore the backup from Server1 to Server2.

C.
Back up the SQL Server 2005 configuration and the WSS 2.0 databases from Server1. Install SQL Server 2005 on Server2. Restore the SQL Server 2005 backup from Server1 to Server2.

D.
Back up the WSS 2.0 configuration and content from Server1. Install WSS 2.0 on Server2. Restore the backup from Server1 to Server2. Perform an in-place upgrade of WSS 2.0 to WSS 3.0 SP2 on Server2.

Explanation:
Install and configure Windows SharePoint Services for an in-place upgrade
When you run an in-place upgrade, all content and configuration data is upgraded in-place, at one time. When you start the in-place upgrade process, the Web server and Web sites remain offline until the upgrade has been installed. When you perform an in-place upgrade, you cannot pause or roll back to the previous version.
Upgrade is a detailed and complicated operation. Even in relatively basic environments, there may be customizations that do not lend themselves to a smooth and simple upgrade. These customizations, and many other variables, are outside of the control of the upgrade process and may cause the in-place upgrade to fail.
We recommend in-place upgrade only for a stand-alone server and even then, in limited situations. In general, this means that you should consider in-place upgrade for environments that meet both of the following conditions:
* Small installations
* Environments that have not been customized
In practice, this means that you should only use in-place upgrade in environments where there is minimal impact when a server is down. Examples include development, test, or staging servers where you need a quick upgrade experience and can quickly roll back the entire server to an earlier configuration. For example, in a virtualized environment, if something goes wrong with the upgrade, you can discard the undo disks and, in minutes, be back to your original environment. Another option to avoid having to troubleshoot a failed upgrade is to restore your server from a backup.
Source: http://technet.microsoft.com/en-us/library/cc288753.aspx