Hard Difficulty Questions

Azure Event Hubs for triggering real-time serverless webhooks upon user profile updates.

Why it fails: Event Hubs ingests high-volume telemetry streams for processing, not discrete user-profile change notifications. Profile updates are lightweight discrete events, which Event Grid routes to webhooks via subscriptions. Event Hubs would be correct for continuous telemetry or log ingestion at scale, where throughput and partitioning matter.

Azure Event Grid for streaming continuous IoT sensor telemetry into Azure Databricks.

Why it fails: Event Grid delivers discrete, low-latency notifications to handlers such as Azure Functions; it does not provide the partitioned, high-throughput retention needed for continuous IoT telemetry. Event Hubs is the ingestion service for streaming sensor data into analytics platforms like Databricks, so the pairing reverses the two services' roles.

Setting the Event Grid webhook handshake timeout to 120 seconds.

Why it fails: Event Grid webhook handshake timeouts govern event delivery subscriptions, not the Event Hubs Kafka/AMQP consumer path, so they cannot influence partition reads or checkpointing. It is tempting because Event Grid does integrate with Event Hubs for reactive triggers, and would be correct when configuring push notifications rather than Spark's pull-based consumer offsets.

Enabling AMQP 1.0 web socket transport mode across all Spark worker nodes.

Why it fails: Web socket transport only changes how AMQP frames traverse proxies; it does not assign partitions to Spark executors or manage offsets, so duplicate bottlenecks persist. It is tempting because web sockets help in restricted networks, and would be correct where firewalls block outbound AMQP ports 5671/5672 on worker nodes.

The Service Bus shared access policy connection string with Manage rights.

Why it fails: A Manage-rights connection string grants send and management permissions, not the Listen permission the Spark connector needs to consume events. Manage rights suit producers or administrative tooling; consumers require a policy carrying Listen claims for the specified consumer group.

It increases vector dimensions from 1536 to 3072 to improve accuracy

Why it fails: Scalar quantization compresses each float32 component into a narrower integer type, cutting memory roughly fourfold; it never changes dimensionality. Increasing dimensions to 3072 describes a different technique entirely — using a higher-dimension embedding model, such as text-embedding-3-large — which improves recall at the cost of greater storage, the opposite of this scenario's goal.

It eliminates the need for an HNSW graph structure

Why it fails: Scalar quantization compresses each float32 dimension to a narrower integer type, shrinking memory while retaining the HNSW graph. It does not remove that graph; HNSW remains the approximate-nearest-neighbour index structure. The option tempts because quantisation and graph indexing are separate concerns, and disabling HNSW would be a deliberate indexing choice, not a quantisation effect.

It converts vectors into plain text strings for keyword indexing

Why it fails: Scalar quantization maps each float32 component to a lower-precision integer, shrinking memory while preserving vector structure for similarity search. Converting vectors to text strings describes keyword indexing, which would discard the numeric embeddings needed for vector queries.

Convert all vector embeddings to base64 string format

Why it fails: Base64 encoding inflates vector size and forces decoding before distance computation, slowing queries. It suits binary payload transport, not vector search; Cosmos DB expects native float arrays so the indexing engine can compute distances directly.

Disable all non-vector indexing policies on the container

Why it fails: Disabling non-vector indexing policies removes the very composite and range indexes that filter predicates in vector queries rely on, so pre-filtering degrades into full scans. It is tempting because trimming unused indexes reduces write RU cost, which is the right move when a container is write-heavy and no filtered vector queries run.

Deploy an Azure Service Bus relay across all subscriptions.

Why it fails: Service Bus Relay exposes on-premises services through the cloud; it does not deliver published domain events to multiple subscriber microservices. Relay is tempting for hybrid connectivity, and would be correct when external clients must reach an internal service without a public endpoint, not for cross-subscription event distribution.

Create individual Event Hubs namespaces in every consumer subscription and peer them via ExpressRoute.

Why it fails: Event Hubs is a high-throughput streaming ingestion service, not an event routing fabric; separate namespaces cannot subscribe to a central Order Service's domain events. Event Hubs is tempting for telemetry pipelines, and would be correct for ingesting millions of streaming events for processing rather than event-driven subscription routing.

Use Azure Storage Queues shared via SAS URLs across subscriptions.

