CCNA Ace Ensuring Operation Questions

In Cloud Logging, a logs-based metric is created by defining a filter that selects which log entries increment the metric's counter. This filter is the heart of the metric because it evaluates each incoming log entry against conditions such as severity >= ERROR or a text payload match. Without it, the metric has no way to distinguish error logs from other entries, so the filter directly determines the metric's value and is therefore required.

This command reverts the Deployment to the previous revision by rolling back to the last good ReplicaSet. The Deployment controller will scale down the current ReplicaSet and scale up the old one, restoring the previous container image and configuration. This is the correct, built-in way to undo a bad deployment while maintaining availability.

This is the correct command for splitting traffic between already deployed revisions: `gcloud run services update-traffic` with `--to-revisions` takes a comma-separated list of `revision=percentage` pairs (v1=90,v2=10) and applies the routing immediately. The specified revisions must exist and the percentages must total 100. It does not create a new revision, so it is the appropriate operation after v1 and v2 have both been deployed.

After you generate a chart in Metric Explorer, adding it to a dashboard persists the visualization as a widget in a chosen layout, making it visible to the team and available in the Monitoring UI. This is the final, required step to actually place the metric on the dashboard; without it, the chart exists only in the temporary Metric Explorer session and will be lost when you navigate away.

Data Access audit logs capture read and write operations on Cloud Storage. Enabling them ensures all access is logged. A log sink to BigQuery exports the logs for analysis, and setting the dataset's default table expiration to 365 days ensures retention for at least one year. This meets all requirements.

Cloud Trace Trace List and Trace Details is the correct service because the Trace List displays each sampled request as a row with its overall latency, while Trace Details opens a waterfall chart that breaks the request into individual spans. In a Cloud Run service, this shows time spent in container startup, internal logic, and downstream calls, making it possible to pinpoint exactly which span causes an intermittent slowdown. The per-request, span-level granularity directly matches the need to diagnose variable performance.

The correct sequence is to first stop the instance with `gcloud compute instances stop INSTANCE_NAME`, then run `gcloud compute instances set-machine-type INSTANCE_NAME --machine-type MACHINE_TYPE` while the instance is in the TERMINATED state, and finally start it again with `gcloud compute instances start INSTANCE_NAME`. This preserves the instance's boot disk, persistent disks, static IP, metadata, and other configuration, and is the standard non-destructive way to resize a VM.

Choosing several geographic locations makes the uptime check probe the endpoint from distinct regions, so an outage or regional network fault is distinguished from a localised failure. This directly satisfies the requirement to monitor availability from multiple locations around the world.

`--use_legacy_sql=false` is the required flag because the `bq` command-line tool historically defaults to legacy SQL when running queries. Legacy SQL uses a different syntax and operates differently from standard GoogleSQL (e.g., unique handling of JOINs and functions). Passing `false` explicitly switches the parser to standard SQL, allowing the developer's query to run without rewriting it into legacy dialect.

Cloud Trace is the Google Cloud service specifically designed for distributed tracing: it captures spans from instrumented applications or via OpenTelemetry, groups them into traces for each request, and renders a waterfall view showing where time is spent across microservices. It supports latency distribution analysis, allows comparison of recent traces, and can identify bottleneck services and anomalously slow requests. Thus it directly answers the need to collect and analyze latency traces.

Using a custom image with pre-installed dependencies is the correct approach because it directly reduces node initialization time. A custom image can bake in the container runtime, required OS packages, and even pre-cached application container images, avoiding the typical runtime download and configuration steps when a new node is added. When the cluster autoscaler triggers a scale-out, these nodes become schedulable faster, so pending pods are scheduled more quickly.

bq query --use_legacy_sql=false --dry_run 'SELECT ...' sends the query to BigQuery's planner, which validates the SQL and returns the estimated number of bytes that would be read from storage, without actually executing the query or consuming slots. The --use_legacy_sql=false flag ensures your statement is parsed as standard SQL, not the older legacy dialect, which matters for syntax compatibility. This is exactly the right tool when a query is slow and you want to quickly see how much data it touches before investing time in optimization or running it.

`gcloud run services update-traffic` is the correct command to split traffic between two or more existing revisions of a Cloud Run service. It accepts flags like `--to-revisions=rev1=50,rev2=50` to assign precise percentages, or `--to-latest` to route all traffic to the latest revision. This command directly modifies the route resource, making it the appropriate tool for controlled canary rollouts or rollbacks.

