350-901 Practice Questions

To build a functional Docker image for a Python application, the instructions must follow a specific logical order:

1. FROM: Specifies the base image (python:3.6-alpine).
2. COPY: Moves files from the local directory (.) to the container's working directory (.).
3. RUN: Executes commands during the build process, such as installing dependencies via pip.
4. EXPOSE: Informs Docker that the container listens on the specified network port (5001) at runtime.
5. CMD: Sets the default command to execute when the container starts (["python", "app.py"]).

ENV, VOLUME, and WORKDIR are valid Docker instructions but do not match the specific values provided in this scenario.

Docker Documentation: Dockerfile reference, sections "FROM", "COPY", "RUN", "EXPOSE", and "CMD". Official Docker Docs

Docker Best Practices: Best practices for writing Dockerfiles, section "Use multi-stage builds" and "Instructions". Docker Documentation

Python Official Image: Docker Hub - Python, usage guidelines for Alpine-based Python images. Docker Hub Python Repository

In the OAuth 2.0 authorization code grant flow, after the end-user authenticates and grants consent, the authorization server redirects the user-agent (browser) back to the application's pre-registered redirect URI. This redirect request includes two key parameters in the query string:

1. code: A temporary, single-use authorization code. The application will exchange this code for an access token in a subsequent back-channel request to the authorization server's token endpoint.

2. state: An opaque value used by the application to maintain state between the request and callback and to prevent Cross-Site Request Forgery (CSRF) attacks. The authorization server must return this value unmodified if it was included in the initial authorization request.

A. The access token and refresh token are provided by the authorization server's token endpoint in a later step, in exchange for the authorization code, not directly in the user-agent redirect.

B. The access token is not returned at this stage. It is obtained later by exchanging the authorization code.

C. The redirect URI is the destination of the redirect, not a parameter returned in the query string. The permission panel is displayed by the authorization server before this redirect occurs.

1. Internet Engineering Task Force (IETF) RFC 6749

"The OAuth 2.0 Authorization Framework":

Section 4.1.2

"Authorization Response": This section explicitly states that upon a successful grant by the resource owner

the authorization server redirects the user-agent to the client's redirection URI with the code and state parameters appended to the query component. It specifies code as "REQUIRED" and state as "REQUIRED if the 'state' parameter was present in the client authorization request."

2. Cisco DevNet Documentation

"Understanding OAuth 2.0":

"Authorization Code" section: This guide describes the flow

stating: "The Authorization Server redirects the user back to the application with an authorization code... The application can now exchange the authorization code for an access token." It also highlights the use of the state parameter for security. This aligns with the standard flow where code and state are returned post-consent.

When a git merge operation results in conflicts, Git pauses the process, leaving the repository in a special "merging" state. The developer must manually resolve the conflicts before committing. If the developer decides to abandon the merge attempt entirely, the git merge --abort command is used. This command aborts the conflict resolution process and restores the repository and working directory to the state they were in just before the merge was initiated.

A. git merge -no-edit is incorrect because it is used to accept the auto-generated merge commit message without opening an editor. It does not abort a merge with conflicts.

C. git merge -revert is incorrect because -revert is not a valid option for the git merge command. git revert is a separate command used to undo a previously committed merge.

D. git merge --commit is incorrect because this is the default behavior to finalize a successful merge by creating a merge commit. It cannot be used when conflicts are present.

1. Official Git Documentation: The git-merge command documentation explicitly states the function of the --abort option.

Source: git-scm.com

Official Git Documentation

Reference: git-merge Documentation

OPTIONS section. " --abort Abort the current conflict resolution process

and try to reconstruct the pre-merge state."

Link: https://git-scm.com/docs/git-merge#options

2. MIT Courseware: University course materials on version control confirm this usage for handling merge conflicts.

Source: MIT Missing Semester of Your CS Education

Reference: Version Control (Git) Lecture Notes. "If at any point you want to give up and get back to the state before you started the merge

you can do that with git merge --abort."

Link: https://missing.csail.mit.edu/2020/version-control/ (Under the "Merge Conflicts" section).

