Tüm alıştırma soruları

1598 soru

Tüm türler1,598 Çoktan seçmeli815 Çoklu seçim537 Sayısal8 Eşleştirme64 Sıralama174

A fintech company hosts its real-time fraud detection microservice on Google Cloud Run, connected to a Managed Cloud SQL for PostgreSQL database. The development team is preparing a continuous deployment pipeline using Google Cloud Deploy to perform canary releases with gradual traffic splitting across Cloud Run revisions. The upcoming application release requires a breaking database schema modification: renaming a column used in transaction scoring. To maintain zero downtime and ensure the active revision continues processing transactions without errors during the canary phase, which deployment and database strategy should the Cloud Architect recommend?

Apply an expand-contract database migration strategy by first adding the new column and maintaining backward compatibility via triggers or application dual-writing, completing the Cloud Run revision canary deployment, and dropping the legacy column only after 100% traffic is shifted.

Execute a database DDL script to rename the column immediately prior to triggering the 10% canary traffic allocation in Cloud Deploy, relying on Cloud Run auto-rollback if error rates increase.

Migrate the microservice workload from Cloud Run to a Google Kubernetes Engine (GKE) Enterprise cluster with Istio Service Mesh to enforce database transaction isolation at the pod level before running canary deployments.

Deploy a duplicate instance of the Cloud Run revision to an alternative GCP region and instantly shift 100% of production traffic using Cloud Load Balancing without requesting quota updates beforehand.

Cevabı ve açıklamayı göster

Cevap: Apply an expand-contract database migration strategy by first adding the new column and maintaining backward compatibility via triggers or application dual-writing, completing the Cloud Run revision canary deployment, and dropping the legacy column only after 100% traffic is shifted.

Cevap

The architect should enforce an expand-contract (parallel-change) database schema strategy so both active revisions function concurrently during canary traffic splitting.

The correct strategy uses the expand-contract pattern. In canary or blue-green release strategies involving shared stateful backends (such as Cloud SQL), schema changes must be backward-compatible. Adding the new column first allows the baseline revision to continue using the original column while the canary revision utilizes the new schema. Once traffic transition completes successfully, the obsolete column is safely removed.

Adım Adım Çözüm

Analyze the impact of canary deployments on shared database schemas.

During traffic splitting (e.g., 90% version 1, 10% version 2), both application revisions execute queries simultaneously against the same Cloud SQL instance.

Directly applying destructive schema updates (like renaming a column) causes immediate query failures in version 1 instances.

Design the database migration phases (Expand phase).

Add the new database column without altering or dropping the existing column. Update database views, triggers, or application writing logic so writes populate both fields.

Allows existing revision instances to operate normally while preparing the database for the new revision.

Execute the Canary deployment in Google Cloud Deploy.

Gradually shift Cloud Run revision traffic from 0% to 100%. Monitor SLIs (latency, error rate).

Verifies that the new revision operates safely in production under real traffic conditions.

Finalize schema cleanup (Contract phase).

Remove the deprecated database column and cleanup temporary triggers after 100% of traffic is successfully running on the new revision.

Completes technical debt cleanup safely without impacting live application traffic.

Anahtar Kavram

Expand-Contract (Parallel Change) Schema Migration in Canary Deployments

Tahmini Süre:2m 0s

Soru 1122Soru →

An e-commerce platform running on Google Cloud processes order transactions through a fleet of Compute Engine virtual machines managed by a Managed Instance Group (MIG) behind an External HTTP(S) Load Balancer. During a flash sale event, downstream database contention caused transient query latency spikes. Because the load balancer health check was configured to query a deep database endpoint, the load balancer marked all backend instances as unhealthy simultaneously and initiated automated instance replacements, causing a complete service outage. Which architectural modification should you recommend to prevent this cascading operational failure and establish a resilient incident management and alerting workflow?

Reconfigure the load balancer health check to target a lightweight local endpoint that validates only instance web server responsiveness, and implement Cloud Monitoring multi-window SLO burn-rate alerting to manage incident response.

Configure the load balancer health check probes to execute deep database SELECT queries on every probe interval, and set an automated policy to restart instances immediately when health probes fail.

Assign the primitive Owner role to the automated incident remediation service account to grant unconstrained permissions to restart instances and alter VPC load balancer settings during an outage.

Establish static single-window threshold alerts on CPU usage, and apply a broad Cloud Logging exclusion filter to drop all 5xx HTTP application logs during traffic spikes to avoid notification throttling.

Cevabı ve açıklamayı göster

Cevap: Reconfigure the load balancer health check to target a lightweight local endpoint that validates only instance web server responsiveness, and implement Cloud Monitoring multi-window SLO burn-rate alerting to manage incident response.

Cevap

Reconfiguring health checks to monitor a local lightweight endpoint prevents load balancers from mistakenly terminating instances due to downstream dependency bottlenecks. Combining this with Cloud Monitoring SLO burn-rate alerting provides precise operational observability, allowing SRE teams to respond effectively to incident events.

Adım Adım Çözüm

Analyze the root cause of the cascading outage

Identify that the health check endpoint tested downstream database availability rather than local instance responsiveness.

When downstream dependencies slow down, deep health checks fail across all instances simultaneously, leading to mass instance removal by the load balancer.

Isolate health probe concerns from application dependency testing

Modify the HTTP health check path to point to a shallow/lightweight status handler on the web server (e.g., returning HTTP 200 OK).

Shallow health checks ensure the load balancer only routes traffic away from genuinely dead or unresponsive compute instances.

Implement proper incident alerting for user-impacting performance degradation

Create Cloud Monitoring alerting policies based on multi-window SLO burn rates to notify SRE teams when database latency impacts user experience.

Burn-rate alerts trigger timely incident management workflows for sustained error budget consumption without causing unintended infrastructure restarts.

Anahtar Kavram

Incident Management and Health Check Architecture

Soru 1123Soru →