kubectl rollout undo deployment/my-app is the correct command because it reverts the deployment to the previous revision, restoring the prior pod template spec and container image. Kubernetes retains rollout history for each change to the pod template, and undo automatically scales down the current ReplicaSet and scales up the previous one, seamlessly rolling back the application without manual image specification.

Cloud Trace is purpose-built for latency analysis. It collects latency data from Cloud Run and other GCP services, then generates distributed traces with spans that show the duration of each operation—such as receiving the request, calling downstream dependencies, and returning the response. Trace features like waterfall views, latency distributions, and per-trace breakdowns let you identify exactly which service or API call is the bottleneck, making it the correct tool for high-latency issues.

This metric tracks the maximum age of the oldest message that has not yet been acknowledged by any subscriber for the subscription. It directly reflects backlog depth and consumer lag: when a subscription is accumulating a backlog, this value grows steadily because messages sit unacked for longer periods. It is the ideal signal for alerting on message processing delays because it captures the time dimension of the backlog, not just its size.

Cloud Monitoring is the correct starting point because it provides time-series metrics for Compute Engine, such as CPU utilization, memory usage, disk I/O, and network throughput. You can build custom dashboards and alerts to correlate intermittent latency spikes with resource saturation, helping you determine whether the cause is a bottleneck in the VM, disk, or network. This metric-centric view is essential for seeing the pattern of when slowdowns occur.

This is the correct diagnostic. A log sink only forwards entries that match its inclusion filter, and an overly narrow filter—such as one restricted to a single resource type or severity level—will silently exclude the rest of the log stream before it reaches BigQuery. Check the sink's filter in the Logs Explorer to confirm it matches the actual log entries you expect to export, and note that any exclusion filters are applied after the inclusion filter and can further reduce the data routed.

This is the correct gcloud command to enable cluster autoscaler on a specific node pool. The `--enable-autoscaling` switch turns on autoscaling for the `default-pool`, and the `--min-nodes 1` and `--max-nodes 10` flags define the minimum and maximum size of the node pool. With this configuration, GKE's cluster autoscaler will automatically add or remove nodes within that range based on pending pod resource requests, which directly relieves the low-resource condition on the cluster's nodes.

Metric threshold is the standard condition type used in a Cloud Monitoring alerting policy. It evaluates a metric stream (e.g., Compute Engine CPU utilization, disk bytes used) against a numeric threshold over a specified aggregation window, triggering notifications when the value crosses the threshold. This is the correct answer because it directly defines the alerting condition that the engineer needs.

Without an external IP address, the instance cannot receive traffic from the internet. Adding an external IP (ephemeral or static) enables the instance to communicate with external clients. The firewall rule already permits ingress on tcp:80, so once the instance has an external IP, traffic will reach it. This is the correct action.

This is the only correct sequence: first stop the instance (gcloud compute instances stop), which transitions it to the TERMINATED state, then call gcloud compute instances set-machine-type with the desired type (predefined, custom, or E2), and finally start the instance again. The stop/start cycle is required because the hypervisor must release the old vCPU and memory resources before the new allocation can be applied. After the instance starts, it retains its existing disks, IP addresses, and metadata, so no configuration is lost.

A log sink is the correct Cloud Logging resource for streaming log entries to a supported destination, and BigQuery is a first-class destination. When you create a sink with `gcloud logging sinks create` or in the console, you specify a BigQuery dataset as the destination; Cloud Logging then continuously routes exported log entries into a partitioned table. This satisfies the requirement to export all logs from the project, optionally filtered by a log query.

This is the correct command. The attach-disk subcommand belongs to gcloud compute instances, takes web-server-1 as the resource, and uses --disk my-disk to specify the existing persistent disk to attach. It associates the already provisioned 100 GB disk with the instance, and requires the disk and instance to be in the same zone (or use --zone if they are not set).

The filter combines the required resource type with a relative timestamp and severity comparison. `resource.type="gce_instance"` scopes results to the Compute Engine instance, `timestamp>="-1h"` restricts to the last hour, and `severity>=ERROR` returns ERROR and above, satisfying every constraint in the stem.

