A financial services firm is deploying a Foundry-hosted model for an internal analyst tool. Compliance requires that inference traffic never traverse the public internet and that data at rest in the deployment be encrypted using keys the firm controls rather than Microsoft-managed keys. (Select TWO.) Which two configurations satisfy these requirements?
Select all correct answers, then click Submit.
Short Explanation
There are two separate promises being made here, keep traffic off the public internet, and make sure the firm, not Microsoft, holds the encryption keys, and each one needs its own fix. A private endpoint sitting inside a managed virtual network is what keeps the actual data path private instead of routing out over the public internet, so that covers the network side. Customer-managed keys is what hands key ownership to the firm instead of leaving it with the platform, so that covers the encryption side. Allowlisting specific office IP addresses sounds secure, but the traffic is still going out over the public internet to get checked against that list in the first place, so it doesn't actually satisfy a 'never touches the public internet' requirement. And sticking with the default managed keys might be fine for plenty of compliance needs in general, but it's the opposite of what was asked for here, since those keys are controlled by the platform, not by the firm. Solving both requirements means pairing private network access with keys the firm actually holds.
Full Explanation
The correct answers are A and D. A private endpoint inside a managed virtual network keeps inference traffic on a private network path rather than the public internet, satisfying the network isolation requirement, and customer-managed keys let the firm hold and rotate the encryption keys used to protect data at rest, satisfying the key-ownership requirement. Together these two configurations directly address both stated compliance conditions. Option B is incorrect because enabling public network access, even with IP allowlisting, still means traffic traverses the public internet before reaching the allowlist check; it narrows who can connect but does not keep traffic off the public path, which the requirement explicitly rules out. Option C is incorrect because Microsoft-managed keys mean Microsoft controls the encryption keys, not the firm, which directly contradicts the requirement that the firm control its own keys, regardless of which compliance frameworks those managed keys satisfy in general. Meeting both stated constraints requires combining private network access with customer-controlled encryption, which is exactly what options D and A provide and what C and D each fail to deliver on one of the two requirements.