200-901 Understanding and Using APIs Practice Question
Which HTTP method is idempotent and safe?
⚠ Common exam trap
Cisco often tests the distinction between idempotent and safe by pairing DELETE (idempotent but not safe) or PUT (idempotent but not safe) as distractors, leading candidates to assume that any method that can be repeated safely is also safe, when in fact safety requires no server-side state change.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
GET
GET is both idempotent and safe because it is designed to retrieve a resource without causing any side effects on the server. According to RFC 7231, a safe method does not modify the resource state, and an idempotent method guarantees that multiple identical requests produce the same result as a single request. GET satisfies both conditions, as it never alters server state and repeating the same GET request returns the same representation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
GET
Why this is correct
GET retrieves a representation without altering server state, satisfying both safety (no side effects) and idempotence (repeated identical requests yield the same result). Unlike POST, which creates or modifies resources, GET is defined by RFC 9110 as both safe and idempotent, making it the only listed method meeting both constraints.
- ✗
DELETE
Why it's wrong here
DELETE is idempotent but not safe, because it alters server state by removing the target resource. It is tempting because repeating a DELETE yields the same end state, which looks safe, yet safety concerns read-only methods; DELETE would be the answer if the question asked only for idempotency.
- ✗
POST
Why it's wrong here
POST is neither safe nor idempotent: it submits an entity for processing, typically creating a resource, and repeated identical requests can produce multiple resources or side effects. It is tempting because POST is the workhorse for form submissions and API creation calls, where non-idempotent behaviour is exactly what is wanted.
- ✗
PUT
Why it's wrong here
PUT is idempotent but not safe, since it creates or replaces the target resource and therefore changes server state. It is tempting because repeating an identical PUT produces the same representation, which resembles safety, but PUT would be correct only if the question asked for an idempotent method that need not be safe.
Go deeper
Related to this question
About these practice questions
Courseiva writes every 200-901 question from scratch — 975 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-901 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-901 exam.