This chapter covers Azure Content Delivery Network (CDN) profiles and their Rules Engine—a powerful feature for customizing content delivery behavior. Understanding CDN and Rules Engine is critical for the AZ-104 exam, as it tests your ability to optimize global content performance and reduce latency. Approximately 10-15% of networking questions relate to CDN, caching, and traffic optimization. You will learn how to create CDN profiles, configure endpoints, and use the Rules Engine to control caching, compression, and URL redirects. This chapter provides the deep technical knowledge needed to answer exam questions and deploy CDN in real-world scenarios.
Jump to a section
Imagine your company has a single warehouse in Seattle that stores all product catalogs. Customers worldwide request catalogs, but those in Europe wait 200ms for delivery. To fix this, you lease small satellite warehouses in London, Frankfurt, and Singapore. Each satellite warehouse (CDN edge node) stores copies of the most popular catalogs (cached content). When a customer in Berlin requests a catalog, the request is intercepted and routed to the nearest satellite warehouse (London) instead of Seattle. The satellite warehouse checks its inventory (cache). If the catalog is there (cache hit), it ships immediately. If not (cache miss), it requests one copy from Seattle (origin), stores a copy for future requests, and then ships to the customer. The satellite warehouse also follows rules: it only keeps catalogs for 24 hours (TTL), and certain catalogs are always fetched fresh (rules engine bypass). This reduces delivery time from 200ms to 20ms for European customers. The key is that the satellite warehouse doesn't create new catalogs—it only caches what Seattle sends. To ensure freshness, the satellite warehouse can ask Seattle, 'Has this catalog changed?' using a conditional request (If-Modified-Since). If unchanged, Seattle replies '304 Not Modified' and the satellite delivers its cached copy. This analogy maps directly to Azure CDN: the origin is your web server, edge nodes are global POPs, cache rules are configured via the Rules Engine, and the conditional request mechanism is the HTTP cache-control and ETag headers.
What is Azure CDN and Why Does It Exist?
Azure Content Delivery Network (CDN) is a globally distributed network of proxy servers (edge nodes) that cache content from your origin servers (e.g., Azure Web App, Azure Storage, or any public web server). Its primary purpose is to reduce latency for end users by serving content from a location geographically closer to them. Without CDN, every request from a user in Tokyo would have to travel to your origin server in Virginia, incurring high latency (200-300ms). With CDN, the request is routed to the nearest edge node—perhaps in Tokyo or Osaka—which can serve cached content in under 10ms.
Azure CDN is not a single product; it offers multiple tiers: Azure CDN Standard from Microsoft, Azure CDN Standard from Akamai, and Azure CDN Premium from Verizon. The AZ-104 exam focuses primarily on the Microsoft and Akamai tiers, with some questions on Verizon. The key difference is that the Premium tier (Verizon) provides a more advanced Rules Engine with additional features like device filtering and token authentication, while Standard tiers have a simpler rules engine. For the exam, you must know the capabilities of each tier and when to use which.
How CDN Works Internally
When a user requests a resource (e.g., https://<your-cdn-endpoint>.azureedge.net/images/logo.png), the following steps occur:
DNS Resolution: The user's device resolves the CDN endpoint hostname (e.g., your-cdn-endpoint.azureedge.net) to the IP address of the nearest edge node (Point of Presence, or POP). Azure CDN uses DNS-based routing to direct users to the optimal POP based on network latency and geographic proximity.
Edge Node Request Handling: The edge node receives the HTTP request. It checks its local cache for the requested resource. The cache is indexed by the full URL (including query strings by default, but this can be controlled).
Cache Hit: If the resource is in cache and has not expired (based on Cache-Control or Expires headers from the origin, or the default TTL), the edge node returns the cached content directly to the user. This is the ideal scenario.
Cache Miss: If the resource is not cached or has expired, the edge node forwards the request to the origin server. The origin responds with the resource and HTTP headers. The edge node caches the resource (respecting cache directives) and then serves it to the user.
Conditional Requests: To optimize bandwidth, the edge node can send conditional requests (If-Modified-Since or If-None-Match) to the origin. If the origin responds with 304 Not Modified, the edge node uses its cached copy. This reduces origin load and bandwidth.
Key Components, Values, Defaults, and Timers
CDN Profile: A container for one or more CDN endpoints. Each profile is associated with a pricing tier (Standard Microsoft, Standard Akamai, Standard Verizon, Premium Verizon). You can have multiple profiles per subscription.
CDN Endpoint: A specific hostname (e.g., myendpoint.azureedge.net) that serves content. Each endpoint points to an origin (origin hostname, origin path, and origin port). You can have multiple endpoints per profile, and each endpoint can have multiple custom domains.
Origin: The source server that hosts the original content. Can be an Azure Web App, Azure Storage (blob or static website), Azure Cloud Service, or any publicly accessible HTTP/HTTPS server.
- Caching Rules: - Default TTL: If the origin does not provide Cache-Control or Expires headers, the default TTL is 7 days for Microsoft CDN, 7 days for Akamai, and 7 days for Verizon. However, for dynamic content (e.g., files with specific extensions), the default may differ. - Cache Behavior Settings: You can set caching rules per endpoint: Ignore query strings (cache one version regardless of query string), Bypass caching (never cache), or Override (set custom TTL). - Rules Engine: Allows fine-grained control based on conditions like URL path, file extension, request header, etc. Actions include cache expiration, compression, redirect, and response header modification.
Compression: Azure CDN supports gzip and brotli compression. By default, compression is enabled on Microsoft CDN for certain MIME types (text/plain, text/html, text/css, application/javascript, etc.). The minimum file size for compression is 1 KB.
Geo-filtering: Allows you to allow or block traffic from specific countries. This is configured at the CDN endpoint level.
Custom Domains: You can add a custom domain (e.g., cdn.contoso.com) to a CDN endpoint. You must verify domain ownership via a CNAME record pointing to the CDN endpoint hostname. For HTTPS, you need to enable custom domain HTTPS, which requires a certificate. Azure CDN provides managed certificates (free) or you can bring your own.
HTTPS: Azure CDN supports HTTPS for both the CDN endpoint and custom domains. For custom domains, you must enable HTTPS explicitly. Microsoft CDN uses DigiCert as the CA for managed certificates.
Configuration and Verification Commands
To create a CDN profile and endpoint via Azure CLI:
# Create a resource group
az group create --name MyCDNResourceGroup --location eastus
# Create a CDN profile (Standard Microsoft tier)
az cdn profile create \
--name MyCDNProfile \
--resource-group MyCDNResourceGroup \
--sku Standard_Microsoft
# Create a CDN endpoint
az cdn endpoint create \
--name MyCDNEndpoint \
--profile-name MyCDNProfile \
--resource-group MyCDNResourceGroup \
--origin www.contoso.com \
--origin-host-header www.contoso.comTo verify CDN endpoint and test caching:
# List endpoints
az cdn endpoint list --profile-name MyCDNProfile --resource-group MyCDNResourceGroup
# Purge cache (force re-fetch)
az cdn endpoint purge \
--content-paths '/images/*' \
--name MyCDNEndpoint \
--profile-name MyCDNProfile \
--resource-group MyCDNResourceGroup
# Test with curl
curl -I https://myendpoint.azureedge.net/images/logo.png
# Look for X-Cache header: HIT, MISS, or TCP_HITHow CDN Interacts with Related Technologies
Azure Front Door: A modern alternative that provides both CDN and application delivery (load balancing, WAF, SSL offload). Front Door is a layer 7 load balancer with global routing, while CDN is primarily a caching layer. For the exam, know that Front Door includes CDN capabilities but is more feature-rich.
Azure Traffic Manager: A DNS-based traffic routing service (layer 4). It can route users to different regional endpoints, but it does not cache content. CDN is often used together with Traffic Manager for global load balancing and caching.
Azure Web Application Firewall (WAF): Can be integrated with CDN (Verizon Premium) or Front Door to protect against common web vulnerabilities. Standard Microsoft CDN does not support WAF natively.
Azure Storage: When using Azure Storage as an origin, you must enable the storage account's "Static website" feature or use blob storage directly. CDN can cache blobs and static website content.
The Rules Engine in Detail
The Rules Engine is a feature available in Azure CDN Standard from Microsoft (limited) and Premium from Verizon (full). It allows you to define conditions and actions to customize how requests are handled at the edge.
Conditions:
Request URL path (e.g., /images/*)
URL file extension (e.g., .jpg, .css)
Request header (e.g., User-Agent, Referer)
Country code (geo-filtering)
Device type (Premium only)
HTTP method (GET, POST, etc.)
Actions:
Cache expiration: Override TTL for specific paths.
Cache key query string: Include/exclude query strings in cache key.
Modify response header: Add, remove, or overwrite headers.
URL redirect: 301/302 redirect to another URL.
URL rewrite: Change the request path before reaching origin (Premium only).
Compression: Enable/disable compression for specific file types.
Origin override: Change the origin for specific requests (Premium only).
How Rules Engine Works:
Rules are evaluated in order (top to bottom) until a match is found.
Each rule can have multiple conditions (AND logic) and multiple actions.
If no rule matches, the default behavior applies.
Example Rule: Redirect all requests for /old-blog/* to https://newblog.contoso.com/
{
"rules": [
{
"name": "Redirect old blog",
"conditions": [
{
"name": "UrlPath",
"parameters": {
"operator": "BeginsWith",
"matchValues": ["/old-blog/"]
}
}
],
"actions": [
{
"name": "UrlRedirect",
"parameters": {
"redirectType": "Found (302)",
"destinationProtocol": "https",
"destinationPath": "/",
"destinationHostname": "newblog.contoso.com"
}
}
]
}
]
}Caching Behavior and Headers
Cache-Control: The origin can set Cache-Control: public, max-age=3600 to allow CDN to cache for 1 hour.
Expires: Older header; if both exist, Cache-Control takes precedence.
Pragma: no-cache is honored if Cache-Control is absent.
Set-Cookie: Responses with Set-Cookie are not cached by default (to avoid serving personalized content to other users).
Vary: If origin sends Vary: User-Agent, CDN will cache separate copies per User-Agent. This can reduce cache hit ratio.
Performance and Scale Considerations
Cache Hit Ratio: Target >90% for static content. Low hit ratio indicates misconfigured caching rules or dynamic content being cached.
Purge and Preload: Use purge to invalidate cache immediately (up to 50 paths per request). Preload (Verizon Premium) allows warming cache for expected high traffic.
Origin Shield: A feature in Premium CDN that adds an intermediate caching layer to reduce load on origin.
Bandwidth: CDN egress costs are billed per GB. Azure CDN Standard Microsoft includes a free tier of 5 GB per month.
Common Misconfigurations and Troubleshooting
404 from CDN but not from origin: Check origin host header. The CDN must send the correct host header to the origin.
Stale content: Cache TTL too long. Use purge or reduce TTL.
HTTPS issues: Custom domain HTTPS must be enabled. Certificate provisioning can take up to 6 hours.
CORS headers: If your CDN serves cross-origin requests, ensure the origin sends Access-Control-Allow-Origin header. You can also add it via Rules Engine.
Create a CDN Profile
Navigate to the Azure portal, search for 'CDN profiles', and click 'Create'. Select the subscription, resource group, and a unique profile name. Choose the pricing tier: Standard Microsoft (most common for exam), Standard Akamai, or Standard/Premium Verizon. The tier determines available features (e.g., Rules Engine complexity). Click 'Review + create' and then 'Create'. This step creates the container for endpoints. Note that the profile tier cannot be changed later; you must delete and recreate.
Create a CDN Endpoint
Within the CDN profile, click '+ Endpoint'. Provide a name (e.g., 'myendpoint') which becomes part of the endpoint hostname (myendpoint.azureedge.net). Select the origin type: Web App, Storage, Cloud Service, or Custom Origin. Enter the origin hostname (e.g., myapp.azurewebsites.net) and optionally an origin path and port. Set the origin host header (usually the same as origin hostname). Configure caching rules: ignore query strings, bypass caching, or override default TTL. Click 'Add'. The endpoint is created and DNS propagation begins; it may take up to 90 minutes to be fully available.
Configure Custom Domain and HTTPS
To use a custom domain (e.g., cdn.contoso.com), add it to the endpoint. First, create a CNAME record in your DNS zone pointing cdn.contoso.com to myendpoint.azureedge.net. In the Azure portal, go to the endpoint, select 'Custom domains', click '+ Add', enter the custom domain name, and verify ownership. After adding, enable HTTPS: choose 'CDN managed' (free certificate from DigiCert) or 'Use your own certificate'. Enabling HTTPS triggers certificate provisioning, which can take up to 6 hours. During this time, the custom domain may not serve HTTPS traffic.
Configure Caching Rules
In the endpoint settings, go to 'Caching rules'. You can set global caching behavior: 'Ignore query strings' (default) treats all URLs as unique if query strings differ; 'Bypass caching' disables caching for the entire endpoint; 'Override' lets you set a custom TTL (e.g., 3600 seconds). For more granular control, use the Rules Engine. In the Rules Engine, add rules with conditions (e.g., URL path starts with /api/) and actions (e.g., set cache expiration to 0 seconds to bypass cache). Rules are evaluated in order; the first matching rule applies.
Test and Monitor CDN
After configuration, test the CDN endpoint by accessing a resource (e.g., https://myendpoint.azureedge.net/images/logo.png). Use curl with -I to check response headers: look for X-Cache: HIT (cached), MISS (not cached), or TCP_HIT (Verizon). Monitor CDN metrics in Azure Monitor: bandwidth, cache hit ratio, request count, and error rates. Set up alerts for low cache hit ratio (<80%) or high error rates. If content is stale, purge the cache using Azure CLI or portal. Purge removes specific paths (e.g., /images/*) from all edge nodes.
Enterprise Scenario 1: Global E-commerce Platform
A large e-commerce company hosts its product images and static assets (CSS, JS) on Azure Blob Storage. Their web application runs on Azure App Service in West US. Users in Europe and Asia experience slow load times (3-5 seconds). They deploy Azure CDN Standard Microsoft with a profile named 'ecommerce-cdn'. They create an endpoint pointing to the storage account's static website URL. They configure caching rules to ignore query strings (since product image URLs are immutable) and set a default TTL of 7 days. For dynamic product pages (e.g., /product/123), they use the Rules Engine to bypass caching entirely, as these pages are personalized. After deployment, load times drop to under 200ms globally. The cache hit ratio stabilizes at 95%. However, during a flash sale, traffic spikes cause origin load to increase. They preload popular images using the 'Preload' feature (Verizon Premium) to warm the cache. They also enable compression for text files, reducing bandwidth by 40%.
Enterprise Scenario 2: Media Streaming Service
A media company streams video on demand (VOD) using Azure CDN. They use Azure CDN Premium from Verizon for advanced features like token authentication to prevent hotlinking. They configure a rule that requires a valid token in the query string for all video files (*.mp4). Without the token, the CDN returns a 403. They also use device filtering to serve different video resolutions based on User-Agent (e.g., mobile gets 480p, desktop gets 1080p). The Rules Engine handles this: condition on User-Agent, action to rewrite the URL to point to a different folder (e.g., /videos/480p/ vs /videos/1080p/). They set cache TTL for video files to 1 hour because content updates frequently. During a major event, they purge old content and preload new videos. A misconfiguration in the token validation rule causes legitimate users to receive 403 errors; they quickly disable the rule, fix the token logic, and re-enable.
Enterprise Scenario 3: SaaS Application
A SaaS provider delivers a JavaScript-based single-page application (SPA) globally. The SPA is hosted on Azure Storage static website. They use Azure CDN Standard Microsoft with custom domain 'app.contoso.com'. They enable HTTPS with a CDN-managed certificate. The SPA makes API calls to a separate API server (api.contoso.com). They configure the CDN to proxy API calls? No—CDN is for static content. Instead, they use Azure Front Door for the API with WAF. For the static SPA, they set cache TTL to 1 year because the SPA is versioned (e.g., app.contoso.com/1.0.0/index.html). They use URL redirect rules to redirect root to the latest version. They also add CORS headers via Rules Engine to allow cross-origin requests from the API domain. A common mistake is caching the SPA's index.html without versioning, causing users to get stale JavaScript after a new release. They avoid this by using versioned URLs and purging only the old version.
What AZ-104 Tests on CDN and Rules Engine
AZ-104 objective 4.2 (Configure CDN endpoints) expects you to:
Create and configure CDN profiles and endpoints (Azure CLI, portal, PowerShell)
Configure caching rules and customize cache behavior
Implement custom domains and HTTPS
Use the Rules Engine to control content delivery (conditions and actions)
Understand differences between CDN tiers (Microsoft, Akamai, Verizon)
Integrate CDN with Azure Storage, Web Apps, and other origins
Common Wrong Answers and Why Candidates Choose Them
Wrong: 'You must use Azure Front Door for CDN' – Many candidates think Front Door is the only CDN solution. Reality: Azure CDN is a separate service. Front Door includes CDN capabilities but is more expensive and feature-rich. The exam tests both.
Wrong: 'The default TTL is 24 hours' – The default TTL for Microsoft CDN is 7 days (7 days for all tiers). Candidates often guess 24 hours because it seems reasonable. Remember: 7 days.
Wrong: 'You can change the CDN tier after creation' – You cannot change the SKU (tier) of a CDN profile. You must delete and recreate. This appears in 'design' questions.
Wrong: 'Rules Engine is available in all CDN tiers' – The full Rules Engine (with URL rewrite, device filtering) is only in Verizon Premium. Standard Microsoft has a limited Rules Engine. Akamai has no Rules Engine (only global caching rules).
Specific Numbers and Terms on the Exam
Default TTL: 7 days (for all tiers when no cache-control headers)
Minimum file size for compression: 1 KB
Maximum purge paths per request: 50
Custom domain HTTPS provisioning time: Up to 6 hours
CNAME requirement: Custom domain requires a CNAME record to the CDN endpoint hostname
Cache behavior options: Ignore query strings, Bypass caching, Override
Rules Engine conditions: UrlPath, UrlFileExtension, RequestHeader, CountryCode, DeviceType (Premium only)
Rules Engine actions: CacheExpiration, CacheKeyQueryString, ModifyResponseHeader, UrlRedirect, UrlRewrite (Premium only)
Edge Cases and Exceptions
Query string caching: By default, CDN treats URLs with different query strings as separate cache entries. To improve cache hit ratio, you can set 'Ignore query strings' to cache all variations as one.
Dynamic content: Files with certain extensions (e.g., .ashx, .aspx) are considered dynamic and are not cached by default. You must override via Rules Engine.
Origin host header: Must match the origin's expected host header. If your origin is a Web App, the host header should be the Web App's hostname (e.g., myapp.azurewebsites.net). If you use a custom domain on the CDN, the host header should still be the origin's hostname, not the custom domain.
HTTPS for custom domains: You cannot use your own certificate if the CDN endpoint is Standard Microsoft; only CDN-managed certificates are supported. For Verizon, you can bring your own.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When you see a question about caching behavior, think: 'What does the origin send?' If the origin sends Cache-Control: no-cache, the CDN will NOT cache. If no headers, default TTL applies. For Rules Engine questions, remember that conditions are evaluated in order; if multiple rules match, only the first applies. For tier questions, associate features: Premium = advanced Rules Engine, Standard = basic. Always verify the tier in the question stem.
Azure CDN profiles are containers for endpoints; you cannot change the SKU after creation.
Default TTL is 7 days when origin sends no cache-control headers.
Rules Engine conditions are evaluated in order; first match wins.
Custom domain HTTPS must be enabled manually; provisioning can take up to 6 hours.
Cache purge invalidates content immediately; you can purge up to 50 paths per request.
Azure CDN Standard Microsoft has a limited Rules Engine; Premium Verizon has the full engine.
Compression is enabled by default for common text MIME types; minimum file size is 1 KB.
These come up on the exam all the time. Here's how to tell them apart.
Azure CDN Standard Microsoft
Simpler service focused on caching static content
Limited Rules Engine (no URL rewrite, no device filtering)
No built-in WAF (must use separate WAF with Premium)
Supports custom domains with CDN-managed certificates only
Lower cost per GB egress compared to Front Door
Azure Front Door
Full application delivery platform (load balancing, SSL offload, WAF)
Advanced routing: path-based, latency-based, priority-based
Built-in WAF with managed rule sets (OWASP, Microsoft)
Supports custom domains with both managed and BYO certificates
Higher cost but includes global load balancing and acceleration
Azure CDN Standard Microsoft
Limited Rules Engine (basic conditions and actions)
No URL rewrite, no device filtering, no token authentication
CDN-managed certificates only for HTTPS
Cache purge via portal/CLI (up to 50 paths per request)
No origin shield feature
Azure CDN Premium Verizon
Full Rules Engine with URL rewrite, device filtering, token auth
Advanced features: origin shield, preload, granular reporting
Supports custom domain HTTPS with BYO certificates
Cache purge with more options (wildcard, regex)
Higher cost but more control and performance tuning
Mistake
Azure CDN caches all content by default, including dynamic pages.
Correct
Azure CDN only caches content that is cacheable based on HTTP headers (Cache-Control, Expires). Dynamic content (e.g., .aspx, .ashx) is not cached by default. You must explicitly configure caching rules to cache dynamic content.
Mistake
You can change the CDN pricing tier (SKU) after creating a profile.
Correct
The SKU (Standard Microsoft, Standard Akamai, Standard Verizon, Premium Verizon) is fixed at creation. To change tiers, you must delete the profile and create a new one. This is a common exam trap.
Mistake
The Rules Engine in Standard Microsoft CDN supports URL rewrite and device filtering.
Correct
The full Rules Engine with URL rewrite, device filtering, and token authentication is only available in Azure CDN Premium from Verizon. Standard Microsoft has a limited Rules Engine with basic conditions (URL path, file extension, etc.) and actions (cache expiration, redirect, header modification).
Mistake
Custom domain HTTPS is enabled automatically when you add a custom domain.
Correct
HTTPS for custom domains must be explicitly enabled. It is not automatic. After adding a custom domain, you must go to the 'Custom domains' settings and enable HTTPS. Provisioning can take up to 6 hours.
Mistake
CDN endpoints can only point to Azure services as origins.
Correct
CDN endpoints can point to any public HTTP/HTTPS origin, including non-Azure servers. You select 'Custom origin' and provide the origin hostname. The origin must be publicly accessible.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure CDN is a global caching service optimized for static content delivery. Azure Front Door is a global application delivery platform that includes CDN capabilities plus load balancing, SSL offload, path-based routing, and a built-in WAF. Front Door acts as a reverse proxy, while CDN is primarily a cache. For the exam, know that Front Door is more feature-rich but costlier. Use CDN for simple caching, Front Door for advanced routing and security.
Yes. Add a custom domain to your CDN endpoint by creating a CNAME record pointing to the endpoint hostname (e.g., cdn.contoso.com -> myendpoint.azureedge.net). Then enable HTTPS: choose 'CDN managed' (free certificate from DigiCert) or 'Use your own certificate' (Premium tier only). HTTPS provisioning may take up to 6 hours. During this time, the custom domain will not serve HTTPS traffic.
You can purge the cache for specific paths using Azure CLI, PowerShell, or the portal. For example, `az cdn endpoint purge --content-paths '/images/*' --name MyEndpoint --profile-name MyProfile -g MyResourceGroup`. This removes the cached content from all edge nodes. The next request will fetch from origin. Alternatively, reduce the TTL in caching rules or set Cache-Control headers on the origin to a shorter duration.
For APIs that return dynamic data (e.g., user-specific responses), you should bypass caching entirely to avoid serving stale data. In the CDN endpoint, set caching rules to 'Bypass caching' or use the Rules Engine with a condition on the URL path (e.g., /api/) and action 'Cache expiration' set to 0 seconds. If the API returns static data (e.g., product catalog), you can cache with a short TTL (e.g., 60 seconds) using 'Override' caching.
Yes. Azure Storage static websites can be used as an origin for CDN. In the CDN endpoint, select origin type 'Storage' and choose the storage account. The primary endpoint of the static website (e.g., https://mystorageaccount.z13.web.core.windows.net) is the origin. You can also use the blob service endpoint (e.g., https://mystorageaccount.blob.core.windows.net/$web). Ensure the storage account allows public access. CDN will cache the static files (HTML, CSS, JS).
The Rules Engine allows you to customize CDN behavior based on conditions (URL path, file extension, request header, country, device type) and actions (cache expiration, redirect, header modification, compression). It is available in Standard Microsoft (limited) and Premium Verizon (full). To use it, go to your CDN endpoint, select 'Rules Engine', and create rules. Rules are evaluated in order; the first matching rule applies. For example, to redirect all requests from /old to /new, add a condition 'UrlPath begins with /old' and action 'UrlRedirect' to the new URL.
Common causes: (1) The origin host header is incorrect. The CDN sends the origin host header to the origin; if it doesn't match the origin's expected host, the origin may return 404. Ensure the 'Origin host header' in the endpoint matches the origin's hostname. (2) The origin path is wrong. Check the 'Origin path' setting; it should be '/' or the correct subfolder. (3) The file is not publicly accessible. Ensure anonymous access is enabled on the origin. (4) DNS propagation delay; wait up to 90 minutes after creating the endpoint.
You've just covered Azure CDN Profiles and Rules Engine — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?