Task 3.2: Develop and implement Azure Functions

• AConsumption

  Incorrect

  The legacy Consumption plan doesn't support virtual networks, and Linux Consumption is retiring.

• BPremium

  Incorrect

  A Premium plan always has at least one active, billed instance, so it never scales to zero.

• CFlex Consumption

  Correct

  Flex Consumption is Linux-based, scales to zero, bills per execution, and adds virtual network integration and fast scale-out.

• DDedicated (App Service plan)

  Incorrect

  Dedicated plans run on instances you pay for continuously, with no scale to zero.

Flex Consumption is the recommended serverless plan: scale to zero, execution-based billing, optional always ready instances, virtual network integration and up to 1,000 instances. Premium and Dedicated keep instances running.

• ACreate a staging slot on the Flex Consumption app and keep swapping

  Incorrect

  Deployment slots aren't currently supported on Flex Consumption.

• BMigrate the existing app in place to Flex Consumption so its slots carry over

  Incorrect

  In-place migration to Flex Consumption isn't supported; you create a new app and redeploy.

• CSet WEBSITE_RUN_FROM_PACKAGE to a package URL to switch versions atomically

  Incorrect

  Flex Consumption deploys from a package in a blob container and no longer uses app settings to drive deployment behavior.

• DUse the rolling updates site update strategy instead of slots

  Correct

  Flex Consumption applies code and configuration changes gradually across instances through rolling updates (currently in preview).

Flex Consumption deploys a zipped package to a blob storage container and has no deployment slots. Its zero-downtime option is the rolling update site update strategy, which other plans replace with slots.

• ACreate a folder per function with its own function.json file

  Incorrect

  function.json folders belong to the v1 programming model, not the decorator-based v2 model.

• BDefine them on func.Blueprint objects and register each with app.register_functions

  Correct

  Blueprints let you define functions in other files and register them with the main FunctionApp object.

• CCreate a separate FunctionApp object in each module and import those modules into function_app.py

  Incorrect

  A function app uses one FunctionApp object in function_app.py; the documented way to add modules is blueprints.

• DPut the modules in a shared folder and list them in host.json

  Incorrect

  host.json holds global settings for the app; it doesn't register functions.

In the v2 model, functions are decorated methods on the FunctionApp in function_app.py. Larger apps define functions on Blueprint objects in other files and call app.register_functions for each one.

• ASbConn set to <namespace>.servicebus.windows.net

  Incorrect

  A bare value under the connection name is read as a connection string, not as an identity-based connection.

• BSbConn__serviceUri set to https://<namespace>.servicebus.windows.net

  Incorrect

  serviceUri is the property used for services such as SignalR, not for Service Bus.

• CAzureWebJobsServiceBus set to the namespace's primary key

  Incorrect

  That's a key-based setting, which the managed identity requirement rules out.

• DSbConn__fullyQualifiedNamespace set to <namespace>.servicebus.windows.net

  Correct

  Identity-based Service Bus connections use the __fullyQualifiedNamespace suffix on the connection name.

Each identity-based connection is a group of settings that share the connection name as a prefix. For Service Bus the required one is <CONNECTION_NAME_PREFIX>__fullyQualifiedNamespace; the identity also needs a Service Bus data role.

• AKeep the default LogsAndContainerScan source

  Incorrect

  The default polling source isn't supported for blob triggers on Flex Consumption.

• BAdd a timer trigger that lists new blobs every minute

  Incorrect

  Polling with a timer isn't a blob trigger and adds latency and cost.

• CSet source to EventGrid on the blob_trigger decorator

  Correct

  On Flex Consumption the Blob Storage trigger supports only the Event Grid source.

• DCreate an Event Grid event subscription on the storage account that delivers to the function's blob extension endpoint

  Correct

  The Event Grid source relies on an event subscription to the container instead of polling it.

• ESet WEBSITE_RUN_FROM_PACKAGE to 1

  Incorrect

  That's a deployment setting, and Flex Consumption doesn't use app settings to control deployment.

The Event Grid-based blob trigger reacts to an event subscription on the container, which lowers latency compared with polling. In Flex Consumption it's the only supported source, so set source="EventGrid" and create the subscription.

• AIn an Authorization header as a bearer token

  Incorrect

  A function key isn't a bearer token; the runtime reads it from the code parameter or the x-functions-key header.

• BIn the code query string parameter or in the x-functions-key request header

  Correct

  Non-anonymous HTTP functions require an access key in either of these places.

• CIn the request body under a key property

  Incorrect

  The runtime doesn't look for access keys in the request body.

• DAs the master key in the x-functions-key header for every call

  Incorrect

  The master key is for the runtime admin APIs; a function key or host key is enough for a function-level endpoint.

With a function or admin authorization level, callers include an access key: ?code=<key> in the URL or the x-functions-key header. The value can be a function key for that function or a host key.

• A*/5 * * * * *

  Incorrect

  In the six-field format the first field is seconds, so this fires every five seconds.

• B0 0 */5 * * *

  Incorrect

  The third field is hours, so this runs every five hours.

• C5 * * * * *

  Incorrect

  This fires at second 5 of every minute, which is once a minute.

• D0 */5 * * * *

  Correct

  NCRONTAB adds a seconds field at the start; this fires at second 0 of every fifth minute.

Functions uses NCRONTAB expressions, {second} {minute} {hour} {day} {month} {day-of-week}, evaluated in UTC by default.

• A512 MB

  Incorrect

  512 MB suits specific low-concurrency needs; it isn't the general default.

• B4,096 MB

  Incorrect

  4,096 MB is for higher concurrency or heavier CPU and memory work.

• C1,536 MB, the fixed size of every Flex Consumption instance

  Incorrect

  Flex Consumption offers selectable sizes of 512, 2,048 and 4,096 MB.

• D2,048 MB

  Correct

  Microsoft suggests 2,048 MB as the default for most scenarios.

Flex Consumption lets you choose the instance memory size, and CPU and network bandwidth scale with it. You can change the size at any time, and the default HTTP concurrency depends on it.

• Ahost.json overrides local.settings.json in Azure

  Incorrect

  host.json holds runtime configuration; it doesn't replace app settings.

• Blocal.settings.json isn't published; add the setting to the app in Azure

  Correct

  The file holds local-only settings and secrets and is never deployed with the app.

• CThe .funcignore file always excludes requirements.txt, which breaks the setting

  Incorrect

  requirements.txt lists dependencies; it has nothing to do with app settings.

• DSettings with a double underscore are only read on Windows

  Incorrect

  The double underscore separates the parts of identity-based connection settings on every platform.

Locally, Core Tools reads app settings from local.settings.json. In Azure, the same names must be set as application settings on the function app, for example through the portal, the CLI or deployment templates.

• AThe identity can't read queue runtime properties, so scaling uses peek estimates

  Correct

  Accurate counts come from the administration API, which needs the Data Owner role or a custom role with namespace read rights.

• BThe Data Receiver role can't complete messages, so they're redelivered

  Incorrect

  Data Receiver allows receiving and settling; the messages are being processed.

• CIdentity-based connections turn off target-based scaling for Service Bus triggers

  Incorrect

  Identity-based connections work with scaling; the missing piece is a permission.

• DService Bus triggers scale only on CPU, not on queue length

  Incorrect

  The Service Bus extension scales on message counts.

The Service Bus extension reads queue or subscription runtime properties to make scale decisions. Without Manage rights or Azure Service Bus Data Owner, it silently uses less accurate peek-based estimates, which can delay scaling.