Implement Azure security practice questions

Enable Microsoft Entra ID authentication and use SAS tokens with a stored access policy

Why it fails: Microsoft Entra ID authentication is enabled, but SAS tokens with a stored access policy still rely on account keys, violating the requirement to disable shared keys.

Enable firewall and virtual network service endpoints, then assign RBAC roles

Why it fails: Firewalls and virtual network service endpoints control network access but do not restrict authentication methods; shared keys could still be used.

Use user-delegation SAS tokens and disable shared key access

Why it fails: User-delegation SAS tokens are signed with Microsoft Entra ID credentials, but they can be used by anyone possessing the token, not only authorized Entra ID users. Additionally, disabling shared key access alone does not enforce Entra ID authentication; RBAC roles are still needed.

Configure IP firewall rules to allow the subnet IP range and add the Azure portal's public IP addresses.

Why it fails: This is possible but less secure and harder to maintain as portal IPs can change. Also, it does not use network security boundary of the virtual network.

Configure a private endpoint for the storage account and disable public network access.

Why it fails: Configuring a private endpoint and disabling public network access fails because the Azure portal requires public network access for management operations, such as viewing containers, even when authenticated via Microsoft Entra ID. Disabling public access would therefore block this functionality. While a private endpoint successfully restricts data plane access to a virtual network, fulfilling the subnet requirement, it is intended for scenarios where all access, including management, originates from within the VNet, ensuring complete isolation from the public internet.

Configure IP ACLs to allow the subnet and also allow all Azure services.

Why it fails: Allowing all Azure services is overly permissive and does not leverage the virtual network boundary.

Key Vault Reader

Why it fails: Key Vault Reader permits reading vault metadata such as properties and tags, but not the secret value itself, so the app cannot retrieve the connection secret. It would be correct for inventory or auditing tasks that only enumerate vault objects.

Key Vault Secrets Officer

Why it fails: Secrets Officer grants create, read, update and delete rights over secret contents, exceeding the read-only requirement. It is tempting because it does include read access, and would be correct where the identity must rotate or manage secrets rather than merely consume one.

Key Vault Contributor

Why it fails: Key Vault Contributor permits managing the vault itself, including deleting secrets, rather than reading secret values, so it grants excessive control without the data-plane access needed. It tempts because Contributor sounds like full access, and it suits administrators provisioning vaults rather than apps consuming secrets.

The user's display name is present

Why it fails: While a user's display name might be present in claims like `name` or `preferred_username`, its existence or specific value is not a security validation control for the token itself. The API's primary security concern is the token's cryptographic validity and authorization claims, not the presence of user-friendly attributes. An API should not reject a token solely because a display name is missing, nor trust it solely because one is present.

The token was sent in a query string

Why it fails: Transmitting sensitive JWT access tokens in a URL query string is a significant security vulnerability and should never be accepted. Query string parameters are often logged by web servers, proxies, and browser histories, making the token highly susceptible to exposure and interception. Bearer tokens must always be sent securely within the `Authorization` header using the `Bearer` scheme to prevent such leakage.

Password hash synchronization

Why it fails: Password hash synchronization replicates on-premises directory credentials into Microsoft Entra ID for interactive user sign-in; it grants no application permissions and cannot authenticate a daemon. It is chosen when hybrid users need identical credentials across both directories.

Delegated permissions only

Why it fails: Delegated permissions act on behalf of a signed-in user, and the background service has none, so no token can be issued. Delegated permissions are correct for apps calling Microsoft Graph as the signed-in user, such as a web portal reading their mail.

Device code flow

Why it fails: Device code flow still requires a human to authenticate at a verification URL, so no signed-in user means it cannot run unattended. It suits input-constrained devices such as CLI tools or smart TVs where a user completes sign-in elsewhere.

Managed Identity: A secret key used to authenticate to Azure SQL Database

Why it fails: This statement is incorrect because a Managed Identity is not a secret key; rather, it is an identity in Microsoft Entra ID that *eliminates* the need for managing secret keys. While a Managed Identity can be used to authenticate to Azure SQL Database, it does so by leveraging Microsoft Entra ID authentication, where Azure SQL Database trusts Microsoft Entra ID for identity verification. The concept of a 'secret key' for authentication typically refers to connection strings or manually managed application secrets, which Managed Identities are designed to replace.

