You created a Block rule for "Streaming Media" at Order 50, and an Allow rule for the same category targeting your CEO at Order 60. The CEO complains Netflix is blocked. Why?

Correct answer: (b) Order 50 evaluates first and matches the CEO's group too, so the Block fires before the Allow at Order 60 is ever reached. Fix: put the Allow at Order 40 (above the Block). Correct: (b). First-match wins. Order 50 matches everyone in the Streaming Media category — including the CEO — so the Block fires and evaluation stops before Order 60 is even considered. The fix is universal: put exceptions above the broader Block rule. (a)/(c)/(d) could be problems too but the order is the textbook cause.

You want to block YouTube uploads but allow viewing. URL Filtering can block youtube.com entirely, but you need finer control. Which feature?

Correct answer: (c) Cloud App Control for YouTube — has sub-actions like "Allow View" and "Block Upload" specifically per app. Correct: (c). Cloud App Control is purpose-built for sub-action granularity on known SaaS — view vs upload vs share vs comment, all distinct controls. URL Filtering only acts on URL/category level. (a) HTTP method match isn't a URL Filtering field. (b) Caution is an action, not a granular control. (d) bandwidth throttles, doesn't differentiate view vs upload.

An employee opens portal.office.com and signs into their personal @outlook.com account on their corporate laptop. Data flows to their personal OneDrive. How do you prevent this in ZIA?

Correct answer: (b) Cloud App Control → Microsoft Office 365 → Tenant Restriction . Whitelist only your corporate tenant ID. ZIA inserts the Restrict-Access-To-Tenants header — Microsoft rejects every non-listed tenant. Correct: (b). Tenant restrictions are exactly built for this — ZIA injects a header on every Office 365 request telling Microsoft "only allow these tenant IDs to authenticate." All non-corporate tenants are rejected at Microsoft side. (a) blocks corporate use too. (c) blocks all OneDrive including the corporate one. (d) Custom URL list doesn't enforce tenant identity.

A user complains "I'm blocked from a site I should have access to." You want to find which rule blocked them. Fastest path?

Correct answer: (a) ZIA Admin → Insights → Web → filter by user + URL + time. The blocked transaction shows the rule name in the Policy column. Right-click → View Policy Tree shows the whole evaluation chain. Correct: (a). Insights → Web is the per-transaction debug view. The Policy column tells you which rule matched. View Policy Tree shows the full evaluation chain so you see why earlier rules didn't match too. (b)/(c)/(d) are slow or destructive.

You created a Custom URL list with *reddit.com intending to match reddit.com and all its subdomains. Auditing logs show verybadreddit.com also matches. What went wrong?

Correct answer: (d) Wildcard typo: *reddit.com matches any string ending in reddit.com . Use *.reddit.com (dot after wildcard) to match only subdomains of reddit.com . Correct: (d). The missing dot makes all the difference. *reddit.com is a suffix match — any character before "reddit.com" is fine. *.reddit.com requires a subdomain (dot is mandatory). Always test custom wildcards with a non-trivial example. (c) SSL isn't relevant to URL matching. (b) wildcards are supported.

You enabled URL Filtering rule "Block youtube.com" but users still watch YouTube on their corporate laptops. SSL Inspection is OFF. Why doesn't the rule match cleanly?

Correct answer: (c) Without SSL Inspection, ZIA only sees the SNI (the domain — youtube.com ) but can't read the full URL or HTTP method. Domain-level block should work — but if YouTube serves video on a CDN like googlevideo.com , traffic continues on a different domain ZIA doesn't block. Fix: enable SSL Inspection so ZIA sees the full URL and can match Cloud App Control rules at the YouTube application level instead of just the domain. Correct: (c). Without SSL Inspection, ZIA's view is limited to the TLS SNI — fine for blocking the domain itself, but YouTube actively serves video from googlevideo.com and other CDN domains. Blocking youtube.com only stops the front page; the video stream continues. SSL Inspection lets Cloud App Control identify "YouTube" as an application across all its CDN domains and block holistically.

