C. You use the Stand By option of the restore command to place the database in read-only mode and allow it to be used for query- and reporting-based activity. Recovery is used to bring a database fully online and ready for use; no further log restores can be done. No Recovery allows for further log restores to occur but doesn't allow the database to be accessed as a read-only secondary. STOPAT is only used to attain a point-in-time recovery and is not applicable in this situation. For more information, see the section "Implementing Log Shipping" and Chapter 6.
C. Site autonomy refers to one site's independence from all other sites for processing modifications. Autonomy measures the effect of a site's operation on another site. A site that has full autonomy is completely independent of all other sites, meaning that it can function without even being connected to another site. See the section "Types of Replication" for more information on autonomy and other considerations.
C. Transactional replication is a good solution when you want updated changes at the server in almost real-time. Because of the frequency of the changes, snapshot replication is not a good solution. Merge replication can be set up in a single direction but is generally used only when the publisher and subscribers make updates while connected or disconnected. See the section "Using Transactional Replication" for more details.
C. Merge replication allows the most flexibility and adds the most autonomy to the replication process, enabling the publisher and subscriber to work virtually independently. The publisher and subscriber can combine their results and updates at any time. See the section "Using Merge Replication" for more details.
B, E. Because there is no primary key and because no other changes to the database can be performed, the only alternative you can use is snapshot replication. Because the data does not need to be up-to-the-minute, a scheduled data refresh occurring overnight or during other nonpeak times is most appropriate. See the section "Using Snapshot Replication" for more details.
D. Currently, in a production environment, only one supported configuration provides automatic failover. Log shipping with a monitor is not automated failover and requires manual intervention to implement the switch. Database mirroring, though offering an automated failover solution, is not supported by Microsoft within a production environment. Merge replication has no failover mechanism at all; although one server could continue to support its own clients if one server went down, it would not handle the missing server's clients. Failover clustering is the only supported configuration. For more information, see the section "Using Failover Clustering."
B. You have to synchronize the process by using a log backup of the principal restored to the mirror database. A witness is not required to initially synchronize the databases. By setting up the endpoints, you have already configured the security as long as you have used the same service ID. Failover needs to be performed only if something goes wrong after the principal and mirror are operational. For more information see the "Using Database Mirroring" section.