Access denied redirect
The default workflow, when a user tries to open the restricted file, is to respond with HTTP 401 (Unauthorized). Depending on the browser, it shows an empty screen or "This page isn't working...". It may not be the best user experience if you want to explain to the user the reason they can't access the file.
You can customize the user experience in a few different ways, and it depends on the service you use to restrict access to files (Posts & Terms or URL Access).
Posts & Terms redirect
When you restrict access to media items with the Posts & Terms service, the access denied redirect can be configured with the Access Denied Redirect service. The only step that you need to take is to enable the Use Access Denied Redirect For Restricted Media Items option on the AAM Settings page. This way, if an unauthorized identity tries to access a protected file with a direct URL, the configured access denied rule triggers.
FYI!
It may appear confusing why you need to enable the Use Access Denied Redirect For Restricted Media Items when you manage access to media items with the Posts & Terms service. The main reason for this extra hoop is because the Posts & Terms service primarily manages access to the WordPress posts. Media items are tricky because they consist of two parts - a post (record in DB) and a physical file. You can learn more about it on the Things to know page.
URI Access redirect
The URL Access service is designed to manage access to parts of your website that may not directly tight to the WordPress website. For example, you may choose to upload some stand-alone files directly to the /wp-content/uploads directory. This is where the URI Access service can help you define your access controls.
Note!
The URI access rule has higher precedence than the Posts & Terms settings. If you restrict access to a media item with the Posts & Terms service and restrict the same file with the URI Access service, the second takes effect.