Assembling and Deploying Apps practice questions

Enable public endpoint access on the Model Serving cluster.

Why it fails: Enabling public access exposes the model endpoint to the internet, which violates security policies for private data integration. Model serving requires internal network routing to access private VPC resources securely, so public exposure is counterproductive and insecure for enterprise-grade generative AI applications that handle sensitive internal documentation.

Deploy the model as a library within a standard Databricks notebook.

Why it fails: Deploying a model as a library inside a notebook is not suitable for high-concurrency production serving. Model Serving provides a managed, scalable REST API endpoint that supports automatic scaling and resource isolation, which is necessary for serving generative AI models reliably in a production environment compared to interactive notebooks.

Increase the maximum instance count to ensure network path availability.

Why it fails: Increasing the instance count only addresses horizontal scaling and does not solve the fundamental network routing problem between the serving endpoint and the private VPC. Network connectivity policies are distinct from cluster scaling configurations and must be explicitly defined to establish paths to restricted internal network resources.

Increase max_instances to 10 to improve throughput.

Why it fails: Increasing the maximum instances improves throughput but increases potential costs during peak traffic. Without addressing the idle cost represented by min_instances, this change does not optimize costs and might actually lead to higher expenditures if traffic patterns are sporadic or highly variable throughout the day or night.

Change instance_type to CPU_MEDIUM to lower cost.

Why it fails: Switching from a GPU to a CPU instance type will drastically degrade the performance of generative AI models, which typically require hardware acceleration. While this reduces costs, the resulting latency and potential model failure make it an unsuitable strategy for production-grade generative AI applications that require low-latency inference.

Delete the tags section to save configuration memory.

Why it fails: Removing metadata tags provides no meaningful cost savings and negatively impacts observability and resource tagging in the Databricks environment. Tags are essential for tracking resource utilization and costs, which is critical for maintaining an organized and financially accountable infrastructure within the Databricks workspace for all production services.

Change the spark_version to an older stable release.

Why it fails: Older Spark versions typically lack the performance optimizations found in newer releases. Changing to an older version is unlikely to improve speed and may introduce compatibility issues with newer libraries. Performance improvements should be sought through scaling or code optimization rather than downgrading the underlying runtime engine.

Rename the job to 'optimized_training_job'.

Why it fails: Renaming a resource is a purely cosmetic change and does not affect the underlying compute or processing capabilities of the cluster. The job performance is determined by the resource allocation defined in the cluster configuration, not by the metadata name assigned to the job definition.

Remove the 'new_cluster' section and use the 'existing_cluster' ID.

Why it fails: Using an existing cluster might share resources with other processes, leading to resource contention and slower performance. Creating a 'new_cluster' for a job ensures resource isolation and predictable performance. Switching to an existing, uncontrolled cluster is generally the opposite of what is needed for optimization.

Use hardcoded 'if-else' statements within the notebook code.

Why it fails: Hardcoding environment logic into notebooks makes the code brittle and difficult to maintain. It violates the principle of separating configuration from logic. Environment-specific parameters should be handled at the deployment layer so that the same code can run in multiple environments without needing any internal changes.

Create separate branches in Git for each environment.

Why it fails: Using git branches for environment differences causes significant overhead and potential for merge conflicts. It is considered an anti-pattern. Instead, use a single codebase and apply environment-specific configuration values at deployment time through the bundle configuration to ensure that the code remains consistent across all environments.

Store environment variables in a Databricks SQL table.

Why it fails: Storing configuration variables in a SQL table creates a runtime dependency and adds unnecessary complexity. Configuration should be resolved at deployment time by the DAB CLI. This keeps the deployment process self-contained and avoids runtime failures caused by missing or incorrectly configured table lookups.

Setting a fixed cluster size with 10 instances.

