Firebase Functions u0026 Third-Party APIs Essentials Quiz Quiz

Discover how serverless functions interact with third-party APIs and enhance your understanding of deploying, securing, and managing external data integrations using cloud functions. Ideal for those seeking practical knowledge of event-driven architecture, API requests, and cloud automation best practices.

1. Trigger Types for Cloud Functions

   Which event can be used to trigger a cloud function that fetches data from an external API when a user account is created?

   1. File upload event
   2. Schedule-based event
   3. User creation event
   4. Database deletion event

   Explanation: A user creation event can be set up to trigger a function whenever a new user account is made, making it ideal for calling an external API to initialize user data. Schedule-based and file upload events do not directly correlate with user sign-ups. A database deletion event only triggers when data is removed, which is unrelated to user account creation.

2. Sending HTTP Requests from Serverless Functions

   Which method is most appropriate for making an HTTPS request to a third-party API within a cloud function?

   1. Writing inline SQL queries
   2. Embedding data in environment variables
   3. Direct browser AJAX request
   4. Using a built-in HTTPS/HTTP library

   Explanation: Most serverless environments provide HTTP or HTTPS libraries to make requests to third-party APIs directly from backend code. Inline SQL queries are for databases, not web APIs. Browser AJAX requests do not run from the backend function. Storing API data in environment variables is unsafe and not a communication method.

3. Securing API Keys in Serverless Environments

   What is the recommended way to manage sensitive API keys used by a cloud function when accessing external services?

   1. Hardcode them directly in source files
   2. Post them to a public spreadsheet
   3. Include them in client requests
   4. Store them in environment variables

   Explanation: Environment variables allow secure and flexible management of secrets, keeping them out of source code. Hardcoding exposes keys and is risky. Public spreadsheets are insecure. Revealing keys in client requests puts them at risk of exposure.

4. Handling External API Errors

   When a cloud function fails due to a third-party API returning a non-200 status code, what is an effective way to handle this error?

   1. Ignore the error and proceed as normal
   2. Duplicate the API call without checking the status
   3. Delete all user data from the database
   4. Log the error and return a meaningful response

   Explanation: Logging the error and sending a clear response helps detect issues while maintaining a good user experience. Ignoring errors can lead to unnoticed failures. Repeating the API call without handling the error may lead to further issues. Deleting user data is extreme and unjustified by an API error.

5. Limiting Excessive Third-Party Requests

   How can you prevent a serverless function from exceeding request limits of a third-party API during frequent data updates?

   1. Implement request throttling or rate limiting
   2. Schedule functions every second
   3. Change the API endpoint address
   4. Remove authentication headers

   Explanation: Throttling or rate limiting helps control how often external APIs are called, preventing quota overages. Removing authentication would break legitimate access. Changing the endpoint address doesn't reduce frequency. Overly frequent scheduling increases the risk of hitting API limits.

6. Parsing Third-Party API Data

   Which step is essential after receiving a JSON response from a third-party API in a cloud function?

   1. Compress the JSON file before parsing
   2. Parse the JSON data into an object
   3. Encrypt the raw response
   4. Ignore the response body

   Explanation: Parsing JSON converts the response into a format that can be easily used in your logic. Encrypting or compressing the raw response is unnecessary for immediate handling and can complicate processing. Ignoring the response means not using important information.

7. Choosing Suitable API Authentication

   If a third-party API requires an access token in the HTTP header, which method should you use in your cloud function to include the token in every request?

   1. Add the token to the database query
   2. Embed the token in posted client data
   3. Set the token in the Authorization request header
   4. Omit the token for public endpoints

   Explanation: Putting the token in the Authorization header ensures authenticated access as required. Including it in database queries or client data is insecure and improper. Omitting a required token results in access denial for protected endpoints.

8. Executing Functions on a Schedule

   Which scenario would most benefit from triggering a cloud function that makes an external API call on a fixed schedule?

   1. Refreshing currency exchange rates daily
   2. Responding to user file uploads
   3. Deleting entries on data deletion events
   4. Creating user profiles instantly

   Explanation: Scheduled triggers are ideal for tasks needing regular updates, like fetching daily rates. Creating or modifying resources instantly is better suited to event-driven triggers. Uploads and deletions should respond contextually, not on a fixed schedule.

9. Optimizing Third-Party API Usage

   What is a good practice when fetching large datasets from a third-party API inside a cloud function?

   1. Request paginated data in manageable chunks
   2. Store request URLs in a public folder
   3. Use only the first page and skip the rest
   4. Retrieve all data at once regardless of size

   Explanation: Paginating requests handles large datasets efficiently and avoids overwhelming resources. Requesting all data at once can cause timeouts or exceed limits. Ignoring additional pages gives incomplete results. Storing URLs publicly does not improve data retrieval.

10. Responding to Third-Party API Rate Limit Responses

    If a cloud function receives a '429 Too Many Requests' response from an external API, what should it do next?

    1. Resend the same request immediately
    2. Wait and retry the request after a delay
    3. Ignore the message and proceed
    4. Permanently stop making API calls

    Explanation: A 429 response means you've hit a request limit; waiting and retrying slows the traffic and helps compliance. Permanently stopping is unnecessary unless limits are changed. Resending immediately or ignoring the response will likely cause repeated failures.