Secure API Key Storage in Azure App Service
Short answer
A Storing the API key as an App Service application setting securely injects it at runtime without exposing it in the source repository or Git history.
Question
After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear on the review screen.
You plan to deploy a container to an Azure App Service API app named api1. You host the source code for api1 in a GitHub repository. The container uses the API key at runtime to connect to a backend service.
The container must be able to retrieve the API key at runtime without exposing it in the source repository or Git commit history.
You need to ensure that the API key remains outside of Git commit history and is available to the container at runtime.
Solution: Store the API key as an App Service application setting configured through the Azure Portal.
Does the solution meet the goal?
Key Takeaways
The core concept is preventing secret leakage in source control; the trap is assuming only Key Vault is acceptable when App Service settings provide sufficient isolation from Git history.
This question evaluates the best practices for managing secrets like API keys in Azure App Service environments. It establishes that application settings are a valid and secure method for runtime configuration.
Common mistake: Learners often select 'No' because they believe Azure Key Vault is the mandatory standard for all secrets, overlooking that App Service Application Settings are natively designed for this purpose and do not persist in code repositories.
Expert Analysis
Why the Answer Is Correct
Storing the API key as an App Service application setting ensures it is stored securely within the Azure environment and injected into the container at runtime via environment variables. Crucially, these settings are managed through the Azure Portal or CLI/ARM templates, meaning the value never resides in the GitHub repository or its commit history. This satisfies the requirement to keep the key out of source control while making it available to the application.
Why the Other Options Are Wrong
There is only one other option, "No." Selecting "No" implies that storing the key in App Service settings is insecure or does not meet the goal. However, since the goal is specifically about keeping the key out of Git history (which it is) and making it available at runtime (which it does), the solution is valid. While Key Vault is a more advanced option for centralized management, it is not strictly required to meet this specific constraint.
Community Comment Notes
One community comment notes that while Key Vault might be "preferrable" for broader secret management architectures, using App Service settings is still a "valid approach" for this scenario. This reinforces that the exam accepts native App Service configurations as correct solutions when they meet the stated requirements.
Exam Strategy
When asked about securing secrets in PaaS offerings like App Service, remember that Application Settings and Connection Strings are built-in secure storage mechanisms. They are distinct from your codebase, so using them prevents accidental commits to Git.
Frequently Asked Questions
Why isn't Key Vault required here?
How does the container access the setting?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
insanewriters 👍 1 Answered AIt's preferrable to use KV, but this is a valid approach.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.