Why it fails: Storage Queues provide polling-based message storage, not publish-subscribe event routing to multiple subscribers across subscriptions; Event Grid domains or custom topics with subscriptions deliver that. Queues are tempting for decoupled messaging, and would be correct for point-to-point work distribution rather than fan-out domain events.

Native webhook push delivery for discrete serverless event triggers

Why it fails: Native webhook push delivery describes Event Grid subscriptions, which push discrete events to handlers; Event Hubs uses a pull-based AMQP or Kafka consumer model over partitioned streams. It is tempting because both are Azure event services, and Event Grid would be correct for reactive serverless triggers on discrete state-change events.

Automatic dead-lettering of messages exceeding a MaxDeliveryCount threshold

Why it fails: Dead-lettering on MaxDeliveryCount is an Azure Service Bus queue or subscription feature, not an Event Hubs capability; Event Hubs retains events in partitions for consumers to replay. It is tempting because both are messaging services, and Service Bus would be correct for ordered brokered messaging with per-message retry and dead-letter handling.

SecurityEvent | where TimeGenerated > ago(2h) | summarize count() by Account

Why it fails: Incorrect. SecurityEvent tracks Windows security log events, not container memory usage.

AzureActivity | where TimeGenerated > ago(2h) | summarize count() by OperationName

Why it fails: Incorrect. AzureActivity tracks control plane operations, not container memory metrics.

AppTraces | where TimeGenerated > ago(2h) | summarize count() by Message

Why it fails: Incorrect. AppTraces stores application trace statements, not system container metrics.

Vector properties cannot be updated after initial document creation

Why it fails: Vector properties are ordinary document fields and can be updated like any other, so this restriction does not exist. It is tempting because immutable embeddings are a common application-level design pattern, and would be correct if the question asked about a custom pipeline that deliberately freezes vectors after ingestion.

Writes are completely blocked until the vector index reaches 100% synchronization

Why it fails: Cosmos DB vector indexing is asynchronous; writes continue and the index catches up in the background, so writes are never blocked by synchronisation state. It is tempting because full synchronisation sounds like a prerequisite for query correctness, and would apply if the engine enforced synchronous index builds before acknowledging writes.

Writes require explicit distributed transactions across regions

Why it fails: Cosmos DB writes are single-partition or single-region operations by default; distributed transactions are not required for vector writes. It is tempting because multi-region replication sounds transactional, and would be correct if the scenario demanded atomic updates spanning several regions or partitions in one commit.

Log Analytics ingestion rate limiting always drops multi-threaded telemetry

Why it fails: Log Analytics does not categorically drop multi-threaded telemetry; throttling is volume-based and returns partial failures rather than silently discarding by thread. It tempts because ingestion limits genuinely cause missing records under heavy load, which would be the cause if the worker emitted at extreme volume.

Application Insights automatically blocks all telemetry generated outside of HTTP request threads

Why it fails: Application Insights has no rule excluding non-HTTP threads; the SDK's TelemetryClient must simply be flushed before a short-lived thread exits. It tempts because request-correlated telemetry dominates documentation, and auto-collection would indeed miss events if no client tracked them.

The instrumentation key was incorrectly formatted as a GUID

Why it fails: A malformed GUID would fail initialisation outright, so no telemetry of any kind would arrive, not just background-thread events. It tempts because connection-string errors are a common ingestion failure, and a wrongly formatted key would indeed be the cause if all telemetry were missing.

Azure Data Factory tumbling window triggers over Blob Storage

Why it fails: Tumbling window triggers schedule batch runs over Blob Storage files; they cannot read the source container's change feed, so migrated embeddings would lag behind live writes. Batch orchestration is tempting for periodic bulk copies, and would be correct where source data already lands in Blob Storage and offline windows are acceptable.

SQL Server Integration Services (SSIS) file import

Why it fails: SSIS imports files into relational targets such as SQL Server; it cannot stream writes into a live Cosmos DB for NoSQL container, so the application would face stale or duplicated embeddings. It is tempting because SSIS handles bulk data movement well, and would be correct for scheduled on-premises-to-SQL Server loads.

Taking a manual offline portal backup and restoring to a new account

Why it fails: A manual portal backup requires taking the account offline and restores into a new account, directly violating the no-downtime requirement and losing the original container identity. Offline backup and restore is tempting as a familiar disaster-recovery routine, and would be correct for planned maintenance windows where an outage is permitted.

