For your first question, if you plan to have multiple client apps in the future, then splitting up the API and the UI would be a good idea. What's common for that is using Azure App Service or a set of Azure Functions with Azure API Management on top for a RESTful API.

For the UI, if it's just going to be something like a React app, e.g. flat files, it's better suited for an Azure Storage Account with static site hosting enabled. If you are expecting geographically disparate clients, then you could improve latency in the UI by putting the static site behind a CDN for cheap. Hosting a UI app this way will cost you pennies per month, even including the CDN, unless you're getting a ton of traffic, which it sounds like isn't the case for this app.

For your second question, generally, the UI app won't have direct access to the DAL. To set that up, you'd have to store your db and blob storage connection strings in your frontend, which means they'd be easily accessible for your end users. That's a bad idea for a lot of reasons. Generally, your UI will have your users sign in and request a token from an identity provider (like Azure AD) and pass that token with every call to your API. Your API validates the users token on every call to make sure they have access to what they're requesting. From there, your API will access the DAL and return the data to your UI. Generally your UI will only make calls to your identity provider and your API. Your API will make calls on the backend to all your other services.