Genaiops Infrastructure practice questions

Implement 'Private Link' for every regional endpoint.

Why it fails: Private Link secures traffic but does not manage regional request routing.

Deploy Azure Traffic Manager with 'Performance' routing.

Why it fails: Traffic Manager operates at the DNS level and lacks the acceleration features of Front Door.

Configure 'Global VNet Peering' between model endpoints.

Why it fails: VNet peering connects private networks but does not handle global request routing.

Deploy the model inside a dedicated 'Azure Kubernetes Service' node pool.

Why it fails: The model service is managed by Microsoft; it must be accessed via private endpoint.

Configure a 'Service Tag' for Azure OpenAI in the Firewall settings.

Why it fails: Service tags are for allow-listing, not enforcing private connectivity.

Add the 'Virtual Network' to the 'Allowed Subnets' in the AI Service.

Why it fails: This restricts access but does not necessarily enforce private path routing.

It can only be used with models deployed in the 'East US' region.

Why it fails: PTUs are available in multiple regions.

It automatically scales the number of tokens based on CPU usage.

Why it fails: PTUs are fixed capacity; they do not auto-scale like standard tiers.

Check the 'Quota' tab in the Azure Portal.

Why it fails: Quota tracks limits, not actual consumption.

Enable 'Diagnostic Settings' for the Azure AI resource.

Why it fails: Diagnostic settings export logs but don't provide real-time monitoring graphs.

It is incompatible with 'Streaming' requests.

Why it fails: PTUs support streaming just like standard deployments.

Query the 'ModelUsage' table in Log Analytics.

Why it fails: This is an indirect way to calculate usage, not a native monitor metric.

Enable 'Load Balancing' in the Azure AI Search resource.

Why it fails: Azure AI Search load balancing does not scale model inference endpoints.

Increase the 'Quota' of the underlying Azure subscription.

Why it fails: Quota limits the maximum capacity but does not automate scaling.

Set the minimum instance count to 0 in the deployment configuration.

Why it fails: Setting min to 0 is for cost-saving, not latency-based scaling.

Disable the 'Load Balancer' to save costs.

Why it fails: Disabling the load balancer removes traffic distribution and health-based failover, leaving one instance serving all requests. It is tempting as a cost-saving measure, but the load balancer is precisely what routes around failed replicas to maintain availability.

Use a 'Standard' tier App Service plan.

Why it fails: App Service plans are less flexible than AKS for custom model containers.

Deploy the container on a single large VM.

Why it fails: A single large VM creates a single point of failure, so a host outage takes the model offline entirely. It is tempting because vertical scaling gives substantial compute capacity for inference, but high availability requires multiple replicas distributed across nodes or availability zones.

Check the 'Activity Log'.

Why it fails: The Activity Log records control-plane operations such as deployment creation or modification, not token or compute consumption. It is tempting for auditing who changed what, but cost attribution needs usage metrics, not administrative event history.

Check the Azure AI Foundry 'Deployments' page.

Why it fails: The Deployments page lists deployment configuration and status, not token or compute consumption per deployment. It is tempting because deployments are what incur the cost, but identifying top consumers requires the cost or usage metrics view rather than deployment inventory.

Review the 'Quotas' tab.

Why it fails: The Quotas tab shows service limits and current quota usage against those limits, not billed consumption per deployment. It is tempting because quota usage correlates loosely with activity, but it cannot rank deployments by actual cost incurred.

A load balancer.

Why it fails: A private endpoint is a network interface in your subnet; Azure handles routing without a load balancer, so the required pieces are the endpoint and a private DNS zone. Load balancers are tempting because they distribute traffic across backends, and this option would be correct for spreading requests over multiple AI resource instances.

A firewall rule allowing all traffic.

Why it fails: Private endpoints deliver traffic over a private IP inside your virtual network, so an allow-all firewall rule is unnecessary and would not satisfy the required private DNS zone and subnet configuration. Firewall rules are tempting because Azure AI resources normally restrict access that way, and this option would be correct for controlling public inbound traffic.

A public IP address.

Why it fails: A private endpoint assigns a private IP from your subnet and disables public exposure, so a public IP address is not part of the setup. Public addressing is tempting because Azure AI resources are reachable publicly by default, and this option would be correct when configuring public network access instead of a private endpoint.

Configure a Load Balancer at the VNet level for the model endpoint.

Why it fails: A VNet-level load balancer distributes traffic only within one region's virtual network; it cannot span regions, so cross-region failover is impossible. It is tempting because load balancing sounds like availability, and it would be correct when scaling an endpoint across multiple backends inside a single region.

Set the model deployment to 'High Availability' mode in the Azure AI Foundry portal.

