Design an application architecture

Fenwick Learning deploys a web app to Azure App Service on a Standard plan from a GitHub repository. Each release must be deployed first to a non-production copy that has the same configuration as production, warmed up, and verified with smoke tests. Promotion to production must happen with no downtime and must be reversible within seconds if an error is found.

Which deployment approach should you recommend?

1. ADeploy directly to the production web app using a GitHub Actions workflow and roll back by redeploying the previous commitDirect deployment restarts the production app during deployment and makes rollback a full redeploy that takes minutes.
2. BDeploy to a staging deployment slot using GitHub Actions, run smoke tests, and swap the slot into productionDeployment slots give a warmed-up, identically configured instance; a swap redirects traffic without downtime and swapping back restores the previous version in seconds.
3. CCreate a second App Service plan for staging and switch traffic with Azure Traffic ManagerA second plan doubles cost and DNS-based switching is subject to TTL delays, so cutover and rollback are neither instant nor seamless.
4. DDeploy to a Virtual Machine Scale Set with a rolling upgrade policyMoving the app to VMs adds OS management and does not use the slot swap feature that App Service already provides for this exact need.

Ambergate Clinics hosts a patient-portal API on Azure App Service. The API needs a storage connection string and a third-party API key. Security policy states that secrets must live only in Azure Key Vault, must never appear in source control or pipeline variables, and the app must retrieve them without any credential stored in its configuration. The developers want to keep reading the values through ordinary environment variables.

Which two actions should you recommend? Each correct answer presents part of the solution.

1. AEnable a system-assigned managed identity on the web app and grant it the Key Vault Secrets User role on the vaultA managed identity gives the app an identity with no stored credential, and the Secrets User role is the least-privilege RBAC role that allows reading secret values.
2. BCreate app settings that use Key Vault reference syntax pointing to the secrets in the vaultKey Vault references in App Service app settings resolve the secret at runtime and expose it to the code as a normal environment variable.
3. CStore the secrets as encrypted variables in the GitHub Actions workflow and inject them at deploymentThis copies secrets into pipeline variables and then into app settings, which violates the policy that secrets live only in Key Vault.
4. DRegister an application in Microsoft Entra ID, create a client secret, and store it in appsettings.json for the Key Vault SDKA client secret in configuration is itself a stored credential and would be committed to source control, which the policy forbids.
5. EEnable Azure App Configuration and import the secrets as plain key-valuesImporting secret values into App Configuration copies them out of Key Vault; App Configuration should hold references, not the secret values themselves.

Sablewood Analytics deploys an application environment of about 60 resources across three resource groups from a single Bicep file using Azure Pipelines. The platform team requires that when a resource definition is removed from the Bicep file the corresponding Azure resource is deleted on the next deployment, that the deployed resources cannot be deleted through the portal by developers, and that the whole environment can be removed as a unit when a project ends.

Which deployment approach should you recommend?

1. ADeploy the Bicep file in Complete mode at the resource group scopeComplete mode deletes unmanaged resources only within a single resource group deployment, does not span three resource groups from one subscription-scope deployment, and provides no protection against portal deletion.
2. BDeploy the Bicep file as an Azure deployment stack at the subscription scope with action-on-unmanage set to delete and a deny-delete settingDeployment stacks track all resources a template creates across resource groups, delete resources that are removed from the template, apply deny settings that block deletion outside the stack, and can delete the whole set when the stack is removed.
3. CDeploy the Bicep file in Incremental mode and apply a CanNotDelete lock to each resource groupIncremental mode never removes resources that are dropped from the template, and locks also block the pipeline itself from deleting resources.
4. DPublish the Bicep file as a template spec and deploy it with Azure Policy deployIfNotExistsTemplate specs version templates and Policy can remediate missing resources, but neither tracks managed resources for deletion or prevents portal deletion.

Glasswing Robotics manages its Azure infrastructure as Bicep files in GitHub. A GitHub Actions workflow must deploy the Bicep templates to a subscription on every merge to main. The security team requires that no long-lived client secret or certificate for the deployment identity is stored in GitHub, and that the identity be limited to the Contributor role on one resource group.

Which authentication approach should you recommend for the workflow?

1. AA Microsoft Entra service principal with a client secret stored as a GitHub encrypted secretA client secret is a long-lived credential stored in GitHub, which the security team explicitly forbids, and it must be rotated manually.
2. BA user-assigned managed identity with a federated credential for the GitHub repository and branch, assigned Contributor on the resource groupWorkload identity federation lets GitHub-hosted runners exchange their OIDC token for an Entra token with no stored secret, and the managed identity can be scoped to Contributor on exactly one resource group.
3. CA personal access token for an administrator account stored as a GitHub encrypted secretA personal token is a long-lived credential tied to a human account and typically carries far more than resource-group Contributor rights.
4. DA system-assigned managed identity on a GitHub-hosted runnerGitHub-hosted runners are not Azure resources and cannot have an Azure managed identity; only self-hosted runners on Azure VMs could.