The scenario requires automating the provisioning of virtual machines (VMs) across multiple cloud providers. The core task is to create the infrastructure (the VM) from a pre-existing image and inject a configuration script (via cloud-init) at launch time.

Terraform is an Infrastructure as Code (IaC) tool designed specifically for this purpose. It allows users to declaratively define and provision infrastructure resources across numerous cloud and on-premises providers. It directly supports passing user data (cloud-init scripts) during VM creation, which fulfills the requirement to configure the VM without needing to log in post-deployment. This makes Terraform the most suitable and direct tool for the described solution.

A. Ansible: Ansible is primarily a configuration management tool that configures software on existing, running systems. It is not the primary tool for provisioning the underlying infrastructure itself.

B. Ansible and Terraform: While Terraform provisions the VM, the scenario states all configuration is handled by cloud-init. Therefore, a separate configuration management tool like Ansible is not needed.

C. NSO: Cisco Network Services Orchestrator (NSO) is a network automation and orchestration platform for network devices and services, not a tool for provisioning general-purpose cloud VMs.

E. Ansible and NSO: This combination is incorrect as neither tool is the primary choice for cloud infrastructure provisioning, which is the central requirement of the question.

1. HashiCorp Terraform Documentation: The official documentation for various cloud providers demonstrates the use of arguments to pass cloud-init data. For example

the awsinstance resource uses the userdata argument.

Source: HashiCorp

"Terraform AWS Provider - awsinstance resource"

userdata argument documentation. (Available on the official Terraform Registry website).

Quote/Concept: "userdata - (Optional) The user data to provide when launching the instance. Do not pass gzip-compressed data via this argument; see userdatabase64 instead." This argument is the standard mechanism for passing cloud-init scripts.

2. Cisco DevNet Documentation: Cisco provides official guides and code for deploying SD-WAN virtual appliances in public clouds using Terraform

validating it as the intended tool for this use case.

Source: Cisco DevNet

"Cisco SD-WAN Cloud OnRamp for IaaS with Terraform on AWS".

Section: The guide's overview and code examples explicitly use Terraform to provision EC2 instances for vEdge/cEdge Cloud routers and utilize userdata to pass bootstrap configurations.

3. University Courseware: Reputable computer science programs cover the distinct roles of provisioning and configuration management tools in their DevOps and Cloud Computing curricula.

Source: University of California

Berkeley

CS 162: Operating Systems and System Programming

Lecture 23: "Datacenter Computing".

Concept: The lecture materials differentiate between tools for provisioning (like Terraform) that create and manage infrastructure resources

and tools for configuration management (like Ansible

Puppet) that install and manage software on those resources. The question describes a provisioning task.

The code snippet checks if the response.status_code falls within the range 500, 501, 502, 503, or 504. In the HTTP protocol standard, the 5xx series represents Server Error responses. These indicate that the server is aware it has erred or is incapable of performing the requested method. Specifically, a 500-series error signifies an unrecoverable server-side issue (such as a crash, gateway timeout, or overload) that prevents it from fulfilling a valid request. Therefore, the message "Error; The server is unable to handle your request" is the only option that accurately describes a 5xx server-side failure.

Option B: This refers to an HTTP 404 Not Found error, which is a 4xx Client Error indicating the resource does not exist, not a 5xx Server Error.

Option C: This refers to an HTTP 429 Too Many Requests error, which is a 4xx Client Error used for rate limiting, not a 5xx Server Error.

Option D: This refers to an HTTP 401 Unauthorized error, which is a 4xx Client Error indicating missing or invalid authentication credentials.

Cisco DevNet Documentation (REST API Fundamentals): Section on "HTTP Status Codes," identifying 5xx codes as "Server Error - the server failed to fulfill an apparently valid request."

IETF RFC 9110 (HTTP Semantics): Section 15.6, "Server Error 5xx," which defines these codes as indicating the server is incapable of performing the request.

Python Requests Library Documentation (v2.31): Section on "Response Status Codes," explaining how the .status_code attribute captures the integer code returned by the server.

