This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
--> Implement security for application platform services
--> Implement and configure security controls for Azure Logic Apps
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Introduction
Azure Logic Apps is a serverless workflow platform used to automate business processes and integrate applications, data, services, and systems. Because Logic Apps frequently process sensitive information and connect to many other services, security must be considered at several layers.
For the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads exam, security for Logic Apps is particularly important within the Secure compute domain and the Implement security for application platform services area.
The primary security controls to understand include:
- Managed identities
- Microsoft Entra authentication
- Connector and connection security
- Azure RBAC
- Inbound access restrictions
- Private endpoints
- Virtual network integration
- Network isolation
- Protection of workflow inputs and outputs
- Protection of run history
- Restricting who can create and use connections
- Least-privilege access to connected resources
A key concept is that Logic App security is not a single feature. A secure workflow generally combines identity, authorization, network controls, connector security, and protection of workflow data.
1. Understand the Azure Logic Apps Security Model
Azure Logic Apps workflows can interact with many different systems, including:
- Azure Storage
- Azure SQL
- Azure Key Vault
- Azure Functions
- Azure Service Bus
- Microsoft Sentinel
- Microsoft APIs
- SaaS applications
- On-premises systems
- Custom APIs
- Other Logic Apps
This creates several potential security boundaries.
A useful way to think about Logic Apps security is:
| Security layer | Primary question | Example control |
|---|---|---|
| Identity | Who or what is accessing the resource? | Microsoft Entra ID |
| Authorization | What is that identity allowed to do? | Azure RBAC |
| Application authentication | Who can invoke the workflow? | OAuth / Microsoft Entra ID |
| Workload identity | How does the workflow authenticate to Azure resources? | Managed identity |
| Network | Where can traffic originate or terminate? | Private endpoint, IP restrictions |
| Connector | How does the workflow connect to another service? | Managed identity / OAuth |
| Data | Can sensitive workflow information be exposed? | Secure inputs/outputs |
| Administration | Who can modify the workflow? | RBAC / Logic Apps roles |
| Governance | Which connections are permitted? | Azure Policy |
These controls complement one another rather than replace one another.
For example, placing a Logic App behind a private endpoint does not automatically determine whether a caller is authorized to perform an operation. Likewise, assigning a managed identity does not automatically grant that identity permission to access a storage account or Key Vault.
2. Consumption and Standard Logic Apps
Two important Logic Apps hosting models appear throughout Azure security discussions:
- Consumption
- Standard
The security capabilities available can differ between them, so SC-500 questions may require you to recognize which model is being used.
Standard Logic Apps provide a single-tenant hosting model and support capabilities such as virtual network integration and private endpoints for securing network traffic. Standard workflows can use inbound private endpoints and outbound virtual network integration to establish more isolated architectures.
Consumption workflows are multitenant and have their own security controls, including trigger authorization policies, inbound IP restrictions, SAS-based access, and managed identity authentication.
Exam tip: Don’t assume that every Logic Apps networking or authentication feature behaves identically in Consumption and Standard.
3. Use Managed Identities Whenever Possible
One of the most important security controls for Logic Apps is the use of managed identities.
A managed identity allows a Logic App to authenticate to supported Azure resources without storing:
- Passwords
- Client secrets
- Connection strings containing credentials
- Access tokens
Azure manages the identity and obtains the appropriate Microsoft Entra token when the workflow needs to access a protected resource. Microsoft recommends managed identities when supported because they eliminate the need to manage credentials manually.
For example:
A Logic App needs to retrieve secrets from Azure Key Vault.
A less secure approach might involve storing a credential or secret in the workflow configuration.
A better approach is:
Logic App → Managed Identity → Microsoft Entra ID → Key Vault
The identity must still be granted the appropriate permissions on Key Vault. Simply enabling the identity does not grant access to the resource.
4. System-Assigned vs. User-Assigned Managed Identity
Logic Apps can use two types of managed identities.
| Feature | System-assigned | User-assigned |
|---|---|---|
| Lifecycle | Tied to Logic App | Independent resource |
| Created with | Logic App | Separate Azure resource |
| Reusable by multiple resources | No | Yes |
| Identity survives Logic App deletion | No | Yes |
| Useful when | Identity belongs exclusively to one Logic App | Identity should be shared/reused |
| Management | Simpler | More deliberate/flexible |
A system-assigned managed identity is associated directly with the Logic App.
A user-assigned managed identity (UAMI) is a separate Azure resource that can be associated with multiple workloads.
Standard Logic Apps automatically enable a system-assigned identity by default. A Logic App can also have user-assigned identities associated with it. Current Logic Apps documentation notes that while both types can be enabled on the resource, a particular workflow uses either the system-assigned identity or a selected user-assigned identity for the applicable authentication scenario.
When should you use a user-assigned identity?
Consider a UAMI when:
- Multiple Logic Apps need the same identity.
- Identity lifecycle should be independent of a Logic App.
- You want consistent permissions across multiple workflows.
- You want to avoid recreating permissions when a Logic App is replaced.
Important security consideration
Use least privilege when assigning permissions to the identity.
If a Logic App only needs to read blobs, don’t grant it broad Storage Account Contributor permissions.
Instead, assign the narrowest role that provides the required access.
5. Managed Identity Does Not Automatically Grant Permissions
This is an important SC-500 concept.
Suppose a Logic App has a system-assigned managed identity.
That does not mean:
“The Logic App can now access every Azure resource.”
Instead, the process is:
- Enable the managed identity.
- Azure creates the identity in Microsoft Entra ID.
- Identify the target resource.
- Grant the identity the required permission.
- Configure the Logic App connector/action to use managed identity authentication.
For Azure resources that support Azure RBAC, the identity can be assigned an appropriate role on the target resource.
For example:
Logic App managed identity → Storage Blob Data Reader → Storage account
The Logic App can then authenticate using its identity while remaining subject to the permissions assigned to that identity.
6. Secure Logic App Connections
Logic Apps uses connectors to communicate with external services.
There are two broad categories to understand:
- Built-in connectors
- Managed/shared connectors
Many managed connectors require a connection resource. These connections are separate Azure resources and have their own permissions and security considerations.
A connection can potentially contain authentication information or tokens that allow the workflow to access the target service.
Therefore, securing the Logic App itself is not sufficient.
You must also secure:
Logic App → Connector → Connection → Target service
7. Managed Identity Authentication for Connectors
Where supported, use managed identity authentication instead of stored credentials.
For example, a Logic App might use:
Logic App → Managed Identity → Azure Blob Storage
rather than:
Logic App → stored storage key → Azure Blob Storage
Managed identity authentication is supported by a number of built-in and managed connectors, although support varies by connector and Logic Apps hosting model. Examples include Azure Storage, Azure Key Vault, Azure Service Bus, Azure Resource Manager, Azure SQL-related scenarios, and other Azure services.
Important exam distinction
A connector supporting managed identity does not mean every operation automatically has permission.
The identity still needs the required authorization on the destination resource.
8. Secure Connector Creation with Azure Policy
Organizations may want to prevent developers from creating connections to particular services.
For example, an organization might prohibit Logic Apps from creating connections to:
- Unapproved SaaS applications
- External data stores
- Personal accounts
- Unapproved third-party services
Azure Policy can be used to govern whether certain connections can be created.
This is an important distinction:
Managed identity controls how a workload authenticates.
Azure Policy can help govern which configurations or connections are permitted.
These controls address different security problems.
9. Protect Workflow Management with Azure RBAC
Security isn’t limited to runtime access.
You must also control who can:
- Create Logic Apps
- Modify workflows
- Create connections
- View workflow configuration
- Enable or disable workflows
- View workflow execution information
- Modify networking
- Change security settings
Azure RBAC provides management-plane authorization.
For Consumption Logic Apps, Azure provides roles such as:
- Logic App Contributor
- Logic App Operator
- Contributor
The Logic App Operator role, for example, allows operational tasks such as reading, enabling, and disabling workflows without allowing workflow editing.
This supports the principle of least privilege.
Example
A production operations employee needs to restart or disable a workflow but should not be able to modify its business logic.
Giving that person an operator-level role is preferable to giving them broad Contributor permissions.
10. Secure Inbound Access to Logic Apps
Some Logic Apps workflows have HTTP or Request triggers.
These create an inbound endpoint that external clients can invoke.
That endpoint needs to be protected.
Potential controls include:
- Microsoft Entra ID / OAuth
- SAS authentication
- Inbound IP restrictions
- Private endpoints
- API Management
- Network isolation
- Authentication policies
For Consumption workflows using Request triggers, Microsoft Entra ID OAuth can be used to authenticate callers, and SAS authentication can also be controlled.
11. Microsoft Entra ID Authentication for Inbound Requests
For workflows that must be invoked by authenticated applications or users, Microsoft Entra ID provides a stronger identity-based approach than simply distributing a shared URL.
The general architecture becomes:
Client → Microsoft Entra ID authentication → Logic App
The Logic App can validate the caller’s token and claims.
Authorization policies can use claims such as:
- Issuer
- Audience
- Subject
- Other applicable claims
At minimum, Microsoft Entra authorization policies require issuer and audience information for the token.
Why is this valuable?
Instead of asking:
“Does the caller possess the secret URL?”
you can ask:
“Is this caller authenticated by the correct identity provider and does the token contain the required claims?”
That provides a much stronger identity-centric security model.
12. SAS Authentication
Some Logic Apps request-based triggers can use Shared Access Signature (SAS) authentication.
A SAS-based URL effectively contains authorization information that allows the caller to invoke the workflow.
SAS can be useful, but it introduces a secret-bearing URL that must be protected.
If the URL is exposed, an unauthorized party may be able to invoke the workflow until the access mechanism is revoked or regenerated.
For this reason, Microsoft recommends Microsoft Entra ID and managed identities whenever possible.
Exam consideration
If a question asks for the strongest identity-based authentication approach, Microsoft Entra ID is generally preferable to distributing long-lived shared secrets or SAS URLs.
13. Restrict Inbound IP Addresses
Network restrictions provide another layer of protection.
For example, suppose a Logic App should only receive requests from an API Management instance.
You can restrict inbound access so that only approved IP ranges can invoke the workflow.
A useful architecture is:
Internet client → API Management → Logic App
The Logic App can then restrict inbound traffic to the expected API Management source addresses.
Azure Logic Apps supports inbound IP restrictions for request-based workflows. Standard Logic Apps can use App Service-style access restrictions, while Consumption workflows provide workflow-level access-control settings.
Defense in depth
IP filtering should generally complement authentication rather than replace it.
For example:
Network restriction + Microsoft Entra authentication
is stronger than:
IP restriction alone
14. Private Endpoints
For workloads requiring strong network isolation, private endpoints can be used.
A private endpoint provides a private IP address within an Azure virtual network and uses Azure Private Link.
This allows traffic to the Logic App to remain on private Azure networking rather than requiring public internet access. Standard Logic Apps support private endpoints for inbound traffic.
Conceptually:
Azure Virtual Network
┌──────────────────────────────────┐
│ │
Client ─┤─► Private Endpoint ─► Logic App │
│ │
└──────────────────────────────────┘
This is particularly useful when:
- The Logic App should not be publicly accessible.
- Internal applications need to invoke the workflow.
- Regulatory requirements require private connectivity.
- The organization wants to reduce public attack surface.
15. Private Endpoint vs. Virtual Network Integration
This distinction is extremely important for the SC-500 exam.
Private endpoint
Primarily provides private inbound connectivity to the Logic App.
Virtual network integration
Provides outbound connectivity from a Standard Logic App into a virtual network.
The concepts are complementary.
| Requirement | Appropriate control |
|---|---|
| Private clients need to invoke Logic App | Private endpoint |
| Logic App needs to access private resources | VNet integration |
| Logic App needs both private inbound and private outbound connectivity | Private endpoint + VNet integration |
| Restrict public access | Disable public network access where supported |
| Restrict specific public source addresses | Access restrictions |
Microsoft’s current Standard Logic Apps networking guidance explicitly separates private endpoints for inbound traffic from virtual network integration for outbound traffic.
Common exam trap
Incorrect:
“VNet integration makes the Logic App’s inbound endpoint private.”
Correct:
VNet integration primarily provides outbound connectivity from the Logic App into a virtual network.
16. Network Isolation for Standard Logic Apps
A highly secured Standard Logic App can use a combination of:
- Private endpoint
- VNet integration
- Private DNS
- Access restrictions
- Network security controls
- Managed identities
- Disabled public network access
For example:
Corporate Network
│
▼
Private DNS
│
▼
Private Endpoint
│
▼
┌─────────────────────┐
│ Standard Logic │
│ App │
└─────────┬───────────┘
│
VNet Integration
│
┌────────────┼────────────┐
▼ ▼ ▼
Key Vault SQL DB Storage
Private Private Private
Endpoint Endpoint Endpoint
This architecture reduces exposure to public networks while still allowing the workflow to communicate with private Azure resources.
17. DNS Is Critical with Private Endpoints
A private endpoint is not sufficient by itself.
The client must resolve the Logic App’s hostname to the private endpoint IP address.
This commonly involves Azure Private DNS.
The basic sequence is:
Client │ ▼DNS query │ ▼Private DNS zone │ ▼Private IP address │ ▼Private Endpoint │ ▼Logic App
If DNS continues resolving the Logic App to a public address, the client may not use the intended private path.
Therefore, when troubleshooting private Logic Apps, consider both:
- Network connectivity
- DNS resolution
18. Protect Workflow Run History
Logic Apps run history can contain highly sensitive information.
A workflow might process:
- Passwords
- Access tokens
- Customer information
- Financial data
- API responses
- Personally identifiable information
- Secrets retrieved from Key Vault
Run history can expose action inputs and outputs to authorized users.
Therefore, simply protecting the workflow endpoint is not enough.
You must also protect the data stored and displayed in run history.
Azure Logic Apps provides controls for restricting access to run-history content and for securing or obfuscating sensitive inputs and outputs.
19. Secure Inputs and Outputs
Suppose a workflow contains:
Get secret from Key Vault ↓Use secret in HTTP request ↓Call external service
If the secret is visible in action inputs or outputs, a person with access to workflow run history could potentially see sensitive information.
For sensitive triggers and actions, use secure inputs and secure outputs where appropriate.
The goal is to prevent sensitive information from unnecessarily appearing in run history.
Security principle
Don’t allow operational troubleshooting data to become an accidental source of credential disclosure.
This is especially important for workflows processing secrets or regulated data.
20. Restrict Access to Run History
Azure Logic Apps also provides controls for limiting who can access workflow run-history content.
For example, access to run-history inputs and outputs can be restricted by IP address.
This creates an additional security boundary around potentially sensitive workflow data.
A secure production environment might therefore use:
Identity + RBAC + network restriction + secure inputs/outputs
rather than relying on a single control.
21. Secure Outbound Connections
A Logic App may need to call:
- Azure SQL
- Storage
- Key Vault
- APIs
- SaaS applications
- On-premises systems
The security of outbound traffic therefore matters as much as inbound security.
For Standard Logic Apps, VNet integration can provide connectivity to resources in a virtual network.
The destination can itself be protected using:
- Private endpoints
- Firewall rules
- Network security controls
- Microsoft Entra authentication
- Managed identities
This creates a layered architecture.
For example:
Logic App │ │ Managed Identity ▼Microsoft Entra ID │ ▼Private network │ ▼Private Endpoint │ ▼Azure SQL
The network control and identity control solve different problems.
22. Protect Connections to On-Premises Resources
Logic Apps can also connect to on-premises systems.
For example:
Logic App │ ▼On-premises Data Gateway │ ▼On-premises SQL Server
The on-premises data gateway supports secure communication for supported connector scenarios.
This can be useful when an organization needs to automate processes involving systems that cannot be moved to Azure.
The security objective remains the same:
- Authenticate the workload.
- Minimize permissions.
- Protect network communication.
- Restrict access.
- Monitor activity.
23. Use API Management for Additional API Protection
If a Logic App is exposed as an API, Azure API Management can provide an additional security and governance layer.
A common architecture is:
API Consumer │ ▼Azure API Management │ │ Authentication / policies ▼Azure Logic App │ ▼Backend services
API Management can centralize API security policies and reduce the need to expose the Logic App directly to consumers.
This can be especially useful when the Logic App is functioning as an API backend rather than simply responding to an internal event.
24. Secure the Logic App Management Plane
Runtime security is only part of the problem.
A compromised administrator or developer account could modify the workflow itself.
Therefore, protect the management plane using:
- Microsoft Entra ID
- Azure RBAC
- Least-privilege role assignments
- Privileged Identity Management where appropriate
- Resource locks for critical resources
- Conditional Access and MFA for administrative identities
- Azure Policy
- Infrastructure as code
For example, a production Logic App might be protected from accidental deletion using an Azure resource lock.
A resource lock doesn’t replace RBAC, but it provides another layer of protection against accidental or unauthorized resource modification.
25. A Defense-in-Depth Architecture
A well-secured Logic App might look like this:
External Client
│
▼
Microsoft Entra ID
Authentication
│
▼
API Management
│
Network Controls
│
▼
Private Endpoint
│
▼
┌──────────────────────┐
│ Logic App │
│ │
│ Managed Identity │
│ RBAC │
│ Secure I/O │
└──────────┬───────────┘
│
VNet Integration
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Key Vault Azure SQL Storage
Private EP Private EP Private EP
│ │ │
└──────────────┼──────────────┘
▼
Microsoft Entra ID
This architecture combines:
- Identity security
- Authentication
- Authorization
- Network isolation
- Private connectivity
- Managed identities
- Least privilege
- Data protection
No single control is expected to provide complete security.
26. Security Control Decision Matrix
| Requirement | Recommended control |
|---|---|
| Authenticate Logic App to Azure resource | Managed identity |
| Avoid storing application secrets | Managed identity |
| Control permissions to Azure resources | Azure RBAC |
| Authenticate users/applications invoking workflow | Microsoft Entra ID / OAuth |
| Restrict callers by source IP | IP restrictions |
| Provide private inbound access | Private endpoint |
| Provide outbound access to private resources | VNet integration |
| Keep Azure resources off public network paths | Private endpoints + appropriate public-access restrictions |
| Protect sensitive workflow data in run history | Secure inputs/outputs |
| Restrict access to run-history data | IP restrictions/access controls |
| Govern which connectors developers can create | Azure Policy |
| Protect workflow administration | Azure RBAC / least privilege |
| Put an API security layer in front of workflow | API Management |
| Protect production resource from accidental deletion | Resource lock |
27. Common SC-500 Exam Traps
Trap 1: “Managed identity automatically grants access.”
False.
The identity must still be granted the appropriate permissions on the target resource.
Trap 2: “VNet integration makes inbound Logic App traffic private.”
False.
VNet integration is primarily for outbound connectivity.
Trap 3: “A private endpoint controls outbound Logic App traffic.”
False.
A private endpoint provides private connectivity to the service for inbound access. VNet integration is used for outbound connectivity from a Standard Logic App.
Trap 4: “Private networking eliminates the need for authentication.”
False.
Network location and identity are separate security controls.
A caller can be inside the private network and still be unauthorized.
Trap 5: “Enabling a managed identity is enough.”
False.
The identity needs appropriate permissions on the target resource.
Trap 6: “Protecting the workflow endpoint protects all workflow data.”
False.
Run history can contain sensitive inputs and outputs and requires separate protection.
Trap 7: “SAS URLs are always preferable because they are easy to use.”
False.
SAS provides a shared-secret-style access mechanism. Microsoft recommends Microsoft Entra ID and managed identities whenever supported.
Trap 8: “RBAC controls everything.”
False.
Azure RBAC primarily controls management-plane access and permissions to Azure resources. Application authentication, connector authentication, and network security are separate layers.
28. Best Practices Checklist
For production Logic Apps, consider the following:
Identity
- Use managed identities whenever supported.
- Prefer user-assigned identities when an identity must have an independent lifecycle or be reused.
- Assign only the permissions required.
- Regularly review role assignments.
Authentication
- Prefer Microsoft Entra ID/OAuth for authenticated callers.
- Avoid unnecessarily distributing SAS URLs.
- Use API Management when centralized API security is required.
Networking
- Use private endpoints for private inbound connectivity where appropriate.
- Use VNet integration for outbound access to private resources.
- Configure DNS correctly for private endpoints.
- Restrict public network exposure where the architecture permits.
- Use IP restrictions when source-network filtering is appropriate.
Connectors
- Review every connector used by the workflow.
- Prefer managed identity authentication when supported.
- Restrict unnecessary connector creation through governance controls.
- Protect connector resources and their permissions.
Data
- Protect sensitive workflow inputs and outputs.
- Prevent secrets from appearing in run history.
- Restrict access to run-history data.
- Treat workflow execution data as potentially sensitive.
Administration
- Apply least privilege through Azure RBAC.
- Separate operational roles from development roles.
- Protect production resources against accidental deletion or modification.
- Review administrative access regularly.
29. SC-500 Key Takeaways
The most important concepts to remember are:
- Managed identities eliminate the need to store credentials for supported authentication scenarios.
- A managed identity still requires appropriate permissions on the target resource.
- System-assigned identities are tied to the Logic App; user-assigned identities have an independent lifecycle and can be reused.
- Microsoft Entra ID/OAuth provides identity-based authentication for callers of protected workflows.
- SAS is another authorization mechanism, but shared secrets should be avoided when stronger identity-based authentication is available.
- Private endpoints provide private inbound connectivity.
- VNet integration provides outbound connectivity from Standard Logic Apps to resources accessible through the virtual network.
- Private endpoints and VNet integration solve different networking problems and can be used together.
- DNS configuration is an important part of a private-endpoint architecture.
- RBAC, network controls, authentication, managed identity, connector security, and data protection address different security layers.
- Workflow run history can expose sensitive inputs and outputs and must be protected.
- Secure inputs and outputs can prevent sensitive information from unnecessarily appearing in run history.
- Azure Policy can help govern which Logic App connections can be created.
- API Management can provide an additional security and governance layer when Logic Apps are exposed as APIs.
- The strongest architectures use defense in depth rather than relying on a single security control.
Practice Exam Questions
Question 1
A company has a Standard Logic App that must retrieve secrets from Azure Key Vault. The security team does not want developers to store Key Vault credentials or secrets in the workflow.
What should you implement?
A. Store the Key Vault access key in an application setting
B. Enable a managed identity for the Logic App and grant it the required Key Vault permissions
C. Store the Key Vault password in the workflow definition
D. Generate a SAS token for the Logic App
Answer: B
Explanation: A managed identity allows the Logic App to authenticate to supported Azure resources without storing credentials. However, the identity must still be granted the appropriate permissions on Key Vault. This is preferable to storing secrets or credentials in the workflow.
Question 2
A Standard Logic App needs to access an Azure SQL database that is accessible only through a virtual network. Which networking capability should primarily be configured on the Logic App to provide outbound connectivity to the private network?
A. Private endpoint on the Logic App
B. Public IP address assignment
C. Azure Front Door
D. Virtual network integration
Answer: D
Explanation: VNet integration provides outbound connectivity from a Standard Logic App into a virtual network. A private endpoint, by contrast, provides private inbound connectivity to the Logic App.
Question 3
A security architect wants a Logic App to be invoked only by applications that authenticate through Microsoft Entra ID. Which approach best satisfies the requirement?
A. Require Microsoft Entra ID OAuth authentication for the workflow’s inbound requests
B. Distribute the workflow’s SAS URL to approved applications
C. Restrict access to the Azure portal
D. Enable a resource lock
Answer: A
Explanation: Microsoft Entra ID OAuth provides identity-based authentication for callers. A resource lock protects the Azure resource from certain management operations but does not authenticate workflow callers. SAS provides another access mechanism but relies on possession of the shared authorization information.
Question 4
A company wants a Standard Logic App to receive requests only through a private IP address in its virtual network. Which solution should the security engineer implement?
A. VNet integration only
B. A user-assigned managed identity
C. A private endpoint for the Logic App
D. Azure RBAC
Answer: C
Explanation: A private endpoint provides private inbound connectivity to the Standard Logic App through a private IP address in the virtual network. VNet integration is primarily an outbound capability.
Question 5
A Logic App uses a managed identity to access Azure Storage. The identity has been enabled, but the workflow receives an authorization error when it attempts to read blobs.
What is the most likely cause?
A. The Logic App does not have an Azure resource lock
B. The managed identity has not been granted the required permissions on the storage account
C. The Logic App must use a public IP address
D. The Logic App must use a SAS URL
Answer: B
Explanation: Enabling a managed identity creates the identity but does not automatically grant it access to Azure resources. The appropriate RBAC role or other supported authorization mechanism must be assigned to the identity on the target resource.
Question 6
A workflow retrieves a database password and then uses the password in an HTTP action. The security team is concerned that authorized operators could see the password in workflow run history.
What should the security engineer implement?
A. Secure inputs and/or secure outputs for the appropriate workflow steps
B. A resource lock
C. A public IP restriction
D. A user-assigned managed identity only
Answer: A
Explanation: Workflow run history can contain action inputs and outputs. Sensitive values should be protected using the available secure-input and secure-output controls so that sensitive information is not unnecessarily exposed through run history.
Question 7
An organization wants to prevent developers from creating Logic App connections to an unapproved external SaaS application.
Which control is most appropriate?
A. Private endpoint
B. Managed identity
C. VNet integration
D. Azure Policy
Answer: D
Explanation: Azure Policy can be used to govern and restrict certain Logic App connection configurations. Managed identities address workload authentication, while private endpoints and VNet integration address networking.
Question 8
A Standard Logic App has both a private endpoint and VNet integration configured. What is the primary purpose of this combination?
A. Provide two independent authentication mechanisms
B. Replace Azure RBAC
C. Provide private inbound access and outbound connectivity to private resources
D. Eliminate the need for Microsoft Entra authentication
Answer: C
Explanation: The private endpoint provides private inbound connectivity to the Logic App, while VNet integration provides outbound connectivity from the Logic App to resources accessible through the virtual network. They address complementary networking requirements.
Question 9
A production Logic App is administered by two teams. The operations team needs to enable, disable, and monitor workflows but should not be able to modify the workflow logic.
Which security principle should guide the assignment of permissions?
A. Least privilege
B. Public network access
C. Shared-secret authentication
D. Full Contributor access
Answer: A
Explanation: Least privilege means granting users only the permissions required to perform their responsibilities. Logic Apps provides roles that can separate operational capabilities from workflow editing capabilities, helping reduce unnecessary management permissions.
Question 10
A company wants to expose a Logic App as an API to external consumers while centralizing authentication, API policies, and traffic management before requests reach the workflow.
Which Azure service should be placed in front of the Logic App?
A. Azure Key Vault
B. Azure Storage
C. Azure Monitor
D. Azure API Management
Answer: D
Explanation: Azure API Management can provide an API-facing security and governance layer in front of a Logic App. It can centralize API policies and authentication and prevent consumers from having to interact directly with the Logic App endpoint. Logic Apps security guidance specifically identifies API Management as an option for exposing and protecting workflow endpoints.
Final Exam Perspective
For SC-500, think about Logic Apps security as a layered security problem:
Who is calling?
→ Microsoft Entra ID / OAuth
How does the workflow authenticate to Azure resources?
→ Managed identity
What can the identity access?
→ RBAC / resource permissions
Who can administer the Logic App?
→ Azure RBAC / least privilege
Where can traffic come from?
→ IP restrictions / private endpoints / network controls
Where can the Logic App send traffic?
→ VNet integration / private connectivity
Can sensitive workflow information be exposed?
→ Secure inputs/outputs / run-history controls
Which integrations are allowed?
→ Connector governance / Azure Policy
Does the Logic App need to be exposed as an API?
→ API Management
The key SC-500 mindset is defense in depth: identity, authorization, network isolation, connector security, and data protection should work together rather than relying on one control.
Go to the SC-500 Exam Prep Hub main page
