Cisco CCNP 350-401 ENCOR EEM and Agent-Based vs Agentless Orchestration Practice Test 1

 

Topic 20 Practice Test 1 covers EEM and Agent-Based vs Agentless Orchestration for Cisco 350-401 ENCOR. For broader exam preparation, review the Cisco 350-401 ENCOR Exam Dumps. Every option includes focused technical reasoning explaining both the Cisco enterprise networking concept and its fit to the scenario.

Question 1

An engineer wants one EEM applet to trigger when a specific syslog message appears and then save the configuration, write an audit message, and run a verification command. Which design is valid?

1. Use one syslog event detector with multiple ordered action commands
2. Use a watchdog timer instead of the syslog event detector
3. Configure three event commands in the same applet, one for each action
4. Use three unrelated applets with identical syslog patterns and no ordering control

Correct Answer(s)

 

A

Rationale

1. The trigger is one syslog condition, while the requested follow-up work is a sequence of actions. An EEM applet registers a single event specification and can execute multiple actions after that event fires. The three post-event operations belong in the action list rather than in separate event statements.
2. A watchdog timer triggers on elapsed time, not on the appearance of the specific log message. It would run even when the fault did not occur and could miss the requirement for event-driven remediation. The trigger is one syslog condition, while the requested follow-up work is a sequence of actions.
3. The trigger is one syslog condition, while the requested follow-up work is a sequence of actions. An applet is not a list of independent event definitions. Cisco EEM applet syntax allows one event command; the save, audit, and verification steps are actions, so adding multiple event commands would not model the requested workflow.
4. Separate applets can all match the message, but their relative execution is not the ordered transaction the requirement calls for. It also duplicates the trigger definition and makes the sequence harder to reason about. The trigger is one syslog condition, while the requested follow-up work is a sequence of actions.

 

Question 2

A change-control team wants an EEM applet that never fires automatically. An operator must explicitly launch it during a maintenance window. What should the applet use?

1. Use a one-second watchdog timer and disable it after each use
2. Match a generic syslog pattern that operators generate before maintenance
3. Create the applet without any event statement
4. Register the applet with event none and invoke it manually with event manager run

Correct Answer(s)

 

D

Rationale

1. A watchdog timer is inherently automatic and periodic. Even if the operator later disables it, the design creates an unnecessary chance of execution outside the maintenance window. The key requirement is explicit operator initiation with no autonomous trigger. For “change control team wants”, Register the applet with event none is the relevant mechanism instead.
2. The key requirement is explicit operator initiation with no autonomous trigger. Using a synthetic log line as a manual trigger couples the workflow to logging behavior and may match accidentally. EEM provides a direct manual-registration mechanism, so this indirection is unnecessary.
3. An EEM applet needs a valid registration event to be runnable as a policy. `event none` is the explicit mechanism for a manually triggered applet, rather than omitting event registration altogether. The key requirement is explicit operator initiation with no autonomous trigger.
4. The key requirement is explicit operator initiation with no autonomous trigger. The `event none` detector marks an EEM policy for manual execution. The operator can then run the named policy explicitly, which keeps it dormant until change control authorizes the action. Because of “change control team wants”, Register the applet with event none is the appropriate design choice.

 

Question 3

An EEM applet uses action labels 1.0, 2.0, and 10.0. Testing shows the action labeled 10.0 runs before 2.0. What is the best correction?

1. Renumber the labels with zero padding such as 01.0, 02.0, and 10.0
2. Move the action commands into three separate syslog event detectors
3. Change the event detector from syslog to SNMP
4. Increase the applet maxrun timer

Correct Answer(s)

 

A

Rationale

1. The observed behavior is caused by EEM label sorting, not by the event source or execution timeout. EEM sorts action labels alphanumerically rather than numerically. Zero padding makes the lexical order match the intended numeric sequence, so the second action cannot be displaced behind a label beginning with `1`.
2. An applet supports one event command, and splitting actions into event detectors confuses triggers with execution steps. It would not establish deterministic action ordering. The observed behavior is caused by EEM label sorting, not by the event source or execution timeout.
3. The observed behavior is caused by EEM label sorting, not by the event source or execution timeout. The detector type determines when the applet starts, not how action labels are sorted once it runs. The issue is the lexical label sequence.
4. A longer runtime does not change the ordering algorithm. The unexpected sequence happens before timeout handling is relevant, so increasing runtime only masks a different class of problem. The observed behavior is caused by EEM label sorting, not by the event source or execution timeout.

 