A security architect is configuring keyless authentication for an external CI/CD runner to fetch database credentials stored in GCP Secret Manager. To comply with zero-trust security standards and prevent credential leakage, the architect decides to implement Workload Identity Federation using OpenID Connect (OIDC). What is the correct chronological sequence of administrative steps required to establish keyless authentication and retrieve the secret payload?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence starts with creating the Workload Identity Pool, adding the OIDC Workload Identity Provider, provisioning a dedicated target Service Account with least privilege, binding the external principal using the Workload Identity User role, and finally exchanging the external OIDC token for a short-lived GCP access token via STS.

The correct order follows the standard setup lifecycle for Workload Identity Federation: first establishing the infrastructure container (Workload Identity Pool), then configuring provider authentication parameters (OIDC Provider), provisioning a target identity with least privilege (Service Account with Secret Accessor role), mapping authorization between the external identity and target identity (Workload Identity User role), and executing runtime short-lived token exchange via STS.

Adım Adım Çözüm

Establish the federated container by creating a Workload Identity Pool.

Workload Identity Pool is created in the target GCP project.

The pool serves as the trust boundary for external workloads.

Configure the OIDC Provider within the Workload Identity Pool.

Google Cloud IAM can validate external JWT assertions against the issuer and audience.

Provider settings enable validation and attribute extraction from third-party tokens.

Create the target Service Account and assign the Secret Manager Secret Accessor role.

The Service Account gains granular access to read secret versions without broad project-level permissions.

Adheres to the principle of least privilege.

Grant the Workload Identity User role on the Service Account to the external workload principal.

The external OIDC principal is authorized to impersonate the GCP Service Account.

Establishes authorization for token impersonation.

Perform runtime token exchange via the Security Token Service (STS) and request the secret payload.

The workload receives a short-lived GCP access token and successfully reads the secret payload.

Completes the keyless authentication workflow securely without long-lived keys.

Anahtar Kavram

Workload Identity Federation lifecycle for external keyless authentication to Secret Manager

Soru 1124Soru →

An enterprise payment processing service hosted on Google Cloud Platform has a defined Service Level Objective (SLO) of $99.95\%$ availability for its transaction validation API over a $30$ -day rolling period. The Service Level Indicator (SLI) evaluates a request as good if it returns an HTTP $200\text{ OK}$ status code in under $500\text{ ms}$ .

During a $30$ -day window, the service processes a total of $8,000,000$ requests. Due to a database failover event, $1,800$ requests fail with HTTP $500$ internal server errors. Additionally, $600$ requests successfully return HTTP $200$ but take longer than $500\text{ ms}$ to complete.

What is the maximum number of additional non-compliant requests the service can sustain before its total error budget for this $30$ -day period is completely exhausted?

Cevabı ve açıklamayı göster

Cevap: 1600

Cevap

1,600 requests

The total error budget is calculated as

0.05\%

8,000,000

total requests, which equals

4,000

allowable non-compliant requests. Subtracting the

1,800

HTTP 500 errors and

600

latency threshold breaches (totaling

2,400

bad requests) leaves exactly

1,600

remaining requests in the error budget.

Adım Adım Çözüm

Calculate the total error budget allowance in terms of total non-compliant requests for the 30-day window

Total Error Budget =

8,000,000 \times (100\% - 99.95\%) = 8,000,000 \times 0.0005 = 4,000

requests.

An SLO of

99.95\%

target success rate allows a failure rate of

0.05\%

across all incoming requests within the evaluation window.

Determine the total consumed error budget by summing all bad requests according to the defined SLI criteria

Consumed Budget =

1,800\text{ (explicit HTTP 500 errors)} + 600\text{ (latency breaches above } 500\text{ ms)} = 2,400

non-compliant requests.

The SLI specifies that both HTTP errors and requests exceeding the

500\text{ ms}

latency threshold count against the service reliability budget.

Calculate the remaining allowable non-compliant requests

Remaining Error Budget =

4,000 - 2,400 = 1,600

requests.

Subtracting the already consumed error budget from the initial total budget yields the remaining buffer before SLO violation occurs.

Anahtar Kavram

Calculating Error Budget Consumption using Request-based SLIs

Soru 1125Soru →

A nationwide agricultural supply chain enterprise is modernizing its legacy crop yield forecasting platform by migrating to Google Cloud. Executive stakeholders mandate that the migration must not disrupt regional field teams who have limited cloud experience, while engineering leaders must ensure that infrastructure capacity is fully available prior to the upcoming high-volume harvest season. As the Principal Cloud Architect, which strategy best aligns GCP technical governance with stakeholder and organizational change management requirements?

Conduct a phased regional rollout supported by role-based training programs, while pre-emptively auditing regional resource limits and requesting GCP quota increases well in advance of peak harvest workloads.

Execute a full nationwide cutover during the peak harvest week to avoid parallel running costs, deferring resource capacity expansion requests until automated auto-scaling alerts indicate quota limits are reached.

Accelerate adoption by granting Project Owner primitive IAM roles to regional operation managers so they can bypass central IT bottlenecks and self-provision necessary resources.

Rely strictly on standard IAM user permissions to protect proprietary yield data, opting against VPC Service Controls perimeters to simplify initial network setup for field teams.

Cevabı ve açıklamayı göster

Cevap: Conduct a phased regional rollout supported by role-based training programs, while pre-emptively auditing regional resource limits and requesting GCP quota increases well in advance of peak harvest workloads.

Cevap

Combining a phased regional rollout with targeted training ensures field personnel are properly onboarded without operational disruption. Additionally, proactively requesting GCP quota increases ensures the platform can scale to handle heavy harvest workloads without running into service quota limits.

Adım Adım Çözüm

Analyze stakeholder requirements and change management constraints

Identified the need to manage user adoption risks for non-technical field teams through structured training and phased deployment.

Phased rollouts reduce organizational friction and allow operational teams to adapt gradually without business disruption.

Evaluate GCP capacity and quota management requirements

Determined that peak harvest workloads require requesting quota increases proactively before deployment.

GCP quota adjustments are not instantaneous and must be planned prior to major traffic events to avoid provisioning failures.

Synthesize technical governance with business operational readiness