Why it fails: Azure AI Foundry offers no 'High Availability' deployment mode toggle; availability comes from deploying the model to multiple regional endpoints. It is tempting because a portal setting implies built-in resilience, and such a mode would be correct if the platform actually provided one-click regional redundancy.

Replicate the underlying storage account for the model weights across regions.

Why it fails: Replicating the storage account holding model weights provides data durability, not an inference endpoint in each region, so requests still hit one regional endpoint. It is tempting because geo-redundant storage protects artefacts, and it would be correct when the requirement is disaster recovery of model files rather than cross-region endpoint availability.

Configure the Prompt Flow runtime to use a Managed Identity with read access to the Blob Storage account.

Why it fails: Managed Identity is for authentication, not for enabling the logging of execution traces.

Deploy a specialized Azure Function to intercept and log flow run events.

Why it fails: Prompt Flow has built-in native logging capabilities that do not require an intercepting Azure Function.

Increase the timeout threshold in the runtime environment settings.

Why it fails: Timeout settings manage execution duration, not observability or trace capturing.

Enable a Virtual Network Service Endpoint on the storage account only.

Why it fails: A service endpoint only extends the storage account's identity to a subnet; it does not make the Foundry project private or block its public inbound endpoint. It is tempting because service endpoints secure PaaS-to-VNet access, and would be right if the requirement were restricting storage traffic rather than the project itself.

Implement an Azure Firewall to inspect all outbound traffic from the agents.

Why it fails: Azure Firewall inspects outbound egress from agents but leaves the Foundry project's own public inbound endpoint reachable, so traffic is not restricted to a private network. It is tempting because firewalls govern agent egress, and would be correct if the requirement were filtering outbound traffic rather than privatising the project.

Use an API Gateway with IP whitelisting.

Why it fails: An API gateway with IP whitelisting still exposes the Foundry project over its public endpoint and filters only at the HTTP layer, so private-network-only access is not achieved. It is tempting because gateways centralise inbound control, and would be correct if the requirement were restricting API callers by source address.

Change the VM SKU to a burstable instance type.

Why it fails: Burstable instances are not generally applicable to the managed compute runtimes used by Prompt Flow.

Implement a script to delete the runtime when the flow is finished.

Why it fails: This is an inefficient operational pattern compared to using native runtime shutdown policies.

Set the concurrency limit to zero.

Why it fails: Setting concurrency to zero stops the flow from processing, but does not release the underlying compute infrastructure.

Azure AI Resource

Why it fails: The Azure AI Resource is the top-level container, but the Project is where the actual model and deployment management occurs.

Azure Machine Learning Workspace

Why it fails: While related, in the context of Azure AI Foundry, the Project is the specific entity for GenAI assets.

Azure Resource Group

Why it fails: A Resource Group is a logical container for all Azure resources, not specific to AI Foundry assets.

Increasing the model throughput capacity.

Why it fails: Throughput capacity is a performance concern, not a data privacy or residency compliance requirement.

Enabling Public IP access for remote debugging.

Why it fails: Public IP access is a security risk and generally prohibited in strict compliance environments.

Deploying models across multiple global regions.

Why it fails: Global deployment might actually violate data residency requirements if the goal is to keep data in a specific region.

Reduce the model's max tokens parameter to a lower value so each request consumes fewer tokens.

Why it fails: Lowering max tokens reduces per-request token consumption but does not change the request rate, which is the likely cause of 429s when token throughput is already below quota. It could also truncate responses and degrade quality. This option misdiagnoses the bottleneck and introduces a functional regression without solving the throttling.

Enable diagnostic logging on the Azure AI Foundry project and wait for the logs to identify the throttled requests.

Why it fails: Diagnostic logging is useful for forensics but does not reduce throttling in real time. Waiting for logs to reveal the pattern leaves users experiencing 429s. This option confuses observability with mitigation; the engineer needs an action that changes request behavior or capacity, not one that only records it.

Increase the model deployment's tokens-per-minute quota by redeploying the model with a higher capacity SKU.

Why it fails: The scenario explicitly requires a solution without redeploying the model, and the metrics show token throughput below the provisioned quota, so raising capacity would not address the bursty request pattern. Redeploying also introduces downtime and cost. This action is therefore both contrary to the stated constraint and unlikely to fix the root cause.

Enable private endpoints on the Azure AI Foundry resource so that traffic never leaves your virtual network.

Why it fails: Private endpoints secure network traffic between your virtual network and the Foundry resource, but the service still processes and may store prompts and completions according to its data-handling policy. Network isolation does not change retention behavior. This option confuses transport security with data retention and does not meet the stated privacy requirement.

Set the model deployment's content filter to block all categories so that no prompts or completions are processed.

Why it fails: Content filters evaluate and block harmful content; they do not control whether data is logged or retained, and blocking all categories would break the application. This option misconstrues the purpose of content filtering and would render the GenAI application unusable. It does not address the requirement to avoid logging prompts and completions.

