Q16) REST pagination & rate limits (client behavior)
You’re consuming a Cisco platform REST API that documents pagination and rate limiting. What is the most robust client behavior?
A. Request the maximum page size and ignore all limit headers
B. Follow the server’s pagination mechanism and honor rate-limit guidance (retry/backoff)
C. Fan out concurrent requests to finish faster and retry 429s immediately
D. Switch to webhooks to automatically receive paginated results
Detailed Explanation:
DEVASC emphasizes designing clients that respect pagination and client-side rate limiting. Practically, you iterate through the API’s pagination mechanism (e.g., next-page tokens/links) and apply backoff/retry based on rate-limit guidance, rather than brute-force concurrency. This trades a bit of speed for reliability and avoids bans/timeouts.
Q17) Containers: isolation & resource control
Which Linux features primarily provide process isolation and resource control for Docker-style containers?
A. Type-1 hypervisors with separate guest kernels per container
B. Namespaces and cgroups, with layered images via a union file system
C. SNMP MIBs controlling host resources exposed to containers
D. Containers each run their own kernel, isolated from the host
Detailed Explanation:
The DEVASC guide outlines container underpinnings: namespaces (PID/net/mount/user/IPC, etc.) provide isolation, cgroups provide CPU/memory I/O control, and a union file system supports layered images. Containers share the host kernel; they are not full VMs.
Q18) Webex authentication pattern (headless service)
A back-end service (no user present) must post operational alerts into a Webex space. Which authentication pattern best fits?
A. OAuth Integration (authorization code grant)
B. Bot token
C. Personal Access Token from a developer’s account (production)
D. Guest Issuer for creating ephemeral guest users that post
Detailed Explanation:
For server-to-server posting, a Webex Bot is the standard approach. Integrations target user-consented apps; Personal Access Tokens are for testing, not production; Guest Issuer is for temporary guest identities, not general-purpose alert posting. The DEVASC guide lists these auth options explicitly (Personal Access Tokens, Integrations, Bots, Guest Issuer).
Q19) Hardening NTP for automation-friendly infra
Which NTP design aligns with DEVASC-recommended security and resiliency?
A. One upstream server; authentication disabled
B. At least three higher-stratum servers; enable encrypted auth; restrict associations via ACLs
C. Two random public servers; rely on unauthenticated broadcasts
D. Use SNMP time-of-day polling instead of NTP
Detailed Explanation:
Accurate time underpins logging, CI/CD timestamps, and cert validation. DEVASC recommends enabling encrypted authentication and limiting NTP associations to trusted servers (ACLs), and using at least three higher-stratum NTP servers for resiliency and accuracy.
Q20) Diagrams, IaC, and CI/CD
In an infrastructure-as-code workflow, what’s the recommended way to manage evolving network diagrams and topologies?
A. Store diagrams only in a wiki; avoid version control for simplicity
B. Keep diagrams in Git; represent topologies as YAML (e.g., VIRL/CML) and use them in CI/CD pipelines
C. Use spreadsheets for diagrams; version by filename suffixes
D. Keep diagrams on a jump host; update manually during changes
Detailed Explanation:
The guide recommends version-controlling network diagrams (e.g., with Git) to track change over time. With IaC, topologies (e.g., Cisco VIRL/CML) are stored as YAML and can be integrated into CI/CD automation pipelines, ensuring reproducible environments and auditable evolution.