Service Principal: A user account in Microsoft Entra ID for human users

Why it fails: This statement is incorrect because a Service Principal is specifically designed as an identity for applications, services, or automated tools, not for human users. Human users in Microsoft Entra ID are represented by 'user accounts,' which have distinct properties and are managed differently, often involving multi-factor authentication and password policies. Service Principals enable programmatic, non-interactive access to Azure resources, distinguishing them fundamentally from human-centric user accounts.

Kubernetes Secrets with a CronJob to update them

Why it fails: Kubernetes Secrets, by default, are only base64 encoded, not encrypted at rest in etcd, making them inherently less secure for highly sensitive data. Implementing secret rotation using a custom CronJob introduces significant operational complexity, potential security vulnerabilities, and a high risk of misconfiguration or service disruption. This approach also places the burden of secret lifecycle management directly on the application team, deviating from best practices for centralized secret management.

Azure Managed Identity for the pod

Why it fails: Azure Managed Identity for the pod provides an identity for applications to authenticate to Microsoft Entra ID-protected resources without requiring developers to manage credentials. While essential for enabling secure access to services like Azure Key Vault, Managed Identity itself does not store, manage, or rotate secrets. It serves as the secure authentication mechanism that allows a pod to access a secret store, rather than being a secret storage or rotation solution in its own right.

Azure App Configuration with a managed identity

Why it fails: Azure App Configuration is primarily designed for centralized management of application settings, feature flags, and dynamic configuration values. Although it can store configuration data that might include non-sensitive connection strings, it lacks the dedicated security features, robust auditing capabilities, and built-in automatic rotation mechanisms specifically engineered for highly sensitive secrets. Using App Configuration for secret rotation would be an anti-pattern, as it's not its intended secure secret management purpose.

Configure a service hook to validate signatures using Azure Functions

Why it fails: Service hooks in Azure DevOps are designed to integrate with external services by sending notifications or triggering workflows *after* specific events occur, such as a pull request completion. While an Azure Function could be invoked to validate signatures, a service hook cannot inherently *block* a merge operation based on the validation outcome. It lacks the direct enforcement capability within the pull request merge process to prevent an unsigned commit from being integrated into the target branch.

Use Azure Policy to require code signing on the repository

Why it fails: Azure Policy is a governance tool primarily focused on enforcing standards and assessing compliance for Azure resources, such as virtual machines, storage accounts, and networking components. It operates at the management group, subscription, or resource group scope and is not designed to interact with or enforce policies within the internal operations of an Azure DevOps Git repository. Therefore, it cannot be used to directly mandate or validate commit signing requirements for source code.

Add a build validation step in the PR pipeline that checks signatures

Why it fails: Adding a build validation step to a pull request pipeline allows for automated checks, like compiling code or running tests, before a merge is permitted. While a custom script within this pipeline could theoretically check for commit signatures, this validation runs *prior* to the final merge decision and does not inherently enforce the signature requirement at the point of merge. If the branch policy itself doesn't mandate signed commits, an unsigned commit could still be merged once the build validation passes, or if the policy is bypassed.

Audit

Why it fails: Audit only records non-compliant resources in the compliance dashboard; it never changes configuration, so ADS remains disabled. It is tempting because it is the standard effect for visibility and reporting, and would be correct where the requirement is merely to detect and evidence non-compliance rather than remediate it.

Modify

Why it fails: Modify applies alterations during evaluation but is intended for tags, SKUs and similar resource properties, and cannot enable Advanced Data Security, which requires a DeployIfNotExists effect to invoke an ARM template remediation task. Modify would be correct for adding or inheriting simple property values on resources.

Deny

Why it fails: Deny blocks creation or update of non-compliant resources, so existing databases with ADS disabled stay unchanged and no automatic enablement occurs. It is tempting because it enforces compliance at deployment time, and would be correct when the goal is preventing new non-compliant resources rather than remediating existing ones.

Microsoft.Storage/storageAccounts/read

Why it fails: This is a management action for reading storage account properties, not blob data.

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

Why it fails: This permission is already included in the role; it allows reading blob content but not listing blobs.

Microsoft.Storage/storageAccounts/blobServices/containers/read

Why it fails: This is an ARM action for listing containers, not for listing blobs.