An alerting policy is the correct resource in Google Cloud Monitoring for triggering notifications based on a specific metric condition. It contains one or more conditions (e.g., metric crosses a threshold for a set duration) and references a notification channel to deliver the alert. Without an alerting policy, no metric evaluation or notification can occur.

This is the correct approach because BigQuery must already exist as a dataset for the log sink to write into, and the sink's underlying writer identity (the service account) needs the BigQuery Data Editor role (roles/bigquery.dataEditor) on that dataset to create tables and insert log entries. You first create the dataset, then configure the log sink with BigQuery as its destination, and after the sink is created you copy its service account ID and grant that service account the required IAM role. Without that grant, the sink will fail with permission errors when trying to deliver logs to BigQuery.

Running 'gcloud run deploy my-service --image gcr.io/my-project/my-app:v2' is the correct way to update a Cloud Run service's container image. The deploy command prepares a new immutable revision with the specified image, makes it the latest revision, and automatically routes traffic to it according to your service's traffic policy. Existing revisions are preserved in the revision history, enabling immediate rollback via 'gcloud run services update-traffic' if the new revision misbehaves.

Cloud Trace provides distributed tracing with per-span and per-service latency breakdowns, capturing the full path of a message as it flows through Pub/Sub and downstream services. Its waterfall view and latency distributions reveal exactly which step—from publish to processing—contributes the most delay. It is the only tool among these options specifically designed to analyze per-step latency in a distributed, asynchronous pipeline.

Checking the subscription's backlog, either in the Pub/Sub console or via the `gcloud pubsub subscriptions describe` command, gives a direct numeric measurement of how many messages are unacknowledged and waiting to be redelivered. A consistently growing backlog relative to the publish rate indicates the subscriber cannot keep up with the incoming flow. This is the first diagnostic step because it confirms whether the bottleneck is on the delivery side or the processing side without instrumenting any application code.

Draining with `--ignore-daemonsets` leaves DaemonSet pods running, preserving node-level system components, while `--delete-emptydir-data` permits eviction of pods holding emptyDir volumes that would otherwise block the drain. Both flags together satisfy the stem's requirement to handle these pods without disrupting critical components.

Creating a log sink with a BigQuery dataset destination routes matching log entries into BigQuery tables, satisfying the organisation-wide export requirement. Sink inclusion filters can scope the sink across all projects when created at the organisation level, enabling centralised long-term analysis without per-project configuration.

gcloud compute instances attach-disk is the correct command: it attaches an existing zonal or regional persistent disk to a specified Compute Engine instance, using --disk and optionally --device-name. It works on both running and stopped instances, and it ensures the disk becomes visible as a block device in the instance's guest OS.

This is correct because Cloud Monitoring supports notification channels for email, SMS, and other services. To receive alerts via email and SMS, you must create those channels and associate them with the alerting policy. Without notification channels, the alert would trigger but no notifications would be sent.

A log sink with a filter and a BigQuery destination is the fully managed, native way to export logs: Cloud Logging continuously routes any newly ingested log entries that match the filter into a specified BigQuery dataset. The sink automatically creates a table with the log schema, and you can use the _PARTITIONTIME pseudo-column for time-based partitioning. This gives reliable, near-real-time export without custom code or manual intervention.

Uptime checks in Cloud Monitoring are the managed, intended way to verify that an external HTTP endpoint is reachable and returning expected responses from multiple locations across the globe. The check_failed metric increments each time a probe fails, and a metric-threshold alerting policy lets you define a condition—for instance, when the number of failed checks is consistently above zero over a specified period—and route it to an email notification channel. This directly implements the requirement without custom code.

A log sink with BigQuery as the destination is the correct method: Cloud Logging's log router matches your chosen log entries and delivers them to a BigQuery dataset, where each daily collection becomes a table. You configure the destination by providing a dataset name, and the sink automatically handles batching and streaming writes. This is the officially supported, commonly used way to export logs to BigQuery for analytics.

`kubectl drain` gracefully evicts all pods from the node while respecting PodDisruptionBudgets, making the node unschedulable and empty for maintenance. The `--ignore-daemonsets` flag skips DaemonSet-managed pods, which are intended to run on every node and would otherwise block eviction, while `--delete-emptydir-data` allows deletion of pods using emptyDir volumes, which would otherwise prevent the drain from finishing. These flags together ensure the command completes cleanly on nodes with these pod types.