For a Newly Registered Domain (NRD) category that often hosts phishing but sometimes hosts legit new SaaS, what's the best action?

Correct answer: (b) Caution — ZIA shows a "this site might be risky, proceed?" interstitial. Users who genuinely need it click through; phishing victims pause. Half-block, half-allow with no admin overhead. Correct: (b). Caution is built for grey-area categories — high false-positive rate but real risk. Users self-select with an extra click. (a) Allow misses real phishing. (c) Block frustrates teams trying new SaaS. (d) Isolate is heavier (compute cost, latency); use only for truly high-risk categories like Adult or Anonymizers.

A Cloud App Report shows your Engineering team uses 14 different GenAI tools. The CTO wants to keep productivity but stop source-code leakage. Which combination of ZIA features?

Correct answer: (d) Cloud App Control to triage: Sanctioned (allow corporate Claude Team / ChatGPT Enterprise with tenant restrictions) · Unsanctioned (allow read-only, DLP-watch uploads — block source-code-fingerprint matches) · Blocked (deny sketchy ones). Plus DLP rules on the unsanctioned bucket. Correct: (d). Triage into sanctioned/unsanctioned/blocked plus DLP is the production pattern for this exact problem — productivity preserved, leak vector closed at the upload. (a) blocks productivity entirely. (c) time quota doesn't prevent code leakage in the first 30 min. (b) education alone is not a control.

A Time Quota rule grants Engineering 30 minutes/day on "Streaming Media". A user spends 15 min on YouTube and 15 min on Netflix, both in Streaming Media. What's the result?

Correct answer: (a) All 30 min are consumed (15 + 15) because both categories are named in the same rule and therefore share the same per-rule pool. After this, any Streaming Media site matched by that rule is blocked till midnight. Correct: (a). Time quota is configured per rule , and quota consumption is tracked per user per rule . All categories named in the same rule share the same pool. Two categories in separate rules each get their own pool. Not 'category-wide'. (b)/(c) misunderstand the pool. (d) selective exemption needs separate rules.

You're rolling out a new ZIA tenant and need to set up URL Filtering rule order. Which sequence is best practice?

Correct answer: (c) Allow exceptions (10–19) → Block by group/loc/time (20–39) → Caution (40–49) → Block universal-bad (50–59) → default Allow. Correct: (c). The canonical Zscaler URL Filter rule pattern: Allow exceptions first (carve out VIPs and edge cases), then group-specific Blocks (the bulk of business rules), then Cautions (grey-area), then universal-bad Blocks (phishing, malicious, adult), then default Allow at the bottom. Same shape on every tenant — pattern-match it in your head when reviewing any deployment.

URL Filtering & Cloud App Control — Batch 11 · Lesson 5

Why this lesson matters

URL Filtering and Cloud App Control are where 80% of the business value of ZIA shows up. Auth + forwarding are infrastructure. Policy is the product. If you can't articulate why this rule matches before that rule, you can't debug a single "why is YouTube allowed for Marketing when I blocked it?" ticket. This lesson nails that.

It also covers a quiet feature most engineers underuse: Cloud App Reports. Every user, every SaaS they touched, ranked by risk score. Hand it to a CISO and you've discovered the company's entire shadow-IT footprint in 30 minutes. That alone justifies a Zscaler deployment.

URL Filtering — the anatomy of one rule

Super-Categories vs Categories

ZIA's URL taxonomy is two-level: 6 super-categories (Bandwidth Loss, Business Use, General Surfing, Privacy Risk, Productivity Loss, Security Risk) split into 160+ categories (e.g. Streaming Media, Gambling, Webmail). You can write a rule against a super-category to block all 'Security Risk' child cats at once — fewer rules to maintain. ZDTA exam tip: super-cat-vs-category is a common distractor.

Every URL Filtering rule has the same shape. Once you see the parts, you can build any rule by recipe.

