easyMultiple Select
Google ACE Practice Question: A developer is deploying an HTTP-triggered Cloud…
A developer is deploying an HTTP-triggered Cloud Function for a production application. Which TWO configuration options should be applied to ensure security and control costs? (Choose two.)
⚠ Common exam trap
Google Cloud often tests the misconception that setting minimum instances to 0 is a cost-saving measure, but it is actually the default and does not control costs; the trap is confusing 'minimum instances' with 'maximum instances' for cost control.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Set a maximum instances limit
Option B is correct because setting a maximum instances limit caps the number of concurrent function instances, which directly bounds the potential scaling and therefore controls the cost of an HTTP-triggered Cloud Function under heavy or unexpected traffic. Option E is correct because requiring a service account to authenticate invocations enforces IAM-based access control, ensuring only authorized identities (via signed ID tokens) can call the function, which is essential for a production security posture. Option A is incorrect because allowing unauthenticated invocations exposes the function publicly and defeats the security requirement. Option C is incorrect because setting minimum instances to 0 only affects cold-start behavior and cost of idle capacity, not the security or the upper cost bound the scenario demands. Option D is incorrect because a custom domain is a routing/branding convenience and does not by itself provide security or cost control.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Allow unauthenticated invocations
Why it's wrong here
Allowing unauthenticated invocations on an HTTP-triggered Cloud Function removes the requirement for an Identity-Aware Proxy, API key, or IAM-based authentication token. A publicly exposed endpoint without authentication lets anyone on the internet invoke the function, potentially triggering expensive or destructive operations, leaking data, or exhausting quotas. For secure deployments, the function should reject anonymous requests and require an OAuth2 token from a valid Google account or service account.
- ✓
Set a maximum instances limit
Why this is correct
Setting a maximum instances limit caps the number of concurrent Cloud Function instances that can be spun up in response to traffic. Without this limit, a sudden spike or a distributed denial-of-service attack could cause the function to scale out to a default high number, driving unbounded costs and risking quota exhaustion. A low maximum, such as 1 or 2 instances, both controls cost and limits the blast radius of a runaway or malicious invocation pattern, making it a practical cost-control and mild DoS mitigation measure.
- ✗
Set minimum instances to 0
Why it's wrong here
Setting minimum instances to 0 simply means the function scales to zero when idle, which is the default and most cost-efficient behavior. This setting has no security implications: it only affects cold-start latency versus running warm instances. While reducing idle instances lowers cost, it does not prevent abuse, control scaling under traffic, or protect the function from unauthenticated or unauthorized calls. It is unrelated to authentication or access control.
- ✗
Configure a custom domain for the function
Why it's wrong here
Configuring a custom domain for an HTTP-triggered Cloud Function maps a user-friendly domain (e.g., functions.example.com) to the function's generated URL, often using a load balancer. Custom domains provide branding, consistent URLs, and easier TLS certificate management, but they do not add security controls or cost limits by themselves. The underlying function still needs IAM or authentication settings to be secure; a custom domain even without authentication could expose the function to the public at a predictable address.
- ✓
Use a service account to authenticate invocations
Why this is correct
Using a service account to authenticate invocations means callers obtain an OAuth2 access token for a dedicated service account and present it in the Authorization header of the HTTP request. This leverages IAM roles (e.g., roles/cloudfunctions.invoker) to restrict invocations to only those identities granted permission, giving you fine-grained, auditable access control. This is the correct security practice for a private HTTP-triggered Cloud Function, ensuring only trusted services or users with a valid token can trigger execution.
Go deeper
Related to this question
Learn chapter
Cloud HSM for Hardware Security
Key term
Service
A service is a software component or system that performs a specific function and is available to be used by other programs or users over a network.
Key term
Service account
A service account is a special type of account used by an application or a virtual machine, rather than a human user, to authenticate and interact with cloud services and APIs securely.
About these practice questions
One of 775 original ACE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.