To change the machine type of a Compute Engine instance, you must first stop it, which brings it to the TERMINATED state. While stopped, the persistent disks and instance settings remain intact, but any data on local SSDs is permanently lost because local SSDs are ephemeral storage tied to the host server. After updating the machine type, you start the instance; this process is the only supported way to resize an instance's vCPU and memory.

Increasing the number of subscribers (i.e., scaling out the subscriber fleet) directly raises the aggregate processing throughput of the subscription. Because the intermittent high latency is likely due to a backlog of messages accumulating faster than the current subscribers can drain, adding more subscribers allows messages to be pulled and processed in parallel, reducing the queue depth and lowering end-to-end latency. This is the correct scaling action for a latency problem caused by insufficient compute, assuming the subscribers are stateless and can process messages independently.

A log sink in Cloud Logging's Router exports matching log entries to a destination such as BigQuery, Cloud Storage, or Pub/Sub. By configuring a sink with BigQuery as the destination and a filter that matches all logs (or empty filter), you continuously export your project's logs to a BigQuery dataset for analysis and long-term retention. This is the standard and only fully supported mechanism for exporting Cloud Logging logs to external services.

Cloud Trace is a distributed tracing service designed to collect latency data from Google Cloud and measure time spent in each service and API call during a request. It provides detailed per-request traces with spans that show the timing of each operation, making it the correct tool to investigate high application latency. By analyzing the waterfall view of spans, you can identify the exact component responsible for the delay across distributed services.

kubectl set image directly updates the Deployment's pod template to reference the v2 image, which triggers a rolling update orchestrated by the Deployment controller. kubectl rollout status then watches that update to completion, returning a non-zero exit code if the rollout fails (e.g., due to crash-loops or insufficient readiness), which is the correct signal for conditional rollback. kubectl rollout undo reverts to the previous revision, but note it should be gated on that failure in practice; even so, this is the only option that uses the proper Kubernetes-native commands for image update, rollout monitoring, and rollback.

This is the correct command because it targets an existing node pool (`my-pool`) within the specified cluster and toggles the GKE cluster autoscaler on for that pool. The `--min-nodes=1` and `--max-nodes=10` flags define the scaling boundaries, allowing the pool to resize within those limits based on resource demand. The `--cluster` flag scopes the operation to the right cluster, and the update command modifies the live pool without recreating it.

The alerting policy is the actual alerting mechanism in Cloud Logging. It defines the conditions that trigger an incident, such as a threshold on a metric (e.g., a log-based metric exceeding a value) and specifies the notification channels (email, Slack, etc.) to receive alerts. Without an alerting policy, a log-based metric only counts or samples log entries; it does not perform any active monitoring or notify anyone.

The subscription's backlog size is the primary indicator of delivery problems: it counts messages that have been published but not yet acknowledged. When troubleshooting a subscription that is not delivering, an ever-growing backlog means messages are arriving faster than the subscriber can process them, or the subscriber has stopped pulling entirely. Large backlog also correlates with slow processing and can help you decide whether to scale out subscribers or inspect subscriber logs.

Stopping the instance transitions it to the TERMINATED state, which releases the underlying host resources while preserving the boot disk, metadata, and attachment of persistent disks. The `gcloud compute instances set-machine-type` command can then change the vCPU and memory allocation, and after that you start the instance. This is the correct workflow because Compute Engine rejects machine type changes on running instances.

A Cloud Function with a Pub/Sub trigger is the compute piece that executes your custom response logic asynchronously. When a message lands on the subscribed topic, the function is invoked with the message payload, letting you parse the log data and call external APIs, send alerts, or modify resources. This event-driven model avoids maintaining a server and scales automatically with message volume. Without this function, the sink and topic would merely transport logs with no automated reaction.

An uptime check is a Cloud Monitoring synthetic probe that periodically sends an HTTP(S) request to the specified URL from configurable global locations. It validates availability by checking for expected HTTP status codes, response time thresholds, and optional content matches, and it emits metrics such as uptime, latency, and check success. This is the correct choice because it actively measures external HTTP reachability from outside the network, which is exactly what is needed to monitor external availability.

This is the correct, supported command for adjusting traffic on a Cloud Run service. The 'update-traffic' subcommand directly modifies the revision routing percents, and '--to-revisions' allows explicit targeting of a specific revision; here, setting 'my-service-00001=100' routes all live traffic to the known-good revision A. This immediately reduces load on the suspect revision B and is exactly how you roll back a bad deployment on Cloud Run.

