Scenario practice questions

Fixed-rate sampling with a 1% rate

Why it fails: Fixed-rate sampling applies a constant sampling percentage, such as 1%, to all telemetry items, regardless of the current traffic volume. While it offers predictable data volume under stable load, it fails to adapt to the fluctuating high volume characteristic of an e-commerce application. During traffic spikes, a fixed 1% rate could still lead to excessive data ingestion and costs, or conversely, during lulls, it might collect too little data for meaningful analysis, making it inefficient for dynamic workloads.

Ingestion sampling

Why it fails: "Ingestion sampling" is not a recognized or configurable sampling method within Azure Application Insights. Application Insights primarily offers SDK-based sampling (fixed-rate and adaptive) and a form of "daily cap" which limits total ingestion but isn't a proactive sampling strategy. While data might be dropped if a daily cap is exceeded, this isn't a configurable, intelligent sampling mechanism like adaptive sampling, making it an incorrect choice for managing high-volume telemetry.

Head-based sampling

Why it fails: Head-based sampling, often used in distributed tracing systems, makes sampling decisions at the very beginning of a request's lifecycle, typically based on a trace ID. This ensures that all telemetry items related to a single request are either fully sampled or fully dropped, preserving the complete context of a transaction. However, Azure Application Insights does not natively implement head-based sampling as a configurable option, instead relying on adaptive or fixed-rate sampling for its telemetry collection.

TrackEvent

Why it fails: TrackEvent is designed for discrete occurrences, like user clicks or specific actions, where each instance is unique and valuable for individual analysis. However, for high-volume, repetitive metrics (e.g., page views per second), sending each as a separate TrackEvent creates excessive telemetry, leading to prohibitive ingestion costs and potential data sampling or throttling by Application Insights, making it unsuitable for aggregated metric tracking.

TrackMetric

Why it fails: TrackMetric allows sending a single metric value at a specific point in time, optionally with a count, sum, and standard deviation. While it supports basic metric reporting, it lacks native support for multiple custom dimensions, which are crucial for segmenting and analyzing metrics by attributes like browser type, region, or user ID. Furthermore, it doesn't perform client-side pre-aggregation, sending each data point individually, which can be inefficient for high-frequency metrics.

TrackDependency

Why it fails: TrackDependency is specifically designed to monitor calls to external components, such as databases, HTTP services, or message queues, capturing their duration, success/failure, and target. Its purpose is to provide insights into the performance and availability of application dependencies. It is entirely inappropriate for emitting general custom metrics like page views or business-specific counters, as it would misrepresent the data's nature and pollute dependency monitoring telemetry.

Microsoft Sentinel Data Connectors

Why it fails: Microsoft Sentinel Data Connectors are fundamental components responsible solely for ingesting security logs and events from various sources into the Sentinel workspace. While crucial for populating the underlying data store, they do not inherently perform threat detection or automated response actions. Their function is limited to data collection, making them a prerequisite for, but not the mechanism of, active threat identification or mitigation. Therefore, relying solely on data connectors would not achieve the goal of detecting and responding to threats.

Microsoft Defender for Identity

Why it fails: Microsoft Defender for Identity is a specialized cloud-based security solution primarily focused on protecting on-premises Active Directory environments from advanced threats and compromised identities. While it provides robust identity-based threat detection, it operates as a distinct product from Microsoft Sentinel, with its own sensors and detection logic. It is not the native mechanism within Sentinel itself for defining custom detection logic or orchestrating automated responses across a broader range of data sources ingested into Sentinel. Therefore, it's not the correct tool for implementing a Sentinel-based detection and response strategy.

Microsoft Sentinel playbooks

Why it fails: Microsoft Sentinel playbooks, built on Azure Logic Apps, are powerful tools for orchestrating automated responses to security incidents or alerts. However, playbooks are reactive by nature; they require a trigger to initiate their execution. They do not perform the initial threat detection themselves, nor do they define the conditions under which a threat is identified. An analytics rule or a manual action is necessary to trigger a playbook, meaning playbooks alone cannot fulfill both the detection and response requirements.

Azure Table Storage

