Select Two (Multi-Select) Questions

AMQP 1.0 broker transaction coordination

Why it fails: Event Grid subscriptions support webhook, Event Hubs and Service Bus destinations with filters, retry policy, dead-lettering and Microsoft Entra ID authorisation; AMQP 1.0 transaction coordination belongs to Service Bus itself. It is tempting because Event Grid and Service Bus are both Azure messaging services often paired in the same architecture.

Service Bus session lock duration extension

Why it fails: Session lock duration extension is a Service Bus feature for ordered, session-based queue processing; Event Grid subscriptions expose no session concept, only delivery retry and dead-letter settings. It is tempting because both services appear in event-driven designs and Service Bus is a supported Event Grid handler destination.

Grant every user Contributor rights to the entire Azure subscription.

Why it fails: Contributor rights let every user modify or delete AI resources, so least-privilege governance collapses; role assignments scoped to specific resource groups with Reader or AI-specific roles are required. It is tempting because Contributor is a common starting grant for teams needing broad deployment capability, but subscription-wide scope is never justified for all users.

Share the master subscription co-administrator password with all external contractors.

Why it fails: Sharing the co-administrator password with external contractors grants unrestricted subscription-wide control, removes accountability, and cannot be revoked per individual, directly undermining governance. It is tempting when contractors need broad access quickly. The correct approach is Microsoft Entra ID accounts with scoped role assignments and just-in-time privileged access.

Disable all firewall rules on Azure Key Vault.

Why it fails: Removing Key Vault firewall rules exposes secrets to any network, defeating the private endpoint and IP restriction controls that governance demands. Firewall rules are disabled only when a vault must accept public traffic during initial setup or from unlisted client networks, which contradicts this scenario's security objective.

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.

Azure Notification Hubs

Why it fails: Notification Hubs pushes mobile push notifications to app users across platforms; it does not publish resource-change events to subscribers. It would suit broadcasting alerts to device tokens, but the stem requires discrete reactive event notifications on resource creation or modification, which Event Grid and Event Hubs deliver.

Azure Event Hubs

Why it fails: Azure Event Hubs ingests high-volume telemetry and streaming data through partitions and consumer groups; it does not publish discrete resource-lifecycle notifications. It is tempting because Event Hubs is the correct choice for streaming ingestion pipelines, but the stem requires reactive notifications when resources are created or modified.

Azure Service Bus Queues

Why it fails: Azure Service Bus Queues store messages for competing consumers to pull, providing brokered point-to-point messaging rather than discrete resource-lifecycle event notifications. It is tempting because Service Bus is the correct choice for reliable command and message queuing between applications, not for reacting to resource creation or modification.

Azure Notification Hubs

Why it fails: Notification Hubs pushes mobile push notifications to tagged device registrations across platforms; it does not provide a general pub/sub broker decoupling arbitrary publishers from consumers. It suits broadcasting alerts to iOS, Android and Windows devices, not machine learning inference event routing.

Azure Storage Queues

Why it fails: Storage Queues implement point-to-point messaging where each message is consumed by one receiver, so they cannot fan out one event to multiple independent subscribers. Service Bus topics or Event Hubs provide that pub/sub decoupling. Storage Queues suit simple work distribution between a single producer and consumer pool.

Azure Event Hubs Capture

Why it fails: Capture writes Event Hubs stream data to Azure Storage or Data Lake in Avro format; it is a archival sink, not a broker decoupling publishers from subscribers. Event Hubs itself provides the pub/sub decoupling. Capture suits long-term retention and batch analytics, not consumer fan-out.

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.

Requirement to store petabytes of data.

Why it fails: Azure AI Search caps index size far below petabytes and is not designed as a bulk data store; Cosmos DB for NoSQL handles petabyte-scale storage. It tempts because AI Search ingests large corpora, but that data lives in the source store, with only indexed content pushed into the search service.

Requirement for high-frequency transactional ACID updates to metadata.

Why it fails: Azure AI Search is a read-optimised search index, not a transactional store; it offers no multi-document ACID guarantees for high-frequency metadata updates. It tempts because search indexes hold metadata, but ACID transactional workloads favour Cosmos DB for NoSQL, which provides those guarantees.

Need for lowest possible latency at the database level.

Why it fails: Cosmos DB for NoSQL delivers single-digit-millisecond reads and writes at the database layer, so latency is its strength, not Azure AI Search's. Azure AI Search is tempting because it also returns results quickly, but its purpose is full-text and vector relevance ranking over indexed content, not minimal-latency transactional storage.

Azure SQL database table creation scripts (DDL)

Why it fails: Azure Workbooks render interactive visualisations from query and metric data, not schema-definition statements. DDL scripts create or alter tables, so they produce no workbook tile. This option tempts because Azure SQL is a genuine Azure Monitor data source, and DDL would be the right choice when provisioning the storage layer that a workbook later queries.

