During post-deployment, a customer's network team asks whether Data Domain-to-Data Domain replication across a WAN link needs a site-to-site VPN solely to protect replication payload confidentiality. What should you recommend?
Select an answer to reveal the explanation.
Short Explanation
Think of replication as a sealed courier bag: the Data Domain pair already encrypts the payload, so the VPN isn't the lock on the contents. If your network team wants a VPN for segmentation, that's fine, but you shouldn't buy it as payload protection.
Full Explanation
Data Domain replication is a protected appliance-to-appliance data movement service. When a source DD system sends replicated data to a target DD system, DD OS applies transport-level protection to the replication stream, so the payload is not exposed as unprotected data merely because the link crosses a WAN. A site-to-site VPN can still be appropriate where policy requires private addressing, routing isolation, or a controlled boundary, but it is not the only control for replication payload confidentiality. A response that claims replication traffic is unencrypted misunderstands the data security model: the appliance pair, not the network tunnel, protects the replicated payload in transit. A response that limits encryption to DD Boost is incorrect because DD Boost protects backup client-to-appliance traffic, while replication is a separate appliance-to-appliance mechanism. A response that says DD Boost or an MTree setting controls replication encryption is wrong: MTree functions don't enable a transport tunnel for replication, and DD Boost isn't the replication engine. Exam caveat: distinguish data-in-transit protection from network segmentation and access control. Operational check: verify the replication pair is configured with transport protection enabled and confirm the VPN requirement is documented as segmentation rather than payload security.