Select Two (Multi-Select) Questions

SFTP support

Why it fails: SFTP support for Azure Blob Storage enables secure file transfer using the SSH File Transfer Protocol, providing a familiar interface for data ingress and egress. However, its functionality is limited to the transport layer. Implementing SFTP does not inherently offer data protection features like versioning or recovery of deleted blobs, meaning it does not safeguard against accidental overwrites or deletions of product images by retaining previous states.

Static website hosting

Why it fails: Static website hosting in Azure Blob Storage allows serving static content directly from a storage container, typically for web applications or single-page applications. While it leverages blob storage, its primary function is content delivery and public accessibility, not data protection or version management. Enabling static website hosting does not provide any inherent mechanisms to recover previous versions of product images or prevent their accidental deletion, as it focuses on serving content rather than data resilience.

An Microsoft Entra ID (Microsoft Entra ID) tenant for employee identities

Why it fails: An Microsoft Entra ID (Microsoft Entra ID) tenant for employee identities is not required because Azure AD B2C operates within its own dedicated B2C tenant. This B2C tenant is specifically designed to manage external consumer identities and is distinct from a standard Microsoft Entra ID tenant used for an organization's internal employees. While both are Microsoft Entra services, a B2C implementation does not depend on or utilize an existing employee-focused Microsoft Entra ID tenant.

An Azure subscription

Why it fails: An Azure subscription is not strictly required for the creation or core functionality of an Azure AD B2C tenant itself. While an Azure subscription is typically linked for billing purposes and to manage other Azure resources that integrate with B2C, the B2C tenant can be provisioned and managed independently. Its fundamental operations and configuration are handled directly through the Azure portal or PowerShell, separate from subscription-bound resource deployments.

The restart policy for containers

Why it fails: Restart policy is a key differentiator. ACI supports Always, OnFailure, and Never restart policies, whereas AKS relies on pod-level restart policies which are more flexible but also more complex to configure. This is a factor to consider when choosing between the two services.

The need for GPU-accelerated compute

Why it fails: The need for GPU-accelerated compute is not a differentiating factor because both Azure Container Instances (ACI) and Azure Kubernetes Service (AKS) support GPU-enabled workloads. ACI allows specific container groups to be deployed on GPU-enabled SKUs, providing direct access to NVIDIA GPUs. Similarly, AKS supports GPU acceleration by enabling node pools with virtual machine sizes that include GPUs, allowing Kubernetes to schedule GPU-intensive pods effectively. Therefore, the mere requirement for GPU compute does not inherently favor one service over the other.

Enable Azure Defender for Storage

Why it fails: Enabling Azure Defender for Storage primarily provides advanced threat detection capabilities, such as identifying unusual access patterns, suspicious activities, or potential malware uploads. While it enhances overall security posture by generating security alerts and recommendations, it does not provide granular logging of all access requests (like successful reads/writes) nor does it function as a network firewall to restrict access to specific virtual networks or subnets. Therefore, it fails to meet the explicit requirements for comprehensive access logging and network-level access control.

Generate a SAS token and store it in the web app's configuration

Why it fails: Generating a Shared Access Signature (SAS) token and storing it in the web app's configuration introduces significant security risks and does not meet all requirements. SAS tokens are shared secrets that, if leaked, can grant unauthorized access to the storage account for their entire validity period, and their revocation can be complex. Furthermore, SAS tokens only provide authorization for specific operations; they do not inherently provide network-level access restriction, meaning they cannot block access from outside the web app's virtual network, failing a critical security requirement.

Store secrets in application settings as plain text

Why it fails: Storing secrets in application settings as plain text, whether in configuration files, environment variables, or deployment scripts, is a critical security anti-pattern. This method leaves sensitive information completely unencrypted and unprotected, making it highly vulnerable to exposure through source code repositories, compromised build pipelines, or unauthorized access to the application's host environment. It lacks any form of access control, auditing, or encryption, directly violating security best practices and compliance requirements.

Use Azure App Configuration for feature flags

