Update

Author: johndowns

articles/azure-resource-manager/bicep/scenarios-secrets.md

@@ -30,8 +30,9 @@ Sometimes, you need to access a secret from one resource to configure another re
 
 For example, you might have created a storage account in another deployment, and need to access its primary key to configure an Azure Functions app. You can use the `existing` keyword to obtain a strongly typed reference to the pre-created storage account, and then use the storage account's `listKeys()` method to create a connection string with the primary key:
 
+> The following example is part of a larger example. For a Bicep file that you can deploy, [see the complete file](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-secrets/function-app.bicep).
+
 ::: code language="bicep" source="~/azure-docs-bicep-samples/samples/scenarios-secrets/function-app.bicep" range="8-46" highlight="1-3, 5, 22, 34" :::
-> [This complete Bicep file is available for download.](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-secrets/function-app.bicep)
 
 By using this approach, you avoid passing secrets into or out of your Bicep file.
 
@@ -49,8 +50,9 @@ When you create a vault, you need to determine who and what can access its data.
 
 Secrets are a [child resource](child-resource-name-type.md) and can be created by using the type [`Microsoft.KeyVault/vaults/secrets`](/azure/templates/microsoft.keyvault/vaults/secrets?tabs=bicep). The following example demonstrates how to create a vault and a secret:
 
+> The following example is part of a larger example. For a Bicep file that you can deploy, [see the complete file](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-secrets/key-vault-secret.bicep).
+
 ::: code language="bicep" source="~/azure-docs-bicep-samples/samples/scenarios-secrets/key-vault-secret.bicep" range="4-25" :::
-> [This complete Bicep file is available for download.](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-secrets/key-vault-secret.bicep)
 
 > [!TIP]
 > When you use automated deployment pipelines, it can sometimes be challenging to determine how to bootstrap key vault secrets for your deployments. For example, if you've been provided with an API key to use when communicating with an external API, then the secret needs to be added to a vault before it can be used in your deployments.

articles/azure-resource-manager/bicep/scenarios-virtual-networks.md

@@ -23,9 +23,9 @@ Virtual networks contain subnets, which are logical groups of IP addresses withi
 
 It's best to define your subnets within the virtual network definition, as in this example:
 
-::: code language="bicep" source="~/azure-docs-bicep-samples/samples/scenarios-virtual-networks/vnet.bicep" range="7-30, 39" :::
+> The following example is part of a larger example. For a Bicep file that you can deploy, [see the complete file](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-virtual-networks/vnet.bicep).
 
-> [This complete Bicep file is available for download.](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-virtual-networks/vnet.bicep)
+::: code language="bicep" source="~/azure-docs-bicep-samples/samples/scenarios-virtual-networks/vnet.bicep" range="7-30, 39" :::
 
 Although both approaches enable you to define and create your subnets, there is an important difference. When you define subnets by using child resources, the first time your Bicep file is deployed, the virtual network is deployed. Then, after the virtual network deployment is complete, each subnet is deployed. This sequencing occurs because Azure Resource Manager deploys each individual resource separately.
 
@@ -35,9 +35,9 @@ When you redeploy the same Bicep file, the same deployment sequence occurs. Howe
 
 You often need to refer to a subnet's resource ID. When you use the `subnets` property to define your subnet, [you can use the `existing` keyword](existing-resource.md) to also obtain a strongly typed reference to the subnet, and then access the subnet's `id` property:
 
-::: code language="bicep" source="~/azure-docs-bicep-samples/samples/scenarios-virtual-networks/vnet.bicep" range="7-42" highlight="26-28, 30-32, 35-36" :::
+> The following example is part of a larger example. For a Bicep file that you can deploy, [see the complete file](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-virtual-networks/vnet.bicep).
 
-> [This complete Bicep file is available for download.](https://raw.githubusercontent.com/Azure/azure-docs-bicep-samples/main/samples/scenarios-virtual-networks/vnet.bicep)
+::: code language="bicep" source="~/azure-docs-bicep-samples/samples/scenarios-virtual-networks/vnet.bicep" range="7-42" highlight="26-28, 30-32, 35-36" :::
 
 Because this example uses the `existing` keyword to access the subnet resource, instead of defining the complete subnet resource, it doesn't have the risks outlined in the previous section.