Application And Data Security practice questions

SSL inspection is not enabled.

Why it fails: SSL inspection is not required for API-based scanning.

The user is an administrator.

Why it fails: Administrator status does not exempt an account from Cloudlock DLP scanning, so it cannot explain why 'Anyone with the link' sharing escapes detection. This option is tempting because privileged accounts often bypass policy enforcement in other systems; here, the actual cause is the policy's missing public-link exposure condition.

The API token for the SaaS has expired.

Why it fails: An expired API token would halt all Cloudlock scanning, so no files would be flagged, not merely the 'Anyone with the link' ones. It is tempting because token expiry genuinely breaks SaaS integrations, and would be the answer if Cloudlock reported no visibility or authentication errors across every sharing category.

The SSL inspection certificate is not installed on the server.

Why it fails: SSL inspection certificates must be installed on the client, not the server.

The SaaS application is whitelisted in the Global Settings.

Why it fails: While possible, the most common operational failure is the lack of proxy enforcement for DLP.

The DNS policy is not configured for the user group.

Why it fails: DNS policy would block the domain, not the specific file upload action.

Perform a packet capture on the gateway.

Why it fails: Packet captures do not reveal internal SaaS folder access.

Review the Google Drive 'Activity' tab only.

Why it fails: While this works, it is not the Cisco Cloudlock tool requested.

Review the Cisco Umbrella DNS logs.

Why it fails: DNS logs do not show file-level access inside Google Drive.

Cisco Secure Firewall

Why it fails: Firewall handles perimeter traffic, not device trust at the app layer.

Cisco Cloudlock

Why it fails: Cloudlock is for data security at rest, not authentication posture.

Cisco Umbrella

Why it fails: Umbrella controls network access, not device trust posture.

Server location

Why it fails: Server location describes where an app is hosted, which App Discovery does not score; risk ratings derive from categories such as last observed date, popularity and application category. It would matter for data-residency or latency planning, not for the risk score itself.

Number of employees

Why it fails: Organization size is not a security risk factor for the app.

User Behavior Analytics (UBA) policy.

Why it fails: Incorrect. UBA detects anomalies but does not enforce download restrictions.

Threat detection policy.

Why it fails: Incorrect. Threat detection monitors for compromised credentials, not file downloads.

Data Loss Prevention (DLP) policy.

Why it fails: Incorrect. Standard DLP focuses on scanning content at rest, not session-level download enforcement.

Content Inspection Override.

Why it fails: Incorrect. Content inspection is for scanning, not excluding based on signatures.

DLP Sensitivity Threshold.

Why it fails: Incorrect. This defines the confidence level of the scan, not exclusion criteria.

Object Scoping.

Why it fails: Incorrect. Object scoping defines which apps/folders are scanned, not exclusion logic.

Reset the user's password.

Why it fails: Resetting the password changes authentication for one mailbox and does nothing to detect or encrypt credit card numbers in transit; Cloudlock applies DLP policy to inspect content and trigger encryption. It is tempting as a familiar account-remediation step, and would be correct for a compromised credential, not a data-classification requirement.

Enable TLS 1.3 for all outgoing mail.

Why it fails: TLS 1.3 encrypts the transport hop only, so it cannot inspect message content for credit card numbers or apply policy-driven encryption to matching emails. It is tempting because TLS secures mail in transit between servers, which would suit a requirement to enforce transport encryption regardless of content.

Create a firewall rule to block the email.

Why it fails: Blocking the email prevents delivery rather than encrypting it, so the compliance requirement to send credit-card emails encrypted goes unmet. It is tempting because firewall rules do enforce policy on outbound traffic, which suits scenarios demanding outright prevention of sensitive data leaving the organisation.

SaaS application object mapping.

Why it fails: SaaS application object mapping inventories and classifies connected apps; it does not evaluate login source IP reputation against anonymiser or TOR exit-node lists. It is tempting because it does provide SaaS visibility, and it would be the right feature when the requirement is discovering which unsanctioned applications users have granted access to.