Question 4

Several EEM applets must use the same maintenance-server address, and operations wants to change that value in one place. Which mechanism best fits?

1. Use the action label as the server address
2. Hard-code the server address separately in every action
3. Define an EEM environment variable and reference it from the applets
4. Store the address in the syslog message that triggers each applet

Correct Answer(s)

 

C

Rationale

1. Action labels control execution order and are not a general-purpose variable mechanism. Repurposing them would neither expose the value to actions nor provide a maintainable configuration object. The value is configuration shared by multiple policies, so it should be externalized from individual action strings.
2. The value is configuration shared by multiple policies, so it should be externalized from individual action strings. Hard-coding works initially but creates configuration drift and repetitive changes. The requirement specifically asks for one centrally maintained value shared across policies. Here “several eem applets use” calls for Define an EEM environment variable, not this alternative.
3. EEM environment variables provide reusable values that policies can reference. Centralizing the address avoids editing each applet when the server changes and makes the shared dependency explicit. The value is configuration shared by multiple policies, so it should be externalized from individual action strings.
4. The value is configuration shared by multiple policies, so it should be externalized from individual action strings. The event text is an input condition, not a reliable configuration store. Depending on log content for a stable server address couples automation to message formatting and weakens change control.

 

Question 5

A team creates custom EEM environment variables named `_site`, `_peer`, and `_owner`. Why should the naming convention be changed?

1. Leading underscores cause every variable to be encrypted
2. Leading underscores force the applet to run with privilege 15
3. Leading underscores make the variable available only to Tcl policies
4. Avoid leading underscores for customer-defined variables because Cisco reserves that convention for EEM variables

Correct Answer(s)

 

D

Rationale

1. The risk is namespace collision with EEM-provided variables rather than runtime behavior. The underscore is a naming convention, not an encryption control. It does not automatically protect variable contents or change how the value is stored. For “team creates custom eem”, Avoid leading underscores for customer-defined variables because Cisco reserves that convention for EEM is the relevant mechanism instead.
2. Variable names do not determine EEM CLI privilege. Privilege and AAA behavior are handled by the EEM session and authorization configuration. The risk is namespace collision with EEM-provided variables rather than runtime behavior. Here “team creates custom eem” calls for Avoid leading underscores for customer-defined variables because Cisco reserves that convention for EEM, not this alternative.
3. The risk is namespace collision with EEM-provided variables rather than runtime behavior. The naming convention is not a scope boundary between applets and Tcl policies. The concern is collision with Cisco-defined variables, not policy-language visibility. Under “team creates custom eem”, Avoid leading underscores for customer-defined variables because Cisco reserves that convention for EEM is required here; this alternative is not.
4. Cisco EEM documentation uses the leading underscore convention for EEM-provided environment variables and advises customers not to create new variables beginning with `_`. Choosing a distinct local prefix reduces future name collisions. The risk is namespace collision with EEM-provided variables rather than runtime behavior.

 

Question 6

A router should launch a local remediation only when syslog reports a specific interface-down signature. Which EEM trigger is most direct?

1. Use a watchdog timer that runs the remediation every minute
2. Use an environment variable as the event detector
3. Use an EEM syslog event detector with a regular-expression pattern matching that signature
4. Use event none and wait for an administrator to notice the message

Correct Answer(s)

 

C

Rationale

1. A timer polls by schedule and can execute when the fault is absent. It also introduces unnecessary delay or repeated actions instead of responding to the actual syslog event. The device already emits the exact fault signal as syslog, so matching that event avoids polling.
2. The device already emits the exact fault signal as syslog, so matching that event avoids polling. Environment variables supply reusable data to policies; they do not themselves register an event. A detector is still required to tell EEM when to start the applet.
3. The syslog event detector is designed to register a policy against matching log messages. A focused pattern lets the applet react to the exact operational signal without polling unrelated state. The device already emits the exact fault signal as syslog, so matching that event avoids polling.
4. The device already emits the exact fault signal as syslog, so matching that event avoids polling. Manual execution defeats the requirement for automatic reaction. `event none` is useful for operator-triggered policies, not for immediate response to a log event. Because of “router launch local remediation”, an EEM syslog event detector with a regular-expression pattern matching that signature better fits the design requirement.

 