Why it fails: Azure App Configuration is designed for managing application settings and feature flags in a centralized and dynamic manner, allowing for configuration changes without requiring application redeployments. While it can store configuration data, it is not engineered with the same level of security and specialized features as Azure Key Vault for high-value secrets. App Configuration lacks HSM-backed protection, advanced access policies tailored for secrets, and the comprehensive auditing capabilities necessary for truly sensitive data, making it unsuitable for storing critical credentials.

The user's display name is present

Why it fails: The presence of the user's display name (the 'name' claim) within a JWT is purely for informational or presentation purposes, such as personalizing a user interface. It does not serve as a security control or contribute to the cryptographic validation of the token's authenticity, integrity, or authorization. Whether this claim exists or is populated has no bearing on whether the token is valid or trustworthy from a security perspective, making it irrelevant for access control decisions.

The token was sent in a query string

Why it fails: Transmitting a sensitive access token within a URL's query string is a severe security vulnerability that should always be rejected. Query string parameters are frequently logged by web servers, proxies, and browsers, and can be exposed in browser history, referrer headers, and shared links, making the token highly susceptible to interception and replay attacks. Bearer tokens must exclusively be sent in the `Authorization` HTTP header to maintain confidentiality and prevent unauthorized access.

Azure Batch

Why it fails: Azure Batch is designed for running large-scale parallel and high-performance computing (HPC) applications efficiently in the cloud. While it manages compute resources for you, it requires defining and managing pools of virtual machines, which are then used to execute scheduled jobs. This model involves explicit resource provisioning and job scheduling rather than the automatic, event-driven scaling and complete infrastructure abstraction characteristic of serverless computing.

Azure Container Instances

Why it fails: Azure Container Instances (ACI) offers a fast and simple way to run containers in Azure without managing virtual machines or higher-level services. While ACI abstracts away the underlying server infrastructure, you still explicitly provision and manage individual container instances, defining their CPU and memory resources. It lacks the automatic, event-driven scaling and consumption-based billing model that defines true serverless computing, making it more of a container-as-a-service offering.

Azure Virtual Machines

Why it fails: Azure Virtual Machines (VMs) fall under the Infrastructure-as-a-Service (IaaS) category, providing complete control over the operating system and software stack. Implementing solutions with VMs requires manual provisioning, configuration, and ongoing management of the underlying servers, including patching, scaling, and maintenance. This hands-on server management and explicit resource allocation directly contradict the fundamental principles of serverless computing, which abstracts away all infrastructure concerns.

Azure SQL Database

Why it fails: Azure SQL Database is primarily designed for relational data storage and querying, not for secure application secret management. While data can be encrypted at rest, it lacks the specialized features of a dedicated secret store, such as granular access policies for individual secrets, automatic secret rotation, and comprehensive audit logging specifically tailored for secret access. Storing secrets directly in a database would complicate key management and increase the attack surface, making it an unsuitable choice for this purpose.

Azure Storage Account with encryption

Why it fails: Azure Storage Accounts are designed for storing large amounts of unstructured data like blobs, files, queues, and tables, and they offer encryption at rest and in transit. However, they are not optimized for managing application secrets due to their lack of granular, secret-specific access policies and robust audit logging capabilities tailored for individual secret access. While data can be secured, a storage account does not provide the specialized secret lifecycle management or the fine-grained control over who can access *specific* secrets that a dedicated secret store offers.

Azure App Configuration

Why it fails: Azure App Configuration is designed to centralize application settings and feature flags, providing dynamic configuration management for applications. While it can store configuration values, it is not intended as a secure secret store and does not encrypt values by default. For sensitive information, App Configuration typically integrates with Azure Key Vault to reference secrets, rather than storing them directly, as it lacks the dedicated security features like hardware-backed protection, granular secret-specific access policies, and comprehensive audit trails for secret access.

Use a managed identity assigned to the container group to authenticate to the storage account.