File content scanning.

Why it fails: File content scanning inspects document contents for sensitive data or malware; it never examines the source IP of a login, so anonymiser and TOR exit-node traffic goes undetected. It is tempting because content scanning is Cloudlock's headline capability, and it would be correct when the requirement is detecting exposed regulated data inside files.

Encryption key management.

Why it fails: Cloudlock's anonymizer/TOR detection relies on its User Behaviour Analytics and IP reputation feeds, not cryptographic controls. Encryption key management governs how Cloudlock encrypts data at rest and in transit, so it cannot attribute a login to an anonymiser. It would be the right pick only when configuring customer-managed keys for data protection.

In Cisco Umbrella, create a policy that blocks all uploads to unsanctioned apps, and in Cloudlock, create a DLP policy that blocks PII uploads to sanctioned apps only.

Why it fails: Blocking all uploads to unsanctioned apps would prevent any file transfer, not just PII, which is overly restrictive. The requirement is to block only PII uploads to unsanctioned services while allowing other uploads. Additionally, Cloudlock DLP policies for sanctioned apps would not address unsanctioned apps. This approach misinterprets the granularity needed.

Configure a Cisco Umbrella cloud firewall rule to block all uploads to unsanctioned apps, and use Cloudlock to scan approved apps for PII.

Why it fails: Cisco Umbrella's cloud firewall can block traffic to unsanctioned apps based on App Discovery categories, but it cannot inspect file contents for PII. Cloudlock provides content inspection for sanctioned apps via API, but it does not enforce blocking for unsanctioned apps at the network layer. This split does not achieve the goal of blocking PII uploads to unsanctioned services while allowing them to approved ones.

Create a Cloudlock DLP policy that inspects all uploads and blocks those matching PII patterns, then set the policy to apply only to unsanctioned apps using the Cloudlock app category filter.

Why it fails: Cloudlock DLP policies can inspect content and block uploads, but Cloudlock does not natively classify apps as sanctioned or unsanctioned. That classification is performed by Cisco Umbrella's App Discovery, which tags apps as sanctioned or unsanctioned based on tenant settings. Cloudlock policies operate on the app itself, not on Umbrella's sanction status, so this approach would not selectively block only unsanctioned services.

Set the policy action to 'Block' and configure a custom message for the user.

Why it fails: The 'Block' action prevents the sharing action from occurring in real-time, but it does not quarantine an already shared file. If the file was already shared, blocking would not retroactively remove access. The scenario specifies that the file is shared and needs to be quarantined, implying post-facto remediation, which 'Block' does not provide.

Set the policy action to 'Alert' and configure an email notification to the user.

Why it fails: The 'Alert' action generates an incident and can notify administrators, but it does not quarantine the file or prevent access. The requirement is to automatically quarantine the file, which requires a more restrictive action. Alerting alone would not stop the data exposure, leaving the credit card numbers accessible to the external recipient until manual intervention.

Set the policy action to 'Tombstone' and enable user notification.

Why it fails: Cloudlock does not have a policy action called 'Tombstone'. The available actions are Alert, Block, Quarantine, and others. Tombstone is not a valid action, so this option is incorrect. The correct action for removing access and containing the file is Quarantine, which also supports user notification.

Deploy a Cloudlock proxy and configure it to intercept traffic to the custom application.

Why it fails: Cloudlock does not offer an on-premises proxy for traffic interception. It is a cloud-native CASB that uses API connectors to access data directly from cloud services. A proxy-based approach would require a different product, such as Cisco Umbrella's secure web gateway, but that would not provide the same depth of API-based content inspection and policy enforcement for the custom app.

Use the Cloudlock Service Provider Interface (SPI) to develop a custom connector.