Question 7

An EEM CLI action issues a command that prompts for confirmation. The applet hangs until its runtime expires. What should the engineer add?

1. Rename the action label with a leading underscore
2. Increase syslog severity so the command is accepted
3. Use the CLI action pattern option to match the expected prompt and then send the required response
4. Convert the trigger to event none

Correct Answer(s)

 

C

Rationale

1. The failure happens at an interactive command prompt, so the action must recognize that prompt. Action labels affect ordering, and leading underscores are not a prompt-handling mechanism. The action needs an explicit expected-prompt pattern. For “eem cli action issues”, the CLI action pattern option to match the expected prompt is the relevant mechanism instead.
2. Syslog severity has no relationship to an interactive CLI prompt. The command is already being issued; the problem is that EEM is waiting for input. The failure happens at an interactive command prompt, so the action must recognize that prompt. Here “eem cli action issues” calls for the CLI action pattern option to match the expected prompt, not this alternative.
3. The failure happens at an interactive command prompt, so the action must recognize that prompt. Interactive commands can wait for input after EEM sends the command. The `pattern` option tells the CLI action what prompt to expect so the policy can continue with the response rather than waiting indefinitely.
4. Changing how the policy is triggered does not resolve the interactive command exchange. The hang occurs during an action after the applet has already started. The failure happens at an interactive command prompt, so the action must recognize that prompt. Because of “eem cli action issues”, the CLI action pattern option to match the expected prompt better fits the design requirement.

 

Question 8

AAA command authorization is enabled. EEM CLI actions are being rejected because there is no authorized identity associated with the automated CLI session. What is the appropriate control?

1. Disable AAA globally whenever EEM runs
2. Add the username as an EEM environment variable only
3. Change the trigger to an SNMP event
4. Associate an authorized username and privilege with EEM CLI sessions using event manager session cli username

Correct Answer(s)

 

D

Rationale

1. Turning off AAA removes a security control far beyond the failing applet and creates an unacceptable management-plane gap. EEM supports an authenticated session identity instead. The policy already triggers correctly; the missing piece is the identity under which its CLI actions are authorized.
2. The policy already triggers correctly; the missing piece is the identity under which its CLI actions are authorized. A variable can hold text, but it does not establish the AAA identity of the CLI session. The session-specific command is what binds EEM CLI execution to a username.
3. The event detector does not supply CLI authorization. AAA evaluates the session used by the actions after any supported detector has fired. The policy already triggers correctly; the missing piece is the identity under which its CLI actions are authorized. Under “aaa command authorization enabled”, Associate an authorized username is required here; this alternative is not.
4. The policy already triggers correctly; the missing piece is the identity under which its CLI actions are authorized. Cisco IOS XE can associate a username and privilege level with EEM CLI sessions. That gives AAA a defined identity to evaluate when the applet executes CLI actions.

 

Question 9

A proposed EEM applet uses `authorization bypass` simply to avoid fixing a TACACS+ authorization policy. What is the best design response?

1. Remove the EEM username so TACACS+ cannot identify the session
2. Move the same commands into a watchdog timer
3. Keep normal authorization and correct the AAA policy unless a documented exception specifically requires bypass
4. Use authorization bypass on all EEM applets for consistency

Correct Answer(s)

 

C

Rationale

1. The requirement is to preserve least privilege and auditability while allowing the automation to run. An anonymous or ambiguous session makes authorization and auditability worse, not better. The right fix is a defined service identity and an appropriate command policy. For “proposed eem applet uses”, normal authorization and correct the AAA policy unless a documented exception specifically requires is the relevant mechanism instead.
2. Changing the event detector does not address authorization. The commands would still execute under the same management-plane policy. The requirement is to preserve least privilege and auditability while allowing the automation to run. Here “proposed eem applet uses” calls for normal authorization and correct the AAA policy unless a documented exception specifically requires, not this alternative.
3. The requirement is to preserve least privilege and auditability while allowing the automation to run. Authorization bypass exists, but using it to sidestep an ordinary policy error weakens the control plane. The safer design is to give the EEM identity only the commands it legitimately needs and retain auditable authorization.
4. Applying bypass broadly expands privilege and defeats centralized command authorization. Consistency is not a security justification for disabling a control. The requirement is to preserve least privilege and auditability while allowing the automation to run. Because of “proposed eem applet uses”, normal authorization and correct the AAA policy unless a documented exception specifically requires better fits the design requirement.

 