Why it fails: Azure Table Storage is a NoSQL key-value store optimized for structured, non-relational data with schema-less entities. While it can store data, its performance characteristics and indexing are not ideal for the high-frequency, low-latency read/write operations typical of session state. It lacks built-in features like automatic expiry and atomic operations crucial for efficient session management in a web application, making it an unsuitable choice.

Azure Blob Storage

Why it fails: Azure Blob Storage is designed for storing large amounts of unstructured object data, such as images, videos, or documents. It is optimized for high throughput and cost-effective storage of immutable objects, not for the frequent, small, and mutable read/write operations required for session state. Using it for session state would incur significant latency and cost due to its object-based nature and lack of direct support for in-memory caching patterns.

Azure SQL Database

Why it fails: Azure SQL Database is a relational database service optimized for transactional data and complex queries, ensuring data integrity and consistency. While it can technically store session data, its disk-based nature and the overhead of relational operations introduce higher latency compared to in-memory caches. It is not designed for the extremely high-speed, volatile, and non-relational key-value access patterns characteristic of efficient session state management, leading to performance bottlenecks.

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.

In the frontend app registration, enable the implicit grant flow for access tokens. The frontend gets a token for the backend directly from the authorization endpoint.

Why it fails: Enabling the implicit grant flow for access tokens is not recommended for modern web applications due to inherent security risks, such as token leakage via browser history or referrer headers, and the lack of refresh tokens. While it allows the frontend to directly obtain a token, it bypasses the secure exchange of an authorization code for a token, making it less secure than the Authorization Code Flow with PKCE, which is the current best practice for single-page applications.

In the frontend app registration, set the redirect URI to the backend URL. The frontend uses the authorization code flow to get a token for the backend directly.

Why it fails: Setting the redirect URI to the backend URL is incorrect because the redirect URI must point back to the *client application* (the frontend) that initiated the authentication request. The authorization code flow is designed for the client to obtain an authorization code, which it then exchanges for an access token and refresh token. This token is for the *client itself* to access resources, not directly for a *different* backend API without further token exchange mechanisms like the On-Behalf-Of flow.

In the frontend app registration, grant API permissions for the backend using the 'Application permissions' type. In the backend app registration, expose an API scope. The frontend uses the client credentials flow to get a token for the backend.

Why it fails: Granting 'Application permissions' and using the client credentials flow is unsuitable for a frontend application calling a backend API on behalf of a user. The client credentials flow is designed for daemon or service-to-service communication where no user context is involved; it authenticates the application itself, not a user. Using this flow would mean the backend API would receive a token representing the frontend application's identity, completely losing the original user's identity and context.

The role definition ID is incorrect.

Why it fails: The GUID 'ba92f5b4-2d11-453d-a403-e96b0029c9fe' is the correct and well-known identifier for the built-in 'Storage Blob Data Contributor' role definition in Azure. Since this specific GUID accurately references a valid role that grants necessary permissions for data operations on storage blobs, the problem does not stem from an incorrect role definition ID. The ARM template correctly specifies which role to assign.

The storage account name 'mystorageacct' does not exist.

Why it fails: If the storage account 'mystorageacct' did not exist, the ARM deployment would typically fail with a 'ResourceNotFound' error during the validation or deployment phase when attempting to resolve the scope for the role assignment. This error would indicate an inability to locate the target resource for the role assignment, which is distinct from an issue related to the principal's identity. The problem is not with the existence of the storage account itself.

The role assignment name is not unique.

Why it fails: The `guid()` function in an ARM template is specifically designed to generate a globally unique identifier each time it is invoked. Using this function for the role assignment name ensures that the name is unique within its scope, preventing naming conflicts that would otherwise cause the deployment to fail. Therefore, the role assignment name being non-unique is not the cause of the deployment issue.

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.

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.

Implement Redis cache-aside pattern and ensure that all database queries check the cache first.

Why it fails: While implementing the Redis cache-aside pattern is a valid optimization technique, applying it indiscriminately to all database queries without first identifying the specific performance bottlenecks is inefficient. This approach could lead to caching infrequently accessed data, increasing cache management overhead, and failing to address the root cause of the performance issues by not targeting the most resource-intensive operations. The problem requires identifying the problematic queries first.

Configure Azure SQL Database Intelligent Insights to automatically tune database queries.

