App-subnet virtual machines must Get secrets from Key Vault while the public Internet must not. Which network setting should the security engineer apply on the vault?

When app-subnet virtual machines must Get secrets while the public Internet must not, Key Vault should use selected networks: allow the app subnet through virtual-network or service-endpoint rules, optionally add specific public IPv4 allowlists for break-glass callers, and keep the default action denying everything else. That selected-networks pattern is the classic allowlist model before or alongside private endpoints for lock-lab workloads.

All networks fails by concept because it admits Internet-origin data-plane traffic to the vault. Disabling soft-delete so network rules become the only recovery control fails because soft-delete is a deletion-recovery feature unrelated to network allowlisting; turning it off increases irreversible loss risk. Removing all virtual-network rules and relying only on subscription Owner for secret Get fails because Owner is control-plane breadth, not a substitute for network restriction, and Owner does not itself perform application secret Get.

Exam caveat: selected networks still require data-plane RBAC or access policies—network allow alone does not authorize Get. Operational check: set Selected networks, add the app subnet rule, deny public residual access, verify a VM in the app subnet retrieves the secret, and verify a host outside allowed networks receives a network/forbidden failure.