Question 10

A policy must parse several values, branch through multiple conditions, maintain variables, and perform error handling that has become unwieldy in a CLI applet. What is the better EEM implementation?

1. Use only syslog actions and perform the logic manually later
2. Add more unrelated event commands to the same applet
3. Replace the policy with a static route-map
4. Use an EEM Tcl policy for the complex logic

Correct Answer(s)

 

D

Rationale

1. That removes the automated remediation the policy was created to provide. The requested branching and error handling are precisely why a scripted EEM policy is appropriate. The workflow complexity has exceeded what is maintainable as a simple CLI applet. For “policy parse several values”, an EEM Tcl policy for the complex logic is the relevant mechanism instead.
2. The workflow complexity has exceeded what is maintainable as a simple CLI applet. An EEM applet permits one event command, and additional event statements would not solve the complexity of the action logic. The problem is policy expressiveness, not event registration.
3. A route-map evaluates routing or policy conditions; it is not an event-driven scripting environment and cannot implement the described operational workflow. The workflow complexity has exceeded what is maintainable as a simple CLI applet. Under “policy parse several values”, an EEM Tcl policy for the complex logic is required here; this alternative is not.
4. The workflow complexity has exceeded what is maintainable as a simple CLI applet. Cisco EEM supports both CLI applets and Tcl policies. Tcl is the more appropriate form when the workflow needs richer control flow, parsing, and error handling than a compact applet can maintain cleanly.

 

Question 11

A device must run a lightweight health check every five minutes regardless of whether a log message appears. Which EEM event type best matches?

1. Use a timer watchdog event with the required interval
2. Use event syslog with a broad pattern that matches normal traffic
3. Use event none
4. Use an EEM environment variable containing the number 300

Correct Answer(s)

 

A

Rationale

1. The requirement is periodic execution independent of faults or operator input. A watchdog timer is intended for recurring time-based execution. It schedules the policy at the configured interval without relying on an external fault message. For “device run lightweight health”, the relevant mechanism is a timer watchdog event with the required interval.
2. A syslog trigger depends on message production, so its timing is neither guaranteed nor tied to the five-minute requirement. It can also fire multiple times unexpectedly. The requirement is periodic execution independent of faults or operator input. Here “device run lightweight health” calls for a timer watchdog event with the required interval, not this alternative.
3. The requirement is periodic execution independent of faults or operator input. `event none` registers a manually launched policy. It will not execute every five minutes unless an external operator or process repeatedly starts it. Under “device run lightweight health”, a timer watchdog event with the required interval is required here; this alternative is not.
4. An environment variable can store the interval value for reuse, but it is not itself a scheduling detector. A timer event still must register the periodic trigger. The requirement is periodic execution independent of faults or operator input. Because of “device run lightweight health”, a timer watchdog event with the required interval better fits the design requirement.

 

Question 12

A branch loses WAN connectivity to its automation controller. The design still requires the router to react immediately to a local syslog event by shutting a flapping test interface. Which approach preserves that behavior?

1. Use a centralized inventory file as the trigger
2. Rely on a nightly configuration compliance job
3. Keep the event-driven remediation as an on-device EEM policy
4. Move the reaction exclusively to an agentless controller across the WAN

Correct Answer(s)

 

C

Rationale

1. Inventory describes managed targets; it does not execute a local reaction or remain event-aware when the controller is unreachable. The distinguishing constraint is that the corrective action must still occur while the central automation path is unavailable. For “branch loses wan connectivity”, the event-driven remediation as an on-device EEM policy is the relevant mechanism instead.
2. The distinguishing constraint is that the corrective action must still occur while the central automation path is unavailable. A scheduled compliance pass is too slow for the immediate fault response and may not have connectivity to the branch during the incident.
3. EEM executes on the network device and can respond to local events without reaching a central controller. That makes it suitable for narrowly scoped local reactions that must survive management-plane isolation. The distinguishing constraint is that the corrective action must still occur while the central automation path is unavailable.
4. The distinguishing constraint is that the corrective action must still occur while the central automation path is unavailable. An off-box agentless controller depends on management reachability. During the WAN outage it cannot receive the signal or push the corrective command to the branch.

 

