4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Create and configure Azure App Service
Hartwell Publishing runs a content site in an App Service named app-cms (Standard S1) that uses an Azure SQL database named sqldb-cms. Compliance requires a backup of the app content and the database to be taken every day at 02:00 and kept for 90 days in a storage account the company controls, so that a point-in-time copy can be restored to a different app if needed.
What should you configure?
- AEnable custom backups on app-cms with a daily schedule at 02:00, 90-day retention, a container in the company's storage account, and the sqldb-cms connection string included in the backup.Custom backups let you set the schedule, retention and destination storage container, and can include linked databases referenced by connection strings; they can be restored to the same or a different app.
- BRely on the automatic backups that App Service performs hourly, which are retained for 30 days.Automatic backups are app-only, retained for 30 days, stored in platform storage the company does not control, and do not include the database.
- CCreate a deployment slot named backup and swap to it daily at 02:00.Slots are for staging and testing; they do not retain point-in-time copies of content and have nothing to do with database backup.
- DEnable Azure Backup on the App Service plan asp-cms through a Recovery Services vault.Recovery Services vaults protect VMs, SQL in VMs, Azure Files and similar workloads; App Service has its own backup feature and is not a vault workload.
Why: App Service has two backup modes. Automatic backups run hourly on Basic and above, keep 30 days in platform storage, back up app content only and cannot be configured. Custom backups, available from Standard, let you choose the schedule, retention, an Azure Storage container you own and optionally include linked Azure SQL or MySQL databases through connection strings, and they can be restored to a new app. The deciding constraints, daily at a fixed time, 90-day retention, company-owned storage and database inclusion, all require custom backups.
Create and configure Azure App Service
Ashford Mobility runs a web app named app-fleet (Standard S1) with a production slot and a staging slot. The staging slot has an app setting named ApiBaseUrl that points to a staging API, and production has the same setting pointing to the production API. After the last swap, production started calling the staging API, and the team also noticed that a swapped build had not warmed up before taking traffic. The team wants future swaps to keep each slot's ApiBaseUrl with that slot and to let an engineer validate the production configuration on the staging slot before traffic moves.
Which two actions should you perform? Each correct answer presents part of the solution.
- AMark ApiBaseUrl as a Deployment slot setting in both slots.A slot-specific (sticky) setting stays with its slot during a swap instead of moving with the code, so production keeps the production API URL.
- BUse Swap with preview, validate the staging slot, then complete the swap.Swap with preview applies production's settings to the staging slot first, so an engineer can test the app with production configuration and the app warms up before the swap completes.
- CEnable Auto swap on the production slot targeting staging.Auto swap is enabled on the source slot (staging) and swaps automatically after deployment, removing the validation step the team wants.
- DMove ApiBaseUrl into a connection string instead of an app setting.Connection strings swap with the code just like app settings unless they are also marked as slot settings; the type does not make a value sticky.
- EScale the plan to Premium v3 so that settings are isolated per slot.Tier affects slot count and compute, not whether settings swap. Slot-specific settings are available at Standard.
Why: By default, app settings and connection strings swap along with the content, which is why production picked up the staging API URL. Marking a setting as a Deployment slot setting pins it to the slot. Swap with preview is a two-phase swap: phase one applies the target slot's configuration (including its sticky settings) to the source slot and restarts it, so you can validate and warm up; phase two completes or cancels the swap. Auto swap removes the manual gate, and neither the setting type nor the tier changes stickiness. Remember the list of items that never swap, such as custom domains, TLS bindings, scale settings and IP restrictions.
Create and configure Azure App Service
Elmcroft Health has a web app named app-intake (Premium v3) in the East US region. The app must read from an Azure SQL database that accepts connections only from the subnet snet-data in the virtual network vnet-clinic. Separately, the app itself must be reachable only from clients inside vnet-clinic, with its public endpoint disabled. The networking team wants to use the native App Service networking features.
Which two features should you configure, and for which direction?
- AVirtual network integration for outbound traffic to the database, and a private endpoint on app-intake for inbound traffic from clients.Virtual network integration routes the app's outbound calls through a subnet in vnet-clinic so the database sees a VNet source. A private endpoint gives the app a private IP in the VNet for inbound access, and public access can then be disabled.
- BA private endpoint on app-intake for outbound traffic to the database, and virtual network integration for inbound client traffic.This reverses the directions. Private endpoints are inbound-only, and virtual network integration affects only outbound traffic from the app.
- CHybrid Connections for the database, and access restrictions that allow the Azure Front Door service tag.Hybrid Connections are for reaching on-premises TCP endpoints via a relay, and a Front Door service tag would still leave the app publicly reachable through Front Door.
- DVirtual network integration for both inbound and outbound traffic, with Route All enabled.Virtual network integration never provides inbound private access; Route All only forces all outbound traffic through the VNet.
Why: App Service networking features are strictly directional and the exam tests whether you can pair each with its direction. Outbound: virtual network integration (regional VNet integration) places the app's outbound traffic in a delegated subnet, with Route All controlling whether internet-bound traffic also goes through the VNet. Inbound: private endpoints give the app a private IP address, and access restrictions filter the public endpoint by IP or service endpoint. Hybrid Connections are a separate outbound relay to on-premises resources. The database's subnet rule and the private-only client access map to VNet integration and a private endpoint respectively.
Create and configure Azure App Service
Quarry Hill Outfitters owns the domain quarryhill.example, hosted in a third-party DNS provider. The company has a web app named app-shop in an App Service plan at the Standard tier, reachable at app-shop.azurewebsites.net. You must make the app answer at shop.quarryhill.example, and the portal shows a custom domain verification ID for the app.
Which two DNS records should you create at the DNS provider? Each correct answer presents part of the solution.
- AA CNAME record for shop that points to app-shop.azurewebsites.net.A CNAME maps the subdomain to the app's default hostname so traffic reaches the App Service front end.
- BA TXT record for asuid.shop that contains the custom domain verification ID.App Service verifies ownership of the hostname by reading the verification ID from the asuid TXT record before it accepts the custom domain.
- CAn A record for shop that points to the app's outbound IP address.An A record is used for apex domains and must point to the app's inbound IP address, not an outbound one; for a subdomain the CNAME is the standard choice.
- DAn MX record for shop that points to app-shop.azurewebsites.net.MX records direct email delivery and play no role in web hostname mapping.
- EAn NS record that delegates quarryhill.example to Azure DNS.Delegating the zone to Azure DNS is optional and does not by itself map the hostname or prove ownership.
Why: Mapping a custom hostname to App Service has two parts. Routing is handled by a CNAME for a subdomain (or an A record to the app's inbound IP for an apex domain). Ownership is proved by a TXT record named asuid.<subdomain> whose value is the app's custom domain verification ID, which App Service checks when you add the hostname. Both records are required; the CNAME alone fails verification and the TXT alone sends no traffic. After the hostname is added, a TLS binding is a separate step.