What Is Secure file in DevOps?
On This Page
Quick Definition
A secure file is a way to store sensitive data, such as private keys or certificates, in Azure DevOps. It keeps these files encrypted and allows only specific pipelines or users to access them. This prevents secrets from being exposed in your code repository or build logs. You can upload, manage, and use secure files during automated builds and releases.
Commonly Confused With
Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates at runtime from applications. Secure files are specifically for storing files used during build and release pipelines in Azure DevOps. While both protect sensitive data, secure files are integrated directly into pipeline tasks, whereas Key Vault requires enabling secret access and retrieving secrets via code or task.
You use Key Vault to store a database password that your web app reads at startup. You use a secure file to store a .pfx certificate that your build pipeline uses to sign a mobile app during compilation.
Secret pipeline variables store short text strings like API keys and are masked in logs. Secure files store entire files (binary or text) like certificates or provisioning profiles. Pipeline variables can be set at queue time and are easier to use for simple values, but they cannot store binary data or large files.
You use a secret variable for an Azure subscription service connection password. You use a secure file for an Apple distribution certificate that is a binary .p12 file.
Storing a sensitive file in a Git repository means the file is versioned, potentially visible to all developers, and impossible to delete from history entirely. Secure files are stored outside of Git, encrypted, and access can be audited and restricted.
Instead of committing a private SSH key to your GitHub repo (bad practice), you upload it as a secure file and reference it in your deployment pipeline.
Must Know for Exams
The concept of secure files is most directly relevant to the Microsoft Azure DevOps Solutions (AZ-400) exam, where it appears under the 'Manage source control' and 'Implement a build strategy' objectives. Candidates should understand how to configure secure files within a pipeline, set permissions, and integrate file downloads into build tasks. The AZ-104 (Azure Administrator) exam also touches on secure files when discussing Azure Pipelines integration, though at a lighter level.
For general IT certifications like CompTIA Security+, the underlying principle of secret management is tested, but secure files specifically are covered only as a peripheral example of Azure DevOps security features. In AZ-400 exam questions, you might see scenarios asking which method to use for storing a signing certificate during a build. The correct answer will often point to secure files rather than storing the certificate in source control or as a pipeline variable.
Another common question type involves troubleshooting a failed build that cannot access a secure file, requiring you to check permissions on the file in the library. You should also know that secure files can be shared across multiple pipelines but require explicit permission for each. Exam questions rarely ask for the encryption details but will focus on the use case, access control, and how to reference a secure file in a YAML pipeline using the DownloadSecureFile task.
For Security+ candidates, the exam emphasizes the principle of separating secrets from code, which aligns perfectly with the secure file concept, even if the specific Azure DevOps term is not tested.
Simple Meaning
Think of a secure file like a locked drawer in a shared office. In an office, many people need to use common supplies like pens and paper, but you also have important documents like contracts or payroll records that should only be accessible to certain people. The locked drawer keeps those sensitive papers safe, and only authorized staff have the key.
In Azure DevOps, a secure file is that locked drawer for your digital projects. You upload files like certificates, signing keys, or configuration secrets into Azure Pipelines. These files are encrypted and stored in the cloud, not in your source code where anyone could see them.
Only the pipelines and users you specifically authorize can access or download these files. For example, if your build process needs a private key to sign a mobile app, you upload that key as a secure file. Your build pipeline can then use it during the build without the key ever appearing in your code, logs, or version control history.
This keeps your sensitive information safe even if someone gains access to your repository. It also helps you follow security best practices by separating secrets from code. Managing secure files is done through the Azure DevOps web interface or using REST APIs, giving you fine-grained control over who and what can access each file.
Full Technical Definition
A secure file in Azure DevOps is a protected storage mechanism designed to hold sensitive binary or text files that are required during build and release pipelines but must not be exposed in version control. These files include, but are not limited to, PFX certificates, Apple Developer signing identities, SSH keys, provisioning profiles, and private configuration files. The secure file service stores each file encrypted at rest using Azure Key Vault-managed keys, ensuring that the file content is never stored in plaintext within the Azure DevOps database.
When a file is uploaded, it is assigned a unique identifier and versioned. Azure DevOps provides a dedicated library section under Pipelines where users can manage secure files. Access control is managed via Azure DevOps security groups and permissions. You can grant Read, Write, or Manage permissions to individual users or entire teams. During pipeline execution, a secure file can be referenced using a special task called the Download Secure File task, which downloads a temporary copy of the file to the agent's workspace for the duration of the job. The file is automatically deleted from the agent after the job completes, minimizing exposure.
Technically, the Download Secure File task uses a secure connection to the Azure DevOps backend, authenticated via the pipeline's OAuth token, to request the file. The file is transmitted over HTTPS to the pipeline agent, which writes it to a temporary location. The agent's environment variables do not contain the file path unless explicitly set by the task. To further secure the content, Azure DevOps allows you to define variable-level restrictions, such as making the file available only for certain release pipelines or build definitions. The secure file service integrates with Azure Pipelines, Azure DevOps Server (on-premises), and also supports multi-stage YAML pipelines.
From a compliance perspective, using secure files helps meet standards such as SOC2, ISO 27001, and PCI DSS by ensuring that secrets are not embedded in code. Audit logs capture every download or modification of secure files, providing traceability. The system also supports file replacement, meaning you can update a certificate without altering any pipeline definitions, as the pipeline simply references the file by its logical name. This decoupling of secrets from pipeline logic is a fundamental principle of secure DevOps (DevSecOps).
Real-Life Example
Imagine you are a manager of a large apartment building. You have a master key box that holds keys to every apartment. You also have a separate, locked fire safe that contains the building's insurance documents, emergency contact lists, and the master key to the key box itself. You don't give every maintenance person the code to the fire safe. Instead, only the building owner and you know the combination. When a plumber needs to fix a pipe in apartment 3B, you open the fire safe, take out the master key, open the key box, and hand the plumber only the key to apartment 3B for that day. The plumber never sees the master key box or the fire safe combination.
In this analogy, the fire safe is the secure file storage. The insurance documents and master key are your sensitive files (certificates, signing keys). You (the pipeline) have the authority to access the safe only when needed. The key box with apartment keys represents other non-sensitive resources. By keeping the master key and documents locked away, you prevent unauthorized access even if someone gets access to the key box. Similarly, in Azure DevOps, secure files are stored encrypted, and only authorized pipelines can temporarily download them for a specific task. After the task (like code signing), the file is erased from the build agent, just like the plumber returns the apartment key at the end of the day.
Why This Term Matters
In real-world IT operations, security breaches often happen because sensitive data like passwords, certificates, and API keys end up in source code repositories or build logs. Once exposed, attackers can use that information to impersonate services, steal data, or inject malware into production. Secure files directly address this by providing a centralized, encrypted vault for such assets within Azure DevOps.
For a DevOps engineer, using secure files means you no longer have to worry about accidentally committing a .pfx certificate to a GitHub repo or having a private key visible in a build output. It enforces the principle of least privilege because you can grant access only to specific pipelines and specific users.
This is crucial for organizations that must pass compliance audits or follow regulations like HIPAA or GDPR. Secure files also simplify certificate rotation. Instead of updating every pipeline definition and build script when a certificate expires, you simply upload the new certificate with the same filename to the secure file library, and all pipelines automatically use the updated version.
This saves time and reduces human error. Since secure files are versioned, you can always roll back to a previous version if a certificate update causes issues. Secure files are not just a nice-to-have feature; they are a fundamental component of a secure software supply chain, reducing risk and operational overhead for any team using Azure DevOps.
How It Appears in Exam Questions
In Azure DevOps certification exams, secure file questions typically fall into three patterns: scenario-based, configuration, and troubleshooting.
Scenario-based questions present a situation where a team needs to use a sensitive file, such as a PFX certificate for code signing, during a build pipeline. The question asks which Azure DevOps feature should be used. The distractors might include 'Pipeline variables', 'Azure Key Vault', 'Source control', or 'Manual upload'. The correct answer is 'Secure files' because it is designed exactly for this purpose. Another variant asks which task should be added to the pipeline to retrieve the file. The answer is 'Download Secure File task'.
Configuration questions test your knowledge of how to set up secure files. For example, you may be asked to set permissions so that only the Release pipeline can access a particular provisioning profile. You would need to modify the security settings of the secure file in the Library tab, removing default access for other pipelines and granting read access to the specific release definition.
Troubleshooting questions describe a failed build with an error like 'Could not find secure file with ID X' or 'Access denied to secure file'. You must identify the cause. Common causes include: the file was deleted from the library, the pipeline agent identity lacks permission, or the file path referenced in the pipeline is wrong. You might also see questions where a secure file download works in the development pipeline but fails in the production pipeline, which often indicates a missing permission assignment for the production pipeline.
Practise Secure file Questions
Test your understanding with exam-style practice questions.
Example Scenario
A mobile development team at a company called AppFlow is building an iOS application. To distribute the app to testers, they need a distribution certificate and a provisioning profile from Apple. These files are sensitive because if someone unauthorized gets them, they could sign malware as AppFlow.
The team stores the .p12 certificate and .mobileprovision file as secure files in their Azure DevOps project. In their pipeline, they add a 'Download Secure File' task for each file, binding them to variables like $(Certificate) and $(ProvisioningProfile).
Then they use a 'CocoaPods' or 'Xcode Build' task that references these variables. The build agent downloads the files only during the build and deletes them after, so no sensitive data lingers on the build machine. One developer accidentally commits a test certificate to the repo.
Because the real production certificate is stored as a secure file, that mistake does not expose the production signing identity. The security team is happy because audit logs show exactly which pipeline downloaded the secure file and when. This scenario illustrates how secure files protect real assets and simplify audit compliance.
Common Mistakes
Storing a certificate as a pipeline variable instead of a secure file.
Pipeline variables can be printed in logs or exported by a developer with edit permissions. They are not encrypted at rest in the same way as secure files.
Always use secure files for binary certificate files and large secrets. Use pipeline variables for short strings like connection strings (and even then, mark them as secret).
Granting 'Read' permission to all pipelines by default on a secure file.
This violates the principle of least privilege. Any pipeline, even test builds, could download the file, increasing the risk of exposure.
By default, set secure file permissions to 'No access' for all pipelines, then explicitly grant read access only to the specific pipelines that need it.
Hardcoding the secure file ID in the pipeline YAML instead of using the file's logical name.
If the file is replaced with a new version, the ID may change, breaking the pipeline. Logical names remain constant across versions.
Reference secure files by their name using the DownloadSecureFile@1 task, which allows you to specify the filename and handles versioning automatically.
Assuming secure files are automatically available to all agents in a private pool.
Secure files are stored in Azure DevOps and must be downloaded explicitly. They are not pre-deployed to agents.
Always include the DownloadSecureFile task in your pipeline before any task that needs the file.
Exam Trap — Don't Get Fooled
{"trap":"Using Azure Key Vault instead of secure files for a PFX certificate used in a build pipeline.","why_learners_choose_it":"Azure Key Vault is commonly known for storing secrets, and learners may think it is the only or best option for certificates.","how_to_avoid_it":"Remember that Azure Key Vault is ideal for secrets accessed at runtime by applications, but for build-time assets like code-signing certificates, secure files are more appropriate because they are directly consumable by pipeline tasks.
Key Vault integration requires additional steps and might not be supported by all build task types."
Step-by-Step Breakdown
Upload the secure file
Navigate to Pipelines > Library > Secure files tab in Azure DevOps. Click '+ Secure File' and select the file from your local machine. The file is encrypted and stored. You can optionally rename it for clarity. This step establishes the secure storage.
Set permissions on the secure file
After upload, click on the file, then go to the 'Security' tab. Remove default access for all pipelines and users. Then add specific pipelines (by name) and users that need read access. This enforces least privilege.
Add the Download Secure File task to your pipeline
In your build or release pipeline, add the 'Download Secure File' task. Specify the file name exactly as it appears in the library. This task downloads the file to the agent's temporary directory and exposes its path via a variable.
Use the downloaded file in subsequent tasks
The Download Secure File task outputs a variable like $(Agent.TempDirectory)/filename.ext. You reference this path in other tasks (e.g., a signing task). The file is available only for the duration of the job.
Pipeline runs and file is cleaned up
When the job completes, Azure DevOps automatically deletes the temporary copy of the secure file from the build agent. Even if the agent is compromised later, the secret file is not left behind. This ensures no residual exposure.
Practical Mini-Lesson
In practice, secure files are used most often for code signing and deployment scenarios. For example, if you build an Android app, you need a keystore file (.jks) to sign the APK. Uploading that keystore as a secure file keeps it safe.
In your pipeline, you add the DownloadSecureFile task and set a variable to the download path. Then you use an Android Signing task that references that variable. A common pitfall is forgetting that the secure file is downloaded to a different location on hosted agents versus self-hosted agents.
On Microsoft-hosted agents, the temporary path is usually $(Agent.TempDirectory). On self-hosted agents, the path depends on the agent configuration. Always use the variable output from the DownloadSecureFile task rather than hardcoding paths.
Another professional practice is to use secure files for configuration files that contain secrets, such as a web.config with connection strings for a staging environment. You upload the config as a secure file and then use a file copy task to place it in the correct location during deployment.
This avoids storing different configs for each environment in source control. What can go wrong? Permissions are the most common issue. If a new pipeline is created but not explicitly granted access to the secure file, the download will fail.
Also, if you update the secure file with a new version, existing pipelines that reference the file by name will automatically get the new version. This is good, but it means you must test the new file in a separate pipeline first before updating the shared file. Professionals often use separate secure file instances for development, staging, and production environments to prevent accidental use of production certificates in a test build.
Memory Tip
Think 'S for Secure, S for Separate', secure files keep secrets separate from source code.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
Related Glossary Terms
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
AAA (Authentication, Authorization, and Accounting) is a security framework that controls who can access a network, what they are allowed to do, and tracks what they did.
A/B testing is a controlled experiment that compares two versions of a single variable to determine which one performs better against a predefined metric.
Frequently Asked Questions
Can I use a secure file in a YAML pipeline?
Yes, you use the DownloadSecureFile@1 task in your YAML pipeline. You specify the file name, and the task downloads it to the agent.
What types of files can be uploaded as secure files?
Any file type can be uploaded, but common examples include .pfx, .p12, .mobileprovision, .jks, and .config files. The service stores binary files as-is.
How do I update a secure file?
Go to Pipelines > Library > Secure files, select the file, and click 'Replace file'. The version is updated, and pipelines using the file name will automatically use the new version.
Are secure files encrypted?
Yes, secure files are encrypted at rest using Azure Key Vault and transmitted over HTTPS during download.
Can I download a secure file manually?
Yes, if you have 'Read' permission on the secure file, you can download it from the Library tab. Audit logs record the download.
Is there a limit to the number of secure files?
Azure DevOps has a limit of 1000 secure files per project. Each file can be up to 10 MB in size.
Summary
Secure files in Azure DevOps provide a dedicated, encrypted storage location for sensitive files used during automated builds and releases. They separate secrets like certificates, signing keys, and provisioning profiles from source code, reducing the risk of accidental exposure. The system allows granular permissions, audit logging, and versioning, making it a cornerstone of secure DevOps practices.
For IT certification learners, understanding secure files is essential for both Azure-specific exams like AZ-400 and for general security concepts like secret management. Key takeaways are that secure files are not the same as pipeline variables or Azure Key Vault, and that permissions must be explicitly configured. When you encounter a question about storing a certificate for a build, remember that secure files are the designed and correct choice.
By using secure files, you protect your organization's digital assets and demonstrate competency in modern, secure software delivery practices.