Question 13

A company needs to push an approved NTP change to 2,000 devices, record per-device results, retry failures, and keep the workflow in source control. Which approach is more appropriate than separate EEM applets on every box?

1. Use centralized orchestration/configuration management for the fleet-wide change
2. Use event none and ask administrators to run the applet manually on each device
3. Create an identical EEM syslog trigger on all 2,000 devices
4. Use a watchdog applet on every device with no controller

Correct Answer(s)

 

A

Rationale

1. The work is a coordinated, auditable fleet change rather than a local event response. Fleet-wide state, inventory, retries, reporting, and version-controlled workflows are strengths of centralized orchestration. EEM is better suited to device-local event handling than to coordinating a large multi-device rollout.
2. Manual launch across thousands of devices is precisely the operational burden orchestration is intended to remove and creates inconsistent execution timing. The work is a coordinated, auditable fleet change rather than a local event response. Here “company needs push approved” calls for centralized orchestration/configuration management for the fleet-wide change, not this alternative.
3. The work is a coordinated, auditable fleet change rather than a local event response. Duplicating local policies does not provide centralized inventory, ordered rollout, aggregate result tracking, or retry coordination. It also makes changing the workflow itself a distributed configuration task. Under “company needs push approved”, centralized orchestration/configuration management for the fleet-wide change is required here; this alternative is not.
4. Periodic local execution still lacks the central change record, per-device workflow state, and coordinated retry logic required by the rollout. The work is a coordinated, auditable fleet change rather than a local event response. Because of “company needs push approved”, centralized orchestration/configuration management for the fleet-wide change better fits the design requirement.

 

Question 14

Operations wants to use Ansible against supported Cisco devices but cannot install persistent orchestration software on those network nodes. Why can Ansible still fit?

1. Ansible automatically installs a hidden permanent agent on every switch
2. Ansible is agentless and can use supported remote management interfaces such as SSH or APIs
3. Ansible works only when EEM launches the playbook locally
4. Agentless means the target needs no reachable management interface

Correct Answer(s)

 

B

Rationale

1. That contradicts the agentless architecture. Modules and connection plugins use supported remote interfaces rather than requiring an always-running Ansible daemon on each managed network device. The constraint prohibits installed target software, not remote management connectivity. For “operations wants use ansible”, Ansible is agentless and can use supported remote management interfaces such as SSH is the relevant mechanism instead.
2. The constraint prohibits installed target software, not remote management connectivity. Agentless orchestration runs its control logic off-box and connects to targets through management interfaces. The devices do not need a persistent Ansible agent installed solely to participate in the workflow. Here “operations wants use ansible” directly calls for Ansible is agentless and can use supported remote management interfaces such as SSH.
3. EEM is not required for normal Ansible control-node execution. Ansible can manage targets directly from the automation system when management connectivity and credentials are available. The constraint prohibits installed target software, not remote management connectivity. Under “operations wants use ansible”, Ansible is agentless and can use supported remote management interfaces such as SSH is required here; this alternative is not.
4. The constraint prohibits installed target software, not remote management connectivity. Agentless removes the installed-agent requirement, not the need for communication. The controller still requires a supported path such as SSH, NETCONF, RESTCONF, or another API. Because of “operations wants use ansible”, Ansible is agentless and can use supported remote management interfaces such as SSH better fits the design requirement.

 

Question 15

An agentless playbook succeeds in the lab but fails at a remote site after a firewall change. The target has no local agent, and the controller can no longer reach SSH or NETCONF. What should be checked first?

1. Add an EEM environment variable with the controller IP
2. Restore the supported management path from the control node to the target
3. Disable AAA on the switch
4. Reinstall the Ansible agent on the switch

Correct Answer(s)

 

B

Rationale

