Cascade Regional Airlines wants to define its standard outstation virtual network pattern once in Bicep and reuse it across every new airport deployment, rather than copying the same resource block into every template. Which Bicep feature is built for exactly this kind of reuse?
Select an answer to reveal the explanation.
Short Explanation
A module in Bicep is a packaged, reusable chunk of infrastructure — write the VNet pattern once, then call that module from every outstation's deployment instead of retyping it each time.
Full Explanation
Bicep modules let an engineer define a set of resources, such as a standard virtual network and its subnets, once in a separate Bicep file, then reference that file from any number of parent templates by passing in the parameters it needs. This is conceptually similar to linked or nested ARM templates but with much simpler syntax, and it is the correct tool for standardizing a pattern across many outstation deployments. Outputs only return values after a deployment completes; they do not package resource definitions for reuse and cannot be called into another template the way a module can. Parameter files hold input values, not resource declarations, so they cannot encapsulate a VNet pattern at all. Deployment history is a record of past deployments in the portal for auditing and troubleshooting; cloning from it is not a supported reuse mechanism and does not scale the way a module does. Before rolling a new module out broadly, a reasonable check is deploying it once to a throwaway resource group and confirming the resulting resources match the expected pattern.