Why it fails: Azure SQL Database Intelligent Insights provides AI-driven performance monitoring and proactive recommendations, including automatic tuning for potential issues. However, its primary function is to identify deviations from normal behavior and suggest or apply tuning actions, rather than explicitly listing the 'most costly queries' in a ranked fashion for manual analysis. It provides recommendations after the fact, not a direct diagnostic tool for initial bottleneck identification.

Use Application Insights Profiler to capture and analyze database query performance.

Why it fails: Application Insights Profiler is an excellent tool for deep-diving into the execution path of application code, including tracing calls to external dependencies like databases within a specific request. It can show the duration of individual database calls as part of an end-to-end transaction. However, Profiler's strength lies in understanding the performance of single request flows and method timings, not in providing an aggregated, ranked list of the most costly queries across the entire database workload, which is what Query Performance Insight offers for systemic database inefficiencies.

emptyDir

Why it fails: An emptyDir volume is created when a pod is scheduled on a node and exists only as long as that pod is running. It provides a temporary, empty directory for containers within the pod to share, useful for scratch space, caching, or temporary file storage. However, all data stored in an emptyDir is deleted permanently when the pod terminates, making it fundamentally unsuitable for stateful applications requiring data persistence beyond the pod's lifecycle.

Host path

Why it fails: Host path volumes directly mount a file or directory from the underlying node's filesystem into a container. While this provides persistence, it tightly couples the container to a specific host node, making the application non-portable and difficult to scale or reschedule across different nodes. This dependency on a single node makes host path volumes unsuitable for stateful applications in a distributed container environment where high availability and flexibility are crucial.

Secret volume

Why it fails: Secret volumes are designed to securely inject sensitive data, such as API keys, passwords, or certificates, into containers as files or environment variables. They are typically mounted as read-only, in-memory (tmpfs) filesystems, meaning any data written to them by the application is not durable and will be lost upon container or pod termination. Therefore, they are entirely unsuitable for persisting application state or general-purpose data that needs to survive restarts.

Block blobs

Why it fails: Block blobs are designed for storing large, discrete objects and are optimized for high-throughput reads and writes of entire blocks, or for replacing specific blocks within a blob. While they can technically be used for appending by downloading, modifying, and re-uploading, or by managing block lists, this process is highly inefficient and expensive for frequent, small log entries. Each append would incur significant transaction overhead and latency, making them unsuitable for continuous, high-volume logging scenarios.

Page blobs

Why it fails: Page blobs are optimized for random read/write operations of fixed-size 512-byte pages, primarily used for Azure Virtual Machine disks. Their architecture is designed to support frequent, small, random I/O operations, not sequential appends of variable-sized log entries. Using page blobs for logging would be highly inefficient due to the overhead of managing page boundaries for each entry and their cost model, which is optimized for disk operations rather than high-volume sequential writes.

Azure Files shares

Why it fails: Azure Files shares use the SMB protocol and are designed for shared file access across virtual machines, not for high-throughput sequential blob writes. The per-file overhead and protocol latency would severely degrade write throughput for millions of small 500-byte entries, and the cost model (based on provisioned capacity or transaction tiers) is far higher than block blob storage for this volume. This option is tempting because Azure Files provides a familiar network drive interface, making it a natural choice for applications that need to mount a file system and append logs as files, which would be correct for scenarios requiring concurrent file sharing or legacy application compatibility.

Azure Blob Storage with JSON logs

Why it fails: Azure Blob Storage is designed for storing massive amounts of unstructured data, such as images, videos, or large log files. While it can store JSON documents, querying individual sensor readings within these blobs would necessitate downloading and parsing entire files, which is highly inefficient and costly for billions of small, frequently queried IoT messages. It lacks the native indexing and query capabilities required for granular, per-record access patterns typical of IoT telemetry.

Azure Queue Storage

Why it fails: Azure Queue Storage is a messaging service primarily used for transient, asynchronous message passing between application components, enabling decoupled processing. It is not designed for long-term data retention or complex querying of historical data. Messages have a configurable time-to-live (TTL) and are typically deleted after consumption, making it unsuitable for persistent storage and analytical queries on billions of sensor readings.

