Cloud Run: Deploying Serverless Containers Quiz Quiz

Challenge your understanding of serverless container deployment with essential questions about configuration, scalability, networking, and best practices. This quiz focuses on fundamental concepts and real-world scenarios related to deploying containers on managed serverless compute platforms.

  1. Deployment Configuration

    When deploying a container to a serverless platform, which of the following settings controls how much memory is allocated to each container instance?

    1. Memory limit parameter
    2. Timeout setting
    3. Scaling rule flag
    4. Health check interval

    Explanation: The memory limit parameter specifies the amount of memory given to each container instance and is essential for controlling resource allocation. The scaling rule flag typically relates to the number of instances rather than per-instance resources. The timeout setting defines how long a request or process can run before being terminated. The health check interval is used to determine how often the service checks the container’s status, not its memory allocation.

  2. Public vs Private Service Access

    A developer wants to restrict access to their serverless container so only clients within a specific network can connect. Which deployment setting should be configured?

    1. Increase concurrency limit
    2. Set service to private
    3. Enable public endpoint
    4. Change container port

    Explanation: Setting the service to private limits access to authorized or internal connections, which is necessary to restrict connectivity. Enabling a public endpoint makes the service accessible to anyone with the proper network information. Increasing the concurrency limit changes how many requests each container handles but does not impact network access. Changing the container port might modify the endpoint but does not secure the service.

  3. Scaling Behavior

    If an application running in a serverless container experiences suddenly increased incoming traffic, what typically happens to handle the load?

    1. Requests are instantly rejected
    2. Instances automatically scale out
    3. The deployment is paused
    4. The container restarts with higher resources

    Explanation: Serverless platforms are designed to automatically scale out by launching new instances in response to higher demand. Containers do not typically restart with more resources; resource parameters are set at deployment. Requests are generally not rejected unless resource limits are reached or scaling is misconfigured. Pausing the deployment would halt processing, which is not the default response to increased traffic.

  4. Container Image Requirements

    Which characteristic is necessary for a container image to be used in serverless deployments?

    1. It must be over 1GB in size
    2. It should require manual startup
    3. It has to contain database data
    4. It must expose a listening port

    Explanation: The container image must expose a specific port so the platform knows where to route incoming network requests. Manual startup is not desired, as serverless deployments require automated, stateless behavior. Database data should not be embedded within the image; containers should connect to external storage. There is no requirement for large image sizes; smaller images are often preferred for efficiency.

  5. Environment Variables and Secrets

    What is a recommended method for providing sensitive information, like API keys, to a container running in a serverless environment?

    1. Set them as environment variables at deployment
    2. Print them to standard output at startup
    3. Hardcode them inside source code
    4. Store them in plaintext within a configuration file

    Explanation: Providing sensitive data as environment variables at deployment is a standard and secure practice, as it avoids embedding secrets in the code or image. Hardcoding secrets in source code is insecure and risks accidental exposure. Storing them in plaintext configuration files can lead to unauthorized access. Printing secrets to standard output is not secure and may expose them in logs.