Generate a shared access signature (SAS) for the container

Why it fails: SAS tokens can be shared and do not restrict to tenant users.

Configure a network firewall to allow only your tenant's IP range

Why it fails: IP-based rules do not authenticate users.

Use storage account access keys and distribute them to users

Why it fails: Access keys grant full account access and are not user-specific.

Azure App Configuration

Why it fails: Azure App Configuration is primarily designed for centralized management of application settings and feature flags, offering dynamic configuration updates without redeploying applications. While it can store configuration values, its capability to manage secrets typically involves storing references to secrets held within Azure Key Vault. This integration allows applications to retrieve both configuration and sensitive data securely from a single endpoint, promoting separation of concerns and enhancing operational efficiency.

Microsoft Entra ID Certificate Services

Why it fails: Microsoft Entra ID Certificate Services (AD CS) refers to the on-premises Public Key Infrastructure (PKI) role that issues and manages digital certificates within an enterprise. While certificates are a type of secret, this service's primary function is to establish trust and secure communication through certificate issuance and revocation for identity verification. It does not provide a centralized repository for general application secrets like API keys or database connection strings, which is the domain of services like Azure Key Vault.

Azure Policy

Why it fails: Azure Policy is a governance tool used to enforce organizational standards and assess compliance across Azure resources. It defines rules and effects to ensure resources adhere to specific configurations, such as requiring Key Vault for secret storage or auditing non-compliant settings. Azure Policy's role is to control and audit resource configurations, not to store or manage secrets or certificates itself.

Key Vault Crypto User role

Why it fails: Key Vault Crypto User role is for cryptographic operations (e.g., encrypt/decrypt) and does not grant permissions to read secret values, so it is incorrect.

Key Vault Secrets Officer role (includes all operations)

Why it fails: Key Vault Secrets Officer role includes all operations on secrets, including 'get' and 'list', so it does allow reading secrets. Although it is more permissive than necessary, it is technically correct for this requirement.

Key Vault Reader role

Why it fails: Key Vault Reader role only allows reading metadata about Key Vault resources (e.g., listing names) but does not grant access to read the actual secret values, so it is incorrect.

Improved application performance by caching secrets.

Why it fails: Azure Key Vault itself does not inherently provide a caching mechanism for secrets to improve application performance. While applications might implement their own client-side caching of retrieved secrets to reduce latency and the number of Key Vault calls, this is an application-level optimization, not a direct feature or benefit provided by the Azure Key Vault service. Key Vault's primary role is secure storage and access control, not performance enhancement through built-in caching.

Integration with Azure DevOps for automatic secret rotation in pipelines.

Why it fails: While Azure Key Vault can be integrated with Azure DevOps pipelines (e.g., using the Azure Key Vault task to fetch secrets) and supports secret rotation capabilities, the automatic rotation specifically within pipelines is not an inherent benefit of Key Vault itself. Key Vault provides the secure storage and APIs for rotation, but the orchestration of *automatic rotation within a DevOps pipeline* requires additional scripting, external automation, or specific tooling configured within the pipeline, rather than being a direct, built-in feature of Key Vault.

Automatic encryption of secrets at rest and in transit.

Why it fails: Azure Key Vault indeed automatically encrypts secrets at rest using FIPS 140-2 validated hardware security modules (HSMs) or software, and data in transit is protected by TLS. However, while crucial for security, this is a fundamental security feature expected of any secure secret management service, rather than a distinct benefit that differentiates it or is its sole purpose. The question asks for *benefits* of *using* Key Vault, implying advantages beyond basic security hygiene that are common to secure storage solutions.

Azure Monitor Log Analytics workspaces.

Why it fails: Azure Monitor Log Analytics workspaces are primarily designed for collecting, analyzing, and querying operational logs and metrics for monitoring, diagnostics, and troubleshooting purposes. While they offer robust querying capabilities, logs stored within Log Analytics are not inherently immutable by default and can be modified or deleted by users with appropriate permissions, making them unsuitable for strict tamper-proof audit requirements where data integrity and non-repudiation are critical for compliance.

Microsoft Sentinel.

Why it fails: Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution. Its core purpose is to provide intelligent security analytics across an enterprise, detecting threats, investigating incidents, and automating responses. While Sentinel ingests vast amounts of log data, its primary function is not to provide tamper-proof, long-term audit log retention for compliance, but rather to identify and act on security events.