Selected the solution that combines early quota requests with phased user enablement and governance.

This dual focus fulfills both executive organizational goals and GCP architectural best practices.

Anahtar Kavram

Organizational Change Management and Proactive Infrastructure Governance

Soru 1126Soru →

A Site Reliability Engineering (SRE) team manages a real-time smart grid IoT telemetry ingestion service hosted on Google Cloud using Cloud Run behind an External HTTP(S) Load Balancer, backed by Cloud Bigtable. During recent peak load events, brief traffic micro-bursts caused transient CPU utilization spikes that triggered frequent, unactionable alerts. Furthermore, during a minor database latency degradation, backend instances were prematurely marked unhealthy by the load balancer, precipitating a cascading outage across the entire service. Which TWO architectural modifications should the SRE team implement to eliminate alert fatigue and prevent cascading service failures?

Geçerli olan tümünü seçin

Configure alerting policies using multi-window, multi-burn-rate conditions tied to the service error budget instead of static CPU utilization threshold alerts.

Modify the load balancer health check configuration to query a dedicated lightweight local endpoint that reports instance liveness without validating downstream database connectivity.

Update the load balancer health check configuration to execute a read/write test query against Cloud Bigtable to guarantee true end-to-end service availability.

Reduce the alignment period and trigger duration of static metric threshold alerts to 1 minute so SREs are immediately notified of transient CPU spikes.

Implement a project-wide Cloud Logging exclusion filter for all application logs below ERROR severity to suppress low-priority log volume.

Cevabı ve açıklamayı göster

Cevap: Configure alerting policies using multi-window, multi-burn-rate conditions tied to the service error budget instead of static CPU utilization threshold alerts.; Modify the load balancer health check configuration to query a dedicated lightweight local endpoint that reports instance liveness without validating downstream database connectivity.

Cevap

The SRE team should implement multi-window, multi-burn-rate alerting policies based on service SLO error budgets and configure load balancer health checks to use a lightweight local endpoint that does not query downstream dependencies.

Configuring multi-window burn rate alerting ensures SREs are notified based on sustained SLO consumption rather than transient CPU bursts, resolving alert fatigue. Additionally, separating load balancer health checks from downstream database checks (shallow health checks) prevents database latency from triggering cascading instance removals by the load balancer.

Adım Adım Çözüm

Analyze the root cause of alert fatigue during transient traffic bursts.

Identified that static metric alerts on CPU utilization trigger on short, non-impacting spikes.

Static metric thresholds fail to distinguish between short benign load bursts and sustained user-impacting outages. Multi-window burn rate alerts calculate error budget consumption rate to trigger alerts only when an SLO breach is imminent.

Analyze the root cause of cascading failures during database latency.

Identified that health checks were evaluating downstream database responsiveness.

Health checks must assess local container/instance liveness (shallow health check). If health checks query downstream components like databases, a transient database delay causes the load balancer to mark all app instances unhealthy, triggering a full service blackout.

Anahtar Kavram

SLO Burn-Rate Alerting & Shallow Health Check Patterns

Tahmini Süre:2m 0s

Soru 1127Soru →

A SaaS company operates an online payment processing API on Google Kubernetes Engine (GKE). The platform team needs to implement a unified observability architecture to satisfy two core mandates: securely export operational logs to BigQuery for multi-year compliance analysis without inadvertently filtering out critical system events, and establish proactive alerting that detects sustained Service Level Objective (SLO) degradation rather than reacting to short-term metric noise. Which TWO architecture decisions should the cloud architect recommend?

Geçerli olan tümünü seçin

Create an aggregated Log Router sink at the Google Cloud Organization level with BigQuery as the destination, including explicit inclusion filters for audit and error logs while avoiding aggregate exclusion filters on high-severity events.

Define Service Level Indicators (SLIs) for API request latency and success rates, and configure Cloud Monitoring alerting policies based on multi-window error budget burn rates.

Configure an aggregate exclusion filter on the Log Router sink to drop all logs matching ERROR severity to minimize BigQuery storage and ingestion expenses.

Set up static Cloud Monitoring threshold alerts on pod CPU utilization exceeding 80% to page on-call engineers for immediate incident mitigation.

Grant the primitive Owner IAM role to the Log Router sink's service account to guarantee write access across all target BigQuery datasets.

Cevabı ve açıklamayı göster

Cevap: Create an aggregated Log Router sink at the Google Cloud Organization level with BigQuery as the destination, including explicit inclusion filters for audit and error logs while avoiding aggregate exclusion filters on high-severity events.; Define Service Level Indicators (SLIs) for API request latency and success rates, and configure Cloud Monitoring alerting policies based on multi-window error budget burn rates.

Cevap

The architect should recommend creating an aggregated Log Router sink targeting BigQuery without overbroad exclusion filters, and implementing Cloud Monitoring alert policies based on multi-window error budget burn rates.

Aggregated Log Router sinks at the organization level ensure compliance logs from all projects stream to BigQuery without risk of dropping critical error events. Furthermore, multi-window error budget burn rate alerts effectively identify true service reliability degradation before SLOs are breached.

Adım Adım Çözüm

Evaluate compliance log retention requirements.

Aggregated Log Router sinks configured at the organization level allow central routing of audit and system logs to BigQuery, while ensuring high-severity logs are preserved by avoiding aggressive exclusion filters.

Log exclusion filters intended to reduce costs can inadvertently drop essential error events if configured too broadly.

Evaluate incident alerting requirements.

Configuring alerts based on multi-window error budget burn rates measures the rate at which the service consumes its error budget over time.

Burn rate alerts align directly with SLO impact and eliminate noise caused by brief, self-healing metric spikes.

Anahtar Kavram

Centralized Observability Integration and Error Budget Alerting

Soru 1128Soru →

Your organization is executing a zero-downtime canary deployment for a critical payment-processing microservice on Google Kubernetes Engine (GKE) backed by Cloud SQL for PostgreSQL. The deployment requires adding a mandatory database column without causing application downtime or transaction failures for live users. Sequence the operational steps in the correct order to safely complete this deployment strategy.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The proper sequence follows the expand-contract deployment pattern: first, perform an additive database migration to add the column as nullable; second, initiate a canary deployment with partial traffic shifting; third, promote the release to 100% traffic upon validation; and fourth, finalize the contract phase by applying the NOT NULL constraint to the database column.

