DRAG DROP
You administer several Microsoft SQL Server 2012 servers. Your company has a number of
offices across the world connected by using a wide area network (WAN).
Connections between offices vary significantly in both bandwidth and reliability.
You need to identify the correct replication method for each scenario.
What should you do? (To answer, drag the appropriate replication method or methods to the
correct location or locations in the answer area. Each replication method may be used once,
more than once, or not at all.)
Answer: 
Explanation:
http://msdn.microsoft.com/en-us/library/ms151198.aspx
I guess:
– Last scenario is one publisher, many subscribers (reporting databases), so transactional replication
– First Scenraio (many publishers/subscribers), so Merge replication, low latency can’t peer2peer.
– Second and third scenarios,snapshot.
Scenario 1: I would say it is Peer to peer do to the fact: That Peer-to-peer publication is suitable when all subscribers must be able to perform updates, and data has been partitioned to ensure that conflicts do not occur. While I was thinking of Merge replication as well, but Merge publication is suitable when subscribers might be offline but must be able to accept and forward updates to the publisher while having a robust conflict resolution mechanism. hence I would go for peer to peer here.
Scenario 2: you are correct Snapshot.
Scenario 3: it was tempting to go with snapshot again but, Snapshot replication is suitable when the database you will make available in multiple locations has the majority of its updates occur over a short period and the fact that Snapshot replication is unidirectional and does not support updates from subscribers. So second temptation would be peer to peer, as Slazenjer_m mentioned the keyword(s) “unreliable connection” makes merge the best candidate since Merge publication is suitable when subscribers “might be offline” – (could be an unreliable connection) but must be able to accept and forward updates to the publisher while having a robust conflict resolution mechanism.
And Scenario 4: transaction: Transactional publication is suitable when subscribers must be kept up to date with constant changes that occur on the publisher.
Resource: Training Kit (Exam 70-462): Administering Microsoft SQL Server 2012 Databases
BlackCat is not right…
check out https://technet.microsoft.com/en-us/library/cc966404.aspx for the first scenario.
For the third scenario check out: https://msdn.microsoft.com/en-us/library/ms152746.aspx
“Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred.”
@BlackCat: Do you have an understanding of what “latency” means?! Latency is a time interval between ‘querying’ and ‘response’; or, from a more general point of view, the timed delay between “a cause and its effect.”
Hence, Low-latency implies there is little or no processing delay within the subnet…
1.So, scenario 1 is very much a Peer-to-Peer Replication scenario.
2. Scenario 3 is a Merge Replication scenario.
3. The second scenario is Snapshot; last one is Transactional.
Also, for very unreliable connections, where the network clients may experience ‘timeout errors’, MERGE Replication works best because you can always reduce the occurrence of these timeout errors by configuring {Subscriber Merge Agents} to utilize “Slow Link Agent Profiles.”
A low latency connection allows for peer to peer, but why does it necessarily preclude merge transactions
https://technet.microsoft.com/en-us/library/ms152565(v=sql.105).aspx
This was completely useless. It differentiates between merge and peer to peer two ways
peer to peer will update a subscriber for every single transactions, not just the net transaction
merge transaction is typically between an server and an updateable client. None of these scenarios has an updateable client