Prepare for your target AI and cloud role.

Model answer

I use RAG when the system needs current, private, attributable knowledge that can be updated without retraining. Fine-tuning is more suitable when the main problem is repeatable behavior, style, or task performance. I would begin with prompting and retrieval, measure the failure mode, and fine-tune only when evaluation shows that knowledge retrieval is not the core issue.

Model answer

I separate retrieval from generation. First I measure expected-source coverage and relevance on a curated question set. Then I measure groundedness, answer completeness, citation correctness, abstention, latency, and cost. I compare every change against a stable baseline and inspect failures rather than relying only on an aggregate score.

Model answer

I narrow the task, supply authoritative context, require inspectable evidence, and define a no-answer path. I validate structured outputs, evaluate unsupported claims, and improve retrieval before endlessly rewriting the prompt. For high-impact decisions, I add deterministic checks or human review because a prompt alone cannot guarantee truth.

Model answer

I start with task quality, safety, latency, context, tool or modality needs, regional availability, quota, data requirements, and cost. I create a representative evaluation set, establish the smallest viable baseline, and compare candidate deployments on successful-task cost rather than token price alone.

Model answer

The prompt, model, schema, tools, and retrieval settings must be versioned together. I run deterministic contract tests and a representative quality and safety evaluation, compare results with the approved baseline, inspect high-impact failures, and confirm latency and cost budgets. I release only with a rollback path and version-aware monitoring.

Model answer

Managed identity removes stored application credentials and lets Azure issue tokens to an Azure resource. I grant the identity only the required role at the narrowest useful scope. It reduces secret distribution and rotation work, but it does not remove the need for authorization design, auditing, or environment isolation.

Model answer

I trace the path from the application subnet to the service: DNS resolution, private endpoint approval and IP, private DNS zone links, routing, network security rules, firewall policy, and the application identity. I test name resolution and network reachability separately from authorization so I do not confuse a 403 with a DNS or routing failure.

Model answer

The platform team should operate shared guardrails such as management groups, subscription vending, connectivity, identity foundations, policy, and common monitoring. The workload team should own the application, Foundry resources, models, retrieval, tools, workload telemetry, and reliability outcomes. I document interfaces and escalation paths because shared ownership without a responsibility matrix creates operational gaps.

Model answer

I define workload priorities, concurrency controls, retry limits, back-pressure, and a safe degraded mode. Where requirements justify it, I pre-evaluate a secondary deployment or region and keep routing configuration versioned. I monitor quota headroom and test failover because an untested fallback is only a diagram.

Model answer

I separate sandbox and production budgets, tag ownership, set alerts, cap requests and tokens, and track cost per successful task. I give teams a paved-road environment with visible limits and cleanup automation. Optimization follows measured drivers such as model calls, retrieval, indexing, storage, observability, and idle environments.

Model answer

I use a deterministic workflow when the steps and decisions are known and auditable. I consider an agent when requests vary and the system must choose among tools or plans using context. I keep deterministic controls around authorization, validation, approvals, budgets, and final execution.

Model answer

I expose the smallest tool set, use strict schemas, authenticate the caller, authorize each operation, validate arguments, constrain network access, set timeouts and rate limits, and log decisions and outcomes. Read, reversible write, external communication, and destructive actions receive different approval policies.

Model answer

MCP is useful when multiple clients need reusable tool discovery and a maintained integration contract. A direct typed API can be simpler for one caller and one stable operation with strict latency or authorization needs. MCP improves interoperability; it does not replace trust review, authorization, validation, or observability.

Model answer

I begin with no persistent memory and add only the minimum needed for a defined user outcome. I separate short-lived working context from user-approved durable facts, attach ownership and retention, enforce per-user access and deletion, and never let model-generated summaries become authoritative records without validation.

Model answer

I evaluate the final task outcome and the trajectory. The test contract defines allowed tools, forbidden actions, expected evidence, approval points, step limits, and resource budgets. I score task completion, tool selection, argument accuracy, output use, policy compliance, recovery, latency, and cost on normal and adversarial scenarios.

Model answer

The pipeline should validate application code, infrastructure, prompts, schemas, retrieval configuration, and evaluation assets. It runs deterministic tests on every change, representative offline evaluations before promotion, environment smoke tests, security checks, and records model and configuration versions with a rollback decision.

Model answer