Microsoft Purview Audit (Premium).

Why it fails: Microsoft Purview Audit (Premium) is specifically engineered to provide comprehensive, tamper-proof audit logging across Microsoft 365 services, including integrated Azure activities, to meet stringent regulatory and compliance requirements. It offers advanced auditing capabilities such as high-value event logging, long-term retention of audit records (up to 10 years), and forensic investigation tools, ensuring the integrity and immutability of audit trails crucial for legal hold and compliance mandates.

Enforce TLS 1.2 for all client connections.

Why it fails: Enforcing TLS 1.2 for all client connections is a vital security practice, but it specifically protects data in transit between the client application and the Azure Cosmos DB service. TLS (Transport Layer Security) encrypts network communications, preventing eavesdropping and tampering during data transmission over the internet or private networks. However, once the data reaches the Cosmos DB storage and is persisted, TLS no longer applies; it does not provide protection for data at rest on the storage media itself.

Deploy Azure Firewall in front of the Cosmos DB account.

Why it fails: Deploying Azure Firewall in front of an Azure Cosmos DB account is a network security measure designed to filter and control inbound and outbound network traffic to and from the Cosmos DB endpoint. While a firewall enhances overall security by restricting network access to authorized sources and preventing network-based attacks, it operates at the network perimeter. It does not directly encrypt or protect the data once it has been successfully written and stored within the Cosmos DB service; thus, it does not safeguard data at rest.

Client secret

Why it fails: Not required if using client credentials flow or other methods.

Tenant ID

Why it fails: Tenant ID is part of the issuer URL.

Assign the same role to other users

Why it fails: Assigning roles requires Microsoft.Authorization/roleAssignments/write.

Delete secrets from Key Vaults in the resource group

Why it fails: Delete requires Microsoft.KeyVault/vaults/secrets/delete.

Create new Key Vaults in the resource group

Why it fails: Create requires write permission (Microsoft.KeyVault/vaults/write).

Use the UseAuthentication middleware to validate tokens

Why it fails: The UseAuthentication middleware is responsible for validating the incoming JSON Web Token (JWT) from Microsoft Entra ID, ensuring its signature, expiry, and issuer are valid. It then constructs the `HttpContext.User` principal based on the token's contents, including all claims. While essential for establishing identity, `UseAuthentication` does not perform any authorization checks against specific claims; its role is purely authentication.

Use the [Authorize] attribute with a policy that requires a specific claim

Why it fails: This is the correct and recommended approach in ASP.NET Core for claim-based authorization. By applying the `[Authorize]` attribute with a named policy, you instruct the authorization middleware to evaluate specific requirements defined within that policy. The policy is configured to demand the presence and/or a specific value of a particular claim, ensuring that only authenticated users possessing the required claim can successfully access the protected resource.

Manually parse the JWT in a custom middleware

Why it fails: Manually parsing the JWT in custom middleware bypasses the built-in policy-based authorisation pipeline that integrates with Microsoft Entra ID, meaning claims are checked outside the framework’s `[Authorize]` attribute and `IAuthorizationHandler` system, which is the intended mechanism for claim-based access control. This approach is tempting because it gives full control over token inspection and would be correct if the requirement were to validate a custom token format or perform non-standard cryptographic checks that the default middleware cannot handle.

Inject secrets as environment variables from ConfigMaps.

Why it fails: Injecting secrets as environment variables from ConfigMaps is a significant security vulnerability. ConfigMaps are designed for non-confidential configuration data and store information unencrypted in etcd, making it easily accessible to anyone with cluster access. Exposing sensitive data like API keys or database credentials directly in pod environment variables allows simple inspection and retrieval, completely undermining security best practices for secret management.

Use Kubernetes Secrets with a scheduled CronJob to rotate them.

Why it fails: Using Kubernetes Secrets with a scheduled CronJob for rotation is an insecure and operationally complex approach. Kubernetes Secrets are merely base64-encoded, not encrypted at rest by default within etcd, meaning they are vulnerable if the underlying storage is compromised. While a CronJob could attempt rotation, this requires a custom, error-prone implementation that lacks the robust security features, auditing, and lifecycle management provided by a dedicated secret management solution.