Why it fails: While managed identities are a robust and secure way for Azure resources to authenticate to services that support Microsoft Entra ID authentication, they are not directly supported for mounting Azure Files shares within an Azure Container Instance. Mounting an Azure Files share typically relies on SMB/NFS protocols, which require a storage account key for authentication, not an Microsoft Entra ID token. Managed identities are primarily used for programmatic access to storage data (e.g., Blob storage via SDK) where Microsoft Entra ID authentication is integrated.

Use a shared access signature (SAS) token to mount the file share.

Why it fails: Shared Access Signatures (SAS) tokens provide granular, time-bound access to specific Azure Storage resources, such as blobs, queues, tables, or individual files. However, the underlying SMB/NFS protocols used by Azure Files for mounting a file share do not natively support authentication via SAS tokens. Mounting an Azure Files share requires the full storage account key or Active Directory Domain Services (AD DS) authentication, not a temporary SAS credential.

Enable the storage account's firewall to allow access from the container group's public IP.

Why it fails: While technically possible to configure a storage account firewall to allow access from a specific public IP address, this approach is generally less secure for Azure Container Instances. ACI container groups often have dynamic public IP addresses, making firewall configuration difficult to maintain, or they might not have a static public IP. More importantly, exposing the storage account to the public internet, even with IP restrictions, increases the attack surface compared to leveraging private networking solutions like virtual networks and service endpoints, which keep traffic within the Azure backbone.

Shared access signature (SAS) token

Why it fails: Shared Access Signatures (SAS) tokens provide delegated access to Azure Storage resources with granular control over permissions and validity. However, SAS tokens are fundamentally derived from either storage account access keys or user delegation keys, which are themselves shared secrets. Since the question specifically asks for authentication methods that do not use shared keys, SAS tokens are not a suitable answer because their security model is inherently tied to these underlying shared secrets.

Storage account access keys

Why it fails: Storage account access keys are highly privileged shared secrets that grant full administrative access to an entire Azure Storage account. These keys are symmetric cryptographic keys, meaning the same key is used for both signing and verifying requests. Since the question specifically seeks authentication methods that do not use shared keys, relying on storage account access keys directly contradicts this requirement, making them an incorrect choice.

Client certificate-based authentication

Why it fails: Client certificate-based authentication is a method where a client presents a digital certificate to prove its identity. However, Azure Blob Storage does not natively support direct client certificate-based authentication for authorizing requests to storage resources. While certificates can be used in conjunction with other services like Azure Key Vault or for authenticating service principals to Microsoft Entra ID, it is not a standalone, supported authentication method for direct access to Blob Storage itself.

Place all resources behind a firewall

Why it fails: Placing all resources solely behind a firewall is a perimeter-centric security approach, which contradicts the core principles of Zero Trust. A firewall primarily protects the network edge, implicitly trusting everything within its boundary. Zero Trust, conversely, assumes no implicit trust based on network location and mandates explicit verification for every access request, regardless of whether it originates inside or outside the traditional network perimeter.

Use a VPN to connect to the corporate network

Why it fails: Using a traditional VPN to connect to the corporate network is generally not aligned with a Zero Trust model. A VPN typically grants broad network-level access once a connection is established, often implicitly trusting the connecting device and user after initial authentication. Zero Trust requires continuous, explicit verification of identity, device health, and context for every access request to every specific resource, rather than providing blanket network access.

Use the Consumption tier for production APIs with custom domains.

Why it fails: The Azure API Management Consumption tier is designed for serverless workloads and offers a pay-per-action billing model, making it cost-effective for intermittent or low-volume usage. However, a key limitation for production APIs requiring a professional presence is its lack of support for custom domains. Production environments typically demand custom domain names for branding and trust, which necessitates using higher tiers like Developer, Standard, or Premium.

Expose the backend service URLs directly to clients.

Why it fails: Directly exposing backend service URLs to clients completely circumvents the purpose of Azure API Management. This practice bypasses all the critical security, transformation, caching, and monitoring capabilities that API Management provides, such as authentication, authorization, rate limiting, request/response transformation, and analytics. It exposes the internal architecture, potentially leading to security vulnerabilities, uncontrolled access, and a lack of centralized management.

