5 intermediate exercises — use RFC 2119 keywords correctly in API specifications, security requirements, coding standards, and system design documents.
MUST NOT / SHALL NOT — absolute prohibition; this behaviour is forbidden
SHOULD / RECOMMENDED — strong recommendation; valid exceptions exist but must be weighed carefully
SHOULD NOT / NOT RECOMMENDED — strong discouragement; valid reasons to permit it may exist
MAY / OPTIONAL — truly optional; implementations may include or omit with no conformance impact
Enforcement test: If ignoring this causes a 4xx/5xx error → MUST. If it's best practice → SHOULD. If there's no enforcement → MAY.
0 / 9 completed
1 / 9
An API specification states: "All requests to the /payments endpoint _____ include an Authorization header. Requests without a valid token will be rejected with a 401 Unauthorized response." Which RFC 2119 keyword correctly signals an absolute requirement?
MUST (equivalents: REQUIRED, SHALL) is the RFC 2119 keyword for an absolute requirement. If a conforming implementation does not satisfy a MUST requirement, it is non-compliant. The sentence confirms this: the second sentence describes the consequence of not sending the header ("will be rejected"), which is consistent with a MUST. RFC 2119 keyword hierarchy: MUST → no exceptions; SHOULD → strong recommendation, valid exceptions exist; MAY → optional feature. The keyword MUST NOT prohibits something absolutely. Example from the real world (RFC 9110, HTTP Semantics): "A client MUST send a Host header field in all HTTP/1.1 request messages." Practical tip: when writing API specs, use MUST only for things you will actually enforce with a 4xx or 5xx error — not for best practices.
2 / 9
A coding standards document reads: "Service handlers _____ log unhandled exceptions to the centralised logging platform. Developers may choose to also log to local files during development, but this is not required." Which RFC 2119 keyword signals a strong recommendation with valid exceptions?
SHOULD (equivalent: RECOMMENDED) signals a strong recommendation: there may be valid reasons to ignore it in particular circumstances, but the full implications must be understood before choosing a different approach. The sentence hints at this with "developers may choose to also log to local files during development" — the core expectation is centralised logging, but there's acknowledged flexibility. When to use SHOULD vs. MUST in coding standards: use MUST for security controls, API contracts, and legal/compliance items; use SHOULD for best practices, architectural guidance, and performance recommendations. RFC 2119 exact wording: "SHOULD: This word… means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Also: SHOULD NOT = strong discouragement but not absolute prohibition.
3 / 9
A system requirements document states: "The API client _____ include a User-Agent header in requests to aid in debugging and traffic analysis. This header is not validated by the server." Which RFC 2119 keyword signals an optional feature?
MAY (equivalents: OPTIONAL) signals that the item is genuinely optional — an implementation may or may not include this feature and remain fully conformant. The sentence confirms this: "This header is not validated by the server" means there is no enforcement and no consequence for omitting it. RFC 2119 exact wording: "MAY: This word… means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item." Common mistakes: using SHOULD when you mean MAY (overstating the recommendation) or MUST when you mean SHOULD (creating false absolutes that are then routinely ignored, undermining the spec's credibility). Synonyms in specs: "is OPTIONAL", "is permitted", "is allowed", "clients are free to include".
4 / 9
An API security spec reads: "Tokens _____ be transmitted in URL query parameters. They MUST only be sent in the Authorization header or as an HttpOnly cookie to prevent exposure in server logs and browser history." Which RFC 2119 keyword creates an absolute prohibition?
MUST NOT (equivalent: SHALL NOT) is the RFC 2119 keyword for an absolute prohibition — the specification forbids this behaviour entirely. Any compliant implementation that transmits tokens in URL parameters violates the specification. The context confirms this: the next sentence ("They MUST only be sent in…") pairs the prohibition with a mandatory alternative, which is the classic security spec pattern. Why not SHOULD NOT? SHOULD NOT means the behaviour is strongly discouraged but may be acceptable in specific circumstances — far too weak for a security control where the risk (token exposure in logs, referrer headers, browser history) is high and unambiguous. In OAuth 2.0 (RFC 6749), you will find exactly this prohibition: "Clients MUST NOT use the query parameter for access tokens." When writing security specs, always escalate SHOULD NOT to MUST NOT for controls that prevent known attack vectors.
5 / 9
A REST API style guide reads: "Endpoints _____ support both JSON and XML response formats. However, JSON _____ be the default content type returned when no Accept header is specified." Which combination of RFC 2119 keywords is correct?
The correct combination is MAY… SHOULD. Breaking down the logic: (1) Supporting both JSON and XML is optional — not every endpoint needs to offer XML. MAY is correct: "implementations are permitted to support both formats but are not required to." (2) When a client sends no Accept header, returning JSON is a strong best practice (it's what API consumers expect), but it's not an absolute requirement that would break conformance. SHOULD is correct: "the default SHOULD be JSON — there may be valid reasons to default to another format in specific contexts." This two-keyword pattern is common in style guides: the optional feature (MAY) paired with a recommended default behaviour (SHOULD). Compare with a stricter alternative: "Endpoints MUST accept both formats. JSON MUST be the default." — this would be appropriate if the API contract explicitly guarantees content negotiation support. Always pair your keywords with the enforcement mechanism: MUST → server enforces (4xx); SHOULD → documented best practice; MAY → no enforcement.
6 / 9
David from QA just commented on your pull request: 'The API documentation states that all requests to the /users endpoint MUST include a valid JWT token. This is critical for authentication.' Which of the following best describes David's comment regarding the use of 'MUST'?
'MUST' in RFC 2119 denotes an absolute requirement. Failure to adhere to this specification will result in the action being blocked or rejected – in David's case, unauthorized access attempts. Confusing 'MUST' with 'SHOULD' or 'MAY' leads to misunderstandings about compliance levels. It is crucial to understand that 'MUST' has no exceptions.
7 / 9
David from QA just commented on your pull request: 'The API documentation states that all requests to the /users endpoint MUST include a valid JWT token. This is critical for authentication.' Which of the following best describes David's comment regarding the use of 'MUST'?
'MUST' in RFC 2119 denotes an absolute requirement. Failure to adhere to this specification will result in the action being blocked or rejected – in David's case, unauthorized access attempts. Confusing 'MUST' with 'SHOULD' or 'MAY' leads to misunderstandings about compliance levels. It is crucial to understand that 'MUST' has no exceptions.
8 / 9
You're writing the description for a pull request that introduces a new feature to an authentication service. You want to specify that users can optionally provide a callback URL when registering. The wording should be clear and precise. Which of the following best uses the appropriate RFC 2119 keyword?
'Should' indicates a recommendation and best practice. It's appropriate here because providing a callback URL enhances security but isn't strictly necessary for the service to function. 'Must' would create an unnecessary hard requirement, while 'May' is too vague. A 'required' statement implies a fundamental part of the system.
9 / 9
Maria (DevOps Engineer) is configuring an automated deployment pipeline. She needs to specify the required level of testing for a new feature that uses external API calls. Which statement best describes how she should use 'MUST', 'SHOULD', and 'MAY' in her configuration?
This correctly utilizes the terms to represent different levels of requirements. 'MANDATORY' for core functionality (API response), 'SHOULD' for best practices, and 'ALLOWED' or 'POSSIBLE' for optional additions. This approach provides a structured framework for testing based on risk and impact.
What will I practise in "Specification Language: MUST, SHOULD, MAY in IT — IT English Grammar Exercise"?
Practice RFC 2119 keywords in technical specifications: MUST, SHOULD, MAY, MUST NOT, SHOULD NOT.
How many exercises are in this module?
This module has 9 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the grammar rule and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Grammar exercises?
Browse the full Grammar hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain grammar rules in prose; this exercise tests and reinforces those rules through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.