Plat-Arch-206 — Salesforce Certified Heroku System Architect

Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.

1. 1. A company wants to build a customer-facing web application that reads Salesforce CRM data at high scale without hitting Salesforce API limits. What is the recommended architectural pattern using Heroku?

   • A. Call the Salesforce REST API directly from the Heroku app on every user request
   • B. Use Heroku Connect to sync relevant Salesforce data to Heroku Postgres and query Postgres from the web app(correct)
   • C. Cache all Salesforce objects in Heroku Redis and refresh hourly
   • D. Deploy the web app directly in Salesforce as a Lightning App

   Explanation: Using Heroku Connect to sync Salesforce data to Heroku Postgres is the recommended pattern for high-scale web applications. This decouples the external app from Salesforce API limits by reading from a local Postgres replica, while Heroku Connect handles real-time bidirectional sync with the Salesforce org.

2. 2. Which of the 12-factor app principles most directly informs the Heroku architectural constraint that processes should be stateless?

   • A. Factor I: Codebase — one codebase tracked in version control
   • B. Factor VI: Processes — execute the app as stateless processes that share nothing(correct)
   • C. Factor X: Dev/prod parity — keep development, staging, and production as similar as possible
   • D. Factor III: Config — store config in environment

   Explanation: The 12-Factor App's Factor VI (Processes) mandates that application processes must be stateless and share-nothing. Any data that needs to persist must live in a backing service (Postgres, Redis). This directly enables Heroku's horizontal scaling model — any dyno can handle any request because no state is stored locally.