Azure File Storage

Why it fails: Azure File Storage provides fully managed file shares in the cloud, accessible via industry-standard Server Message Block (SMB) or Network File System (NFS) protocols. It is designed for traditional file system scenarios, such as lift-and-shift applications or shared configuration files. This service is not engineered for high-volume ingestion of small, structured data records or for programmatic querying of individual entities, lacking the necessary APIs and performance characteristics for IoT telemetry.

Use the HTTP action with Managed Identity authentication.

Why it fails: Managed Identities provide an identity for Azure resources to authenticate to services that support Microsoft Entra authentication within the same tenant where the identity is registered. Since the external API resides in a different Microsoft Entra ID tenant, the Logic App's Managed Identity would not be recognized or authorized by that external tenant's application registration, rendering it ineffective for cross-tenant API calls.

Use the HTTP + Swagger connector to import the API definition.

Why it fails: The HTTP + Swagger connector primarily serves to parse an OpenAPI (Swagger) definition, providing design-time schema validation and a more structured interface for the HTTP action within the Logic App. While it enhances the developer experience by defining API structure, it does not inherently handle the runtime acquisition or management of OAuth tokens, especially for complex cross-tenant authentication scenarios.

Use the Azure Key Vault - Get secret action to retrieve a token.

Why it fails: Azure Key Vault is a secure service for storing and managing secrets, keys, and certificates, such as API keys or client secrets. However, it is not designed to generate or store dynamic OAuth access tokens, which are short-lived credentials obtained from an identity provider after a successful authentication flow. The Logic App would still need to use stored client credentials to programmatically request a token from the external API's identity provider, not retrieve a pre-existing token from Key Vault.

Create a metric alert on the 'failed requests' metric with a static threshold.

Why it fails: A static threshold alert on the 'failed requests' metric is insufficient for robust anomaly detection because it requires a predefined, fixed value. This approach struggles to adapt to normal fluctuations in application load or expected error rates, leading to either excessive false positives during peak times or or missed critical issues during low traffic. It lacks the intelligence to dynamically learn the application's baseline behavior, making it less effective for identifying true anomalies.

Use Log Analytics to run a query every 5 minutes and trigger an action.

Why it fails: While Log Analytics can be used to create log alerts, this method necessitates writing specific Kusto Query Language (KQL) queries and manually defining static thresholds to detect anomalies. This approach demands continuous tuning and maintenance as application behavior evolves, making it less efficient for dynamic anomaly detection compared to automated solutions. It shifts the burden of defining 'anomalous' behavior to the operator rather than leveraging AI-driven insights.

Create an availability test that periodically pings the application.

Why it fails: Creating an availability test primarily focuses on monitoring the external reachability, uptime, and basic response time of a web application's endpoint from various geographic locations. These tests simulate user traffic but do not analyze the internal telemetry, such as detailed failed request patterns or exceptions, generated by real user interactions within the application itself. Therefore, an availability test would not effectively detect subtle or sudden anomalies in the application's internal failure rates.

Block blob

Why it fails: Block blobs are optimized for storing large, discrete objects like documents, images, and videos, where the entire object is typically uploaded or downloaded. While they can handle files up to 4.75 TB, frequent append operations are highly inefficient. Each append would require listing existing blocks, uploading new blocks, and then committing the entire block list again, or even re-uploading modified blocks, which is not designed for high-throughput sequential writes.

Page blob

Why it fails: Page blobs are optimized for random read/write operations on fixed-size 512-byte pages, making them the underlying storage for Azure Virtual Machine disks. They are designed for scenarios where specific byte ranges within a file are frequently updated, not for sequential appends where data is continuously added to the end. Using page blobs for sequential appends would be inefficient and complex, requiring manual management of page boundaries and potentially overwriting data.

Archive blob

Why it fails: The Archive access tier is designed for storing rarely accessed, long-term data, offering the lowest storage costs but with the highest access latency and retrieval costs. It is explicitly not intended for frequent write or append operations. Data in the Archive tier must first be rehydrated to a hot or cool tier before it can be read or modified, making it entirely unsuitable for an application requiring frequent appends to media files.

Log alert based on a Kusto query that measures average response time in 5-minute windows

