Cloud Web And Email Security Automation practice questions

WSA Admin password

Why it fails: The Investigate API authenticates with an API key and secret, not WSA credentials; the web security appliance is a separate product with its own console. It is tempting because WSA administrators often own Umbrella deployments, but those credentials grant no Investigate API access.

Internal DNS server IP

Why it fails: The internal DNS server address is irrelevant to Investigate API authentication; queries go to Cisco's cloud service over HTTPS, not through your resolver. It is tempting because DNS configuration matters for Umbrella's forwarding, but that is deployment, not API authentication.

Organization ID

Why it fails: The Organization ID is not an authentication credential for the Investigate API; access is granted by API key and secret pair. It is tempting because organisation identifiers appear in other Cisco cloud APIs, but Investigate authenticates solely on the key pair.

/v1/organizations/{organizationId}/policies/destination-lists

Why it fails: This path does not exist in the Umbrella Management API.

/v1/reports/destinationlists/{organizationId}

Why it fails: This endpoint is used for reporting, not management.

/api/v2/orgs/{organizationId}/dest-lists

Why it fails: This is an incorrect URI structure for the Umbrella API.

PATCH

Why it fails: PATCH is not the primary method for this specific API operation.

DELETE

Why it fails: DELETE is used for removing messages, not releasing them.

GET

Why it fails: GET is used for retrieving data, not performing state changes.

slice_id

Why it fails: Slice ID is not a valid parameter for Umbrella reporting.

page_token

Why it fails: This parameter is not used in the Umbrella Reporting API.

session_id

Why it fails: Session ID is for authentication tokens, not data pagination.

Sending a block command to the Cisco Umbrella API

Why it fails: Umbrella controls DNS traffic, not SaaS application OAuth token revocation.

Updating the SaaS app status to 'Disabled' in the Cloudlock console via API

Why it fails: Changing an app's status disables the application registration, not individual OAuth grants, so compromised tokens remain valid until expiry. It is tempting because status changes are exposed through the API, but the token revocation endpoint is the correct mechanism when you must invalidate specific compromised OAuth tokens immediately.

Deleting the user account from the Cloudlock directory

Why it fails: Removing a user from the Cloudlock directory only affects Cloudlock's own records; it does not revoke the OAuth grant held by the SaaS provider, so the token stays live. It is tempting because directory cleanup is API-driven, but the token revocation endpoint is what invalidates compromised OAuth tokens.

DELETE /msg/{mid}

Why it fails: DELETE /msg/{mid} removes a message from the queue or deletes it, so it cannot place a message into quarantine. It would be the correct call when the intent is to drop or purge a specific message rather than isolate it for review.

GET /msg/quarantine?mid={id}

Why it fails: GET /msg/quarantine?mid={id} is a read operation returning quarantine status or listing entries; it cannot move a message into quarantine. It would be correct when querying which messages currently sit in quarantine for a given message ID.

PUT /policy/quarantine/{mid}

Why it fails: PUT /policy/quarantine/{mid} targets quarantine policy configuration keyed by message ID, not a message action, so it cannot move a specific message. It would be correct when updating policy settings rather than quarantining an individual message.

Install the Umbrella Connector on a local server

Why it fails: The Umbrella Connector is a separate on-premises component for DNS forwarding from roaming clients, not a dashboard prerequisite for VA deployment. It is tempting because connectors relate to Umbrella, but VA automation requires the site and API key registered in the dashboard so the VA can authenticate and register.

Enable the 'Legacy' API mode

Why it fails: Legacy API mode is a deprecated compatibility setting for older integrations, not a prerequisite for VA deployment automation. It is tempting because it appears as a dashboard API toggle, but VA provisioning requires the site and API key configured in the dashboard so the appliance can authenticate and register.

Create a dedicated API user account

Why it fails: Umbrella VA deployment via API requires a pre-generated API key and legacy token from the dashboard; a dedicated API user account is not the prerequisite, since Umbrella API credentials are issued as keys, not user logins. Dedicated service accounts are the correct approach for platforms like Microsoft Entra ID that authenticate principals.

Rule Enforcement API

Why it fails: The Rule Enforcement API manages rule sets and policy objects, not the deployment of configuration to appliances. It would be the right component for programmatically creating or editing rules, but triggering a policy push to apply committed changes requires the dedicated push endpoint.

Device Sync API

Why it fails: The Device Sync API synchronises appliance registration and status data with the management server; it does not commit configuration changes to the proxy. It would be correct for reconciling device inventory, whereas a policy push needs the endpoint that publishes staged configuration to the WSA.

Policy Push API

Why it fails: No Policy Push API exists within the WSA API surface; the correct component is the Policy Commit API, which publishes staged configuration to the appliance. A similarly named endpoint is tempting because the task literally describes a push, but the actual API naming uses commit terminology.

filter='High'

Why it fails: Cloudlock's incident filter expects the severity field value 'High', not a bare 'filter=High' parameter; the correct parameter is severity. It is tempting because filter is a genuine Cloudlock query parameter, but it applies to fields such as severity or category, so the syntax must name that field explicitly.

limit=high

Why it fails: limit controls how many incidents are returned per page, not which severity is retrieved, so 'limit=high' is invalid and filters nothing. It is tempting because limit is a real Cloudlock API parameter, and it would be correct when you need to cap result volume or paginate through a large incident set.