Mozilla Developer Network (MDN) Web Docs: "HTTP response status codes - 5xx Server Error," documenting that these errors occur when the server encountered an unexpected condition.

Relational databases (RDBMS) focus on data consistency and integrity. They utilize Highly normalized data to reduce redundancy, Enforced data integrity tools (like foreign keys and constraints) to ensure accuracy, and Structured Query Language (SQL) for complex querying.

Nonrelational (NoSQL) databases are designed for modern, high-velocity data needs. They are Elastic, scalable, and schema-free, allowing for unstructured data. They are Highly horizontally scalable, meaning they scale by adding more servers (sharding) rather than upgrading a single unit. Consequently, they excel at Rapid transaction handling for massive volumes of simple read/write operations where the overhead of complex relational joins would cause bottlenecks.

Microsoft Azure Documentation: "Non-relational data and NoSQL" (Section: Characteristics of non-relational data). Describes horizontal scaling and schema-free nature. [Official Vendor Documentation]

AWS Documentation: "What is NoSQL?" (Section: Why use NoSQL?). Highlights high-performance at scale and flexible schemas. [Official Vendor Documentation]

Stanford University (CS145): Introduction to Databases. Course notes on Relational Algebra and Normalization (3NF/BCNF) vs. NoSQL CAP theorem. [University Courseware]

Silberschatz, A., Korth, H. F., & Sudarshan, S. (2019): Database System Concepts (7th Edition). McGraw-Hill. Chapters on Relational Model (Ch. 2) and NoSQL (Ch. 10). [Academic Publication]

Oracle Documentation: "What is a Relational Database?" Explains the importance of SQL and data integrity constraints. [Official Vendor Documentation]

In a Docker Swarm, placement constraints are the standard mechanism to limit the nodes where a service can run based on node attributes or labels. To satisfy the first requirement (central region), you would use a constraint like --constraint 'node.labels.region == central' (assuming labels are set). To satisfy the second requirement (ineligible for manager role), you would use the constraint --constraint 'node.role == worker'. In Docker Swarm, manager nodes handle orchestration, while worker nodes are typically the intended targets for application workloads, and constraints are specifically designed to filter these targets during the scheduling phase.

Option A is incorrect because creating a separate cluster adds unnecessary management overhead and breaks the unified orchestration model of the existing multi-region swarm cluster.

Option B is incorrect because setting replicas to 0 prevents the service from running entirely, failing the requirement to deploy and run the service.

Option D is incorrect because there is no "control flag" in Docker Swarm containers used to prevent services from starting in specific geographical regions.