Safely deploying application updates dependent on database schema changes requires decoupled, backward-compatible steps. The additive schema migration (Expand) must precede canary traffic shifting. Once the canary release is validated and promoted to 100% traffic across all instances, restrictive schema changes (Contract) can be safely applied.

Adım Adım Çözüm

Execute Expand DDL Migration

The new column is added as nullable to the database schema.

Existing application instances running version 1 do not supply data for the new column and would crash if strict non-null constraints were enforced prematurely.

Deploy Canary Revision and Route Partial Traffic

Version 2 microservice receives 10% of traffic via GKE ingress/Cloud Deploy orchestration.

Allows real-world metric evaluation of version 2 without exposing the entire user base to potential release defects.

Promote Version 2 to Full Production Traffic

100% of incoming requests are handled by version 2 instances.

Ensures complete transition off legacy version 1 code before locking down schema contracts.

Execute Contract DDL Migration

Column schema is updated to NOT NULL and deprecated fields are cleaned up.

Maintains database data integrity once all active workload instances write compliance data.

Anahtar Kavram

Expand-Contract (Parallel Change) Pattern for Database Zero-Downtime Releases

Soru 1129Soru →

An airline company is modernizing its flight operations architecture on Google Cloud. Match each enterprise perimeter security requirement on the left with the correct Google Cloud security mechanism on the right that fulfills it.

Soldaki öğeye tıklayın, sonra eşleşen sağdaki öğeye tıklayın

Cevabı ve açıklamayı göster

Cevap

The enterprise security requirements match as follows: Data exfiltration prevention for GCP APIs maps to VPC Service Controls; Edge HTTP(S) layer 7 protection maps to Google Cloud Armor Security Policy; Mandatory top-down network rule enforcement maps to Hierarchical Firewall Policy; Private non-transitive partner service access maps to Private Service Connect Endpoint.

Each Google Cloud perimeter security mechanism targets a distinct operational boundary: VPC Service Controls secure API-level communication for managed services; Cloud Armor delivers Layer 7 WAF and rate limiting at the load balancer edge; Hierarchical Firewall Policies enforce immutable organization-wide IP/port filtering; Private Service Connect provides targeted, non-transitive endpoint connectivity between separate VPC environments.

Adım Adım Çözüm

Evaluate requirement 1 regarding GCP API exfiltration prevention

Identify that IAM controls user permissions but does not restrict egress destination for API requests. VPC Service Controls create perimeters that restrict data movement outside authorized boundaries.

VPC Service Controls isolate Google-managed platform service resources within defined perimeters.

Evaluate requirement 2 regarding edge application protection

Identify that Google Cloud Armor attaches to Global External HTTP(S) Load Balancers to provide Web Application Firewall (WAF) and DDoS protection.

Cloud Armor inspects L7 request attributes at the Google edge prior to hitting backend instances.

Evaluate requirement 3 regarding centralized firewall enforcement

Identify that Hierarchical Firewall Policies attach to Organization or Folder nodes to enforce non-overridable network rules across all underlying projects.

Project-level VPC firewall rules can be modified by local project admins, whereas Hierarchical policies enforce top-down compliance.

Evaluate requirement 4 regarding isolated service consumption

Identify that Private Service Connect endpoints allow unidirectional connection to consumer services via internal IP mapping without establishing transitive network routing.

VPC Peering exposes full CIDR ranges and does not scale across independent administrative domains as easily as Private Service Connect.

Anahtar Kavram

Designing multi-layered network perimeters using VPC Service Controls, Cloud Armor, Hierarchical Firewalls, and Private Service Connect.

Tahmini Süre:1m 30s

Soru 1130Soru →

A cloud security architect is establishing permission inheritance across a newly created Google Cloud resource hierarchy for an automated compliance audit tool. Arrange the following implementation steps in the correct sequential order, starting from top-level organization governance down to granular resource-level access enforcement.

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct sequence starts with applying Organization-level IAM bindings, followed by creating dedicated Folder nodes, then assigning predefined IAM roles at the Project level, and finally attaching conditional IAM policy bindings on specific Cloud Storage buckets.

In Google Cloud, permissions flow downwards through the resource hierarchy: Organization → Folders → Projects → Resources. Setting up policy governance follows this top-down structure, establishing organization-wide baselines first, structuring organizational folder units next, configuring project IAM roles third, and finally applying fine-grained resource-level bindings at the bottom.

Adım Adım Çözüm

Establish root organization governance

Organization-level IAM bindings provide baseline visibility that inherits down the resource hierarchy.

Permissions in Google Cloud inherit downwards from the Organization root node to all descendant folders, projects, and resources.

Construct folder hierarchy boundaries

Folders organize projects into logical groupings under the Organization node.

Structuring folders enables administrative grouping before assigning project-specific or environment-specific security controls.

Grant project-level roles

Predefined roles bound at the project level control service account access within that project scope.

Project IAM policies narrow down broad organization permissions to project-specific workload requirements.

Enforce resource-level conditional access

Resource-level policy bindings restrict access to specific assets like Cloud Storage buckets.

Applying bindings directly to individual resources provides the most granular enforcement of least privilege at the leaf nodes of the hierarchy.

Anahtar Kavram

Resource Hierarchy Permission Inheritance and Downward IAM Policy Flow

Soru 1131Soru →

During a major regional outage in Google Cloud, your operations team must execute a manual disaster recovery runbook to fail over a web application and its database from the primary region to a secondary standby region. In what order should you perform the following disaster recovery execution steps?

Öğeleri doğru sıraya koymak için sürükleyin

Cevabı ve açıklamayı göster

Cevap

The correct operational sequence is: first, promote the cross-region database read replica to standalone primary status; second, update secondary application workload connections to point to the new database; third, update Cloud DNS routing policies to direct user traffic to the secondary region; and fourth, verify application telemetry and functionality.