Azure Key Vault plain-text master password files

Why it fails: Azure Key Vault stores secrets, keys and certificates; it does not render visualisations, so it cannot appear as a Workbook component. The distractor tempts because Key Vault legitimately supplies credentials to dashboards querying protected data sources, but that is configuration behind a query, not a display element.

Docker container image binary layers

Why it fails: Docker image layers are stored as blobs in a registry, not as workbook visualisation components, so they cannot be rendered on a dashboard. The option tempts because container registries do hold image layers for deployment pipelines; that storage concern belongs to Azure Container Registry tasks, not Azure Monitor Workbooks.

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.

A Cognitive Services storage blob container

Why it fails: A vector profile references a vectoriser and an algorithm configuration (HNSW or exhaustive KNN); blob containers hold source documents for indexers, not vector search configuration. It is tempting because AI Search indexers do read blobs, but storage is unrelated to the vector profile's required pairings.

An Azure SQL connection string

Why it fails: A vector profile requires a vectoriser and an algorithm configuration (HNSW or exhaustive KNN); Azure SQL connection strings belong to indexer data sources, not vector profiles. It is tempting because SQL databases commonly feed search indexes, but the connection string plays no part in the vector profile itself.

A Cosmos DB throughput RU/s setting

Why it fails: Vector profiles pair a vectoriser with an algorithm configuration such as HNSW; Cosmos DB throughput is a database provisioning setting with no role in Azure AI Search vector configuration. It is tempting because Cosmos DB can serve as a data source, but RU/s never appears in a vector profile.

Azure Bastion audit logs.

Why it fails: Azure Bastion audit logs record RDP and SSH sessions to virtual machines, not application requests, dependencies or model inference telemetry, so they cannot diagnose the AI web app's failures. They are tempting because Bastion logging is genuinely useful when investigating suspicious administrative access to jump-host VMs.

Azure Firewall packet capture PCAP files.

Why it fails: Azure Firewall PCAP capture is a network forensics tool, not an application telemetry source, and captures must be enabled per-flow. It is tempting when diagnosing connectivity faults, but AI application troubleshooting needs application logs, traces and metrics instead.

Verify the AMQP listener port 5671 firewall rules on the function app.

Why it fails: Event Grid delivers events over HTTPS webhooks, not AMQP, so port 5671 firewall rules are irrelevant to event delivery. It is tempting because AMQP 5671 is the standard port for Service Bus and Event Hubs, and verifying it would be correct when troubleshooting those AMQP-based services.

Review Service Bus session lock renewal logs.

Why it fails: Service Bus session lock renewal logs relate to Service Bus queues, not Event Grid subscriptions, so they reveal nothing about event delivery. It is tempting because session locks are a genuine troubleshooting area, and reviewing them would be correct when diagnosing a Service Bus-triggered function with session-enabled queues.

Check Event Hubs consumer group checkpoint offset status.

Why it fails: Event Hubs consumer group checkpoints track offset progress for Event Hubs streams, not Event Grid subscriptions, so this reveals nothing about the failing trigger. It is tempting because checkpoint lag genuinely diagnoses missed events — but only when Event Hubs, not Event Grid, delivers them.

Direct modification of physical Azure datacenter top-of-rack switches

Why it fails: Container Apps networking operates at the platform layer, exposing ingress, VNet integration and private endpoints; customers never touch physical datacentre switches, which Microsoft manages. It is tempting because network isolation implies control of underlying fabric, and would be correct only for a dedicated hardware or ExpressRoute peering scenario.

Direct attachment of physical Fibre Channel storage SAN arrays

Why it fails: Container Apps abstracts storage entirely; Fibre Channel SAN attachment belongs to IaaS virtual machines, not a serverless container platform. It is tempting because persistent storage is a genuine Container Apps concern, and would be correct if the workload ran on Azure VMs requiring block-level SAN connectivity.

Disable all scoring and ranking algorithms to save CPU cycles

Why it fails: Disabling scoring and ranking removes relevance ordering, so the highest-similarity documents cannot be surfaced, destroying precision. It is tempting because ranking consumes CPU, and would be correct only for workloads returning the full result set unordered, such as bulk exports where relevance is irrelevant.

Store embeddings as plain text strings in unindexed fields

Why it fails: Plain-text embeddings in unindexed fields cannot be searched by vector similarity, so retrieval returns nothing and recall collapses. It is tempting because storing raw vectors as text is convenient for debugging or export, and would be correct for archival or inspection, not for query-time vector search.

replicaCount

