Bicep existing resource - Azure Glossary

Understand the concept

In plain English

A Bicep existing resource declaration tells Bicep, “this resource is already there; use it, but do not create it.” It is commonly used when a new deployment needs information from a shared storage account, virtual network, Key Vault, Log Analytics workspace, or resource group. You provide the existing resource name and, when needed, its scope. Bicep can then reference its properties or deploy related resources around it without trying to recreate the original resource. That makes the term easier to recognize during design reviews, pipeline troubleshooting, and postdeployment validation.

Why it matters

Bicep existing resource matters because enterprise deployments rarely own every dependency they touch. Application teams often deploy into shared networks, monitoring platforms, identity resources, and governance resource groups managed by other teams. The existing keyword lets templates connect to those shared assets without taking ownership or overwriting configuration. It also makes dependencies explicit, which helps reviews and troubleshooting. The risk is scope confusion: a template may reference the wrong resource with the same name, fail because the dependency is absent, or accidentally hide missing platform prerequisites. This keeps architecture decisions visible for reviewers, helps support teams understand intended behavior, and gives release managers evidence before approving changes.

Official wording and source

A Bicep existing resource declaration references a resource that already exists instead of deploying it again. Microsoft Learn places it in Reference existing resources in Bicep; operators confirm scope, configuration, dependencies, and production impact. Use the linked source for exact Azure behavior.

Open Microsoft Learn

Technical context

Technically, a Bicep existing resource uses the existing keyword after the resource type and API version. The declaration supplies enough identity information, usually name and sometimes scope, for Azure Resource Manager to locate the resource. The current deployment does not redeploy that resource, but it can access properties through the symbolic name. Existing resources can be referenced in the same scope or a different scope. If the resource cannot be found, the deployment fails with a NotFound-style error.

Exam context

Compare with

ARM template Deployment stack

Where it is used

Where you see it

You see existing resources in Bicep files where a resource declaration includes the existing keyword and only identifies a resource already deployed. Operators use this evidence during release review.
You see them in templates that attach new diagnostics, role assignments, private endpoints, or modules to shared workspaces, networks, vaults, or resource groups. Operators use this evidence during release review.
You see problems in deployment errors when the referenced name, scope, tenant, subscription, or deploying identity permission does not match the real resource. Operators use this evidence during release review.

Common situations

Standardize Azure infrastructure as code across teams and environments.
Reduce manual portal configuration by making deployment behavior reviewable and repeatable.
Support CI checks that catch template problems before production changes.
Create clearer handoffs between platform modules, application teams, and operations runbooks.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Shared monitoring workspace integration Scenario, objectives, solution, measured impact, and takeaway.

Scenario

BeaconStream Media needed new streaming services to send logs to a central Log Analytics workspace owned by the observability team.

Goals

Use the central workspace without redeploying it.
Avoid creating duplicate monitoring resources per application.
Validate workspace scope before application deployment.
Improve chargeback visibility for log ingestion.

Approach using Bicep existing resource

The application module declared the Log Analytics workspace as a Bicep existing resource using its approved name and resource group scope. Diagnostic settings for app services, storage, and APIs referenced the workspace symbolic name. CI first ran az resource show against the workspace ID, then az bicep build and what-if for the application template. Tags on diagnostic settings identified the consuming product so ingestion cost could be allocated correctly. The team documented ownership, rollback steps, and approval evidence so operators could distinguish intentional template behavior from configuration drift. Pipeline checks compared expected deployment output with actual Azure inventory before the release was marked complete. Runbooks were updated with validation commands, known failure modes, and the escalation path for production changes.

Potential outcomes

Avoided creation of 12 duplicate workspaces across product teams.
Reduced monitoring onboarding time from two days to four hours.
Improved log ingestion chargeback accuracy by 37 percent.
Eliminated deployment failures caused by mistyped workspace IDs after preflight checks.

What to learn

Existing resource declarations are ideal when applications consume shared platform services without owning them.

