Software Development and Design practice questions

git rebase main

Why it fails: `git rebase main` replays feature-login's commits onto main's tip, rewriting their hashes and producing linear history with no merge commit. It is tempting because it is the standard way to integrate upstream changes cleanly, and it would be correct if the branch were private and unpushed.

git merge main

Why it fails: Merge creates a merge commit, which is not desired here.

git checkout main && git pull && git checkout feature-login && git merge main

Why it fails: The final `git merge main` still produces a merge commit, so the sequence fails the stated requirement despite updating main first. It is tempting because pulling main before merging avoids working from a stale local main, and it would suit a workflow that accepts merge commits.

try:\n x = 1/0\nexcept ZeroDivisionError, e:\n print(e)

Why it fails: Python 3 removed the 'except Exception, e' comma syntax, requiring 'except ZeroDivisionError as e:'; this line raises SyntaxError. It is tempting because Python 2 accepted it, so legacy code and older tutorials still show this form, but the current certification targets Python 3.

try:\n x = 1/0\nexcept (ZeroDivisionError, TypeError) as e:\n print(e)

Why it fails: Invalid: tuple of exceptions with `as` is not valid syntax.

try:\n x = 1/0\nexcept:\n print('error')

Why it fails: Invalid: bare `except:` is not considered a valid exception handling statement.

array

Why it fails: array is a module type from the standard library, not a built-in Python data type; the built-ins are int, float, complex, bool, str, bytes, list, tuple, set, frozenset, dict and NoneType. It is tempting because array.array stores typed numeric sequences compactly, which suits bulk numeric work.

dict

Why it fails: Python's dict is a built-in mapping type, so listing it as invalid is mistaken. The question asks for valid data types, and dict qualifies alongside list, tuple and set. Confusion arises because dict denotes a data structure rather than a scalar type, but Python treats it as a first-class type usable in isinstance checks.

map

Why it fails: map is a built-in function returning an iterator, not a data type; the built-ins are int, float, complex, bool, str, bytes, list, tuple, set, frozenset, dict and NoneType. It is tempting because map objects are iterable and appear type-like when inspected.

The request was malformed and the server cannot process it.

Why it fails: A malformed request produces 400 Bad Request, not 403; 403 means the server understood the request but the authenticated principal lacks permission for that resource. It is tempting because both statuses indicate the request was rejected before any resource action occurred.

The requested resource does not exist on the server.

Why it fails: A missing resource returns 404 Not Found; 403 means the resource exists but the caller's identity or scope is not authorised to access it. It is tempting because both responses deny the client the requested representation, so the failure looks similar from the script's perspective.

The server is temporarily unavailable due to maintenance.

Why it fails: A 403 means the server understood the request but refused authorisation, so maintenance is not the cause; that would return 503 Service Unavailable. It is tempting because maintenance genuinely produces failures, but 503 signals temporary overload or downtime, whereas 403 concerns credentials or permissions.

response = requests.get(url); return response.headers['Date']

Why it fails: The Date header is the server's timestamp for when it generated the response, not the client-side round-trip duration. It is tempting because it is a time value returned with the response, but it cannot measure elapsed request time; response.elapsed or wall-clock timing around the call is required.

response = requests.get(url); return response.elapsed.total_seconds()

Why it fails: response.elapsed measures only the time between sending the request and receiving the response headers, excluding body download, so it understates total response time. It is tempting because requests exposes it directly, and it is correct when only server processing and header latency matter.

start = time.time(); response = requests.get(url); return time.time() - start

Why it fails: time.time() returns wall-clock time, which can jump if the system clock is adjusted (NTP, DST), making the measured interval unreliable. It is tempting because it captures the full request including body download, and would be correct if time.monotonic() were used instead.

result = map(lambda x: x**2, filter(lambda x: x % 2 == 0, range(20)))

Why it fails: While functional, it returns a map object, not a list; but list(map(...)) would be equivalent. However, the question asks for equivalent code, and this answer is not a complete list conversion. The loop is the most direct equivalent.

result = [] for x in range(20): result.append(x**2)

Why it fails: This loop appends x**2 for every x in range(20), omitting the 'if x % 2 == 0' filter, so it squares all twenty values including odd ones. The comprehension's condition restricts output to even x. It is tempting because the squaring expression and range match exactly; only the filter clause is missing.

result = [x**2 for x in range(20) if x % 2 != 0]

Why it fails: This comprehension inverts the filter, squaring only odd values, whereas the original keeps even ones. The condition must read 'x % 2 == 0' to match. It is tempting because the structure, range and squaring expression are identical, and only the comparison operator differs, which is easy to overlook when skimming.