Why it fails: A fixed cluster size is inefficient for variable traffic. It either over-provisions resources, resulting in unnecessary costs during low traffic, or under-provisions, leading to performance degradation during high demand. Autoscaling is the preferred approach for production environments to balance cost-efficiency with performance needs dynamically.

Disabling logging to increase inference throughput.

Why it fails: Disabling logging is a poor practice because it removes visibility into endpoint performance and errors. Without logs, troubleshooting issues in production becomes impossible. The performance impact of logging is generally negligible compared to the operational risks of running a production system without any telemetry or audit trail.

Using the 'default' public endpoint URL for testing.

Why it fails: Using public endpoints exposes your service to potential attacks and unauthorized access. Production deployments should always favor private connectivity options. Relying on public endpoints for anything other than trivial testing is a security risk that violates standard best practices for enterprise application architecture and data governance.

bundle validate

Why it fails: The 'bundle validate' command is strictly for checking the integrity of the YAML configuration files before deployment. It does not communicate with the workspace to check the status of actual assets, such as whether a model serving endpoint or a job is currently running or configured correctly.

bundle deploy

Why it fails: The 'bundle deploy' command is the action used to push the configuration to the workspace. It triggers the creation or update of resources. It is not an introspection or status command. While it provides output during the deployment process, it is not used to query existing status.

bundle list

Why it fails: There is no 'bundle list' command in the Databricks Asset Bundle CLI specifically for querying deployed asset states. Status information is generally managed through specific resource commands, as DABs act as a wrapper for managing those resources, not as a standalone monitoring dashboard for asset health.

Define the job in a separate Python script and call it from the YAML.

Why it fails: DABs are designed to manage configuration through declarative YAML files. While Python code can be referenced, the job definition itself must reside within the YAML structure for the bundle to recognize and deploy it as a managed resource alongside the rest of the application assets.

Create a notebook with the job schedule and import it.

Why it fails: While notebooks can contain logic, scheduling is an infrastructure concern that belongs in the bundle configuration. Mixing scheduling logic into the notebook itself makes it harder to manage and modify. The bundle configuration is the appropriate place to define execution frequency, ensuring consistency and clear configuration management.

Use the 'sync' section to automatically pull existing jobs from the workspace.

Why it fails: The 'sync' section in DABs manages file synchronization between your local environment and the Databricks workspace. It is not used for importing or defining job configurations. Resources like jobs must be explicitly defined in the YAML configuration to be tracked and managed by the bundle's deployment logic.

A Docker container image of the entire Databricks workspace.

Why it fails: Serving a model does not require packaging the entire Databricks workspace. Databricks Model Serving automatically handles the underlying containerization for the model code itself. Attempting to package the workspace would be counterproductive, as the service is designed to be lightweight and focused on the specific model artifact.

A local copy of the model stored as a pickle file in the Git repo.

Why it fails: Storing model artifacts directly in a Git repository is not recommended due to file size limits and security risks. Models should be saved using MLflow and registered in Unity Catalog. This approach ensures that the model is versioned correctly and managed within the secure Databricks governance framework.

A separate SQL Warehouse dedicated to model inference.

Why it fails: SQL Warehouses are designed for running SQL queries and BI workloads, not for model inference. Model Serving endpoints are a distinct compute resource specifically optimized for low-latency, real-time model serving. Using a SQL Warehouse for inference is not the intended use case and would likely fail to support the model.

Include a hardcoded personal access token directly inside the default target block to authenticate automated CI/CD pipelines.

Why it fails: Hardcoding personal access tokens in bundle configurations is a severe security risk and violates enterprise governance policies. Authentication should instead rely on environment variables, Databricks CLI profiles, or secure CI/CD secret management providers.

Configure a manual notebook execution step that compiles the bundle files into a compiled Java archive before deployment.

Why it fails: Databricks Asset Bundles do not require compilation into Java archives because Databricks Apps and agent frameworks natively execute Python code. Introducing manual notebook compilation steps adds unnecessary complexity and breaks automated workflows.