Executing disaster recovery requires ensuring data tier readiness prior to application connection updates and traffic redirection. Promoting the cross-region database replica ensures a writable database exists. Reconfiguring the secondary application instances allows them to communicate with the database. Updating Cloud DNS shifts user traffic safely to the secondary region. Finally, operational telemetry verification ensures business continuity success.

Adım Adım Çözüm

Promote Database Replica

Database in the secondary region becomes writable.

Data persistence layer readiness is required before application instances can execute stateful operations.

Reconfigure Secondary Application Workloads

Secondary application instances target the new writable database endpoint.

Prevents database connection failures when incoming requests start arriving.

Reroute External Network Traffic via Cloud DNS

User requests are directed to the secondary region's load balancer.

Traffic should only be introduced once backend infrastructure is fully reconfigured and ready.

Perform System Validation and Telemetry Checks

Confirmed disaster recovery failover completion and operational stability.

Validates that business continuity objectives have been met under live operational conditions.

Anahtar Kavram

Disaster Recovery Failover Execution Sequence

Tahmini Süre:1m 0s

Soru 1132Soru →

A biopharmaceutical enterprise processes sensitive clinical trial datasets stored within Cloud Storage buckets and BigQuery datasets hosted in Google Cloud. The security team requires that internal research applications running on-premises can securely access these resources, but must strictly prevent any credentialed insider or compromised service account from exfiltrating data to external Google Cloud Storage buckets or projects outside the corporate perimeter. IAM policies alone are insufficient to guarantee protection against data exfiltration. Which security architecture should a Professional Cloud Architect implement to satisfy these requirements?

Establish a VPC Service Controls service perimeter enclosing the Cloud Storage and BigQuery resources, and configure Private Service Connect endpoints with ingress rules to allow restricted on-premises access.

Configure fine-grained custom Identity and Access Management (IAM) roles restricting Storage Object Viewer permissions combined with an Organization Policy constraint blocking external IP access.

Set up VPC Network Peering between the on-premises network gateway VPC and the Google Cloud research VPC, relying on default VPC peering transitive routing to isolate traffic from external destinations.

Assign the primitive IAM Owner role to service accounts running the research workloads to enable GCP's automated perimeter protection policies across all project storage endpoints.

Cevabı ve açıklamayı göster

Cevap: Establish a VPC Service Controls service perimeter enclosing the Cloud Storage and BigQuery resources, and configure Private Service Connect endpoints with ingress rules to allow restricted on-premises access.

Cevap

VPC Service Controls creates a perimeter around GCP API services such as BigQuery and Cloud Storage. It blocks unauthorized communication and prevents credentialed users or service accounts from reading data inside the perimeter and copying it to resources outside the perimeter. Combining VPC Service Controls with Private Service Connect allows secure hybrid access from on-premises workloads.

Adım Adım Çözüm

Identify the primary threat vector and security goal

The requirement is to prevent data exfiltration from Google Cloud managed services (Cloud Storage and BigQuery) even by authenticated identities.

IAM permissions grant access to identities but cannot restrict where authorized identities send or copy data once read.

Select the appropriate perimeter security boundary mechanism

VPC Service Controls creates a security boundary around GCP service APIs, preventing data transfers outside the designated perimeter.

VPC Service Controls mitigates exfiltration risks such as unauthorized copying to external storage buckets or projects.

Establish secure hybrid access into the service perimeter

Private Service Connect endpoints combined with perimeter ingress rules enable safe private connectivity from on-premises environments into restricted GCP APIs.

This allows authorized on-premises systems to communicate with the protected GCP services without exposing endpoints to the public internet.

Anahtar Kavram

VPC Service Controls Perimeter & Exfiltration Prevention

Soru 1133Soru →

A enterprise logistics company operates a real-time dispatch routing microservice on Google Kubernetes Engine (GKE) backed by Cloud Spanner. The service maintains a 30-day rolling availability Service Level Objective (SLO) of $99.9\%$ . The development team wants to maximize feature deployment velocity, but the Site Reliability Engineering (SRE) team observes that transient network hiccups cause frequent alert noise, while slow, steady error trends deplete the monthly error budget before human operators are notified. Which TWO operational and alerting strategies should the SRE team implement to manage the error budget effectively and balance velocity with system reliability? (Select TWO.)

Geçerli olan tümünü seçin

Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that evaluate short-term and long-term consumption windows simultaneously to trigger pages and ticket alerts based on budget consumption speed.

Configure a single static threshold alert that pages on-call engineers whenever the HTTP 5xx error rate exceeds 0.1% over any 5-minute rolling window.

Establish an automated policy that halts non-emergency deployment pipelines and shifts engineering focus to reliability engineering whenever the remaining error budget drops below a predefined safety threshold.

Set up primary paging alerts on GKE node pool CPU and memory utilization exceeding 85% to detect system degradation before SLO violations happen.

Cevabı ve açıklamayı göster

Cevap: Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that evaluate short-term and long-term consumption windows simultaneously to trigger pages and ticket alerts based on budget consumption speed.; Establish an automated policy that halts non-emergency deployment pipelines and shifts engineering focus to reliability engineering whenever the remaining error budget drops below a predefined safety threshold.

Cevap

The correct strategies are implementing multi-window, multi-burn-rate alerting policies in Cloud Monitoring and establishing an automated deployment freeze policy triggered by error budget consumption.

The combination of multi-window multi-burn-rate alerting and automated deployment policy freezes forms the core foundation of GCP SRE error budget management. Multi-window multi-burn-rate alerting measures how quickly the budget is consumed across different time intervals, avoiding false positives from short spikes while accurately catching fast and slow budget burns. Automated deployment freeze policies directly balance deployment velocity with availability by using remaining budget as the quantitative signal for releasing features versus working on stability.

Adım Adım Çözüm

Evaluate alerting strategy requirements for SRE practices.

Identified that static alerts cause high noise during temporary spikes and fail to measure total budget consumption rates over time.