I prefer workload identity federation or another short-lived identity flow rather than stored client secrets. The pipeline identity receives only the deployment actions required for that environment. Production has a separate identity and approval boundary, and runtime identities remain distinct from deployment identities.

Model answer

I use a secured remote backend with encryption, locking, restricted access, recovery, and separate state boundaries for independently owned or deployed environments. I avoid putting secrets into state, pin provider versions, review plans, and keep production apply permissions narrower than plan permissions.

Model answer

I monitor successful task completion, groundedness or domain quality, schema failures, refusals, tool calls, approval compliance, retrieval failures, safety events, latency, token use, and cost. Every trace carries prompt, model, tool, and retrieval versions while avoiding unnecessary sensitive content.

Model answer

Databricks is useful when the organization already relies on it for governed data engineering, feature or document pipelines, analytics, experimentation, and model lifecycle work. I would not add it solely for a small chat application. The decision depends on data gravity, governance, team skills, integration boundaries, and operating cost.

Model answer

Terraform is a declarative infrastructure-as-code tool. You describe the desired infrastructure in configuration, Terraform loads provider plugins, reads its state and the remote systems, builds a dependency graph, and proposes the actions needed to converge the real infrastructure on that desired state. The normal workflow is initialize, review a plan, and apply an approved change.

Model answer

Infrastructure as code makes infrastructure repeatable, reviewable, versioned, and automatable. Terraform can create consistent environments, expose proposed changes before execution, and reduce undocumented configuration. The benefit is not merely speed: code review, policy checks, audit history, and reproducible recovery improve operational control.

Model answer

A provider is the plugin that lets Terraform communicate with an API such as Azure, AWS, GitHub, or Kubernetes. A resource block declares an infrastructure object Terraform should manage through that provider. Provider requirements and versions should be constrained and committed through the dependency lock file so runs remain predictable.

Model answer

State maps resource addresses in configuration to real infrastructure objects and stores metadata and observed attributes. If the only copy is deleted, the infrastructure usually continues running, but Terraform loses those bindings and can propose duplicate creation or other incorrect actions. I would stop applies, restore a versioned backend backup where possible, or carefully import existing objects rather than recreating blindly.

Model answer

A plan calculates and displays the changes Terraform proposes; it does not normally modify managed infrastructure. Apply executes a plan and updates state after operations complete. In CI/CD I save the plan artifact, require review for production, and apply that exact approved plan so the executed change matches what reviewers saw.

Model answer

During planning, Terraform refreshes its understanding of managed resources and compares remote reality, recorded state, and configuration. A difference caused outside Terraform appears in the plan. I first determine whether the manual change should be reverted, represented in code, or imported; I do not automatically apply every drift plan because that can overwrite a legitimate emergency change.

Model answer

A module is a collection of Terraform configuration managed as one unit; every root configuration is already a module. A reusable child module should have a focused responsibility, typed and documented inputs, useful outputs, constrained providers, safe defaults, and versioned releases. I avoid modules that expose every provider argument because they create abstraction without a stable contract.

Model answer

I use count for identical instances or simple conditional creation where numeric indexes are acceptable. I use for_each when instances have stable business keys or distinct values, because adding or removing one key does not renumber unrelated objects. Switching changes resource addresses, so I use moved blocks or controlled state moves and inspect the plan instead of changing the meta-argument and risking replacement.

Model answer

A remote backend gives the team one authoritative state location and can provide access control, encryption, versioning, and state locking. It prevents engineers from passing local state files around and reduces stale-state concurrency problems. Backend credentials should come from short-lived identity or secure environment configuration, not be embedded in Terraform code or plan files.

Model answer

A supported backend locks state during operations that can write it, preventing concurrent writers from corrupting state or acting on stale information. For a stuck lock I first prove that no run is still active, inspect the owning job, and prefer waiting or fixing pipeline cleanup. I use force-unlock only for my own abandoned lock and with the exact lock ID, because breaking an active lock can create conflicting writes.

Model answer

I avoid hardcoding secrets and prefer short-lived workload identity or retrieving values from an approved secrets system. Marking a value sensitive only suppresses normal display; it can still exist in state and plan files. I therefore secure remote state with encryption, narrow access, audit logs, retention controls, and use ephemeral or write-only capabilities where the provider and Terraform version support them.

Model answer

