Cloud Digital Leader — Practice Questions and Mock Exam

Cloud Trace is Google Cloud's distributed tracing service that tracks requests across microservices, recording latency at each step (docs.cloud.google.com/trace/docs/overview). It generates waterfall visualizations showing how long each service takes to process a request, making it easy to pinpoint bottlenecks. Cloud Trace integrates with GKE, Cloud Run, App Engine, and supports OpenTelemetry instrumentation. Why not Cloud Monitoring? It tracks metrics like CPU/memory utilization but doesn't trace individual request paths across services. Why not Error Reporting? It identifies application errors and exceptions, not latency bottlenecks. Why not Cloud Logging? It captures log entries but doesn't provide request-level latency tracing across service boundaries. Exam tip: identifying which specific service causes latency in a distributed request chain = Cloud Trace.

AutoML on Agent Platform automates algorithm selection, hyperparameter tuning, and model training, requiring no ML expertise or coding (docs.cloud.google.com/vertex-ai/docs/start/training-methods). For teams with limited ML experience and smaller datasets, AutoML produces high-quality models faster since it eliminates the need for custom training code and data pipeline development. The official training methods comparison confirms: AutoML needs no data science expertise and is codeless. Why not custom training? It requires significant ML expertise to develop training applications—it does not always produce better models regardless of expertise. Why not pre-trained APIs only? Pre-trained APIs handle common tasks but cannot train on your custom dataset. Why not AutoML is only for large enterprises? AutoML is available to all users regardless of organization size. Exam tip: limited ML expertise + need for quick results + small dataset = AutoML.

Containers virtualize at the OS level, sharing the host kernel, while VMs virtualize at the hardware level with each running a full guest OS (docs.cloud.google.com/migrate/containers/docs/anthos-migrate-benefits). Google docs confirm containers are much lighter than VMs since they do not contain the operating system, and therefore require considerably fewer compute and memory resources. This yields startup in seconds (not minutes) and higher density on the same hardware. Why not eliminate the need for any OS? Containers still rely on the host OS kernel—they share it rather than bundling their own. Why not only run on Google Cloud? Containers are portable across any platform supporting container runtimes. Why not stronger security isolation? VMs provide stronger isolation via separate kernels; containers trade some isolation for efficiency. Exam tip: containers share the OS kernel; VMs each have their own OS.

Google Cloud encrypts data in transit both over the public internet and within its internal network (docs.cloud.google.com/docs/security/encryption-in-transit). External traffic uses TLS/QUIC encryption via Google Front Ends (GFEs), while internal service-to-service traffic uses ALTS (Application Layer Transport Security) for mutual authentication and encryption. Google also uses the PSP security protocol for network-layer encryption with SmartNIC offloading. This is automatic and requires no customer configuration for standard traffic. Why not only on Premium Tier? Encryption in transit applies regardless of network tier. Why not only over the public internet? Docs explicitly state Google encrypts data within its internal network using ALTS. Why not manual TLS configuration? Google automatically handles encryption for its services—no customer-managed certificates needed. Exam tip: TLS = external; ALTS = internal. Both automatic.