Scenario 02 Bank Key Vault dependency control Scenario, objectives, solution, measured impact, and takeaway.

Scenario

ValeBridge Bank deployed payment applications that needed access policies and private endpoints connected to centrally managed Key Vaults.

Goals

Reference approved Key Vaults without modifying vault baselines.
Prevent teams from creating unmanaged vaults.
Deploy app-specific private endpoint resources safely.
Keep ownership between platform and application teams clear.

Approach using Bicep existing resource

Platform engineers required application templates to declare the Key Vault as an existing resource at the controlled platform resource group scope. The Bicep module deployed private endpoint connections, diagnostic settings, and managed identity role assignments around that existing vault. What-if output was reviewed to confirm the vault itself was not recreated or updated beyond intended related resources. Azure Policy blocked new vault creation outside the platform subscription. The team documented ownership, rollback steps, and approval evidence so operators could distinguish intentional template behavior from configuration drift. Pipeline checks compared expected deployment output with actual Azure inventory before the release was marked complete. Runbooks were updated with validation commands, known failure modes, and the escalation path for production changes.

Potential outcomes

Stopped six unmanaged vault requests in the first quarter.
Reduced payment application onboarding from twelve days to five days.
Maintained clear separation between vault ownership and app access changes.
Passed access review with resource IDs, role assignments, and what-if evidence.

What to learn

The existing keyword helps teams consume governed shared resources while preserving ownership boundaries.

Scenario 03 Public-sector landing zone dependency Scenario, objectives, solution, measured impact, and takeaway.

Scenario

Cedar County Digital Services deployed workloads into resource groups and virtual networks provisioned by a separate landing zone program.

Goals

Deploy workloads into approved existing resource groups.
Avoid accidental recreation of landing zone infrastructure.
Verify virtual network and subnet availability before release.
Support multiple departments with one workload module.

Approach using Bicep existing resource

The workload Bicep file used existing resource declarations for the department resource group and hub-approved virtual network. Modules for app hosting, diagnostics, and private endpoints received those symbolic references as scope or parameter inputs. The pipeline verified resource IDs before running build and what-if. If a department lacked the required landing zone resources, the deployment failed early with a clear prerequisite message instead of creating unmanaged infrastructure. The team documented ownership, rollback steps, and approval evidence so operators could distinguish intentional template behavior from configuration drift. Pipeline checks compared expected deployment output with actual Azure inventory before the release was marked complete. Runbooks were updated with validation commands, known failure modes, and the escalation path for production changes.

Potential outcomes

Deployed seven department workloads using one reusable module.
Reduced landing zone misrouting incidents to zero over two release cycles.
Cut prerequisite troubleshooting time from hours to minutes.
Preserved central ownership of network and resource group baselines.

What to learn

Bicep existing resources make platform prerequisites explicit, testable, and safer for multi-team deployments.

Azure CLI

CLI checks are useful because existing resource declarations depend on live names, scopes, and permissions that are easy to misread in code.

Useful for

Verify the referenced resource exists at the expected scope before running the Bicep deployment.
Run what-if to confirm the deployment consumes the existing resource rather than recreating it.
Inspect permissions and resource IDs when a deployment fails because an existing dependency cannot be found.

Before you run a command

Confirm the active tenant, subscription, resource group, deployment scope, and parameter file before running Bicep commands.
Check the installed Bicep CLI version and whether external modules must be restored from a registry.
Run commands from the repository folder that should control bicepconfig.json resolution and relative module paths.
Make sure the pipeline or user identity has only the permissions needed for restore, what-if, and deployment.

What the output tells you

Build output shows whether the Bicep source compiles into valid ARM JSON and whether module restore succeeded.
Lint output identifies syntax, rule, naming, cleanup, or maintainability issues before a deployment touches Azure.
What-if output shows which Azure resources would be created, modified, skipped, or deleted for the current parameters.
Deployment output or query results show the resource IDs, endpoints, or module values returned after a completed deployment.

Mapped commands