Google SRE best practices recommend multi-window, multi-burn-rate alerts (such as evaluating 1-hour 14x burn rate for immediate pages and 6-hour 6x burn rate for ticket creation) to balance alert precision and recall.

Evaluate governance strategies for error budget management and deployment velocity balance.

Identified that error budget policies provide a formal mechanism to control deployment velocity based on current reliability reserves.

When error budget reserves fall below critical thresholds, halting feature releases enforces reliability work until the budget recovers.

Anahtar Kavram

Error Budget Management and Multi-Window Burn-Rate Alerting

Soru 1134Soru →

An enterprise organization needs to centralize operational and security audit logs across multiple Google Cloud projects into a designated security operations project. The solution must ensure secure, least-privilege log delivery to a central BigQuery dataset while excluding low-severity debug logs to control storage costs, without dropping high-severity operational events. Which TWO actions should you take to implement this architecture?

Geçerli olan tümünü seçin

Create an aggregated Log Router sink at the Google Cloud Organization level targeting the destination BigQuery dataset, using an inclusion filter for severity ERROR and audit logs.

Grant the unique writer identity service account generated by the Log Router sink the BigQuery Data Editor role on the target destination dataset.

Configure a global log exclusion filter set to drop all cloudaudit.googleapis.com records across the organization to minimize ingestion bandwidth.

Assign the Owner primitive IAM role to the Log Router service account across all projects to ensure unrestricted write access.

Rely strictly on project IAM read permissions to prevent authorized analysts from copying dataset contents to external storage buckets.

Cevabı ve açıklamayı göster

Cevap: Create an aggregated Log Router sink at the Google Cloud Organization level targeting the destination BigQuery dataset, using an inclusion filter for severity ERROR and audit logs.; Grant the unique writer identity service account generated by the Log Router sink the BigQuery Data Editor role on the target destination dataset.

Cevap

Creating an aggregated Log Router sink at the organization level with an inclusion filter for required high-severity logs, and granting the sink's generated writer identity least-privilege write permissions (BigQuery Data Editor) on the central dataset.

Centralized observability across multiple projects is best achieved by establishing an aggregated Log Router sink at the Organization level with targeted log filters. The sink automatically receives a unique writer identity service account, which must be granted minimum required permissions (such as BigQuery Data Editor) on the destination dataset to adhere to security best practices.

Adım Adım Çözüm

Define centralized log routing scope

Aggregated Log Router sink created at the organization level to capture logs across child projects.

Organization-level sinks automatically aggregate logs across all current and future projects in the resource hierarchy.

Configure filter and destination

Filter set to include severity ERROR and audit logs, targeting a central BigQuery dataset.

Filtering controls log ingestion volume and cost while ensuring critical operational events are preserved.

Grant writer identity permissions

Sink writer identity granted BigQuery Data Editor on the central dataset.

Log Router relies on a dedicated service account identity that requires explicit destination authorization under least privilege.

Anahtar Kavram

Centralized Log Router Sinks & Least-Privilege Log Export Architecture

Soru 1135Soru →

A financial data analytics platform runs microservices on Google Cloud that generate log entries during routine nightly database maintenance. These maintenance activities cause temporary error logs for up to 3 minutes, which currently trigger false alarms and wake up on-call engineers. Operations requirements mandate that genuine outages—where error log rates persist beyond 5 minutes—must automatically initiate incident workflows via Cloud Pub/Sub and notify PagerDuty, without losing error logs required for compliance auditing. How should you configure the Cloud Monitoring alerting policy to satisfy these operational requirements?

Create a log-based metric for error logs, and set the alert policy condition duration to 5 minutes before triggering notifications to Pub/Sub and PagerDuty.

Configure Cloud Logging aggregate exclusion filters to drop all database error log entries automatically during the nightly maintenance window.

Reconfigure the backend Load Balancer health checks to execute a deep query against the primary database every 3 seconds to auto-drain traffic during maintenance.

Assign the primitive Owner role to the monitoring service account and configure static zero-delay threshold alerts that trigger local shell scripts on a management VM.

Cevabı ve açıklamayı göster

Cevap: Create a log-based metric for error logs, and set the alert policy condition duration to 5 minutes before triggering notifications to Pub/Sub and PagerDuty.

Cevap

Create a log-based metric for error logs, and set the alert policy condition duration to 5 minutes before triggering notifications to Pub/Sub and PagerDuty.

Configuring a log-based metric with an alert condition duration of 5 minutes ensures that transient error bursts occurring during 3-minute maintenance windows do not trigger on-call alerts, while genuine sustained issues immediately trigger incident response notifications through Pub/Sub and PagerDuty.

Adım Adım Çözüm

Analyze the operational issue

Transient log errors last up to 3 minutes during routine maintenance, causing alert fatigue.

Alert policies without appropriate duration windows trigger immediately upon single spikes or short error bursts.

Configure metric evaluation window and condition duration

Using a log-based metric combined with a 5-minute alert condition duration filters out short-lived maintenance noise while capturing sustained incidents.

Cloud Monitoring alert policy duration settings require conditions to remain true continuously for the specified time before triggering notification channels.

Connect notification channels

Route alerts to PagerDuty and Pub/Sub for automated incident response workflows without suppressing log ingestion.

Maintains log retention for compliance while automating incident triage.

Anahtar Kavram

Cloud Monitoring Alert Policy Duration & Log-based Metric Filtering

Soru 1136Soru →

A global media streaming platform operates a rights-management API running on Google Kubernetes Engine (GKE) behind an External HTTP(S) Load Balancer. The service has a defined Service Level Objective (SLO) of $99.99\%$ availability over a rolling 30-day window. SRE teams are currently suffering from alert fatigue caused by transient error spikes triggering immediate paging alerts, while simultaneously failing to catch slow, sustained error budget consumption that exhausts their 30-day budget prior to monthly reviews. Which alerting approach should a Cloud Architect recommend to ensure actionable notifications based on actual risk to the error budget?

Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that consume short (e.g., 5-minute/1-hour) and long (e.g., 6-hour/3-day) lookback windows to alert based on the rate of error budget depletion.