git reset --hard HEAD

Why it fails: git reset --hard HEAD discards all staged and unstaged changes across the entire working tree, not just one file, so it overshoots the requirement and risks unrelated work. It is tempting because it does revert to the last commit, but git checkout -- <file> or git restore <file> targets the single file precisely.

git stash drop

Why it fails: git stash drop deletes a saved stash entry from the stash list; it does not touch working-tree modifications to a tracked file, so the local changes remain. It is tempting because stashes do hold discarded work, which would be correct when you want to remove a stash you no longer need.

git revert <file>

Why it fails: git revert creates a new commit that inverses an earlier commit; it operates on committed history, not uncommitted working-tree edits, so it cannot discard local changes. It is tempting because it does undo changes, which would be correct for reversing an already-committed change on a shared branch.

Linear branching

Why it fails: Linear branching is not a recognised Git branching strategy; Git branches are pointers, and no workflow model is named linear. It is tempting because a linear commit history results from rebasing, but that describes history shape, not a strategy such as Git Flow, GitHub Flow or trunk-based development.

Monolithic branching

Why it fails: Monolithic branching is not a Git branching strategy; the term describes repository architecture, not how branches are organised. It is tempting because a single long-lived main branch resembles a monolithic layout, but the recognised strategies are Git Flow, GitHub Flow and trunk-based development.

Copy-on-write branching

Why it fails: Copy-on-write branching is not a Git branching strategy; copy-on-write describes filesystem or storage snapshot behaviour, not branch workflow. It is tempting because Git objects are immutable and shared, but the valid strategies are Git Flow, GitHub Flow and trunk-based development.

List

Why it fails: Lists are ordered and index-accessed, so they fail the unordered requirement despite being mutable. The stem needs a mutable unordered type, which is a dictionary or set. Lists are correct when element order matters and positional access or duplicate values are required.

Tuple

Why it fails: Tuples are immutable and ordered, so they fail the mutability requirement outright; any attempt to assign an element raises a TypeError. They are tempting because they behave like read-only sequences, which is exactly what you want for fixed records, dictionary keys, or data that must not change after creation.

GET

Why it fails: GET is safe (does not modify) and also idempotent. It does not satisfy the 'not safe' condition.

POST

Why it fails: POST is neither idempotent nor safe. Subsequent calls create new resources, so it fails both criteria.

device_id = response['id']

Why it fails: The requests library returns a Response object, not a dictionary, so subscripting it directly with 'id' raises a TypeError; the JSON body must be parsed first. It tempts because the payload is JSON and dictionary access is the natural idiom once parsed, which is exactly what response.json()['id'] achieves.

device_id = response.text['id']

Why it fails: response.text returns the raw JSON body as a string, so subscripting it with ['id'] raises a TypeError rather than parsing the payload. It is tempting because the attribute name suggests the response content, but text is only for reading unparsed bodies; requests' json() method or json.loads on text is required to obtain a dictionary.

device_id = json.loads(response)['id']

Why it fails: json.loads expects a JSON string, but response is a Response object, so it raises a TypeError before any parsing occurs. It is tempting because loads is the correct deserialiser once you supply response.text or response.content; passing the object directly is the mistake, whereas response.json() handles decoding internally.

f = open('config.json'); data = json.load(f); key = data['authentication']['api_key']; f.close()

Why it fails: The snippet works but leaks the file handle if json.load raises, and omits an explicit mode argument. It is tempting because it mirrors the classic open/load/close pattern taught in tutorials; the with statement is preferred since it guarantees closure even when parsing fails, which matters for scripts opening many files.

with open('config.json') as f: data = json.loads(f) key = data['authentication']['api_key']

Why it fails: json.loads requires a string, but f is a file object, so it raises a TypeError; json.load is the function that reads from a file handle. It is tempting because loads is correct for strings such as API responses, and the with block looks right, but the wrong loader is paired with the file object.

with open('config.json', 'r') as f: data = json.load(f) key = data['authentication.api_key']

Why it fails: The key 'authentication.api_key' is a single literal string, not two nested lookups, so it raises a KeyError against the parsed dictionary. It is tempting because dotted notation resembles attribute access in other languages, but Python dictionaries require chained subscripts: data['authentication']['api_key'].

git checkout feature-logging && git rebase develop && git checkout develop && git merge feature-logging

Why it fails: Rebasing onto develop replays commits individually; it never squashes them, so the merge brings in multiple commits, violating the single-commit requirement. Interactive rebase with squash, or merge --squash, performs the consolidation. Rebasing is tempting for linearising history before integration, which suits teams wanting a clean, non-squashed branch.

