Select Two (Multi-Select) Questions

SFTP support

Why wrong: 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 wrong: 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 Azure AD (Microsoft Entra ID) tenant for employee identities

Why wrong: An Azure AD (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 Azure AD 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 Azure AD tenant.

An Azure subscription

Why wrong: 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.

Set the 'MaxBatchSize' property to 1 to ensure even distribution.

Why wrong: Batch size does not affect partition distribution.

Select the Premium App Service plan for the function app.

Why wrong: Premium plan is not required for partition distribution.

Use the EventHubs trigger with the 'PartitionKey' parameter set to the partition ID.

Why wrong: Incorrect. The 'PartitionKey' parameter is used when sending events to specify a partition, not in the trigger binding. The Event Hubs trigger automatically distributes partitions among function instances; you do not set the partition key in the trigger.

The restart policy for containers

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Increase the 'BatchSize' to reduce the frequency of trigger evaluations.

Why wrong: Increasing BatchSize only affects how many blobs are fetched at once from the queue, but does not help with detecting partial writes. The trigger can still fire on a blob that is being written. Therefore, A is incorrect.

Use the 'BlobTrigger' with the 'LeaseBlob' property set to 'True'.

Why wrong: 'LeaseBlob' is not a valid property of the Azure Functions Blob trigger binding. While acquiring a lease is a recommended approach, it must be done manually in the function code, not as a trigger binding property. Therefore, D is incorrect.

Set the 'ScanBlob' property to 'True' in the trigger binding.

Why wrong: 'ScanBlob' is not a valid property of the Azure Functions Blob trigger binding. There is no built-in trigger property to scan for completeness. Therefore, E is incorrect.

Use a client certificate.

Why wrong: Client certificates are not a supported authentication method for Azure Blob Storage. They can be used for device authentication or to authenticate to Azure AD as a service principal, but not directly for Blob Storage access.

Azure Batch

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: While managed identities are a robust and secure way for Azure resources to authenticate to services that support Azure AD 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 Azure AD token. Managed identities are primarily used for programmatic access to storage data (e.g., Blob storage via SDK) where Azure AD authentication is integrated.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 Azure Active Directory for secure access to other services.

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

Why wrong: 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 Azure Active Directory directly to issue tokens on behalf of the application.

A public IP address on the app

Why wrong: 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 wrong: 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 wrong: Notification Hubs is for push notifications to mobile devices.

Azure Queue Storage

Why wrong: Queue Storage is a point-to-point messaging service.

Transactional

Why wrong: Transactional is not a standard Azure Blob Storage access tier and is not optimized for infrequently accessed data with a 30-day minimum.

Archive

Why wrong: Archive is optimized for rarely accessed data but has a minimum storage duration of 180 days, not 30 days, so it is incorrect.

Premium

Why wrong: Premium is optimized for high-performance, low-latency scenarios and is not intended for infrequently accessed data with a minimum duration.

Hot

Why wrong: Hot is optimized for frequently accessed data and has no minimum storage duration, so it does not apply.