I normally give each environment a separate state boundary, backend key, identity, permissions, and approval policy while sharing versioned modules. Separate root configurations make blast radius and ownership explicit. Workspaces can suit short-lived copies of the same configuration, but I do not use one shared state file for all environments because a single mistake could affect production and state access cannot be isolated cleanly.

Model answer

I would first compare the exact artifact digest, source revision, configuration, feature flags, migrations, and dependencies used in staging and production. A sound pipeline builds an immutable artifact once, records its provenance and test results, then promotes that same artifact through protected environments. I would also compare environment-specific configuration and runtime versions, add deployment smoke tests, and keep a reversible rollback or roll-forward decision based on user impact.

Model answer

I automate fast, deterministic checks on every change, such as unit, contract, dependency, and infrastructure validation. I reserve human approval for meaningful risk boundaries, such as a production environment or a high-impact migration, and make the approver independent of the change where required. The deploy identity should be narrowly scoped and short-lived, environments should enforce branch and approval rules, and progressive rollout plus health checks should stop or reverse a bad release quickly.

Model answer

I stop before apply and preserve the plan and state context. I inspect the resource address, configuration diff, provider and module versions, remote object, recent out-of-band changes, and state lineage. I check whether a rename, immutable property, import, or drift caused the proposed replacement, then test a correction in a safe environment and review a fresh plan with the service owner. I apply only after the intended change and recovery plan are clear; I never edit state or bypass the plan to make the warning disappear.

Model answer

I define state boundaries around ownership, lifecycle, and blast radius rather than putting the whole platform into one root configuration. Reusable modules expose a small, versioned contract; environment roots compose those modules with reviewed inputs. Each state has protected remote storage, locking where supported, backups, narrowly scoped access, and an environment-specific deployment identity. CI validates and plans changes, while production apply is gated and uses the reviewed plan or equivalent immutable evidence.

Model answer

I trace one expected source record through extraction, landing, transformation, and publication using run IDs, source watermarks, partition dates, and lineage. I compare source counts and freshness with each stage's accepted and rejected records, inspect skipped activities and late-arriving data, then verify the consumer is reading the expected table or partition. I repair from a known checkpoint or bounded backfill, make the missing-data condition visible, and add a freshness or completeness assertion so orchestration success cannot mask a bad data product.

Model answer

I assume retries and replays can produce duplicates unless the source and sink contract proves otherwise. I assign stable event or business keys, make writes idempotent through deduplication or upsert semantics, use checkpoints and event-time rules appropriate to the workload, and quarantine records that violate the schema. Backfills run with bounded ranges and observable checkpoints, and I validate reconciliation before publishing the refreshed output. I avoid promising end-to-end exactly-once behavior across independent systems without documenting the actual guarantees and failure boundaries.

Model answer

I begin with users, authoritative sources, allowed actions, data classification, quality targets, and failure consequences. Then I separate ingestion, permission-aware retrieval, generation, citations, tools, identity, network, evaluation, observability, and human escalation. I state assumptions and postpone service selection until the requirements and trust boundaries are clear.

Model answer

I structure the answer around the requirement, competing options, decision criteria, evidence, decision, and result. For example, I might choose simpler hybrid retrieval over a more autonomous query-planning approach because the measured quality gain did not justify additional latency and operating complexity. I also explain what evidence would make me revisit the decision.

Model answer

I restate the shared outcome and make constraints explicit. I bring a small decision record with risks, evidence, options, and a reversible test. If an exception is necessary, I define scope, compensating controls, owner, expiry, and review criteria rather than treating governance as an obstacle.

Model answer

I protect users first: contain unsafe actions, disable the affected capability or revert the version, and communicate the impact. I preserve evidence, build a verified timeline, separate model, retrieval, tool, data, and infrastructure causes, and run a blameless review. Corrective actions receive owners and verification tests, including new regression cases.

Model answer

I am direct about the boundary of my experience, then connect relevant production skills such as identity, networking, APIs, CI/CD, observability, and incident response. I describe a serious project with evaluation, security, cost, and failure testing, explain what remains unproven, and show how I would reduce risk under senior review.

Model answer

I start with the user outcome, business risk, and the few decisions that affect cost, trust, and delivery. I use one simple flow diagram, define unfamiliar terms only when needed, and present options with consequences. I keep deep implementation detail available as an appendix rather than making it the main story.