Set the runtime environment to execute exclusively on legacy Hadoop MapReduce clusters managed outside the workspace.

Why it fails: Modern generative AI applications and Mosaic AI Agent frameworks require modern compute paradigms such as serverless compute or specialized ML clusters. Hadoop MapReduce is entirely incompatible with modern deep learning inference and LLM serving workloads.

The database schema migration failed because the SQL warehouse was suspended during deployment.

Why it fails: While SQL warehouses can suspend, the deployment logs explicitly reference an infrastructure manifest error rather than a database connectivity timeout. Warehouse states do not prevent the initialization of the application deployment service itself.

The application source code exceeds the maximum file size limit imposed by the workspace storage volume.

Why it fails: File size limits for source code repositories are rarely exceeded by standard Python applications and agent frameworks. The deployment error points to configuration parsing failures rather than storage capacity restrictions.

The personal access token used for authentication has expired during the git synchronization phase.

Why it fails: Token expiration typically results in explicit 401 Unauthorized errors during CLI authentication steps. The exhibit points to an application assembly and provisioning failure rather than an initial authentication handshake rejection.

The model signature is missing the input schema definition.

Why it fails: The exhibit shows a 'signature' argument in the log_model function. While the exact content of the signature variable is not shown, the syntax itself is correct. A missing signature would cause inference errors rather than a deployment or compute-provisioning failure at the infrastructure level.

The pip_requirements list is incompatible with the serverless environment.

Why it fails: The provided packages are standard and well-supported in Databricks environments. Using specific versions is a best practice to ensure environment consistency. These requirements do not cause infrastructure provisioning failures; they would only cause runtime errors if the libraries failed to install or were incompatible with the base image.

The model artifact_path must be a full S3 URI.

Why it fails: The 'artifact_path' argument in 'log_model' is a relative path within the MLflow run directory, not a full cloud storage URI. MLflow handles the artifact storage backend automatically, so providing a local relative path is correct. This is not the cause of a deployment failure.

Store the secret in a .env file and include it in the bundle

Why it fails: Including a .env file in the bundle is a security vulnerability because it would be checked into the source control repository. This exposes all sensitive keys to anyone with access to the code. Environment-specific secrets should always be retrieved from a secure secret management service at runtime.

Use a comment in the YAML file to warn users not to share it

Why it fails: Security by documentation is not a control. Relying on human behavior to protect credentials is guaranteed to fail in an enterprise environment. Technical controls, such as secret scopes, must be implemented to ensure that secrets remain inaccessible to unauthorized users, regardless of how well the code is documented.

Encrypt the secret string directly inside the YAML file

Why it fails: Encrypting a string inside a YAML file creates a management nightmare. If the encryption key is compromised, the secret is exposed. Furthermore, Databricks does not support decrypting arbitrary strings embedded in YAML files. Use the native Secret Scope API to maintain a secure and manageable credential lifecycle.

Run `databricks bundle deploy -t prod --var="catalog_name=prod_catalog"`.

Why it fails: The `-t prod` flag selects the correct target, but `--var` is not a supported flag for `databricks bundle deploy`. Databricks Asset Bundles expect variable overrides to be passed with `--var` only on `bundle validate` and `bundle run`, not on `bundle deploy`. This command would fail with an unknown flag error and the production catalog variable would never be applied.

Run `databricks bundle deploy -t prod --var catalog_name=prod_catalog`.

Why it fails: This looks identical to the correct answer but uses a space between `--var` and `catalog_name=prod_catalog`. The Databricks CLI accepts `--var` with a space separator, so this actually parses, but it does not persist the value; the correct mechanism is to define the variable in the target block of `databricks.yml` so every deploy in that target uses it. Without that definition the deploy fails.

Create a `databricks.yml` copy named `databricks.prod.yml` with the production values and run `databricks bundle deploy -f databricks.prod.yml`.

