{"id":19774,"date":"2026-09-23T07:33:39","date_gmt":"2026-09-23T07:33:39","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=19774"},"modified":"2026-09-23T07:33:39","modified_gmt":"2026-09-23T07:33:39","slug":"cyberark-epm-def-practice-test-questions-and-exam-dumps-part10-q181-200","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cyberark-epm-def-practice-test-questions-and-exam-dumps-part10-q181-200\/","title":{"rendered":"CyberArk EPM-DEF Practice Test Questions and Exam Dumps Part10 Q181-200"},"content":{"rendered":"

View Full <\/b>CyberArk EPM-DEF Exam Dumps<\/b><\/a> and Practice Test Dumps<\/b><\/h2>\n

 <\/p>\n

Question 181.<\/b><\/p>\n

An EPM administrator wants to prevent a user from elevating software simply by copying a trusted executable into another folder. Which policy design is BEST?<\/b><\/p>\n

    \n
  1. <\/b> Combine application identity with an approved protected path when location is part of the trust requirement<\/span><\/li>\n
  2. <\/b> Trust the filename wherever it runs<\/span><\/li>\n
  3. <\/b> Trust all user profile directories<\/span><\/li>\n
  4. <\/b> Elevate every signed executable<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1. Combine application identity with an approved protected path when location is part of the trust requirement<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    If the business requires elevation only for the installed copy of an application, policy should include both strong application identity and the approved execution context. The trusted installation directory should also be protected so standard users cannot replace files there. Relying only on filename allows easy copying or renaming, while trusting all signed files is too broad because signatures establish publisher identity, not business authorization. Administrators should test copied versions from temporary and user-writable directories to confirm they do not receive unintended privilege. Secure policy design combines precise software identity, protected paths, and narrow scope.<\/span><\/p>\n

    Question 182.<\/b><\/p>\n

    An endpoint has received the latest EPM policy, but an application still behaves differently from identical systems. What should the administrator compare NEXT?<\/b><\/p>\n

      \n
    1. <\/b> Printer configuration<\/span><\/li>\n
    2. <\/b> The application’s local version, hash, path, signature, and related file attributes<\/span><\/li>\n
    3. <\/b> Desktop background<\/span><\/li>\n
    4. <\/b> User email signature<\/span><\/li>\n<\/ol>\n

      Correct Answer: 2. The application’s local version, hash, path, signature, and related file attributes<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      If policy synchronization is confirmed, the next likely cause is a difference in the application itself. One endpoint may have a different version, modified binary, alternate installation path, expired or changed signature, or different supporting files. EPM application matching can depend on these attributes, so even small differences may produce a different policy result. Administrators should compare a working endpoint with the affected device and review the corresponding event records. This evidence-based approach is more useful than changing a policy that already functions elsewhere. Printer and personalization settings generally do not affect application matching.<\/span><\/p>\n

      Question 183.<\/b><\/p>\n

      A security team wants to allow elevation for a tool only when used by members of the IT support group. Which policy control is MOST important in addition to application identification?<\/b><\/p>\n

        \n
      1. <\/b> Browser settings<\/span><\/li>\n
      2. <\/b> Screen-lock policy<\/span><\/li>\n
      3. <\/b> User or group targeting<\/span><\/li>\n
      4. <\/b> Printer mapping<\/span><\/li>\n<\/ol>\n

        Correct Answer: 3. User or group targeting<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        Strong application identification determines what software is trusted, while user or group targeting determines who is authorized to receive elevation for that software. Both are necessary when a tool is appropriate only for a specific job function. Even a legitimate administrative utility should not automatically be elevated for every employee. Administrators should ensure that support-group membership is accurate and periodically reviewed so users who change roles do not retain old privileges. Combining precise application matching with narrow user targeting reduces attack surface and makes the policy easier to audit.<\/span><\/p>\n

        Question 184.<\/b><\/p>\n

        A user-writable directory contains a configuration file that controls the behavior of an elevated application. What is the MAIN risk?<\/b><\/p>\n

          \n
        1. <\/b> The configuration file may consume too much storage<\/span><\/li>\n
        2. <\/b> The endpoint may stop receiving policies<\/span><\/li>\n
        3. <\/b> The application may lose its digital signature<\/span><\/li>\n
        4. <\/b> A user may manipulate the configuration to influence privileged execution**<\/span><\/li>\n<\/ol>\n

          Correct Answer: 4. A user may manipulate the configuration to influence privileged execution<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          An elevated executable can still be unsafe if it consumes user-controlled configuration, scripts, plug-ins, libraries, or command files. A standard user may be able to modify those inputs and cause the privileged process to perform unintended administrative actions. Policy design should therefore evaluate the entire privileged workflow, not only the executable itself. Sensitive configuration should be stored in protected locations or validated before use. This is especially important for extensible tools and applications that load external components dynamically. Strong executable identity alone does not eliminate risk when untrusted users can control what the elevated process reads or executes.<\/span><\/p>\n

          Question 185.<\/b><\/p>\n

          Which action BEST supports safe removal of a broad elevation policy that appears to be unused?<\/b><\/p>\n

            \n
          1. <\/b> Review event history and confirm with the policy owner that the privilege is no longer required<\/span><\/li>\n
          2. <\/b> Delete the policy immediately without checking usage<\/span><\/li>\n
          3. <\/b> Replace it with a global administrator rule<\/span><\/li>\n
          4. <\/b> Disable EPM logging<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1. Review event history and confirm with the policy owner that the privilege is no longer required<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            Unused policies should be retired to reduce attack surface, but removal should be based on evidence. Historical events can show whether the policy has been triggered recently and by whom. The responsible business or technical owner can then confirm whether the underlying application or workflow is still required. This prevents accidental disruption while still supporting least privilege. Removing policies blindly may affect infrequent but important business processes, while retaining broad rules indefinitely creates unnecessary exposure. Good policy governance combines usage evidence, ownership, business validation, and controlled retirement.<\/span><\/p>\n

            Question 186.<\/b><\/p>\n

            A company wants to prevent users from running a prohibited executable even after the file is renamed. Which identification method would be MOST effective for one exact binary?<\/b><\/p>\n

              \n
            1. <\/b> Filename<\/span><\/li>\n
            2. <\/b> Cryptographic hash<\/span><\/li>\n
            3. <\/b> Desktop shortcut<\/span><\/li>\n
            4. <\/b> Folder color<\/span><\/li>\n<\/ol>\n

              Correct Answer: 2. Cryptographic hash<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              A cryptographic hash is calculated from the file contents rather than its visible name. Renaming the executable therefore does not normally change the hash, allowing EPM to continue identifying the exact binary. This is useful for blocking a known malicious or prohibited file. The limitation is that a modified version of the application will usually have a different hash and may require an additional rule or stronger publisher\/product-based criteria. Filename-only rules are easy to bypass, while shortcuts and visual properties provide no reliable software identity. Hash-based matching is highly precise when the organization needs to identify one exact file.<\/span><\/p>\n

              Question 187.<\/b><\/p>\n

              An approved application is signed by a trusted publisher, but one old version is vulnerable and should no longer be elevated. Which policy design is BEST?<\/b><\/p>\n

                \n
              1. <\/b> Trust every version from the publisher<\/span><\/li>\n
              2. <\/b> Disable signature checking<\/span><\/li>\n
              3. <\/b> Add version-specific criteria so the vulnerable release is excluded<\/span><\/li>\n
              4. <\/b> Give users administrator rights for the old version<\/span><\/li>\n<\/ol>\n

                Correct Answer: 3. Add version-specific criteria so the vulnerable release is excluded<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                Publisher trust identifies the software vendor but does not mean every version should receive the same privilege. If a particular release is vulnerable, policy can be refined using version information or other attributes so only approved versions are elevated. This should be coordinated with patching or application-removal processes so vulnerable software is replaced rather than simply left unprivileged indefinitely. Disabling signature validation weakens trust, while broad publisher trust would continue elevating the risky version. Application policies should evolve as security information changes, especially for privileged software.<\/span><\/p>\n

                Question 188.<\/b><\/p>\n

                A policy elevates a trusted installer, but the installer can launch any user-specified executable as a child process. What should the administrator investigate?<\/b><\/p>\n

                  \n
                1. <\/b> Desktop wallpaper<\/span><\/li>\n
                2. <\/b> Printer driver<\/span><\/li>\n
                3. <\/b> Monitor configuration<\/span><\/li>\n
                4. <\/b> Whether child processes inherit elevation and can be controlled by the user**<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 4. Whether child processes inherit elevation and can be controlled by the user<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  If an elevated installer can start arbitrary user-selected programs and those child processes inherit privilege, the policy may provide a general administrative bypass. Administrators should examine process-tree behavior, command-line parameters, helper programs, and whether users can influence which child executables are launched. If elevation propagates too broadly, the policy should be refined or an alternate workflow used. Testing only the parent executable is insufficient because the real privilege boundary may extend into its descendants. This is especially important for installers, shells, script engines, and management consoles.<\/span><\/p>\n

                  Question 189.<\/b><\/p>\n

                  An EPM administrator needs to identify why several users suddenly started receiving elevation prompts for the same business application. What should be reviewed FIRST?<\/b><\/p>\n

                    \n
                  1. <\/b> Recent application updates and related EPM events<\/span><\/li>\n
                  2. <\/b> Printer usage reports<\/span><\/li>\n
                  3. <\/b> User desktop themes<\/span><\/li>\n
                  4. <\/b> Network cabling diagrams<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1. Recent application updates and related EPM events<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    A sudden increase in prompts often follows an application update that changed a hash, executable path, signature, version, helper process, or privilege requirement. EPM events can show which component is triggering the prompt and which policy is being applied. Comparing the current application with the previously working version helps determine whether the existing rule needs adjustment. This is more efficient than assuming a user-specific problem when multiple users experience the same behavior. Application lifecycle changes should always be considered when established EPM policies suddenly stop matching or produce new privilege interactions.<\/span><\/p>\n

                    Question 190.<\/b><\/p>\n

                    A user requests a temporary EPM exception for a one-day maintenance activity. Which configuration BEST supports least privilege?<\/b><\/p>\n

                      \n
                    1. <\/b> Permanent elevation for the user<\/span><\/li>\n
                    2. <\/b> A narrowly scoped exception with a defined expiration time<\/span><\/li>\n
                    3. <\/b> Global administrator rights for the department<\/span><\/li>\n
                    4. <\/b> Disable EPM until maintenance is complete<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2. A narrowly scoped exception with a defined expiration time<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      Temporary work should normally receive temporary privilege. The exception should be limited to the required user, endpoint, application, and maintenance period, with a clear business justification and owner. Automatic expiration is useful where supported because it removes access even if an administrator forgets to clean up manually. Permanent elevation or department-wide privilege would significantly exceed the stated requirement. Disabling EPM would also affect unrelated software. Time-bounded exceptions are an important way to support unusual operational needs while maintaining the broader least-privilege model.<\/span><\/p>\n

                      Question 191.<\/b><\/p>\n

                      Which activity BEST verifies that a new EPM elevation policy is not overly broad?<\/b><\/p>\n

                        \n
                      1. <\/b> Test both the intended application and similar unapproved executables that might match the same criteria<\/span><\/li>\n
                      2. <\/b> Test only whether the approved application opens<\/span><\/li>\n
                      3. <\/b> Disable event collection during testing<\/span><\/li>\n
                      4. <\/b> Test only with an administrator account<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 1. Test both the intended application and similar unapproved executables that might match the same criteria<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        Positive testing confirms functionality, while negative testing confirms security. Administrators should verify that the intended application receives elevation and then deliberately try similar files, alternate versions, copied executables, related vendor tools, and applications launched from untrusted locations. This can reveal rules that are too broad before they reach production. Testing only the successful use case does not show whether unintended software also matches. Event collection should remain enabled because policy decisions and process behavior provide valuable evidence during testing.<\/span><\/p>\n

                        Question 192.<\/b><\/p>\n

                        A company wants to prevent a known application from running on a sensitive endpoint group while allowing it elsewhere. Which EPM feature is MOST appropriate?<\/b><\/p>\n

                          \n
                        1. <\/b> Global elevation<\/span><\/li>\n
                        2. <\/b> Targeted application blocking<\/span><\/li>\n
                        3. <\/b> Shared administrator credentials<\/span><\/li>\n
                        4. <\/b> Policy logging disablement<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 2. Targeted application blocking<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          Application control can block a specific executable only for the endpoints or users where the risk is unacceptable. Policy targeting allows the organization to distinguish sensitive systems from general-purpose endpoints rather than applying the same rule everywhere. The application should be identified reliably so users cannot bypass the restriction by renaming or moving it. Event monitoring can then reveal attempted execution on protected systems. Global elevation would have the opposite effect, while credential sharing and disabled logging would weaken security. Targeted blocking supports risk-based application control without unnecessarily disrupting other parts of the business.<\/span><\/p>\n

                          Question 193.<\/b><\/p>\n

                          A security administrator wants to know whether an EPM exception is still justified six months after creation. What should be reviewed?<\/b><\/p>\n

                            \n
                          1. <\/b> User wallpaper<\/span><\/li>\n
                          2. <\/b> Endpoint monitor model<\/span><\/li>\n
                          3. <\/b> Business ownership, event usage, current scope, and original justification<\/span><\/li>\n
                          4. <\/b> Printer settings<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 3. Business ownership, event usage, current scope, and original justification<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            Exceptions should be periodically recertified to determine whether they remain necessary. Administrators should confirm that the owner still supports the business need, review whether the exception has actually been used, check that its scope has not expanded unintentionally, and compare current requirements with the original justification. If the application or project has ended, the exception should be removed. If the need remains, the rule may be retained or redesigned as a formal standard policy. Regular recertification prevents temporary privileges from silently becoming permanent.<\/span><\/p>\n

                            Question 194.<\/b><\/p>\n

                            An endpoint is correctly targeted by a new EPM policy but still shows an older policy version. What is the MOST likely area to troubleshoot?<\/b><\/p>\n

                              \n
                            1. <\/b> Monitor settings<\/span><\/li>\n
                            2. <\/b> Printer mapping<\/span><\/li>\n
                            3. <\/b> User email client<\/span><\/li>\n
                            4. <\/b> Agent synchronization and communication**<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 4. Agent synchronization and communication<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              Correct targeting does not guarantee successful policy delivery. If the endpoint still shows an older version, administrators should check agent health, connectivity to the management service, recent check-in information, certificates, service status, and synchronization logs. Remote or intermittently connected systems are particularly likely to experience policy delays. Until the current policy arrives, the endpoint may continue enforcing the previous configuration. Reinstalling applications or altering unrelated endpoint settings should not be the first response. Policy-version verification helps distinguish targeting problems from communication problems.<\/span><\/p>\n

                              Question 195.<\/b><\/p>\n

                              A user-writable directory is included in an EPM elevation rule because a legacy application runs from that location. What is the BEST compensating action?<\/b><\/p>\n

                                \n
                              1. <\/b> Reduce user write access where possible and strengthen application identification criteria<\/span><\/li>\n
                              2. <\/b> Trust every executable in the directory<\/span><\/li>\n
                              3. <\/b> Disable application events<\/span><\/li>\n
                              4. <\/b> Expand the rule to all temporary folders<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 1. Reduce user write access where possible and strengthen application identification criteria<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                User-writable locations are risky because users or malware may modify, replace, or add executables. If a legacy business requirement makes such a path unavoidable, administrators should reduce write permissions where technically possible and combine path with stronger application identity such as publisher, hash, product information, or other supported attributes. The rule should also be narrowly targeted and monitored closely. Trusting every executable in the directory would create a straightforward elevation path. Compensating controls are necessary when ideal least-privilege architecture cannot be implemented immediately.<\/span><\/p>\n

                                Question 196.<\/b><\/p>\n

                                An organization wants EPM policy changes to be attributable to individual administrators. Which administrative practice is BEST?<\/b><\/p>\n

                                  \n
                                1. <\/b> Use one shared EPM administrator account<\/span><\/li>\n
                                2. <\/b> Assign individual administrator identities and retain audit history<\/span><\/li>\n
                                3. <\/b> Disable management logging<\/span><\/li>\n
                                4. <\/b> Allow anonymous configuration changes<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 2. Assign individual administrator identities and retain audit history<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  Individual identities create accountability because policy changes can be traced to the administrator who performed them. Retained audit history provides additional evidence about what changed and when, which is important for troubleshooting, security reviews, and change governance. Shared accounts make attribution difficult, while anonymous changes or disabled logging eliminate reliable accountability. EPM configuration is security-sensitive because a single policy change can grant or remove privilege across many endpoints. Administrative access should therefore follow strong identity, least privilege, and auditing practices.<\/span><\/p>\n

                                  Question 197.<\/b><\/p>\n

                                  A user changes roles and no longer requires an EPM elevation policy assigned through a department group. What should happen?<\/b><\/p>\n

                                    \n
                                  1. <\/b> Remove the user from the obsolete target group as part of role-change access review<\/span><\/li>\n
                                  2. <\/b> Keep the privilege permanently<\/span><\/li>\n
                                  3. <\/b> Add more elevation rules<\/span><\/li>\n
                                  4. <\/b> Disable all group targeting<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1. Remove the user from the obsolete target group as part of role-change access review<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    Privileges should reflect the user’s current responsibilities. When employees transfer between departments or roles, old access should be reviewed and removed if no longer required. Leaving the user in the former EPM target group creates privilege accumulation and increases risk. Group-based policy targeting remains valuable because it simplifies administration, but it depends on accurate membership. Integrating EPM group review into employee lifecycle processes helps ensure that elevation follows current business need rather than historical assignment.<\/span><\/p>\n

                                    Question 198.<\/b><\/p>\n

                                    A company wants to identify whether blocked applications are mostly legitimate business tools or suspicious software. Which approach is BEST?<\/b><\/p>\n

                                      \n
                                    1. <\/b> Ignore blocked events<\/span><\/li>\n
                                    2. <\/b> Analyze EPM block events by application, user, endpoint, frequency, and business context<\/span><\/li>\n
                                    3. <\/b> Allow every blocked application temporarily<\/span><\/li>\n
                                    4. <\/b> Give users local administrator rights<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 2. Analyze EPM block events by application, user, endpoint, frequency, and business context<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      Blocked-event analysis helps administrators distinguish policy gaps from genuine security issues. Repeated blocks involving the same approved business software may indicate the need for a refined policy, while unknown executables appearing unexpectedly across many endpoints may require security investigation. User, endpoint, frequency, application identity, and timing provide valuable context. Automatically allowing blocked software would undermine application control, and administrator rights would bypass the restriction entirely. Event analysis supports both security operations and policy improvement by turning enforcement data into actionable information.<\/span><\/p>\n

                                      Question 199.<\/b><\/p>\n

                                      An EPM administrator sees an elevation policy being used by endpoints outside its expected department. What should be checked FIRST?<\/b><\/p>\n

                                        \n
                                      1. <\/b> Policy scope, group membership, and target assignments<\/span><\/li>\n
                                      2. <\/b> Printer status<\/span><\/li>\n
                                      3. <\/b> Endpoint wallpaper<\/span><\/li>\n
                                      4. <\/b> Keyboard layout<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1. Policy scope, group membership, and target assignments<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        Unexpected policy usage often results from incorrect targeting, stale group membership, inherited assignment, or a broader scope than intended. Administrators should verify which users and endpoints are included in the policy and compare that with the approved business requirement. Event data can help identify exactly where the rule is being triggered. Once the scope issue is corrected, administrators should confirm that affected endpoints receive the updated configuration. Unrelated endpoint settings do not determine policy assignment. Precise targeting is a fundamental part of least privilege.<\/span><\/p>\n

                                        Question 200.<\/b><\/p>\n

                                        Which statement BEST describes effective long-term CyberArk EPM defense management?<\/b><\/p>\n

                                          \n
                                        1. <\/b> Create policies once and leave them unchanged<\/span><\/li>\n
                                        2. <\/b> Trust all applications from known publishers<\/span><\/li>\n
                                        3. <\/b> Focus only on removing local administrator rights<\/span><\/li>\n
                                        4. <\/b> Continuously validate application trust, policy scope, exceptions, agent health, event trends, and changing business requirements**<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 4. Continuously validate application trust, policy scope, exceptions, agent health, event trends, and changing business requirements<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          EPM defense is an ongoing process rather than a one-time deployment. Applications are updated, users change roles, business workflows evolve, and new security risks emerge. Administrators must therefore maintain accurate application definitions, narrow policy targeting, healthy agents, current policy synchronization, and well-governed exceptions. Event trends help identify policy gaps, suspicious activity, and obsolete privileges. Trusted publishers can still release vulnerable software, and standing administrator removal alone does not address application-control risk. Mature EPM management combines least privilege, application control, operational monitoring, policy lifecycle governance, and continuous reassessment so endpoint protection remains effective over time.<\/span><\/p>\n

                                           <\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full CyberArk EPM-DEF Exam Dumps and Practice Test Dumps   Question 181. An EPM administrator wants to prevent a user from elevating software simply by copying a trusted executable into another folder. Which policy design is BEST? Combine application identity with an approved protected path when location is part of the trust requirement Trust […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/19774"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=19774"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/19774\/revisions"}],"predecessor-version":[{"id":19775,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/19774\/revisions\/19775"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=19774"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=19774"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=19774"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}