Enable duplicate detection for all queues

Why it fails: Enabling duplicate detection for all queues is not a best practice because it introduces significant processing overhead and latency. This feature requires Service Bus to maintain a message ID history, consuming additional resources and potentially impacting throughput. While crucial for idempotent message processing in specific scenarios where "at-least-once" delivery might lead to application-level side effects, it should only be enabled selectively for queues where strict "exactly-once" processing semantics are absolutely required, not as a default.

Use sessions to guarantee ordering

Why it fails: Using sessions solely to guarantee ordering for all messages is not a best practice due to the inherent serialization it imposes. When messages are part of a session, they must be processed sequentially by a single receiver, which significantly reduces the potential for parallel processing and thus limits overall throughput. While sessions are essential for scenarios requiring ordered processing of related messages (e.g., stateful message sequences), their use should be carefully considered and restricted to specific business flows where message order within a logical group is paramount, rather than a general approach for all messages.

Send messages larger than 256 KB to reduce the number of messages

Why it fails: Sending messages larger than 256 KB is generally not a best practice, even if it appears to reduce the *number* of messages. Large messages consume more network bandwidth, increase serialization/deserialization times, and require more memory on both the sender and receiver, leading to higher latency and reduced overall system throughput. Furthermore, Service Bus has a maximum message size limit (typically 256 KB for Standard tier, 1 MB for Premium), and exceeding this requires using claims-based routing or external storage, adding complexity and cost.

Create a service principal and assign it to the function app.

Why it fails: A service principal is an identity used by applications, services, or automation tools to access Azure resources, but it requires manual management of its credentials, such as client secrets or certificates. While it can be assigned permissions to resources, it does not provide the automatic credential management and lifecycle handled by Azure that defines a managed identity. Therefore, directly creating and using a service principal does not leverage the benefits of a managed identity.

Use the function app's default connection string with a username and password.

Why it fails: Using a function app's default connection string with a username and password represents a traditional method of authentication that relies on static credentials. This approach necessitates storing and managing sensitive information, which contradicts the primary purpose of Azure Managed Identities. Managed identities are designed to eliminate the need for developers to handle such credentials, providing an automatically managed identity within Microsoft Entra ID for secure access to other services.

Upload a client certificate to the function app and use it to authenticate.

Why it fails: Uploading a client certificate to a function app and using it for authentication, while a valid security mechanism in certain scenarios, does not constitute using a managed identity. Certificate-based authentication still requires developers or administrators to manage the certificate's lifecycle, including its secure storage, renewal, and rotation. Managed identities abstract away all forms of credential management, including certificates, by leveraging Microsoft Entra ID directly to issue tokens on behalf of the application.

It can be defined at the container level.

Why it fails: Azure Blob Storage lifecycle management policies are configured at the storage account level, not granularly per container. This design ensures consistent application of rules across all blobs within the account, simplifying administration for large-scale data management. While rules can specify blob prefixes to target specific subsets of data, the policy itself is a storage account resource and applies its rules across the entire account's blob containers.

It can change the replication type of the storage account.

Why it fails: Azure Blob Storage lifecycle management policies are focused on managing the lifecycle of blob data itself, including tiering, archiving, and deletion. However, they do not possess the functionality to alter fundamental storage account properties such as the replication type (e.g., LRS, GRS, RA-GRS). Changing the replication strategy is a separate, account-level operation that impacts data durability and availability, distinct from data lifecycle management.

A public IP address on the app

Why it fails: A public IP address provides external network accessibility to an application, allowing it to be reached from the internet. While some applications might require a public IP for client access, it is entirely unrelated to Azure Monitor's internal telemetry collection and alerting mechanisms, which operate within the Azure platform regardless of the application's network exposure.

A manually exported CSV report

Why it fails: A manually exported CSV report represents a static snapshot of data at a specific point in time, requiring human intervention to generate and review. This method is inherently reactive and cannot provide the immediate, automated notifications or actions necessary for proactive alerting on high telemetry, which demands continuous monitoring and automatic triggers.