Why it fails: The Databricks CLI does not have a `-f` flag on `databricks bundle deploy` for choosing an alternate bundle file. Duplicating the bundle file also fragments configuration and defeats the purpose of targets. The supported pattern is a single `databricks.yml` with multiple target blocks, each carrying its own variable overrides, so this approach would not work.

Store the documents in DBFS and apply a cluster-level init script that filters results before returning them.

Why it fails: DBFS does not provide fine-grained access control comparable to Unity Catalog, and an init script runs at cluster startup, not per query. It cannot dynamically filter retrieval results based on the calling user's identity, so it fails to prevent unauthorized access to confidential documents.

Configure the endpoint with a service principal and set the vector search index to public read access.

Why it fails: Public read access on the index directly contradicts the requirement that only authorized users see retrieved content. A service principal authenticates the application, not the end user, so it cannot enforce per-user authorization for confidential financial documents.

Use a personal access token in the application code and rely on Unity Catalog table ACLs on the source documents.

Why it fails: Embedding a personal access token in application code is a security anti-pattern and does not enforce per-user access at query time. Unity Catalog ACLs on source tables do not automatically propagate to a Vector Search index, so retrieval could still return unauthorized content to the endpoint caller.

Enable Unity Catalog row filters on the underlying document table and let the endpoint's service principal determine the filter.

Why it fails: Row filters apply to the identity querying the table, which here is the endpoint's service principal, not the web app's end user. Every request would be filtered identically, so the department-specific behavior the front end requires would never occur. Row filters are useful for table-level governance but cannot carry a per-request end-user identity that varies request to request.

Store the user's department in a Delta table and have the agent look it up using the endpoint's service principal credentials at inference time.

Why it fails: Looking up the department with the endpoint's service principal gives the agent the department of the caller only if the caller is somehow identified, which this approach never does. The lookup would either return the service principal's own mapping or require a user identifier that is still missing. It also adds a synchronous table read on every request without solving the identity propagation problem.

Create a separate model serving endpoint per department and route users by having the front end choose the endpoint URL.

Why it fails: Per-department endpoints would multiply deployment, scaling, and cost overhead, and the routing decision still lives in the front end, which the team is trying to avoid. More importantly, it does not answer how identity is transmitted to the agent at request time; it merely sidesteps the need by duplicating infrastructure. This is operationally heavy and does not scale as departments are added.

Deploy the chain as a Databricks job that runs on a schedule and writes answers to a Delta table that the application reads.

Why it fails: A scheduled job precomputes answers for anticipated questions and cannot serve arbitrary user prompts interactively at low latency. It also introduces a delay between question and answer, and the requirement is a live Model Serving endpoint, not a batch pipeline writing to a table.

Bake the index contents into the logged model artifacts so the endpoint serves a self-contained snapshot of the embeddings.

Why it fails: Embedding the index inside model artifacts freezes retrieval at the moment of logging. When the nightly job rebuilds the index, the served model would still answer from stale vectors, and refreshing would require logging and redeploying a new model version, directly violating the no-redeploy requirement.

Register the chain in Unity Catalog and configure a serving endpoint that caches index lookups for 24 hours.

Why it fails: A 24-hour lookup cache does not guarantee freshness; if the nightly rebuild finishes after the cache is populated, queries return yesterday's vectors until the cache expires. Caching is a latency optimization, not a mechanism for tracking a nightly-refreshed index, so the endpoint could serve stale context.

A `resources.model_serving` block that wraps the serving endpoint under a model-specific resource type.

Why it fails: The bundle resource type for serving endpoints is `serving_endpoints`, not `model_serving`. There is no `model_serving` resource kind in Databricks Asset Bundles, so this declaration would be rejected during bundle validation. The engineer should use the correctly named `serving_endpoints` resource to define the endpoint that hosts the agent.

A `resources.mlflow_experiments` block that registers the agent's chain as an MLflow model.

