DVA-C02 Development with AWS Services Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Change the Lambda runtime to Python 3.9 which includes requests

  Why it's wrong here

  AWS Lambda runtimes, including Python 3.9, are designed to be lean and only include essential libraries like `boto3` and `urllib` by default. Third-party libraries such as `requests` are not pre-installed in the execution environment. This design choice ensures smaller runtime images and faster cold starts, requiring developers to explicitly bundle external dependencies rather than relying on the runtime to provide them.

• ✓

  Package the 'requests' library with the Lambda deployment package

  Why this is correct

  To successfully use the `requests` library in an AWS Lambda function, it must be included as part of the deployment package. This typically involves installing `requests` and its dependencies into a local directory, then zipping that directory along with the function's handler code. Alternatively, for shared dependencies across multiple functions, a Lambda Layer can be created and attached, which is a best practice for managing common libraries efficiently.

• ✗

  Use the 'urllib' library instead of 'requests'

  Why it's wrong here

  While the `urllib` library is a standard Python module available in all Lambda runtimes and can perform HTTP requests, it is generally less convenient and user-friendly than `requests`. Developers often prefer `requests` for its simpler API, automatic JSON handling, and robust error management, which significantly streamlines web interactions. Replacing `requests` with `urllib` would require rewriting existing code and sacrificing the ergonomic benefits that `requests` provides, which is not what the developer intends.

• ✗

  Install the 'requests' library using pip in the Lambda console

  Why it's wrong here

  Attempting to install the `requests` library using `pip` directly within the Lambda console or during function execution is not a viable solution. The Lambda execution environment's file system is read-only for the function's code and dependencies, preventing persistent package installations at runtime. Dependencies must be pre-packaged with the deployment bundle or provided via a Lambda Layer before the function is invoked, as the console does not facilitate dynamic package management.

Go deeper

Related to this question