Performing CyberOps Using Cisco Security Technologies — Free Practice Questions
10 free sample questions from a bank of 174, with the correct answers and explanations. No signup required — start practising right now.
- Assign the issue to the incident handling provider because no suspicious activity has been observed during business hours.
- Review the SIEM and FirePower logs, block all traffic, and document the results of calling the call center.
- Define the access points using StealthWatch or SIEM logs, understand services being offered during the hours in question and cross-correlate other source events.
- Treat it as a false positive, and accept the SIEM issue as valid to avoid alerts from triggering on weekends.
The short version
C — Triage off-hours foreign traffic with StealthWatch and SIEM correlation. Scope, services, and cross-source events come before blocking.
Key concepts in this question
- Anomaly triage: recurrent off-hours spikes from out-of-area sources need scoping.
- StealthWatch and SIEM: flow telemetry plus event correlation identify access points and services.
- Measured response: understand exposure before broad blocks or dismissals.
Why C is correct
A repeating Sunday-night load from outside the service area warrants defining affected access points in StealthWatch or SIEM logs, identifying what services listen during that window, and cross-correlating other events. That disciplined triage distinguishes backup traffic, misconfiguration, or compromise from noise. Immediate full blocking, outsourcing without analysis, or accepting it as a false positive skips that required scoping.
Why the others are wrong
- A. Handing off solely because it occurs off-hours abdicates analysis and misses potential compromise.
- B. Blocking all traffic and calling the call center is disproportionate and destroys evidence before scoping.
- D. Treating a recurrent geo-anomalous pattern as a false positive hides a possible incident and weakens detection.
350-201 exam tip
Odd-hours plus odd-places means scope with flows and SIEM first, block or close later.
- Seeds for existing domains are checked
- A search is conducted for additional seeds
- Domains are compared to seed rules
- A list of domains as seeds is blocked
The short version
C — Domains are compared to seed rules. The script generates candidate domains and tests each banked seed against them.
Key concepts in this question
- Banjori DGA logic:
next_domain+isBanjoriTailgenerate and check domains. - Seed comparison:
seed.startswith(domain)tests seeds against generated names. - Result loop:
for seed in seeds: print seed,isBanjoriTail(seed)outputs comparison results.
Why C is correct
The exhibit defines map_to_lowercase_letter, next_domain, and isBanjoriTail(seed) looping c0-c3 to build domain = chr(c0)+chr(c1)+chr(c2)+chr(c3) then next_domain(domain), returning False on seed.startswith(domain) match. The final loop iterates the hard-coded seeds set and prints each seed with its check result, which is a comparison of domains to seed rules.
Why the others are wrong
- A. No check of seeds for existing registered domains is shown; it checks generated DGA candidates.
- B. No search for additional new seeds is conducted; the seed list is fixed.
- D. Nothing is blocked; the script only prints comparison results.
350-201 exam tip
DGA + hard-coded seed list + startswith check = compare/match verdict, not block.
- Implement a new workflow for SOAR to fetch a report of assets that are outside of the PKI zone, sort assets by certification management leads and automate alerts that updates are needed.
- Integrate a SOAR solution with Active Directory to pull server owner details from the AD and send an automated email for problematic certificates requesting updates.
- Implement a new workflow within SOAR to create tickets in the incident response system, assign problematic certificate update requests to server owners, and register change requests.
- Integrate a PKI solution within SOAR to create certificates within the SOAR engines to track, update, and monitor problematic certificates.
The short version
A — Automate discovery and owner-routed alerts for non-PKI certificates. Report, sort, and alert closes the manual tracking gap.
Key concepts in this question
- Certificate sprawl: endpoints outside PKI management expire unnoticed.
- SOAR workflow: scheduled fetch, enrichment, and alerting automation.
- Owner mapping: routing by management lead replaces manual server-owner hunts.
Why A is correct
Fetching a report of assets outside the PKI zone, sorting by certification management leads, and automating update alerts directly fixes the stated pain of manually finding owners. It extends lifecycle visibility beyond managed PKI without re-architecting issuance, making tracking continuous. AD-only emailing, generic ticketing, or building a parallel CA inside SOAR do not target the out-of-zone discovery gap as precisely.
Why the others are wrong
- B. Pulling owners from AD and emailing helps notification, but misses scheduled out-of-zone discovery and lead-based routing.
- C. Creating IR tickets and change requests adds process without the asset-discovery and sorting automation needed.
- D. Issuing certificates from SOAR duplicates PKI function rather than tracking problematic external certificates.
350-201 exam tip
Outside-PKI blind spot means fetch, sort, and alert — discover first, then notify owners.
- Option A
- Option B
- Option C
- Option D
The short version
C — Iterate output dict by domain to get status. Only the for-loop extracting output[domain]["status"] feeds the -1/1/else verdict logic.
Key concepts in this question
- Umbrella Investigate response:
output = req.json()dict keyed by domain. - Status field:
domain_statusdrives MALICIOUS (-1) / CLEAN (1) / UNDEFINED else. - Python iteration: correct
for domain in domainslookup is required.
Why C is correct
The exhibit shows output = req.json() then a missing box before if(domain_status == -1): MALICIOUS / elif ==1: CLEAN / else: UNDEFINED. The only snippet that defines both domain_output = output[domain] and domain_status = domain_output["status"] inside a valid for domain in domains: loop is Option C, bridging the JSON response to the verdict prints.
Why the others are wrong
- A.
for domain in domains[]:is invalid syntax and never definesdomain_output. - B.
while domain in domains:never definesdomain_output, sodomain_statuscannot resolve. - D.
while domains in domains:is wrong loop logic and condition, not iterating keys.
350-201 exam tip
If verdict code checks -1/1/else, look for output[domain]["status"] in a for-loop.
- The extension is not performing as intended because of restrictions since ports 80 and 443 should be accessible
- The traffic is legitimate as the google chrome extension is reaching out to check for updates and fetches this information
- There is a possible data leak because payloads should be encoded as UTF-8 text
- There is a malware that is communicating via encrypted channels to the command and control server
The short version
D — Malware beaconing over encrypted WebSocket to C2. Masked WebSocket text with obfuscated payloads and direct IP connections indicates C2.
Key concepts in this question
- WebSocket MASKED payloads: client-to-server masking plus unreadable content.
- Direct IP connections: Chrome extension initiating off-site flows.
- STIX observation: encrypted channel to command and control.
Why D is correct
The exhibit Wireshark view filtered websocket.payload shows repeated WebSocket Text [FIN] [MASKED] segments to direct IPs with unreadable/obfuscated payload bytes in the pane. Combined with the stem's suspicious extension and unreadable off-site payloads, this indicates malware communicating via encrypted channels to its command and control server.
Why the others are wrong
- A. Ports 80/443 restriction is not the issue; WebSocket traffic is present.
- B. Direct-IP masked exfiltration with unreadable payloads is not legitimate update checks.
- C. UTF-8 encoding expectation does not explain masked obfuscated C2 payloads.
350-201 exam tip
MASKED + unreadable + direct IP = suspect encrypted C2, not updates.
- Update the cached header metadata.
- Confirm the resource's location.
- Increase the allowed user limit.
- Modify the session timeout setting.
The short version
B — A 301 means the resource moved permanently, so confirm its new location. Update references to the Location header URL.
Key concepts in this question
- 301 Moved Permanently: redirect status signaling a new canonical URL.
- Location header: authoritative new address for future requests.
- Cache and bookmark update: clients should use the new location going forward.
Why B is correct
HTTP 301 indicates the requested resource now resides at a different URI given in the Location header. The correct action is confirming that new location and directing subsequent requests there. It has no relation to user limits, session timeouts, or generic cache metadata, which would apply to other status or configuration issues.
Why the others are wrong
- A. Updating cached header metadata alone misses the required move to the advertised new URL.
- C. Increasing allowed user limits addresses capacity errors like 503, not a redirect.
- D. Modifying session timeout addresses authentication or idle-expiry behavior, not relocation.
350-201 exam tip
301 equals moved — follow the Location header and update the reference.
- Threat scores are high, malicious ransomware has been detected, and files have been modified
- Threat scores are low, malicious ransomware has been detected, and files have been modified
- Threat scores are high, malicious activity is detected, but files have not been modified
- Threat scores are low and no malicious file activity is detected
The short version
C — High threat scores with malicious activity but no file modification. EML artifact shows multiple malicious indicators without file-modification verdict.
Key concepts in this question
- Threat Grid behavioral indicators: severity/confidence per behavior.
- EML / SMTP artifact:
ee48240044e6236cb315ad7ed035bd77ad4014039ec9bfebc8f2.eml. - Malicious vs modified: activity detected does not equal files modified.
Why C is correct
The exhibit Analysis Report for Windows 7 64-bit shows high-severity behaviors: Email With Different Sender and Return-Path Severity 60, Document Contains Embedded Material Severity 50, Download Forced Open/Save Severity 50, Potential Code Injection Severity 50, plus command-line and disk-download indicators. This supports high threat scores and detected malicious activity, while no file-modified ransomware verdict is shown, matching high, malicious, but files not modified.
Why the others are wrong
- A. Ransomware with files modified is not shown; filename is .eml mail, not ransomware file-mod verdict.
- B. Scores are not low given multiple 50-60 severity indicators.
- D. No-malicious-activity contradicts the 60/50 severity detections.
350-201 exam tip
EML + 50-60 severity download/injection/email-spoof = malicious but not ransomware-modified.
- Contain the malware
- Install IPS software
- Determine the escalation path
- Perform vulnerability assessment
The short version
A — The team skipped containment before eradication and recovery. NIST requires isolating spread first.
Key concepts in this question
- NIST lifecycle: preparation, detection, containment, eradication, recovery, lessons learned.
- Containment: isolate hosts and block propagation before cleaning.
- Sequence matters: removing malware before containing risks reinfection and wider spread.
Why A is correct
Identifying, removing malware, restoring systems, and holding a lessons-learned meeting covers detection, eradication, recovery, and post-incident activity. The missing NIST phase is containment, short-term and long-term isolation to stop lateral movement before cleanup. Installing IPS, escalation paths, or vulnerability assessments are useful but are not the omitted lifecycle phase.
Why the others are wrong
- B. Installing IPS software is a protective control, not a NIST incident-handling phase.
- C. Determining escalation paths belongs to preparation, not the gap between eradication and recovery.
- D. Vulnerability assessment supports hardening, but NIST lists containment as the skipped step here.
350-201 exam tip
See identify, remove, restore, and review with no isolate — answer containment every time.
- SNMP
- syslog
- REST API
- pxGrid
The short version
D — pxGrid signaled ISE to quarantine. SMC with pxGrid agent plus pxGrid Controller to ISE shows pxGrid ANC path.
Key concepts in this question
- Stealthwatch SMC with pxGrid agent: threat source.
- pxGrid Controller to Cisco ISE: policy signaling path.
- Adaptive Network Control: quarantine VLAN enforcement on NAD/802.1x.
Why D is correct
The exhibit labels Stealthwatch Management Console (SMC) with pxGrid agent, pxGrid Controller, and Cisco ISE with dashed signaling lines from SMC/Controller to ISE, then ISE to NAD/802.1x Malware Infected Desktop for quarantine. That wired pxGrid path is the method used to signal ISE to place the 802.1x endpoint into quarantine via ANC.
Why the others are wrong
- A. No SNMP link is labeled; signaling is shown via pxGrid entities.
- B. No syslog path is labeled for quarantine signaling.
- C. No REST API link is labeled; exhibit names pxGrid agent and Controller.
350-201 exam tip
SMC + pxGrid agent + pxGrid Controller + ISE diagram = pxGrid quarantine.
- Analyze the applications and services running on the affected workstation.
- Compare workstation configuration and asset configuration policy to identify gaps.
- Inspect registry entries for recently executed files.
- Review audit logs for privilege escalation events.
The short version
C — After isolation, check registry for recently executed files. It links execution artifacts to the breach vector.
Key concepts in this question
- Order of volatility: isolate first, then examine persistent execution traces.
- Registry artifacts: UserAssist, Run keys, and Shimcache show what ran.
- Breach identification: executed-file timeline points to malware and entry point.
Why C is correct
With the workstation isolated to stop spread, the next investigative step is determining what executed, and registry entries for recently executed files directly reveal malware, droppers, or abused binaries. That execution timeline focuses later log, config, and process review. Broad service listing, policy comparison, or privilege-log review are valid later but do not first establish the execution cause.
Why the others are wrong
- A. Analyzing running apps and services is useful, but volatile state is secondary to execution artifacts for root cause.
- B. Comparing config to policy finds gaps, but does not identify what actually breached this host.
- D. Reviewing privilege-escalation logs matters only after knowing which file or process to trace.
350-201 exam tip
Isolated box plus what ran — go registry execution artifacts before broad log dives.
Want the full bank of 174 questions for Performing CyberOps Using Cisco Security Technologies? See all practice exams.