git checkout develop && git pull feature-logging && git commit --amend

Why it fails: Incorrect commands; pull from a different branch is not standard.

git checkout develop && git merge --no-ff feature-logging

Why it fails: --no-ff preserves all commits, does not squash.

git checkout HEAD~2

Why it fails: Detaches HEAD, does not revert.

git reset --hard HEAD~2

Why it fails: Discards changes entirely.

git remove HEAD~2

Why it fails: Invalid Git command.

else

Why it fails: Optional; runs if no exception occurs.

raise

Why it fails: Used to raise exceptions, not essential for handling.

for iface in interfaces.keys(): print(iface + ': ' + interfaces.get(iface))

Why it fails: Incorrect: Does not skip None, so prints 'None' as a string for entries with None IP.

for iface in interfaces: if interfaces[iface]: print(iface, ':', interfaces[iface])

Why it fails: Incorrect: Uses truthiness check which could skip non-None falsy values, and print with commas produces spaces around the colon (e.g., 'iface : ip'), deviating from expected format.

git stash; git checkout -b feature-x; git stash pop; git checkout master; git reset --hard HEAD~3

Why it fails: Stashing only saves uncommitted changes, not commits. The commits remain on master. After creating feature-x and popping the stash, the commits are not transferred. Resetting master removes the commits, but feature-x never received them, so they are lost.

git checkout feature-x; git merge master; git checkout master; git reset --hard HEAD~3

Why it fails: This assumes feature-x already exists and merges master into it, which would bring the commits but also create a merge commit. Then resetting master removes the commits from master, but feature-x now has them via merge, not as original commits. This is not the desired clean move.

git checkout -b feature-x; git reset --hard HEAD~3; git checkout master

Why it fails: This creates feature-x and switches to it, then resets feature-x to three commits back, losing the commits on feature-x. Then switching to master leaves master unchanged with the commits still present. The commits are not moved to feature-x; they are lost on feature-x.

YAML using the PyYAML third-party library

Why it fails: YAML is expressive and human-readable, but PyYAML is an external package that must be installed separately, violating the requirement to avoid external dependencies. While YAML supports nested structures, the standard Python library does not include a YAML parser, so this choice fails the scenario's constraint.

JSON using the json module

Why it fails: JSON is built into Python through the json module and supports nested objects, but it does not permit comments and has stricter syntax rules that make hand-edited configuration files less forgiving. For typical device configuration with comments and flexible formatting, JSON is less practical, though it remains technically possible.

INI using the configparser module

Why it fails: configparser is a standard library module and handles sections and key-value pairs, but it does not natively support arbitrarily nested sections beyond one level. Deeply nested device/interface hierarchies would require workarounds, making it a poor fit for complex nested configurations.

socket.create_connection((url, 80), timeout=5)

Why it fails: socket.create_connection() establishes a raw TCP connection and does not handle HTTP protocol details such as headers, methods, or response parsing. It would require implementing the HTTP request manually, which is far from minimal. It also does not directly support HTTP GET semantics, making it unsuitable for this REST API call.

urllib.request.urlopen(url, timeout=5)

Why it fails: urllib.request.urlopen() does support a timeout parameter, but it is part of the standard library and requires more code to handle exceptions and parse responses. While it can work, it is not as concise as requests for this scenario. The stem asks for minimal code, and requests provides a simpler, more readable interface.

http.client.HTTPConnection(url, timeout=5)

Why it fails: http.client is a low-level library that requires manual connection management, request construction, and response parsing. Using it would involve significantly more code than requests. While it supports timeouts, it is not the minimal-code solution for a simple GET request with timeout handling.

def run(hostname, *commands, port=443):

Why it fails: Placing *commands before port=443 makes port a keyword-only parameter, so a caller cannot pass the port positionally as the second argument; run('r1', 22, 'show version') would put 22 into commands instead of port. The default still works only when port is passed by keyword, which does not match the stated requirement of a straightforward optional port.

def run(hostname, port=443, **commands):

Why it fails: The **commands parameter collects keyword arguments into a dictionary, not positional arguments into a tuple. Extra command strings passed positionally would raise a TypeError because no *args parameter exists to absorb them. This signature supports named options such as run('r1', timeout=5) but not an arbitrary list of positional command arguments.

def run(*commands, hostname, port=443):

Why it fails: With *commands first, hostname and port become keyword-only and the required hostname loses its normal positional role. A call like run('r1', 'show version') would place both strings into commands and then fail because hostname was never supplied. This reverses the intended parameter order and makes the common positional call impossible.