Last updated: May 2026
AP-225 — Salesforce Certified Heroku Developer
Test your knowledge with official exam-style questions
Questions and options are shuffled each attempt
▶Heroku Developer Accredited Professional — Practice Exam Set 1: All Questions & Explanations
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. What is the basic unit of a running application process in Heroku?
- A. Container
- B. Dyno(correct)
- C. Slug
- D. Buildpack
Explanation: A Dyno is the basic unit of a running process in Heroku. Dynos are lightweight Linux containers that run the commands specified in the Procfile. A Slug is the compiled/compressed version of the app; a Buildpack transforms source code into a Slug.
2. What is a Heroku 'Procfile' used for?
- A. Defining environment variables for the application
- B. Declaring the process types and commands that Heroku should run to start the application(correct)
- C. Specifying the Heroku add-ons the application requires
- D. Configuring the buildpack for the application
Explanation: The Procfile is a plain text file in the app's root directory that declares the process types (web, worker, release, etc.) and the commands to run for each. Heroku reads this file to determine how to start the application.
3. What is the purpose of a 'Buildpack' in Heroku?
- A. A Docker container image definition for the application
- B. A set of scripts that detect the application's language/framework and compile it into a deployable Slug(correct)
- C. A configuration file for Heroku CI pipelines
- D. A Heroku add-on that accelerates build times
Explanation: A Buildpack is a set of scripts that: (1) detect whether the app's source code is compatible (e.g., Node.js, Python, Ruby), (2) compile and prepare the app (install dependencies, compile assets), and (3) output a Slug — the compressed, ready-to-run package deployed to Dynos.
4. Which statement correctly describes Heroku's dyno filesystem?
- A. Each dyno has a persistent filesystem that survives restarts
- B. The filesystem is shared across all dynos in the same application
- C. The filesystem is ephemeral — changes are lost when the dyno restarts or is replaced(correct)
- D. Dynos use a network-attached storage volume for persistent file storage
Explanation: Heroku dynos have ephemeral filesystems — any files written during runtime are lost when the dyno restarts, crashes, or is replaced. This is a key architectural constraint: applications should use external storage (S3, Postgres, etc.) for any data that must persist. All dynos start from the same read-only Slug.
5. Which two types of dynos are most commonly used in a Heroku application? (Choose 2)
- A. web — handles HTTP requests(correct)
- B. worker — processes background jobs from a queue(correct)
- C. scheduler — runs cron-like periodic tasks
- D. release — runs migrations before new releases go live
Explanation: The two most common dyno types are web (serves HTTP traffic and must bind to $PORT) and worker (processes background jobs from queues like Redis/Sidekiq/Celery). The release process type runs release-phase tasks (like migrations) but is not a 'dyno type' in the traditional sense — it runs once per release, not continuously.
6. What is a Heroku 'slug' size limit and what happens when an app's slug exceeds it?
- A. 500 MB; apps cannot be deployed if the slug exceeds this limit
- B. 100 MB; Heroku automatically compresses the slug to fit within the limit
- C. 500 MB; the build fails and deployment is rejected with a slug size warning(correct)
- D. 1 GB; the app is deployed but dyno startup times increase significantly
Explanation: Heroku has a 500 MB slug size limit. If the compiled slug exceeds this, the build fails with a 'Compiled slug size: X MB is too large (max is 500 MB)' error. Common causes include large static assets, vendor directories, or test files inadvertently included. The fix is to add offending files to .slugignore.
7. What is the primary way to deploy an application to Heroku?
- A. FTP upload of the application directory
- B. Git push to the Heroku remote (heroku git:remote)(correct)
- C. Uploading a ZIP file through the Heroku Dashboard
- D. Running heroku deploy from the app directory
Explanation: The primary deployment method for Heroku is `git push heroku main` — pushing to the Heroku-managed Git remote triggers the build pipeline (buildpack detection, compilation, slug creation, deployment). Heroku also supports GitHub integration and Container Registry for Docker deployments.
8. What is a Heroku 'Pipeline' used for?
- A. Connecting Heroku to Salesforce via an ETL pipeline
- B. Managing CI/CD by organizing apps across review, staging, and production environments with promotion between stages(correct)
- C. Setting up data pipelines between Heroku Postgres and external databases
- D. Configuring network routing rules between dyno types
Explanation: Heroku Pipelines implement CI/CD workflows by connecting multiple apps in stages: Review Apps (per PR), Staging, and Production. Code is promoted (not rebuilt) between stages — the same Slug tested in staging is promoted to production, ensuring what was tested is what gets deployed.
9. How are application configuration values (API keys, connection strings, etc.) stored and accessed in Heroku?
- A. In a .env file committed to the git repository
- B. As Config Vars (environment variables) set via the Heroku CLI or Dashboard(correct)
- C. In a Heroku Secrets Manager vault
- D. In a config.json file in the application root
Explanation: Config Vars are Heroku's mechanism for environment-specific configuration. They are set via `heroku config:set KEY=VALUE` (CLI) or the Dashboard and are exposed to the app as environment variables at runtime. This follows the 12-factor app methodology — never commit credentials to source code.
10. What is the 'release phase' in a Heroku Procfile and when does it run?
- A. A dyno type that runs permanently alongside web dynos to handle release management
- B. A one-time task that runs after a new slug is deployed but before traffic is shifted — used for migrations, cache warming, etc.(correct)
- C. The final step of the buildpack that compiles the slug
- D. A health check that runs after every dyno restart
Explanation: The release phase (declared as `release: <command>` in the Procfile) runs once after each new deployment, after the new slug is ready but before web dynos are started with the new code. It is ideal for database migrations, data seeding, and cache warming. If the release phase fails, the deployment is aborted.
11. Which two Heroku features support zero-downtime deployments? (Choose 2)
- A. Preboot — starting new dynos before old ones are shut down(correct)
- B. Rolling restarts — updating one dyno at a time
- C. Blue-green deployment via Heroku Pipelines promotion(correct)
- D. Dyno clustering with automatic failover
Explanation: Heroku supports zero-downtime deployments via: (1) Preboot — new dynos start and receive traffic before old dynos are terminated, and (2) Blue-green deployment using Pipelines, where a production slot is swapped atomically by promoting the tested staging slug. Rolling restarts are not a Heroku feature.
12. What is 'Heroku Connect' and what is its primary use case?
- A. A Heroku add-on that synchronizes data bidirectionally between a Heroku Postgres database and a Salesforce org(correct)
- B. A VPN tunnel connecting a Heroku app to an on-premises data center
- C. A CI/CD integration that connects Heroku Pipelines to GitHub Actions
- D. An API gateway that routes traffic between multiple Heroku applications
Explanation: Heroku Connect is an add-on that provides bidirectional data synchronization between a Heroku Postgres database and a Salesforce org. It maps Salesforce objects to Postgres tables and keeps them in sync, enabling Heroku applications to interact with Salesforce data without direct API calls.
13. Which Heroku add-on provides a managed PostgreSQL database?
- A. Heroku Data for Redis
- B. Heroku Postgres(correct)
- C. JawsDB MySQL
- D. Heroku Kafka
Explanation: Heroku Postgres is Heroku's native managed PostgreSQL database service. It provisions, scales, and maintains PostgreSQL databases, and integrates with Heroku apps via the DATABASE_URL Config Var. It is the recommended persistent data store for Heroku applications.
14. What is Heroku Data for Redis used for in a typical Heroku application architecture?
- A. Replacing Heroku Postgres as the primary database
- B. Caching, session storage, and background job queuing (e.g., Sidekiq, Bull, Celery)(correct)
- C. Storing large binary objects and file uploads
- D. Syncing data with Salesforce orgs
Explanation: Heroku Data for Redis (managed Redis) is primarily used for caching (reducing database load), session storage, and background job queue backends (Sidekiq for Ruby, Bull for Node.js, Celery for Python, etc.). Redis is an in-memory data structure store, not a replacement for a relational database.
15. How are Heroku add-ons typically integrated with a Heroku application?
- A. By installing a client library and hardcoding the add-on credentials in the source code
- B. By automatically injecting Config Vars (environment variables) with connection credentials into the app(correct)
- C. By mounting a shared filesystem volume between the add-on and the app dynos
- D. By providing a webhook that the app polls for data
Explanation: When a Heroku add-on is provisioned, it automatically adds Config Vars to the app (e.g., REDIS_URL, DATABASE_URL) containing the connection credentials. Applications read these environment variables at runtime — no hardcoded credentials needed, and rotating credentials only requires an add-on restart.
16. Which two Heroku Postgres features help ensure database continuity and recovery? (Choose 2)
- A. Continuous Protection (WAL-based point-in-time recovery)(correct)
- B. Automated daily backups with 25-backup rolling retention(correct)
- C. Cross-region synchronous replication for all plan tiers
- D. Automated schema migration on restore
Explanation: Heroku Postgres provides Continuous Protection (WAL streaming to S3 enabling point-in-time recovery) and automated daily backups retained for up to 25 rolling backups (on Standard+ plans). Cross-region synchronous replication is available on Premium/Private plans, not all tiers. Schema migration is never automated.
17. What is the Heroku Private Link feature used for?
- A. Creating private URLs for Heroku apps that bypass the public internet
- B. Securely connecting a Heroku Postgres or Redis database to an AWS VPC without public internet exposure(correct)
- C. Enabling SSL/TLS encryption on Heroku data add-ons
- D. Whitelisting specific IP ranges to access Heroku applications
Explanation: Heroku Private Link (via AWS PrivateLink) allows Heroku Postgres and Redis databases to be accessed directly from an AWS VPC without traffic traversing the public internet. This improves security and reduces latency for Heroku data services used alongside AWS workloads.
18. What does 'horizontal scaling' mean in the context of Heroku?
- A. Upgrading to a larger dyno size (more CPU and RAM)
- B. Adding more dynos of the same type to distribute load(correct)
- C. Enabling CDN caching for static assets
- D. Increasing the Heroku Postgres plan to a higher tier
Explanation: Horizontal scaling on Heroku means adding more dynos of the same type (e.g., scaling web dynos from 1 to 5) to handle more concurrent requests. Vertical scaling means upgrading to a larger dyno size. Heroku supports both, but horizontal scaling is the preferred pattern for stateless applications.
19. A Heroku web dyno must bind to which port for HTTP traffic?
- A. Port 80
- B. Port 443
- C. Port 3000
- D. The value of the $PORT environment variable(correct)
Explanation: Heroku dynamically assigns a port to each dyno and passes it via the $PORT environment variable. Applications must bind their HTTP server to `process.env.PORT` (Node.js), `ENV['PORT']` (Ruby), etc. Hardcoding port 80 or 3000 will cause the dyno to fail to start, as Heroku's router requires the app to use $PORT.
20. What is the Heroku Router's request timeout and what happens when it is exceeded?
- A. 30 seconds; the router returns an H12 error to the client(correct)
- B. 60 seconds; the dyno is automatically restarted
- C. 120 seconds; the router retries the request on a different dyno
- D. There is no timeout; requests wait indefinitely for the dyno to respond
Explanation: Heroku's router has a 30-second request timeout. If an application dyno does not respond within 30 seconds, the router returns an H12 error ('Request Timeout') to the client and logs the error. This is a common issue for long-running operations that should be moved to background worker dynos.
21. Which two Heroku features help application developers identify performance bottlenecks in production? (Choose 2)
- A. Heroku Metrics — dyno memory and CPU usage in the Dashboard(correct)
- B. Log drains — streaming application logs to external observability tools (Datadog, Splunk, Papertrail)(correct)
- C. Heroku Profiler — a built-in APM that traces all requests
- D. Dyno Inspector — a live SSH session to examine running dyno state
Explanation: Heroku Metrics (in the Dashboard) shows real-time and historical dyno CPU/memory usage, response times, and throughput. Log drains allow streaming application logs, including router performance logs, to external APM/observability platforms. There is no built-in 'Heroku Profiler' — external APM add-ons (New Relic, Datadog) are used. `heroku run` provides a one-off dyno for debugging but not a live inspector.
22. How should sensitive credentials (database passwords, API tokens) be stored in a Heroku application?
- A. In a secrets.json file in the app repository, encrypted with GPG
- B. As Heroku Config Vars (environment variables) — never in source code(correct)
- C. In a Heroku-managed key vault accessible via the Heroku API
- D. Embedded in the Procfile with base64 encoding
Explanation: Credentials must be stored as Heroku Config Vars (environment variables), never in source code or committed files. Config Vars are encrypted at rest and exposed to dynos as environment variables. This follows the 12-factor app methodology and prevents credential exposure in version control.
23. What is Heroku Shield and when is it required?
- A. A DDoS protection layer that is automatically enabled for all Heroku apps
- B. A compliance-focused Heroku tier providing enhanced security controls for regulated industries (HIPAA, PCI, etc.)(correct)
- C. An Heroku add-on that scans code for security vulnerabilities
- D. A web application firewall that blocks malicious HTTP requests
Explanation: Heroku Shield is Heroku's compliance-ready infrastructure tier for regulated industries (HIPAA, PCI DSS, etc.). It provides Private Spaces with enhanced security controls: VPC isolation, audit logging, data encryption at rest, and compliance-specific features. Required when handling PHI or cardholder data on Heroku.
24. Which two Heroku features provide network-level isolation for applications handling sensitive data? (Choose 2)
- A. Heroku Private Spaces — isolated runtime environments with private networking(correct)
- B. IP Allow Listing — restricting inbound traffic to specific IP ranges
- C. Heroku SSL — forcing HTTPS for all application traffic
- D. Internal Routing — marking apps as internal-only so they are not accessible from the public internet(correct)
Explanation: Private Spaces provide VPC-level network isolation for Heroku apps — all inter-app traffic stays within AWS private networking. Internal Routing (available within Private Spaces) allows apps to be configured as internal-only, not reachable from the public internet — only accessible from other apps in the same Private Space.
25. A Heroku application needs to call a corporate API that only accepts connections from known IP addresses. How can a Heroku app ensure its outbound IP is static?
- A. Use a Heroku Private Space — Private Space apps have static outbound IPs(correct)
- B. Assign a static IP via the Heroku Dashboard under the app's networking settings
- C. Use the Heroku Fixed IP add-on
- D. By default, all Heroku dynos share a single stable outbound IP
Explanation: Common Heroku dynos (in the default runtime) share rotating, unpredictable outbound IPs. To get static outbound IPs, an application must be deployed in a Heroku Private Space — Private Space apps have stable, dedicated NAT gateway IPs that can be whitelisted at external firewalls/APIs.