3. 3. A Heroku architect must design a system where background jobs must not be lost if a worker dyno crashes mid-processing. Which pattern achieves this?

   • A. Store job status in dyno memory and restart the dyno automatically on crash
   • B. Use a durable queue (Redis with job acknowledgment or Postgres-backed queue) and only delete jobs after successful completion(correct)
   • C. Write jobs to the ephemeral dyno filesystem and re-enqueue on dyno restart
   • D. Increase dyno tier to eliminate crash risk

   Explanation: For crash-safe background jobs, use a durable queue backed by Redis (with job acknowledgment semantics like Sidekiq's RPOPLPUSH pattern) or a Postgres-backed queue. Jobs are only removed from the queue after the worker confirms successful completion. If the worker crashes mid-job, the job remains in the queue for retry. Dyno memory and ephemeral filesystems are lost on crash.

4. 4. Which two architectural patterns should be used when a Heroku application must handle traffic spikes of 100x normal volume without service degradation? (Choose 2)

   • A. Horizontal autoscaling of web dynos combined with queue-based load leveling for heavy operations(correct)
   • B. Vertical scaling to the largest available dyno size
   • C. CDN caching of static assets and cacheable API responses to reduce origin hits(correct)
   • D. Database connection pooling via PgBouncer to prevent database connection exhaustion under load

   Explanation: For 100x traffic spikes: (1) Horizontal autoscaling of web dynos (more dynos = more request capacity) combined with offloading heavy operations to worker queues prevents blocking; (2) CDN caching (via Fastly, CloudFront, or Heroku's CDN) absorbs the majority of static and cacheable requests, dramatically reducing origin load. Database connection pooling is important but doesn't address spike capacity. Vertical scaling alone is insufficient.

5. 5. When should a Heroku architect choose a microservices architecture over a monolithic deployment?

   • A. Always — microservices are always the better architecture on Heroku
   • B. When the system has multiple independently scalable domains with different scaling requirements, different tech stacks, or independent deployment lifecycles(correct)
   • C. When the team is small and wants to avoid deployment complexity
   • D. When the app needs to use more than one Heroku add-on

   Explanation: Microservices are appropriate when different parts of the system need to scale independently, have different technology requirements, or need to be deployed on separate release cycles. For small teams or early-stage products, a well-structured monolith is usually simpler and more productive. The decision should be driven by actual complexity, not general preference.

6. 6. A Heroku Private Space offers which advantage over the Common Runtime?

   • A. Cheaper per-dyno pricing on Private Space
   • B. Dedicated, isolated infrastructure with private networking, static IPs, and compliance certifications (HIPAA, PCI)(correct)
   • C. Access to all Heroku add-ons, which are not available in Common Runtime
   • D. Higher dyno performance due to dedicated hardware

   Explanation: Heroku Private Spaces provide isolated runtime environments hosted in a dedicated VPC within a specific AWS region. Key advantages over Common Runtime: private networking between apps, stable outbound IPs (NAT gateway), no shared infrastructure, and compliance certifications enabling HIPAA/PCI workloads. Private Spaces cost more and have the same add-on availability.

7. 7. Which two patterns help a Heroku application remain resilient when a backing service (database, Redis) becomes temporarily unavailable? (Choose 2)

   • A. Circuit breaker pattern — stop sending requests to a failing service and fail fast(correct)
   • B. Retry with exponential backoff — retry failed requests with increasing delays(correct)
   • C. Increasing dyno count to create more connections to the failing service
   • D. Storing failed requests in dyno memory for later replay

   Explanation: Circuit breakers prevent cascading failures by stopping requests to a failing service after a threshold is exceeded — returning a fast failure instead of waiting for timeout. Retry with exponential backoff handles transient failures by retrying after progressively longer delays, giving the service time to recover. More dynos worsen connection pressure on a struggling database. Dyno memory is ephemeral.

8. 8. A Heroku application serves both public web traffic and sensitive internal admin APIs. How should the architect separate these concerns?

   • A. Use feature flags to restrict admin API access at the application level
   • B. Deploy the public app in Common Runtime and the internal admin app in a Private Space with Internal Routing(correct)
   • C. Use a single Heroku app with route-level authentication for admin endpoints
   • D. Add a Heroku Shield add-on to the public-facing app to protect admin routes

   Explanation: The recommended pattern is to split into two apps: the public app in Common Runtime (or Private Space) exposed to the internet, and the admin app in a Private Space with Internal Routing enabled (not publicly accessible). Internal Routing ensures the admin app is only reachable from other apps within the same Private Space, not from the internet.

9. 9. Which integration pattern should be used when a Heroku app needs to receive notifications when Salesforce records change without polling?

   • A. Scheduled Apex batch that calls a Heroku webhook every 5 minutes
   • B. Salesforce Platform Events or Change Data Capture events consumed by the Heroku app via the Streaming API(correct)
   • C. Heroku Connect real-time triggers that push changes to the Heroku app
   • D. Salesforce SOQL query from the Heroku app via the REST API on a cron schedule

   Explanation: For event-driven integration without polling, Salesforce Platform Events or Change Data Capture (CDC) events should be subscribed to via the Salesforce Streaming API (CometD protocol) from the Heroku app. This provides real-time, push-based notifications when Salesforce data changes, avoiding API limit consumption from polling.

10. 10. What is the Heroku External Objects feature and how does it relate to Salesforce Connect?

    • A. Heroku External Objects allow Salesforce to display Heroku Postgres data as native Salesforce objects without data migration
    • B. Heroku External Objects are a legacy feature replaced by Heroku Connect
    • C. External Objects expose data from any OData endpoint; Heroku Postgres can be exposed to Salesforce via Salesforce Connect as an External Object(correct)
    • D. Heroku External Objects sync data to Salesforce Custom Objects via nightly batch

    Explanation: Salesforce Connect allows Salesforce to query data from external systems as External Objects using OData. A Heroku Postgres database can be connected as an External Data Source via Salesforce Connect's OData adapter, making Heroku data visible in Salesforce in real time without copying it into Salesforce storage.

11. 11. A Heroku app must call a REST API that has a 200 requests/minute rate limit. How should the architect design the integration to handle burst traffic without exceeding the limit?

    • A. Throttle the Heroku app at the dyno level using dyno formation limits
    • B. Queue API calls via a Redis-backed job queue with a rate-limited worker that processes at a controlled pace(correct)
    • C. Catch HTTP 429 errors and immediately retry with the same request
    • D. Increase the number of web dynos to distribute API calls across more IPs

    Explanation: A rate-limited worker queue is the correct pattern: incoming requests enqueue API calls; worker dynos process the queue at a rate under the API limit (e.g., 3.3 requests/second). This decouples ingestion from the rate-limited API, prevents 429 errors, and allows burst traffic to queue up without failing. Retrying immediately on 429 just worsens the problem.

12. 12. Which two integration patterns are most appropriate for a Heroku microservice architecture where services need to communicate asynchronously? (Choose 2)

    • A. Message queues (Redis/Kafka) for event-based communication between services(correct)
    • B. Synchronous REST calls between services with shared API keys
    • C. Shared Heroku Postgres database accessed by all services
    • D. Pub/sub via Heroku Kafka for high-throughput event streaming(correct)

    Explanation: Asynchronous microservice communication should use message queues (Redis-backed queues like Sidekiq/Bull for task queues) or pub/sub via Heroku Kafka for high-throughput event streaming. Synchronous REST calls create tight coupling and cascade failures. A shared database is the 'shared database' anti-pattern for microservices.

13. 13. What is the advantage of using Heroku Kafka over Redis as a message backbone in a microservices architecture?

    • A. Kafka is simpler to set up and has lower latency for small message volumes
    • B. Kafka retains messages for configurable periods enabling consumer replay, supports multiple consumer groups, and handles very high throughput(correct)
    • C. Kafka is cheaper than Heroku Redis at all scales
    • D. Kafka natively integrates with Salesforce Platform Events, eliminating custom code

    Explanation: Heroku Kafka (Apache Kafka) is designed for high-throughput event streaming with durable, replayable message logs. Multiple independent consumer groups can each read the full event stream. Messages are retained for configurable periods (hours/days), enabling event replay for new consumers or recovery. Redis queues are ephemeral (messages are consumed once and lost) and better suited for task queues than event streaming.

14. 14. A company uses Heroku for their customer portal and Salesforce for CRM. Sales reps in Salesforce need to see real-time order data created in the Heroku app. Which integration approach minimizes Salesforce API limits and provides real-time data?

    • A. Heroku app calls Salesforce REST API to write order records as they are created
    • B. Use Salesforce Connect with an OData endpoint served by the Heroku app to show Heroku order data as External Objects in Salesforce(correct)
    • C. Export Heroku orders to CSV and import to Salesforce nightly via Data Loader
    • D. Build a custom Apex callout from Salesforce to the Heroku REST API on every page load

    Explanation: Salesforce Connect + OData is ideal for this scenario: the Heroku app exposes an OData API; Salesforce reads data as External Objects in real time without storing copies in Salesforce. This eliminates API limit consumption, provides always-current data, and avoids data duplication. Writing to Salesforce on every order creation consumes API calls and creates data storage overhead.

15. 15. A Heroku architect is designing a multi-tenant SaaS application on Heroku Postgres. Which isolation strategy provides the strongest tenant data isolation?

    • A. Row-level isolation — all tenants share tables with a tenant_id column and row-level security
    • B. Schema-level isolation — each tenant has a separate Postgres schema within a shared database
    • C. Database-level isolation — each tenant has a dedicated Heroku Postgres instance(correct)
    • D. Application-level isolation — tenant filtering enforced only in application code

    Explanation: Database-level isolation (separate Postgres instance per tenant) provides the strongest isolation — a bug in one tenant's queries cannot affect another tenant's data, and performance issues are contained. However, it is the most expensive. Schema-level and row-level provide weaker isolation but are more cost-efficient for many-tenant scenarios.

16. 16. A Heroku Postgres database is experiencing slow query performance as data volume grows. Which two actions should be taken first?

    • A. Add indexes on frequently queried columns used in WHERE and JOIN clauses(correct)
    • B. Enable VACUUM ANALYZE on large tables to update statistics and reclaim space(correct)
    • C. Migrate all data to Redis for faster reads
    • D. Enable Heroku Postgres Follower databases for read scaling

    Explanation: The first steps for Postgres performance issues are: (1) Add indexes on columns used in WHERE/JOIN/ORDER BY clauses — missing indexes cause full table scans; (2) Run VACUUM ANALYZE to update the query planner statistics and reclaim dead row space. Followers help with read scaling but don't fix query efficiency. Redis is not a replacement for relational data.

17. 17. What is a Heroku Postgres 'Follower' and when should it be used?

    • A. A read replica that follows the leader database; used to scale read traffic without impacting write performance(correct)
    • B. A warm standby that automatically promotes to leader on primary failure
    • C. A second database used for staging/testing that mirrors production data
    • D. A backup copy of the database that is updated once per day

    Explanation: A Heroku Postgres Follower is a read replica that continuously replicates from the leader database using streaming replication. It accepts read-only queries, enabling read traffic to be offloaded from the primary (which handles writes). It can also be promoted to leader during a disaster recovery scenario.

18. 18. What is the risk of sharing a single Heroku Postgres database connection pool across all dynos without using PgBouncer?

    • A. All dynos share the same database credentials, creating a security vulnerability
    • B. Postgres has a maximum connection limit; scaling dynos can exhaust the connection pool, causing 'too many connections' errors(correct)
    • C. Shared connection pools make it impossible to use database transactions
    • D. Heroku Postgres performance degrades linearly with more connections regardless of query volume

    Explanation: PostgreSQL has a configured maximum connection limit (e.g., 25 on Standard-0, 500 on Standard-2). Each Heroku dyno opens its own connection pool to the database. Scaling to many dynos can exhaust Postgres connections, causing new connection attempts to fail. PgBouncer is a connection pooler that multiplexes many dyno connections onto fewer actual Postgres connections.

19. 19. Which two strategies should a Heroku architect use to handle large file uploads (images, documents) in a Heroku application? (Choose 2)

    • A. Direct-to-S3 uploads from the browser using presigned S3 URLs — bypassing Heroku dynos entirely(correct)
    • B. Store files in the Heroku dyno's ephemeral filesystem
    • C. Buffer uploads through the Heroku web dyno, then stream to Amazon S3 or a similar object store(correct)
    • D. Store files as BLOBs in Heroku Postgres

    Explanation: For large file uploads: (1) Direct-to-S3 (presigned URLs) is the most efficient — files go from the browser directly to S3 without tying up a Heroku web dyno, avoiding the 30-second request timeout; (2) Streaming through the dyno to S3 is acceptable for smaller files or when server-side processing is needed. Ephemeral filesystem files are lost on restart. BLOBs in Postgres are inefficient and waste database capacity.

20. 20. How does Heroku Autoscaling work for web dynos?

    • A. Heroku automatically adds or removes dynos based on CPU usage thresholds
    • B. Heroku scales dynos based on response latency — adding dynos when p95 latency exceeds the configured threshold(correct)
    • C. Autoscaling is not available on Heroku; only manual scaling is supported
    • D. Heroku scales based on queue depth from the connected Redis add-on

    Explanation: Heroku Autoscaling (available on Performance dynos and above) scales web dynos based on p95 response latency. When the 95th percentile response time exceeds the configured threshold, additional dynos are added; when latency returns to normal, excess dynos are removed. This latency-based approach correlates better with user experience than CPU-based scaling.

21. 21. A Heroku application experiences degraded performance due to a large number of database connections from multiple dyno formations. What is the recommended architectural solution?

    • A. Scale down to fewer, larger dynos to reduce connection count
    • B. Deploy PgBouncer as a sidecar on each dyno using the heroku-buildpack-pgbouncer buildpack(correct)
    • C. Upgrade to a Heroku Postgres plan with unlimited connections
    • D. Migrate from connection pooling to single-connection mode in the ORM

    Explanation: The heroku-buildpack-pgbouncer buildpack deploys PgBouncer alongside the application in the same dyno, acting as a local connection pooler. Each dyno's application connects to its local PgBouncer, which maintains a small pool of actual Postgres connections. This multiplexes many logical connections into fewer real database connections, resolving connection exhaustion.

22. 22. A Heroku application handles OAuth tokens for third-party integrations. What is the secure approach for storing and refreshing these tokens?

    • A. Store tokens in Heroku Config Vars, which are automatically rotated by Heroku
    • B. Store encrypted tokens in Heroku Postgres with an encryption key stored as a Config Var; implement token refresh logic in the app(correct)
    • C. Store tokens in the user's browser session and re-request them on every server restart
    • D. Hardcode long-lived tokens in the application source code to avoid storage complexity

    Explanation: OAuth tokens should be stored in encrypted form in a persistent store (Heroku Postgres) with the encryption key as a Config Var. The application implements refresh logic to renew expiring tokens. Config Vars alone are for static configuration values shared across all users — they cannot hold per-user tokens. Browser sessions are not appropriate for server-side service tokens.

23. 23. Which two measures should a Heroku architect implement to prevent SQL injection in a Heroku Postgres-backed application? (Choose 2)

    • A. Use parameterized queries or prepared statements for all database interactions(correct)
    • B. Use an ORM (Sequelize, SQLAlchemy, ActiveRecord) with bound parameters rather than string concatenation for queries(correct)
    • C. Restrict database user permissions so the app user cannot execute DROP or DELETE statements
    • D. Enable Heroku Postgres's built-in SQL injection firewall

    Explanation: SQL injection prevention requires parameterized queries (prepared statements with bound parameters) or ORM usage with proper binding — both prevent user input from being interpreted as SQL. Restricting DB user permissions (least privilege) is good defense-in-depth but does not prevent injection; it limits blast radius. There is no Heroku Postgres SQL injection firewall.

24. 24. Which Heroku feature allows a Heroku app to communicate with resources in a corporate data center without exposing services to the public internet?

    • A. Heroku IP Allowlist
    • B. Heroku Private Space Peering (AWS VPC Peering or VPN)(correct)
    • C. Heroku Trusted IP Range on the application router
    • D. Using HTTPS only and relying on SSL for network security

    Explanation: Heroku Private Space Peering allows a Private Space's VPC to connect to a corporate AWS VPC (via VPC Peering) or to on-premises networks (via VPN). This creates a private network path between Heroku and the data center, keeping traffic off the public internet without requiring services to be publicly accessible.

25. 25. A Heroku architect must design an architecture meeting HIPAA compliance requirements. Which combination of Heroku features is required?

    • A. Common Runtime with SSL enforcement and Heroku Postgres Standard plan
    • B. Heroku Shield Private Space with Shield Postgres and Shield Redis, all in the same compliant region(correct)
    • C. Any Heroku setup with HIPAA add-ons from the AppExchange
    • D. Heroku Private Space with standard Postgres and encryption-at-rest enabled via a Config Var

    Explanation: HIPAA compliance on Heroku requires Heroku Shield — specifically: Shield Private Spaces (HIPAA-eligible runtime), Shield Postgres (encrypted data storage, audit logging, no sharing with other tenants), and Shield Redis if used. All must be in a Shield-eligible region. Standard Private Spaces and non-Shield data stores are not HIPAA-eligible. A Business Associate Agreement (BAA) with Salesforce/Heroku is also required.