Why it fails: Cloudlock does not have a Service Provider Interface (SPI) for custom connectors. The correct mechanism is the Custom API Connector, which is a configuration-based integration rather than a code-level SPI. Developing a custom connector via an SPI would require access to Cloudlock's internal APIs, which are not exposed for this purpose.

Configure Cisco Umbrella's App Discovery to recognize the custom application and then enable Cloudlock scanning.

Why it fails: Cisco Umbrella's App Discovery can identify traffic to cloud applications, but it does not provide the API-level integration needed for Cloudlock to scan files and enforce DLP policies. App Discovery is for visibility and categorization, not for content inspection. Without a native API connector or custom connector, Cloudlock cannot access the files stored in the custom application.

Cisco Umbrella's App Discovery to identify unsanctioned sharing of files.

Why it fails: Cisco Umbrella's App Discovery identifies cloud applications based on network traffic, but it does not monitor file permissions or content within Google Workspace. It cannot detect when a specific file becomes publicly accessible or contain sensitive data. Therefore, it does not fulfill the requirement for continuous file monitoring and automatic restriction within the SaaS application.

Cloudlock's Incident Management dashboard to manually review and remediate exposures.

Why it fails: The Incident Management dashboard is for reviewing and responding to incidents, but it is not a proactive monitoring feature. It relies on policies to generate incidents. While it is part of the remediation workflow, it does not itself provide continuous monitoring or automatic restriction. The requirement is for automatic restriction, which is achieved through policy actions, not manual review.

Real-time DLP policies that scan files upon upload and sharing.

Why it fails: Real-time DLP policies scan files at the moment of upload or sharing, which is useful for preventing initial exposure. However, the requirement includes continuous monitoring of files that may become publicly accessible after sharing. Real-time policies do not re-scan existing files when permissions change later, so they alone do not meet the continuous monitoring aspect.

Cisco Secure Endpoint

Why it fails: Secure Endpoint protects endpoints through AMP signatures and behavioural analysis; it does not inspect SaaS-bound web traffic inline. URL filtering and malware scanning of that traffic belong to Cisco Umbrella's secure web gateway, which is why Secure Endpoint is the wrong component here.

Cisco Cloudlock

Why it fails: Cloudlock is an API-based CASB providing data loss prevention, app discovery and policy violation alerts; it does not sit inline to filter URLs or scan SaaS traffic for malware. That inline inspection is performed by Cisco Umbrella's secure web gateway.

Cisco Adaptive Security Appliance

Why it fails: The Adaptive Security Appliance is a stateful firewall and VPN platform for on-premises perimeter traffic, not a cloud-delivered secure web gateway. It cannot perform the inline URL filtering and malware scanning of SaaS-destined traffic that Cisco Umbrella provides.

File size limit

Why it fails: Duo policies evaluate identity, device posture, location, network and risk attributes; file size is not an access condition. It is tempting because file-related controls exist in data-loss prevention tooling, but Duo authorises sessions before any file transfer occurs.

Application bandwidth usage

Why it fails: Duo policy conditions cover user identity, group membership, device health, location and network ranges; bandwidth consumption is not evaluated at authentication time. It is tempting because bandwidth monitoring appears in network management tools, but Duo gates access before traffic flows, not during it.

To pre-authenticate users for that SaaS.

Why it fails: App Discovery identifies and reports SaaS usage from traffic logs; it does not authenticate users to third-party applications, which is handled by identity providers via SAML or OIDC. Pre-authentication is tempting because Umbrella does integrate with identity systems for policy, but that is a separate function from defining a Cloud Application.

To increase bandwidth for authorized SaaS apps.

Why it fails: App Discovery provides visibility into which cloud applications are in use; it cannot allocate or increase bandwidth, which is a network QoS function. Bandwidth control is tempting because Umbrella can block or allow apps, but defining a Cloud Application only classifies traffic for reporting, not for prioritisation or throughput guarantees.

To bypass SSL inspection for the application.

