What are two characteristics of JavaScript macros for Cisco collaboration room devices? (Choose two.)

Question

Exhibit

Options

• AThe Macro console log messages are lost every time the runtime is restarted.
• BThe Macro console log supports severity levels.
• CThe Macro console log supports one macro at a time.
• DThe macros depend on each other to prevent overloading the system with listeners.
• EThe Macro Editor forbids saving macros if the macros have a compile error

• A
  94% (33)
• B
  3% (1)
• C
  3% (1)

Explanation

A is correct because Cisco macro runtime log messages exist only in memory - when the macro runtime restarts (triggered by enabling/disabling macros, device reboot, or code reload), all console log output is discarded. There is no persistent log storage, so debugging output is ephemeral.

E is correct because the Macro Editor performs compile-time validation and actively blocks saving a macro that contains a syntax or compile error. This is a deliberate safeguard to prevent broken scripts from being deployed to the device.

Why the distractors are wrong:

• B is false - the Macro console log has no severity level support (no debug/info/warn/error filtering); it's a flat console.log system.
• C is false - multiple macros can all write to the console simultaneously; there is no single-macro restriction.
• D is false - macros are designed to be independent of one another; interdependence is not a feature or requirement.

Memory tip: Think of two gatekeepers - the Editor guards the entrance (won't let bad code in) and the Runtime clears the room on restart (logs don't survive). "Save clean, log short" captures both truths.

No community discussion yet for this question.