Azure Notification Hubs

Why it fails: Notification Hubs pushes mobile notifications to tagged device registrations; it has no topic subscriptions for decoupled application components. It is tempting because its tag-based broadcast resembles publish/subscribe, and it would be correct when the subscribers are mobile apps receiving platform push notifications.

Azure Queue Storage

Why it fails: Queue Storage is point-to-point: each message is consumed by one receiver and deleted, so every subscriber cannot get a copy. It is tempting because it decouples producers from consumers, and it would be correct for load-levelling work distribution among competing worker roles.

Integrate with Azure Virtual Network by default.

Why it fails: Azure Container Instances (ACI) provides basic public IP connectivity by default, allowing containers to be directly accessible from the internet. While ACI does support integration with an Azure Virtual Network (VNet), this is an optional and advanced networking configuration that must be explicitly enabled during container group creation. It is not the default behavior, as default deployments typically run on a public IP address without VNet isolation.

Run containers as nested containers (Docker-in-Docker).

Why it fails: Azure Container Instances runs containers in a secure, hypervisor-isolated environment, which means the underlying host operating system is not exposed to the container. Consequently, ACI does not support privileged operations like running Docker-in-Docker (DinD) or other forms of nested containerization. This architectural design prioritizes security and rapid startup times over complex virtualization scenarios within the container itself.

Use Microsoft Entra ID v1.0 endpoints.

Why it fails: Using Microsoft Entra ID v1.0 endpoints is an outdated practice for new application development. The Microsoft identity platform v2.0 endpoints offer enhanced capabilities, including support for personal Microsoft accounts, incremental consent, and adherence to modern OpenID Connect and OAuth 2.0 standards. Relying on v1.0 endpoints would lead to a less flexible and potentially less secure authentication implementation, as v1.0 is considered deprecated and lacks the full feature set of the current platform.

Configure authentication via the 'Authentication' blade in the portal.

Why it fails: Configuring authentication via the 'Authentication' blade in the Azure portal primarily enables Azure App Service's built-in authentication/authorization (EasyAuth) for the function app itself. While EasyAuth can integrate with Microsoft Entra ID, this step focuses on securing access *to* the function app's endpoint for users or applications. It does not directly involve defining custom OAuth 2.0 scopes or app roles that *other client applications* would use to call *your API* with specific permissions, which is central to a custom OAuth configuration for an API.

Enable Azure App Service built-in authentication (EasyAuth).

Why it fails: Enabling Azure App Service built-in authentication, also known as EasyAuth, provides a convenient, low-code solution for securing web apps and APIs by offloading authentication to the platform. However, while useful for securing the function app's access, it's not the primary mechanism for *defining* and *exposing* custom OAuth 2.0 permissions (scopes and app roles) that external client applications would use to call the API. EasyAuth primarily *consumes* identity, rather than *defining* the API's specific authorization contract for external consumers.

Azure Queue Storage trigger

Why it fails: An Azure Queue Storage trigger is designed to activate an Azure Function when a new message is added to a specified Azure Storage Queue. This trigger is specifically for processing discrete messages placed into a queue for asynchronous processing, not for monitoring or reacting to events occurring within Azure Blob Storage containers. It operates on the principle of message consumption, not external resource change detection.

Azure Cosmos DB trigger

Why it fails: An Azure Cosmos DB trigger specifically responds to changes occurring within an Azure Cosmos DB container, leveraging the service's change feed functionality. This trigger is designed for scenarios where a function needs to process new inserts, updates, or deletes of documents in a NoSQL database. It has no direct mechanism to monitor or react to events originating from Azure Blob Storage.

HTTP trigger

Why it fails: An HTTP trigger provides a function with a callable HTTP endpoint, allowing it to be invoked by an explicit HTTP request from any client or service. This trigger operates on a request-response model, requiring an external entity to actively send a web request to the function's URL. It does not automatically react to passive events like a blob being created in storage; it waits for an inbound network call.