Field	Example	What it does
Rule order	10, 20, 30…	First-match wins. Lower number evaluates first.
Rule name	"Block-Social-Marketing"	Searchable identifier. Use a naming convention.
Action	Block · Allow · Caution (notify-and-continue) · Allow with Quota · Isolate (requires separate Zscaler Browser Isolation SKU)	What happens on match.
URL Categories	"Social Networking", "Streaming Media"	One or more of 160+ URL categories organized into 6 super-categories (Bandwidth Loss, Business Use, General Surfing, Privacy Risk, Productivity Loss, Security Risk).
Custom URLs	"reddit.com", "*.4chan.org"	Exceptions or additions to category coverage.
Groups	Marketing, Engineering	Match only for these IdP groups.
Locations	Mumbai-HQ, all-roaming	Match only at these Locations or Sub-Locations.
Time	Mon-Fri 09:00-18:00	Restrict to working hours, allow social after-hours.
Bandwidth	Cap 5 Mbps/user	Throttle without blocking. Useful for streaming.
Quota	30 min/day for "Streaming Media"	User can browse, but only X minutes per period.

Build a real rule — "Block social for Marketing during work hours"

ZIA Admin Portal · URL Filtering rule

Policy → URL & Cloud App Control → URL Filtering → + Add Rule

  Order:            20
  Name:             Block-Social-Marketing-Workhrs
  Action:           Block
  Severity:         Medium  (used in Insights filtering)

  URL Categories:   Social Networking, Personal Network Storage,
                    Dating, Streaming Media (Video)
  Custom URLs:      reddit.com, hackerrank.com  (exception: hackerrank
                    is "social" but engineers need it during interviews)
  Group:            Marketing
  Location:         All (HQ + branch + roaming)
  Time:             Mon-Fri 09:00-18:00 IST
  HTTP/HTTPS:       Both

Save → Activate

That single rule covers ~95% of "block X for group Y during hours Z" tickets. Note the trick: list hackerrank.com in Custom URLs without going to the Allow rule first — that's a category-level override done inside the same Block rule using ZIA's Exception handling. Cleaner than a separate Allow rule above.

The policy evaluation order — first match wins

ZIA URL Filtering rules are evaluated top-to-bottom by Order number. First match wins. The moment a rule matches, evaluation stops and the action applies. This is why rule order is the single most important thing you'll touch.

ZIA URL Filtering policy evaluation flow

Top-down evaluation. The instant any rule matches, ZIA stops and applies that action. So if you Block social for Marketing at Order 20, then Allow social for everyone at Order 50, Marketing still gets blocked — Order 20 fires first. Order matters more than logic.

The classic order pattern (use this on every tenant)

10-19: Allow rules for exceptions / VIPs / bypasses
20-39: Block rules for group/location/time-based restrictions
40-49: Caution rules for risky-but-allowed categories
50-59: Block rules for universally bad (malicious, phishing, adult)
Default: Allow — anything else passes through (with malware scan, SSL inspect, etc. still applying — those are separate policy stacks)

Cloud App Control — the SaaS layer

URL Filtering treats every site as a URL. Cloud App Control treats SaaS as applications with sub-actions. You can block YouTube as a category at the URL layer, OR you can use Cloud App Control to "allow YouTube view but block YouTube upload". Sub-action granularity is the whole point.

Sanctioned vs unsanctioned — the core distinction

Category	Definition	Action pattern
Sanctioned	Approved corporate SaaS (Office 365 tenant `company.onmicrosoft.com`, Google Workspace `company.com`, Salesforce instance, the official Slack workspace)	Allow — but enforce tenant restrictions so users can't sign in to other Office 365 tenants from corporate devices
Unsanctioned	Shadow IT — personal Dropbox, personal Google Drive, random GenAI tools, file converters	Block uploads, allow read-only, or block entirely. Log for Cloud App Reports.

Tenant Restrictions — the killer feature

