Issue with Azure key vault and Azure storage account deployment

I am trying to deploy a storage account, key vault along with private endpoints using terraform and azure devops, I have deployed this previously for dev environment in which all the resources were in same subscription along with agent so everything got deployed in one go, now i am trying to deploy for preprod environment here private dns zones are in different subscription but my service principal do have contributor access on private dns zones and subscription but still getting below mentioned error in key vault and storage account private dns zones deployment, resources key vault and storage account got deployed succesfully.

2024-02-23T15:42:56.2261892Z Error: retrieving contact for KeyVault: keyvault.BaseClient#GetCertificateContacts: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

2024-02-23T15:42:56.2282150Z Storage Account Name: "************"): accounts.Client#GetServiceProperties: Failure sending request: StatusCode=0 -- Original Error: context deadline exceeded

Tried checking access for build agent as build agent is in different vnet and resources are getting deployed are in different vnet, Is vnet peering required if build agent , key vault/storage account are in different vnety?

To answer your final question; yes, if your agent doing the deployment is in another vNet, that vNet has to be peered to finish the deployment. (Or the agent needs to be able to connect to that network.)

You are probably running into the following scenario:

1. Terraform creates the resources
2. Terraform creates the Private Endpoints and they register in the DNS zones
3. All future requests to those resources fail/timeout because they are now getting a private DNS name for the resources and the agent can no longer communicate, even though it initially got a successful web response for the API call to create them.

A couple other points to note:

• The Private Endpoints do not need to be created in the same subscription as the resources. (They must be in the same region.)
• You can have multiple private endpoints for resources

If you didn't want to peer the vNets, you could deploy two private endpoints for each, one in your agent subscription/vNet and the second in the prod sub/vNet. You would need to specify dependencies though using depends_on to verify that the PEs in the agent vNet are created first.

Otherwise your only other option is to connect your agent to the target vNet somehow.