Study guide
8.3 Sensitive input/output parameters & Azure Key Vault
Microsoft Power Platform Developer Associate PL-400
Track your progress as you read
Finished sections get a check mark.
1 Introduction, Exam Overview & Developer Toolchain
0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow
2 Create a Technical Design
1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations
3 Build Power Platform Solutions
2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools
4 Implement Power Apps Improvements
3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance
5 Extend the User Experience
4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component
6 Extend the Platform: Dataverse Plug-ins & Custom APIs
5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events
7 Extend the Platform: Custom Connectors
6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation
8 Extend the Platform: Platform APIs & Azure Functions
7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities
9 Extend the Platform: Power Automate Cloud Flows
8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals
10 Develop Integrations
9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message
11 Exam Readiness & Practice
10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan
8.3 Sensitive input/output parameters & Azure Key Vault
Key Takeaways Explain This Topic AI
Secure Inputs and Secure Outputs mask a step's values in run history but do not change how or where the underlying data is stored.
A Dataverse environment variable with the Secret data type stores only a reference; the actual value lives in an Azure Key Vault.
Linking an environment to Key Vault requires a Microsoft Entra ID app registration granted Get and List permissions on the vault's secrets.
The Azure Key Vault connector's Get secret action can retrieve values directly inside a flow beyond the environment-variable model.
Secure Inputs/Outputs and Key Vault-backed environment variables are complementary: one protects run-history display, the other protects at-rest storage.
Last updated: July 2026
Cloud flows routinely handle values that should never appear in plain text inside a run's history — passwords, API keys, personally identifiable data, connection secrets. PL-400 candidates need to know both of the platform's protective mechanisms: masking values in the UI, and keeping secrets out of Dataverse entirely by referencing Azure Key Vault.
Secure Inputs and Secure Outputs
Every trigger and action exposes Settings → Secure Inputs and Secure Outputs toggles. Enabling Secure Inputs masks the values sent into that step in the flow's run history; enabling Secure Outputs masks the values that step returns. Once enabled, anyone viewing a run — including someone with edit access to the flow itself — sees "Content not shown due to security configuration" instead of the actual value.
This is purely a run-history display control : it prevents accidental exposure to people reviewing logs, but it does not change how or where the platform stores the underlying data, and it does not reduce what data the step is allowed to process. A developer should still avoid passing sensitive values through more steps than necessary, and should enable Secure Inputs/Outputs on every action in the chain that touches the sensitive value — masking only the final action leaves the value visible in every earlier step's output.
Azure Key Vault-Backed Environment Variables
Dataverse environment variables (introduced with solution ALM) support a Secret data type. Unlike Text, Number, JSON, or Yes/No variables, a Secret-typed environment variable does not store its value inside a Dataverse table row at all — it stores a reference to a secret held in an Azure Key Vault , and the actual value is resolved from the vault only at the moment a flow, plug-in, or other component requests it.
Setting this up requires:
An Azure Key Vault in the same tenant.
A Microsoft Entra ID app registration (service principal) with a client secret or certificate.
An access policy on the vault granting that app registration Get and List permissions on secrets.
Linking the Dataverse environment to the vault (once per environment) so environment variables of type Secret know where to resolve their value.
Referencing Secrets in a Flow
Once configured, a flow retrieves a Key Vault-backed value the same way it retrieves any environment variable — through the environment variable dynamic content — without ever displaying the raw secret in the flow definition. For secrets that live outside the environment-variable model, such as an external service's API key used ad hoc, the flow can call the Azure Key Vault connector directly, using actions like Get secret , to pull a value at runtime rather than hardcoding it into an HTTP action's headers or a connection string.
Why This Matters for ALM
Environment variables and connection references are specifically designed so a solution can move between Dev, Test, and Production without editing flow internals — but a plain-Text environment variable holding a password would export that password inside the solution's XML the moment the solution is exported. Backing sensitive values with Secret -typed environment variables tied to Key Vault keeps the actual credential out of the solution package entirely; only the reference travels with the solution, and each environment's own Key Vault link resolves it locally.
- Mechanism Protects Scope
- Secure Inputs/Outputs Values shown in run history Per-action, per flow run
Key Vault-backed environment variable Where the secret value is stored at rest Per-environment, travels with the solution as a reference only
Both mechanisms are complementary, not substitutes: a flow can retrieve a Key Vault secret through an environment variable and still need Secure Outputs enabled on the action that retrieves it, since fetching the secret is itself an action whose output should not appear in plain text in run history.
Rotating a Secret Without Touching the Flow
Because a Secret-typed environment variable stores only a reference to a vault entry rather than the value itself, rotating the underlying credential is a Key Vault operation, not a flow-maintenance task. An administrator updates the secret in Azure Key Vault, and every flow, plug-in, or component that resolves that environment variable picks up the new value on its next run — with no flow to edit, no solution to re-export, and no downtime for the makers who built the automation. This is a meaningful advantage over a Text-typed environment variable holding a password directly, where rotating the credential means editing and republishing the variable's current value in every environment it exists in.
A Common Design Mistake to Avoid
A frequent anti-pattern is pasting an API key straight into an HTTP action's header or a custom connector's connection parameters "just to get it working," then leaving it there. Beyond the security exposure, this couples the credential to a single environment and a single flow definition, defeating the entire purpose of environment variables and connection references for ALM. The exam expects a developer to recognize this pattern as a defect and to redesign it as a Secret environment variable (for a value the platform resolves automatically) or an explicit Get secret call to the Azure Key Vault connector (for a value fetched programmatically at runtime), rather than a value hardcoded into the flow's JSON definition.