Configure static threshold alerts in Cloud Monitoring that trigger an urgent paging notification whenever the 5-minute aggregate HTTP 5xx error rate exceeds

0.01\%

Set up GKE Horizontal Pod Autoscaler (HPA) policies based exclusively on CPU utilization and memory consumption to automatically mitigate 5xx errors.

Redefine the Service Level Indicator (SLI) metric target to

99.99\%

container CPU health and issue pings when container CPU consumption surpasses

85\%

Cevabı ve açıklamayı göster

Cevap: Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that consume short (e.g., 5-minute/1-hour) and long (e.g., 6-hour/3-day) lookback windows to alert based on the rate of error budget depletion.

Cevap

Implement multi-window, multi-burn-rate alerting policies in Cloud Monitoring that evaluate both short and long lookback windows to alert based on the rate of error budget consumption.

Implementing multi-window, multi-burn-rate alerts in Cloud Monitoring is the SRE best practice for managing SLOs. By pairing a short lookback window (ensuring quick response to severe outages) with a long lookback window (ensuring errors are still ongoing and not transient noise), teams can trigger pages for rapid budget consumption and open support tickets for slow budget burn without experiencing alert fatigue.

Adım Adım Çözüm

Analyze the operational problem and SLO requirements

The API has a target SLO of

99.99\%

over 30 days, leaving an error budget of

0.01\%

. Transient spikes cause alert fatigue, while slow errors burn budget unnoticed.

Static threshold alerting fails to balance reset speed (alerting quickly on critical outages) with precision (avoiding alerts on minor brief spikes).

Evaluate SRE best practices for Google Cloud Monitoring SLO alerting

Multi-window multi-burn-rate alerts monitor both recent activity (short window) and sustained trend (long window) across multiple burn rate multiples (e.g., 14.4x for fast burn, 2x for slow burn).

This guarantees that an alert is triggered only when the error budget is genuinely at risk of depletion, avoiding unnecessary pages while catching persistent issues early.

Compare against distractor strategies

Static 5xx threshold alerts cause alert fatigue; CPU-based HPA does not remedy software error codes; infrastructure resource metrics are invalid SLIs for availability.

Only multi-window multi-burn-rate alerting correctly measures error budget consumption rate.

Anahtar Kavram

Multi-Window Multi-Burn-Rate Alerting on Error Budgets

Tahmini Süre:2m 30s

Soru 1137Soru →

A healthcare technology provider is deploying a major version update to its patient telemonitoring microservice hosted on Google Cloud Run and backed by a Cloud SQL for PostgreSQL database. The release requires structural changes to relational data tables and uses Cloud Deploy for canary traffic shifting. Which TWO engineering practices should be implemented in the deployment strategy to guarantee zero downtime and prevent service failures during the rollout?

Geçerli olan tümünü seçin

Apply an expand-contract database migration strategy, ensuring schema modifications remain backward-compatible with the active application revision prior to initiating traffic splitting.

Execute destructive database DDL modifications simultaneously when shifting initial canary traffic to synchronize database fields with new application code.

Configure automated canary verification and rollback criteria in Cloud Deploy based on Cloud Monitoring error budget and latency metrics.

Replatform the stateless Cloud Run microservice to a multi-zone Google Kubernetes Engine (GKE) cluster specifically to enable basic HTTP revision traffic allocation.

Cevabı ve açıklamayı göster

Cevap: Apply an expand-contract database migration strategy, ensuring schema modifications remain backward-compatible with the active application revision prior to initiating traffic splitting.; Configure automated canary verification and rollback criteria in Cloud Deploy based on Cloud Monitoring error budget and latency metrics.

Cevap

The deployment strategy must incorporate an expand-contract database schema migration pattern and automated canary verification using Cloud Deploy integrated with Cloud Monitoring metrics.

Zero-downtime releases backed by relational databases require strict separation between schema migrations and application rollouts. An expand-contract schema pattern ensures that additive database modifications remain compatible with both old and new code versions. Furthermore, using Cloud Deploy automated canary verification enables real-time metric tracking and automatic rollback if the new revision exhibits abnormal error behavior.

Adım Adım Çözüm

Decouple database schema changes from application code deployment by using an expand-contract pattern.

Database changes (such as adding new columns as nullable) allow both legacy and new application revisions to function concurrently during traffic shifting.

Prevents active legacy instances from throwing database query errors during the canary phase.

Leverage Cloud Run's native revision traffic splitting combined with Cloud Deploy release pipelines.

Traffic can be incrementally routed (e.g., 10%, 50%, 100%) to the candidate revision.

Allows real-world validation on a subset of user traffic with minimal blast radius.

Configure Cloud Deploy automated verification rules using Cloud Monitoring metrics.

High error rates or latency anomalies trigger an automatic rollback to the original stable revision.

Ensures immediate recovery if regressions are detected during rollout.

Anahtar Kavram

Decoupled database migrations (expand-contract) combined with automated canary deployment and rollback triggers.

Soru 1138Soru →

An enterprise financial company uses a Google Cloud Organization hierarchy containing a parent folder named `Financial-Core-Prod` that holds multiple production projects. The security team needs to grant an external compliance audit firm read-only access to view infrastructure resource configurations, security policies, and IAM bindings across all present and future projects within `Financial-Core-Prod`. The audit firm must not have access to view underlying data inside Cloud Storage buckets or modify any resource configurations. Which IAM assignment strategy meets these requirements while adhering to Google Cloud best practices for resource hierarchy and least privilege?

Grant the predefined `roles/iam.securityReviewer` role to the audit firm's Google Group at the `Financial-Core-Prod` folder level.

Grant the primitive `roles/viewer` role to the audit firm's Google Group at the `Financial-Core-Prod` folder level.

Create a dedicated audit service account, grant it `roles/iam.serviceAccountAdmin` at the Organization level, and download service account keys for the auditors.

Grant `roles/editor` to the auditors on each project individually and rely on VPC Service Controls perimeters to block data exfiltration.

Cevabı ve açıklamayı göster