Why it fails: replicaCount sets how many query-serving replicas the search service runs, affecting throughput and availability rather than the HNSW graph's speed, memory or recall trade-offs. It is tempting because replicas influence query performance, and it would be correct when scaling query capacity or providing high availability.

partitionCount

Why it fails: partitionCount controls index storage sharding and overall service capacity, not the HNSW graph parameters that govern recall against latency and memory. It is tempting because partitions affect indexing throughput, and it would be correct when scaling storage or write performance for a large index.

maxTextLength

Why it fails: maxTextLength caps the characters indexed per document field; it is a field definition property, not part of the HNSW parameters object, so it cannot tune graph traversal. It is tempting because it affects index size, and it would be correct when configuring analysers or field attributes for text content.

analyzerName

Why it fails: analyzerName applies only to searchable string fields to override the default language analyser; it is optional and invalid on non-string fields. It tempts because analysers govern tokenisation, but the two properties required on every field are name and type.

scoringProfile

Why it fails: scoringProfile is an index-level collection that customises relevance ranking; it is never a per-field property. It tempts because relevance tuning feels fundamental to search design, yet every field must instead define its name and data type.

vectorDimensions

Why it fails: vectorDimensions is set only on fields of type Collection(Edm.Single) used for vector search, not on every field. It tempts when the index is vector-enabled, but the mandatory per-field properties remain name and type regardless of field kind.

Execute az aks browse to open the Kubernetes dashboard.

Why it fails: Azure Container Apps does not expose a Kubernetes API, so az aks browse has no cluster to connect to and returns an authentication or connection failure. It is tempting because Container Apps runs on Kubernetes underneath, but the dashboard would be correct when troubleshooting an AKS cluster directly.

Use kubectl describe pod to inspect Kubernetes events.

Why it fails: Container Apps abstracts the underlying Kubernetes control plane, so no pod objects are exposed and kubectl describe pod cannot reach the environment. It is tempting because the platform is Kubernetes-based, but kubectl describe pod would be correct when diagnosing pods in an AKS cluster you administer.

Automatic deployment of bare-metal hypervisors

Why it fails: Azure Container Apps is a serverless container platform; it abstracts the host layer entirely, so hypervisor deployment is not exposed or managed by the service. It would be the correct choice when provisioning virtual machines directly, where you control the underlying hypervisor through Azure infrastructure offerings.

Direct root SSH access to individual container instances for interactive debugging

Why it fails: Azure Container Apps does not expose container instances for direct SSH; interactive debugging uses revision-based log streaming and console access through the platform. Root SSH would be correct with self-managed Kubernetes or Azure Container Instances, where you own the container host and its access controls.

Direct manual configuration of control plane Kubernetes master nodes

Why it fails: Azure Container Apps manages the Kubernetes control plane for you; master nodes are never surfaced for manual configuration. Direct control-plane administration would be the correct choice with Azure Kubernetes Service, where node pools and control-plane settings are configurable through the platform.

Apache Kafka record batch binary schema

Why it fails: Event Grid custom topics natively accept only the Event Grid schema and CloudEvents 1.0 JSON; Kafka record batches are a Kafka protocol format. It tempts because Event Grid offers a Kafka-compatible endpoint, but that endpoint translates rather than natively supporting the binary schema.

AMQP 1.0 binary stream envelope

Why it fails: Event Grid custom topics publish Event Grid schema or CloudEvents 1.0 JSON, not AMQP 1.0 envelopes. AMQP suits Service Bus queues and topics, which is why it appears plausible, but Event Grid does not natively accept that binary stream format.

SOAP 1.2 XML messaging schema

Why it fails: Event Grid custom topics support only Event Grid schema and CloudEvents 1.0 JSON; SOAP 1.2 XML is not accepted. SOAP is tempting because it is a recognised messaging standard, but it belongs to legacy web-service stacks, not Event Grid's HTTP-based publish model.

Disable the Application Insights telemetry client entirely in production to save bandwidth.

Why it fails: Disabling the telemetry client removes the very error and request data the scenario requires, so failures go unrecorded. It is tempting when bandwidth or ingestion cost is the concern, and disabling telemetry would suit an offline or air-gapped workload where no Application Insights resource exists.

Route all application logs exclusively to local text files on ephemeral container storage.

Why it fails: Ephemeral container storage is destroyed on restart, so logs vanish before troubleshooting and never reach Application Insights. Local file logging is tempting for low-latency debugging on a developer workstation, but the scenario requires centralised, queryable telemetry across instances.

Store plain-text passwords in telemetry custom dimensions.

Why it fails: Custom dimensions are transmitted to Application Insights and readable by anyone with access, so plain-text passwords become a credential leak. Storing secrets in telemetry is tempting for correlating authentication failures, but secrets belong in Azure Key Vault, referenced by identifier rather than logged.