Why it fails: Defining a Cloud Application categorises and reports on SaaS usage; SSL inspection bypass is configured through selective decryption settings, not App Discovery. The confusion arises because both features reference applications by name, but bypassing decryption is a policy action, whereas App Discovery is purely visibility and reporting.

Block the user account in Active Directory

Why it fails: Blocking an Active Directory account suspends the whole identity, not the offending file, and Cloudlock's remediation targets the O365 object itself. It is tempting because account suspension is a genuine response to repeated policy breaches, but file-level DLP violations call for quarantine, restore or permission changes within the platform.

Change the file owner

Why it fails: Changing ownership transfers the file to another user but leaves the violating content intact and accessible, so the DLP breach persists. It is tempting because ownership transfer is a legitimate remediation for orphaned or departed-user files, where reassigning custody restores accountability rather than removing offending data.

Re-encrypt the file with a new key

Why it fails: Cloudlock remediates by deleting, quarantining, or removing sharing permissions on the violating file; re-encrypting with a new key is not a supported remediation action. It is tempting because encryption protects data at rest, which is correct when you own the key management and want to render content unreadable, not for policy violation response.

Cisco Secure Firewall

Why it fails: Cisco Secure Firewall inspects traffic inline at the network edge, so it cannot query a SaaS provider's API to examine stored data at rest. It is tempting because it delivers strong SaaS application visibility and control for traffic crossing it, which would be correct if the requirement were inline traffic inspection rather than API-based data-at-rest scanning.

Cisco Stealthwatch

Why it fails: Cisco Stealthwatch analyses NetFlow and network telemetry to detect anomalous traffic, not data stored inside SaaS tenants. It is tempting because it provides broad network visibility, and it would be the right choice if the question asked about detecting lateral movement or exfiltration across the corporate network rather than inspecting SaaS data at rest via API.

Cisco Umbrella

Why it fails: Cisco Umbrella enforces DNS-layer and secure web gateway controls on requests leaving the network; it does not use SaaS APIs to inspect stored data. It is tempting because it blocks unsanctioned SaaS access, and it would be correct if the requirement were blocking or allowing SaaS destinations by DNS and URL.

User Behavior Analytics

Why it fails: User Behavior Analytics flags anomalous user activity patterns, not data content, so it cannot detect credit card numbers in shared files. It is tempting because it addresses insider risk, but content matching for publicly shared card data belongs to the Data Loss Prevention policy category.

Application Firewall

Why it fails: Application Firewall governs inline traffic to sanctioned cloud applications; it does not inspect stored Salesforce content for card numbers. It is tempting because it protects cloud apps, but detecting publicly shared credit card data requires the Data Loss Prevention category, which scans content rather than network sessions.

Threat Intelligence

Why it fails: Credit card numbers shared publicly is data-loss prevention content matching, not threat intelligence, which correlates indicators of compromise and malicious IPs or domains. It would be the right category for detecting command-and-control callbacks or known-bad file hashes, not for classifying regulated data types.

SNMP monitoring

Why it fails: SNMP monitoring polls device metrics and traps; it carries no user identity or authentication exchange, so it cannot secure sign-in between Umbrella and a SaaS application. It is tempting because SNMP is a familiar Cisco management protocol, and it would be the right choice for collecting appliance health statistics instead.

Local LDAP database

Why it fails: A local LDAP database stores directory entries on-premises and is not reachable by a cloud SaaS provider for federated sign-in; Umbrella integrates through SAML or OIDC against a cloud identity provider. LDAP suits internal application authentication within the corporate network, not SaaS federation.

WPA2-Enterprise

Why it fails: WPA2-Enterprise authenticates devices to wireless networks via 802.1X and RADIUS; it plays no part in SaaS authentication, which occurs over HTTPS through SAML or OIDC. It is the right choice for securing Wi-Fi access, not for federating identities into a cloud application.