Cevap: Grant the predefined `roles/iam.securityReviewer` role to the audit firm's Google Group at the `Financial-Core-Prod` folder level.

Cevap

Grant the predefined role Security Reviewer (roles/iam.securityReviewer) to the auditor Google Group at the folder level.

Granting the predefined Security Reviewer role (`roles/iam.securityReviewer`) to a Google Group at the folder level leverages resource hierarchy inheritance. All current and future projects beneath that folder inherit the policy, allowing auditors to inspect security configurations and resource metadata across the environment without accessing object data or requiring broad primitive roles.

Adım Adım Çözüm

Identify the scope of access required across multiple projects.

The target scope encompasses all present and future projects under the `Financial-Core-Prod` folder.

Applying the IAM policy at the folder node allows permissions to naturally inherit down to all child project nodes, minimizing operational management overhead.

Determine the role that provides security metadata inspection without data access.

The Security Reviewer role (`roles/iam.securityReviewer`) grants permissions to inspect IAM policies, network configurations, and resource metadata without granting access to data payloads.

This adheres strictly to least privilege compared to broad primitive roles or administrative permissions.

Anahtar Kavram

Resource Hierarchy Permission Inheritance and Predefined IAM Roles

Soru 1139Soru →

Match each Google Cloud service local development requirement with the appropriate emulator configuration command or environment variable required to bind client SDKs to local testing environments.

Soldaki öğeye tıklayın, sonra eşleşen sağdaki öğeye tıklayın

Cevabı ve açıklamayı göster

Cevap

Each Google Cloud service emulator requires specific startup flags via gcloud CLI and corresponding environment variables (PUBSUB_EMULATOR_HOST, SPANNER_EMULATOR_HOST, DATASTORE_EMULATOR_HOST, BIGTABLE_EMULATOR_HOST) to redirect client library traffic locally without real cloud credentials.

Google Cloud client SDKs automatically detect emulator environment variables (e.g., `PUBSUB_EMULATOR_HOST`, `SPANNER_EMULATOR_HOST`, `DATASTORE_EMULATOR_HOST`, `BIGTABLE_EMULATOR_HOST`). When set, client calls are automatically redirected to the specified localhost ports without requiring production service account credentials or project authorization.

Adım Adım Çözüm

Identify the target GCP service being emulated in local development.

Map Pub/Sub, Spanner, Datastore, and Bigtable to their respective emulator commands.

Each service uses a dedicated `gcloud` sub-command component for local emulation.

Determine specific emulator runtime parameters such as in-memory state flags.

Match `--no-store-on-disk` to the ephemeral Datastore configuration requirement.

Preventing disk persistence ensures fast, isolated, clean unit test environments.

Identify the standard environment variable required by GCP client SDKs for each service emulator.

Pair service name to host variable: PUBSUB_EMULATOR_HOST, SPANNER_EMULATOR_HOST, DATASTORE_EMULATOR_HOST, and BIGTABLE_EMULATOR_HOST.

GCP client SDKs check for these environment variables at instantiation to redirect connection endpoints away from production GCP APIs.

Anahtar Kavram

Local GCP Service Emulators and Environment Configuration

Soru 1140Soru →

An enterprise financial platform deployed on Google Compute Engine Managed Instance Groups (MIGs) runs an I/O-bound microservice that handles persistent gRPC connections and database transactions. During high-volume marketing campaigns, request latencies increase drastically due to database connection pool exhaustion and thread waiting, but the MIG autoscaler fails to launch additional instances because host CPU utilization stays around 30%. Furthermore, during sudden unexpected traffic spikes, dynamic scaling attempts intermittently stall due to regional compute resource limitations. Which architectural strategy should a Cloud Architect implement to ensure auto-scaling responsiveness and capacity reliability?

Configure the MIG autoscaler to use custom Cloud Monitoring metrics tracking active database connection pool saturation and pending request queue depth, while requesting regional quota increases and securing reservations prior to peak events.

Lower the target CPU utilization threshold on the existing MIG autoscaler from 80% to 25% so that new instances are triggered earlier during I/O wait states.

Configure the autoscaling policy using Cloud Pub/Sub backlog metrics while relying entirely on default dynamic Compute Engine provisioning to scale up to the maximum instance limit during traffic spikes.

Migrate the microservice workload to a Google Kubernetes Engine (GKE) Autopilot cluster and configure the Horizontal Pod Autoscaler (HPA) to scale pods strictly using standard cluster memory consumption metrics.

Cevabı ve açıklamayı göster

Cevap: Configure the MIG autoscaler to use custom Cloud Monitoring metrics tracking active database connection pool saturation and pending request queue depth, while requesting regional quota increases and securing reservations prior to peak events.

Cevap

For I/O-bound workloads constrained by database connections or concurrency rather than host processing, CPU metrics do not reflect actual system load. Utilizing custom Cloud Monitoring metrics (such as active connection count or pending queue depth) ensures the autoscaler responds accurately to load increases. Furthermore, proactive capacity planning—including requesting quota adjustments and purchasing reservations—guarantees that Compute Engine has sufficient available resources during large scale-up events.

Adım Adım Çözüm

Analyze workload resource bottlenecks.

Identified that the service is I/O-bound, meaning host CPU utilization remains low even when connection pools and request queues are saturated.

Standard CPU metrics are ineffective for autoscaling workloads constrained by network, database connections, or thread waiting.

Select appropriate autoscaling metric signals.

Expose application-level custom metrics (connection pool utilization, queue depth) to Cloud Monitoring and target these in the MIG autoscaling policy.

Custom metrics accurately reflect true application load and trigger scaling before user latency degrades.

Address capacity and quota limitations for peak events.

Verify regional compute quotas and acquire On-Demand or Compute Engine Reservations in advance of anticipated events.

Autoscaling policies cannot provision instances beyond project quotas or regional physical resource availability.

Anahtar Kavram

Custom Metric Autoscaling & Capacity Reservation

ÖncekiSayfa 57 / 80Sonraki

Tüm alıştırma soruları

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Cevap

Adım Adım Çözüm

Anahtar Kavram