1. The failure appeared exactly when the remote management protocols became unreachable. Storing an address locally does not open the blocked firewall path or cause the control node to regain a usable protocol session. For “agentless playbook succeeds lab”, Restore the supported management path from the control node to the target is the relevant mechanism instead.
2. Agentless orchestration depends on remote connectivity to a management interface. If SSH/NETCONF is blocked, the controller cannot deliver modules or RPCs even though no resident agent needs repair. The failure appeared exactly when the remote management protocols became unreachable. Here “agentless playbook succeeds lab” directly calls for Restore the supported management path from the control node to the target.
3. The failure appeared exactly when the remote management protocols became unreachable. AAA may affect authentication after a connection is established, but the stated failure is that the controller cannot reach the management protocols at all. Removing AAA is also an excessive security change. Under “agentless playbook succeeds lab”, Restore the supported management path from the control node to the target is required here; this alternative is not.
4. There is no persistent Ansible agent to reinstall in the described architecture. The failure aligns with lost remote management reachability. The failure appeared exactly when the remote management protocols became unreachable. Because of “agentless playbook succeeds lab”, Restore the supported management path from the control node to the target better fits the design requirement.

 

Question 16

A proposed automation platform requires a resident agent on every target. The network team has thousands of appliances with strict software-certification windows. Which trade-off should be highlighted?

1. Agent-based orchestration cannot perform local actions
2. Agent-based orchestration eliminates all target-side software maintenance
3. Agent-based orchestration never needs credentials or authorization
4. Agent-based orchestration adds agent deployment, compatibility, patching, and lifecycle overhead on each target

Correct Answer(s)

 

D

Rationale

1. A resident component may in fact support local action or telemetry. The concern here is not capability but the cost of maintaining that component on every managed system. The organization is constrained by per-device software qualification and maintenance windows. For “proposed automation platform requires”, Agent-based orchestration adds agent deployment, compatibility, patching is the relevant mechanism instead.
2. The organization is constrained by per-device software qualification and maintenance windows. It does the opposite: the agent itself becomes target-side software with a lifecycle. The statement ignores the exact certification constraint in the scenario. Here “proposed automation platform requires” calls for Agent-based orchestration adds agent deployment, compatibility, patching, not this alternative.
3. An installed agent still operates under a security model and needs permissions to perform changes. Deployment style does not remove authentication, authorization, or secret-management requirements. The organization is constrained by per-device software qualification and maintenance windows. Under “proposed automation platform requires”, Agent-based orchestration adds agent deployment, compatibility, patching is required here; this alternative is not.
4. The organization is constrained by per-device software qualification and maintenance windows. A resident agent can provide local capabilities, but it becomes another software component to qualify, upgrade, secure, and monitor across the fleet. That operational overhead is central when device software changes are tightly controlled.

 

Question 17

A set of network appliances exposes a supported SSH/API interface but does not allow third-party software installation. Which orchestration characteristic is most advantageous?

1. Require an agent so the controller does not need network reachability
2. Use an agentless tool that manages the devices through their existing supported interfaces
3. Use only manual CLI because automation always requires an installed agent
4. Run EEM solely to emulate an orchestration server on each device

Correct Answer(s)

 

B

Rationale

1. The devices are manageable remotely but cannot accept extra resident software. An agent requirement conflicts with the platform restriction, and most agent models still need communication with a controller or service. For “set network appliances exposes”, an agentless tool that manages the devices through their existing supported interfaces is the relevant mechanism instead.
2. Agentless automation avoids installing a resident component and can work with devices that expose remote management protocols. That directly matches platforms where the software image cannot host or certify an external agent. The devices are manageable remotely but cannot accept extra resident software. Here “set network appliances exposes” directly calls for an agentless tool that manages the devices through their existing supported interfaces.
3. The devices are manageable remotely but cannot accept extra resident software. Remote orchestration can use SSH or APIs without a resident agent, so the lack of installable software does not force the team back to manual configuration. Under “set network appliances exposes”, an agentless tool that manages the devices through their existing supported interfaces is required here; this alternative is not.
4. EEM can automate local events but does not replace centralized inventory, workflow coordination, or source-controlled multi-device orchestration. The devices are manageable remotely but cannot accept extra resident software. It would also force device-local policy maintenance for changes that belong in the controller workflow.

 

Question 18

An agentless orchestration job needs to choose which routers receive a change and use different credentials for lab and production. Where should that targeting context primarily live?

1. Maintain inventory and credential references on the orchestration/control side rather than installing target agents for that purpose
2. Store production passwords directly inside every playbook task
3. Install a resident agent only to remember which environment the device belongs to
4. Encode the entire fleet inventory as EEM environment variables on every router

Correct Answer(s)

 

A

Rationale

