Google ACE Practice Question: A GCP organization mandates that all new Cloud…

Answer analysis

Option-by-option breakdown

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

• ✗

  Rely on database administrators to manually enable SSL on each new Cloud SQL instance

  Why it's wrong here

  Manual SSL enablement by database administrators does not scale across a large enterprise where Cloud SQL instances are created programmatically via Infrastructure as Code, scripts, or multiple developer teams. Each new instance must be individually inspected and configured, and a single oversight leaves an instance accepting unencrypted connections indefinitely. Because there is no centralized enforcement mechanism, this approach cannot guarantee uniform compliance with organizational security requirements, unlike an organization policy constraint that is evaluated automatically at resource creation time.

• ✗

  Use Security Command Center to detect SSL-disabled instances and alert the team

  Why it's wrong here

  Security Command Center (SCC) is a security and risk management platform that can detect misconfigured instances, including Cloud SQL instances that allow non-SSL connections, and generate findings or alerts. However, this is a reactive control: the non-compliant instance already exists by the time the finding is generated, leaving a window during which unencrypted connections are possible. Even if the team receives an alert quickly, someone must triage and remediate the issue, whereas an enforced organization policy constraint prevents the Cloud SQL instance from being created or modified without SSL from the start.

• ✗

  Set a Cloud Monitoring alert for new Cloud SQL instances and auto-remediate via Cloud Functions

  Why it's wrong here

  Using Cloud Monitoring alerts and a Cloud Functions-based auto-remediation workflow is an event-driven reaction: the instance is created without SSL, the alert fires, and the function runs to enable SSL, so a period of non-compliance always exists between creation and the completion of the remediation function. The Cloud Function must have sufficient permissions to modify Cloud SQL instances, which introduces additional IAM security surface, and the approach is more complex to maintain than a declarative org policy. An org policy does not require event handling, custom code, or a remediation script, and it eliminates the non-compliance window entirely by preventing the insecure resource from being created in the first place.

• ✓

  Apply the org policy constraint `constraints/sql.requireSsl` at the organization level to enforce SSL on all Cloud SQL instances

  Why this is correct

  The organization policy constraint `constraints/sql.requireSsl` is a boolean constraint that, when enforced at the org level, applies to every project in the hierarchy and prevents Cloud SQL instances from being created (or updated) unless SSL is required. Because the Cloud SQL API checks this policy during instance creation and modification, it stops non-compliant configurations before they exist, covering instances created via Console, gcloud, API, or Terraform. This provides a centralized, deterministic enforcement mechanism that scales to the entire organization without requiring per-instance automation or human intervention. Setting this constraint at the organization level also ensures all future projects automatically inherit the requirement.

Go deeper

Related to this question