Cloud Logging is a fully managed service that ingests, stores, and allows you to search and analyze logs from Google Cloud resources, including Compute Engine instances. By default, logs are retained for 30 days, which matches the requirement. You can also create log sinks to export logs for longer retention if needed, but for the stated 30-day period, Cloud Logging alone is sufficient.

A readiness probe determines whether a pod is ready to accept traffic. When a pod fails the readiness probe, it is removed from the Service's endpoints, preventing traffic from being routed to it. This ensures that only healthy pods receive requests, which is essential for zero-downtime deployments and maintaining service availability during updates.

Viewing Cloud Logging for firewall rule logs is the direct way to see whether VPC firewall rules are dropping or allowing traffic. Firewall rule logging records each connection attempt with details like source IP, destination IP, port, protocol, and the action (allow or deny). If the Compute Engine instance is unreachable due to a firewall rule, these logs will show the denied packets, making this a reliable troubleshooting step.

kubectl set image updates the Deployment's pod template to gcr.io/myproject/myapp:v2, which triggers the Deployment controller to create a new ReplicaSet and incrementally replace old pods while respecting maxSurge/maxUnavailable. kubectl rollout status then blocks until the new ReplicaSet becomes ready and the old ReplicaSet is scaled down, confirming the rolling update completed successfully. This is the standard declarative workflow for updating an app version.

The correct condition uses a metric threshold on the time series compute.googleapis.com/instance/cpu/utilization. This metric is emitted automatically from GCE instances and can be queried with a threshold (e.g., > 80%) aligned over a defined period such as 5 minutes. When the condition's duration (e.g., 'for 5 minutes') is met, the alerting policy enters the firing state and notifies any attached channels. This is the native, fully integrated way to alert on CPU load.

kubectl set image deployment/my-app my-app=my-app:v2 imperatively updates the container image of the specified container in the Deployment, which immediately triggers a new ReplicaSet and rolling update. kubectl rollout status deployment/my-app then blocks and reports the status of that rollout until it completes, satisfying the requirement to update and monitor progress in one straightforward command sequence.

In Cloud Monitoring, you create an alerting policy with a condition that uses a threshold for a metric such as 'compute.googleapis.com/instance/cpu/utilization'. The policy samples the metric stream over an alignment period and triggers when the value (e.g., average CPU utilization) crosses the threshold for a specified duration. This is exactly the native mechanism for CPU utilization alerts.

This filter uses a comparison operator on the numeric field httpRequest.status. In Cloud Logging, filters support comparison operators like >= for numeric values, so this will match any log entry where the HTTP response status is 500 or higher, capturing all server error statuses (5xx). This is the recommended approach because it is concise and semantically correct.

bq cp performs a server-side metadata copy, duplicating the schema and all rows without streaming data through the client, so billions of rows transfer in seconds and avoid the cost and time of a query-based rewrite.

A metric threshold alert continuously evaluates a time-series metric (e.g., error rate, request latency, or CPU utilization) against a user-defined threshold, such as 'error rate > 5% for 5 minutes', and immediately triggers a notification when the condition is met. This is precisely the right tool for an SRE who needs to be notified when application error rates exceed an acceptable level, because it supports real-time aggregation, sliding windows, and alerting policies with multiple notification channels. It is the correct answer.

Adding a content match with a regular expression is the direct way to verify a specific string pattern in the HTTPS response body. Cloud Monitoring uptime checks accept both substring and regex content matches, allowing you to assert that the page contains a particular marker or dynamic token. This confirms the endpoint is serving expected application content, not just a reachable server.

Upgrading the cluster's control plane with `gcloud container clusters upgrade` is the correct first step because GKE enforces a maximum version skew between the control plane and node pools—typically one minor version. The control plane must be on the target version before node pools can be upgraded, and this command without a `--node-pool` flag updates only the control plane. This ensures the Kubernetes API server and scheduler are consistent with the target version, reducing the risk of API deprecations or incompatibility. It is the only supported way to perform an in-place control plane upgrade while preserving cluster identity and state.

A counter metric is the correct log-based metric type for this use case, because it increments by one for every log entry that matches the specified filter, such as severity=ERROR. This gives the total number of error logs over the selected time window, which is exactly what the team wants to track. In Cloud Logging, you define a counter-based log metric with a filter and then use it in Monitoring charts or alerts.