Bicep existing resource validation and operations

direct

az bicep version

az bicepdiscoverManagement and Governance

az bicep build --file main.bicep

az bicepprovisionManagement and Governance

az bicep lint --file main.bicep

az bicepdiscoverManagement and Governance

az deployment group what-if --resource-group <resource-group> --template-file main.bicep

az deployment groupdiscoverManagement and Governance

az resource show --ids <resource-id>

az resourcediscoverManagement and Governance

Architecture context

Technically, a Bicep existing resource uses the existing keyword after the resource type and API version. The declaration supplies enough identity information, usually name and sometimes scope, for Azure Resource Manager to locate the resource. The current deployment does not redeploy that resource, but it can access properties through the symbolic name. Existing resources can be referenced in the same scope or a different scope. If the resource cannot be found, the deployment fails with a NotFound-style error.

Security: Security depends on confirming the referenced resource is the intended trusted dependency. Existing declarations can point to Key Vaults, networks, managed identities, or monitoring workspaces that influence access and data flow. Use precise names, scopes, and permissions, and avoid accepting arbitrary existing resource IDs from untrusted parameters. The deploying identity still needs permission to read or use the referenced resource and deploy related resources. Review role assignments, private endpoint targets, diagnostics destinations, and secret access so existing dependencies do not bypass governance boundaries. Security teams should pair the pattern with least privilege, policy checks, repository review, and controlled parameters in shared pipelines.
Cost: Cost impact comes from shared-resource ownership. An existing resource may already carry costs for capacity, logging, backup, or networking, and new deployments can increase its consumption without creating a new billable resource. For example, adding diagnostics to an existing workspace raises ingestion volume, and attaching workloads to an existing premium file share changes utilization. Chargeback tags and ownership records should separate platform baseline costs from application-driven usage. Avoid creating duplicate resources simply because the existing dependency was hard to reference correctly. Cost owners should review defaults, environment parameters, and what-if output because small template changes can multiply across many deployments.
Reliability: Reliability improves when shared dependencies are declared explicitly and checked before deployment. Existing resources should be treated as prerequisites with owners, SLAs, and change windows. If a workspace, virtual network, or Key Vault is missing or renamed, the deployment can fail before creating partial dependent resources. Use what-if, preflight checks, and clear error handling in pipelines. Avoid coupling many applications to a shared resource without monitoring its health. When referencing resources across scopes, test permissions and names in every environment. Reliable teams also rehearse rollback, check generated resources after deployment, and document how downstream modules behave when the pattern changes.
Performance: Performance depends on the shared resource being suitable for the new workload. Referencing an existing workspace, storage account, cache, or network path does not guarantee enough capacity or low latency. Check region, SKU, throughput, throttling limits, and dependency health before connecting more workloads. Existing declarations can improve deployment speed because Azure does not recreate the dependency, but runtime performance may suffer if too many systems share it. Use metrics and capacity planning when existing resources become common platform anchors. Performance reviewers should compare pipeline duration, provider throttling, generated template size, and runtime impact before scaling the pattern broadly. Performance reviewers should compare pipeline duration, provider throttling, generated template size, and runtime impact before scaling the pattern broadly.
Operations: Operationally, existing resources require coordination between application and platform teams. Runbooks should identify who owns the referenced resource, where it lives, and what changes are allowed. Pipelines should check that the active tenant, subscription, resource group, and scope match the intended dependency. Use tags or documentation to show when a template consumes but does not own a resource. During incidents, operators should know whether to troubleshoot the application deployment, the shared dependency, or the permissions between them. Operators should keep examples, expected outputs, owner contacts, and troubleshooting steps near the repository that deploys the template. Operators should keep examples, expected outputs, owner contacts, and troubleshooting steps near the repository that deploys the template.

Common mistakes

Providing the right resource name but the wrong subscription or resource group scope.
Assuming existing means the deploying identity does not need read or related deployment permissions.
Using existing dependencies without documenting ownership, change windows, or capacity limits.