Store all documents in a single partition without a partition key

Why it fails: A single logical partition caps throughput at one physical partition's limit and prevents horizontal scale-out, undermining availability and predictable performance. Choosing an appropriate partition key, such as tenant or document ID, distributes load; single-partition storage suits only tiny, low-throughput datasets.

Disable automatic indexing entirely across all properties

Why it fails: Disabling indexing removes the index that vector and filter queries rely on, forcing full scans that raise RU cost and latency. Selective indexing policies, excluding unused paths while retaining vector and filter properties, deliver predictable performance; blanket exclusion is the tempting but wrong simplification.

Storage Optimized (L1)

Why it fails: Storage Optimized tiers target large-scale, low-latency indexing with high storage-to-compute ratios, and semantic ranking is not offered on them. It is tempting because they are premium tiers, but semantic ranker availability follows Basic and above on standard tiers, not the Storage Optimized family.

Free

Why it fails: Semantic ranking is unavailable on the Free tier; it requires Basic or higher, with semantic ranker capacity billed separately. The tier is tempting because Free supports basic indexing and queries, but semantic reranking depends on infrastructure the Free tier does not provision, so enabling it there fails.

Basic

Why it fails: Semantic ranking is unavailable on the Basic tier; it requires Standard tier or higher, so Basic cannot satisfy this scenario. Basic is tempting because it supports full-text search and scoring profiles, making it the right choice for small workloads needing only lexical relevance without semantic re-ranking.

Azure Network Watcher.

Why it fails: Azure Network Watcher diagnoses network connectivity, latency and traffic flows between endpoints, not disk throughput. It is tempting because latency is the symptom, but confirming storage IOPS limits requires VM-level metrics such as Azure Monitor's disk performance counters for the virtual machine.

Azure Resource Graph Explorer.

Why it fails: Azure Resource Graph Explorer queries resource configuration and metadata across subscriptions, returning inventory-style results rather than live performance telemetry. It is tempting for auditing deployed resources, but storage IOPS metrics require Azure Monitor metrics or VM diagnostics, which record actual disk read/write operations per second.

Application Insights Dependency logs.

Why it fails: Application Insights Dependency logs record outbound calls made by instrumented application code, not hypervisor-level disk throughput, so they cannot expose the VM's storage IOPS ceiling. It is tempting because dependency telemetry does surface latency, but that reflects application-to-service calls; host storage metrics require Azure Monitor VM diagnostics or Metrics Explorer.

Mount the /proc filesystem as read-write.

Why it fails: Mounting /proc read-write exposes kernel parameters but cannot install a driver; kernel modules must be loaded on the host node itself. It is tempting because /proc/sys tuning adjusts runtime kernel behaviour, which would suffice if the driver already existed and only a parameter needed changing.

Run the application as root.

Why it fails: Running as root grants privileges inside the container but cannot install or load a kernel driver on the host node; kernel modules require node-level access. Root execution suits applications needing privileged in-container operations. Driver installation demands a DaemonSet or custom node image.

Rebuild the AKS cluster.

Why it fails: Rebuilding the cluster does not install the missing driver unless the node image or a DaemonSet is changed; the same default node configuration returns. It is tempting because node image upgrades can ship newer drivers, which would be correct if the required version were bundled in a supported AKS node image.

Configure Azure Blob Storage RBAC permissions on the Cosmos DB container

Why it fails: Blob Storage RBAC governs blob containers, not Cosmos DB data-plane operations, so it cannot restrict document reads or writes. It is tempting because Azure RBAC is the standard access-control mechanism, and it would be correct if the embeddings were stored in Azure Blob Storage rather than Cosmos DB.

Share the primary master master-key with all microservices

Why it fails: The primary master key grants full control over the account, so every microservice could write and delete documents, defeating read-only enforcement. It is tempting because keys are simple to distribute, and it would be correct for a trusted single service needing unrestricted account access.

Disable authentication on the Cosmos DB account during query execution

Why it fails: Disabling authentication removes all access control, letting any caller read, write or delete documents rather than restricting microservices to reads. It is tempting because it avoids credential management during testing, and it would be correct only for an isolated, non-production account with no sensitive data.

Send all events to an Azure Service Bus Topic, then configure a logic app to forward them to Event Grid.

