Which two initial actions should be taken when exploring automation capabilities for ACI? (Choose two)

Question

Options

• AWrite scripts that leverage the Python Standard Library
• BLook for an open-source package or SDK
• CUse the API Inspector and test API Calls
• DDevelop an open-source package or SDK
• EUse the ncclient command to explore the NETCONF capabilities

• A
  4% (1)
• B
  93% (25)
• C
  4% (1)

Explanation

Looking for an open-source package or SDK (B) and using the API Inspector to test API calls (C) are the two correct initial actions - the stated answer of only "B" appears incomplete for a "choose two" question.

Why B and C are correct: When first exploring ACI automation, you should leverage what already exists rather than building from scratch. Cisco's APIC has a rich ecosystem including the Cobra SDK and open-source packages (B). Equally important is using the API Inspector built into the APIC GUI (C), which captures live REST API calls as you navigate the UI - giving you real, working API calls to reverse-engineer and automate immediately.

Why the distractors are wrong:

• A - Writing raw scripts against the Python Standard Library skips existing, purpose-built SDKs; it's reinventing the wheel.
• D - Developing an open-source SDK is a contribution activity, not an exploration step - and premature before you understand what already exists.
• E - ncclient targets NETCONF, which is not ACI/APIC's primary interface; ACI is REST/JSON-centric, so this is the wrong protocol to start with.

Memory tip: Think "Borrow before you Build" - first look for existing tools (B) and observe the API in action via the Inspector (C) before writing a single line of code. The API Inspector is your cheat sheet hidden inside the APIC GUI.

No community discussion yet for this question.