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.

• ✓

  Set up permissions, then write code, then create function, then configure trigger, then test.

  Why this is correct

  This is correct because permissions must be set first to allow the Lambda function to access S3 and CloudWatch, then the code is written, the function is created, the S3 trigger is configured to invoke the function on events, and finally testing validates the setup.

• ✗

  Write code, then set up permissions, then create function, then configure trigger, then test.

  Why it's wrong here

  This sequence is incorrect because the Lambda execution role, which defines the function's permissions to interact with other AWS services like S3 and CloudWatch Logs, should ideally be established *before* the code is written and certainly before the function is created. While code can be written independently, the function's ability to perform its intended actions relies on these permissions. Attempting to create and test a function without its necessary privileges will result in runtime errors, making the "write code" step less effective without the context of available permissions.

• ✗

  Set up permissions, then create function, then write code, then configure trigger, then test.

  Why it's wrong here

  This order is flawed because creating a Lambda function inherently requires the function's code and handler to be specified during its initial setup. You cannot create a functional Lambda resource as an empty shell and then subsequently "write code" as a separate, later step in the creation workflow. The deployment package containing the function's logic is a fundamental component provided at the time of function creation, not added afterwards as a primary step.

• ✗

  Set up permissions, then write code, then create function, then test, then configure trigger.

  Why it's wrong here

  This sequence is incorrect because testing a Lambda function designed to respond to an S3 trigger *before* that trigger is configured prevents end-to-end validation. While you can perform isolated tests with sample events through the console, this does not confirm the crucial integration where an actual S3 event successfully invokes the function. The "configure trigger" step establishes the event source mapping, which is essential for validating the function's behavior in its intended event-driven environment.

Go deeper

Related to this question