Cisco 350-901 DEVCOR/AUTOCOR common mistakes
Cisco 350-901 DEVCOR/AUTOCOR · Understand the traps and how to avoid them.
Treating the exam as a single 350-901 DEVCOR test and skipping the AUTOCOR automation material, so questions on YANG models, NETCONF/RESTCONF operations, and model-driven telemetry get answered with generic API knowledge.
Study guides and forum threads for the older 350-901 path dominate search results, and candidates assume the automation content is a small appendix rather than a co-equal portion of the blueprint.
What to do instead
Build a two-column blueprint map: one column for the software development, API, platform, and security objectives, one for infrastructure and automation objectives. For every automation objective, write the exact protocol operation (get-config vs edit-config, RESTCONF PATCH vs PUT, gNMI Subscribe modes) next to it and verify you can state its semantics without notes.
Confusing the four REST constraints in practice: using POST for idempotent updates, caching GET responses without checking Cache-Control, or describing statelessness as 'the server keeps session state'.
Most candidates learned REST by copying CRUD-to-HTTP mappings from tutorials and never internalised idempotency or the client-statelessness constraint as examinable definitions.
What to do instead
Memorise a small table: GET/PUT/DELETE idempotent, POST not; PUT replaces the whole resource, PATCH partially modifies; 201 with Location on create, 204 on delete, 409 on conflict, 429 with Retry-After. Practise explaining why a retried POST can duplicate a resource while a retried PUT cannot.
Writing code that reads API credentials or base URLs from hardcoded literals or commits them to the repo, and answering security questions by saying 'use HTTPS' as the whole answer.
Lab exercises are usually run against a single sandbox, so environment separation and secret handling never come up until the exam asks about CI pipelines or twelve-factor configuration.
What to do instead
Adopt a habit: os.environ or a vault lookup for every secret, .env excluded via .gitignore, and a config object injected at startup. Be able to name the tradeoffs of environment variables versus a secrets manager and explain why TLS alone does not protect a leaked token.
Handling API pagination and rate limits by requesting everything at once, then failing questions about Link headers, cursor tokens, 429 responses, and exponential backoff with jitter.
Small test datasets return everything in one page, so pagination and throttling code is never exercised during practice.
What to do instead
Write one reusable paginated fetch function that follows the Link rel=next header or cursor field until exhausted, and one retry wrapper that honours Retry-After, backs off exponentially, and adds jitter. Be able to explain why jitter prevents thundering-herd retries.
Describing CI/CD only in terms of tools (Jenkins, GitLab CI) rather than the pipeline stages, artefact immutability, and gate placement the exam asks about.
Candidates memorise tool names from job ads instead of the build-test-scan-deploy flow and where quality and security gates belong.
What to do instead
Draw a pipeline on paper: commit, lint and unit test, build immutable artefact tagged by commit SHA, dependency and container scan, integration test against the artefact, deploy to staging, promote the same artefact to production. For each gate, state what fails the build and why the artefact is never rebuilt per environment.
Answering OAuth 2.0 questions by mixing up the authorization code flow, client credentials, and PKCE, or claiming the access token is sent to the resource server as a password.
OAuth is learned from scattered blog posts, so the roles (resource owner, client, authorization server, resource server) and which grant suits machine-to-machine versus user-delegated access blur together.
What to do instead
Learn one diagram with the four roles and three grants. Client credentials for service-to-service with no user; authorization code plus PKCE for user-delegated access from public clients; refresh tokens only where a user context exists. Know that the access token goes in the Authorization: Bearer header to the resource server, and that scopes limit, not grant, access.
Writing unit tests that hit the live sandbox API, or mocking so broadly that the test asserts nothing about request shape, headers, or error handling.
Sandbox APIs are convenient during development, and broad mocks feel faster than designing seams for dependency injection.
What to do instead
Structure code so the HTTP client is injected. In tests, assert on the outgoing request (method, path, auth header, body) and simulate 401, 404, 429, and 500 responses to prove the retry and error paths. Keep a separate, small set of contract tests against a recorded fixture.
Treating the design-pattern and code-review objectives as trivia, memorising pattern names without being able to say when each applies or what problem it solves.
Pattern questions look like vocabulary tests, so candidates memorise definitions and then fail scenario questions that ask which pattern fits a described coupling problem.
What to do instead
For each pattern on your list (factory, observer, adapter, strategy, singleton), write one sentence of the problem it solves and one sentence of the cost it introduces. Then practise reading a short code snippet and naming the smell: duplicated logic, tight coupling to a vendor SDK, or a class doing I/O and parsing.
Assuming every Cisco platform exposes the same interface: calling a Meraki endpoint with a DNA Center token pattern, or expecting ACI object-model queries to behave like RESTCONF on IOS XE.
Each platform's API style, auth scheme, and data model differ, and candidates study only the one platform they have lab access to.
What to do instead
Keep a comparison grid with columns for auth method, base path or protocol, data model, and pagination style, and fill it for at least Meraki (API key header), DNA Center (X-Auth-Token from /dna/system/api/v1/auth/token), ACI (APIC cookie or signature), and IOS XE via RESTCONF with YANG. Recite the grid from memory before the exam.
Ignoring observability and infrastructure-as-automation questions: no clear answer for structured logging, correlation IDs, health versus readiness probes, or idempotent configuration runs.
These topics feel like operations trivia to developers, so they are skipped, yet they appear in deployment, security, and automation objectives.
What to do instead
Write short definitions you can defend: structured logs as JSON with a correlation ID propagated across calls; liveness probe answers 'is the process alive', readiness answers 'can it serve traffic'; idempotent automation converges to a desired state and is safe to rerun. Tie each back to a concrete failure it prevents.