💻 Designing Scalable, Available, and Reliable Cloud-Native Applications - PCD Practice Questions

Design scalable applications using microservices, event-driven patterns, and GCP managed services.

5Questions Available
1Exam Domains

Practice Cloud-Native Apps Questions Now

Start a timed practice session focusing on Designing Scalable, Available, and Reliable Cloud-Native Applications topics from the PCD question bank.

Start PCD Practice Quiz →

PCD Cloud-Native Apps Question Bank (5 Questions)

Browse all 5 practice questions covering Designing Scalable, Available, and Reliable Cloud-Native Applications for the PCD certification exam. Each question includes the full answer and a detailed explanation to help you understand the concepts.

  1. Question 1Designing Scalable, Available, and Reliable Cloud-Native Applications

    According to twelve-factor app methodology, how should a Cloud Run service access its database connection string?

    AHardcode in source code
    BInject via environment variables or Secret Manager — keeping configuration separate from code, enabling different values per environment✓
    CRead from a local config file in the container
    DQuery a DNS record
    Show Answer & Explanation
    Correct Answer: B
    Explanation:

    Factor III (Config): store config in environment, not code. Cloud Run: --set-env-vars or --set-secrets (Secret Manager). Different environments (dev/staging/prod) use different config without code changes. Secret Manager for sensitive values (credentials), env vars for non-sensitive config (URLs, feature flags).

  2. Question 2Designing Scalable, Available, and Reliable Cloud-Native Applications

    How should you design a Cloud Run service to process events from multiple Google Cloud sources?

    APoll each source separately
    BUse Eventarc to route events from Cloud Storage, Pub/Sub, Firestore, and other sources to your Cloud Run service — providing unified event delivery with CloudEvents format✓
    CCreate separate services per source
    DUse cron jobs to check each source
    Show Answer & Explanation
    Correct Answer: B
    Explanation:

    Eventarc: unified event routing to Cloud Run. Sources: direct events (Cloud Storage, BigQuery, etc.), Pub/Sub topics, and 130+ sources via Audit Logs. CloudEvents format (standard). Create trigger: gcloud eventarc triggers create TRIGGER --destination-run-service=SERVICE --event-filters=type=EVENT_TYPE. One service handles multiple event types.

  3. Question 3Managing Application Performance

    What observability stack should you implement for a microservices application on Cloud Run?

    AOnly error logs
    BThree pillars: Cloud Logging (structured logs), Cloud Monitoring (metrics, dashboards, alerts), and Cloud Trace (distributed tracing) — correlated via trace ID for end-to-end request visibility✓
    COnly monitoring
    DThird-party tools only
    Show Answer & Explanation
    Correct Answer: B
    Explanation:

    Observability three pillars: Logs (Cloud Logging — structured JSON, severity, trace correlation), Metrics (Cloud Monitoring — latency, error rate, throughput, custom metrics), Traces (Cloud Trace — distributed latency breakdown across services). Correlate: same trace ID across all three. Dashboards: golden signals. Alerts: SLO burn rate. Error Reporting: exception grouping.

  4. Question 4Designing Scalable, Available, and Reliable Cloud-Native Applications

    When should you implement a service mesh (Anthos Service Mesh) for your microservices on GKE?

    AAlways, for any microservices
    BWhen you need mTLS, traffic management (canary, retries, circuit breaking), and observability (distributed tracing, metrics per service) without modifying application code✓
    CNever, it adds too much complexity
    DOnly for 2 services
    Show Answer & Explanation
    Correct Answer: B
    Explanation:

    Service mesh benefits: mTLS (automatic encryption + identity between all services), traffic management (canary routing, retries, timeouts, circuit breaking — configured declaratively, no code changes), observability (automatic distributed tracing, per-service metrics, access logs). Trade-off: complexity, resource overhead. Use when: >5 services, security requirements, complex traffic patterns, need observability.

  5. Question 5Building and Testing Applications

    How should you implement chaos engineering for your Cloud Run and GKE services?

    ABreak production randomly
    BInject controlled failures in a staging environment: kill pods, add latency, simulate service outages — verify that circuit breakers, retries, and fallbacks work as designed✓
    COnly test in production
    DNever test failures
    Show Answer & Explanation
    Correct Answer: B
    Explanation:

    Chaos engineering: controlled experiments to verify resilience. GKE: Chaos Mesh or Litmus (inject pod failures, network delays, CPU stress). Service mesh: Istio fault injection (add latency, return errors for a percentage of requests). Verify: circuit breakers trip, retries work, fallbacks activate, alerts fire. Start in staging, graduate to production with blast radius limits.

Key Cloud-Native Apps Concepts for PCD

microservicesevent-drivenscalablecloud-nativetwelve-factorcloud rungke

PCD Cloud-Native Apps Exam Tips

Designing Scalable, Available, and Reliable Cloud-Native Applications questions in PCD are typically scenario-based. Focus on service-level decision making aligned to official exam objectives. Priority concepts: microservices, event-driven, scalable, cloud-native, twelve-factor, cloud run.

What PCD Expects

  • Anchor your answer in select the most practical, secure, and scalable answer for the stated scenario.
  • Cloud-Native Apps scenarios for PCD are frequently mapped to Domain 1 (~25%), so read the objective carefully before picking controls or architecture.
  • Expect multi-service scenarios where Cloud-Native Apps interacts with IAM, networking, storage, or observability patterns rather than appearing as an isolated service question.
  • When two options are both technically valid, prefer the choice that best aligns with the exam's operational scope (Professional) and managed-service best practices.

High-Value Cloud-Native Apps Concepts

  • Know the core Cloud-Native Apps building blocks cold: microservices, event-driven, scalable, cloud-native.
  • Review the edge-case features and limits for twelve-factor, cloud run; these details are commonly used to differentiate answer choices.
  • Practice service-integration reasoning: how Cloud-Native Apps pairs with Building & Testing, Deploying in real deployment patterns.
  • For PCD, explain why the chosen Cloud-Native Apps design meets reliability, security, and cost expectations better than the alternatives.

Common PCD Traps

  • Watch for answers that partially solve the requirement but miss operational constraints.
  • Questions in Designing Cloud-Native Applications often include distractors that look correct for Cloud-Native Apps but violate least-privilege, durability, or availability requirements.
  • Avoid picking options purely by feature name; validate data path, failure handling, and governance impact before answering.
  • If the prompt hints at automation or repeatability, eliminate manual-only operational answers first.

Fast Review Checklist

  • Can you compare at least two Cloud-Native Apps implementation paths and justify which one best fits the scenario?
  • Can you map the chosen answer back to Designing Cloud-Native Applications (~25%) outcomes for PCD?
  • Can you explain security and access boundaries for Cloud-Native Apps without relying on default-open assumptions?
  • Can you describe how Cloud-Native Apps integrates with Building & Testing and Deploying during failure, scaling, and monitoring events?

Exam Domains Covering Cloud-Native Apps

Domain 1Designing Cloud-Native Applications~25%

Related Resources

🎯 Free PCD Mock Exam📝 Building & Testing Questions📝 Deploying Questions

More PCD Study Resources

← PCD Study Hub30-Day Study PlanFull Practice Exam