Office 365 tenant restrictions stop users from signing into any other Office 365 tenant from your network. Without it, an employee can open portal.office.com and log into their personal Microsoft account — exfiltrating corporate data to a personal OneDrive. ZIA enforces this by inserting the Restrict-Access-To-Tenants HTTP header into every Office 365 request — your corporate tenant ID is allowed, every other rejected by Microsoft.

Modern Microsoft tenant restrictions use header sec-Restrict-Tenant-Access-Payload (a signed JWT) — v2. Legacy v1 used Restrict-Access-To-Tenants + Restrict-Access-Context. Both injectable via ZIA Tenant Restrictions module.

ZIA · Office 365 Tenant Restriction

Policy → URL & Cloud App Control → Cloud Applications →
Tenant Restriction → + Add Cloud Application

  Cloud Application: Microsoft Office 365
  Action:            Restrict
  Allowed Tenants:   contoso.onmicrosoft.com  (your tenant)
                     contractor.onmicrosoft.com  (partner if needed)
  Restrict v2:       Enabled  (newer header format)

Save → Activate

The app-control hierarchy SVG

Cloud App Control — sanctioned / unsanctioned / blocked hierarchy

Three buckets, three different actions. Most cloud-app design conversations boil down to "what goes in which column" — that's the entire framework.

URL Rule Order Lab Cloud App Drill

📊Cloud App Risk Score (1-5)

Cloud App Risk Score (1-5): derived from data retention, admin audit logs, encryption-at-rest, MFA support, breach history. ZIA Cloud App Reports rank apps by this score. Standard interview question — know the input dimensions.

🔑Admin override codes

Override codes let a help-desk give a one-time pass for a blocked URL. Useful for emergency unblocks without policy change. Generated under Administration → User Management → Override Codes.

Time quotas — the "allow with limit" pattern

Sometimes you don't want to outright block. "Engineers can browse Reddit, but cap them at 30 minutes per day" is the time-quota use case. ZIA tracks per-user time spent in matched categories and shows a polite block page once the quota is hit ("you've used your 30 minutes on Streaming today — try again tomorrow").

URL Filtering rule with daily quota

Order:          25
Action:         Allow with Quota
URL Category:   Streaming Media (Video)
Group:          Engineering
Time Quota:     30 minutes / day
Bandwidth Cap:  5 Mbps (per user, while streaming)

Common production gotchas

⚠Common Mistakes — URL filtering + cloud apps

Rule order wrong — Block rule for everyone at Order 50, an Allow rule for a VIP at Order 60. Rule 50 fires first, VIP also gets blocked. Always put Allow exceptions above the Block.
Forgot to enable SSL Inspection for the URL category — HTTPS sites get only the SNI / domain match, not the full URL. So you can block youtube.com by SNI but not youtube.com/watch?v=xyz without SSL inspection.
Custom URL with wildcard typo — *reddit.com matches verybadreddit.com too. Use *.reddit.com (dot before).
Sanctioned tenant rule has wrong tenant ID — entire company locked out of Office 365 in 5 minutes. Always test on one user first, get them to login successfully, then Activate broadly.
Cloud App Reports never reviewed — shadow IT discovered only after a leak. Schedule weekly review of the top 20 unsanctioned apps; promote to Sanctioned, restrict, or Block.
Time quota set per-rule but multiple categories share the quota — engineer uses 15 min on YouTube and 15 min on Netflix, both quota-allowed under "Streaming Media" → all 30 min consumed even though each individual app got less. Educate users.

💡Pro Tip — use Caution before Block on grey-area categories

For categories like "Newly Registered Domains" (potential phishing but lots of false positives), don't go straight to Block — use Caution. Caution shows a "this site might be risky, proceed?" interstitial. Users who genuinely need the site click through; phishing victims pause and reconsider. Half-block-half-allow with no admin overhead.

✓Verify — confirm a rule actually matched

After saving + Activating any rule:

Test from one user's browser. Block rule → expect Zscaler block page. Allow → expect the site loads.
ZIA Admin → Insights → Web → filter by URL + user. Each transaction shows which rule matched (rule name in the "Policy" column).
Right-click any transaction → "View Policy Tree" — shows the full chain of rules evaluated and where the match happened. Best debugging tool ZIA ships.
Bonus: schedule a daily Cloud App Report and have it emailed to security@. Top-10 unsanctioned apps with user counts → instant shadow-IT visibility.

Real-world scenario — Engineering's GenAI tool sprawl

Wednesday standup. Engineering manager: "Half our devs are pasting code into ChatGPT, Claude, Perplexity, every random AI tool. We can't ban all of them — productivity will tank. But we can't allow source code leakage either."

Your design using everything in this lesson:

Cloud App Reports — run a 7-day report on the Engineering group, all AI-tool categories. You discover 14 distinct GenAI services in active use.
Triage into three buckets: Sanctioned (your enterprise ChatGPT account, Claude Team) · Unsanctioned (personal accounts on the same services + a few obscure ones) · Blocked (totally unknown ones that look like data-exfil fronts).
Sanctioned rules: Allow with tenant restriction — Engineering can use your Claude Team workspace but not personal Claude. Same for ChatGPT Enterprise.
Unsanctioned: Allow read-only (engineers can read AI outputs) but DLP-watched on upload — if they paste source code matching your code-fingerprint patterns, ZIA blocks the upload and logs to SIEM.
Blocked: outright denial of the 4 sketchy ones. Block page explains why and points to the sanctioned alternative.
Caution for any newly-discovered AI tool added to the Newly Registered category — engineers see a "proceed if you trust this" warning and self-select.

Zero productivity loss for engineers who use sanctioned tools. Source code leakage blocked at the upload. Shadow IT shrunk from 14 tools to 2 sanctioned + a handful of read-only.

📌 Quick reference (memorise before Module 6)

URL Filtering rule fields: Order · Name · Action · URL Categories · Custom URLs · Groups · Locations · Time · Bandwidth · Quota
Actions: Allow · Block · Caution · Isolate · Allow with Quota
First-match wins — order is everything. Allow exceptions go ABOVE Block rules.
Classic order pattern: 10–19 Allow exceptions · 20–39 Block by group/loc/time · 40–49 Caution · 50–59 Block universal-bad · Default Allow.
Cloud App Control = sub-action granularity (allow view, block upload) on SaaS apps.
Sanctioned vs Unsanctioned: corporate-tenant SaaS vs personal/shadow IT.
Tenant Restrictions — Office 365 / Google Workspace: only your corporate tenant logs in from the network.
Time Quota: allow with daily/weekly minute cap per category, per user.
SSL Inspection ON for full URL matching — without it, you only see SNI (domain).
Insights → Web → Policy Tree = your first stop when "why didn't my rule fire?"
Cloud App Reports — weekly review of unsanctioned SaaS to catch shadow IT early.

▶ QUICK LAB · ~15 MIN

Build a tight URL/Cloud App policy:

In ZIA Admin → Policy → URL Filtering: create a rule blocking "Security Risk" super-category for ALL users.
Add a second rule blocking "Productivity Loss → Social Media" with a 30-min quota for the Marketing group.
In Cloud App Control: block ChatGPT for all, allow for the AI-Engineers group.
Validate by browsing each category from a test laptop — verify block page or quota timer fires.

What's next — Lesson 6

URL Filtering matches based on what ZIA can see in the request. To see inside HTTPS requests, you need SSL Inspection. Next: SSL Inspection & File Type Control — the cert chain, Zscaler Root CA distribution, MITM concept, pinned-app exemptions, and the file-type rules that decide which uploads/downloads are allowed.

Module 6 → SSL Inspection & File Type Control (next) Practice ZDTA on exam.techclick.in

URL Filtering & Cloud App Control — shape what users can actually do