status='critical'

Why it fails: status selects incident workflow state (open, resolved, etc.), not severity, so 'critical' matches nothing in Cloudlock's severity vocabulary. It is tempting because status is a valid Cloudlock parameter, and it would be correct when filtering incidents by their investigation lifecycle rather than by risk level.

The incidents have been deleted by the user

Why it fails: Incident logs are typically preserved for audit purposes, not immediately deleted.

The API is offline

Why it fails: If the API were offline, the script would receive errors, not missed data.

The script uses POST instead of GET

Why it fails: The incident retrieval API is GET-based; using POST would return an error.

{"type": "oauth", "state": "blocked"}

Why it fails: The App Firewall expects the app's own status field set to 'revoked'; 'state' with 'blocked' targets a different attribute and value. It is tempting because it mirrors the type/state pattern used elsewhere in Cloudlock's API, but the correct body uses {"status": "revoked"}.

{"action": "delete"}

Why it fails: Deleting the app removes the record entirely rather than transitioning its status to Revoked. It is tempting because revocation sounds like removal, but Cloudlock's App Firewall requires a status update, so the correct body sets the app's status field to 'revoked' instead of issuing a delete action.

{"user_id": "all", "action": "revoke"}

Why it fails: This structure targets user-level revocation, not an OAuth application's status. It is tempting because 'revoke' matches the desired outcome and user_id scoping appears in Cloudlock policy calls, but the App Firewall expects the app's status field set to 'revoked' in the request body.

GET

Why it fails: GET retrieves a policy representation and changes nothing on the server. It tempts because you must first read the policy to know its current state, but the update itself requires a method that submits modified fields. Cloudlock applies changes through PUT or PATCH, not GET.

PATCH

Why it fails: While PATCH can be used for partial updates, PUT is the primary method for updating policy objects.

POST

Why it fails: POST creates a new subordinate resource or triggers an action, so it cannot target an existing policy's URI for replacement. It is tempting because POST is the general-purpose write method many APIs accept for updates, and it would be correct when creating a new Cloudlock policy rather than modifying one.

CONNECT

Why it fails: CONNECT is not used in the Umbrella API.

HEAD

Why it fails: HEAD is generally not used for resource management in this API.

TRACE

Why it fails: TRACE is not used in the Umbrella API.

Reboot the appliance

Why it fails: Rebooting is not required for API access.

Configure a local Syslog server

Why it fails: Syslog is for log forwarding, not API-based retrieval.

Enable SSH access

Why it fails: SSH is for CLI, not REST API.

organizationId

Why it fails: Organization ID is typically in the URL path, not the body.

description

Why it fails: Description is optional.

createdAt

Why it fails: This is a system-generated field.

GET

Why it fails: GET is for retrieving data only.

PUT

Why it fails: PUT is typically used for full resource replacement.

DELETE

Why it fails: DELETE removes the resource entirely.

X-API-KEY

Why it fails: This header is used for Umbrella management APIs but not for the Reporting API.

Cookie: session_id

Why it fails: A session_id cookie belongs to browser-based Umbrella dashboard sessions, not the Reporting API, which authenticates each call with a token rather than a cookie. It is tempting because cookie authentication works for interactive dashboard access, and would be correct when scripting against a session-aware web interface.

X-Auth-Token

Why it fails: X-Auth-Token is not the header Umbrella's Reporting API expects; that API requires an Authorization header carrying the API key and secret. It is tempting because X-Auth-Token is a genuine token header used by other Cisco platforms, and would be correct against those APIs rather than Umbrella reporting.

CSV

Why it fails: CSV is used for bulk user imports, not system content filters.

YAML

Why it fails: YAML is not used for AsyncOS configuration files.

JSON

Why it fails: While the API uses JSON for requests, the configuration objects themselves are structured in XML.

/whois/ip/{ip}

Why it fails: The /whois/ip/{ip} endpoint returns registrar and ownership registration data, not reputation or categorisation. It would be correct for mapping an IP to an owning organisation. Security status and associated domains for an IP come from the /security/ip/{ip} endpoint instead.

/threat/ip/{ip}

Why it fails: The Investigate API exposes IP reputation data through /security/ip/{ip}, which returns the security score plus categorised domains; /threat/ip/{ip} does not exist, so the call returns 404. It is tempting because 'threat' suggests reputation data, yet that namespace covers other artefacts such as threat feeds, not per-IP enrichment.

/dnsdb/ip/{ip}/domain

Why it fails: This endpoint returns the domains associated with the specified IP.

Update the config.xml file via SCP

Why it fails: The Management API exposes engine updates through its own endpoints; editing config.xml over SCP changes configuration but does not invoke the update action, and the API call would still fail. It is tempting because SCP file edits are a legitimate ESA administration method for other settings, just not for triggering this operation.

Send a GET request to /config/antispam

Why it fails: A GET to /config/antispam only retrieves the current anti-spam configuration; it performs no update, so the engine is never refreshed. It is tempting because the path looks relevant and GET requests are the natural first step when exploring an unfamiliar API, but reading state cannot trigger the required action.

Restart the appliance via API

Why it fails: Restarting the appliance reboots services rather than invoking the anti-spam engine update endpoint, so the API call's purpose is unmet and the update may not occur. It is tempting because restarts often force components to reload, and it would be correct when a stuck service needs recycling.