Why it fails: A log alert based on a Kusto query is incorrect for this scenario because average server response time is a standard metric natively collected by Application Insights. Metric alerts are specifically designed to efficiently monitor such pre-aggregated metrics over rolling time windows, which precisely matches the requirement. This option is tempting due to Kusto's powerful analytical capabilities, making it the correct choice when the alert condition requires analysing custom log properties, correlating data across multiple log types, or performing complex calculations not available as standard metrics.

Smart Detection alert on response time degradation

Why it fails: Smart Detection is an AI-driven feature designed to identify unusual patterns and sudden degradations in application performance by establishing a dynamic baseline of normal behavior. It alerts on anomalies and deviations from this learned baseline, rather than monitoring against a fixed, static threshold. Therefore, it would not reliably trigger an alert for a consistent response time exceeding a specific 2-second limit if that value falls within its learned 'normal' operating range or if the degradation is gradual and not considered anomalous.

Availability test alert for HTTP response time

Why it fails: Availability tests, also known as web tests, are synthetic monitoring tools that simulate user traffic from various global locations to check the uptime and performance of a web application's external endpoints. While they measure response time, this measurement reflects the performance of a synthetic transaction from a specific test location, not the actual server response time experienced by real users interacting with the application. The question specifically asks to monitor the web application's server response time, implying real user traffic, which is captured by the Application Insights SDK.

Azure Blob Storage with Block blobs

Why it fails: Azure Blob Storage with Block blobs is generally optimized for storing large, unstructured binary data objects, typically greater than 1 MB, or for streaming data. Storing millions of small 1KB JSON documents as individual block blobs would incur significant transaction costs and overhead per object, leading to inefficient storage and retrieval due to the per-blob metadata and management. This approach is not cost-effective or performant for high-volume, small-entity storage scenarios requiring frequent access.

Azure Files with SMB protocol

Why it fails: Azure Files with SMB protocol provides fully managed file shares in the cloud, primarily intended for lift-and-shift applications that require a file system interface or for sharing files across multiple virtual machines. It is not designed as a NoSQL document store and lacks the indexing and query capabilities necessary for efficient management of millions of individual 1KB JSON documents. Using it for this purpose would result in high latency, increased costs, and poor performance compared to a purpose-built NoSQL database.

Azure Cosmos DB for NoSQL

Why it fails: Azure Cosmos DB for NoSQL offers a globally distributed, multi-model database service with guaranteed low latency and high availability, making it suitable for mission-critical applications. However, for a scenario focused solely on cost-effectively storing millions of small 1KB JSON documents without requiring its advanced features like global distribution, multi-master writes, or specific API compatibility, Cosmos DB is significantly more expensive than Azure Table Storage. Its provisioned throughput model (RUs) would incur higher costs for simple storage and retrieval compared to Table Storage's optimized pricing for massive scale.

Event Hubs metrics.

Why it fails: Event Hubs metrics provide operational insights into the Event Hub service itself, such as message throughput, active connections, and throttled requests. While essential for monitoring the health and performance of the Event Hub, these metrics do not extend to the processing status within the consuming Azure Function. They cannot indicate whether an event was successfully consumed, processed, or failed after leaving the Event Hub, making them unsuitable for monitoring the function's internal event handling.

Stream Analytics job.

Why it fails: An Azure Stream Analytics job is designed for real-time data processing and complex event pattern matching on streaming data. While it could theoretically process events from Event Hubs, introducing a Stream Analytics job solely for monitoring an Azure Function's event processing status is an unnecessary architectural overhead. The function's internal processing metrics can be captured more directly and efficiently using native Application Insights instrumentation without adding another costly and complex service to the data pipeline.

Log Analytics query on function logs.

Why it fails: Log Analytics queries on function logs are unsuitable for directly monitoring *event counts* because they primarily analyse textual log data, not structured metrics. While you can count log entries, this approach lacks the native metric capabilities required for aggregate event processing statistics. It is tempting because Azure Functions integrate with Log Analytics for comprehensive logging. Log Analytics is ideal for detailed troubleshooting, investigating specific errors, and ad-hoc analysis of log patterns, providing granular insights into *why* events failed, rather than just their numerical totals.