I've just recently passed the Salesforce Accredited Heroku Developer exam.
There isn't much information available on that. Hence, I'd like to share my experience, outline what you can expect, and recommend some helpful materials.
Introduction: Why Heroku?
I've been a long-time advocate of pro-code solutions and using Heroku for some projects earlier.
It's a great way to ensure developer productivity, overcome Salesforce platform limitations, and ensure brand integrity across customer-facing apps.
For instance, I've used it for the co-investment platform for Innovestor Group, which helped us speed up the time to market, save on license costs, and utilize a unified UI design.
After that project, I primarily used AWS for custom development to bypass the constraints of the Salesforce platform.
However, I would now like to reconsider Heroku.
Heroku announced a new partner program earlier this year, along with new features that support AI development and Salesforce integration.
The product offering improved, for example, the introduction of Heroku AppLink, a free add-on that enables seamless integration between Salesforce and your Heroku applications.
One of the prerequisites for the Heroku consulting program is to obtain one of the two currently available certificates:
I decided to explore the platform again and obtain one for those.
Heroku Developer Accredited Professional
The official exam guide mentions the following topics that you need to know to pass the exam successfully:
- Heroku Platform: Apps and Runtime: 12%
- Heroku Platform: Building and Deployment: 8%
- Heroku Platform - Operations: 12%
- Heroku Platform - Elements: 3%
- Continuous Delivery - Pipelines, Review Apps and CI: 10%
- Data: Redis, Postgres, and Data Clips: 8%
- Data - Kafka & Add-ons: 8%
- Security - SSL, Certs, and ACM: 13%
- Integrations - Heroku Connect, API, and Webhooks: 13%
- Architecting Apps - 12 Factor Methodology: 13%
Thus, the exam covers a wide range of topics.
Note: Unlike the Heroku Architect exam, this certification focuses less on Heroku Enterprise.
Unfortunately, Trailhead doesn't offer training modules specifically for this exam, except for some of the basics covered in "Develop Apps with Heroku".
There are two primary sources of learning materials for the exam that I found.
The first one is, of course, Heroku Dev Center.
It's your best friend, and it has excellent documentation covering all topics.
Another source is the Heroku Developer Curicculum from the Partner Learning Camp if you have access to it.
The main benefit is that it's more organized and focuses on specific topics.
Additionally, one section of the exam is dedicated to architecting the applications.
If you have experience with cloud architecture, you may already be familiar with the 12 Factor Methodology.
However, it's a good idea to refresh your memory and review the Twelve-Factor App Manifest.
Here is a short list taken from the website:
- I. Codebase
- One codebase tracked in revision control, many deploys
- II. Dependencies
- Explicitly declare and isolate dependencies
- III. Config
- Store config in the environment
- IV. Backing services
- Treat backing services as attached resources
- V. Build, release, run
- Strictly separate build and run stages
- VI. Processes
- Execute the app as one or more stateless processes
- VII. Port binding
- Export services via port binding
- VIII. Concurrency
- Scale out via the process model
- IX. Disposability
- Maximize robustness with fast startup and graceful shutdown
- X. Dev/prod parity
- Keep development, staging, and production as similar as possible
- XI. Logs
- Treat logs as event streams
- XII. Admin processes
- Run admin/management tasks as one-off processes
Platform Terminology
Regarding the other topics, you need to understand the main terminology of the platform, for example, the differences between buildpacks, slugs, dynos, and how they work.
Buildpacks are a set of scripts that transform code into a deployable artifact with minimal configuration, which is then executed on a dyno.
Heroku has a set of officially supported buildpacks as well as an auto-detection feature. Otherwise, you can also use third-party buildpacks.
Slugs are compressed and pre-packaged copies of your application optimized for distribution to the dyno manager.
Dynos are Heroku-managed Linux containers that provide secure, scalable compute for your applications. All Heroku applications run on dynos.
You also need to know different dyno types and their use cases, such as
- Web dynos to handle requests and serve responses.
- Worker dynos to run background jobs, queueing systems, and timed jobs.
- One-off dynos for administrative tasks, such as database migrations and console sessions.
SSL, Certs, and ACM
I recall the exam having a few questions on SSL and ACM.
Overall, the platform has four ways to enable SSL.
1. ACM Automated Certificate Management (ACM)
It manages TLS certificates for Hobby and Professional dynos on the Common runtime and Private Spaces that enable that feature.
- Pros:
- Free
- Easy to set up
- Heroku provides and manages renewal
- Supports multiple domains
- Cons:
- No support for wildcard domains
- No support for EV cert
- Does not work with Private and Trusted IPs
- Not compatible with CDNs
- No support for IPv6
- No support for apps with > 100 domains
2. Heroku SSL
It's free for paid dynos, and you can upload your own certificate. Use this option if you need an EV certificate or a wildcard certificate to cover multiple subdomains.
- Pros:
- Free
- Wildcard and EV support
- Cons
- Purchase and renew cert
- Cannot support older browsers without SNI (Server Name Indication)
3. SSL Endpoint
It's available as an add-on for 20$/months and is free for Heroku Private Spaces.
- Pros:
- Supports older browsers
- Can disable TLS 1.0 or 1.1.
- Free with Private Spaces
- Supports WSS
- Cons:
- Purchase and renew cert
- 20$/month with Common Runtime
- May need to contact support
4. Provisioning a 3rd-party add-on
There are many add-ons available, such as those that enforce HTTPS, block DDoS attacks, and require TLS 1.2.
The general guideline is that you should use ACM unless it is not supported.
Heroku Managed Data Services
You should be familiar with Heroku's managed data services and their various use cases.
For example, regarding Heroku Postgres, it is essential to understand the concepts of a fork and a follower, as well as when to use each.
Forked databases offer a risk-free way to work with your production data and schema. For example, you can use them to test new schema migrations or to load test your application on a different database plan. They're also valuable as snapshots of your data at a particular point in time for later analysis or forensics.
A database follower is a read-only copy of the leader database that stays up to date with the leader database data. As writes and other data modifications are committed in the leader database, the changes are streamed, in real time, to the follower databases.
Heroku Dataclips
Do not forget about the Heroku Dataclips.
I recall a few questions on this topic as well, e.g., what databases and formats it supports.
Heroku Dataclips enable you to create SQL queries for your Heroku Postgres databases and share the results with colleagues, third-party tools, and the public. Recipients of a dataclip can view the data in their browser and also download it in JSON and CSV formats.
Heroku Isolated Networks
I don't recall if I had any of the questions, but I suggest learning about the Heroku isolated networks and their use cases.
- Trusted IPs
- VPN
- Private Space Peering
- Private Space DNS Service Discovery
- Internal Routing
An important thing to know is that you should use private space peering to establish a connection to the AWS VPC under your control.
You can connect to other cloud platform networks using VPN connections.
Use internal routing to restrict external traffic on the app level to your web process type. When enabled, it only supports web traffic from the same Private or Shield space, VPC-peered, or VPN-connected networks.
Heroku Data Security
Definitely learn about the platform's data security and compliance.
For example, you should be aware that the highest level of PCI DSS compliance, which is required to process payment data, is only available in Heroku Shield Private Spaces, Shield Dynos, and Shield Heroku Postgres, but not in Heroku Redis, Apache Kafka on Heroku, or Heroku Connect.
Here is a helpful image from the Heroku documentation.
Heroku Flow
You need to learn about the Heroku development flow.
For example, you can use Heroku Pipeline to organize the development process into stages.
Heroku CI is a low-configuration test runner designed to help you catch problems early in the development process.
Heroku Review Apps allow you to spin up temporary test apps when a GitHub PR is opened for connected apps.
You can also integrate Slack into the workflow with Heroku ChatOps. It allows you to deploy apps to staging and promote to production from Slack.
The Release Phase allows you to run tasks before a release is deployed to production, such as migrating databases and uploading assets to the CDN.
Otherwise, there were also some questions about the Heroku CLI commands, but that shouldn't be an issue, as you don't need to remember the exact commands. Instead, you should understand them on a high level and be familiar with their syntax.
Conclusion
In this post, I outline the main topics from the Heroku Developer exam and share the materials that helped me pass it.
The exam itself shouldn't be a problem if you have prior experience with the platform.
Gladly, this exam doesn't focus as much on Heroku Enterprise as the Heroku Architect certification. I didn't have much experience with that, so finding out that I don't need to focus on it has been a relief.
As mentioned at the beginning, there is limited information available about this exam, so I hope this post is helpful to someone.
Nikita Verkhoshintcev
Senior Salesforce Technical Architect & Developer
I'm a senior Salesforce technical architect and developer, specializing in Experience Cloud, managed packages, and custom implementations with AWS and Heroku. I have extensive front-end engineering experience and have worked as an independent contractor since 2016. My goal is to build highly interactive, efficient, and reliable systems within the Salesforce platform. Typically, companies contact me when a complex implementation is required. I'm always open to collaboration, so please don't hesitate to reach out!