Why it fails: There is no `resources.mlflow_experiments` resource type in Databricks Asset Bundles. MLflow experiments are created by the training or logging code, not declared as bundle resources. While the agent must be logged as an MLflow model before it can be served, that logging is done by the notebook or job that trains the agent, not by a bundle resource block, so this declaration would not exist.

A `resources.registered_models` block that points to the Unity Catalog model to be served.

Why it fails: While `registered_models` is a valid bundle resource type used to set tags or aliases on a Unity Catalog model, it does not create the serving endpoint or the Vector Search index. The scenario specifically asks for resources that create the index and the endpoint. Declaring a registered model would not create either of those, so it does not satisfy the requirement.

A `permissions` block that assigns CAN_MANAGE to the CI service principal on every bundle resource.

Why it fails: While the CI service principal does need sufficient privileges to deploy, a permissions block is not what declares or registers the model. It governs access to resources after they exist and is optional for deployment. The requirement to register a model version and let an endpoint reference it is satisfied by resource declarations and target configuration, not by permission grants alone.

A `sync` block that uploads the local notebook and Python files to the workspace on each deploy.

Why it fails: File synchronization moves source files into the workspace, which is useful for jobs and notebooks, but it does not register a model version or create a serving endpoint. The scenario requires the model to be registered and the endpoint to reference a specific version, which is a resource-level concern. Synchronization alone leaves the bundle without declared model or endpoint artifacts.

An `artifacts` block that compiles the agent into a wheel for deployment.

Why it fails: Building a wheel packages Python code so jobs or endpoints can install it, but it does not by itself register the model in Unity Catalog or declare a serving endpoint. The scenario's two goals are resource declaration and environment targeting, not code packaging. A wheel is a supporting artifact, not the element that satisfies either stated requirement.

Move the endpoint to a smaller GPU SKU so more replicas fit within the same budget.

Why it fails: A smaller GPU may not hold the model in memory or may drastically increase per-request latency, which compounds the timeout problem. Swapping SKUs does not change how many concurrent requests the endpoint accepts unless provisioned concurrency is also raised. This choice treats a capacity configuration issue as a hardware sizing issue and risks making latency and throughput worse.

Lower the endpoint's query timeout so slow requests fail faster and free capacity.

Why it fails: Shortening the timeout makes requests fail sooner rather than succeed, which worsens user experience during peak load. It does not add capacity, so the endpoint still throttles with 429s once concurrency is exceeded. The goal is to absorb bursts without failing requests, and reducing timeouts moves in the opposite direction by converting slow responses into errors.

Enable payload logging to inference tables so the endpoint can queue requests more efficiently.

Why it fails: Inference tables capture request and response payloads for monitoring and debugging; they do not add request-handling capacity. Enabling logging can even add slight overhead. The 429 errors indicate the endpoint hit its concurrency ceiling, which logging cannot raise. This option confuses an observability feature with a scaling control and leaves the throttling unresolved.

Restart the model serving endpoint with `databricks serving-endpoints update-config` to force the secret to be re-read at startup.

Why it fails: Model Serving does not require an endpoint restart to pick up secret values; secrets are resolved at request time from the referenced scope. A restart would not fix an identity or reference-syntax problem and would only cause brief unavailability without addressing the root cause.

Store the API key as a plaintext environment variable in the bundle's serving endpoint configuration so the endpoint can read it directly.

Why it fails: Embedding plaintext credentials in the bundle violates least-privilege and secret-management practices, and bundle files may be committed to source control. Even if it made the request succeed, it would expose the key and is not an acceptable fix for a production deployment.

Add the secret scope and key names to the bundle's target configuration, then redeploy with `databricks bundle deploy`.

Why it fails: Secret scope and key names are not bundle resources and cannot be declared in target configuration. The scope already exists with the correct name and permissions, so adding names to the bundle would be a no-op. The failure is about the serving endpoint's credential lookup, not bundle metadata.