Docker Documentation: Deploy services to a swarm - Control service placement. Section: Placement constraints. (https://docs.docker.com/engine/swarm/services/#control-service-placement)

Docker Documentation: Node metadata. Section: Labels and Constraints. (https://docs.docker.com/engine/swarm/manage-nodes/#add-or-remove-label-metadata)

Cisco DevNet Associate (DEVASC) Study Guide: Chapter: Containers and Pipelines, Section: Docker Swarm Orchestration and Scheduling.

In software engineering, code maintainability is heavily dependent on readability and the ability of a developer to understand the intent of the code without extensive reverse-engineering. The exhibit uses generic, single-character variable names like k, v, i, k2, and v2. These names provide no context regarding the data being processed. Replacing these with verbose, descriptive names (e.g., department_key, employee_list, record) allows future developers to understand the data structure and logic flow quickly during quarterly updates, significantly reducing the risk of errors during modifications.

A. Use global variables Global variables increase coupling and make code harder to debug and maintain, as they can be modified unexpectedly from any part of the application.

B. Use double quotes instead of single quotes to enclose variables In Python, there is no functional or maintainability difference between single and double quotes for strings; this is a purely stylistic choice that does not impact logic.

C. Use different indent levels for variables In Python, indentation levels define code blocks and scope. Using arbitrary or inconsistent indentation would break the syntax and make the code unreadable and unmaintainable.

Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. (Chapter 2: Meaningful Names - Discusses how intention-revealing names improve software longevity and maintainability).

Python Software Foundation. PEP 8 – Style Guide for Python Code. (Section: Overriding Principle - Readability counts; Section: Naming Conventions - Encourages descriptive naming to improve code clarity).

ISO/IEC 25010:2011. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE). (Defines maintainability sub-characteristics including Analyzability, which is enhanced by clear identifier naming).

McConnell, S. (2004). Code Complete: A Practical Handbook of Software Construction. Microsoft Press. (Chapter 11: The Power of Variable Names - Details how the "Optimal Name Length" and specificity contribute to maintenance efficiency).

The salting technique involves adding a unique, randomly generated value (the "salt") to each user's password before it is hashed. This salt is then stored alongside the hashed password in the database. Because every user has a different salt, even if two users choose the identical password, their stored hashes will be unique. This uniqueness invalidates pre-computed attack methods like rainbow tables, which rely on mapping common passwords to their hashes. Consequently, an attacker who compromises the password database is forced to attempt to crack each password hash individually, using its corresponding salt, which directly fulfills the requirement.

A. Apply the peppering technique: Peppering adds a single, static secret value (the pepper) to all passwords before hashing. Identical passwords will still result in identical hashes, allowing an attacker to target them simultaneously.

B. Store the passwords by using asymmetric encryption: Asymmetric encryption is reversible. If the private key is compromised, an attacker can decrypt all passwords, which is a catastrophic failure and not a recommended practice for password storage.

D. Store the passwords by using symmetric encryption: Symmetric encryption is also reversible. If the single shared key is compromised, an attacker can decrypt the entire database of passwords, violating the principle of secure password storage.

1. NIST Special Publication 800-63B

Digital Identity Guidelines: Authentication and Lifecycle Management. Section 5.1.1.2

"Memorized Secret Verifiers

" states: "Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Memorized secrets SHALL be salted and hashed... The salt value SHALL be a 32-bit (or longer) random value generated by an approved random bit generator... The salt value is stored with the hash result." This process ensures each hash is unique.

2. OWASP Foundation

Password Storage Cheat Sheet. Section "Use a salt for all hashes

" explains: "A salt is a unique

randomly generated string that is added to each password before it's hashed... Salting passwords prevents an attacker from using pre-computed hash tables (rainbow tables) to crack passwords." This directly supports the concept of forcing one-at-a-time attacks.

3. Stanford University

CS 155 Course Notes

Web Security. Lecture notes on "Passwords" describe how using a unique salt per user (H(password || salt)) prevents rainbow table attacks and forces attackers to compute a separate table for every user

which is computationally equivalent to a brute-force attack on each password individually.

In Python's requests library, the standard attribute to check the HTTP response status is status_code; the attribute .status does not exist in this library, making those options invalid.

1. Box 1: A successful authentication POST returns a 200 OK status.
2. Box 2: Upon successful execution and printing the data, sys.exit(0) is used to signal a clean termination to the operating system.
3. Box 3: An "Authentication error" specifically maps to 403 Forbidden (or 401), identifying unauthorized access attempts.
4. Box 4: If the script encounters an error (the elif or else blocks), sys.exit(1) is standard practice to indicate an unrecoverable failure or error state.

Python Requests Documentation: "Response Status Codes" section. Verifies that the correct attribute for checking HTTP status is Response.status_code. (Source: https://requests.readthedocs.io/en/latest/user/quickstart/#status-codes)

Cisco DevNet - SD-WAN API Documentation: Authentication Section. Describes that a successful login to vManage via /j_security_check results in an HTTP 200 status code. (Source: Cisco DevNet vManage REST API Guide).

Python Standard Library (sys module): Documentation for sys.exit([arg]). Specifies that 0 is considered "successful termination" and any nonzero value is considered an "abnormal termination." (Source: https://docs.python.org/3/library/sys.html#sys.exit)

RFC 7231 (Hypertext Transfer Protocol): Section 6.5.3 (403 Forbidden) and Section 6.3.1 (200 OK). Defines the semantic meaning of these status codes in RESTful operations. (Source: https://tools.ietf.org/html/rfc7231)