Why it fails: Service Bus topics provide brokered messaging with subscriptions, not Event Grid domain topic routing; inserting a logic app adds a hop that cannot partition by tenant ID at publish time. It is tempting because Service Bus filters resemble routing, but the correct approach sends events directly to the Event Grid Domain with the tenant ID as subject.

Use Azure Event Hubs capture keys to route events to tenant-specific storage containers.

Why it fails: Event Hubs capture writes stream data to Storage blobs; it neither partitions Event Grid domain events nor routes them to domain topics by tenant ID. It is tempting because capture and partitioning sound related, but the correct approach publishes to the domain with the tenant ID as the subject, letting Event Grid route to the matching domain topic.

Create separate Event Grid custom topics for each tenant and configure an Azure API Management gateway to multiplex the requests.

Why it fails: Separate custom topics bypass the domain's built-in tenant-to-domain-topic routing, and API Management multiplexing adds a gateway layer that does not partition events by tenant ID. It is tempting because per-tenant isolation sounds secure, but the correct approach publishes to one Event Grid Domain using the tenant ID as the event subject.

All queued messages are automatically migrated to the secondary region within 5 seconds.

Why it fails: Service Bus geo-failover does not replicate subscription messages; only metadata is replicated, so queued messages in the primary namespace are lost. Messages are only preserved if the application itself copies them. Automatic migration suits active geo-replication of data stores, not Service Bus topics.

Azure Event Grid automatically replays all lost messages from the storage capture.

Why it fails: Event Grid handles event routing and subscriptions; it does not capture Service Bus subscription messages or replay them after failover. Storage capture is a separate feature and is not enabled by geo-disaster recovery pairing. Replay would be the right answer only where message capture to storage had been explicitly configured beforehand.

The primary namespace messages are permanently deleted and cannot be recovered.

Why it fails: Geo-disaster recovery failover promotes the secondary namespace; messages held in the primary's subscriptions are not replicated and remain stranded there, effectively unrecoverable once the primary is lost. Permanent deletion is the eventual outcome, but the mechanism is the absence of message replication, not an explicit delete operation.

Hardcode the secondary search IP address in client application configuration files

Why it fails: Azure AI Search endpoints are DNS names, and regional service IPs change, so hardcoded addresses break failover; clients must query the secondary service endpoint or use a traffic manager. It tempts as a simple static configuration, but it suits fixed on-premises endpoints, not regional Azure services.

Rely on Cosmos DB automatic failover to replicate search indices

Why it fails: Cosmos DB failover replicates database data, not Azure AI Search indices, which are a separate service with its own replication; search queries would still hit the failed region. It tempts because Cosmos DB failover is a genuine HA pattern for the data tier, not the search tier.

Configure SQL replication between search indexes

Why it fails: Azure AI Search has no SQL replication mechanism; indexes are not SQL databases, so this cannot synchronise primary and secondary services. It is tempting because SQL replication is a familiar geo-redundancy pattern for relational data, and would fit a scenario replicating Azure SQL Database rather than search indexes.

Configure an Azure Front Door health probe pointing to the internal container IP

Why it fails: Azure Front Door probes external endpoints for global load balancing, not internal container readiness within Container Apps. The platform's own readiness probe governs traffic routing to replicas. Front Door health checks suit multi-region HTTP failover, not intra-revision container gating.

Configure a TCP liveness probe pointing to port 22 for SSH management

Why it fails: Port 22 serves SSH management, not the application's HTTP endpoint on 8080, so a TCP probe there tests the wrong process. Liveness probes restart unhealthy containers; readiness probes gate traffic. A TCP check on 22 would pass even if the model server were unready.

Configure a startup probe that restarts the container if CPU usage drops below 5 percent

Why it fails: Startup probes verify initial container start, not readiness for traffic, and CPU thresholds are not a supported probe type. Azure Container Apps readiness probes use HTTP or TCP checks against port 8080. CPU-based restart logic belongs to autoscaling rules, not health probes.

Use an internal VNET peering.

Why it fails: Peering is for connectivity, not performance optimization of the NIC.

Enable standard load balancing.

Why it fails: Standard LB adds overhead and is not optimized for MPI traffic.

Disable the pod network policy.

Why it fails: Disabling network policy doesn't improve raw performance.