Configure a customer-managed key on the Azure AI Foundry resource so that all stored data is encrypted with your key.

Why it fails: Customer-managed keys encrypt data at rest with a key you control, but they do not prevent Microsoft from storing prompt and completion data in the first place. The requirement is about whether the data is retained, not how it is encrypted. This option addresses a different control and would leave the compliance gap unresolved.

Configure 'Cost Analysis' alerts in the Azure Portal.

Why it fails: Cost Analysis alerts in the Azure Portal aggregate spend at subscription, resource group or tag scope, not per Foundry project. They suit budget threshold notifications across an Azure estate; per-project tracking requires Foundry's own project-level cost and usage reporting.

Implement 'Azure Policy' to restrict resource types.

Why it fails: Azure Policy enforces governance rules over resource configurations, such as restricting which resource types can be deployed, so it cannot attribute token or compute consumption to individual projects. It is tempting because it genuinely controls resource provisioning and compliance. Cost attribution per project instead requires tagging resources and analysing usage through Microsoft Cost Management.

Switch to 'Pay-As-You-Go' subscription model.

Why it fails: Switching to Pay-As-You-Go changes the billing arrangement, not the granularity of usage reporting; it provides no per-project attribution. It is chosen when moving off commitment tiers or enterprise agreements, not when you need to isolate costs by project.

Disable the 'Streaming' flag in the agent request.

Why it fails: Streaming governs response delivery mode, not transport reliability; disabling it leaves retries and circuit breakers untouched. It is tempting because streaming connections can drop mid-response, so it would be the right move if streaming itself caused the failures rather than transient service errors.

Switch the model to a higher tier instance type.

Why it fails: Transient faults require retry, circuit-breaker, and fallback logic; a larger instance type changes capacity, not fault tolerance. It is tempting because scaling up genuinely helps sustained load or rate-limit throttling, but it cannot absorb intermittent network or service failures between calls.

Increase the 'Timeout' parameter in the model deployment manifest.

Why it fails: A longer timeout only delays failure detection, holding threads open while the call still fails; resilience needs retry with backoff and fallback. It is tempting because timeouts do cause errors when a service responds slowly, so raising it would be correct for a genuinely slow-but-healthy endpoint.

Review individual request headers in the app logs.

Why it fails: Request headers in application logs capture only traffic reaching that app, omitting model invocations from other clients, pipelines and services, so the audit is incomplete. Microsoft Entra ID sign-in and audit logs centralise access events. Header review suits debugging a single application's inbound requests.

Use 'Azure Advisor' to detect unauthorized access.

Why it fails: Azure Advisor surfaces cost, security and reliability recommendations from resource telemetry, not per-request model access records, so it cannot produce the audit trail required. It is tempting because it does flag misconfigurations, and would be the right tool for reviewing best-practise recommendations across an Azure estate.

Download the 'Model Usage' report from the billing console.

Why it fails: A billing console usage report aggregates token and request counts for invoicing, omitting caller identity, timestamps and prompt content needed for auditing. It is tempting because it is readily available and shows which deployments were used, and would suit cost allocation or chargeback reporting rather than access auditing.

Pass the key as an environment variable in the deployment YAML.

Why it fails: Environment variables in deployment YAML are stored in plaintext and visible to anyone with access to the manifest or runtime, so the key is not protected at rest or in logs. It tempts because environment variables are the standard mechanism for injecting non-secret configuration into containerised deployments.

Hardcode the key in the prompt template.

Why it fails: Prompt templates are transmitted to the model and may be logged or exposed, so embedding the key there leaks the credential. Hardcoding is tempting for quick prototypes, but production secrets belong in Azure Key Vault, referenced by the project's managed identity or connection.

Save the key in a local '.env' file in the code repository.

Why it fails: A '.env' file in the repository commits the key to source control, exposing it to every clone and history entry. It tempts because '.env' files are the conventional local-development pattern for separating configuration from code, and work well for non-sensitive settings on a developer workstation.

Azure Monitor

Why it fails: Azure Monitor collects metrics, logs and traces for observability; it can alert on filter events but does not itself classify or block harmful content. It is the correct tool for telemetry and diagnostics, while response filtering must be enforced by a content safety service before output reaches users.

Azure Key Vault

Why it fails: Azure Key Vault stores and controls access to secrets, keys and certificates; it performs no inspection of model output. It is the correct component for centralising credential management, but content filtering requires a service that evaluates prompts and completions, such as Azure AI Content Safety.

Azure Bastion

Why it fails: Azure Bastion provides secure RDP and SSH access to virtual machines through the portal without public IPs; it never inspects LLM prompts or completions. It is the right choice for hardened remote administration, whereas harmful-content filtering needs a dedicated moderation layer in the inference path.