1. Agentless tools keep workflow logic and target inventory off-box, then connect to selected devices through supported management interfaces. Separating inventory and secrets from target software is consistent with the agentless operating model. The information is controller workflow state, not a device-local runtime dependency.
2. The information is controller workflow state, not a device-local runtime dependency. Hard-coded secrets create exposure and complicate rotation. The need for environment-specific credentials calls for controlled secret references, not embedding passwords in task text. Here “agentless orchestration job needs” calls for inventory and credential references on the orchestration/control side rather than installing target agents, not this alternative.
3. The environment can be represented in controller-side inventory/groups. Adding target software solely for classification defeats the simplicity that agentless orchestration provides. The information is controller workflow state, not a device-local runtime dependency. Under “agentless orchestration job needs”, inventory and credential references on the orchestration/control side rather than installing target agents is required here; this alternative is not.
4. The information is controller workflow state, not a device-local runtime dependency. That duplicates central orchestration state across all targets and creates drift. EEM variables are useful for local policies, not as a distributed master inventory. Because of “agentless orchestration job needs”, inventory and credential references on the orchestration/control side rather than installing target agents better fits the design requirement.

 

Question 19

An EEM policy performs a corrective CLI command. Operations also wants an explicit local audit breadcrumb whenever the policy runs. Which additional action directly provides that?

1. Replace the corrective command with an environment variable
2. Add an EEM action syslog message describing the remediation
3. Add a second event syslog statement after the CLI action
4. Rename the applet so the name appears automatically in all remote logs

Correct Answer(s)

 

B

Rationale

1. The requested evidence is a deliberate log record generated as part of execution. Variables store values; they do not log policy execution. The requirement is evidence that the action occurred. A variable also does not create a timestamped remediation event for downstream log collectors.
2. EEM can emit a syslog message as an action. Recording a specific remediation message creates a local and potentially centrally collected audit breadcrumb without changing the triggering condition. The requested evidence is a deliberate log record generated as part of execution. Here “eem policy performs corrective” directly calls for Add an EEM action syslog message describing the remediation.
3. The requested evidence is a deliberate log record generated as part of execution. Events are triggers, not post-action records, and an applet supports a single event command. The audit entry belongs in the action list. Under “eem policy performs corrective”, Add an EEM action syslog message describing the remediation is required here; this alternative is not.
4. A descriptive name helps configuration readability but does not guarantee that an explicit audit message is emitted when the corrective action executes. The requested evidence is a deliberate log record generated as part of execution. Because of “eem policy performs corrective”, Add an EEM action syslog message describing the remediation better fits the design requirement.

 

Question 20

A policy must react when a monitored SNMP object crosses a defined threshold, not when a log string is generated. Which EEM mechanism best matches?

1. Use a syslog event detector with no pattern
2. Use an EEM SNMP event detector configured for the relevant OID and comparison condition
3. Use event none and have an operator query the OID
4. Use an action snmp command as the trigger

Correct Answer(s)

 

B

Rationale

1. A syslog detector observes messages, not arbitrary MIB values. Without a message representing the threshold, it does not evaluate the required SNMP object. The condition exists as an SNMP-managed value rather than a log event. For “policy react monitored snmp”, an EEM SNMP event detector configured for the relevant OID is the relevant mechanism instead.
2. The condition exists as an SNMP-managed value rather than a log event. The SNMP detector can poll or evaluate a specified object and trigger when its configured condition is met. That lets the policy respond to the measured state directly rather than waiting for a separate syslog translation.
3. Manual execution removes automatic threshold response and defeats the event-driven requirement. The condition exists as an SNMP-managed value rather than a log event. An operator could therefore miss the crossing or react well after the threshold was exceeded. Under “policy react monitored snmp”, an EEM SNMP event detector configured for the relevant OID is required here; this alternative is not.
4. The condition exists as an SNMP-managed value rather than a log event. Actions execute after a policy has been triggered. The SNMP condition belongs in the event detector, not in the post-event action phase. Because of “policy react monitored snmp”, an EEM SNMP event detector configured for the relevant OID better fits the design requirement.

• < Cisco CCNP 350-401 ENCOR Python, JSON, YANG, Catalyst Center/SD-WAN APIs, and REST Results Practice Test 3
• Cisco CCNP 350-401 ENCOR EEM and Agent-Based vs Agentless Orchestration Practice Test 2 >