This is the correct command because autoscaling is a node-pool-level feature. It uses `gcloud container node-pools update`, points at the specific pool with `--cluster=my-cluster`, and enables the Cluster Autoscaler with the valid `--enable-autoscaling` flag. The `--min-nodes 1 --max-nodes 10` range constrains the pool size, and `--region us-central1` correctly specifies the regional control plane where the cluster lives.

bq load is the correct BigQuery CLI command to initiate a batch load job from Cloud Storage. It creates a load job that reads the CSV file at the given URI, parses it according to the specified --source_format, and writes rows into the target table (mydataset.mytable), which can be appended to or replace. This is the standard, idempotent way to bulk-load CSV data into BigQuery.

kubectl set image deployment/my-deployment my-app=gcr.io/my-project/my-app:v2 is the correct imperative command to update a container image inside a Deployment. The container name (my-app) must exactly match the container name defined in the Deployment's pod spec, and the command updates the pod template so the Deployment controller creates a new ReplicaSet and performs a rolling update. This is the canonical kubectl syntax for changing an image without editing a manifest.

This is the correct drain command because --ignore-daemonsets tells kubectl to skip evicting Pods that are managed by DaemonSets (they would just be recreated on the same node), and --delete-emptydir-data lets the drain proceed even if Pods have emptyDir volumes that will be lost. The drain cordons the node, then gracefully evicts remaining workload Pods while honoring PodDisruptionBudgets, making it safe for planned maintenance. These flags are the standard pair used when a GKE node contains DaemonSets and emptyDir-backed pods.

Choosing a time aggregation function is essential because raw metric samples arrive at irregular intervals and need to be aligned to a fixed time step for a coherent time series. The aggregation function (e.g., mean, max, sum) reduces multiple points within each alignment window into a single value, which determines the chart's shape and sensitivity to spikes. Without this step, the dashboard may render unusable, too-dense data or fail to produce a meaningful trend. For CPU utilization, 'mean' is typical for overall usage, while 'max' can highlight peak behavior.

Updating the service with a new image tag, for example via `gcloud run deploy`, is what creates a new revision. A revision cannot be manually created in isolation—it is always the result of deploying a new container image or configuration change. This step is a prerequisite because the later `update-traffic` command must reference the new revision's name to assign it a percentage of incoming requests.

Stopping the instance first moves it to the TERMINATED state, where the underlying vCPU/memory allocation can be changed. The `gcloud compute instances set-machine-type` command only works on a stopped instance, so stopping, changing, then starting is the documented, supported path. This preserves the boot disk, persistent disks, static IP, and all instance metadata.

This is the correct service-level command for a precise traffic split between two existing revisions. It specifies both revisions explicitly, so Cloud Run routes exactly 10% of requests to rev2 and 90% to rev1; percentages must sum to 100 and should be entered as bare integers (no '%' sign). Because it uses `--to-revisions` on `update-traffic`, it works for rollbacks and gradual shifts without creating a new revision.

The `oldest_unacked_message_age` metric, available in Cloud Monitoring under `pubsub.googleapis.com/subscription/oldest_unacked_message_age`, is a gauge metric that reports, per subscription, the age of the oldest message that has not yet been acknowledged. A high or increasing value directly indicates that the subscriber is not keeping up with the message flow, representing a growing backlog. This is the standard and most direct way to detect consumer lag in Cloud Pub/Sub, making it the correct diagnostic tool for the scenario.

The correct approach is to define a filter expression in Cloud Logging that matches the error logs (e.g., severity=ERROR or specific text), then use that filter to create a logs-based metric. The metric counter increments for every matching log entry, and the filter becomes the metric's definition, allowing you to alert on the count over time.

Correct: --concurrency controls the maximum number of simultaneous requests that each container instance can process at the same time. With a spike, setting it to 10 means an instance will accept only 10 in-flight requests and Cloud Run will automatically spin up additional instances to handle the remaining traffic, preventing any single instance from being overwhelmed. It directly manages per-instance load rather than total capacity or request duration.

A managed instance group (MIG) automatically creates and manages instances based on an instance template. It supports autohealing by recreating instances that fail health checks, and it can autoscale based on CPU utilization or other metrics. This directly meets the requirement for automatic repair and scaling, making it the correct choice for the stateless web application.