Practice Elixir & Phoenix developer English through realistic code review scenarios: JWT authentication with Guardian, rate limiting with Hammer, Ecto queries, and OTP GenServer design discussions.
0 / 19 completed
1 / 19
Liam: 'Just finished implementing the new user authentication flow. Using Phoenix’s `Guardian` module for JWTs and added a simple rate limiting middleware to protect against brute force attacks. Looks good!'
During code review, your colleague, Maya, comments: ‘I'm seeing you're using `Guardian`. Could you elaborate on the specific configuration options you’ve set for it? Specifically, I want to understand how you handled expiry times and what rate limit you’ve applied.’
Which of the following responses best addresses Maya’s concerns?
The correct answer highlights the importance of explicitly stating configuration choices. Maya isn't questioning whether Guardian is *appropriate* (option A), but rather *how* it was configured. Options B, C, and D present overly simplistic or misleading statements – implying automatic behaviour where there isn’t one, or a lack of understanding about core settings like expiry times and rate limits within the `Guardian` module. Understanding these specifics demonstrates proactive communication and attention to detail during code review.
2 / 19
Sarah: ‘Hey team, just merged the new user authentication flow into Phoenix. It’s using JWT for tokens and a dedicated schema in Postgres. Let me know if you spot any issues!’
During a code review, Mark comments:
‘Could you explain why we’re persisting the entire JWT payload instead of just the user ID? Seems like a potential security risk if this data gets exposed.’
This question tests understanding of secure coding practices in Elixir/Phoenix. While persisting the entire JWT payload isn't inherently wrong, it’s generally considered a security risk because it exposes more data than strictly necessary. The key here is recognizing that exposing sensitive information—even if intended for future use—can create vulnerabilities. Mark's comment highlights this concern effectively.
3 / 19
Liam: "Hey team, just finished implementing the new user profile endpoint. It uses Phoenix’s Repo to fetch data and Ecto.Query to filter by ID. I've added comprehensive tests for all scenarios."
This comment demonstrates a good start, showing Liam’s use of Phoenix tools. However, it's missing crucial elements for a code review. A strong response would highlight the importance of validating request payloads (to prevent bad data), and discussing error handling and logging mechanisms—a developer should always consider how failures will be managed and tracked. The comment also doesn't address potential performance bottlenecks or database interactions.
4 / 19
Sarah: 'Hey team, just finished implementing the new user authentication flow using Phoenix’s Guardian. I've added rate limiting with Hammer to prevent brute-force attacks and ensured proper logging of all failed attempts. The API endpoint now returns a 401 Unauthorized if credentials are invalid after three attempts, followed by a 429 Too Many Requests after six. I’m using the Ecto.Repo for database interactions.'
Which of the following best summarizes Sarah's update during a code review?
This question tests understanding of common phrasing used when describing a completed implementation during a code review. The key here is that Sarah is detailing *what* she did and *why*. Option A is incorrect because rate limiting is explicitly mentioned. Option C is wrong as it misrepresents the focus; authentication logic is implied, not stated directly. Option D also misses the crucial point about how Hammer contributes to security – preventing abuse.
5 / 19
Sarah: ‘Hey team, just pushing a PR with the new user authentication flow. Using Phoenix's live_view to handle real-time updates and integrating with our existing Guardian service. Let me know if you spot any issues!’
During code review, your colleague, Mark, comments: ‘Could you explain the rationale behind using a separate Guardian service instead of directly hashing passwords in the live view? It seems like a potential security risk.’ Which response best addresses Mark's concern and aligns with best practices?
This question assesses understanding of security best practices within Elixir/Phoenix development. Option 2 is incorrect because directly hashing passwords in a live view is indeed a significant security risk – it exposes the password hash to potential vulnerabilities. Option 1 dismisses Mark's concern without justification and doesn’t highlight the benefits of abstraction. Option 3 accurately explains why decoupling authentication logic into a separate service, like Guardian, improves flexibility and adds a crucial defense against attacks, while option 4 is a completely inappropriate response demonstrating a lack of awareness.
6 / 19
Mark: 'I've noticed you're using `Ecto.Query` directly within the controller action for this user creation endpoint. While it works, isn't that generally discouraged in Phoenix due to potential issues with testability and separation of concerns? Could you explain your reasoning?'
Which response best addresses Mark's feedback regarding the use of `Ecto.Query`?
The correct answer highlights the importance of refactoring for testability and maintainability – a key principle in Phoenix development. Options A and D are dismissive or incorrect justifications. Option C demonstrates awareness of the issue and a plan to address it, aligning with good coding practices. This reflects a developer's understanding of separation of concerns.
7 / 19
Sarah: 'Just deployed the new API endpoint for fetching product details. It's built with Phoenix and uses the `Phoenix.Controller` framework. I've included a Swagger documentation link for easy integration.'
During code review, Liam comments: 'Could you elaborate on how you're handling errors in this endpoint? Specifically, what happens when an item ID doesn't exist?'
Returning a 404 Not Found is the standard and recommended approach for invalid IDs in RESTful APIs. Options B and D represent over-engineering or inappropriate error handling strategies. Option C suggests an overly simplistic solution that may not adequately address all potential issues.
8 / 19
Sarah is discussing a potential issue in a standup update: 'I've added rate limiting with Hammer to prevent brute-force attacks and ensured proper logging of all failed attempts when creating user accounts.', what is the *primary* benefit Sarah is communicating?
Sarah's update clearly focuses on mitigating a significant security risk – brute force attacks. Rate limiting and detailed logging are crucial defenses against this type of attack. While other aspects might be involved, the core message is about improving security posture through proactive measures.
9 / 19
Mark comments on a Slack channel: 'The API response for fetching product details includes a Swagger documentation link. That's great for developers integrating with our service!' What is Mark highlighting regarding the provided API response?
Mark is praising the inclusion of Swagger documentation. This type of documentation provides developers with clear technical specifications – including endpoints, parameters, and expected responses – which significantly simplifies integration efforts. It's a best practice for creating easily consumable APIs.
10 / 19
Liam just submitted a PR for the new user registration flow. He's using Phoenix's `Guardian` module for JWTs and includes a middleware function to limit requests per IP address. During a code review, Mark asks: 'Are you handling password reset flows with this approach?' What is Mark primarily questioning about Liam's implementation?
Mark is questioning whether Liam has addressed a critical aspect of user security – password reset functionality. While JWTs are commonly used for authentication, a separate and secure mechanism is *essential* for users to recover their accounts if they forget their passwords. This highlights the importance of considering all aspects of the user journey during code reviews, not just the initial registration.
11 / 19
Sarah is explaining a change in Slack: 'I've implemented a new feature using Phoenix LiveView for real-time updates on user dashboards. The component uses the `Phoenix.LiveView` module and dynamically renders content based on WebSocket messages.' A developer, David, responds: 'Can you describe how you're managing state transitions within the LiveView?' What does David want to understand about Sarah's code?
David is focusing on a core aspect of Phoenix LiveView development – state management. LiveViews are designed to handle real-time updates by managing state changes triggered by user interactions or server events. Understanding how Sarah is handling these transitions is crucial for maintaining the application's responsiveness and preventing unexpected behavior.
12 / 19
Liam writes in a code review comment: 'I've refactored this module to use `Ecto.Query` directly within the controller action. It simplifies the logic and improves performance.' Mark replies: 'Are you sure this approach adheres to Phoenix's best practices for testability, considering the potential challenges in mocking Ecto queries?' What is Mark primarily concerned about?
Mark is raising a key concern about testability – a fundamental principle in Phoenix development. Directly using `Ecto.Query` within a controller makes it extremely difficult to mock and test the query logic independently, leading to brittle tests and increased maintenance effort. This highlights the importance of abstraction layers for improved testability.
13 / 19
Sarah is describing a new API endpoint in a Slack channel: 'I've created an endpoint that returns product details using Phoenix and integrates with our existing Guardian service for authentication. I've included a Swagger documentation link for easy integration.' David asks: 'How does the API handle potential rate limiting scenarios?' What aspect of the API is David focusing on?
David is specifically concerned about a crucial aspect of API design – rate limiting. Even if the authentication is handled correctly (as noted in Sarah's description), the API needs to protect itself from abuse and overload. Understanding how the endpoint manages requests beyond the defined limits is essential for overall system stability.
14 / 19
Sarah is explaining a change to the team via Slack: 'I've implemented a new feature using Phoenix LiveView for real-time updates on user dashboards. The component uses the Phoenix.LiveView module and dynamically renders content based on WebSocket events.' Which of the following best describes Sarah's explanation?
A. She's detailing a complex database query optimization.
B. She's outlining the use of Phoenix LiveView for real-time updates, highlighting its dynamic rendering capabilities and WebSocket integration.
C. She's describing the implementation of a new authentication protocol using JWTs.
D. She's explaining how to deploy the application to production.
Sarah is focusing on the core functionality – Phoenix LiveView. This framework dynamically renders content based on events, particularly leveraging WebSockets for real-time updates. Option B accurately captures this technical description, while the other options represent different aspects of development (database optimization, authentication, deployment).
15 / 19
Liam is writing a PR description for a change to the user registration flow. He states: 'I've added rate limiting with Hammer to prevent brute-force attacks and ensured proper logging of all failed attempts when creating user accounts.' Which aspect is Liam primarily addressing?
A. The performance optimization of the database queries.
B. Security vulnerabilities, specifically protecting against denial-of-service attacks through rate limiting and robust logging.
C. The user interface design for the registration form.
D. The integration with third-party authentication services.
Liam's description highlights security concerns – preventing brute-force attacks. Rate limiting (with Hammer) directly addresses this vulnerability, while logging provides crucial information for monitoring and incident response. Options A, C, and D relate to different aspects of the application that are not central to Liam's current focus.
16 / 19
During a code review of a PR introducing a new user onboarding flow using Phoenix LiveView and the Phoenix.LiveView module, David comments: 'This dynamically rendered component uses a lot of complex state management. Are you considering alternative approaches like SignalFlux for handling real-time updates?' What is David primarily questioning regarding the implementation?
A) The use of Phoenix LiveView itself. B) The efficiency of the Ecto.Query used to fetch user data. C) The complexity and scalability of the state management strategy. D) The security measures implemented against potential attacks.
David's comment highlights a key concern during code reviews: scalability. While LiveView is appropriate for dynamic UI updates, complex state management can quickly become difficult to maintain and scale. The question probes whether a more robust solution like SignalFlux would be suitable for handling real-time data changes efficiently. Options A, B, and D are irrelevant to the core issue of design choices regarding state management.
17 / 19
Sarah is discussing a potential performance bottleneck in a Slack channel: 'I've refactored the product detail API endpoint to utilize Phoenix's `Phoenix.GenServer` for handling asynchronous requests and caching frequently accessed data. This should significantly improve response times.' Which of the following best describes Sarah's rationale?
A) She is optimizing database queries using Ecto.Query. B) She is implementing a more efficient approach to handle concurrent requests and reduce latency. C) She is simplifying the API endpoint's logic by removing unnecessary middleware. D) She is improving the user interface's responsiveness by utilizing AJAX calls.
Sarah's explanation clearly indicates she's addressing a potential bottleneck by leveraging `Phoenix.GenServer` for asynchronous processing and caching. This approach is crucial for handling concurrent requests efficiently, reducing latency—the primary goal of optimizing API response times. Options A, C, and D represent alternative strategies that are not the focus of her comment.
18 / 19
Liam writes in a code review comment: 'I've implemented rate limiting with Hammer to prevent brute-force attacks and ensured proper logging of all failed attempts when creating user accounts.' Mark replies: 'That's good, but are you monitoring the number of failed login attempts to proactively identify potential attackers?' What is Mark highlighting regarding Liam's approach?
A) The importance of using a robust authentication system. B) The need for comprehensive logging and auditing practices. C) The significance of proactive threat detection and response measures. D) The effectiveness of the Hammer library in blocking malicious traffic.
Mark's comment shifts the focus from simply implementing rate limiting with Hammer (logging failed attempts) to proactive threat detection. Monitoring failed login attempts allows for real-time identification of potential attackers and enables a more responsive security strategy. This emphasizes a crucial element often overlooked: actively analyzing data to anticipate and mitigate risks.
19 / 19
Liam is writing a PR description for a change to the user registration flow. He states: 'I've added rate limiting with Hammer to prevent brute-force attacks and ensured proper logging of all failed attempts when creating user accounts.' A reviewer asks, 'How are you validating that the rate limiting is actually effective?' What is the most appropriate response from Liam?
A) 'Hammer automatically handles rate limiting, so no further validation is needed.' B) 'I've configured Hammer to block IP addresses after a certain number of failed attempts.' C) 'I'm monitoring the logs for an increase in failed login attempts as evidence of effectiveness.' D) 'The authentication service automatically handles rate limiting, so I don't need to implement it myself.'
Validating rate limiting's effectiveness goes beyond simply implementing it. Monitoring the logs—specifically looking for an increase in failed login attempts—provides tangible evidence that the rate limiting mechanism is functioning as intended and preventing brute-force attacks. This demonstrates a proactive approach to ensuring security.
What does the "Elixir & Phoenix Code Review English" vocabulary exercise cover?
This exercise tests real IT vocabulary related to elixir & phoenix code review english through 19 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 19 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.